4. 多集群架构概览：联邦集群、Hub-Spoke 架构、独立集群的证书管理差异

聊证书轮换之前，得先搞清楚你面对的是哪种多集群架构。我见过不少团队，上来就抄一套轮换脚本，结果在联邦集群里跑得欢，换到 Hub-Spoke 就炸了。说白了，证书管理没有银弹，架构决定了你的策略。

这一章，咱们把三种主流架构掰开揉碎，看看它们在证书生命周期管理上到底差在哪。

4.1 三种架构的核心差异

先看一张总览图，帮你快速建立认知框架。

4.2 联邦集群：统一控制面的双刃剑

联邦集群（Federation）是我个人比较喜欢的一种模式。它通过一个控制面，把多个 Kubernetes 集群组织在一起。证书管理上，最大的优势是「统一」。

我在项目中遇到过这样的情况：一个联邦集群管理着 20 多个成员集群，所有集群的 kubeconfig 证书都从同一个 CA 签发。轮换时，只需要更新控制面的证书模板，然后通过 kubefedctl 或 clusterctl 下发到所有成员。

但这里有个坑。我曾经帮一个团队排查过，他们联邦集群的证书轮换脚本跑完后，部分成员集群的 API Server 直接挂了。原因是什么？证书模板里没有包含正确的 SAN（Subject Alternative Name）。联邦集群的证书模板是全局的，但每个成员集群的 API Server 地址不同。你想想看，如果模板里只写了控制面的域名，成员集群的 kubelet 拿这个证书去连本地的 API Server，肯定报错。

4.3 Hub-Spoke 架构：代理与隔离的平衡

Hub-Spoke 架构在混合云场景下特别常见。Hub 集群作为管理入口，Spoke 集群可能是边缘节点、分支机构或者云上的独立集群。证书管理上，它比联邦集群更灵活，但也更复杂。

说白了，Hub-Spoke 的核心是「代理」和「隔离」。Hub 集群持有所有 Spoke 集群的证书，但 Spoke 集群之间互不通信。证书轮换时，Hub 作为分发中心，把新证书推送到各个 Spoke。

特性	联邦集群	Hub-Spoke	独立集群
证书存储	控制面统一	Hub 集中 + Spoke 本地	完全本地
轮换触发	批量下发	Hub 推送 / Spoke 拉取	逐个操作
网络依赖	高（所有成员在线）	中（Spoke 可离线）	低
回滚难度	高	中	低
典型场景	同机房大规模集群	混合云 / 边缘计算	开发测试 / 小规模

嗯，这里要注意。Hub-Spoke 架构下，Spoke 集群可能因为网络问题长时间离线。证书轮换时，如果 Hub 强制推送，Spoke 上线后可能因为证书过期而无法连接。我建议的做法是：在 Hub 侧保留旧证书的缓存，Spoke 上线后先验证旧证书，再拉取新证书。这样即使轮换过程中断，也不会造成永久性失联。

4.4 独立集群：简单但不可忽视

独立集群听起来最简单，但千万别小看它。很多团队一开始都是独立集群，后来规模大了才迁移到联邦或 Hub-Spoke。证书管理上，独立集群完全自治，没有统一控制面。

我见过最惨的情况是：一个团队管理着 50 多个独立集群，每个集群的证书过期时间都不一样。结果某天凌晨，3 个集群同时证书过期，生产环境直接瘫痪。他们当时没有自动化轮换脚本，只能手动登录每个集群去更新 kubeconfig。

独立集群的证书管理，说白了就是「人肉运维」的噩梦。但如果你只有 3-5 个集群，而且都是测试环境，那独立集群反而是最灵活的。你可以用 Ansible 或简单的 Shell 脚本，逐个 SSH 到集群节点执行轮换。

4.5 架构选择对证书轮换策略的影响

聊了这么多，你可能会问：到底选哪种架构？我的建议是，先看你的网络环境和规模。

• 同机房、网络稳定、集群数量 > 10：优先考虑联邦集群，证书管理最省心
• 混合云、边缘计算、网络不稳定：Hub-Spoke 更合适，离线容忍度高
• 开发测试、小规模、临时环境：独立集群就够了，别过度设计

但不管选哪种架构，证书轮换的核心原则不变：自动化、可回滚、可监控。我在后面几章会详细讲具体的轮换方案，但架构选型这一步走错了，后面再好的方案也救不回来。