\n\n微软分享了在“舰队规模”下管理成千上万 Kubernetes 集群的经验。通过 Azure Kubernetes 舰队管理器结合 Cilium 网格技术，实现了自动化阶段性更新、跨集群连接及 GPU 资源优化。
译自：How Microsoft is governing thousands of Kubernetes clusters without manual intervention
作者：Adrian Bridgwater
Kubernetes 的复杂性众所周知。逻辑上讲，以“舰队规模（fleet scale）”部署的、由收集并合并的实例组成的 Kubernetes 集群无疑更加复杂。
在涵盖本地、云端和边缘的大规模分布式环境中，同步数千个集群的配置是一项巨大的挑战，那么它是如何实现的呢？
视频
小而美，大而繁
在更标准（较小）的环境中，Git 仓库中的自动化控制器会将 Git 中保存的集群期望状态与给定 Kubernetes 集群的实际状态进行同步。
Microsoft 首席软件工程师 Stephane Erbrech 告诉 The New Stack，尽管 GitOps 是 Kubernetes 生态系统中的主导声明式管理模式，但其单集群假设随着舰队规模的增长而成为了真正的限制。
“在标准的 GitOps 设置中，云原生软件工程团队可能会管理一两个集群，”Erbrech 表示，“在舰队规模下，复杂性从如何部署……转向了如何在没有人工干预的情况下治理大规模分布式环境。”
“随着 Kubernetes 客户群和社区的壮大……团队现在从一个集群开始，然后增长到两个，再到十个……随后达到数百个甚至数千个。”
他指出，GitOps 通常假设仓库与集群之间存在 1:1 的关系。它往往忽视了多集群的复杂性，如全局流量路由、跨集群机密同步以及跨环境的统一可观测性。
“随着 Kubernetes 客户群和社区的壮大（它已被确立为首选平台），我们看到团队从一个集群开始，然后增长到两个，再到十个……随后达到数百个甚至数千个，”Erbrech 解释道，“在这个过程中，他们最终都会遇到过去在虚拟机管理上遇到的同样问题：如何管理它们并保持合规与安全。”
对大规模分布式 Kubernetes 的需求源于多种原因（单纯的普及是其中之一），但一个关键驱动因素是 AI 正在无处不在地部署，即部署在从风力涡轮机到烘焙烤箱的每一个边缘设备上。这意味着统一的集群管理最好也能以同样的方式扩展。随着推理工作负载默认变为分布式，集群管理需要超越 GitOps 在大规模场景下会遭遇的调和延迟。
集群大舞台
Erbrech 将这一背景作为 Microsoft Azure Kubernetes 舰队管理器 (Azure Kubernetes Fleet Manager) 的背景验证，他表示这种管理层技术允许团队定义可重用的策略，以编排整个舰队的集群更新。
工程师可以将集群分组到不同的阶段，以实现更受控的推广。这意味着集群更新可以顺序应用，并可能在应用于舰队中关键的生产集群区域之前，先在低风险环境（如测试环境）中进行验证。
“这种控制使开发人员能够按照团队选择的步调，逐个环境、逐个集群地安全部署应用程序，同时持续检查指标并确保部署环境中没有任何环节出错，”Erbrech 解释道。
“Cilium Cluster Mesh 是我们在‘底层’使用的技术，用以实现 Microsoft Azure Kubernetes 舰队管理器提供的跨集群连接，并使网络以无缝方式运行。”
Cilium Cluster Mesh
Cilium 也是这个故事的重要组成部分。随着 Cilium Cluster Mesh 的到来，这个针对云原生环境的开源网络、安全和可观测性服务得到了扩展。
“Cilium Cluster Mesh 是我们在‘底层’使用的技术，用以实现 Microsoft Azure Kubernetes 舰队管理器提供的跨集群连接，并使网络以无缝方式运行，”Erbrech 澄清道，“[Cilium] 社区投入了大量工作来实现智能网络策略和控制机制；由于 Cilium 中的 eBPF 层，团队只需点击几次即可管理证书。”
这种技术带来的控制聚合显然对云原生工程师极具吸引力，其中许多人痛苦地意识到整个 Kubernetes 工具集是多么繁杂且难以驾驭。Erbrech 提到的 Microsoft Azure Kubernetes 舰队管理器中提升的控制能力，意味着团队现在可以让集群“相互对话”，因为工作负载可以在集群之间移动。
“这一切都是无缝发生的，最终用户完全察觉不到，因为工作负载始终保持高度可访问，一切运行良好，”Erbrech 总结道。
由于 GPU 资源昂贵且偶尔稀缺，跨集群的工作负载旅程有助于确保团队充分利用已准备的资源，而不会让它们闲置和浪费。
我们在开头提到了与边缘相关的更广泛的 AI 推理领域，这里还有第二个影响工作负载轨迹的因素需要考虑。由于 GPU 资源昂贵且偶尔稀缺，跨集群的工作负载旅程有助于确保团队有效利用已准备的资源，而不会让它们闲置或浪费。
集群生命周期管理
这一切都让我们回到了集群生命周期管理，以及使用 Microsoft Azure Kubernetes 舰队管理器的能力，它不仅是顺序升级 Kubernetes 版本的路径，也是集群定期退役时的寿命终止操作路径。
随着平台工程现在与日益复杂和分布式的云原生管理层交汇，我们需要管理好这支“舰队”，使其在一大群配置偏移的“舰队”中保持航行。各位，请加固舱门。全 工智能
