第 8 篇：Kubernetes Pod、Node 与 Deployment#

2.1 Pod：最小调度单元，不是稳定机器#

Pod 是 Kubernetes 中最小调度单元。一个 Pod 可以包含一个或多个容器，这些容器共享网络命名空间和部分生命周期。对普通后端 API 来说，一个 Pod 通常只有一个业务容器；sidecar 场景下，可能还有日志代理、服务网格代理或辅助容器。Pod 内部容器共享同一个 Pod IP，容器之间可以用 localhost 通信。

Pod 不是稳定机器。Pod 被删除、驱逐、节点故障或滚动发布时，新的 Pod 会获得新的名称和 IP。后端调用方不应该记录 Pod IP，也不应该直接依赖某个 Pod 名称。稳定访问入口应该由 Service 提供，副本维持应该由 ReplicaSet 或 Deployment 负责。

Pod 的状态要分层看。Pod phase 可能是 Pending、Running、Succeeded、Failed、Unknown；container state 可能是 Waiting、Running、Terminated；conditions 里有 Initialized、Ready、ContainersReady、PodScheduled 等。看到 Running 不代表已经 ready，看到 Pending 也不一定是镜像问题。先区分 Pod 是否被调度，再看容器是否启动，再看 readiness 是否通过。

2.2 Node、Scheduler 与资源约束#

Node 是运行 Pod 的工作节点。每个 Node 上有 kubelet、容器运行时、网络插件和系统资源。Kubernetes 调度 Pod 时，会看 Node 的可分配资源、污点和容忍、亲和性、节点选择器、PVC 绑定、拓扑约束等条件。Node 不是业务对象，但 Node 状态会直接影响 Pod 是否能运行。

Scheduler 只负责把未调度的 Pod 绑定到某个 Node。它不拉镜像，不启动容器，也不判断业务是否健康。Pod Pending 且事件里出现 FailedScheduling 时，说明调度阶段就没过。常见原因包括 CPU 或内存 requests 太大、节点 taint 不允许调度、nodeSelector 不匹配、PVC 未绑定。

requests 和 limits 是后端服务必须认真设计的字段。requests 决定调度时预留多少资源，limits 决定容器运行时的上限。没有 requests，调度器无法准确判断容量；limits 太低，容易 OOMKilled；limits 太高，可能让单个服务影响节点稳定。Java 服务还要让 JVM 感知容器内存，避免堆和非堆内存加起来超过 limit。

2.3 Deployment 与 ReplicaSet 控制循环#

Deployment 是无状态后端 API 最常用的工作负载对象。它声明期望副本数、Pod 模板、滚动发布策略和历史版本。Deployment 不直接创建容器，它通过 ReplicaSet 管理某一版本的 Pod。当你修改 Pod 模板中的镜像、环境变量、资源或探针时，Deployment 会创建新的 ReplicaSet，并按照策略逐步替换旧 Pod。

ReplicaSet 负责维持某一版本 Pod 的数量。你通常不直接编辑 ReplicaSet，因为它由 Deployment 管理。rollout 过程中，旧 ReplicaSet 副本数减少，新 ReplicaSet 副本数增加。rollout 卡住时，不要只看 Deployment，要看新 ReplicaSet 创建的 Pod 为什么没有 ready。

Deployment 的成功不等于业务一定可用。Deployment 只知道 Pod 是否 ready，不知道你的业务指标是否正常、数据库迁移是否兼容、接口延迟是否升高。生产发布还要结合 Service、Ingress、监控、日志、trace、错误率和回滚策略一起判断。

3.1 从 YAML 到 Pod 的控制链路#

当你提交 Deployment YAML 时，API Server 保存的是期望状态。Deployment 控制器观察到期望状态后，会计算是否需要创建或更新 ReplicaSet。ReplicaSet 控制器继续观察副本数量，如果当前 Pod 少于期望，就创建新的 Pod 对象。此时 Pod 还没有运行，只是 API Server 中的对象。

