多集群管理
multi-cluster-management 概览。
30 分钟
多集群管理
单集群够用之前，不必引入多集群复杂度。当 环境隔离（prod/stage）、区域部署、收购整合、 blast radius 控制 成为需求时，multi-cluster-management 进入路线图。本课建立概念框架：联邦、GitOps 多集群、服务网格多 primary——不要求一次上全，但要能 选模式、定 kubeconfig 与发布边界。
学习目标
- 区分多集群动机：隔离、地域、规模、合规
- 比较「多 kubeconfig + GitOps」与 Cluster API / 联邦的适用场景
- 为 CodeRoadMap 设计 prod + staging 两集群的最小治理模型
为何要多集群
| 动机 | 示例 |
|---|---|
| Blast radius | prod 与实验集群 etcd 分离 |
| 地域 | 华东 / 华北各一集群，就近接入 |
| 版本 | staging 先升 K8s 小版本，验证后再 prod |
| 租户 | 大 BU 独立集群 + 统一 GitOps 仓库 |
| 边缘 | 中心集群 + 边缘轻量集群 |
kubernetes-essentials 的 minikube 可视为「第 0 个集群」；进阶是 第 N 个集群如何一致发布。
常见管理模式
模式 A：独立集群 + 统一 GitOps
每个集群一个 Argo CD / Flux 实例或 hub-spoke
Chart 相同，values-prod.yaml / values-stg.yaml 不同
→ 见 gitops-argocd、gitops-flux
模式 B：Cluster API / 集群生命周期 GitOps
用 CRD 声明「要一个三节点 EKS」
→ 与 k8a-crds 思维一致
模式 C：服务网格多集群
跨集群服务发现、mTLS
→ 需 mesh + k8s 基础（选读 service-mesh-essentials）
多数团队从 模式 A 起步：与 helm-gitops-essentials 自然衔接。
kubeconfig 与访问
- 上下文命名：
codermap-prod、codermap-stg，避免误操作 prod - RBAC：人类只读 staging；prod 变更走 CI + GitOps
- Secret 分发：External Secrets / 云 Secret Manager，避免同一 Secret 复制到 Git
kubectl config use-context codermap-stg
kubectl get deploy -n backend
发布与配置漂移
| 实践 | 说明 |
|---|---|
| 单仓库多 values | Helm -f values-prod.yaml |
| Promotion | staging 镜像 tag 验证后，PR 改 prod values |
| 策略差异 |