使用 nvidia-container-runtime 的朋友可以重点关注下，特别是还有 JuiceFS 的情况。 1. 突然收到告警，我慌了 周末，学习 TensorRT LLM，顺便给线上最大的正式集群安装了一下 Dragonfly，然后就去买菜了。 下午发现有个节点的 Dragonfly Daemon 没起来，一直告警，就去所在节点重启了下 Kubelet。 大约

1. 现象 业务反馈应用 app-a 的接口慢，查看日志发现是某一个 Pod 慢，删除该 Pod 让其更换节点就好。 从监控指标可以看到，Pod 的 CPU 使用率确实有剧增。 但该 Pod 没有达到 Limit 的限制，没有被限流 CPU。 接着看节点的 CPU 监控，发现节点的 CPU 使用率也有剧增。 并且增加的部分是 System C

1. DNS 请求超时 原因: alpine 使用的是 musl 库，在 DNS 解析上会有一些限制[1] 解决方式： 不使用 apline 镜像，并在容器 resolv.conf 文件中增加 options single-request-reopen 配置。因为 single-request-reopen 配置项只对 glibc 库生效，但是 apline 镜像使用的是 musl 库 2. Docker 下无法解析 hosts 原因: alpine 没有 /etc/nsswitch.conf，导致依赖 hosts

在 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