1. 多集群与Fleet治理全景
当业务从“一个能跑的 Kubernetes 集群”走向“多套环境、多个地域、多个团队共享的基础设施”时，单集群的边界会迅速暴露。单集群并不是技术缺陷，而是设计目标不同：它假设节点规模、故障域、租户数量和发布节奏都在可控范围内。一旦这些假设被打破，问题就不再是“集群能不能扩容”，而是“控制面爆炸半径、升级窗口、网络策略、配额与权限如何被治理”。多集群与 Fleet 治理，本质上是把“集群”从一台大机器，变成一组可被编排、观测、升级和审计的资源池。
为什么单集群不够
单集群最先遇到的不是性能瓶颈，而是故障域耦合。etcd 的 quorum、API Server 的负载、CNI 的地址空间、Ingress 的入口、CRD 的版本，全部共享同一套控制面。一次集群级升级、一次误删 CRD、一次网络插件滚动，都可能同时影响所有业务。其次是发布节奏冲突：支付团队需要每周两次灰度，风控团队要求变更冻结，基础设施团队要升级节点镜像，这些诉求在同一个集群里只能互相妥协。第三是合规与隔离：不同地域的数据驻留、不同租户的网络与 RBAC 边界，很难靠命名空间彻底解决。最后是规模上限：单集群的节点数、Pod 数、Service 数都有经验阈值，超过后调度延迟、etcd 写入放大、控制器队列积压会显著上升。
多集群的典型驱动力
生产中选择多集群，通常由以下驱动力触发，而不是为了“架构好看”：
- 故障隔离与爆炸半径控制：按业务域或地域拆分，单集群故障不扩散。
- 环境与发布隔离：dev/staging/prod 分集群，避免测试流量与生产互相干扰。
- 地域与数据驻留：用户就近接入，数据留在指定区域。
- 多租户与合规：不同团队、不同客户拥有独立控制面边界。
- 版本与升级节奏：先在小集群验证新版本，再逐步推广。
- 容量与成本：按业务峰谷在不同集群间调度，避免单集群长期超配。
这些驱动力往往同时存在，因此多集群不是“多建几个集群”那么简单，而是需要一套Fleet 层来统一治理。
Fleet 的概念边界
Fleet 可以理解为“集群的集群”：它不直接运行工作负载，而是管理一组 Kubernetes 集群的注册、标签、策略分发、应用部署与状态汇总。Fleet 的边界需要明确：
- Fleet 管集群，不管 Pod：它关注集群是否在线、版本是否合规、标签是否匹配、策略是否下发成功。
- Fleet 管分发，不管调度：它把应用或策略推到目标集群，具体调度仍由各集群的 kube-scheduler 完成。
- Fleet 管期望状态，不管运行时细节：它通过 GitOps 或声明式 API 表达“哪些集群应该有什么”，运行时差异由各集群控制器收敛。
- Fleet 需要可观测性闭环：没有集群状态、部署状态、策略合规状态的汇总，Fleet 就只是“批量 kubectl”。
常见的 Fleet 实现包括 Karmada、Cluster API、Argo CD ApplicationSet、Flux 多集群、Rancher Fleet 等。它们的能力侧重点不同，但治理目标一致：让集群成为可声明、可观测、可审计、可回滚的资源。
生产治理目标
多集群 Fleet 的生产治理，可以归纳为五个目标：
- 一致性：所有集群的基线配置（CNI、CSI、RBAC、策略）可声明、可校验。
- 可观测性：集群健康、应用部署、策略合规、资源水位集中可见。
- 可回滚：任何分发变更都能定位到具体集群、具体版本、具体时间。
- 安全边界：Fleet 控制面自身高可用，凭证最小权限，跨集群通信加密。
- 成本与容量：按标签和策略分配工作负载，避免资源碎片与长期超配。
这些目标不是一次性达成的，而是随着集群数量增长逐步补齐。下面这张图给出多集群与 Fleet 治理的全景关系：左侧是驱动力，中间是 Fleet 控制面，右侧是治理目标与反馈闭环。
课程实战地图
本课程围绕“多集群与 Fleet 生产实践与可靠性治理”展开，后续章节会沿着这条主线逐步深入：先建立 Fleet 的架构与集群注册模型，再进入策略分发、应用编排、状态汇总与故障排查，最后落到可靠性治理与成本优化。每一章都会给出可复现的示例参数、配置片段与判断依据，帮助你把“多集群”从概念变成可运行、可观测、可回滚的生产系统。