阶段四 · 人与规模:平台与多集群

多集群与多云治理

一句话总结

当一个集群不够用(容灾, 合规, 规模, 多云), 就进入了多集群世界. 这里有两类工具各管一面: Cluster API 把"创建和管理集群本身"变成声明式(集群也是被 K8s 管理的资源), Karmada 等则把"应用如何分发到多个集群"统一编排. 它们让我们"像管一个集群一样管一片集群"--但也转移来一整层新的复杂度.

前置回顾

第 01 篇四个进阶方向里的最后一个, 也是"抽象层上移"主线的又一例: 把"单个集群"抽象成"一片集群". 前面所有 K8s 相关内容都默认"一个集群", 但生产到了一定规模, 单集群会撞上天花板. 本篇是阶段四的第二块, 也是把"规模与复杂度"这个主题推到极致--下一篇(08)就回到第 01 篇, 收束整个系列.

为什么一个集群会不够用

单集群能解决绝大多数问题, 但当业务长大, 几种力量会逼我们走向多集群:

驱动力 为什么单集群不够
容灾 / 高可用 一个集群是一个故障域--集群级故障(控制平面挂, 网络分区, 整个可用区宕)会让里面所有服务一起趴窝. 多集群跨可用区/地域, 鸡蛋不放一个篮子
合规 / 数据主权 数据必须留在特定地域(如 GDPR, 国内数据不出境)→ 不同地域各一个集群
规模上限 单集群的节点数, Pod 数有实际上限(etcd, 控制平面压力); 超大规模必须拆分
多云 / 混合云 不想被单一云绑定, 或自建机房+公有云混用 → 天然就是多个集群
隔离 强隔离需求(生产/测试, 不同业务线, 不同租户)用独立集群比命名空间更彻底

延续第 01 篇的理性: 多集群显著增加复杂度--跨集群网络, 跨集群服务发现, 配置一致性, 统一可观测, 运维负担全部翻倍甚至更多. 能用单集群(靠命名空间, 节点池, 多租户隔离)解决的, 就别上多集群.

多集群是被容灾, 合规, 规模这些硬约束逼出来的, 不是"看起来更厉害"的选择. 很多团队为了"高可用"上了多集群, 结果跨集群的复杂度本身成了新的故障源. 先确认真的撞到了单集群的硬墙.

多集群的两个独立问题

"管理多集群"其实是两个不同的问题, 容易混为一谈, 但由不同工具解决:

问题一: 集群本身怎么来, 怎么管?         问题二: 应用怎么分发到多个集群?
  ┌──────────────────────────┐         ┌──────────────────────────┐
  │ 创建/升级/销毁集群        │         │ 这个应用部署到哪几个集群?  │
  │ 让集群配置一致, 可复现    │         │ 副本怎么分布? 故障了怎么迁移?│
  │ → Cluster API            │         │ → Karmada / 多集群编排     │
  └──────────────────────────┘         └──────────────────────────┘
   "管集群的生命周期"                     "管应用的跨集群调度"

分清这两个问题, 是理解多集群工具生态的钥匙. 下面分别看.

Cluster API: 把"集群"也变成声明式资源

Cluster API(CAPI) 解决问题一. 它的核心思想优雅得让人会心一笑: 用 Kubernetes 的方式来管理 Kubernetes 集群本身--把"一个集群"也变成一个用 YAML 声明, 由控制器调谐的资源.

# 用声明式 YAML 描述"我要一个什么样的集群"
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: prod-cluster-tokyo
spec:
  # ... 集群规格: 控制平面几个节点, worker 几个, 用什么基础设施(AWS/裸机/...)
# 提交后, Cluster API 的控制器自动去: 开机器, 装 K8s, 组装成集群
# 想升级? 改 YAML. 想销毁? 删资源. 集群的生命周期 = 声明式管理

回想 GitOps(CI/CD 第 05 篇), IaC 与 Crossplane(CI/CD 第 08 篇)的主线: 用声明式代码描述期望状态, 让控制器去达成. Cluster API 把这套思想应用到了 K8s 自己身上--集群不再是手工 kubeadm 一台台搭出来的雪花, 而是可声明, 可复现, 可版本化的资源.

甚至可以把集群定义放进 Git, 用 GitOps 来管集群(集群也能"git revert"). 用 K8s 管 K8s, 这种递归正是云原生设计美感的极致体现.

它直接解决了多集群的一大痛点: 怎么快速, 一致地造出几十个长得一样的集群--手工搭十个集群会搭出十个微妙不同的"雪花", Cluster API 让它们从同一份声明里诞生, 完全一致, 可批量管理.

Karmada: 把应用编排到多个集群

Karmada(及类似的多集群编排方案)解决问题二: 集群有了, 应用怎么跨集群部署和调度. 它在多个集群之上架一个"控制平面", 像对单个集群那样下发应用, 由它负责分发:

  • 统一入口: 对 Karmada 的控制平面提交一个 Deployment, 它按策略把工作负载分发到多个成员集群.
  • 分发策略: 声明"这个应用部署到东京和法兰克福两个集群, 各 3 副本""按权重/地域分布".
  • 故障转移: 某个集群挂了, 把它上面的工作负载自动迁移到健康集群.
┌──────────────────────────┐
│ 提交一个应用 + 分发策略    │
└──────────────────────────┘
            │
            ▼
