如何预防Kubernetes资源不足引发的集群故障？

问题分析 #

这是Kubernetes典型的资源饿死场景：节点CPU/内存耗尽时，Pod启动失败，但Deployment/StatefulSet等控制器会按重启策略持续重建Pod，无效Pod堆积进一步耗尽API Server、调度器等集群核心组件资源，最终导致集群彻底不可用。从你提供的Pod列表能看到大量ContainerStatusUnknown、Pending状态实例，以及重启次数极高的Pod，完全匹配该场景。

一、快速恢复集群（无需删除所有资源） #

1. 清理无效Pod释放资源 #

先手动删除长期无法启动的无效Pod，快速缓解资源压力：

# 删除所有ContainerStatusUnknown状态的Pod
kubectl delete pod --field-selector=status.phase=Unknown
# 删除所有Pending状态且超过10分钟的Pod
kubectl delete pod --field-selector=status.phase=Pending --field-selector=metadata.creationTimestamp<=$(date -d '-10min' --iso-8601=seconds)

2. 临时缩容失控控制器 #

对持续重建Pod的Deployment/StatefulSet临时缩容，阻断无效重建循环：

kubectl scale deployment aa344-detect --replicas=0
kubectl scale deployment bb756-detect --replicas=0

3. 释放节点资源 #

登录节点用top或kubectl top node查看资源占用最高的进程，手动清理非关键容器/进程；若有备用节点，加入集群后将Pod调度至新节点。

4. 逐步恢复应用 #

节点资源释放后，逐步将缩容的控制器恢复至正常副本数，验证Pod能否正常启动。

二、预防此类问题的核心配置 #

1. 强制配置Pod资源请求与限制 #

给所有Pod声明CPU/内存的requests和limits，让调度器基于资源请求选择节点，同时限制Pod最大资源占用：

resources:
  requests:
    cpu: "100m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

• requests：Pod运行所需最小资源，用于调度节点选择；
• limits：Pod可使用的最大资源，超量会触发OOMKilled或CPU限流。

2. 配置HPA的资源阈值与副本上限 #

若使用HPA自动扩缩容，需设置资源使用率阈值和最大副本数，避免无限制扩容耗尽资源：

kubectl autoscale deployment aa344-detect --min=1 --max=5 --cpu-percent=70

3. 启用集群级资源管控 #

• ResourceQuota：限制单个命名空间的总资源占用，防止单命名空间耗尽集群资源：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
spec:
  hard:
    pods: "20"
    requests.cpu: "2"
    requests.memory: "4Gi"
    limits.cpu: "4"
    limits.memory: "8Gi"

• LimitRange：给命名空间内未配置资源的Pod设置默认请求与限制，避免无约束占用资源：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limit-range
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "256Mi"
    type: Container

4. 调整Pod重启与控制器回退策略 #

• 对非核心应用，将Pod的restartPolicy设为OnFailure，避免容器启动失败时无限重启；
• 给Deployment配置回退策略，新版本Pod启动失败时自动回退至可用版本：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aa344-detect
spec:
  revisionHistoryLimit: 5
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate

内容的提问来源于stack exchange，提问作者noname7619