Scheduler 观察到没有绑定 Node 的 Pod 后，会尝试选择合适 Node。它会检查资源 requests、节点状态、调度约束、污点容忍、亲和性、存储绑定等。如果找不到合适节点，Pod 会停留在 Pending，并在 events 中记录 FailedScheduling。这个阶段应用容器还没启动，所以查应用日志没有意义。

Pod 被绑定到 Node 后，目标 Node 上的 kubelet 开始工作。kubelet 会拉取镜像、准备 volume、设置网络、启动容器、运行探针，并把状态回写 API Server。镜像拉取失败会出现 ImagePullBackOff；进程启动后反复退出会出现 CrashLoopBackOff；内存超限可能出现 OOMKilled；readiness 失败会让 Pod 不接 Service 流量。

3.2 滚动发布和版本切换#

Deployment 更新时，关键变化通常发生在 Pod template。只要 spec.template 发生变化，例如镜像 tag、环境变量、资源、探针、label 等，Deployment 就会创建新的 ReplicaSet。仅修改 Deployment 外层 metadata，不一定触发新 Pod。

滚动发布的核心是逐步增加新 ReplicaSet 副本，逐步减少旧 ReplicaSet 副本。maxSurge 控制最多可以额外创建多少新 Pod，maxUnavailable 控制发布过程中最多允许多少旧 Pod 不可用。对后端 API 来说，readinessProbe 是滚动发布是否安全的关键。新 Pod 未 ready 之前，不应该被 Service 接流量。

rollout 卡住通常有三类原因。第一，新 Pod 无法调度或拉镜像。第二，新 Pod 启动后崩溃或探针失败。第三，资源不足导致新旧 Pod 无法同时存在。排障时用 kubectl rollout status 看 Deployment，再看 ReplicaSet 和新 Pod 事件，才能找到具体卡点。

3.3 伪代码：Deployment 控制循环#

下面用伪代码理解 Deployment、ReplicaSet、Scheduler 和 kubelet 的分工。

1
function reconcileDeployment(deployment):
2
    desiredTemplate = deployment.spec.template
3
    desiredReplicas = deployment.spec.replicas
4

5
    currentReplicaSet = findReplicaSetByTemplate(desiredTemplate)
6
    if currentReplicaSet is None:
7
        currentReplicaSet = createReplicaSet(desiredTemplate)
8

9
    rolloutPlan = calculateRollout(
10
        newReplicaSet = currentReplicaSet,
11
        oldReplicaSets = findOldReplicaSets(deployment),
12
        strategy = deployment.spec.strategy
13
    )
14

15
    scaleReplicaSets(rolloutPlan)
16

17
function reconcileReplicaSet(replicaSet):
18
    while replicaSet.readyPods < replicaSet.desiredReplicas:
19
        createPod(replicaSet.template)
20

21
function schedulePod(pod):
22
    candidates = filterNodesByResourcesAndConstraints(pod)
23
    if candidates.isEmpty():
24
        recordEvent(pod, "FailedScheduling")
25
        return
26
    bindPodToNode(pod, chooseBestNode(candidates))
27

28
function kubeletSyncPod(pod):
29
    pullImages(pod.containers)
30
    mountVolumes(pod.volumes)
31
    startContainers(pod.containers)
32
    runProbes(pod)
33
    reportStatus(pod)

这段伪代码说明：Deployment 不拉镜像，ReplicaSet 不选 Node，Scheduler 不启动容器，kubelet 不决定期望副本。排障时必须沿着职责链路看证据，不能把所有异常都归到一个对象上。

4.1 编写 Deployment#

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: order-api
5
  labels:
6
    app: order-api
7
spec:
8
  replicas: 2
9
  selector:
10
    matchLabels:
11
      app: order-api
12
  strategy:
13
    type: RollingUpdate
14
    rollingUpdate:
15
      maxSurge: 1
