多集群管理

单集群够用之前，不必引入多集群复杂度。当 环境隔离（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
策略差异	prod 多副本、PDB、拓扑约束（k8a-topology）
可观测	每集群独立 Prometheus 或联邦；见 observability-essentials

跨集群 不 共享 etcd；全局视图靠 监控联邦、日志聚合、Tracing 后端，见 k8a-obs 与 prometheus-essentials 的 federation 话题。

CodeRoadMap 两集群草图

Git repo（Helm chart + values-stg / values-prod）
    ├─ Argo CD @ staging 集群 → 自动 sync
    └─ Argo CD @ prod 集群     → 手动 approve / PR merge

共享：容器镜像 registry、Terraform VPC（概念）
隔离：namespace、Secret、Ingress 域名、HPA 上限

练习

• 画 prod + staging 两集群 + GitOps 数据流
• 写三条规则防止「kubectl 误删 prod」
• 对照路线图 multi-cluster-management，列一种你暂不需要的多集群动机及原因

小结

多集群首先是治理与发布问题，其次才是网络联通。 下一课进入节点级调度隔离：污点与容忍度。