如何通过优化Pod和Node的资源限制配置提高Kubernetes(k8s)集群的稳定性？

在Kubernetes集群稳定性优化中，Pod与Node资源限制的合理配置是核心实践。以下是具体经验与挑战：

1. 资源请求与限制的精确配置

   • 实践经验：通过压力测试与历史监控数据（如Prometheus指标）动态调整Pod的requests和limits。例如，Java应用需预留额外内存缓冲（如limit=request*1.2），避免OOMKilled。对于CPU密集型服务（如视频转码），设置limits略高于requests（如request=2核，limit=2.5核），防止突发流量导致节流。
   • QoS策略：优先使用Guaranteed类型（CPU/内存均设limits），确保关键服务在资源竞争时不被驱逐。

2. 节点资源预留与分配策略

   • 系统预留：通过kube-reserved和system-reserved为节点组件（如kubelet、容器运行时）预留资源（例如10%CPU+20%内存），避免DaemonSet耗尽资源导致节点故障。
   • 碎片优化：启用Topology Manager与CPU Manager，减少跨NUMA节点访问延迟。对于GPU节点，使用device-plugin实现显存隔离。

3. 动态弹性与监控

   • HPA调优：结合自定义指标（如队列堆积数）触发扩缩，调整--horizontal-pod-autoscaler-downscale-stabilization（默认5分钟）避免抖动。
   • VPA限制：仅对无状态服务启用，避免Pod重启导致数据丢失。

4. 挑战与解决方案

   • 资源预估偏差：某日志采集服务因未预估日志突增导致频繁OOM。最终通过LimitRange设置默认内存limit，并增加本地缓存兜底。
   • 节点碎片化：某集群因剩余资源“小块化”无法调度新Pod。引入descheduler重平衡Pod，同时调整调度器resourceBinPacking权重。
   • 多租户争抢：通过ResourceQuota限制命名空间资源总量，结合PriorityClass定义关键业务优先级，但需谨慎使用preemptionPolicy避免级联驱逐。

5. 稳定性兜底措施

   • 配置PodDisruptionBudget确保最小可用实例数。
   • 对关键Pod添加nodeAffinity，分散部署至不同故障域（如可用区、机架）。

最终需结合混沌测试（如模拟节点宕机）验证配置有效性，并建立资源水位基线（如节点CPU平均使用率≤70%）。

通过合理设置Pod的requests和limits，并确保Node资源预留足够，可避免资源竞争导致的节点过载。延伸知识点：Kubernetes的QoS（服务质量）等级分为Guaranteed、Burstable、BestEffort。Guaranteed要求所有容器均设置且requests=limits，此类Pod在资源不足时最后被终止；Burstable为至少一个容器设置requests但不满足Guaranteed条件，优先级次之；BestEffort未设置任何资源约束，最先被驱逐。合理配置可使关键服务获得更高稳定性，例如数据库Pod应设为Guaranteed，确保资源独占且避免突发故障。

合理设置Pod的CPU、内存requests和limits，别让应用饿死或撑爆；Node上预留系统资源，别全分给容器；用监控工具分析实际用量，定期调参数，避免资源争抢导致雪崩。Pod密度别太高，该扩节点别硬扛，kube-scheduler压力会小很多。