16
      maxUnavailable: 0
17
  template:
18
    metadata:
19
      labels:
20
        app: order-api
21
    spec:
22
      containers:
23
        - name: api
24
          image: registry.example.com/order-api:1.0.0
25
          ports:
26
            - containerPort: 8080
27
          resources:
28
            requests:
29
              cpu: 200m
30
              memory: 512Mi
31
            limits:
32
              memory: 1Gi
33
          readinessProbe:
34
            httpGet:
35
              path: /actuator/health/readiness
36
              port: 8080
37
            initialDelaySeconds: 15
38
            periodSeconds: 5
39
          livenessProbe:
40
            httpGet:
41
              path: /actuator/health/liveness
42
              port: 8080
43
            initialDelaySeconds: 60
44
            periodSeconds: 10

这个示例没有写 Service，因为下一篇会专门讲 Service 和 Ingress。这里先聚焦工作负载本身：Deployment 如何管理 Pod 副本，Pod 如何被调度到 Node，容器如何启动和暴露健康状态。

4.2 应用和观察对象链#

应用 Deployment：

1
kubectl apply -f order-api-deployment.yaml

观察对象链：

1
kubectl get deployment order-api
2
kubectl get rs -l app=order-api
3
kubectl get pod -l app=order-api -o wide
4
kubectl rollout status deployment/order-api

kubectl get pod -o wide 可以看到 Pod 被调度到哪个 Node，以及 Pod IP。Pod IP 只是当前实例地址，不应该写进业务配置。kubectl get rs 可以看到当前版本和历史版本对应的 ReplicaSet。rollout 状态能告诉你发布是否完成。

4.3 模拟更新和回滚#

更新镜像：

1
kubectl set image deployment/order-api api=registry.example.com/order-api:1.0.1
2
kubectl rollout status deployment/order-api

查看历史：

1
kubectl rollout history deployment/order-api
2
kubectl get rs -l app=order-api

回滚：

1
kubectl rollout undo deployment/order-api

这里要注意，回滚只是回到上一个 Deployment revision。它不能自动回滚数据库 schema，不能撤销外部配置变更，也不能保证业务状态兼容。后端发布必须把镜像、配置、数据库迁移和业务兼容性一起设计。

5.1 apiVersion、kind、replicas 和 selector#

apiVersion: apps/v1 和 kind: Deployment 决定对象类型。Kubernetes 根据类型把对象交给对应控制器处理。写成 Pod、Deployment、StatefulSet 或 Job，背后的控制逻辑完全不同。后端 API 通常用 Deployment，因为它适合无状态副本和滚动发布。

replicas 是期望副本数。副本数为 2，不是“启动两个容器后结束”，而是控制器持续维持两个 Pod 副本。某个 Pod 被删掉，ReplicaSet 会创建新的 Pod。副本数设计要结合可用性、容量、成本和依赖承载能力。副本变多会增加数据库连接、缓存连接和下游调用压力。

selector.matchLabels 是控制器识别 Pod 的依据。它必须和 template.metadata.labels 匹配。这个字段一旦创建后通常不应随意改变。selector 错误会导致 Deployment 管不到 Pod，Service 也可能选不到后端。Kubernetes 排障里，label 和 selector 是第一等证据。

5.2 template、image、ports 和 probes#

template 是 Pod 模板。Deployment 的版本变化主要由 spec.template 决定。修改镜像、环境变量、资源、探针或模板 label，会触发新的 ReplicaSet。理解这一点后，你就能解释为什么有些 YAML 修改不会触发滚动发布。

image 是容器制品引用。生产环境最好使用明确版本 tag 或 digest，不要依赖可变的 latest。如果出现 ImagePullBackOff，要看镜像名、tag、仓库地址、网络、认证和 imagePullSecret。不要先去改 Deployment 副本数，那和拉取失败没有直接关系。

