Kubernetes高可用核心是分层保障：控制平面冗余（3+master、etcd奇数节点、VIP负载均衡）、工作节点自动隔离与驱逐、Pod声明式自愈（Deployment/StatefulSet+健康探针）、网络存储镜像等配套稳态。
高可用架构结合 Kubernetes 实现容器高可用，核心不是堆机器，而是分层保障：控制平面不挂、工作节点可容错、Pod 自动恢复、网络与存储不拖后腿。关键在于把 Kubernetes 本身当成高可用系统来设计，而不是只靠它跑高可用应用。
控制平面必须冗余，且有可靠选主机制
单 master 是最大隐患。生产环境至少用 3 个 master 节点，组成 etcd 集群（3 或 5 节点），基于 Raft 算法保证数据强一致和自动选主。kube-apiserver 本身无状态，需前置负载均衡（如 HAProxy + Keepalived 提供 VIP），让客户端始终连一个稳定入口；kube-scheduler 和 kube-controller-manager 启动多个实例，靠内置领导者选举（leader election）机制自动选出活跃主控，其余待命。
- etcd 必须奇数节点，3 节点可容忍 1 台宕机；5 节点可容忍 2 台，但写入延迟上升，一般不盲目扩到 7+
- 避免将 etcd 与高负载业务混部；若资源有限，stacked 模式（etcd 与 apiserver 同节点）可接受，但要确保磁盘 I/O 稳定
- 所有 master 节点上的 kubelet、containerd 必须健康，否则组件起不来，整个控制面就断链
工作节点要能自动隔离与恢复
节点不是“永远在线”，而是“可被信任或被剔除”。kubelet 定期上报心跳，Node Controller 检测失联后将节点置为 NotReady，并触发驱逐逻辑。配合 PodDisruptionBudget（PDB）约束，确保关键应用在滚动更新或节点维护时，始终保有最小可用副本数。
- 为关键服务设置 topologySpreadConstraints，让副本分散在不同可用区或 rack，防止单点物理故障影响全部实例
- 使用 nodeSelector 或 affinity 配合 label（如 node-role.kubernetes.io/master=）控制 Pod 调度范围，避免误调度到不稳定的节点
- 配置 kubelet 的 --fail-swap-on=false（已弃用）或彻底关闭 swap，防止内存压力下 OOM 杀死关键组件
Pod 层要声明期望状态，交由控制器持续调谐
Kubernetes 的高可用本质是“声明式自愈”：你声明“我要 3 个 nginx 副本”，Deployment 控制器就不断检查实际数量，少了就拉起，多了就缩容，异常了就重建。这不是靠人工干预，而是控制循环（reconciliation loop）在后台持续运行。
- 用 Deployment 管理无状态服务，用 StatefulSet 管理有状态服务（如 Kafka、ZooKeeper），后者提供稳定网络标识和有序部署/扩缩
- 为 Pod 配置 livenessProbe 和 readinessProbe：前者决定是否重启容器，后者决定是否接入流量，两者缺一不可
- 避免裸写 Pod 清单——它不会被任何控制器管理，节点故障后不会自动重建
配套能力不能掉链子：网络、存储、镜像都要稳
再好的调度逻辑，卡在 CNI 插件启动失败、PV 绑定超时、镜像拉不到，一样不可用。高可用是端到端的事。
- CNI 插件（如 Calico、Cilium）需部署为 DaemonSet，每个节点自动注入；启用 IPAM 健康检查，避免地址池耗尽
- PV 应优先选用集群级存储（如 Ceph RBD、Longhorn、云厂商 CSI 驱动），避免依赖单节点本地路径（hostPath）
- 内网部署 Harbor 镜像仓库，所有 worker 节点配置镜像加速器指向它，既提速又规避外网抖动和限流
