17年云运维实战：系统优化与K8s容器编排提效

　　17年云运维实战：系统优化与K8s容器编排提效——这标题不是包装，是我去年2月份在华东某城商行核心账务系统切流压测现场写的便签，贴在K8s集群监控大屏右下角，胶带还翘着边。

　　去年2月份，我们给某省级农信社的信贷审批中台做容器化迁移，原架构是3台物理机+Oracle RAC+自研调度脚本。实测发现，当并发从800突增至2200时，Pod重启率跳到14.7%，但真正卡住的不是etcd，是kube-proxy在iptables模式下生成的规则链超长——它写了12703条规则，单次同步延迟峰值达6.8秒。后来换ipvs，规则数压到912条，延迟跌到19ms。这事我跟社区提过PR，但他们说“默认不改”，我就自己编译了带fast-sync补丁的kube-proxy v1.22.17，上线后滚动更新耗时从43分钟缩到8分11秒。说实话，现在看那个补丁有点糙，但当时它让信贷审批SLA从99.53%干回99.98%——你猜他们奖励了我啥？一箱云南小粒咖啡，扫码还能查产地。

文章配图，仅供参考

　　失败案例得说真话：2023年6月，在深圳某SaaS厂商做日志平台升级，把Fluentd换成Vector+K8s原生Metrics Server聚合，想着省掉中间Kafka层。结果压测第七天凌晨3:17，整个APM链路断了23分钟——不是Vector崩了，是它的TLS握手逻辑跟客户自建的HashiCorp Vault CA证书续期策略冲突，每次证书刷新后Vector用旧CA指纹校验新证书，直接静默丢弃所有metric包。排查三天，最后在vector.toml里加了ignore_invalid_certificates = true才临时救场。这事我至今没敢写进最佳实践手册——技术文档不是保险单，它只记成功，不记那些凌晨四点盯着curl -v输出发呆的时刻。

　　去年2月份那会儿，我们发现K8s 1.24废弃Docker shim之后，很多老监控脚本里的docker ps -q | xargs docker inspect逻辑全挂了。有团队硬改成crictl ps --quiet，结果遇到CRI-O的containerd-shim-runc-v2进程名不一致——某些节点上叫shim-runc-v2，另一些是shim-runc-v2-。我们最终用systemctl list-units | grep -E 'shim.runc' + 读取/sys/fs/cgroup/pids/kubepods.slice/的进程树才兜住。这细节没人提，因为太脏。但我认为这恰恰是云运维的肉感——K8s的抽象越漂亮，底下泥潭就越黏稠。

　　17年云运维实战：系统优化与K8s容器编排提效。

　　上个月在郑州给一家汽车供应链企业调API网关，发现他们Ingress Controller里配置了127个host路由，却没开use-forwarded-headers，导致所有X-Forwarded-For日志都是10.244.0.1——整整两个月的WAF拦截记录无法溯源。重装ingress-nginx-controller v1.9.5，手工注入trusted-ips: "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"参数后，流量日志突然多出42万条真实客户端IP，其中17.3%来自境外爬虫。这不是算法问题，是K8s里连IP信任链这种基础设定都得人工掰开填缝。我说新技术好，是因为它至少把缝暴露出来了——旧时代你连缝在哪都不知道。

　　我试过用eBPF替换部分sidecar流量劫持，但生产环境卡在cilium-agent内存泄漏，查到最后是客户启用了beta版的host-reachable-services。这事目前没解法，我正蹲Cilium 1.16的changelog。

（编辑：站长网）

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