高可用容器编排依赖设计原则而非资源堆砌，核心是服务冗余、跨故障域部署（如podantiaffinity+topologykey）、n+2实例策略、健康探针闭环（liveness/readinessprobe）、多集群联邦灾备及rto/rpo分级保障。
容器编排的高可用性不是靠堆资源实现的，而是靠设计原则驱动的冗余、可观测与自动响应能力。灾备策略也不是事后补救，而是从部署第一天就嵌入架构中的确定性保障机制。
服务冗余与故障域隔离
单点失效是高可用最大的敌人。必须让相同服务的多个实例分布在不同的物理节点、机架甚至可用区，避免共因故障。Kubernetes 中通过 Pod 反亲和性（podAntiAffinity）强制调度分散，配合 topologyKey: "topology.kubernetes.io/zone" 实现跨可用区部署。建议采用 “N+2” 实例策略——例如订单服务日常需 8 个 Pod，至少部署 10 个，并设置 maxUnavailable: 0 确保滚动更新期间不降级。
- 每个工作负载应明确标注 app 和 tier 标签，便于反亲和规则精准匹配
- etcd 集群必须为奇数节点（推荐 3 或 5），且各节点跨不同故障域部署
- APIServer 应配置多副本 + 负载均衡器前置，杜绝控制平面单点
健康检查与自动恢复闭环
容器是否“活着”不能只看进程在不在，而要看业务是否可服务。Docker 的 HEALTHCHECK 指令或 Kubernetes 的 livenessProbe 和 readinessProbe 是关键入口。探测路径必须真实反映业务状态，比如调用 /health 接口而非仅检查端口通断。
- start-period 要覆盖应用冷启动时间（如 Java 应用设为 60s），避免误杀
- failureThreshold 建议设为 3～5，兼顾灵敏度与抗抖动能力
- 探测失败后，Kubernetes 会先驱逐 Pod，再由 Deployment 控制器拉起新实例，整个过程无需人工干预
多集群灾备拓扑与智能切换
同城双活+异地容灾已成标配。单纯备份镜像或数据不够，要实现应用级秒级切换。借助 Karmada 或 Clusternet 等联邦控制器，可统一管理多地集群，并按策略同步 Deployment、Service、Ingress 等资源。
- 主集群异常时，通过 Prometheus 监控指标（如 5 分钟内 API 错误率 > 5%）触发 AlertManager 告警
- 告警联动自动化脚本，调用联邦 API 将流量权重从 100% 主集群切至 100% 备集群
- 数据同步需分层处理：配置类走 GitOps（Argo CD），状态类依赖分布式存储（如 Ceph RBD）或数据库主从复制
RTO/RPO 驱动的灾备分级实施
不同业务对恢复时间和数据丢失容忍度差异极大，灾备不能一刀切。金融核心交易系统 RTO ≤ 30 秒、RPO = 0；内部管理系统 RTO 可放宽至 15 分钟、RPO ≤ 5 分钟。
- 高 RTO/RPO 场景：采用定时快照 + 跨 AZ 备份，成本低、运维简单
- 中等要求场景：启用实时日志同步（如 Kafka + Flink CDC）+ 异步主从库
- 极致要求场景：双写模式（如 TiDB Multi-Region 或 Vitess 分片双活）+ Service Mesh 流量染色与灰度切换
