运维解惑：生产环境中kubelet重启，Pod会受影响吗？

当你在生产环境敲下 systemctl restart kubelet 时，你是否会感到一阵紧张？会担心什么呢？

• 😨 业务容器会被杀掉吗？
• 😨 正在处理的用户请求会断开吗？
• 😨 流量会不会突然打不进来？

先给明确结论：
在 正常配置 + 常见容器运行时 (containerd/docker) 的环境下：
👉 Pod 进程不会死
👉 网络连接不会断

但，这是为什么呢？我们来深入剖析一下。

核心机制：理解 “包工头”理论

首先，我们需要纠正一个常见的认知误区：kubelet 并不直接运行容器。它的角色更像是一个“包工头”。

图：kubelet与容器运行时职责分工示意图

💡 核心洞察
Linux 容器的本质是独立的进程。除非其父进程 (如容器运行时shim) 发出终止信号，否则像 kubelet 这样的旁路管理组件退出，不会导致容器内的业务进程终止。

图解流量路径：网络为何不断？

可能你会疑惑：流量不是要经过 kubelet 吗？它挂了网络怎么会不断？

这是个误解！ 正常的业务流量（无论是通过 Service、Ingress 还是直接访问 Pod IP）完全不经过 kubelet。

真实的网络真相如下：

1. 建好了就不动：Pod 在创建时，CNI 网络插件就已经配置好了网络命名空间 (Network Namespace) 和路由规则。
2. 内核接管：TCP 连接的状态由 Linux 内核的 conntrack（连接跟踪）模块负责维护。
3. 最终结果：只要 Linux 内核本身没有崩溃，已经建立的网络连接就不会中断。

不可忽视的“真空期”代价

虽然业务容器和网络在短期内不受影响，但 kubelet 停止工作的那几十秒内，该节点对于集群来说处于一种 “失控”状态，会带来一系列风险：

• ⚠️ 监控致盲：节点的状态可能被标记为 NotReady（如果 kubelet 停止时间过长）。
• ⚠️ 探针失效：kubelet 负责执行的 Liveness（存活）和 Readiness（就绪）探针会停止工作。
  • 风险点：如果此时应用内部发生死锁，将没有人能自动重启它。
  • 风险点：如果应用负载过高，需要摘除流量，也将无法被及时踢出服务列表。
• ⚠️ 启动“起床气”：kubelet 在重启后的瞬间，有可能会误杀 Pod。
  • 原因：kubelet 刚启动就立刻执行探针检查，可能因为容器尚未完全准备就绪导致探针超时，从而判定 Liveness 失败并重启容器。

运维实操建议

了解原理后，我们可以更自信地操作：

✅ 可以安全执行的操作：

• 升级 kubelet 的版本。
• 修改 kubelet 的配置参数（例如资源驱逐阈值）。
• 执行短时间的重启（建议控制在 1 分钟以内）。

❌ 需要严格避免的操作：

• 不要 同时重启 kubelet 和 containerd/docker（这会直接终止容器运行时，导致所有容器被杀死！）。
• 不要 在 kubelet 停止期间手动删除 Pod（因为此时控制器无法同步状态，可能导致异常）。

下期预告
如果重启的不仅仅是 Worker 节点，而是 Master（控制平面）节点呢？其中又有哪些关键陷阱需要注意？欢迎在云栈社区继续探讨云原生运维的深层话题。