容器编排驱动系统优化，提升服务器效能

　　凌晨告警。

文章配图，仅供参考

　　三点半，手机在裤兜里震第三回，不是嗡嗡那种，是“嗒、嗒、嗒”三下短促的钝响——跟去年机房换新空调后报警喇叭的节奏一模一样。我摸出来看了一眼，K8s Cluster Health: DEGRADED，下面跟着三百七十二条告警，其中二百六十一条来自同一个 Deployment 的 readiness probe 失败。DBA 老陈已经在线上发了个表情包：一只穿西装的浣熊叼着U盘在跑，配字“撤退路线已失效”。我没回。先去摸了摸机柜侧面——还是凉的，冷风从底部格栅往上涌，吹得脚踝发紧，但不知道是不是错觉，那风里带了点铁锈味。

　　我原以为是节点亲和性配置漏了一行 label，结果翻到 yaml 第四层嵌套时发现，真正出问题的是那个被标记为“可驱逐”的旧 Node 上还挂着两个遗留的 DaemonSet，其中一个早该随 v2.4.1 下线，但没人动——因为它的 ConfigMap 里混着一条数据库连接串，谁改谁背锅，三年了，就那么挂着。我敢打包票，它最后一次健康检查成功是在去年二月份，那天我正蹲在测试环境里核对一笔退款状态变更的幂等性，而它在生产集群里悄悄睡死了十七小时二十三分钟。

　　然后就是 SSH 连上去。先 ssh node-07 ——密码输错一次，小写L和数字1又搞混了；再 ssh node-07 ——连上了，但 prompt 卡住半秒，光标不动，像在听什么；敲个 df -h，回显出来之前，我盯着终端右下角时间跳了一次：03:37:09 → 03:37:11。不是系统时间错了，是那个终端延迟了两秒才把 stdout 吐完。这时候对面工位后端老赵忽然把拖鞋踢掉，换了一双灰蓝拼色的，鞋底磨得发亮，趿拉趿拉往茶水间走，没带杯子，空手去的。

　　优胜劣汰？呵。这词听着体面，实际干的活儿是：把跑歪了三年的 DaemonSet 突然塞进驱逐队列，让 kube-scheduler 自己发现“哎哟这个 Pod 居然还在占着 CPU 不干活”，然后一脚踹进 Pending 状态。它不是被优化掉的，是被晾在那儿晒干的——就像我们上次做灰度发布时，线上流量切过去一半，另一半卡在 istio-ingressgateway 里等一个 timeout，timeout 到了，才“哦”一声，放行或拒掉。这种优化不靠算力，靠忍耐阈值。老板上周拍桌子说“编排驱动”，我差点接嘴：“驱动个锤子，是靠故障在后面拿鞭子抽。”

　　咖啡洒在工牌上了。深褐色一圈，刚好盖住我的工号尾数“861”，现在只看得清“86·”，底下是湿漉漉的咖啡渍晕开。当时我正把笔记本合上，左手抬杯右手推椅子，杯沿撞到工牌边缘，噗一下，液体顺着塑料斜面流下去，滴在键盘托架上，积成一小洼。没人说话。空调嗡的一声，音调略高，像是刚换了压缩机轴承，还没磨合好。

　　说到这儿其实该讲讲节点复用率。但我不想算——这个我说不准。只知道调度器现在更愿意把临时 Job 扔进那些“内存使用率低于 45% 且有 GPU 可挂载”的节点，而它们全是我上个月亲手给打了 cordon 标签的“养老节点”。标签打完第二天，DBA 老陈来问我：“你那个 node-13，上面的 etcd 数据快照还能读吗？”我没答，反问他：“你们备份策略改了没？”他摆摆手，手机响了一声没接，屏幕亮起又暗下去，微信头像缩略图是只柴犬，叼着一张纸，纸上印着“DDL 已锁定”。

　　碎片化这事，真不是编排系统的问题，是我们人自己碎的。上周我查一条订单履约状态流转异常，追日志追到第七个服务，发现源头是支付回调里少了一个幂等 key 的校验逻辑，但那个服务的负责人——实习生小王，上月刚转正，昨天调休申请被驳回，理由是“Q3 压测周期人力缺口”，他在钉钉群回了个“收到”，后面跟了三个句号。我看着那三个点，忽然想到，我们写的每个 liveness probe 都在学他：活没死，但也不说话；状态是 up，可里面全是空的。

　　后来我改了 probe 的 failureThreshold 从 3 改成 1，删了 initContainer 里的 curl -f 检查依赖服务那一步，把它砍掉，直接让容器启动就 ready。上线之后，那个老 DaemonSet 果然立刻被驱逐，节点负载曲线像被刀劈开似的，唰一下掉下去一块。但当天晚上，订单创建成功率跌了 0.3%，不是报错，是超时。后端老赵说是 DB 连接池被挤爆了，因为所有新 Pod 启动太快，连上来的时候都在同一秒。我没吭声。我知道问题在哪：ready 就 ready，可 readiness 不等于 readiness probe 返回 true 就真 ready。它只是“不拒绝流量”，不代表它准备好处理流量了。

　　所以现在我每天早上九点零七分准时点开 Grafana，看那个叫 “node_pods_evicted_by_scheduling_pressure” 的指标，只看。不点展开，不设告警，就让它浮在那里。它最近三天涨得有点快，但幅度不大，可能是节点老化导致 cadvisor 上报延迟，也可能是 scheduler 里某个参数被谁悄悄调松了。我不打算深挖。反正下周我要交功能回归测试报告，重点覆盖支付链路的状态机切换，至于底层 pod 是怎么死的、怎么活的、活了又怎么被系统礼貌地请出去的——随它去吧。要真揪，怕是得把 kube-scheduler 的调度队列快照扒出来，再比对 APIServer 的 etcd rev。我懒得开那个权限工单。上回为了调个 debug 日志级别，填了四张表，最后一张写着“申请人需承担因调试导致的 SLA 偏离风险”。

　　对了，值班表刚更新了。我名字后面多了一栏备注：【容器健康巡检频次 ×2】。没说为什么，也没说起止时间。我就当它是个提醒——提醒我下次看见 readiness probe 成功返回时，别急着关 terminal，先伸手摸摸机柜侧板，看风是不是还凉着。

（编辑：站长网）

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