ports.containerPort 主要是声明容器监听端口，方便文档化和被其他对象引用。它不等于外部访问入口。真正的集群访问入口要靠 Service，外部访问还要靠 Ingress、Gateway 或 LoadBalancer。探针会访问容器端口，因此端口和探针路径必须和应用真实监听一致。

readinessProbe 和 livenessProbe 语义不同。readiness 失败时，Pod 不应接流量；liveness 失败时，kubelet 会重启容器。后端 API 不要把依赖短暂波动直接放进 liveness，否则数据库抖一下可能触发应用反复重启。启动慢的应用可以再加 startupProbe。

5.3 requests、limits、Node 和调度#

resources.requests 决定调度时预留资源。Scheduler 会根据 requests 判断哪个 Node 能容纳 Pod。如果 requests 设置过高，Pod 可能 Pending；设置过低，多个 Pod 可能挤在同一 Node 上，运行时竞争严重。requests 是容量规划输入，不是装饰字段。

resources.limits 决定容器运行上限。内存超过 limit 时，容器可能被 OOMKilled；CPU limit 则可能导致 throttling。Java 后端要让 JVM 最大堆、直接内存、元空间、线程栈和容器 limit 之间留出余量。只设置 -Xmx 不看容器 limit，很容易在高峰期被杀。

Node 约束包括 nodeSelector、affinity、taints/tolerations、拓扑分布和 PVC 绑定。它们决定 Pod 能不能调度到合适位置。学习阶段可以先不写复杂约束，但生产环境至少要知道 Pending 时可能不是应用问题，而是资源或调度约束问题。

6.1 无状态 API 的标准部署#

无状态 API 最适合用 Deployment。应用状态放在数据库、缓存或外部服务里，Pod 可以随时重建。每个 Pod 输出标准日志，暴露健康接口，优雅处理 SIGTERM，不把关键数据写在本地文件系统中。这样的服务才能真正享受 Kubernetes 的副本和滚动发布能力。

标准部署至少应该包含 replicas、resources、readinessProbe、livenessProbe、清晰 labels、镜像版本和发布策略。Service 和 Ingress 会在下一篇讲，但 Deployment 本身已经决定了实例是否稳定、是否可调度、是否能安全滚动。

后端服务还要考虑连接池。replicas 从 2 扩到 10，数据库连接池如果每个实例 50 个连接，总连接数就会从 100 变成 500。Kubernetes 可以扩副本，但下游依赖能否承受，是应用和架构设计问题。

6.2 发布、扩容和容量治理#

扩容不是只改 replicas。水平扩容会影响 CPU、内存、下游连接、缓存命中、消息消费并发和外部接口限流。扩容前要看资源使用率、请求延迟、错误率和依赖容量。盲目扩副本可能把瓶颈从 API 转移到数据库。

滚动发布要依赖 readiness。新 Pod 只有在准备好接流量时才应该进入 Service endpoints。应用收到 SIGTERM 后，也要停止接收新请求、等待正在处理的请求结束，再退出。否则滚动发布会制造 5xx 或请求中断。

容量治理要从 requests 开始。requests 太低，调度看起来省资源，但节点可能超卖严重；requests 太高，资源利用率低，Pod 也更容易 Pending。后端团队应该根据压测和历史指标给出初始 requests，再通过监控持续调整。

6.3 订单服务排障案例#

假设订单 API 发布后一直 Pending。第一步看 kubectl describe pod，如果 events 显示 Insufficient memory，说明调度阶段资源不足，应该调整 requests、扩容节点或优化资源占用，而不是查应用日志。因为应用根本还没启动。

如果订单 API 是 CrashLoopBackOff，说明容器启动后反复退出。此时看 kubectl logs --previous、环境变量、配置引用、启动命令和数据库连接。不要先怀疑 Scheduler，因为 Pod 已经调度并启动过。

