📚 课程目录第2章 Kubernetes集群基础回顾

2. Kubernetes 集群基础回顾：节点角色、Pod调度、控制器模式、Helm与Chart基础

在深入 Helm 集群升级与故障域隔离设计之前，必须重新校准 Kubernetes 的核心抽象。本节将聚焦四个关键领域：节点角色与拓扑、Pod 调度机制、控制器模式以及 Helm 与 Chart 的基础结构。这些概念是后续节点迁移与容错策略的基石。

2.1 节点角色与拓扑结构

Kubernetes 集群由两类节点构成：控制平面节点（Control Plane） 与 工作节点（Worker Node）。控制平面负责集群状态管理与调度决策，工作节点负责运行容器化应用。

节点角色	核心组件	关键职责	故障影响范围
Control Plane	kube-apiserver, etcd, kube-scheduler, kube-controller-manager	API 请求处理、状态存储、调度决策、控制器循环	集群级（不可用则集群失能）
Worker Node	kubelet, kube-proxy, 容器运行时（containerd/CRI-O）	Pod 生命周期管理、网络代理、资源报告	节点级（仅影响本节点 Pod）

  关键认知： 在 Helm 升级场景中，工作节点的故障域隔离通常通过 节点亲和性（Node Affinity） 与 Pod 反亲和性（Pod Anti-Affinity） 实现。控制平面节点应部署在独立的物理或逻辑故障域中（如不同机架、不同可用区）。

2.2 Pod 调度机制

Pod 是 Kubernetes 中最小的调度单元。调度器（kube-scheduler）通过一系列 谓词（Predicates） 与 优先级（Priorities） 算法，为未调度的 Pod 选择最合适的节点。

2.2.1 调度流程

过滤阶段（Filtering）： 排除不满足 Pod 资源请求、端口冲突、节点污点（Taints）等条件的节点。
打分阶段（Scoring）： 对剩余节点按资源利用率、亲和性规则、拓扑分布约束进行加权评分。
绑定阶段（Binding）： 将 Pod 绑定到得分最高的节点，由 kubelet 负责启动。

2.2.2 调度约束与故障域隔离

调度约束类型	YAML 示例字段	故障域隔离用途
节点亲和性	`spec.affinity.nodeAffinity`	将 Pod 调度到特定标签的节点（如 `failure-domain.beta.kubernetes.io/zone: us-east-1a`）
Pod 反亲和性	`spec.affinity.podAntiAffinity`	避免同一应用的多个副本调度到同一节点或同一故障域
拓扑分布约束	`spec.topologySpreadConstraints`	强制 Pod 在拓扑域（如 zone、hostname）之间均匀分布
污点与容忍	`spec.tolerations`	将特定 Pod 调度到带有污点的节点（如专用 GPU 节点或控制平面节点）

实践建议： 在 Helm Chart 的 values.yaml 中暴露 topologySpreadConstraints 与 podAntiAffinity 参数，允许运维人员在升级时动态调整故障域隔离策略，无需修改 Chart 模板。

2.3 控制器模式

Kubernetes 的核心设计哲学是 声明式控制器模式。控制器通过 控制循环（Control Loop） 持续观察集群的当前状态，并与期望状态（Spec）进行对比，执行操作以弥合差异。

2.3.1 常见控制器类型

控制器	管理资源	升级容错特性
Deployment	ReplicaSet + Pod	支持滚动更新（RollingUpdate）、回滚（Rollback）、暂停（Pause）
StatefulSet	有状态 Pod（有序、稳定网络标识）	支持有序更新（OrderedReady）、分区更新（Partition）
DaemonSet	每个节点运行一个 Pod	支持滚动更新、节点选择器过滤
Job / CronJob	批处理任务	支持并行度控制、失败重试

2.3.2 控制循环示例（Deployment）

// 伪代码：Deployment 控制器循环
for {
    currentReplicas := getCurrentReplicas(deployment)
    desiredReplicas := deployment.Spec.Replicas
    if currentReplicas != desiredReplicas {
        scaleReplicaSet(deployment, desiredReplicas)
    }
    // 检查 ReplicaSet 中的 Pod 版本是否匹配
    if !isRolloutComplete(deployment) {
        performRollingUpdate(deployment)
    }
    time.Sleep(10 * time.Second)
}

注意： 在 Helm 升级过程中，控制器模式决定了 Pod 的替换策略。例如，Deployment 的 maxSurge 与 maxUnavailable 参数直接影响节点迁移时的容错能力。设置 maxUnavailable: 0 可以确保升级期间始终有足够的 Pod 提供服务。

2.4 Helm 与 Chart 基础

Helm 是 Kubernetes 的包管理器，它将 Kubernetes 资源定义打包为 Chart。Chart 是 Helm 的部署单元，包含模板、默认值、依赖关系与元数据。

2.4.1 Chart 目录结构

my-chart/
├── Chart.yaml          # 元数据：名称、版本、依赖
├── values.yaml         # 默认配置值
├── values.schema.json  # 可选：values 的 JSON Schema 校验
├── charts/             # 子 Chart 依赖（手动或通过 helm dependency）
├── templates/          # Go 模板文件，生成 Kubernetes 资源
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # 模板辅助函数
│   └── tests/          # 测试 Pod 模板
└── README.md

2.4.2 Helm 升级核心流程

渲染模板： Helm 将 values.yaml 与用户提供的 --set 参数合并，渲染 templates/ 目录下的 Go 模板。
生成 Release： 每个 helm install 或 helm upgrade 操作创建一个 Release 对象，记录版本号、配置与资源清单。
执行升级策略： Helm 根据 Chart 中定义的资源类型（如 Deployment、StatefulSet）调用 Kubernetes API 执行更新。
回滚支持： 通过 helm rollback 恢复到之前的 Release 版本，保留完整的配置历史。

2.5 关键概念关联

上述四个基础概念在 Helm 集群升级与故障域隔离设计中紧密关联：

节点角色 决定了哪些节点可以承载控制平面组件，哪些承载工作负载。故障域隔离策略必须区分这两类节点。
Pod 调度 通过亲和性与拓扑分布约束，将 Pod 分散到不同故障域，避免单点故障。
控制器模式 提供了滚动更新、回滚等机制，是 Helm 升级时实现零停机迁移的基础。
Helm Chart 将上述配置参数化，使得故障域隔离策略可以在不同环境间复用，并通过版本控制管理升级历史。