Pod处于CrashLoopBackOff状态时，K8s因PDB无法驱逐该如何处理？

临时调整PDB规则（推荐） #

当所有Pod均处于不可用状态时，临时修改PDB的minAvailable参数或暂时删除PDB，完成节点驱逐/版本升级后再恢复：

• 修改PDB：执行kubectl edit pdb <你的PDB名称>，将minAvailable的值改为0，保存退出后即可正常执行kubectl drain操作
• 删除PDB：执行kubectl delete pdb <你的PDB名称>，操作完成后重新创建原PDB配置

强制驱逐失败Pod #

直接强制删除处于CrashLoopBackOff状态的Pod，此时控制器会尝试在其他可用节点重建Pod，同时可完成当前节点的驱逐：

• 强制删除指定Pod：kubectl delete pod <Pod名称> --grace-period=0 --force
• 执行节点驱逐：kubectl drain <节点名称> --delete-emptydir-data

调整PDB策略（长期优化） #

将PDB的minAvailable改为maxUnavailable配置，更适配存在失败Pod的场景：

• 例如将PDB配置改为maxUnavailable: 1，表示最多允许1个Pod不可用（包括被驱逐或失败状态），这样即使部分Pod失败，节点驱逐操作仍可正常进行，同时保障服务可用时的稳定性

注意：调整PDB策略前需评估业务对可用性的实际需求，确保配置符合服务SLA要求

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