8.3 多集群管理 - 杨晓明的Study空间

本章目标

当你第一次接触 Kubernetes 时，往往会默认“一家公司一个集群”。但真正进入生产后，你会很快发现：单集群并不是万能答案。学完这一章，你应该能理解：

为什么会出现多集群需求
多集群常见的组织形态有哪些
如何做统一发布、统一观测与统一权限管理
多集群体系真正难的地方到底是什么

1. 为什么会出现多集群需求

Kubernetes 的 Service、调度和资源管理天然是围绕“单集群边界”设计的。SIG Multicluster 文档明确指出，传统 Service 概念默认只在单个集群内部成立，而 Multi-cluster Services API 则是在“跨多个集群延伸 Service 语义”这一背景下提出的::cite[348].

换句话说，单集群天然有边界，而业务一旦跨过这些边界，多集群就会变成现实需求。

1.1 常见驱动因素

Google Cloud 的多集群服务文档把这些动因说得很清楚：企业常常因为状态管理、隐私、可扩展性、可用性以及数据主权等要求，不得不把应用拆分到多个集群中运行::cite[204].

把这些场景翻译成更接地气的话，大致就是：

一套集群装不下所有业务
不同环境不能混在一起
不同区域要就近接入
不同业务线要彼此隔离
监管与合规要求数据留在指定地区

1.2 为什么不是“把单集群做大”就行

单集群做大当然可以解决一部分问题，但它解决不了下面这些矛盾：

问题	单集群的局限
环境隔离	测试、预发、生产共享控制面，爆炸半径过大
区域部署	单集群跨地域延迟高、网络复杂
合规治理	数据可能不能跨境或跨区域流动
团队自治	各业务线升级节奏、准入策略、插件栈不同
集群生命周期	某一类工作负载希望独立扩缩、独立升级

所以，多集群不是“炫技”，而是单集群边界被现实业务打破后的自然结果。

2. 多集群的常见形态：环境隔离、地域分布与业务隔离

多集群并不是只有一种模式。更准确地说，它是一组组织方式。

2.1 形态一：按环境隔离

这是最常见、也最容易理解的一类：

dev 集群
test 集群
staging 集群
prod 集群

优点：

变更风险隔离明显
环境权限清晰
配置漂移更容易管理

缺点：

环境越多，发布链路越复杂
工具链、镜像、策略需要统一抽象

一个典型的 kubeconfig 组织方式如下：

apiVersion: v1
kind: Config
clusters:
  - name: dev-cluster
    cluster:
      server: https://api.dev.example.com:6443
      certificate-authority-data: <base64-ca>
  - name: staging-cluster
    cluster:
      server: https://api.staging.example.com:6443
      certificate-authority-data: <base64-ca>
  - name: prod-cluster
    cluster:
      server: https://api.prod.example.com:6443
      certificate-authority-data: <base64-ca>
users:
  - name: platform-admin
    user:
      token: <token>
contexts:
  - name: dev
    context:
      cluster: dev-cluster
      user: platform-admin
  - name: staging
    context:
      cluster: staging-cluster
      user: platform-admin
  - name: prod
    context:
      cluster: prod-cluster
      user: platform-admin
current-context: dev

2.2 形态二：按地域分布

如果你的用户分布在多个国家或区域，多集群往往会按地域建设，例如：

华东集群
华北集群
新加坡集群
法兰克福集群

GKE 的多集群文档提到，跨集群部署的一大原因就是可用性和数据主权要求::cite[204].

这种模式常见目标是：

就近访问，降低延迟
满足本地合规要求
避免单区域事故影响全局

2.3 形态三：按业务隔离

还有一种常见做法是按业务域拆集群，例如：

在线交易集群
数据处理集群
AI 推理集群
内部办公系统集群

这样做的典型原因包括：

工作负载模型差异大
插件和节点规格差异大
风险级别不同
升级节奏不同

例如 GPU 集群与普通 Web 集群通常就不适合长期混跑。

2.4 三种形态往往会叠加

真实企业里，多集群通常不是单一维度，而是叠加出来的，例如：

prod-ap-sg-payment
prod-eu-fr-search
staging-cn-hz-platform

也就是说，环境、地域、业务线常常会共同决定集群边界。

3. 多集群统一发布、观测与权限管理

多集群真正难的，不是“集群数量多”，而是“如何统一管理”。

3.1 统一发布：核心是“声明一致、目标分发”

在多集群场景里，最容易失控的事情就是：

同一个应用在不同集群版本不同
某些集群忘记升级
某些集群临时手改配置
回滚时找不到真实状态

因此，多集群发布通常推荐 GitOps 化：

Git 保存期望状态
按集群 / 区域 / 环境生成清单
平台统一下发与追踪同步状态

下面给出一个常见的 Argo CD ApplicationSet 示例，用集群标签做目标分发：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: payment-service
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            app-group: payment
  template:
    metadata:
      name: '{{name}}-payment-service'
    spec:
      project: default
      source:
        repoURL: https://git.example.com/platform/apps.git
        targetRevision: main
        path: apps/payment-service/overlays/{{metadata.labels.env}}
      destination:
        server: '{{server}}'
        namespace: payment
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

这个例子的关键点不在具体工具，而在思路：

集群成为一个“目标集合”
发布策略通过标签选择目标集群
配置差异通过 overlay 控制
最终状态回到统一控制面可见

3.2 统一观测：指标、日志、链路要能按集群维度聚合

当你从单集群进入多集群，观测体系必须同步升级。至少要做到：

