2. 多集群 K8s 基础：集群联邦、多集群管理工具与统一控制面设计
在镜像供应链安全巡检与容量瓶颈定位的场景中，单一集群的管理模式已无法满足大规模、跨地域、多环境的运维需求。多集群管理不仅需要解决资源调度与故障隔离问题，更要求安全策略与容量视图在控制面层面实现统一抽象。本章将围绕集群联邦（Federation）的核心概念、主流多集群管理工具（Karmada / Clusternet）的架构对比，以及统一控制面的设计原则展开。
2.1 集群联邦的核心模型
集群联邦的本质是将多个 Kubernetes 集群抽象为一个逻辑控制面，通过统一的 API 入口下发资源，由联邦控制面负责将资源分发到成员集群，并维持期望状态的一致性。其核心组件包括：
- 联邦 API 服务器：接收用户提交的联邦资源（如 FederatedDeployment），不直接调度 Pod，而是生成分发策略。
- 调度与分发引擎：根据资源配额、亲和性、地域分布等策略，将资源模板推送到目标成员集群。
- 状态收集器：从各成员集群拉取资源实际状态，聚合后反馈给联邦 API 服务器，用于状态回写与异常检测。
| 维度 | 单集群 K8s | 集群联邦（Federation） |
|---|---|---|
| 控制面范围 | 单个 API Server | 联邦 API Server + 多个成员集群 API Server |
| 资源抽象 | 原生 Deployment / Service | FederatedDeployment / FederatedService + 分发策略 |
| 安全策略生效范围 | 集群级 RBAC / NetworkPolicy | 联邦级策略 + 成员集群本地策略叠加 |
| 容量视图 | 单集群 Metrics Server | 聚合多集群资源用量，支持跨集群容量瓶颈定位 |
关键认知： 集群联邦不是简单的“多集群管理工具”，而是一种控制面水平扩展模式。镜像供应链安全巡检中的策略（如镜像签名验证、CVE 扫描准入）需要在联邦层定义，再下推至各成员集群，避免安全策略碎片化。
2.2 主流多集群管理工具：Karmada 与 Clusternet
当前社区中，Karmada（CNCF 孵化项目）与 Clusternet（由腾讯云开源）是两种具有代表性的多集群管理方案。两者在架构设计、资源分发模型、安全集成方面存在显著差异。
2.2.1 Karmada：以联邦 API 为核心
Karmada 继承了 Kubernetes Federation v2 的设计理念，强调声明式资源分发与策略与资源分离。用户通过 ResourceTemplate（资源模板）定义应用负载，通过 PropagationPolicy（分发策略）控制资源应分发到哪些集群。
- 资源模板：标准的 K8s 资源 YAML（如 Deployment），无需修改。
- 分发策略：支持集群标签选择、地域亲和、权重调度、差异化覆盖（OverridePolicy）。
- 状态聚合：通过 ResourceBinding 对象维护资源在成员集群中的状态，支持故障转移。
2.2.2 Clusternet：以边缘与异构集群为重心
Clusternet 更侧重于边缘计算场景与异构集群管理，其架构中引入了“超级集群（Super Cluster）”概念，通过代理模式将成员集群注册到中心控制面，支持从中心直接下发原生 K8s 资源，无需定义额外的联邦资源类型。
- 轻量级代理：成员集群中部署 clusternet-agent，与中心控制面建立反向连接，解决边缘集群无法暴露 API Server 的问题。
- 原生资源下发：用户可直接在中心集群创建 Deployment，Clusternet 自动将其调度到指定成员集群。
- 多租户与安全：支持基于 Shadow API Server 的租户隔离，适合多团队共享控制面。
| 对比维度 | Karmada | Clusternet |
|---|---|---|
| 资源抽象 | 联邦资源（FederatedDeployment）+ 分发策略 | 原生 K8s 资源 + 调度标签 |
| 网络模型 | 成员集群 API Server 需对联邦控制面可达 | 支持反向代理，边缘集群无需暴露 API Server |
| 策略灵活性 | 强（支持 OverridePolicy、ReplicaScheduling） | 中（依赖原生调度器 + 自定义调度器扩展） |
| 安全集成 | 联邦级 RBAC + 成员集群本地 RBAC 叠加 | Shadow API Server 租户隔离 + 原生 RBAC |
| 适用场景 | 大规模同构集群、统一安全策略管控 | 边缘集群、异构集群、弱网络环境 |
选型建议： 如果您的多集群环境以数据中心内同构集群为主，且需要精细化的安全策略下推（如镜像签名准入、Pod 安全标准），Karmada 的联邦资源模型更易与 OPA/Gatekeeper 集成。如果涉及边缘节点或网络受限的成员集群，Clusternet 的反向代理架构能显著降低网络暴露面。
2.3 统一控制面设计原则
无论是选择 Karmada 还是 Clusternet，构建统一控制面时需遵循以下设计原则，以确保镜像供应链安全巡检与容量瓶颈定位的可观测性与可管控性：
- 控制面与数据面分离：联邦控制面只负责策略编排与状态聚合，不参与实际的数据面流量转发。镜像扫描结果、CVE 报告等安全数据应通过控制面聚合，而非逐集群手动采集。
- 策略继承与覆盖：安全策略（如只允许使用已签名的镜像）应在联邦层定义，允许成员集群根据本地合规要求进行差异化覆盖（Override）。例如，生产集群强制签名验证，开发集群仅记录告警。
- 统一可观测性出口：所有成员集群的镜像拉取事件、节点磁盘使用率、镜像仓库缓存命中率等指标，应通过统一的可观测性管道（如 Prometheus + Thanos / VictoriaMetrics）汇聚到控制面，避免数据孤岛。
- 最小权限接入：联邦控制面与成员集群之间的认证凭证应使用短生命周期 或 mTLS，且仅授予读取资源状态、下发资源所需的 RBAC 权限，防止控制面被攻破后横向移动至成员集群。
2.4 统一控制面下的安全与容量数据流
在统一控制面架构中，镜像供应链安全巡检与容量瓶颈定位的数据流可抽象为以下步骤：
- 策略注入：安全运维人员在联邦控制面定义镜像准入策略（如只允许镜像 digest 与签名匹配的 Pod 运行），该策略通过分发机制下推至所有成员集群的 Admission Webhook。
- 镜像拉取事件采集：成员集群的 kubelet 在拉取镜像时，触发审计日志或事件，由集群内的 Agent（如 Falco / AuditSink）采集并上报至控制面的安全事件管道。
- 容量指标聚合：各成员集群的节点磁盘使用率、镜像缓存命中率、镜像拉取延迟等指标，通过 Prometheus Remote Write 写入控制面的 Thanos Receive，形成全局容量视图。
- 异常定位与告警：控制面中的巡检引擎（如自定义 Operator）定期扫描全局镜像仓库与成员集群的镜像使用情况，发现未签名镜像、过期 CVE 镜像或节点磁盘即将写满时，触发告警并自动生成工单。
常见陷阱： 在多集群环境中，镜像供应链安全策略的一致性是最大挑战。如果成员集群的 Admission Webhook 版本不一致，或安全策略未正确下推，可能导致部分集群绕过镜像签名校验。建议在联邦控制面中引入策略合规性巡检，定期对比各成员集群实际生效的策略与期望策略，发现偏差立即修复。