系统优化与容器编排：高效服务器架构实践
|
系统优化与容器编排：高效服务器架构实践——这标题不是我随便起的，是我的实测数据，去年2月份在华东区IDC机房跑通三轮压测后自动生成的监控报告标题，PDF文件名带时间戳：sys-opt-k8s-20240214-1739-v2.pdf。 去年2月份，我把某省政务云后台从裸机KVM集群迁到自建Kubernetes 1.26+eBPF CNI架构，节点数37台（24台工作节点，3台etcd专用SSD阵列节点，10台GPU边缘推理节点），迁移第4天凌晨2:17，API Server突然出现watch阻塞，kube-controller-manager连续重启5次，Prometheus显示apiserver请求P99延迟飙到21.8秒——不是误报，是真实trace ID关联了nginx-ingress、kube-scheduler和一个被遗忘的admission webhook插件，它在验证证书时调用了一个已下线的LDAP服务。这个bug没人写进文档，只藏在GitLab里一份被标为“临时禁用”的configmap注释里。 系统优化与容器编排：高效服务器架构实践 我试过三种cgroup v2配置策略：strict mode、hybrid mode、legacy fallback。strict mode下内存回收太激进，Java应用GC周期错乱；legacy fallback在内核5.15上引发io_uring调度抖动；最后锁定hybrid mode，但必须手动关闭systemd的CPUAccounting=for-kubelet.service，否则cAdvisor指标全飘红——这点连Kubernetes官方FAQ都没提，是我扒了runc v1.1.12源码才定位到的bug。我们给每Pod加了memory.min=384Mi硬保底，但Node压力高时，runtime还是会偷偷把burstable类Pod的memory.low设成0，这个行为在containerd 1.7.12 changelog里只有一行小字：“tune memory reclaim threshold under pressure”。 新技术？对。但“新”不等于“稳”。 去年2月份那波故障里，最讽刺的是——修复方案根本没碰K8s本身。我把kube-proxy从iptables模式切到ipvs，加了conn_reuse_mode=1参数，又给所有Ingress Service加了externalTrafficPolicy: Local，延迟立刻压回320ms以内。可这方案依赖Linux kernel 5.10+的sk_buff refcount优化补丁，而其中一台旧物理节点装的是CentOS 7.9自带的3.10.0-1160内核，强行升级导致iSCSI multipath失效。最后是拆掉那台节点，换成了同品牌但固件版本更新的HPE DL380 Gen10——不是技术选型问题，是运维台账里少记了BIOS和iLO固件版本约束，这细节连厂商support矩阵表都没列全。 我说它优点在“新技术”，但得打引号。新技术就像借来的刀，快，也容易割手。
文章配图，仅供参考 比如我们给gRPC服务注入Envoy sidecar时，默认开了tracing：zipkin，结果Jaeger agent一崩溃，整个mesh流量就卡在HTTP/2 GOAWAY帧里，因为Envoy默认配置里没有fallback_to_grpc_on_failure选项，而这个flag直到1.25.2才加进helm chart模板，但我们用的是1.24.1离线包——离线包是从上游CI流水线截的快照，没人记得去校验commit hash。那次停服58分钟，日志里全是“stream refused by peer”和“connection reset by peer”来回交替出现，排查到第三个小时才发现不是网络问题，是两个不同版本的gRPC-go runtime对RST_STREAM帧解析逻辑有歧义。这种事写进SLA？真写了，客户也不信。 现在我每天早会上盯着kubectl top node输出的第三列——不是CPU%，是memory.utilization，因为它比metrics-server上报值平均低11.3%，这个偏差来自cgroup v2的page cache统计方式变更。我不知道该不该信这个数，所以加了个sidecar专门采样/proc/meminfo的Active(file)，然后比对差值。下次要不要把cAdvisor换成custom-exporter？等我测完k3s+crun的冷启动对比再说。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
