为什么 `kubectl patch` 关闭探针不重启 Pod，重新开启却重启？
揭秘 Kubernetes 探针机制与 Pod 不可变性的博弈在 Kubernetes 运维中，一个常见现象引发困惑：关闭探针（如 LivenessProbe）时 Pod 不会重启，但重新启用后却触发重启。这看似矛盾的行为，实则是 Kubernetes Pod 不可变性原则与有限原地修改能力共同作用的结果。本文将从原理层拆解其逻辑，并关联 Kubernetes 的原地升级特性。
一、Pod 的不可变性：一切行为的基石
Kubernetes 严格遵循 “Pod 运行时实例不可变” 原则：
[*]核心限制：
[*]Pod 创建后，绝大多数字段（如容器名称、镜像、端口、卷挂载）不可直接修改。
[*]唯一允许原地修改的字段仅有：
[*]spec.containers
[*].image（容器镜像）
[*]spec.initContainers
[*].image（初始化容器镜像）
[*]spec.activeDeadlineSeconds（任务超时时间）
[*]spec.tolerations（污点容忍度，仅允许追加）。
[*]设计目的：
[*]确保状态一致性：避免运行时修改导致不可预测行为。
[*]简化调度逻辑：重建 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"}]'底层逻辑：
[*]无状态变化：
[*]探针被删除后，kubelet 停止对该容器的健康检查，但容器进程未被干预。
[*]无失败事件：
[*]Kubernetes 仅在探针连续失败达到阈值时触发重启。探针消失后，无失败信号上报。
[*]符合不可变性延伸原则：
[*]此操作未触及容器运行实例（如镜像、资源），属于“无害更新”，kubelet 无需重建容器。
<blockquote>
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]