K8s 多集群到底是「默认架构」还是「不得已的退路」：你的团队是主动多集群，还是被历史包袱推着走？

【背景】

做了 8 年 K8s 运维，今年带团队把一套 30+ 服务的线上平台从「单集群 18 节点」迁到了「同城双集群 + 跨域只读副本」，跑了半年，复盘下来一句话：多集群解决的是容量和故障域问题，但它把 80% 的复杂度从「节点层」转移到了「服务层」——服务发现、配置一致性、跨集群流量调度、数据库主从切换、CI/CD 矩阵、监控聚合，每一层都要重新设计。

我们踩过几个典型的坑：

1. 一个消费者组在两个集群各跑一份，offset 各自维护，重启后两边从不同位置继续消费，下游幂等表被打穿；
2. ConfigMap 改了主集群忘了同步副本集群，灰度流量切过去后行为不一致，排查了 3 小时；
3. Istio 的 ServiceEntry 跨集群配置漂移，同一个 FQDN 在两个控制面指向不同 endpoint，请求 502 概率性出现。

【常见分歧 / 三种做法】

• A. 默认单集群：能用一个集群解决就不拆，容量靠节点池弹性、故障靠反亲和 + PodDisruptionBudget。优点是运维心智简单、跨服务链路是「一跳」；缺点是单集群脑裂、控制面故障、节点池资源枯竭都是硬风险。
• B. 多集群 + 服务网格统一：Istio / Linkerd / Consul 做跨集群服务发现和 mTLS，业务无感。优点是故障域隔离彻底；缺点是控制面本身成了新的 SPOF，版本升级、CNI 一致性、网络策略对齐全是坑。
• C. 多集群 + 业务自适配：不引入网格，业务层自己做服务发现、配置中心、流量路由（Nacos / Consul / 自研）。优点是透明可控、调试链路短；缺点是每套业务都得重新实现一遍，跨团队一致性难保证。

【我的倾向与理由】

我倾向 A 为主、B 为辅：

• 单集群 + 合理的资源隔离（ResourceQuota / LimitRange / 节点池按业务线分）能覆盖 90% 的场景，且排障路径是单跳的；
• 多集群只在两种情况下值得上：① 合规/数据驻留要求（如不同地域必须独立集群），② 单集群容量确实打满且弹性无法满足（比如 GPU 集群、突发流量 10 倍级）；
• 如果一定要多集群，优先选 B（网格统一），但前提是团队有专人维护控制面版本，否则 C 看起来灵活，实际是每套业务各搞一套、长期维护成本更高。

核心判断标准：多集群的复杂度成本，必须大于它带来的故障域收益。很多团队把多集群当「默认架构」，其实是把历史包袱（机房、合规、容量）当成了技术选型。

【想听大家在什么场景下怎么选】

1. 你们线上是单集群还是多集群？节点规模多少？拆集群的最初动因是什么（合规 / 容量 / 故障域 / 历史原因）？
2. 跨集群服务发现你们用什么方案？Istio / Consul / Nacos / 自研？跨集群流量切换的 RTO 实测是多少？
3. 数据库 / 有状态服务在两个集群之间怎么同步？主从切换的 RPO 目标是多少？有没有实际触发过跨集群切换的演练？
4. 监控和日志聚合是「每个集群一套」还是「统一后端」？你们怎么保证跨集群 trace 不断链？
5. 你们有没有「从多集群退回到单集群」的案例？什么信号让你们决定合并？

想听一线的真实数据，不是 PPT 上的架构图。