容器运维视角：技术讨论应回归客观本质

　　我越来越觉得“容器运维视角：技术讨论应回归客观本质”是错的。

　　不是偏了，是根基上就悬着——像我们去年在东莞新园区那台跑着 kubelet 的边缘节点，物理内存插槽没插满，监控里 RSS 涨到 92%，告警却压根没响。值班的阿哲连敲三遍 `kubectl describe node`，盯着 Conditions 里那行 `Ready:True` 看了两分钟，说“指标都绿，应该没事”。结果凌晨三点它自己飘了——Pod 全挂，kubelet 进程还在 heartbeat，就是不接 API Server 新请求。日志里只有七条 `http: TLS handshake error`，全是同一个源 IP，可那 IP 是集群内 Service 的 ClusterIP，根本不可能发 TLS 握手。后来查出来是 etcd 客户端连接池复用时把旧连接的 tls.Conn 误当新连接塞进 http.Transport，底层 socket 已 close，但上层没判空。没人报 bug，没人修，因为“现象不复现”。

　　我原以为只要把 metrics 拉全、把日志埋深、把 SLO 卡死，技术讨论自然会沉到底层逻辑里去。结果今年春节前，我们在深圳机房做 k8s 1.28 升级，灰度十七个站，第十四个站上线后第七小时，某个核心服务突然 503 率跳到 18%。我拉出所有指标——CPU、内存、网络丢包、etcd latency、apiserver request duration……全正常。连 istio-proxy 的 access log 都扫了三百多万行，只看到一行 `upstream_reset_before_response_started{remote_connection_failure}`。最后发现是新版本 kubelet 在处理带 subPath 的 downwardAPI volume 时，把 containerID 字符串截断了一位，导致 cAdvisor 报告的 container_metrics 和 CRI 返回的 status 不匹配，kubelet 就把那个容器标成了 `Unknown`，但 Pod phase 还是 `Running`。我们对着 `kubectl get pod -o wide` 看了四十三分钟，就盯着 `STATUS` 那栏的 Running 发愣。李工蹲在地上啃冷馒头的时候还嘟囔：“这不客观么？状态明摆着。”

　　所以说，所谓“客观本质”，就是你愿意信哪一层的数据。是 cgroup.stat 里的 `pgmajfault`？还是 /proc/1/cgroup 里那串 hash？还是 `kubectl get node` 输出里那行 `Conditions:`？它们全是客观的，可全是错的拼图。就像上次珠海灾备演练，三个环境配的 ConfigMap 名字一模一样，唯独生产多了一个 trailing space——不是换行，是空格，藏在 YAML 文件末尾。CI 流水线跑过，helm template 渲染完也看不出异常，直到 service mesh 的 mTLS 认证失败，证书 subject 里多了个 `CN=appname `（注意那个空格），CA 拒绝签发。运维老张拿 vim -b 打开文件，放大字号，把光标停在最后一行最后一位，眯着眼看了四十秒，吐了口烟：“啧，这儿有东西。”——他没看文档，没看 RFC，没查 Kubernetes source，他就靠眼力认出一个不可见字符。这客观吗？当然客观。本质吗？不，本质是懒。

　　反常识结论就在这儿：技术讨论越想回归“客观本质”，就越容易集体失明。因为你刚锁死一个“本质”，别人立刻用另一个本质把你绕死。比如上周跟杭州团队吵 gRPC Keepalive 配置，他们坚持 client-side 设置 idle_timeout=30s 就能保活；我说你忘了 transport 层的 TCP keepalive 会被中间防火墙截断——结果上海那个叫林薇的女同学直接甩出 pcap：三次 SYN ACK 后第 47 秒收到 FIN，Wireshark 显示 TCP timestamp 差值是 46.987，她连小数点后三位都标红了。可我们俩谁也没提那台阿里云 SLB 实际用了自研 TCP stack，根本不会发 FIN，只伪造 reset。这事我试了三个月都没复现，就因为只有凌晨两点他们那边 CDN 节点轮转时才触发一次。

文章配图，仅供参考

　　所以现在我听人讲“本质”，第一反应是翻他们上个月 Prometheus alert_history 里有没有 `NodeHighNumOfContainerRestarts` 这条告警没处理——没有的话，免谈本质。有次在厦门开会，隔壁组一个戴圆框眼镜的实习生举手问：“老师，如果容器本质是进程，那 systemd-run 跟 docker run 有区别吗？”全场静了五秒，然后大刘——就是当年写过《Kubernetes 生产排障手册》那个——把茶杯往桌上一顿，说：“有，docker run 失败会删掉整个 /var/lib/docker/overlay2，systemd-run 失败只删 /tmp 下的 unit 文件。”他说完自己先笑了。我们当时都笑，可现在想想，这才是真话。容器不是抽象概念，是磁盘上一堆被 rm -rf 掉又重建的目录，是 inode 号撞车时内核悄悄改写 dentry 的那一刻。

　　再说个无关的：上周四下午三点，广州数据中心机柜顶部漏水，顺着桥架滴到第三列 U22-U24 的交换机背面，其中一台的电源模块指示灯开始间歇闪烁紫光，但 BGP session 一毛钱没掉。我们拍了十六张不同角度的照片，最后靠一张倒影里映出的 UPS 状态屏确认了问题根源不在机房空调。这事儿跟容器无关，但每次看到有人写“以终为始”，我就想起那盏紫灯——它亮得毫无逻辑，可它就是发生了。

　　这事我也可能就运气好。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!