使用多集群服务 API 扩展 Kubernetes 服务

可以这么说：Kubernetes的构建并没有考虑多集群。集群的概念在核心Kubernetes API中没有出现。Kubernetes引入了跨单个集群内虚拟机或节点边界调度工作负载的能力，这是对大规模工作负载和配置管理的根本改进。现在，随着数据和计算管辖权问题的不断演变、组织复杂性的不断提高以及多租户应用程序的趋势等原因，规模化的企业正在超越单一集群。

虽然你可以将集群扩展到数千个节点，但用户发现他们需要多个集群，而不是一个大型集群。他们可能想：

• 通过一系列区域节点拓扑提供全局可用性。

• 由于数据重力或延迟问题，将工作负载扩展到远程位置。

• 出于性能、安全和隐私原因，在工作负载之间创建硬隔离。

• 任何一个应用程序或基础架构问题的爆发半径限于一个集群中。

在许多情况下，这是自然而然发生的。为新的团队或项目提供新的集群，最终需要绑定在一起。

在多集群世界中，我们发现有两组用户对这种情况有着非常不同的看法：平台团队，他们试图为可能是数百个集群“照明”；应用程序团队，他们只想让自己的应用程序在某个地方运行，并访问它所需的所有其他服务。对于应用程序团队来说，集群之间的硬边界可能会成为阻碍。理想情况下，应用程序开发人员不需要梳理——甚至不需要知道——平台团队的Terraform计划，就可以发现一些特殊的多集群拓扑，让他们完成工作。

了解应用程序连接

我们可以将应用程序连接划分为三个抽象层：

顶层：纯应用程序管理

将一个应用程序连接到另一个应用程序，无论它位于何处——这是应用程序开发人员所需要的。

中间层：服务层

在这里你分组和定义组成应用程序的后端、它们是如何公开的，以及允许谁与它们交谈。

底层：网络层

每个单独的计算节点实际上是如何连接在一起的。

vanilla Kubernetes安装为你处理网络层，并提供服务对象原语来配置单个集群中的服务层。在跨越集群方面，前进的道路不再那么清晰。

在当今的多集群部署中，平台管理员正在以多种方式解决跨集群服务发现问题——一些是使用服务网格，比如Istio以及谷歌云平台的Anthos服务网格、OpenShift的Service Mesh或VMWare的Tanzu，另一些是使用自己的解决方案。虽然服务网格功能强大得令人难以置信，但并不总是能立即确定你是否需要它们提供的一切，而且取决于组织的工程资源，这可能是一个挑战。如果平台管理员希望将无状态工作负载拆分到另一个集群上，并以不同于有状态工作负载的方式对其进行扩展和升级，那么只需要在两者之间进行一些最小的服务发现。如果应用程序开发人员希望集中一些公共服务以减少开发冗余，但又希望团队保持在自己的集群上，那么在集群之间共享一些服务对象就可以了。

好消息是，Service API的Kubernetes原生扩展可用了，它为你提供了一种以熟悉的方式将多个集群缝合在一起的方法。

多集群服务API

KEP-1645中定义的多集群服务API描述了ClusterSet的最小属性，即连接在一起的两个或多个Kubernetes集群集，其核心是两个新的API对象：“ServiceExport”和“ServiceImport”。用户创建一个“ServiceExport”映射到他们想要共享的“服务”，这允许他们选择只发布他们想要的服务。监控“ServiceExport”对象的控制器在ClusterSet的其余部分创建相应的“ServiceImport”对象，为使用者工作负载传输相关信息。

该设计非常简单，只引入了填补现有核心Kubernetes网络原语之间差距所需的最少量新API资源：生产集群中的“Service”本身和消费集群中的“EndPointSlices”。控制器负责处理可能同时从多个集群导出的服务定义之间的任何冲突，并创建和维护保存每个导出集群后端IP的“EndpointSlices”。MCS API包括一个DNS规范，该规范扩展了大家已经熟悉的Kubernetes DNS范式，添加了以服务和命名空间命名的记录，但以DNS区域“.clusterset.local”结尾。

这意味着应用程序开发人员可以停留在顶层，继续以他们一贯的方式构建应用程序。只需加入一些ServiceExports，并切换出应用程序配置，以引用以“.clusterset.local”结尾的DNS，而不是“.cluster.local”，就可以了。Kubernetes Service在集群间传播，你可以无缝地使用多集群服务。对于需要将另一个集群中的特定粘性或有状态端点作为目标的情况，也可以将ServiceExports添加到无头服务中，从而使各个后端可以在整个集群集中寻址。

这一新API是SIG Multicluster两年多工作的成果，来自谷歌、红帽和其他公司。它现在在GKE和OpenShift上的托管产品中可用，或者使用名为submarner.io的开源实现自行托管。它还作为一个统一的API，可以扩展到Kubernetes生态系统的其余部分：网关API支持入口路由的ServiceImport后端，并且Istio正在遵循一个多阶段集成计划，最终在istiod中实现一个功能齐全的MCS控制器，允许以最小的工作量投入使用。

扩展到多集群现在非常容易：从熟悉的、轻量级的MCS API开始，当需求增加时，为额外的配置和功能铺平道路。

多集群入门

多集群不是未来的事情——它正在发生。通过MCS API弥合集群之间的服务发现差距，应用程序团队可以继续在应用程序级别工作，而不必担心他们的服务在众多底层集群中的哪一个。同时，平台团队可以灵活地以他们想要的方式配置其基础设施，根据需要添加更多集群，以解决高可用性、服务弹性和集中共享服务等用例。你不再需要将集群的边缘视为硬边界。

想自己试试吗？很简单！如果你想立即开始制作自己的ServiceExports，你可以启动几个集群并启用GKE的多集群服务API的托管实现。如果你想自己管理，请尝试使用kind、k3s、GKE、Rancher或OpenShift快速入门指南部署submarner.io。如果你想在试用之前先学习，请访问KubeCon NA 2021，在这里你可以看到多集群服务API的演示，可以看到使用MCS API的服务。

https://kccncna2021.sched.com/event/lV67/here-be-services-beyond-the-cluster-boundary-with-multicluster-services-laura-lorenz-google-stephen-kitt-red-hat?iframe=no

原文链接：

https://thenewstack.io/extending-kubernetes-services-with-multi-cluster-services-api/