Fleet多集群灰度发布准入与权限治理 - 第1节
1.1 Fleet 是什么
Fleet 是 Rancher 生态中面向大规模 Kubernetes 多集群环境的持续交付与 GitOps 引擎。它并非简单的应用分发工具，而是一套以“声明式管理”为核心、以“集群舰队”为管理单元的平台级组件。
Fleet 的核心设计理念可以概括为：
- GitOps 驱动：所有集群状态、应用版本、配置变更都以 Git 仓库为单一事实来源。
- 多集群统一：将成百上千个 Kubernetes 集群抽象为“舰队（Fleet）”，实现批量管理。
- 差异化部署：支持按集群标签、环境、区域等维度定义不同的部署策略。
- 准入与门禁：内置健康检查、资源验证、灰度发布准入控制，确保变更安全可控。
关键认知：Fleet 不是 CI/CD 工具链的替代品，而是位于 Git 仓库与多集群之间的“调度与准入层”。它负责将 CI 产出的制品安全、可控地分发到不同集群，并持续保证集群状态与 Git 一致。
1.2 Fleet 在云原生多集群管理中的角色
在云原生多集群管理体系中，Fleet 处于控制面与工作负载面之间的枢纽位置。下表清晰展示了 Fleet 与周边组件的关系：
| 层级 | 组件/工具 | Fleet 的角色 |
|---|---|---|
| 源码与 CI | GitHub / GitLab / Jenkins / Argo Workflows | Fleet 监听 Git 仓库变更，拉取最新 manifests |
| 制品仓库 | Harbor / Docker Hub / OCI Registry | Fleet 通过 Helm / Kustomize 引用制品，不直接存储 |
| 多集群控制面 | Rancher Manager / Fleet Controller | Fleet 是核心控制引擎，负责策略解析、准入检查、分发调度 |
| 工作集群 | Kubernetes 集群（生产/预发/测试/边缘） | Fleet Agent 在目标集群执行资源同步与状态上报 |
| 可观测性 | Prometheus / Grafana / Rancher Monitoring | Fleet 暴露集群状态、部署进度、健康指标 |
Fleet 在以下典型场景中扮演关键角色：
- 多环境灰度发布：从开发 → 测试 → 预发 → 生产，Fleet 按标签逐批推送。
- 边缘集群批量管理：数百个边缘站点统一纳管，Fleet 自动处理网络中断后的重试与回滚。
- 多租户隔离部署：不同团队共享同一套 Fleet 控制面，通过命名空间与 RBAC 实现隔离。
- 合规与准入门禁：在应用部署前执行 OPA/Kyverno 策略检查，不符合策略的变更被拒绝。
1.3 Fleet 核心组件与架构
Fleet 采用控制面 + Agent 的经典分布式架构。控制面运行在“管理中心集群”，Agent 运行在每个“工作集群”中。下面通过架构图直观展示各组件及其交互关系：
1.3.1 控制面组件详解
| 组件 | 职责 | 关键技术 |
|---|---|---|
| Fleet Controller | 核心协调器，监听 Git 仓库变更，解析 Fleet 资源定义（Bundle、ClusterGroup），驱动部署流程 | Kubernetes Controller 模式、Informer、WorkQueue |
| 策略引擎 | 加载 OPA/Kyverno 策略，对即将部署的资源进行合规性检查 | Rego 策略、Kyverno ClusterPolicy |
| 准入检查 | 在资源下发到工作集群前执行门禁检查（镜像签名、命名空间白名单、资源配额等） | Admission Webhook、ValidatingAdmissionPolicy |
| 集群状态存储 | 维护所有工作集群的实时状态、部署进度、健康度 | CRD（Cluster、ClusterGroup、Bundle）、Etcd |
| Fleet API Server | 对外暴露 REST API，供 Rancher UI、CLI、第三方系统集成 | Kubernetes API 扩展、Aggregation Layer |
1.3.2 工作集群组件详解
| 组件 | 职责 | 关键技术 |
|---|---|---|
| Fleet Agent | 与控制面建立长连接，接收部署指令，执行资源同步，上报状态 | gRPC Stream、WebSocket、Client-go |
| 资源同步器 | 将控制面下发的 manifests 应用到工作集群，处理 Helm Chart、Kustomize 等 | Helm SDK、Kustomize、Server-Side Apply |
| 本地状态缓存 | 缓存当前集群已部署的资源版本与状态，减少与控制面的频繁通信 | Local Informer、ConfigMap 存储 |
| 健康检查 | 定期检查工作集群节点、系统组件、关键应用的运行状态 | Node Health、Pod Ready、自定义 Probe |
1.3.3 核心资源模型
Fleet 通过以下 CRD 资源定义多集群部署模型：
- Cluster：代表一个注册到 Fleet 的工作集群，包含连接信息、标签、状态。
- ClusterGroup：将多个 Cluster 按标签选择器分组，用于批量部署。
- Bundle：定义要部署的应用内容（Helm Chart / 原生 YAML / Kustomize），以及目标集群组。
- BundleDeployment：Bundle 在单个集群上的实际部署实例，记录部署状态与历史。
架构要点：Fleet 的 CRD 设计遵循 Kubernetes 声明式 API 规范，所有资源都可以通过
kubectl apply 管理。这意味着你可以将 Fleet 资源本身也纳入 GitOps 流程，实现“管理平台的管理平台”。
1.4 Fleet 工作流程概览
下面通过第二个 SVG 图展示一次完整的部署流程，从 Git 提交到多集群生效：
重要提示：Fleet 的准入检查发生在步骤 3，即在资源分发到工作集群之前。这意味着不符合策略的变更会被拦截在控制面，不会污染任何工作集群。这是实现“门禁灰度发布”的关键机制，后续章节将深入讲解如何配置自定义准入规则。
1.5 本章小结
- Fleet 是 Rancher 生态的多集群 GitOps 引擎，以声明式方式管理大规模 Kubernetes 集群。
- 在云原生多集群管理体系中，Fleet 充当控制面与工作负载面之间的调度与准入层。
- 核心架构分为控制面（Controller、策略引擎、准入检查、状态存储、API Server）和工作集群（Agent、资源同步器、本地缓存、健康检查）两部分。
- 核心资源模型包括 Cluster、ClusterGroup、Bundle、BundleDeployment，全部以 CRD 形式管理。
- 部署流程为：Git 提交 → Controller 检测 → 准入检查 → 分发到集群组 → Agent 执行 → 状态反馈。