如果发布后 rollout 卡住，但 Pod Running，继续看 readinessProbe。健康接口可能因为数据库连接失败而返回非 200，Pod 因此不进入 ready。此时 Service 可能没有新版本 endpoints，rollout 会等待。修复方向是配置、依赖或探针语义，而不是盲目把 probe 删除。

7.1 Pending、ImagePullBackOff 和调度问题#

Pod Pending 时，先看事件。

1
kubectl describe pod <pod-name>
2
kubectl get node
3
kubectl describe node <node-name>

如果事件里是 FailedScheduling，重点看资源 requests、nodeSelector、affinity、taints/tolerations、PVC 绑定和节点可用资源。此时不要查应用日志，因为容器还没有运行。

ImagePullBackOff 时，看镜像引用和仓库认证。

1
kubectl describe pod <pod-name>
2
kubectl get secret
3
kubectl logs <pod-name>

很多时候 kubectl logs 没有内容，因为容器根本没启动。真正证据在 Pod events 里，例如镜像不存在、认证失败、拉取超时。

7.2 CrashLoopBackOff、OOMKilled 和探针失败#

CrashLoopBackOff 表示容器进程反复退出。看当前日志和上一次退出日志。

1
kubectl logs <pod-name>
2
kubectl logs <pod-name> --previous
3
kubectl describe pod <pod-name>

常见原因包括启动命令错误、环境变量缺失、配置文件不存在、数据库连接失败、应用启动后立即退出。--previous 很重要，因为容器重启后当前日志可能只剩新一轮启动内容。

OOMKilled 要看容器状态和资源限制。

1
kubectl describe pod <pod-name>
2
kubectl top pod <pod-name>

如果内存 limit 过低，先调整 limit 和 JVM 参数，再结合内存指标判断是否存在泄漏。不要只把副本数加大，因为单 Pod 内存超限并不会因副本数增加自动消失。

探针失败时，看探针路径、端口、initialDelay、timeout、period，以及应用实际健康接口。readiness 失败会影响接流量，liveness 失败会触发重启。两者后果不同，不能混用。

7.3 Deployment 不更新和 rollout 卡住#

Deployment 修改后没有新 Pod，先确认是否修改了 spec.template。只有 Pod 模板变化才会触发新 ReplicaSet。可以查看 rollout 历史和 ReplicaSet。

1
kubectl rollout history deployment/order-api
2
kubectl get rs -l app=order-api
3
kubectl describe deployment order-api

rollout 卡住时，看新 ReplicaSet 的 Pod 状态。

1
kubectl get pod -l app=order-api -o wide
2
kubectl describe pod <new-pod-name>
3
kubectl logs <new-pod-name> --tail=200

如果新 Pod 不 ready，Deployment 会等待，旧 Pod 可能继续保留。不要为了让 rollout 通过就删除 readinessProbe。正确做法是修复新版本为什么不 ready，或者回滚到上一个版本。

8.1 应用生命周期边界#

后端应用必须正确处理启动、ready、运行、终止四个阶段。启动阶段可以慢，但要用 startupProbe 或合理 initialDelay 避免误杀；ready 阶段要只在能处理请求时返回成功；运行阶段要输出可观测日志和指标；终止阶段要处理 SIGTERM，停止接新请求并等待正在处理的请求结束。

不要让 livenessProbe 承担业务依赖判断。数据库短暂不可用时，应用可能应该暂时不 ready，而不是被重启。重启不能修复外部依赖故障，反而可能造成连接风暴。readiness 和 liveness 的边界，是后端 Kubernetes 稳定性的基础。

Pod 本地文件系统也要谨慎使用。Pod 可以重建，本地状态会丢失。临时文件可以写 emptyDir，业务数据应该放外部存储或数据库。把关键业务状态写在 Pod 本地目录里，是和 Kubernetes 可替换实例模型冲突的。

8.2 资源、调度和高可用边界#

