如何诊断Kubernetes中卡住的Deployment滚动更新？

让我们一步步拆解你遇到的问题，从你提供的信息来看，核心原因已经很明确了，我们把诊断和解决步骤理清楚：

1. 从事件日志抓核心问题 #

你贴的kubectl get events输出里，重复出现的这条警告就是关键：

No nodes are available that match all of the predicates: Insufficient cpu (1), Insufficient memory (2), MatchInterPodAffinity (1)

简单说就是：你的集群里没有任何一个节点能满足新WordPress Pod的调度要求，三个拦路虎：

• 1个节点CPU资源不足
• 2个节点内存资源不足
• 1个节点不符合你配置的Pod间亲和性规则

因为新Pod一直处于Pending状态（没法被调度到任何节点启动），Kubernetes的Deployment控制器不会终止旧Pod——它要确保始终有足够的可用副本提供服务，所以Rollout就卡在了2 out of 3 new replicas have been updated的状态。

2. 验证节点资源剩余情况 #

先确认集群节点的资源到底够不够，跑这两个命令：

• 查看节点详细资源分配：

kubectl describe nodes

每个节点的输出里，Allocatable是节点总可用资源，Allocated resources是已经被占用的资源，对比一下就能看到CPU和内存的剩余量是不是真的不足以容纳新Pod。

• 用更直观的方式看节点资源使用：

kubectl top nodes

这个命令能直接显示每个节点的CPU、内存使用率，一眼就能看出哪些节点资源紧张。

3. 检查Pod亲和性配置 #

事件里提到的MatchInterPodAffinity问题，你需要看看WordPress Deployment是不是配置了特殊的亲和/反亲和规则，比如要求和Redis、NFS Pod在同一个节点，或者不能和某些Pod共存：

kubectl get deployment wordpress -o yaml | grep -A 20 affinity

如果规则太严格，而集群里没有节点满足，那新Pod肯定没法调度。

4. 可行的解决思路 #

根据上面的诊断结果，你可以选适合自己的方案：

• 扩容集群节点：新增节点来补充CPU、内存资源，同时满足亲和性规则，这是最彻底的方案
• 降低Pod资源请求：如果WordPress的资源请求设得太高，编辑Deployment调低resources.requests.cpu和resources.requests.memory，让现有节点能装下新Pod：

  kubectl edit deployment wordpress
  

  找到spec.template.spec.containers下的resources部分修改即可
• 放宽亲和性规则：如果亲和性不是必须的，把规则改成偏好性（preferredDuringSchedulingIgnoredDuringExecution）或者直接删除，让Pod能调度到更多节点
• 临时缩容应急：如果着急恢复服务，先把副本数缩到当前能运行的数量（比如2个），先让Rollout完成，之后再处理资源问题：

  kubectl scale deployment wordpress --replicas=2
  

额外确认：查看ReplicaSet状态 #

你也可以检查新的ReplicaSet状态，确认调度失败的细节：

kubectl describe replicaset wordpress-f59c459fd

这里的输出会和事件日志对应，进一步验证我们的诊断。

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