2. Kubernetes 核心概念回顾：Pod、Deployment、Service、Node、NodePool 的定义与关系
在深入滚动升级与流量切换之前，必须重新校准这五个核心概念。它们构成了集群调度的最小单元、工作负载声明、网络抽象、物理/虚拟节点以及节点池化管理的完整链路。理解它们之间的静态关系与动态交互，是后续控制速率与切换流量的基础。
2.1 核心概念定义速查表
| 概念 | API 对象（Group/Version） | 核心职责 | 生命周期特征 |
|---|---|---|---|
| Pod | v1 |
运行一个或多个容器，共享网络/IP 与存储卷 | 临时性，可被驱逐、重启、重建；IP 不固定 |
| Deployment | apps/v1 |
声明式管理 ReplicaSet，控制 Pod 的期望副本数与更新策略 | 支持滚动更新、回滚、扩缩容；版本可追溯 |
| Service | v1 |
提供稳定的虚拟 IP（ClusterIP）与 DNS 名称，负载均衡到后端 Pod | 与 Pod 解耦，通过 Label Selector 动态绑定 |
| Node | v1 |
集群中的工作节点（物理机/虚拟机），运行 kubelet 与容器运行时 | 可被标记为不可调度（cordon）、驱逐（drain） |
| NodePool | 云厂商扩展（如 cluster.x-k8s.io/v1beta1） |
将一组同配置的 Node 抽象为池，支持统一扩缩容、升级、镜像替换 | 池级别操作，节点可被原地升级或替换 |
关键区分：Pod 是“运行载体”，Deployment 是“声明控制器”，Service 是“流量入口”，Node 是“容量单元”，NodePool 是“运维聚合层”。滚动升级速率控制作用于 Deployment 的 maxSurge/maxUnavailable，而流量切换作用于 Service 与 NodePool 的节点就绪状态。
2.2 五者关系：从调度到流量闭环
下图展示了从用户请求到 Pod 运行在 NodePool 上的完整链路，以及 Deployment 如何驱动 Pod 版本更新。
关系要点：
- Deployment → ReplicaSet → Pod：Deployment 不直接管理 Pod，而是通过 ReplicaSet 控制 Pod 的版本与数量。每次滚动升级会创建新 RS，逐步缩容旧 RS。
- Service → Pod：Service 通过
spec.selector匹配 Pod 标签，流量只转发到Ready状态的 Pod。这是流量切换的“开关”。 - Pod → Node：Pod 由调度器绑定到某个 Node，Node 的
Ready状态影响 Pod 的可用性。 - Node → NodePool：NodePool 是云原生集群的节点分组抽象，升级 NodePool 时，池内节点会逐个被封锁、驱逐、替换或原地升级。
2.3 滚动升级中的角色分工
在滚动升级场景下，每个概念承担不同职责，理解分工才能精准控制速率与流量：
| 组件 | 在滚动升级中的角色 | 速率控制参数 |
|---|---|---|
| Deployment | 驱动 Pod 版本替换，控制新旧 Pod 的创建与销毁节奏 | maxSurge（最大超出副本数）、maxUnavailable（最大不可用数） |
| Pod | 承载新版本容器，通过 Readiness Probe 向 Service 注册就绪状态 | readinessProbe.initialDelaySeconds、periodSeconds |
| Service | 自动将流量从旧 Pod 切换到新 Pod（基于标签与就绪状态） | 无直接参数，依赖 Pod 的 Ready 状态 |
| Node | 提供 Pod 运行环境；节点被封锁（cordon）后不再调度新 Pod | 无直接参数，但节点状态影响 Pod 调度 |
| NodePool | 管理节点组的升级顺序与速率，逐个替换或原地升级节点 | maxSurge（节点级）、maxUnavailable（节点级）、升级策略（滚动/替换） |
2.4 典型交互流程：一次滚动升级
- 用户更新 Deployment 的 Pod 模板（如镜像版本），触发滚动升级。
- Deployment 创建新 ReplicaSet，并按照
maxSurge和maxUnavailable逐步创建新 Pod、销毁旧 Pod。 - 新 Pod 启动，运行 Readiness Probe。通过后，Pod 状态变为
Ready。 - Service 的 Endpoint 控制器 检测到新 Pod 就绪，将其加入负载均衡后端；同时移除未就绪的旧 Pod。
- 流量平滑切换：新请求开始流向新 Pod，旧 Pod 在
terminationGracePeriodSeconds内处理完已有连接后退出。 - 如果涉及 NodePool 升级：NodePool 控制器会先封锁节点（cordon），驱逐 Pod（drain），然后升级节点镜像或替换实例，最后解除封锁。Pod 会被重新调度到已升级的节点上。
常见误区：很多人认为 Service 在滚动升级中“主动切换流量”，实际上 Service 只是被动响应 Pod 的 Ready 状态变化。真正的流量切换驱动力来自 Deployment 的 Pod 替换节奏与 Readiness Probe 的探测结果。NodePool 升级时，节点驱逐顺序会打破 Deployment 的速率控制，需要额外协调。
2.5 概念关系总结
下图从“声明层”、“调度层”、“网络层”、“基础设施层”四个维度归纳五者的层级关系：
课程前置结论：滚动升级速率控制的核心在于 Deployment 的
maxSurge 与 maxUnavailable，而流量切换的核心在于 Service 对 Pod Ready 状态的实时响应。NodePool 升级则是在节点维度引入额外的速率控制与流量排空逻辑。后续章节将逐一拆解这些参数的精确配置与实战调优。