Deployment仅管理单集群内副本调度与滚动更新，无法实现跨集群高可用；需引入KubeFed、Submariner等额外控制平面，并配合多集群就绪的探针、镜像、Service暴露及Secret同步机制。
跨集群高可用不是 Deployment 能解决的事
Deployment 本身只管单个集群内的副本调度和滚动更新，它完全感知不到其他集群的存在。想让 Go 应用在多个 Kubernetes 集群之间自动 failover 或负载分摊，必须引入额外的控制平面——比如 Kubernetes Cluster Federation v2（KubeFed），或者更现代的替代方案如 Submariner + Service Topology + 自定义 DNS 路由。直接在多个集群里各自部署一个 Deployment 并起相同名字，不会产生任何跨集群协同效果；它们彼此隔离，流量也不会自动绕行。
Go 应用镜像和探针必须支持多集群就绪
跨集群容灾的前提是每个集群里的 Go 实例都“真实可用”，否则切过去也是 502。这就要求：
-
readinessProbe必须检查业务真实就绪状态，比如访问/health/ready接口，且该接口要验证数据库连接、下游依赖、本地缓存加载完成等 —— 不能只返回硬编码 200 -
livenessProbe要独立路径（如/health/live），避免因 readiness 暂时失败触发误重启 - Go 程序启动时需支持传入动态配置（如 region、cluster-id），并在日志和 metrics 中打标，方便后续定位故障集群
- 镜像必须是多架构兼容的（
linux/amd64和linux/arm64），因为不同云厂商或边缘集群的节点 CPU 架构可能不同
Service 暴露方式决定容灾粒度
单集群用 ClusterIP 或 LoadBalancer 就够了，但跨集群必须打破这个边界：
- 不要用各集群独立的
LoadBalancerService：公网 IP 不统一，DNS 切换延迟高，无法健康感知 - 推荐组合：
Headless Service+ExternalDNS+Global Load Balancer（如 Google Cloud 的Global External HTTP(S) Load Balancing或 AWS 的Global Accelerator） - 每个集群部署一个
EndpointSlice，由外部 LB 基于健康探测结果自动剔除异常集群的 endpoints - 如果用 KubeFed，需启用
MultiClusterService类型，并确保所有参与集群已注册到联邦控制平面
Secret 和 ConfigMap 同步是最大隐形坑
你改了一个集群的 mysql-secret，其他集群不会自动同步。手动同步极易出错，尤其密码类字段：
- 别把 Secret 写死在 YAML 里再
kubectl apply -f多次 —— base64 编码容易粘连、换行符错乱导致解码失败 - 生产环境必须用
external-secrets（如ExternalSecrets.io）对接 Vault / AWS Secrets Manager，让各集群从同一后端拉取密钥 - ConfigMap 中的 region-specific 配置（如
cache_ttl、retry_backoff_ms）要用helm template或kustomize的patchesStrategicMerge按集群注入，而不是靠环境变量覆盖 - 所有集群的 Go 应用启动命令中，必须显式指定
--cluster-name=us-east-1这类参数，避免配置逻辑混淆
跨集群高可用真正的复杂点不在 YAML 写多少，而在于健康信号怎么传、密钥怎么保一致、DNS 缓存怎么清、以及——当主集群网络分区时，你的 Go 应用是否会在两个集群同时接受写请求造成数据冲突。这些都不是加几个 replica 就能解决的。
