资源模型基础：Pod、Service、Deployment、StatefulSet 概述

在 Kubernetes 故障排查中，理解核心资源模型是定位故障域的第一步。Pod、Service、Deployment、StatefulSet 构成了绝大多数工作负载的骨架。它们之间的依赖关系、生命周期差异以及网络模型，往往是排错时最先需要确认的维度。

1. 核心资源角色与职责

资源类型 核心职责 排错关注点
Pod 最小调度单元，运行一个或多个容器，共享网络栈与存储卷 容器退出码、就绪探针、资源限制、镜像拉取
Service 提供稳定的网络端点，通过标签选择器将流量分发到后端 Pod 端点列表、ClusterIP 可达性、端口映射、会话亲和性
Deployment 声明式管理无状态 Pod 的副本数、滚动更新与回滚 副本状态、更新策略、历史版本、Pod 模板哈希
StatefulSet 管理有状态 Pod，提供稳定的网络标识与持久化存储 序号索引、PVC 绑定、Pod 启动顺序、Headless Service
排错口诀：Pod 看死活，Service 看端点，Deployment 看副本，StatefulSet 看序号与存储。

2. 资源模型关系图

下图展示了四种资源在集群中的典型协作关系。Deployment 或 StatefulSet 负责管理 Pod 的生命周期，Service 通过标签选择器将流量路由到后端 Pod，而 Pod 内部包含一个或多个容器。

Kubernetes 核心资源模型关系图 Kubernetes 核心资源模型关系 Deployment 无状态 · 滚动更新 · 回滚 StatefulSet 有状态 · 稳定标识 · 序号 Pod A 10.0.1.5 Pod B 10.0.1.6 Pod C 10.0.1.7 Service ClusterIP: 10.96.0.10 管理副本 管理序号 标签选择器 排错关键路径 1. 检查 Deployment/StatefulSet 的副本状态 → 确认 Pod 是否 Running 2. 检查 Service 的 Endpoints 列表 → 确认后端 Pod IP 是否注册 3. 检查 Pod 的就绪探针 → 确认 Service 是否将流量路由到该 Pod

3. 资源生命周期对比

不同资源在创建、更新、删除时的行为差异，是故障域划分的重要依据。下表总结了关键生命周期特征：

操作 Deployment StatefulSet Service
创建 立即创建 Pod，按 maxSurge 策略启动 按序号顺序创建 Pod，前一个 Ready 才启动下一个 创建后立即分配 ClusterIP，但 Endpoints 为空直到有匹配 Pod
更新 滚动更新，逐步替换 Pod 按序号逆序更新，保留 PVC 绑定 更新 selector 或 port 后，Endpoints 重新匹配
删除 删除 Pod 后 ReplicaSet 立即重建 删除 Pod 后按序号重建，PVC 保留 删除 Service 后 Endpoints 立即清除，Pod 不受影响
扩缩容 并行创建/删除 Pod 按序号顺序创建/删除 Pod 无需操作，自动感知后端 Pod 变化
常见陷阱：StatefulSet 的 Pod 删除后，PVC 不会自动删除。如果手动删除了 PVC，新 Pod 会因 PVC 绑定失败而处于 Pending 状态。这是有状态应用排错时最容易忽略的故障域。

4. 网络模型与标识

Pod 与 Service 之间的网络模型决定了流量路径。理解以下三个核心概念，有助于快速定位网络层面的故障：

  • ClusterIP：Service 的虚拟 IP，仅在集群内部可达。通过 iptables 或 IPVS 规则将流量转发到后端 Pod。
  • Pod IP：Pod 的真实网络地址，由 CNI 插件分配。Pod 重启后 IP 会变化，因此客户端应始终通过 Service 访问。
  • Headless Service：设置 clusterIP: None，不提供负载均衡，直接返回后端 Pod 的 IP 列表。StatefulSet 通常配合 Headless Service 使用，为每个 Pod 提供稳定的 DNS 名称。
# 查看 Service 的 Endpoints 列表
kubectl get endpoints <service-name>

# 查看 Pod 的 IP 与就绪状态
kubectl get pods -o wide

# 查看 StatefulSet 的 DNS 记录（需配合 Headless Service）
kubectl run -it --rm dns-test --image=busybox -- nslookup <pod-name>.<service-name>.<namespace>.svc.cluster.local

5. 故障域划分原则

在排错时，将问题归因到正确的资源模型层，可以大幅缩小排查范围。以下是一套实用的故障域划分流程：

  1. Pod 层：检查 Pod 状态是否为 Running、就绪探针是否通过、容器日志是否有错误。如果 Pod 反复 CrashLoopBackOff，优先排查应用配置与资源限制。
  2. Service 层：检查 Endpoints 列表是否包含目标 Pod IP。如果 Endpoints 为空，检查 Service 的 selector 是否与 Pod 的 labels 匹配。
  3. Deployment/StatefulSet 层：检查副本数是否达到预期、更新策略是否阻塞、历史版本是否异常。如果 Pod 无法调度，检查节点资源与污点容忍。
  4. 存储层（StatefulSet 特有）：检查 PVC 是否 Bound、StorageClass 是否存在、PV 的访问模式是否匹配。
实战案例：某生产环境 StatefulSet 的 Pod 一直处于 Pending 状态。通过 kubectl describe pod 发现 PVC 绑定失败，进一步排查发现 StorageClass 引用的存储后端磁盘配额已满。故障域定位到存储层，而非应用层。

6. 资源模型排错速查表

现象 可能故障域 排查命令
Pod 一直 Pending 调度、存储、资源配额 kubectl describe pod <pod-name>
Pod 反复重启 应用配置、资源限制、探针 kubectl logs --previous <pod-name>
Service 无法访问 Endpoints、selector、端口 kubectl get endpoints <svc-name>
Deployment 更新卡住 更新策略、就绪探针、副本数 kubectl rollout status deployment <deploy-name>
StatefulSet Pod 启动顺序异常 序号依赖、PVC 绑定、Headless Service kubectl get statefulset <sts-name> -o yaml
← 上一章 📖 返回目录 下一章 →