资源配置要来自压测和线上指标。requests 决定调度容量，limits 决定运行上限。后端团队要知道自己的服务在不同 QPS 下的 CPU、内存、线程、连接池和延迟表现。没有这些数据，Kubernetes 只能执行你写的数字，不能替你判断是否合理。

高可用还需要考虑 Pod 分布。多个副本如果都调度到同一节点，节点故障会同时影响全部副本。生产环境可以通过 topology spread constraints、pod anti-affinity 或平台默认策略让副本分散。但这些策略也会增加调度约束，需要和资源容量一起评估。

Deployment 不适合所有工作负载。无状态 API 用 Deployment；有状态服务可能用 StatefulSet；一次性任务用 Job；定时任务用 CronJob；节点级守护进程用 DaemonSet。选错工作负载对象，会让后续治理非常别扭。

8.3 发布、回滚和观测边界#

rollout 成功只是 Kubernetes 视角的成功，不等于业务成功。业务还要看错误率、延迟、吞吐、关键接口、日志和 trace。一个版本可能所有 Pod 都 ready，但业务逻辑错误仍然存在。生产发布需要 Kubernetes 状态和业务指标共同验收。

回滚也有边界。Deployment 可以回滚 Pod 模板，但不能自动回滚数据库 schema、消息格式、缓存数据和外部配置。后端发布要保持向前兼容，数据库迁移要能安全回滚或双写过渡。不要把 kubectl rollout undo 当成万能撤销按钮。

观测要围绕对象链路组织。Deployment 看 rollout，ReplicaSet 看版本副本，Pod 看事件和日志，Node 看资源和状态，Service 看 endpoints。业务层再看指标、日志和 trace。只有平台证据和业务证据结合，事故复盘才不会停留在“Pod 重启了”这种表面描述。

9.1 适合使用 Deployment 的场景#

无状态 HTTP API、内部 RPC 服务、后台消费者、网关层服务，通常适合 Deployment。它们可以水平扩副本，实例之间没有稳定身份要求，状态在外部数据库、缓存或消息系统中。

需要滚动发布、快速回滚和副本自愈的服务，也适合 Deployment。Deployment 能保留历史 ReplicaSet，能逐步替换旧版本，能在 Pod 异常时创建新副本。前提是应用本身支持健康检查、优雅关闭和无状态运行。

团队想统一后端交付模板时，也应该从 Deployment 开始。它是 Kubernetes 中最常见的后端工作负载模型，和 Service、Ingress、ConfigMap、Secret、HPA、监控等对象都能自然组合。

9.2 不适合使用 Deployment 的场景#

需要稳定网络身份和稳定存储身份的有状态组件，不应该默认使用 Deployment。数据库、部分消息队列和有状态集群组件更可能需要 StatefulSet，或者直接使用外部托管服务。

一次性数据库迁移、批处理、初始化任务，不适合长期 Deployment。它们更适合 Job 或 CronJob。用 Deployment 跑一次性任务，会让控制器不断维持副本，和任务完成语义冲突。

每个节点都要运行一个实例的组件，例如日志采集 agent、网络插件、节点监控 agent，也不适合 Deployment。它们通常应该用 DaemonSet，让每个目标 Node 上运行一个 Pod。

9.3 默认建议#

默认建议是：后端无状态 API 用 Deployment，配齐 resources、readinessProbe、livenessProbe、清晰 labels 和稳定镜像版本；外部入口交给 Service 和 Ingress；配置和密钥交给 ConfigMap/Secret；状态数据不要写在 Pod 本地。

排障默认顺序是：先看 Deployment rollout，再看 ReplicaSet，再看 Pod events 和 logs，再看 Node 与资源，最后结合业务指标。不要只看一条日志就下结论，也不要把所有问题都归因于 Kubernetes。

学习顺序上，先理解 Pod 和 Deployment，再理解 Service 和 Ingress。Pod 能不能稳定运行，是流量入口之前的基础；如果 Pod 自己都不 ready，Service 和 Ingress 配得再漂亮也没有意义。