📚 课程目录第2章 Kubernetes多集群架构基础

2. Kubernetes多集群架构基础：集群联邦（KubeFed）原理、多集群服务网格、集群注册与生命周期管理

在进入跨集群调度与安全审计之前，必须建立对多集群架构的底层认知。本章聚焦三大核心支柱：集群联邦（KubeFed）、多集群服务网格以及集群注册与生命周期管理。这三者构成了跨集群调度与OPA门禁策略的物理与逻辑基础。

2.1 集群联邦（KubeFed）原理

KubeFed（Kubernetes Federation）是CNCF的早期孵化项目，旨在通过一个控制平面统一管理多个Kubernetes集群。其核心思想是“一次声明，多集群生效”。

2.1.1 核心架构组件

组件	角色	说明
Federation API	统一资源定义	定义跨集群的通用资源模板（如FederatedDeployment）
Federation Controller Manager	调度与同步引擎	监听Federation API变化，将资源分发到成员集群
Cluster Registry	集群信息存储	维护所有成员集群的Kubeconfig、状态、标签
DNS Controller	跨集群服务发现	自动生成跨集群的DNS记录（如`svc1.ns1.fed.example.com`）
Policy Engine	调度策略执行	决定资源应分发到哪些集群（可对接OPA）

2.1.2 资源分发流程

用户创建：在Host集群中创建FederatedDeployment资源，指定overrides和placement策略。
Controller Manager 监听：Federation Controller Manager 捕获资源变更事件。
策略评估：根据placement中的集群选择器（如region: us-east）或OPA策略，决定目标集群列表。
资源分发：将Deployment模板分发到每个选中的成员集群的对应命名空间。
状态聚合：各成员集群的Deployment状态回写到Host集群的FederatedDeployment Status中。

  关键设计原则： KubeFed采用“推模式”（Push Model），Host集群主动向成员集群推送资源。这种模式在成员集群数量较少（< 50）时表现良好，但大规模场景下需注意控制平面的性能瓶颈。

2.2 多集群服务网格

服务网格（如Istio、Linkerd）在多集群场景下解决了跨集群服务间通信的身份认证、流量管理、可观测性问题。与KubeFed的“资源分发”不同，服务网格关注的是“网络连通与安全”。

2.2.1 多集群服务网格的三种部署模式

模式	网络要求	控制平面	典型场景
扁平网络（Flat Network）	Pod CIDR 不重叠，可直接路由	共享一个控制平面	同机房、同VPC的多集群
跨网络（Multi-Network）	Pod CIDR 可重叠，需东西向网关	每个集群独立控制平面，通过Mesh Federation互联	跨地域、跨云厂商
主从模式（Primary-Remote）	Remote集群无控制平面，仅运行数据面	Primary集群控制平面管理Remote集群的Sidecar	边缘集群、轻量级集群

2.2.2 跨集群服务发现与流量路由

以Istio为例，多集群服务网格通过ServiceEntry和WorkloadEntry实现跨集群服务注册。每个集群的Pilot（控制面组件）通过Mesh Federation API交换服务端点信息。

# 示例：在集群A中定义集群B的服务
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: svc-b-from-cluster-a
spec:
  hosts:
  - svc-b.ns-b.global
  location: MESH_INTERNAL
  ports:
  - number: 8080
    name: http
    protocol: HTTP
  resolution: DNS
  endpoints:
  - address: 10.200.1.5   # 集群B中svc-b的ClusterIP
    labels:
      cluster: cluster-b

安全提示： 在多集群服务网格中，mTLS（双向TLS）必须跨集群启用。建议使用SPIFFE标准身份（如spiffe://cluster-b.local/ns/ns-b/sa/svc-b-sa）来确保跨集群调用的身份可信。OPA策略可以基于SPIFFE ID进行细粒度访问控制。

2.3 集群注册与生命周期管理

无论是KubeFed还是服务网格，都需要一个可靠的集群注册机制来管理集群的加入、更新、健康检查和移除。这是多集群架构的“基础设施层”。

2.3.1 集群注册的核心信息

字段	示例值	用途
Cluster Name	`prod-us-east-1`	全局唯一标识
API Server Endpoint	`https://api.prod-us-east-1.example.com:6443`	控制平面通信地址
CA Certificate	`-----BEGIN CERTIFICATE-----...`	TLS验证
Service Account	`eyJhbGciOiJSUzI1NiIs...`	身份认证（通常使用Bootstrap 或OIDC）
Labels	`region: us-east, env: prod, tier: critical`	调度与策略选择
Status	`Ready / NotReady / Unknown`	健康状态

2.3.2 生命周期状态机

一个典型的集群生命周期包含以下状态转换：

Pending：集群注册请求已提交，但尚未完成验证。
Joining：控制平面正在向目标集群推送初始配置（如命名空间、RBAC、ServiceAccount）。
Ready：集群健康检查通过，可以接收工作负载。
Updating：集群标签、证书或端点正在变更。
Draining：正在将工作负载迁移出该集群（用于计划内维护或退役）。
Removed：集群已从注册表中删除，所有资源已清理。

安全风险： 集群注册阶段是攻击者注入恶意集群的窗口期。必须对注册请求进行强身份验证（如使用预共享密钥或OIDC ），并在注册后立即执行集群准入审计（例如通过OPA检查集群的CA证书是否来自受信任的CA、集群标签是否符合规范）。

2.4 本章知识结构图

下图展示了KubeFed、服务网格与集群注册管理三者之间的协作关系，以及它们如何共同支撑跨集群调度与安全审计。

2.5 本章小结

KubeFed 提供“一次声明，多集群生效”的资源分发能力，其Placement策略是后续OPA门禁策略的天然集成点。
多集群服务网格 解决了跨集群服务间身份认证与流量管理问题，SPIFFE身份是OPA策略评估的关键输入。
集群注册与生命周期管理 是多集群架构的“准入第一关”，必须在注册阶段就引入安全审计，防止恶意集群混入。
三者共同构成了跨集群调度与安全审计的基础设施底座，后续章节将在此基础上构建具体的调度策略与OPA门禁规则。