指标：Prometheus / 远端写入平台按 cluster 维度聚合
日志：日志平台可按集群、命名空间、应用检索
链路：Trace 里带上集群标签
事件：变更和告警能定位到具体集群

一个多集群指标采集配置示例：

apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
  name: federation-remote-write
  namespace: monitoring
spec:
  staticConfigs:
    - labels:
        cluster: prod-ap-sg
      targets:
        - prometheus.prod-ap-sg.example.com:9090
    - labels:
        cluster: prod-eu-fr
      targets:
        - prometheus.prod-eu-fr.example.com:9090
  metricsPath: /federate
  params:
    match[]:
      - '{__name__=~"job:.*|container_.*|kube_.*"}'

3.3 统一权限管理：身份统一，授权按边界拆分

多集群场景下，最糟糕的做法是每个集群都维护一套独立账号。更合理的方向通常是：

身份认证统一接入企业 IdP / OIDC
不同集群按角色授权
权限最小化
平台团队保留 break-glass 权限

一个典型 RBAC 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-only-platform
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps", "namespaces"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets", "daemonsets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-platform-binding
subjects:
  - kind: Group
    name: platform-readonly
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: read-only-platform
  apiGroup: rbac.authorization.k8s.io

3.4 统一服务发现：跨集群 Service 的一种思路

SIG Multicluster 文档把 Multi-cluster Services API 定义为对 Service 语义的跨集群扩展；GKE 文档也把它描述为跨集群服务发现与访问能力::cite[348].

一个学习型示例如下：

apiVersion: v1
kind: Service
metadata:
  name: checkout
  namespace: shop
spec:
  selector:
    app: checkout
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: networking.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: checkout
  namespace: shop

这个思路的核心是：

本地仍然是普通 Service
通过额外资源声明“导出”到多集群范围
再由多集群服务发现层完成跨集群访问

4. 多集群实践中的复杂度与治理重点

很多团队一开始只看到多集群的好处，后面才发现复杂度会急剧上升。

4.1 多集群增加的复杂度主要来自哪里

维度	复杂度来源
发布	配置矩阵膨胀，回滚链路更长
网络	跨集群访问、DNS、Service 发现更复杂
安全	证书、身份、网络策略、密钥分发更难统一
观测	数据分散，需要统一标签与聚合口径
成本	多套控制面、多套节点池、多套运维流程
组织	平台团队与业务团队职责边界更难划分

4.2 治理重点一：先定义“建集群的门槛”

不是所有问题都要靠新集群解决。你应该先明确：

什么场景可以只用命名空间隔离
什么场景必须新建集群
新集群申请、审批、纳管流程是什么
谁负责集群生命周期

否则，多集群很容易演变成“集群泛滥”。

4.3 治理重点二：统一元数据模型

如果不同集群没有统一标签规范，后续发布、观测、成本归集都会变得非常痛苦。至少建议统一这些标签：

metadata:
  labels:
    env: prod
    region: ap-sg
    business-unit: payment
    owner: platform-team
    criticality: high
    compliance-tier: restricted

4.4 治理重点三：把差异收敛到“少数维度”

多集群最怕每个集群都是“特例”。更稳妥的方式是：

尽量统一 CNI、Ingress、监控、日志、证书管理
把差异收敛到环境、地域、业务三个维度
通过模板 / overlay / policy 控制差异，而不是手工改

4.5 治理重点四：用策略系统约束漂移

你可以通过准入策略、Policy as Code、模板校验来避免配置漂移。例如要求每个工作负载必须带集群治理标签：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-governance-labels
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: "has(object.metadata.labels.env)"
      message: "必须提供 env 标签"
    - expression: "has(object.metadata.labels.region)"
      message: "必须提供 region 标签"
    - expression: "has(object.metadata.labels.business-unit)"
      message: "必须提供 business-unit 标签"

4.6 治理重点五：分清“平台职责”和“业务职责”

一个简单划分可以是：

角色	主要职责
平台团队	集群生命周期、策略、可观测性、统一发布基础设施
业务团队	应用清单、服务依赖、容量规划、上线节奏
安全 / 合规团队	身份、审计、基线策略、敏感数据要求

职责不清时，多集群一定会变乱。

5. 一套实用的多集群落地路线

如果你准备从 1 个集群走向多集群，可以按下面顺序推进：

阶段 1：先做“资产可见”

建立集群清单
统一命名规则
补齐标签与 owner 信息

阶段 2：再做“访问统一”

OIDC 统一认证
RBAC 基线模板化
集群接入平台目录

阶段 3：再做“发布统一”

GitOps 管理应用清单
应用按标签分发到目标集群
统一回滚与审计

阶段 4：最后做“跨集群能力”

跨集群服务发现
跨集群流量治理
全局观测和 SLO 管理

这个顺序很重要：先纳管，再统一，再扩展。

6. 本章小结

多集群不是 Kubernetes 的“高级玩法”，而是业务发展后的自然演进。你需要记住四个核心观点：

单集群天然有边界，业务一旦跨越环境、地域或治理边界，多集群就会出现::cite[348]
多集群常见形态包括环境隔离、地域分布和业务隔离::cite[204]
统一发布、观测、权限，是多集群落地的基本盘
多集群最难的是治理，而不是把集群建出来

如果你现在就在做平台建设，可以先问自己一句话：

我们到底是在“扩集群数量”，还是在“建设多集群治理体系”？

两者差别非常大。

📝 版权声明：本文为原创技术博客，转载请注明出处。

如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！