Unlike on CentOS or Ubuntu, where we feel that mv is faster than cp, when you build an image with a Dockerfile, using Run cp is faster than Run mv. This post presents the test and verification data behind that. 1. Test Setup Machine environment Ubuntu 20.04.1 LTS 32C

Recently I ran into this twice: a host had to be reinstalled because of a failure. In one case only a single Etcd node was left, and the whole cluster stayed down for half an hour before it recovered. This post mainly records the process of initializing a fresh Ubuntu

Elastic scaling mainly has three dimensions: HPA, which automatically scales the number of Pods based on utilization VPA, which automatically sets a Pod’s Request and Limit based on historical data CA, which automatically scales the number of Nodes based on usage This post focuses on the node scaling part. 1. The autoscaler Autoscaling Component autoscaler is a project maintained by the Kubernetes community.

1. Purpose of the Test Tune the parameters of the build cluster Probe the upper limit on the number of concurrent Tekton pipelines Give the optimal concurrency limit for a single cluster 2. Related Components and Machine Configuration Kubernetes version v1.21.4 Tekton version v0.24.1, kept consistent with production OpenEBS version localpv version 3.

1. Local Storage Capacity Required disk size (GB) = data retention period _ samples fetched per second _ metric data size / 1024 / 1024 / 1024 Where Samples fetched per second: rate(prometheus_tsdb_head_samples_appended_total[1d]) Average size of a sample within one hour: rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1d])/rate(prometheus_tsdb_compaction_chunk_samples_sum[1d]) The disk consumption for one day (86400 seconds) can be queried directly in Prometheus: