2. Kubernetes 集群基础：集群架构、节点角色、Pod 调度原理、资源请求与限制
2.1 集群架构与节点角色
Kubernetes 集群采用 控制面（Control Plane） 与 工作节点（Worker Node） 分离的架构。控制面负责全局决策与集群状态管理，工作节点负责运行容器化应用。理解这一分层是进行故障域划分与容量规划的前提。
关键认知： 控制面组件（etcd、kube-apiserver、kube-controller-manager、kube-scheduler）的可用性直接决定集群的管控能力；工作节点的资源水位则决定 Pod 的实际运行容量。两者在故障域设计中应分别对待。
2.1.1 节点角色与组件清单
| 角色 | 核心组件 | 职责 | 故障域影响 |
|---|---|---|---|
| 控制面节点 | etcd, kube-apiserver, kube-controller-manager, kube-scheduler | 状态存储、API 网关、控制器循环、调度决策 | 需跨可用区部署奇数副本（3/5），etcd 写入多数派才成功 |
| 工作节点 | kubelet, kube-proxy, 容器运行时（containerd/CRI-O） | Pod 生命周期管理、网络代理、资源上报 | 按资源池划分故障域，单节点故障不影响集群 |
| 附加组件 | CoreDNS, kube-controller-manager 扩展, 监控/日志 Agent | 服务发现、存储卷管理、可观测性 | 通常作为 DaemonSet 或 Deployment 运行在工作节点 |
2.1.2 控制面与工作节点交互流程
下图展示了控制面与工作节点之间的核心通信路径，以及 Pod 调度与资源上报的闭环。
2.2 Pod 调度原理
Pod 是 Kubernetes 中最小的调度单元。调度器（kube-scheduler）通过一系列 过滤（Predicates） 与 打分（Priorities） 阶段，为每个待调度 Pod 选择最合适的工作节点。
2.2.1 调度两阶段模型
- 过滤阶段（Filtering）： 排除不满足 Pod 约束的节点。包括：资源不足、端口冲突、节点亲和性/反亲和性不匹配、污点容忍度检查等。
- 打分阶段（Scoring）： 对通过过滤的节点进行优先级排序。常用打分策略包括：资源余量（LeastRequestedPriority）、镜像局部性（ImageLocality）、节点亲和性权重等。
容量规划提示： 当集群出现容量突增时，调度器会优先选择资源余量最多的节点。如果所有节点资源余量均不足，Pod 将处于 Pending 状态。此时需要结合 Helm 水位预测提前扩容节点池。
2.2.2 调度约束与故障域的关系
| 调度约束类型 | 配置方式 | 故障域影响 |
|---|---|---|
| 节点亲和性（nodeAffinity） | requiredDuringScheduling / preferredDuringScheduling | 可将 Pod 固定到特定故障域（如可用区 A） |
| Pod 反亲和性（podAntiAffinity） | requiredDuringScheduling / preferredDuringScheduling | 确保同一应用的不同副本分布在不同的故障域 |
| 污点与容忍度（Taints & Tolerations） | kubectl taint node / tolerations 字段 | 隔离特殊硬件节点或标记故障域边界 |
| 拓扑分布约束（topologySpreadConstraints） | maxSkew / topologyKey | 强制 Pod 在故障域间均匀分布，避免热点 |
2.3 资源请求与限制
资源请求（Requests）与限制（Limits）是 Kubernetes 资源管理的基础，直接影响 Pod 调度决策与节点容量水位。
2.3.1 核心概念
- Requests（请求）： Pod 启动时向节点承诺的最低资源保障。调度器依据节点剩余可分配资源（Allocatable - Requests）决定是否调度。
- Limits（限制）： Pod 运行时不能超过的资源上限。CPU 是压缩资源（可限流），内存是非压缩资源（超限即 OOMKill）。
- QoS 等级： 由 Requests 与 Limits 的组合决定：
- Guaranteed： requests == limits（最高优先级，最不易被驱逐）
- Burstable： requests < limits（中等优先级）
- BestEffort： 未设置 requests 与 limits（最低优先级，节点压力时最先被驱逐）
2.3.2 资源请求与限制配置示例
apiVersion: v1
kind: Pod
metadata:
name: capacity-demo
spec:
containers:
- name: app
image: nginx:1.25
resources:
requests:
cpu: "500m" # 0.5 核
memory: "256Mi" # 256 MiB
limits:
cpu: "1000m" # 1 核
memory: "512Mi" # 512 MiB
容量规划陷阱： 许多团队只设置 Limits 而不设置 Requests，导致调度器无法准确评估节点剩余容量，造成节点过载。在 Helm 水位预测中，必须基于 Requests 计算节点容量占用，而非 Limits。
2.3.3 节点容量计算模型
节点可调度 Pod 数量受限于以下资源维度：
| 资源维度 | 计算公式 | 典型瓶颈 |
|---|---|---|
| CPU | floor( (NodeCPUAllocatable - 系统预留) / PodCPURequest ) | 高计算型应用 |
| 内存 | floor( (NodeMemoryAllocatable - 系统预留) / PodMemoryRequest ) | 内存密集型应用（Java、缓存） |
| Pod IP / 网卡 | 节点最大 Pod 数（由 CNI 插件决定） | 大规模微服务集群 |
| 本地存储（临时存储） | floor( (NodeEphemeralStorage - 预留) / PodEphemeralStorageRequest ) | 日志、临时文件写入频繁的应用 |
2.4 资源请求与节点水位的关系
下图展示了 Pod 资源请求如何影响节点容量水位，以及调度器如何根据水位做出决策。
2.5 本章小结
- 集群架构： 控制面与工作节点分离，控制面组件需跨故障域高可用部署。
- 节点角色： 控制面节点承载集群管控，工作节点承载业务 Pod，两者故障域策略不同。
- Pod 调度原理： 调度器通过过滤+打分两阶段选择节点，亲和性/反亲和性/拓扑分布约束用于故障域分布控制。
- 资源请求与限制： Requests 决定调度准入，Limits 决定运行时上限。容量规划必须基于 Requests 计算节点水位。
- 水位预测基础： 节点剩余容量 = Allocatable - Sum(Requests)。Helm 水位预测模型以此为基础，叠加突增系数进行时间序列预测。