SOFAStack CAFE 单元化混合云产品中的 Kubernetes 多集群实践

背景

SOFAStack 是蚂蚁集团的商业化金融级云原生架构产品，基于 SOFAStack 可快速搭建云原生微服务体系，快速开发更具可靠性和扩展性、更加易于维护的云原生应用。在宏观架构层面，提供单机房向同城双活、两地三中心、异地多活架构演进路线，使系统容量能在多个数据中心内任意扩展和调度，充分利用服务器资源，提供机房级容灾能力，保证业务连续性。

在应用生命周期管理层面，SOFAStack 提供了一个多模应用 PaaS 平台——SOFAStack CAFE (Cloud Application Fabric Engine) 云应用引擎。它提供应用管理、流程编排、应用部署、集群运维等全生命周期管理的 PaaS 平台能力，满足金融场景中经典和云原生架构的运维需求，帮助传统架构平滑过渡、保障金融技术风险。

在云原生架构运维上，SOFAStack CAFE 通过单元化混合云产品 LHC (LDC Hybrid Cloud) 提供单元化应用的云原生多集群发布运维能力，实现应用的多地域、多机房、多云混合部署。本文将揭开 LHC 的神秘面纱，来详细谈谈我们在其底层 Kubernetes 多集群发布体系中的一些实践。

挑战

在 LHC 产品诞生之初，我们首要面临的问题便是为其选择一个合适的底层 Kubernetes 多集群框架。彼时 Kubernetes 社区刚刚完成了其官方多集群项目 KubeFed，其提供了多集群的纳管、Kubernetes 资源的多集群分发与状态回流等一系列多集群基础能力，自然成为了我们当时的最佳选择。

但正如前面所说，社区的多集群框架提供的仅仅是“基础能力”，这些能力对于我们的单元化混合云产品来说存在着很多不满足甚至有冲突的点。其中，最突出的一个问题就是社区没有“单元化”的概念，其多集群就是纯粹的多 Kubernetes 集群，对任何一个多集群 Kubernetes 资源（在 KubeFed 中我们称其为联邦资源）来说，它的分发拓扑只能是按集群。但在单元化模型中，一个应用服务的资源是分布在多个部署单元中的，而部署单元和集群之间的关系的灵活的——在我们目前的模型中，集群和部署单元之间的关系是 1:n，即一个 Kubernetes 集群可以包含多个部署单元。这时候，我们便遇到了和社区框架的分歧点，也是最大的挑战：上层业务需要按部署单元维度来进行 Kubernetes 资源的治理，底层社区框架则只认集群。

除此之外，KubeFed 自身所涵盖的基础能力也还不足以满足我们的所有需求，比如缺乏集群的租户隔离能力、不支持资源 annotation 的下发、主集群和子集群之间的网络连通性要求高等等。由此，解决冲突并补齐能力便成为了我们在建设 LHC 产品底层多集群能力上的重点课题。

实践

下面我们就来分模块谈谈建设 LHC 产品底层 Kubernetes 多集群能力中的一些具体实践。

多拓扑联邦 CRD

在社区 KubeFed 框架中，我们通过联邦 CR 来进行 Kubernetes 资源的多集群分发。一个典型的联邦 CR 的 spec 如下所示：

可以看到其主要包含三个字段，其中 placement 用于指定所需分发的集群，template 包含了该联邦资源的单集群资源体，overrides 用于指定每个子集群中对 template 中资源体的自定义部分。

前面我们提到，对于单元化应用的 Kubernetes 资源而言，它需要按部署单元维度而非集群维度进行分发，因此上面的社区 CRD 显然是无法满足要求的，需要对其进行修改。经过修改后，新的联邦 CR 的 spec 如下所示：

可以看到，我们没有完全摒弃社区的 CRD，而是对其进行了“升级”，通过将具体的“集群”转变为抽象的“拓扑”，将联邦资源的分发拓扑完全自定义化，打破了单一集群维度的限制。如上面的 spec 中我们将 topologyType 设置为 cell 即指定了该资源以部署单元维度进行分发，反之指定为 cluster 则能完全兼容社区原生的集群维度分发模式。

当然，仅仅定义一个新的 CRD 无法解决问题，我们还需要修改其对应的实现，才能让其工作起