2. Kubernetes 集群架构基础：Master 节点、Worker 节点、Pod、Deployment、StatefulSet、Service 核心概念回顾
在深入容量规划与自动扩缩容之前，必须重新夯实 Kubernetes 的核心架构基石。本章将聚焦于集群的两大物理角色（Master 与 Worker）、最小编排单元（Pod）、工作负载控制器（Deployment / StatefulSet）以及网络抽象层（Service）。理解这些组件的资源模型与生命周期，是后续制定扩缩容策略的前提。
2.1 集群物理拓扑：Master 节点与 Worker 节点
Kubernetes 集群由两类节点构成：Master 节点（控制平面） 负责全局决策与集群状态管理；Worker 节点（数据平面） 负责运行实际业务容器。两者通过 kube-apiserver 进行通信，形成“控制面-数据面”分离架构。
| 节点角色 | 核心组件 | 职责说明 | 资源敏感度 |
|---|---|---|---|
| Master | kube-apiserver, etcd, kube-scheduler, kube-controller-manager | API 网关、状态存储、调度决策、控制器循环 | 高（etcd 磁盘 IO、apiserver 内存） |
| Worker | kubelet, kube-proxy, 容器运行时（containerd） | Pod 生命周期管理、网络代理、镜像拉取 | 中（CPU/内存/网络带宽） |
容量规划要点： Master 节点不建议运行业务 Pod，避免资源争抢导致控制面不稳定。Worker 节点的可分配资源 = 节点总资源 - 系统预留 - kubelet 预留 - Pod 驱逐阈值。扩缩容决策应基于 Worker 节点的 Allocatable 而非 Capacity。
2.2 Pod：最小编排与资源单元
Pod 是 Kubernetes 中可创建和部署的最小计算单元，包含一个或多个共享网络栈和存储卷的容器。Pod 的 资源请求（Requests） 与 资源限制（Limits） 是容量规划的核心输入。
- Requests：调度器依据此值选择节点，保证 Pod 获得最低资源保障。
- Limits：cgroup 层面限制 Pod 的资源使用上限，防止“吵闹邻居”效应。
- QoS 等级：根据 Requests 与 Limits 的配置关系，Pod 被分为 Guaranteed、Burstable、BestEffort 三类，直接影响节点压力过大时的驱逐顺序。
成本优化提示： 生产环境中建议为关键业务 Pod 设置 Requests = Limits（Guaranteed 等级），避免因资源超卖导致 OOM 或驱逐。对于批处理任务，可适当设置 Requests < Limits 以提高节点装箱率。
2.3 工作负载控制器：Deployment 与 StatefulSet
控制器负责确保集群中运行的 Pod 副本数符合期望状态。Deployment 和 StatefulSet 是最常用的两类控制器，它们的扩缩容行为存在本质差异。
| 特性 | Deployment | StatefulSet |
|---|---|---|
| Pod 标识 | 随机名称（无状态） | 有序、固定名称（有状态） |
| 扩缩容顺序 | 并行创建/删除 | 顺序创建（0→N）、逆序删除（N→0） |
| 存储卷 | 通常共享卷或临时卷 | 每个 Pod 独立 PVC（PersistentVolumeClaim） |
| 适用场景 | 无状态应用（Web、API） | 有状态应用（数据库、消息队列） |
| 扩缩容速度 | 快（并行） | 慢（串行，依赖存储挂载） |
容量规划差异： Deployment 的扩缩容主要受节点剩余 CPU/内存限制；StatefulSet 的扩缩容还需考虑 PVC 的创建速度、存储后端 IOPS 上限以及数据迁移成本。在成本优化场景中，StatefulSet 的缩容往往无法立即释放存储资源，需要配合 PVC 回收策略。
2.4 Service：稳定的网络访问抽象
Service 为一组动态变化的 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称，实现服务发现与负载均衡。Service 的类型决定了其对外暴露的方式与网络路径。
- ClusterIP：默认类型，仅在集群内部可达，适合内部微服务通信。
- NodePort：在每个 Worker 节点上开放静态端口，适合开发测试或非 HTTP 协议。
- LoadBalancer：对接云厂商 LB，自动分配公网 IP，适合生产对外服务。
- Headless Service：不分配 ClusterIP，直接返回 Pod IP 列表，适合 StatefulSet 的有状态访问。
Service 本身不消耗节点 CPU/内存，但其背后的 kube-proxy 组件（iptables/IPVS 模式）会占用一定的节点资源。当集群规模超过 1000 个 Service 时，iptables 规则更新延迟可能达到秒级，此时建议切换至 IPVS 模式。
2.5 核心概念与容量规划的关联总结
下表将上述核心概念与后续章节的容量规划、自动扩缩容、成本优化直接关联，帮助建立全局视角。
| 概念 | 与容量规划的直接关联 | 扩缩容影响因子 |
|---|---|---|
| Master 节点 | 控制面稳定性决定扩缩容指令能否及时下发 | etcd 性能、apiserver QPS |
| Worker 节点 | Allocatable 资源是 Pod 调度的硬边界 | 节点池大小、实例规格、预留策略 |
| Pod | Requests/Limits 决定节点装箱率与 QoS | 资源超卖比、驱逐优先级 |
| Deployment | 无状态应用可快速并行扩缩，成本弹性高 | HPA 指标、副本数上下限 |
| StatefulSet | 有状态应用扩缩受存储约束，成本释放滞后 | PVC 生命周期、存储 IOPS |
| Service | 网络层不直接消耗计算资源，但影响流量分布 | kube-proxy 模式、Service 数量 |
常见误区： 很多团队在容量规划时只关注 Worker 节点的 CPU/内存，忽略了 Master 节点在集群规模增长时的瓶颈。当集群节点数超过 500 时，etcd 的磁盘 IOPS 和 apiserver 的内存占用往往成为扩缩容延迟的首要因素。建议在规划阶段就将控制面资源纳入监控与预算。