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

1. 设置合理的资源请求（Requests）和限制（Limits）：

   • 为每个Pod的容器定义CPU和内存的requests和limits，避免资源超卖。例如，设置requests为应用基线需求，limits为峰值容忍值。
   • 通过kubectl top pod/node监控实际使用情况，调整配置。

2. 使用LimitRange和ResourceQuota：

   • 通过LimitRange为命名空间设置默认资源限制，避免未定义资源配置的Pod过度占用资源。
   • 通过ResourceQuota限制命名空间总资源用量，防止单个应用耗尽节点资源。

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

   • 在Node上预留资源（通过kube-reserved、system-reserved），确保K8s系统组件和OS稳定运行。
   • 配置节点资源分配比例，避免单节点负载过高（如通过kube-scheduler的均衡策略）。

4. 优化调度策略：

   • 使用节点亲和性（Node Affinity）或反亲和性（Anti-Affinity），分散高负载Pod到不同节点。
   • 配置Pod优先级（PriorityClass），确保关键服务优先调度。

5. 监控与自动扩缩容：

   • 集成Prometheus和Grafana监控资源使用率，识别瓶颈。
   • 配置HPA（Horizontal Pod Autoscaler）基于CPU/内存指标自动扩缩Pod副本。
   • 结合Cluster Autoscaler动态调整节点数量。

6. 配置驱逐（Eviction）策略：

   • 设置eviction-hard参数（如内存不足阈值），在节点压力大时主动驱逐低优先级Pod。
   • 通过PodDisruptionBudget保障关键服务的最小可用实例数。

7. 定期审查与调优：

   • 使用kube-state-metrics分析资源分配与实际使用差异。
   • 定期清理僵尸Pod，优化冗余资源配置。

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