2. Kubernetes 核心概念回顾：Pod、ReplicaSet、Deployment、Service、Node、节点池（Node Pool）的定义与关系
在深入 Deployment 滚动中断与集群升级治理之前，必须对 Kubernetes 的核心抽象层有精确的理解。这些概念构成了节点池巡检与排错的所有操作对象。以下按从最小调度单元到集群资源池的层次进行梳理。
2.1 核心概念定义
| 概念 | API 对象（Group/Version） | 定义 | 关键属性 |
|---|---|---|---|
| Pod | v1/Pod |
Kubernetes 中最小的可部署计算单元，封装一个或多个容器、存储资源与网络 IP。 | spec.containers、status.phase、spec.nodeName |
| ReplicaSet | apps/v1/ReplicaSet |
确保指定数量的 Pod 副本始终运行。通过 spec.selector 匹配 Pod 标签，管理 Pod 的创建与删除。 |
spec.replicas、spec.selector.matchLabels、spec.template |
| Deployment | apps/v1/Deployment |
声明式管理 ReplicaSet 与 Pod 的更新策略。支持滚动更新、回滚、扩缩容。是生产工作负载的标准控制器。 | spec.replicas、spec.strategy、spec.revisionHistoryLimit |
| Service | v1/Service |
为一组 Pod 提供稳定的网络端点与负载均衡。通过标签选择器将流量路由到后端 Pod。 | spec.selector、spec.type（ClusterIP/NodePort/LoadBalancer）、spec.ports |
| Node | v1/Node |
集群中的工作节点（物理机或虚拟机），运行 kubelet、kube-proxy 与容器运行时。承载 Pod 的实际计算资源。 | status.conditions、status.capacity、spec.taints |
| 节点池（Node Pool） | 云厂商扩展（如 cluster-api 或托管集群 CRD） |
一组具有相同配置（实例规格、镜像、磁盘、标签、污点）的 Node 集合。用于实现节点分组管理与差异化运维。 | spec.nodeTemplate、spec.autoscaling、status.nodes |
排错视角提示： 节点池并非原生 Kubernetes API 对象，而是云厂商（如 GKE Node Pool、AKS Agent Pool、EKS Managed Node Group）或 Cluster API 提供的抽象。在巡检时，需要同时关注
v1/Node 状态与节点池 CRD 状态之间的映射关系。
2.2 概念关系：从 Deployment 到节点池的完整链路
下图展示了从用户声明 Deployment 到最终调度到节点池中某个 Node 的完整对象关系链。理解这条链路是定位滚动中断与升级故障的基础。
2.3 关键关系详解
2.3.1 Deployment → ReplicaSet → Pod：三层控制链
- Deployment 不直接管理 Pod。 每次更新（镜像、环境变量等）时，Deployment 会创建一个新的 ReplicaSet，并逐步增加新 ReplicaSet 的副本数、减少旧 ReplicaSet 的副本数——这就是滚动更新的本质。
- ReplicaSet 通过标签选择器（selector） 匹配 Pod 的 labels。如果手动修改 Pod 标签使其脱离选择器，ReplicaSet 会立即创建新 Pod 补足副本数。
- Pod 的
status.phase反映其生命周期：Pending、Running、Succeeded、Failed、Unknown。排错时，Pending通常意味着资源不足或调度失败。
滚动中断关键点： 当 Deployment 执行滚动更新时，如果新 ReplicaSet 的 Pod 无法通过就绪探针（readinessProbe），旧 ReplicaSet 不会缩容，导致新旧 Pod 共存，可能引发流量异常。这是节点池巡检时需要重点关注的场景。
2.3.2 Service → Pod：流量路由
- Service 通过
spec.selector匹配 Pod 标签，自动将 Endpoints 或 EndpointSlice 更新为匹配 Pod 的 IP 列表。 - 滚动更新期间，旧 Pod 被移除、新 Pod 加入，Service 的 Endpoints 会动态变化。如果新 Pod 就绪延迟，可能导致部分请求超时。
- 排错命令：
kubectl get endpoints <service-name>可查看当前后端 Pod IP 列表，确认是否有异常 Pod 被路由。
2.3.3 Node → 节点池：分组与隔离
- Node 通过标签（labels）和污点（taints） 标识其所属节点池。例如：
cloud.google.com/gke-nodepool: pool-1。 - 节点池通常具有统一的实例规格（如 4vCPU/16GB），便于资源管理与自动扩缩容。巡检时需确认节点池内所有 Node 的
status.capacity是否一致。 - 节点池升级 是集群升级的最小操作单元。升级时，节点池内的 Node 会逐个被腾空（drain）并替换为新版本镜像。
2.4 概念关系总结表
| 关系对 | 关联方式 | 排错关注点 |
|---|---|---|
| Deployment → ReplicaSet | spec.template 生成 ReplicaSet 模板 |
新 ReplicaSet 是否成功创建；旧 ReplicaSet 是否正常缩容 |
| ReplicaSet → Pod | 标签选择器 + PodTemplate | Pod 是否全部 Running；是否有 CrashLoopBackOff |
| Service → Pod | 标签选择器 → Endpoints | Endpoints 是否包含目标 Pod IP；是否有未就绪 Pod 被路由 |
| Pod → Node | spec.nodeName 绑定 |
Pod 是否被调度到预期节点；节点资源是否充足 |
| Node → 节点池 | 节点标签/污点 + 云厂商 CRD | 节点池内 Node 版本是否一致；是否有异常 Node 未纳入池管理 |
2.5 节点池视角下的核心对象关系
下图从节点池运维角度，展示节点池、Node、Pod 与 Deployment 之间的依赖关系，以及升级时的影响范围。
节点池巡检关键指标：
- 节点池版本一致性： 同一节点池内所有 Node 的 kubelet 版本必须一致。版本不一致会导致调度异常与升级失败。
- 节点池资源水位： 检查
kubectl top node确认 CPU/内存使用率。如果节点池资源接近饱和，滚动更新时新 Pod 可能无法调度。 - Pod 分布均衡性： 使用
kubectl get pods -o wide查看 Pod 是否均匀分布在节点池内的 Node 上。避免单点故障。
2.6 核心概念在排错中的实际应用
在后续章节的巡检与排错场景中，你会反复用到以下映射关系：
- Pod 调度失败 → 检查 Node 资源与污点：
kubectl describe pod <pod-name>查看 Events 中的调度错误，然后检查对应 Node 的status.capacity与spec.taints。 - 滚动更新卡住 → 检查 ReplicaSet 与 Pod 就绪状态：
kubectl rollout status deployment <deploy-name>结合kubectl get rs查看新旧 ReplicaSet 的副本数变化。 - 节点池升级失败 → 检查节点池 CRD 与 Node 版本： 对比节点池期望版本与 Node 实际 kubelet 版本，确认是否有 Node 未完成升级。
快速记忆口诀： “Deployment 管版本，ReplicaSet 管数量，Pod 管运行，Service 管流量，Node 管资源，节点池管分组。” 巡检时按这个链路逐层排查，不会遗漏关键点。