K8s 高可用（HA）的核心是通过多节点冗余和故障自动转移，确保控制平面与数据平面在节点故障时仍能稳定运行，主要依赖以下四大机制：

1. 控制平面高可用（核心）

控制平面是 K8s 的 “大脑”，需通过多节点部署避免单点故障，关键组件设计如下：

• etcd 集群：作为 K8s 的数据库，必须部署 3/5/7 个节点（奇数个，满足 Raft 协议多数派选举），单个节点故障不影响数据一致性，支持自动选主与数据同步。
• apiserver 集群：无状态组件，通过多实例部署（如 3 个）对外提供服务，前端搭配负载均衡器（如 Nginx、HAProxy）分发请求，避免单 apiserver 故障导致集群不可访问。
• controller-manager 与 scheduler：通过 “领导者选举” 机制（基于 etcd 锁）实现主从备份，同一时刻仅 1 个主实例工作，从实例监听主实例状态，主实例故障后自动选举新主，确保控制器逻辑与调度功能不中断。

2. 节点与容器高可用

• 节点故障自愈：kubelet 定期向 apiserver 上报节点状态，当节点失联（超过node-monitor-grace-period，默认 40s），controller-manager 的node-controller会将节点标记为 “NotReady”，并触发pod-eviction（驱逐节点上的非本地存储 Pod），随后 scheduler 将这些 Pod 重新调度到健康节点。
• Pod 故障自愈：通过控制器（如 Deployment、StatefulSet）管理 Pod，设置replicas（副本数）确保 Pod 始终维持期望数量。当某个 Pod 因容器崩溃、资源不足等原因终止时，控制器会自动创建新 Pod 替换故障实例。

3. 网络高可用

• Service 负载均衡：Service 通过标签（Label）关联一组 Pod，对外提供固定访问地址（ClusterIP/NodePort/LoadBalancer），并基于 “轮询” 或 “会话亲和” 策略将请求转发到健康 Pod。当后端 Pod 故障时，kube-proxy 会实时更新 iptables/ipvs 规则，剔除故障 Pod，避免请求转发到不可用实例。
• 网络插件冗余：主流网络插件（如 Calico、Flannel）支持节点间网络通信冗余，部分插件（如 Calico）通过 BGP 路由协议实现多路径转发，单个节点网络故障不影响整体集群网络连通性。

4. 存储高可用

• 持久化存储（PV/PVC）：依赖外部高可用存储系统（如 Ceph、GlusterFS、云厂商存储服务），PV 数据存储在分布式存储中，即使 Pod 所在节点故障，重新调度后的 Pod 仍能通过 PVC 挂载相同 PV，访问到完整数据，避免数据丢失。
• 本地存储高可用：对于需本地存储的场景（如 StatefulSet 搭配local-storage），可通过存储插件（如 OpenEBS）将本地磁盘聚合为分布式存储，或通过主从复制（如 MySQL 主从）实现数据冗余，确保本地存储数据不因节点故障丢失。