Kubernetes 性能优化实战:从集群调优到 Pod 级调参,我踩过的坑和总结的经验

说实话,大多数团队在上 Kubernetes 的头半年,关注的都是"能不能跑起来"。等业务量上来了,才发现响应变慢、Pod 频繁重启、节点资源吃满却有一半在空转——这时候才开始认真对待性能优化,但往往已经欠了一屁股技术债。\n\n我经历过不止一次这样的场景。有一次,一个电商团队在大促前两周找过来,集群 CPU 利用率常年在 70% 以上,但实际业务吞吐量远没到瓶颈。排查下来,问题出在 requests/limits 配置不合理、HPA 策略过于粗放、以及网络层的一个不起眼的 DNS 解析延迟上。\n\n这篇文章就是把这些年在 Kubernetes 性能优化上积累的实战经验做一次系统梳理。不讲空话,每一条建议都来自真实生产环境。\n\n## 先搞清楚瓶颈在哪,别上来就调参\n\n性能优化最忌讳的就是"凭感觉"。我见过有人一上来就把所有 Pod 的 CPU limits 翻倍,结果节点调度更不均衡,问题反而恶化了。\n\n正确的第一步永远是观测和定位。推荐一个基本的排查路径:\n\n1. 用 kubectl top nodes 和 kubectl top pods 看资源消耗的大盘\n2. 通过 Prometheus + Grafana 观察一段时间内的趋势,而不是某个瞬时值\n3. 重点关注几个指标:CPU throttling 比例、内存 OOMKill 次数、Pod 调度等待时间、网络延迟\n4. 用 kubectl describe node 检查 Allocatable 和已分配资源的差距\n\n坦白讲,很多性能问题根本不是 Kubernetes 本身的问题,而是应用层的问题被放大了。一个内存泄漏的 Java 应用,放在虚拟机上可能扛一周才出事,放在容器里可能几小时就被 OOMKill。所以优化的第一原则是:先确认问题出在哪一层。\n\n## Requests 和 Limits:90% 的团队都没配对\n\n这是 Kubernetes 性能优化中最基础、也是影响最大的一环。\n\n我的经验是,绝大多数团队的 requests 和 limits 配置都存在两个极端:要么完全没设,要么拍脑袋设了一个很大的值"保平安"。两种做法都会带来严重问题。\n\n不设 requests 的后果是调度器无法合理分配 Pod,可能把大量 Pod 堆到同一个节点上。而 limits 设得过高,会导致节点超卖严重,一旦多个 Pod 同时突发,就会互相争抢资源。\n\n这里有个实用的方法论:\n\n