Kubernetes中无法删除CrashLoopBackOff状态Pod的问题求助

错误根源分析 #

从kubectl describe pod的日志可以明确：nginx-cache容器启动失败是因为CPU配额设置超出内核允许范围。错误日志中尝试写入cpu.cfs_quota_us的数值107374182400000过大，超过了系统的有效阈值，导致容器初始化失败。

分步解决方案 #

1. 停止异常Pod的持续创建 #

• 查看所有ReplicaSet，确认异常的RS：

  kubectl get rs
  

• 将异常ReplicaSet（示例中为deployment-5bd9ff7f9d）的副本数设为0，阻止它继续生成错误Pod：

  kubectl scale rs deployment-5bd9ff7f9d --replicas=0
  

• 删除已存在的异常Pod：

  kubectl delete pod <异常Pod的完整名称>
  

2. 修复Deployment的CPU资源配置 #

• 编辑Deployment的配置文件：

  kubectl edit deployment <你的Deployment名称>
  

• 定位到nginx-cache容器的resources.limits.cpu配置项，检查数值是否异常：

  示例错误配置（可能是误写了超大值）：

  resources:
    limits:
      cpu: "100000"  # 这个数值会被转换为100000*100000=10000000000微秒，远超系统上限
  

• 将CPU限制修改为合理值（比如2核或2000毫核）：

  resources:
    limits:
      cpu: "2"  # 或 "2000m"
    requests:
      cpu: "500m"  # 建议同时设置合理的请求值
  

• 保存并退出编辑器，Deployment会自动滚动更新，创建配置正确的Pod。

3. 验证修复效果 #

• 检查Pod状态，确认所有Pod都处于2/2 Running状态：

  kubectl get pods
  

• 查看ReplicaSet状态，确保异常RS的副本数为0，正常RS维持2个运行副本：

  kubectl get rs
  

额外说明 #

更新Deployment后出现3个副本的原因：旧ReplicaSet（deployment-ffbf89fcd）保留了2个运行副本，新ReplicaSet尝试创建2个副本但仅成功启动1个（另一个陷入CrashLoopBackOff），因此总副本数显示为3。修复配置后，旧RS会被Deployment自动清理（默认保留历史RS的数量由revisionHistoryLimit控制）。

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