Kubernetes 中 Pod 节点相关问题

重启是否导致 Pod 名称发生变化

在 Kubernetes 中，Pod 的名称是否变化取决于它是如何创建的。

一、手动创建的 Pod（裸 Pod）

如果你是用 kubectl apply -f pod.yaml 创建的 裸 Pod，那么：

• Pod 重启（节点重启）后不会自动恢复；
• 如果节点崩溃了，Pod 会直接消失（不会自动迁移到其他节点）；
• 如果你自己重新创建 Pod，名称可能会改变，取决于你是否指定相同名称；
• Pod 是不可恢复的资源 —— 不推荐在生产中使用裸 Pod。

二、由控制器管理的 Pod（如 Deployment、StatefulSet）

1. Deployment / ReplicaSet 管理的 Pod
   • 如果节点重启、Pod 宕机，Deployment 会重建一个新的 Pod；
   • 新的 Pod 名称会变化，因为它们是动态生成的，比如：

     my-app-7cc7b569b6-lmwvh → my-app-7cc7b569b6-k9zdf
     

2. StatefulSet 管理的 Pod
   • StatefulSet 会保留 Pod 名称（有状态）；
   • 名称不会变，例如：

     my-db-0、my-db-1 这种格式；
     

   • 即使节点重启、Pod 被重新调度，名称还是 my-db-0。

总结

生产环境中使用频率

在现代生产环境中，使用最多的是 Deployment + ReplicaSet 管理的 Pod，原因如下：

✅ Deployment 是默认的无状态服务部署方式

• 适合大多数业务场景（如 Web 服务、API 服务、Worker 等）；
• 支持 滚动更新、回滚、扩缩容、健康检查；
• 简单易用，社区支持广泛；
• 与 HPA（水平自动扩展）无缝配合。

✅ StatefulSet 用于有状态服务，使用相对少一些

• 适用于数据库、Kafka、ZooKeeper 这类 有状态服务；
• 支持固定 Pod 名称和稳定持久化存储（如 my-app-0, my-app-1）；
• 支持有序部署、扩容、缩容；
• 配置和管理更复杂，不适合大规模无状态服务。

✅ DaemonSet 适合做守护进程

• 用于每个节点运行一个 Pod，比如日志采集（Fluentd）、监控 Agent（Prometheus Node Exporter）等；
• 用量少但场景明确。

❌ 裸 Pod 几乎不用于生产

• 不具备自愈能力；
• 无法自动调度、自动扩缩容；
• 容易丢失，不安全。

📊 实际使用比例（大致趋势）

所以，一般来说，Deployment 是绝大多数生产场景的首选方式。

Pod 中容器个数设计

在现代生产环境中，大多数情况下一个 Pod 只运行一个主要容器，但也存在运行多个容器的情况，具体看应用场景。

1. 单容器 Pod（最常见）

• 绝大多数业务服务（Web 服务器、API 服务、后台任务）都是一个 Pod 只运行一个主容器；
• 简单、易管理、资源隔离清晰；
• Kubernetes 的设计理念是“一组紧密相关的容器组成一个 Pod”，但大多数场景一个容器足够了。

2. 多容器 Pod（Sidecar 模式等）

• 多个容器共享一个 Pod 网络和存储，彼此协作；
• 常见场景包括：
  • Sidecar 容器：
    • 日志采集（如 Fluentd sidecar 跟主容器一起工作）；
    • 配置更新（如 Envoy 代理、Istio Sidecar）；
    • 监控 Agent；
    • 数据同步；
  • Adapter 容器：
    • 对主应用进行辅助处理，例如缓存、代理等。
• 多容器 Pod 让业务容器和辅助容器能紧密协同，且共享生命周期。

3. 总结

• 大部分生产环境的 Pod 是单容器的；
• 多容器 Pod 更多用于需要辅助功能（sidecar）或服务网格场景；
• 设计时建议尽量拆分单一职责容器，避免一个 Pod 里运行多个复杂业务容器。

容器异常导致 Pod 节点重启

在一个 Pod 里运行多个容器时，Pod 的生命周期是绑定在这些容器上的，所以：

• 只要 Pod 里任意一个容器崩溃或异常，整个 Pod 都会被认为“异常”；
• Kubernetes 会根据 Pod 的重启策略（restartPolicy）来决定是重启单个容器，还是整个 Pod 重启；
• 但实际上，Pod 里的容器共享同一个 Pod 生命周期和调度单元，当关键容器挂掉，通常会触发 Pod 重启；
• Pod 里的所有容器都会被杀死并重新启动，这意味着任何一个容器异常都会导致整个 Pod 重启。

举个例子：

• Pod 有两个容器：主业务容器 + sidecar 容器（比如日志采集）；
• 如果 sidecar 容器崩溃，Kubernetes 会重启整个 Pod，主业务容器也会被重启。

但是有几点补充：

1. RestartPolicy 影响重启行为
   • 一般都是 Always，即任意容器崩溃都会重启 Pod；
   • 也可以设置为 OnFailure 或 Never（但生产中很少用）。
2. 探针（Liveness/Readiness Probe）影响调度
   • 探针失败也会触发容器重启，从而触发 Pod 重启；
   • 设计时要保证辅助容器稳定，避免影响主容器。
3. 通过设计降低风险
   • Sidecar 容器应足够稳定；
   • 业务容器和辅助容器解耦，避免一个容器异常拖垮整个 Pod。