为什么 `kubectl patch` 关闭探针不重启 Pod，重新开启却重启？

揭秘 Kubernetes 探针机制与 Pod 不可变性的博弈

在 Kubernetes 运维中，一个常见现象引发困惑：关闭探针（如 LivenessProbe）时 Pod 不会重启，但重新启用后却可能触发重启。这看似矛盾的行为，实则是 Kubernetes Pod 不可变性原则与有限原地修改能力共同作用的结果。本文将从原理层拆解其逻辑，并关联 Kubernetes 的原地升级特性。

---

一、Pod 的不可变性：一切行为的基石

Kubernetes 严格遵循 “Pod 运行时实例不可变” 原则：

1. 核心限制：
   • Pod 创建后，绝大多数字段（如容器名称、镜像、端口、卷挂载）不可直接修改。
   • 唯一允许原地修改的字段仅有：
     • spec.containers[*].image（容器镜像）
     • spec.initContainers[*].image（初始化容器镜像）
     • spec.activeDeadlineSeconds（任务超时时间）
     • spec.tolerations（污点容忍度，仅允许追加）。
2. 设计目的：
   • 确保状态一致性：避免运行时修改导致不可预测行为。
   • 简化调度逻辑：重建 Pod 可触发完整的调度、网络分配、存储挂载流程。

关键结论：

探针字段（如 livenessProbe）不属于允许原地修改的字段列表。但为何 kubectl patch 能修改它？

答案在于：kubectl patch 本质是向 API Server 提交合并请求，而 API Server 对探针字段的更新校验较为宽松（仅校验格式，不禁止更新）。

---

二、探针的关闭为何不重启？无事件+无状态变更

当执行 kubectl patch 移除探针时：

kubectl patch pod/myapp --type='json' -p='[{"op":"remove", "path":"/spec/containers/0/livenessProbe"}]'

底层逻辑：

1. 无状态变化：
   • 探针被删除后，kubelet 停止对该容器的健康检查，但容器进程未被干预。
2. 无失败事件：
   • Kubernetes 仅在探针连续失败达到阈值时触发重启。探针消失后，无失败信号上报。
3. 符合不可变性延伸原则：
   • 此操作未触及容器运行实例（如镜像、资源），属于“无害更新”，kubelet 无需重建容器。

类比原地升级：

删除探针类似“移除监控”，而 Kubernetes 支持原地升级容器镜像（如更新镜像触发容器重建，但不重建 Pod）。二者均利用 kubelet 的容器级管理能力，避免整个 Pod 重建。

---

三、重新启用探针为何重启？状态冲突+不可变性边界

重新启用探针时，重启的根源是状态冲突：

kubectl patch pod/myapp --type='json' -p='[{"op":"add", "path":"/spec/containers/0/livenessProbe", "value": {...}}]'

触发重启的两种场景：

1. 当前状态不满足探针条件（最常见）：
   • 若容器内应用已崩溃（如 OOM），探针首次检测即失败 → 触发重启策略。
   • 例：Tomcat 进程退出后启用探针，HTTP 检查 /index.jsp 失败 → 容器重启。
2. 参数不合理导致持续失败：
   • initialDelaySeconds（初始延迟）过短：应用未启动完成即开始检测 → 失败次数超阈值 → 重启。
   • failureThreshold（失败阈值）过小：短暂抖动被判定为永久失败。

️ 与不可变性的关联：

探针重新启用属于运行时配置变更。根据不可变性原则，若新配置要求状态重置（如应用需重新初始化），则重建容器是唯一可靠途径——这与原地升级镜像需重建容器的逻辑一致。

---

四、扩展：Kubernetes 的“有限原地修改”进化

近年来，Kubernetes 正逐步突破不可变性限制，支持关键字段的原地修改：

特性	支持版本	修改字段	是否重启	原理
原地升级镜像	原生支持	spec.containers[*].image	仅重建目标容器	kubelet 对比容器 hash 变化，重建单个容器
原地资源扩缩容	v1.33+ (Beta)	spec.containers[*].resources	通常无需重启	kubelet 动态调整 cgroup 参数，通过 /resize 子资源协调状态
探针修改	原生支持	livenessProbe 等	可能触发重启	依赖探针检测结果，非原子更新

未来趋势：

原地资源调整（v1.33 Beta）标志着 Kubernetes 向状态化应用友好性迈进。未来可能扩展至环境变量、端口等字段，但需解决状态一致性难题。

---

五、最佳实践：规避重启风险的实操建议

1. 启用探针前预检容器状态：

   kubectl logs <pod>          # 确认应用日志无异常
   kubectl describe pod <pod>  # 检查容器状态（Ready/Running）
   

2. 配置探针参数时预留缓冲：
   • 首次启用时调高 failureThreshold（失败阈值）和 initialDelaySeconds（初始延迟）。
   • 对慢启动应用使用 StartupProbe 隔离存活检测。
3. 优先使用声明式更新：
   • 通过 Deployment/StatefulSet 更新 Pod 模板，让控制器管理重建流程（而非直接 patch Pod）。
4. 善用原地升级特性：
   • 修改镜像时直接更新 image 字段，避免手动重建 Pod；
   • 资源调优使用 kubectl edit pod --subresource resize（v1.33+）。

---

总结：矛盾背后的设计哲学

操作	是否重启 Pod	根本原因
关闭探针	否	无状态变更 + 无失败事件 → 符合不可变性延伸逻辑
重新启用探针	是	新配置与当前状态冲突 → 触发健康检查机制 → 按策略重建容器（不可变性的妥协）

Kubernetes 通过 “有限原地修改” 在不可变性与运维灵活性间寻求平衡。理解这一底层逻辑，方能避免误操作，精准掌控容器生命周期。