┌──────────────────────────┐
│ Karmada 控制平面          │
│ (多集群编排层)            │
└──────────────────────────┘
       │         │         │
       ▼         ▼         ▼
   集群 A     集群 B     集群 C
  (东京)    (法兰克福)   (本地)
  3 副本     3 副本      按需

多集群/多云还常牵涉到云上的非 K8s 资源(数据库, 对象存储, 负载均衡). Crossplane(CI/CD 第 08 篇见过)在这里登场: 它让我们用 K8s 的方式声明和管理云资源, 把"建一个云数据库"也变成 kubectl apply 一个资源.

于是应用, 集群(Cluster API), 云资源(Crossplane)统一在同一套声明式控制平面下. 三者拼起来, 就是"用 K8s 这一套范式管理整个多云基础设施"的愿景. 它们共享同一个内核--声明式 + 控制器调谐.

多集群真正难的不是工具, 是这些

工具(Cluster API, Karmada)解决了"怎么造集群, 怎么分发应用", 但多集群最棘手的复杂度其实在别处, 引入前必须想清:

难点 为什么棘手
跨集群网络 不同集群的 Pod 怎么互通?(回到网络存储篇的难题, 只是跨集群更难, 常需服务网格或专门方案)
跨集群服务发现 A 集群的服务怎么找到 B 集群的服务? DNS, 流量路由都要打通
配置一致性 几十个集群, 怎么保证它们的配置, 策略, 版本一致不漂移?(GitOps 在此关键)
统一可观测 指标/日志/追踪散在多个集群, 要聚合成一个全局视图(可观测性系列的多集群版)

注意到了吗--多集群的难点, 几乎是把本系列乃至整个云原生学习路径的每个主题(网络, 服务发现, 配置管理, 可观测, GitOps)在"跨集群"这个更高维度上重新提了一遍. 这也说明为什么多集群是"进阶中的进阶": 它要求前面所有的地基都足够扎实.

这正是把它放在全系列倒数第二篇的原因--它是对整个云原生知识体系的综合考验.

快速回顾

  • 走向多集群的硬约束: 容灾(单集群是一个故障域), 合规/数据主权, 规模上限, 多云, 强隔离
  • 先泼冷水: 多集群是"不得已"而非"更高级", 复杂度翻倍; 能用单集群+命名空间/多租户解决就别上
  • 两个独立问题: 1. 集群本身怎么造和管(Cluster API) 2. 应用怎么分发到多集群(Karmada)
  • Cluster API: 用 K8s 的方式管理 K8s 集群本身, 集群变成声明式资源(可复现, 可批量, 可 GitOps)--声明式思想的自我应用
  • Karmada: 多集群上架一层编排控制平面, 统一下发应用, 按策略分发, 故障自动转移; Crossplane 再把云资源也纳入声明式
  • 真正的难点不在工具, 而在跨集群网络/服务发现/配置一致/统一可观测--是对整个云原生知识体系的综合考验

为了高可用, 是不是应该尽早上多集群?

恰恰要警惕这个冲动. 高可用有多个层次, 多集群是最重, 最后才考虑的那一层. 在上多集群之前, 先确认已经做好了更便宜的高可用措施:

  1. 单集群内跨可用区部署节点(很多云的托管 K8s 默认就跨 AZ, 已经能扛单可用区故障)
  2. 应用多副本 + 反亲和(Pod 分散在不同节点/可用区)
  3. 完善的备份与恢复(网络存储第 08 篇)

这些做好了, 单集群已经相当健壮. 只有当需要扛"整个集群级"或"整个地域级"的故障时, 多集群才是必要的--而那时它转移来的复杂度, 也得有能力扛住. 别用多集群的复杂度, 去解决一个多副本就能解决的问题.

多集群和服务网格(Istio)是什么关系?

互补, 且服务网格常是多集群"跨集群通信"难题的解法之一. 多集群编排(Karmada)解决"应用部署到哪些集群", 但"A 集群的服务怎么安全地调用 B 集群的服务"(跨集群的服务发现, 流量路由, mTLS 加密)是另一个问题--服务网格的多集群模式(如 Istio multi-cluster)正是干这个的: 它把多个集群的服务连成一个统一的网格, 跨集群调用就像同集群一样, 还带加密和可观测.

所以成熟的多集群方案里, 常常是"Cluster API 管集群 + Karmada 管应用分发 + 服务网格管跨集群通信", 各司其职. 这也再次印证多集群是"多个主题叠加"的综合工程.

动手练习

  1. 评估真实需求: 诚实评估: 当前系统用单集群有没有撞到天花板? 如果有, 是上面五个驱动力中的哪一个? 如果没有, 那多集群还不是真需求.
  2. 声明式创建集群: 用 Cluster API 的 Docker provider 在本地"声明式地创建一个集群", 感受"集群也是一个 kubectl apply 出来的资源".
  3. 工具分类: 对照"两个独立问题", 把听说过的多集群工具各自归类: 它是管"集群生命周期"还是"应用分发"?
  4. 难点溯源: 列出"跨集群网络/服务发现/配置一致/统一可观测"这四个难点, 对应回本系列(或整个学习路径)的哪些篇章--体会多集群是综合考验.
  5. 轻量高可用方案: 针对一个"想做高可用"的诉求, 先写出不上多集群的三种更轻方案(跨 AZ, 多副本反亲和, 备份), 判断它们够不够, 再决定是否真需要多集群.