1. K8s集群架构概述：Master节点与Worker节点角色及核心组件
Kubernetes集群采用典型的主从（Master-Worker）分布式架构。Master节点负责集群的“大脑”决策与控制，Worker节点负责运行实际的应用负载。理解各节点角色及组件功能，是进行故障迁移与调度策略优化的基础。
1.1 节点角色与职责对比
| 节点类型 | 核心职责 | 关键组件 | 故障影响范围 |
|---|---|---|---|
| Master节点 | 集群控制面，负责API请求处理、调度决策、状态维护与控制器循环 | etcd、kube-apiserver、kube-scheduler、kube-controller-manager | 全局：Master宕机导致集群管理不可用，但已有Pod继续运行 |
| Worker节点 | 数据面，负责运行Pod容器、执行健康检查、维护网络规则 | kubelet、kube-proxy、容器运行时（如containerd） | 局部：节点宕机导致其上Pod不可用，需调度迁移 |
架构要点：Master节点通常部署为奇数个（3或5）形成高可用集群；Worker节点数量根据业务规模弹性扩展。故障迁移主要发生在Worker节点层面，但Master组件的稳定性直接影响调度决策的及时性。
1.2 核心组件功能详解
1.2.1 etcd — 集群状态存储
etcd是一个分布式、强一致性的键值存储系统，是Kubernetes集群的“数据库”。所有集群对象（Pod、Service、ConfigMap等）的声明状态都持久化存储在etcd中。
- 数据一致性：基于Raft共识算法，保证集群中所有etcd节点数据一致。
- 监听机制：支持Watch API，其他组件可通过监听etcd的变化实时感知集群状态变更。
- 故障影响：etcd集群不可用将导致整个Kubernetes控制面瘫痪，无法进行任何资源变更操作。
1.2.2 kube-apiserver — 集群入口网关
kube-apiserver是Kubernetes控制面的前端，所有对集群的操作请求（kubectl、Pod调度、控制器调用）都必须经过API Server。它负责认证、授权、准入控制以及RESTful API的暴露。
- 无状态设计：API Server本身不存储状态，所有数据读写都委托给etcd，便于水平扩展。
- 请求处理流程：认证 → 授权 → 准入控制 → 对象验证 → 持久化到etcd。
- 故障影响：API Server宕机后，kubectl命令、调度器、控制器均无法工作，但已有Pod不受影响。
1.2.3 kube-scheduler — 调度决策引擎
kube-scheduler负责为新创建的Pod选择最合适的Worker节点。调度决策直接影响集群资源利用率和应用性能，是故障迁移策略的核心执行者。
- 调度流程：过滤（Predicates）→ 打分（Priorities）→ 绑定（Bind）。
- 调度策略：支持节点亲和性、Pod亲和性/反亲和性、污点与容忍、资源请求与限制等。
- 故障影响：调度器宕机将导致新Pod无法被调度，但已调度Pod正常运行。
1.2.4 kube-controller-manager — 状态调节器
控制器管理器运行多个控制器进程，负责将集群的实际状态调节至用户声明的期望状态。每个控制器专注于一种资源类型。
| 控制器名称 | 核心功能 | 与故障迁移的关系 |
|---|---|---|
| Node Controller | 监控节点健康状态，检测节点宕机 | 触发Pod驱逐与迁移的起点 |
| Replication Controller | 确保Pod副本数符合期望 | 在Pod故障后创建替代Pod |
| Endpoint Controller | 维护Service与Pod的映射关系 | 故障迁移后更新服务端点 |
| Service Account Controller | 管理命名空间默认服务账户 | 间接影响Pod启动权限 |
1.2.5 kubelet — 节点代理
kubelet是运行在每个Worker节点上的核心代理，负责管理节点上的Pod生命周期。它接收来自API Server的PodSpec，确保容器按声明运行。
- 核心职责：Pod创建/删除、容器健康检查（liveness/readiness probe）、资源监控上报。
- 故障影响：kubelet宕机导致该节点上的Pod无法被管理，节点状态变为NotReady，触发控制器驱逐Pod。
1.2.6 kube-proxy — 网络代理
kube-proxy负责实现Service的抽象网络层，维护节点上的网络规则，确保集群内外的流量能够正确路由到后端Pod。
- 工作模式：iptables（默认）、IPVS、userspace。
- 核心功能：负载均衡、会话保持、Service发现。
- 故障影响：kube-proxy故障导致该节点上的Service网络规则失效，流量无法到达Pod。
1.3 集群组件交互架构
下图展示了Master节点与Worker节点之间各组件的通信关系与数据流向：
1.4 组件故障对集群的影响矩阵
在故障迁移与调度策略优化中，需要明确每个组件故障后的具体表现，以便制定针对性的容错方案：
| 故障组件 | 故障表现 | 自动恢复机制 | 对调度迁移的影响 |
|---|---|---|---|
| etcd（全部宕机） | 集群完全不可管理 | 需人工恢复数据或重建集群 | 调度器无法读取/写入状态 |
| kube-apiserver | 所有API请求失败 | 多副本负载均衡自动切换 | 调度器与控制器无法工作 |
| kube-scheduler | 新Pod处于Pending状态 | 多副本选举新Leader | 故障迁移无法触发新调度 |
| kube-controller-manager | 控制器循环停止 | 多副本选举新Leader | 节点宕机后Pod不会被驱逐 |
| kubelet | 节点状态变为NotReady | 需重启kubelet服务 | 触发Node Controller驱逐Pod |
| kube-proxy | Service网络规则失效 | 需重启kube-proxy | 迁移后Pod网络不可达 |
关键提示：在故障迁移场景中，kube-controller-manager 中的 Node Controller 是检测节点故障并触发Pod驱逐的起点；kube-scheduler 负责将驱逐的Pod重新调度到健康节点。这两个组件的稳定性直接决定了故障迁移的时效性与成功率。
1.5 调度决策流程与故障迁移触发链路
下图展示了从节点故障发生到Pod完成迁移的完整调度链路：
1.6 高可用部署建议
基于上述架构分析，在生产环境中进行故障迁移与调度优化时，应遵循以下部署原则：
- Master组件多副本：kube-apiserver、kube-scheduler、kube-controller-manager 均部署为多副本，通过Leader选举实现高可用。
- etcd集群奇数节点：至少3个etcd节点，保证Raft多数派可用，避免脑裂。
- Worker节点资源预留：每个Worker节点预留10%-20%的CPU/内存资源，用于故障迁移时的Pod快速调度。
- PodDisruptionBudget：为关键应用设置PDB，控制故障迁移时允许同时中断的Pod数量。
- 节点故障检测参数调优：调整kube-controller-manager的
--node-monitor-period和--node-eviction-rate参数，平衡故障检测速度与集群稳定性。