3. Federation 核心概念:FederatedDeployment、FederatedService、ReplicaSchedulingPreference、OverridePolicy
KubeFed(Kubernetes Federation v2)通过一组 Federation 核心 API 将多个独立 Kubernetes 集群抽象为一个统一控制面。理解这些核心资源是掌握版本漂移治理的前提——它们决定了工作负载如何分发、服务如何暴露、副本如何调度以及如何针对不同集群进行差异化覆盖。
核心认知:Federation 并非创建一个“超级集群”,而是通过控制面在成员集群间同步资源。版本漂移治理正是利用这些同步机制,确保跨集群的 Deployment、Service 等资源版本保持一致。
3.1 FederatedDeployment:跨集群工作负载分发
FederatedDeployment 是 Federation 中最核心的工作负载资源。它封装了标准的 Deployment 定义,并附加了跨集群分发策略。
- 模板(Template):包含标准的 Deployment 规范(Pod 模板、副本数、镜像等),是跨集群同步的“黄金配置”。
- 放置策略(Placement):定义该 Deployment 应该被分发到哪些成员集群(通过 clusterSelector 或 clusterNames 指定)。
- 覆盖策略(Overrides):允许针对特定集群调整模板中的字段(如镜像标签、环境变量),用于处理集群间差异。
apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
name: app-frontend
namespace: production
spec:
template:
metadata:
labels:
app: frontend
spec:
replicas: 3
template:
spec:
containers:
- name: nginx
image: nginx:1.25.0
ports:
- containerPort: 80
placement:
clusters:
- name: cluster-01
- name: cluster-02
- name: cluster-03
overrides:
- clusterName: cluster-03
clusterOverrides:
- path: /spec/replicas
value: 5
- path: /spec/template/spec/containers/0/image
value: nginx:1.25.0-staging
版本漂移治理要点:FederatedDeployment 的 template 是版本基准。当需要升级镜像时,只需修改 template 中的 image 字段,Federation 控制面会自动将变更同步到所有成员集群。任何手动在成员集群上直接修改 Deployment 的行为,都会被 Federation 的“回拉”机制覆盖,从而防止版本漂移。
3.2 FederatedService:跨集群服务发现与暴露
FederatedService 负责将 Service 资源同步到多个集群,并结合 DNS 联邦(如 CoreDNS + kube-dns)实现跨集群的服务发现。
| 特性 | 说明 | 版本漂移关联 |
|---|---|---|
| 模板同步 | Service 的 spec(类型、端口、选择器)被同步到所有选定集群 | 确保跨集群的服务端口和选择器一致,避免因 Service 配置差异导致流量中断 |
| DNS 联邦 | 自动创建 servicedns 记录,格式为 <service>.<namespace>.svc.<federation-domain> |
客户端通过统一域名访问服务,无需关心后端 Pod 分布在哪个集群 |
| 健康检查 | Federation 控制面会监控成员集群中 Service 的 Endpoint 状态 | 当某个集群的 Service 版本异常(如 Pod 镜像不一致),可被快速检测 |
apiVersion: types.kubefed.io/v1beta1
kind: FederatedService
metadata:
name: app-frontend-svc
namespace: production
spec:
template:
spec:
selector:
app: frontend
ports:
- name: http
port: 80
targetPort: 80
type: ClusterIP
placement:
clusters:
- name: cluster-01
- name: cluster-02
注意:FederatedService 的 selector 必须与 FederatedDeployment 中 Pod 的 label 匹配。如果版本漂移导致某个集群的 Pod label 被修改,Federation 会尝试修复,但修复期间可能出现服务中断。
3.3 ReplicaSchedulingPreference:智能副本调度
ReplicaSchedulingPreference(RSP) 是 Federation 中用于跨集群副本数调度的策略资源。它解决了“每个集群应该运行多少个 Pod 副本”的问题,是版本漂移治理中控制副本分布的关键。
apiVersion: scheduling.kubefed.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: app-frontend-rsp
namespace: production
spec:
targetTemplate:
# 关联的 FederatedDeployment
apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
name: app-frontend
totalReplicas: 10
clusters:
cluster-01:
minReplicas: 2
maxReplicas: 8
weight: 6
cluster-02:
minReplicas: 1
maxReplicas: 5
weight: 3
cluster-03:
minReplicas: 0
maxReplicas: 2
weight: 1
rebalance: true # 当集群加入/离开时自动重新平衡
版本漂移治理价值:RSP 确保每个集群的副本数始终符合策略定义。当版本漂移导致某个集群的 Pod 被手动删除或扩缩容时,RSP 会检测到偏差并自动调整回目标副本数,从而维持跨集群的容量一致性。
3.4 OverridePolicy:集群差异化覆盖
OverridePolicy 允许 Federation 管理员针对特定集群覆盖 FederatedDeployment 或 FederatedService 模板中的字段。这是处理集群间差异(如不同硬件架构、不同网络插件、不同存储类)的核心机制。
| 覆盖类型 | 适用场景 | 版本漂移风险 |
|---|---|---|
| 镜像覆盖 | 集群使用不同镜像仓库(如私有 registry)或不同架构(arm64 vs amd64) | 低——覆盖是显式声明的,版本变更受控 |
| 环境变量覆盖 | 不同集群需要不同的配置参数(如数据库连接地址) | 中——需确保覆盖后的配置与全局版本兼容 |
| 资源配额覆盖 | 集群硬件规格不同,需要调整 CPU/内存限制 | 低——仅影响资源分配,不影响应用版本 |
| 副本数覆盖 | 集群容量不同,需要差异化副本数(与 RSP 配合) | 低——RSP 会进一步确保最终副本数符合策略 |
apiVersion: types.kubefed.io/v1beta1
kind: OverridePolicy
metadata:
name: app-frontend-override
namespace: production
spec:
overrideRules:
- clusterSelector:
matchLabels:
region: us-east
overrides:
- path: /spec/template/spec/containers/0/image
value: registry.us-east.example.com/nginx:1.25.0
- path: /spec/template/spec/containers/0/env/0
value:
name: DB_HOST
value: db.us-east.example.com
- clusterSelector:
matchLabels:
region: eu-west
overrides:
- path: /spec/template/spec/containers/0/image
value: registry.eu-west.example.com/nginx:1.25.0
- path: /spec/template/spec/containers/0/env/0
value:
name: DB_HOST
value: db.eu-west.example.com
版本漂移治理关键:OverridePolicy 必须与 FederatedDeployment 的 template 保持版本一致性。例如,当全局 template 中的镜像从
nginx:1.25.0 升级到 nginx:1.26.0 时,所有 OverridePolicy 中的镜像覆盖也需要同步更新。否则,被覆盖的集群将停留在旧版本,形成版本漂移。
3.5 核心资源关系总结
以下表格总结了四种核心资源在版本漂移治理中的角色与协作关系:
| 资源 | 主要职责 | 版本漂移治理角色 | 与其他资源的关系 |
|---|---|---|---|
| FederatedDeployment | 定义工作负载模板并分发到集群 | 版本基准——所有集群的 Deployment 必须与模板一致 | 被 RSP 引用;被 OverridePolicy 覆盖 |
| FederatedService | 同步 Service 并实现跨集群服务发现 | 服务版本一致性——确保端口、选择器跨集群统一 | 依赖 FederatedDeployment 的 Pod label |
| ReplicaSchedulingPreference | 跨集群副本数调度与平衡 | 容量一致性——自动纠正副本数漂移 | 关联 FederatedDeployment;可被 OverridePolicy 影响 |
| OverridePolicy | 针对特定集群的字段覆盖 | 差异化控制——显式声明集群差异,避免隐式漂移 | 作用于 FederatedDeployment 和 FederatedService |
实践建议:在版本漂移治理中,建议将 FederatedDeployment 的 template 作为“单一事实来源”(Single Source of Truth)。所有版本变更(如镜像升级)只修改 template,然后通过 Federation 同步到所有集群。OverridePolicy 仅用于处理无法避免的集群差异(如镜像仓库地址),且必须与 template 版本同步更新。