多集群治理与灾备切换 Hands-on
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
本文缩写（英文全称与中文含义）
| 缩写 | 英文全称／名称 | 中文含义 |
|---|---|---|
| API | Application Programming Interface | 应用程序编程接口 |
| CD | Continuous Delivery / Continuous Deployment | 持续交付／持续部署；是否自动上线取决于流程 |
| CIDR | Classless Inter-Domain Routing | 无类别域间路由，用于表示网段 |
| DNS | Domain Name System | 域名系统 |
| IAM | Identity and Access Management | 身份与访问管理 |
| ID | Identifier | 标识符 |
| KMS | Key Management Service | 密钥管理服务 |
| LB | Load Balancer | 负载均衡器 |
| PITR | Point-In-Time Recovery | 时间点恢复 |
| PVC | Persistent Volume Claim | 持久卷申领 |
| RPO | Recovery Point Objective | 恢复点目标，可接受的数据丢失时间范围 |
| RTO | Recovery Time Objective | 恢复时间目标，可接受的恢复耗时 |
| SA | Service Account | 服务账号，供程序或工作负载使用的身份 |
| TTL | Time To Live | 存活时间；具体指缓存有效期或记录过期时间 |
| TXT | Text record | DNS 文本记录；这是记录类型名 |
场景：两个独立预生产集群，A 主用/B 恢复验证；默认不做数据库双活。前置：两集群网络无 CIDR 冲突、Argo CD各自独立实例、受保护 Git、外部数据库恢复方案、各自云身份与可观测。
1. 分离故障域和所有权#
export CTX_A='REPLACE_STAGING_A'
export CTX_B='REPLACE_STAGING_B'
kubectl --context="$CTX_A" get nodes
kubectl --context="$CTX_B" get nodes每次命令显式 context；集群名/环境标签写进日志和指标。使用两个 Argo CD 实例避免把一个控制器故障扩散到两集群，两个 Application 指向不同 overlays 和各自本地 API Server。平台权限、KMS/云 SA、ExternalDNS TXT owner ID 独立；同一业务域名只由指定控制器/切流系统管理。
2. 给 B 部署隔离的恢复版本#
在部署仓库建 overlays/cluster-a、overlays/cluster-b，共同引用 Kustomize base。B 的差异至少包括：恢复数据库地址、独立 Secret、临时域名、禁止生产 worker/CronJob 消费、恢复专用云权限。
kubectl kustomize overlays/cluster-b > cluster-b.yaml
kubectl --context="$CTX_B" apply --dry-run=server -f cluster-b.yaml在 B 的 Argo CD 创建 Application，使用 Argo CD 篇模板，path=overlays/cluster-b，targetRevision 固定 commit。先 manual sync、禁止 prune；在网络和云 IAM 层阻断 B 的生产支付/队列入口，不能仅设置应用变量。
3. 恢复数据并验收#
- 根据应用选数据库原生复制/PITR，或 Velero恢复 PVC；不把对象恢复当数据恢复。
- 按恢复水位调整 B 的配置、SA trust、域名/证书、StorageClass 和 webhook 引用。
- 临时域名运行建单/查询/幂等验证，确认不会触发生产副作用。
- 记录实际 RPO（缺失数据时间/条数）和 RTO（宣布故障到完整业务恢复），与目标比较。
kubectl --context="$CTX_B" -n orders get deploy,pods,pvc,svc
kubectl --context="$CTX_B" -n orders get cronjob
kubectl --context="$CTX_B" -n orders get events --sort-by=.metadata.creationTimestamp4. 主备切换演练#
冻结有风险的发布→停止 A 的新写入/消费者→记录最终水位并 fencing A 的写权限→将 B 提升到可写→解除 B 的消费限制→验证业务→修改唯一入口的 DNS/LB 指向 B。每一步由对应负责人记录确认，写主未隔离不得继续。
DNS 操作使用既有 Route 53 或 Cloud DNS 的受控变更；提前降低 TTL，不保证客户端立即刷新，长连接和缓存需观测。切换不是同时让两个 ExternalDNS 抢同一个 record。
5. 回切与演练结束#
B 已产生写入后不能直接把 DNS 改回旧 A。先从 B 同步/恢复 A、追平并对账，再以同样 fencing 顺序切回；否则继续由 B 提供服务。Git revert 只恢复配置，不恢复数据。
验收：只有一个写主/队列消费者集合、两侧身份不越权、业务无重复副作用、RPO/RTO有证据。保留 B 最小必要容量与备份，按预算决定常驻/按需恢复；多区域并不自动等于灾备。
参考：多租户隔离、Argo 声明式配置。
可执行配套#
数据库强制单写者与回切 提供角色隔离、状态比较交换、实际对账查询和切换脚本；前置拓扑与不支持的故障场景均明确列出。