Kubernetes节点驱逐时如何实现先扩容Pod再缩容？

a) 是否遗漏了相关配置？ #

并没有遗漏——Kubernetes的计划内节点驱逐机制本身就不支持自动触发Pod扩容。PodDisruptionBudget（PDB）的作用很明确：只限制驱逐过程中不可用Pod的数量，定义副本数的最低容忍下限（比如确保至少N个Pod在线），完全不涉及任何扩容逻辑。

当你执行kubectl drain这类计划内驱逐操作时，系统只会尝试把目标节点上的Pod调度到其他已有空闲资源的节点上，只有满足PDB要求且有可用节点资源时，才会删除节点上的Pod；如果没有足够资源，驱逐会直接卡住，直到有资源释放或者你手动去调整副本数。

b) 为什么应用升级能用先扩容再缩容的逻辑，计划内驱逐却不行？ #

这是因为两者的设计目标和执行逻辑完全是两回事：

• 应用升级（RollingUpdate）：核心是在不中断服务的前提下完成版本更新，maxSurge和maxUnavailable是Deployment/StatefulSet这类控制器的升级策略参数。这类控制器本身就有主动管理副本数量的能力——它会按照策略先创建新Pod，等新Pod就绪后再销毁旧Pod，整个过程是控制器主动驱动的。
• 计划内节点驱逐：核心是安全清空节点（比如做维护、下线节点），驱逐操作本身只是触发Pod的迁移，不负责管控应用的副本数。副本数的管理是Deployment/StatefulSet的职责，驱逐过程中只会尝试调度现有Pod到其他节点，不会主动去扩容副本。

说白了，升级是控制器主动调整副本完成版本替换，驱逐只是被动迁移现有Pod，两者的职责划分很清晰，驱逐机制从设计上就没考虑主动扩容这件事。

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