Pod、Deployment、Service 到底怎么协作

很多人学 Kubernetes 时，会把 Pod、Deployment、Service 分成三个独立章节来记。
结果真正上线一个服务时，脑子里却连不起来：

• Pod 是谁创建的
• Deployment 为什么不直接对外暴露
• Service 为什么不关心某个 Pod 的 IP

理解这三个对象的关系，等于理解了 K8s 最核心的一条应用发布链路。

先说结论

• Pod 承载运行中的容器实例，是最小调度单元
• Deployment 负责声明“我要多少个 Pod、如何滚动更新、异常时怎么自愈”
• Service 负责给一组符合标签的 Pod 提供稳定访问入口
• 这三者串起来，才构成了一个可发布、可伸缩、可替换的应用单元

先从一个上线场景理解

假设你要把一个订单服务部署到 Kubernetes：

• 需要运行 3 个副本
• Pod 崩了要自动拉起
• 发布新版本时要滚动替换
• 其他服务要用稳定地址访问它

这时三类对象分别承担不同职责：

• Pod: 真正跑服务进程
• Deployment: 管理这些 Pod 的生命周期
• Service: 给这些 Pod 提供稳定访问方式

Pod 是“运行实体”

Pod 可以理解成 K8s 调度和网络的最小单位。
通常一个 Pod 里会有一个主业务容器，也可能带一个 sidecar。

Pod 负责的是：

• 容器启动
• IP 分配
• 卷挂载
• 探针检查
• 资源限制生效

但 Pod 有一个重要特点：

Pod 是易失的。

它挂了可以重建，重建后：

• Pod 名称可能变化
• IP 通常变化
• 运行实例不是“原来那一个”

所以你不能把 Pod 当成长期稳定实体。

Deployment 是“声明式管理者”

如果你直接创建 Pod，会很快遇到问题：

• Pod 挂了谁重建
• 要扩容到 5 个副本怎么办
• 发布新版本怎么平滑替换

Deployment 的作用就是回答这些问题。

它通常通过 ReplicaSet 间接管理 Pod，核心能力包括：

• 保持副本数
• 滚动发布
• 回滚版本
• 自愈补齐

换句话说，Deployment 关注的是“期望状态”。

例如：

• 我希望一直有 3 个 Pod
• 我希望镜像版本升级到 v2

至于中间怎么删旧建新，由控制器持续收敛。

Service 是“稳定入口”

Pod IP 不稳定，Deployment 名字也不是给业务流量直接访问的。
这时就需要 Service。

Service 解决的是：

• 给一组 Pod 一个稳定的虚拟访问入口
• 自动把流量分发到后端 Pod
• 当 Pod 增减或替换时，访问方不用感知

Service 不盯某一个 Pod，而是盯一组 label selector。

例如：

selector:
  app: order-service

只要 Pod 带这个标签，就会自动成为 Service 的后端端点。

三者是怎么协作的

可以按这条链路理解：

1. 你声明一个 Deployment
2. Deployment 创建 ReplicaSet
3. ReplicaSet 拉起多个 Pod
4. Pod 带着统一标签上线
5. Service 根据标签发现这些 Pod
6. 集群内其他服务通过 Service 名称访问它们

如果某个 Pod 挂了：

• Deployment 负责补一个新 Pod
• 新 Pod 起来后，只要标签匹配，Service 自动把它纳入后端

这就是为什么 Kubernetes 能做到“实例变化，但访问入口稳定”。

一个高频误区: Service 不是四层代理盒子那么简单

很多人第一次接触会把 Service 理解成“像 Nginx 一样转发请求”。
这种理解不算错，但不够完整。

更准确地说，Service 是一层服务发现和稳定抽象：

• 对上游暴露稳定名字和地址
• 对下游维护动态 Pod 集合

它把“实例变化”隔离掉了。

发布时三者怎么配合

当你更新 Deployment 镜像版本时：

1. Deployment 创建新 ReplicaSet
2. 新 ReplicaSet 拉起新 Pod
3. 探针通过后，新 Pod 被加入 Service 后端
4. 旧 Pod 逐步摘除

这意味着真正影响发布稳定性的，不只是 Deployment 本身，还包括：

• Pod 是否能健康启动
• readiness probe 是否正确
• Service 是否只把流量打到可用 Pod

所以发布稳定性的核心，不是“我有 Deployment”，而是这条链路都设计对了。

为什么线上常见问题都卡在三者交界处

1. Pod 起得来，但 Service 没流量

常见原因：

• label 不匹配
• readiness probe 未通过
• Service selector 配错

2. Deployment 显示更新中，但业务一直 502

常见原因：

• 新 Pod 启动慢
• 滚动更新参数过激
• 探针配置导致 Pod 频繁重启

3. Pod 正常，调用仍失败

这时要看 Service、Endpoint、DNS、Ingress 等后续链路，而不是只盯 Pod。

一个实用的心智图

你可以这样记：

• Pod: 具体跑起来的实例
• Deployment: 负责让实例数量和版本维持在期望状态
• Service: 负责让别人稳定找到这组实例

如果把它们映射到传统发布概念：

• Pod 类似单个应用实例
• Deployment 类似发布编排和副本管理
• Service 类似服务注册发现加稳定入口

总结

Pod、Deployment、Service 不是三个平行知识点，而是一条连续的应用交付链路。

你真正要建立的理解是：

• Pod 负责运行
• Deployment 负责管理
• Service 负责暴露

把这条链看清楚之后，再去理解探针、Ingress、HPA、ConfigMap，整个 Kubernetes 会顺很多。