helmfile apply触发Deployment重建致停机问题排查求助

针对配置了RollingUpdate策略（maxUnavailable:0、maxSurge:1）但仍出现旧Pod全量终止后再启动新Pod的问题，以下是核心排查方向和解决思路：

1. Pod模板的Immutable字段变更触发全量重建 #

Kubernetes判定Deployment是否执行滚动更新的核心依据是Pod模板的哈希值，如果模板的metadata.labels或metadata.annotations（尤其是Deployment selector依赖的标签）发生变更，Kubernetes会认为需要创建全新的Pod集合，直接销毁所有旧Pod再启动新Pod，完全绕过RollingUpdate策略。

• 排查方法：执行kubectl get deployment <deploy-name> -o yaml，对比更新前后的spec.template.metadata部分，确认没有非预期的标签/注解变更。

2. Helmfile/Helm的强制重建配置 #

如果CD流水线或Helmfile配置了强制更新逻辑，会直接触发全量Pod重建：

• 检查Helmfile的releases配置块中是否存在force: true；
• 确认CD执行的helm upgrade命令是否带有--force参数。

这两个配置都会强制Kubernetes替换所有资源，忽略滚动更新策略。

3. 探针配置的隐性问题 #

虽然配置了探针，但以下情况可能导致滚动更新逻辑异常：

• 就绪探针失败阈值过短：旧Pod收到终止信号后，若就绪探针在terminationGracePeriodSeconds内快速失败，Kubernetes可能提前发送SIGKILL，但这种情况一般不会导致全量Pod同时终止；
• 探针路径/端口配置错误：若旧Pod的存活探针突然失效，导致所有旧Pod被标记为不健康，可能打破maxUnavailable:0的约束。可通过kubectl describe pod <old-pod>查看终止时的事件日志，确认是否因探针问题触发终止。

4. PodDisruptionBudget（PDB）未生效 #

若PDB的selector与Deployment的Pod标签不匹配，PDB无法发挥作用，无法阻止全量Pod终止：

• 执行kubectl get pdb <pdb-name> -o yaml查看selector；
• 用kubectl get pods -l <pdb-selector>验证是否能匹配到目标Deployment的Pod。

5. HPA的干扰 #

虽然设置了固定副本数，但如果HPA的配置存在问题（比如自定义指标异常、selector不匹配），可能导致更新过程中副本数临时波动，间接影响滚动更新：

• 临时删除HPA，手动执行helmfile apply，观察是否仍出现全量重建；
• 检查HPA的scaleTargetRef是否正确指向目标Deployment。

快速排查步骤 #

1. 对比Deployment更新前后的Pod模板标签：kubectl get deployment <deploy-name> -o jsonpath='{.spec.template.metadata.labels}'，确认无变更；
2. 检查Helmfile和CD命令是否有强制更新配置；
3. 查看旧Pod终止时的事件日志：kubectl describe pod <old-pod-name>，定位终止原因；
4. 验证PDB的selector有效性；
5. 临时移除HPA后重新部署，排除干扰。

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