服务编排实现高可用主备自动切换，核心是系统自动决策“谁当主”“何时切”“怎么切”，依赖声明式配置、Leader Election、外部协调服务（ZooKeeper/etcd/Redis Sentinel）、VIP漂移及存储状态同步机制闭环执行。
服务编排实现高可用集群的主备自动切换，核心是把“谁当主”“何时切”“怎么切”这三个问题交给系统自动判断和执行，而不是人工干预。关键不在于堆组件，而在于机制是否闭环、动作是否可靠。
用声明式配置定义主备角色与切换策略
Kubernetes 原生不直接提供“主备”语义，但可通过组合资源达成效果：
- 用 StatefulSet 管理有状态服务（如数据库、消息队列），确保副本有序部署、网络标识稳定
- 通过 Headless Service + 自定义探针暴露每个 Pod 的健康状态，供上层协调器读取
- 在应用层或 Sidecar 中集成 Leader Election 客户端（如 client-go 的 resourcelock），在多个副本中竞争持有同一个 Lease 或 ConfigMap 锁
- 切换触发后，新主主动更新 Service 的 Endpoint 或修改 ConfigMap 中的主节点标识，下游服务据此重路由
依赖外部协调服务做分布式决策
当业务逻辑复杂或跨集群时，单靠 Kubernetes API 可能不够：
- ZooKeeper：利用临时顺序节点 + Watch 机制，首个成功创建 /leader 节点的服务成为主，其余为备；主宕机后节点自动删除，触发新一轮选举
- etcd：用 CompareAndSwap（CAS）操作争抢 leader key，配合 TTL 续租，失败方降级为只读备节点
- Redis Sentinel：监听 +switch-master 事件，收到通知后调用脚本更新本地配置、重启服务或调整流量入口
VIP 漂移与流量接管必须原子化
主备切换若只改应用状态，客户端仍可能连到旧主，导致请求失败：
- 在主节点上绑定 VIP（如
ip addr add 10.0.0.100/24 dev eth0），备节点不配置该 IP - 使用 Keepalived 或 kube-vip 监控主进程或健康端点，检测失败后秒级执行
ip addr del+ip addr add - 若使用 kube-vip，它会自动与 Kubernetes Service（类型为 LoadBalancer）联动，VIP 同时用于控制平面接入和业务流量入口
- 注意：ARP 刷新需配合 gratuitous ARP 广播，否则交换机缓存旧 MAC，造成短暂丢包
存储与状态同步不能滞后于切换
主备切换不是单纯换一个进程，而是换一套可写上下文：
- 共享存储（如 NFS、Ceph RBD）需配合 fencing 机制：切主前先确保旧主彻底离线（如 SSH 执行
systemctl stop app或 IPMI 断电），防止脑裂 - 若用本地存储，必须依赖应用层复制协议（如 MySQL Group Replication、etcd Raft），确保新主已同步最新日志才允许晋升
- 配置文件、证书、密钥等元数据应通过 GitOps（Argo CD）、ConfigMap 热更新或 etcd watch 实时同步，避免切换后配置不一致
不复杂但容易忽略
