凌晨一点四十，手机震动。不是闹钟，是告警。某个核心集群的 apiserver 延迟飙到十几秒，etcd 的 WAL fsync 时间长得离谱。我爬起来开电脑，一边骂一边翻监控。奇怪的是——业务量并没有涨。
查了两个小时，真正的原因让人想摔键盘。不是流量，是半年前某团队悄悄在同一个集群里塞了一整套 CI runner，几千个短生命周期 Pod 像蝗虫一样反复创建销毁，把控制面磨得喘不过气。
那天之后我们才开始认真聊多集群。不是为了架构好看，纯粹是被逼的。
先问清楚为什么要多集群
说实话，这个问题问一百个团队，能问出八十种答案。隔离爆炸半径，一种。合规要求数据不出境，又一种。不同业务线要自己管发布节奏，第三种。还有纯粹历史遗留——收购来的公司自带一套集群，你总不能让人家明天就搬过来。
这些理由都成立。但有一种理由不成立：因为别人都在搞多集群。
我见过太多这种情况了。一个二十人的平台团队，业务规模其实一个集群绰绰有余，结果硬生生拆成六套，然后疲于奔命地维护六份监控、六份网络策略、六份证书轮换脚本。在这种环境里待过你就知道，光每年一次的证书过期，就能让整个团队熬个通宵。
先算一笔账：每多一个集群，运维复杂度不是加一，是乘。 跨集群的维度是两两组合往外冒的。
所以我的建议是先做减法。能塞进同一个集群的，就塞进去。命名空间加网络策略加资源配额加 RBAC，能挡住大部分隔离需求。真正需要独立集群的，通常是这几种：跨地域的低延迟要求、强监管下的物理隔离、以及单集群规模真顶到了天花板。
顺便说一句，单集群的容量比很多人想的大得多。官方那个五千节点是保守说法，社区里跑过万节点集群的案例并不少。当然，前提是 etcd 调优、控制器并发、节点心跳这些细节都照顾到了。
多集群不是一种东西而是好几种
这里有个特别容易踩的坑。大家嘴上都说多集群，其实说的根本不是一回事。
第一种是控制面联邦。Karmada、Open Cluster Management 这类，一个上层控制面把工作负载下发到成员集群，还能做多集群调度策略——按区域优先、按负载均衡。功能全，但概念多，团队得花时间吃透。
第二种是 GitOps 分发。Argo CD 的 ApplicationSet，或者 Flux 的多集群模式，本质上是把「哪个集群跑什么」写进 Git，剩下交给控制器去对齐。
第三种最土但最常见：一堆脚本加一张 Excel，手动 kubectl 到各个集群 apply。
我的看法是，这三种没有谁高谁低，但有个先后顺序不能乱。你得先把集群本身的生命周期管住，再谈工作负载怎么分发。
什么意思呢。很多团队一上来就选 Karmada，结果底下集群还是人肉建的，版本五花八门，kubelet 参数全不一样。这时候上层再优雅的调度策略都没用，因为底座是歪的。用 Cluster API 或者 Terraform 把集群创建这件事模板化、声明化，让每个新集群都由同一套参数生出来——这一步的收益，比纠结选哪个联邦方案大得多。
真正耗人的是看不见的那些东西
集群建起来了，负载也分发下去了。恭喜，苦日子才刚开始。
网络。跨集群服务发现是经典难题。集群 A 里的服务要调集群 B，DNS 怎么解析，流量怎么走，证书怎么互信。Submariner、Cilium Cluster Mesh、各种 east-west gateway，方案不少，每个都有自己的脾气。我踩过的坑是，测试环境两地三集群跑得好好的，上生产之后因为 MTU 没对齐，大包全丢，排查了整整两天。
身份和权限。每个集群一套 RBAC，五个集群就是五套。新人入职，你要去五个地方给他开权限。员工离职，你要去五个地方删账号。到这一步，统一 OIDC 对接上游 IdP 就不是可选项了，是必须。让集群只做鉴权，身份的事交给一个地方管。
可观测性。每个集群一套 Prometheus，然后呢？你想在 Grafana 上看全局视图，得先解决数据怎么汇总。Thanos、VictoriaMetrics、Mimir，挑一个。注意别把查询压力全压到单个集群上。
还有最阴的一个，配置漂移。三个月前两个集群的 CoreDNS 配置还一模一样，今天你发现其中一个多了三行没人记得的改动。谁改的？不知道。为什么改？没人记得。这就是为什么 GitOps 的强约束这么重要——任何直接 kubectl edit 的行为，都该被当成事故来对待。
如果你现在就要动手
列一下我建议的顺序。不一定适合所有场景，但大多数团队照着走不会太偏。
第一步，做一份清单。 哪个团队、哪个应用、跑在哪个集群、为什么在这个集群。写不出来的，说明你其实不需要这么多集群。
第二步，统一集群的创建方式。 哪怕只是把 kubeadm 参数写进仓库里的一个模板。
第三步，把所有 YAML 收进 Git，用 Argo CD 或 Flux 管起来。 这一步会暴露大量历史债务，做好心理准备。
第四步，定命名空间和 label 规范。 别小看这个，跨集群的查询、策略、账单分摊全靠它。
第五步，挑一个无状态服务先搬。 别一上来就迁数据库。用一个小服务把整条链路走通，网络、监控、发布、回滚，一个都不能少。
多集群管理这事，没有一步到位的方案。你会经历一段混乱期，会有人抱怨，会有集群被遗忘在角落里没人管。这都正常。重要的是别为了追求架构的纯粹，把团队拖进无止境的搬运工作里。
毕竟集群是给人用的。人要累垮了，再优雅的架构也是负债。