云原生高可用核心是“故障可预期、恢复可声明、状态可收敛”，需控制平面、数据层、服务层、基础设施四层协同：控制平面多节点冗余（API Server≥3副本、etcd奇数跨AZ、Scheduler/CM启用leader-elect）；数据层有状态服务自动容灾（Patroni+etcd、Nacos Raft集群、Redis哨兵或Cluster）；服务层Pod反亲和打散、探针合理配置、Ingress主动健康检查；基础设施层选BGP/eBPF网络插件、拓扑感知存储、节点taint与PDB保障容错。
云原生环境下的高可用配置，核心不是堆机器，而是让系统具备“故障可预期、恢复可声明、状态可收敛”的能力。关键在于控制平面、数据层、服务层和基础设施四者协同，缺一不可。
控制平面高可用：避免单点调度失效
Kubernetes 控制平面必须多节点部署，且各组件需按角色冗余：
- API Server：无状态，可水平扩展，建议至少3副本，前置负载均衡（如 Nginx 或云厂商 NLB），启用 --enable-admission-plugins 中的 PodDisruptionBudget 和 NamespaceLifecycle
- etcd：必须奇数节点（3/5/7），跨可用区部署；生产环境强烈推荐外置 etcd 集群（非容器内嵌），使用 TLS 双向认证 + 定期快照 + WAL 归档；禁用 etcd 的 --auto-compaction-retention 避免误删历史版本
- Scheduler 与 Controller Manager：启用 leader-elect，确保仅一个实例主控；通过 --lock-object-name 指定唯一租约对象，避免脑裂
数据层高可用：有状态服务不能靠重启解决
数据库、缓存等有状态组件必须脱离“单主+人工备库”模式：
-
PostgreSQL：用 Patroni + etcd 实现自动选主，同步复制至少保障 1 个 standby 处于
sync状态；通过pg_stat_replication持续校验流复制健康度 -
Nacos：严格采用 ≥3 节点集群，禁用单机启动模式；配置
cluster.conf明确各节点 IP+端口，启用raft协议而非默认的standalone；所有客户端连接必须指向 VIP 或 DNS 轮询地址，而非直连某节点 - Redis：哨兵模式需 ≥3 哨兵实例（跨节点部署），主从切换后自动更新服务发现注册信息；若用 Redis Cluster，确保每个分片至少含 1 主 2 从，且 failover 由 cluster bus 自动触发
服务层高可用：流量与实例双维度防护
应用本身要适配弹性环境，不能只靠 Kubernetes 做兜底：
-
Pod 级冗余：关键服务副本数 ≥3，并配置 podAntiAffinity，按
topology.kubernetes.io/zone反亲和，强制打散到不同可用区 - 就绪与存活探针：livenessProbe 不应检查外部依赖（如 DB 连通性），否则可能误杀；readinessProbe 可检查 DB 连接池是否就绪，但超时时间需大于连接池初始化耗时
- Ingress 流量治理：Nginx Ingress Controller 多副本 + EndpointSlice 支持；配合 service-upstream-check 启用主动健康检查，自动摘除异常 Pod 后端
基础设施层高可用：网络与存储不拖后腿
再好的上层设计，也架不住底层链路不稳定：
-
网络插件选型：跨 AZ 场景优先选 Calico BGP 模式（零封装损耗），但需网络团队开通 BGP Peer；若无法协调，改用 Cilium eBPF 模式，开启
hostServices.enabled=true避免 NodePort 性能瓶颈 - 存储可靠性：StatefulSet 使用支持拓扑感知的 CSI 驱动（如 EBS CSI、Ceph RBD）；PVC 必须设置 volumeBindingMode: WaitForFirstConsumer，确保 Pod 调度到目标 zone 后再绑定 PV
-
节点容错：为 Worker 节点配置 taints（如
node.kubernetes.io/unreachable:NoExecute），配合 PodDisruptionBudget 控制滚动更新时最大不可用数
