站长自说自话？容器运维视角看评论客观性

　　“站长自说自话？容器运维视角看评论客观性”——这标题是我去年12月份在青云QingCloud容器集群巡检日志里随手记下的批注，当时正对着37台Node节点上飘红的metrics-server Pod发呆，Prometheus拉取失败率突然飙升到41.6%，而官网社区帖子里那位站长却连发三帖称“稳定运行超90天，零告警”。

　　我信了前两帖。直到第三帖底下冒出个ID叫@k8s-sysctl的用户，贴出一段curl -k https://metrics-server.kube-system.svc.cluster.local:443/healthz 的返回体——HTTP/2 503 Service Unavailable，带完整Timestamp和Pod UID：metrics-server-7b8f9d4c6b-mxg9q，UID=5a2e1b8f-8c4d-4b1a-9f0e-331d6b7c0a21。我立刻ssh进对应节点，发现kubelet日志里埋着一行被忽略的Warning：“failed to sync pod status: context deadline exceeded (Client.Timeout exceeded while awaiting headers)”，时间戳精准吻合——原来metrics-server早挂了47分钟，但站长用的监控看板只刷status指标，没查livenessProbe实际响应。

　　新技术。

　　去年12月份那个周末，我在阿里云ACK 1.24.6集群里复现了这个现象：给metrics-server Deployment加了个sidecar容器，专门抓它对kube-apiserver的TLS握手耗时——结果发现83%的失败请求卡在client_hello→server_hello之间，平均延迟2.8秒。根本不是服务本身崩了，是某次内核升级后iptables规则链里多了一条--jump KUBE-FIREWALL，把metrics-server的service IP误标为EXTERNAL，触发conntrack状态同步阻塞。没人提这事，站长帖子里的截图连kubectl get nodes -o wide都截得干干净净，完全不展示AGE列那刺眼的14d——那是节点上次重启时间，也是漏洞引入时间。

　　真有人试过改kube-proxy的proxy-mode为ipvs再开strict ARP吗？

　　我们团队去年底用Argo CD灰度发布一个日志聚合组件，上线第3小时，ELK索引写入延迟从120ms飙到2.3s，但Kibana仪表盘上“log ingestion success rate”还挂着99.97%——因为指标统计只采样了非error级别的bulk response。我翻了fluent-bit的plugin log，发现它默认丢弃了含“too_many_requests”的ES返回体，而ES恰恰因为索引分片数配错触发了写入限流。站长们不会写这种日志细节，他们截图永远选Dashboard右上角那个最大最亮的绿色数字。我的实测数据：“站长自说自话？容器运维视角看评论客观性”，就诞生在那个凌晨三点，我手动curl了127次fluent-bit的healthz端口，发现probe成功率稳定在98.2%——但它健康检查根本不管后端ES是不是在喷503。

　　这标题太直白。

　　我不信任何没附kubectl describe pod输出的稳定性声明。去年12月份，在客户现场排查一个“偶发502”的Ingress问题时，站长提供的排障记录里写着“已验证upstream健康”，但他describe出来的EndpointSlice只有2个active endpoints，而实际Service selector匹配了7个Pod——剩下5个被污点taint.node.kubernetes.io/unreachable锁死了，但kubectl get nodes显示status还是Ready，因为node-status-update频率被调到了30秒，而污点注入发生在两次心跳间隙。我用journalctl -u kubelet -S '2023-12-17 02:18:00' | grep -A3 "taint" 找到原始日志，时间戳比站长声称的“问题发生前已检查节点”早11分23秒。他截图的kubectl get nodes表格甚至没展开AGE列，那列里明晃晃印着13h21m。现在想想，他可能真的没看。或者看了，但觉得Age值跟502没关系——可运维人知道，超过10分钟没心跳的节点，etcd里lease对象早过期了，只是API server缓存还没刷新而已。这标题的优点在“新技术”，但新在哪儿？新在用eBPF抓svc转发路径时，发现某个站长宣称“零丢包”的Ingress Controller，其实每万次连接有3.7次sk_buff被kfree_skb直接释放，原因是net.core.somaxconn设成了1024，而他压测工具用的是keepalive=200的长连接池……要不要今晚就去客户环境跑一遍tcpretrans追踪？

文章配图，仅供参考

　　先抓个tcpdump再说。

（编辑：站长网）

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