在 client 中已经看到 Docker CLI 在给 Docker Daemon 发生构建上下文时，通过设置 X-Registry-Config 传递凭证，但在最近的构建反馈中，还是会出现一些无法解释的现象，本篇主要是进行一些基础的测试，以便于更好排查问题。 1. 宿主机 Docker 下构建 Docker Daemon 以 root 用户权限启动。 未登录任何账户 1 2 3 4 su ansible echo "FROM harbor.chenshaowen.com/private/test:v1" | sudo

1. 遇到的问题 项目介绍: 文件大小 5.6 GB 文件数量 529352 Dockerfile 1 2 3 FROM golang:1.13 COPY ./ /go/src/code 构建命令及输入如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile . --progress=plain #1 [internal] load build definition from Dockerfile #1 sha256:2a154d4ad813d1ef3355d055345ad0e7c5e14923755cea703d980ecc1c576ce7 #1 transferring dockerfile: 37B done #1 DONE 0.1s #2 [internal] load .dockerignore #2 sha256:9598c0ddacf682f2cac2be6caedf6786888ec68f009c197523f8b1c2b5257b34 #2 transferring context: 2B

最近碰到两次，因故障需要重装主机系统。其中一次 Etcd 只剩下一个节点，导致整个集群宕机半个小时才恢复。本篇主要记录的是新系统 Ubuntu 20.04 初始化的过程，完成初始化之后采用优秀的集群安装工具 Kubekey 的 add nodes 命令，无需修改配置文件，一键就将节点重新加入了集群。 1. 恢复 Etcd

1. 本地存储容量 所需磁盘大小（GB） = 数据保留时长 _ 每秒获取指标数量 _ 指标数据大小 / 1024 / 1024 / 1024 其中 每秒获取指标数量 rate(prometheus_tsdb_head_samples_appended_total[1d]) 一个小时内样本的平均大小 rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1d])/rate(prometheus_tsdb_compaction_chunk_samples_sum[1d]) 一天（86400 秒）的磁盘消耗，可以在 Prometheus 中直接查询: 86400 * (rate(prometheus_tsdb_head_samples_appended_total[1d]) * (rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1d]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1d]))) / 1024 /1024 / 1024 例如，返回 {instance="localhost:9090", job="prometheus"} 4.437

设置合理的 Req 和 Limit 不设置 Req 和 Limit，当应用的 CPU、MEM 暴涨时，会危害同一节点上的其他 Pod，甚至导致集群节点一个接一个被压垮。 Req 和 Limit 一共有四个值，如果只设置部分值，当节点资源使用率达到 Kubelet 预设值时，Kubelet 会驱逐 Pod，驱逐的顺序