分布式Kubernetes PaaS控制平面

F5生态系统 | 2019年11月15日

本文是系列博客的第一篇，将从多个方面介绍我们构建和运营SaaS服务所需的工作：

分布式Kubernetes PaaS的控制平面
面向分布式应用的全局服务网格
面向分布式基础设施、应用和数据的平台安全
分布式集群的应用和网络安全
覆盖全球分布式平台的可观测性
全球分布式平台的运维与SRE
面向分布式微服务的Golang服务框架

正如我们在之前的博客文章中所述，客户正在构建复杂多样的业务解决方案，例如智能制造、用于公共安全的视频取证、算法交易和电信5G网络。因此，我们需要为这些应用及其最终用户提供始终在线、互联且可靠的体验。

由于这些应用可能运行在不同云提供商或客户边缘位置的多个集群中，我们的平台团队必须构建分布式控制平面和PaaS服务，用于部署、保护和运维多个多租户Kubernetes集群。该分布式控制平面在运维、扩展和性能方面带来了诸多优势。我们将在演讲（视频链接）中介绍这些优势，例如如何使用GitOps管理数千个边缘K8s集群；未来几周，我们还会另行发布一篇博客文章。

摘要

我们在市场上找不到简单易用的解决方案，来解决跨云提供商、私有云或多个边缘位置部署、保护和运维多个应用集群的问题。
我们找不到能够为分布式集群提供全面安全和运维服务的可靠Kubernetes发行版或PaaS（例如OpenShift、Cloud Foundry等）。这些服务包括基于PKI的身份认证、RBAC和用户访问管理、跨云提供商的机密信息和密钥管理、多集群服务网格、可观测性和审计日志，以及应用和网络安全。
Anthos（Google）、Azure Arc（Microsoft）和Rancher是多集群管理平台，整合了多种不同的服务。根据我们的分析，这些平台无法满足跨多个集群的应用和基础设施服务在运维、扩展、安全和多租户方面的要求。
我们必须为基于Kubernetes构建的托管PaaS自行开发分布式控制平面。我们从原生Kubernetes入手，随后进行了重大改造，以提供DevOps和SRE团队所需的平台服务。此外，我们还必须构建一个控制平面，用于管理大量分布式集群，并在异构基础设施（包括边缘环境、我们的网络以及多个云提供商的环境）中实现多租户。

使用Kubernetes管理应用：原因与方法

我们选择Kubernetes（K8s）作为分布式应用管理平台的核心，因为它功能丰富，又不会施加过多限制，让我们能够灵活创新，专注于我们认为对客户至关重要的方面。我们以此为基础开始构建服务。随着K8s日益普及，寻找熟悉该技术的开发人员和运维人员也变得更加容易。

不过，要在混合环境（多个云、网络POP和边缘位置）中部署和管理大量生产级Kubernetes集群并非易事，因为Kubernetes没有可直接使用且能够实现以下功能的解决方案：

通过自动化集群、扩缩容和零接触配置来协调异构基础设施资源；这一问题在边缘位置和我们的网络PoP中尤为棘手
在不同位置之间提供高性能、可靠的连接，尤其是跨云提供商连接以及从边缘位置接入时
解决传输中数据、静态数据、机密信息、密钥和网络的安全问题……所有这些均由统一的PKI身份提供支持，该身份适用于边缘、网络和云环境
提供真正的多租户能力，确保租户隔离和安全，并支持在同一集群上运行生产和开发工作负载，满足内部及客户需求
为分布式集群提供可观测性和运维能力，并与集中式策略和意图相衔接，无需构建复杂的日志和指标收集机制

在针对多个云提供商和开源平台（如GKE、AKS、EKS、RKE、OpenShift和Cloud Foundry）开展多次概念验证后，我们发现，没有一个平台能够满足上述全部5项要求。因此，我们决定构建自己的PaaS：以原生Kubernetes为基础，并针对身份、网络、安全、多租户、日志和指标等方面进行扩展。虽然我们使用Kubernetes来满足内部需求，但也不得不做出一些艰难的决定，例如不直接向内部用户和客户开放这些Kubernetes集群来运行其工作负载（稍后将详细说明，因为多租户是我们的一个关键目标）。

除了需要添加多项新功能外，我们还需要在边缘、我们的网络以及公有云和私有云的多个位置，让自身的工作负载和服务与客户工作负载并行运行。因此，我们必须构建更多功能，以管理多个环境中的多个集群。这些集群通过我们的全球网络和分布式应用网关互连，从而在集群之间提供零信任和应用级连接。

难点：Kubernetes 多租户与多集群

即使使用由云提供商管理的集群，构建和运维在单个Kubernetes集群中运行的应用也并非易事。因此，DevOps和SRE团队通常会尽量降低管理开销，避免应对多集群带来的复杂性。常见的做法是构建一个大型Kubernetes集群，并将各类资源全部放入同一集群。这样做看似不错，因为既能简化运维，又能提高集群的计算效率并降低成本，但出于多种原因，这并非理想方案。首先，生产工作负载的需求与开发测试和预发布环境有很大差异；不稳定的开发工作负载可能会给更稳定的生产工作负载带来问题。

除了不同工作负载的需求外，K8s在安全和隔离方面的局限也是采用多集群的另一个驱动因素。解决K8s安全和资源隔离问题的一种常见方法是采用多租户模型，为每个租户启动独立集群。虽然这种做法在云端可能可行，但边缘环境无法运行多个集群。边缘站点的计算和存储资源有限，网络带宽也受到限制，难以将每个新增集群的日志和指标发送到中央云。

为解决多个Kubernetes集群带来的问题，我们评估了用于集中管理Kubernetes集群的Rancher（项目启动时，Anthos和Azure Arc尚未推出）以及KubeFed。当时有以下两种方法可供选择（如今依然如此）：

通过中央控制台进行多集群管理（例如Rancher），可以让我们在任意位置部署多个集群，并执行升级、回滚等生命周期管理操作。其中一些系统还支持通过自动化方式对单个集群进行配置和应用部署
另一种方法是部署Kubernetes集群联邦（KubeFed）控制平面，使多个物理集群看起来像一个集群。我们当时评估时，该项目才刚刚起步，即使到现在也仍处于Alpha阶段。

在近期发布GCP Anthos和Azure Arc后，我们重新评估了最初构建分布式控制平面的决定。结论是，即使这两项新产品也无法解决分布式集群面临的两个关键问题。我们的平台需要具备以下两项关键能力：

将多个集群作为一个集群组进行管理，以解决跨所有集群或某个逻辑集群组执行配置、部署、指标监控等操作的问题。这一点至关重要，因为我们希望降低SRE团队的运维开销，提升DevOps团队的调试效率，并增强系统的可扩展性
能够将单个物理Kubernetes集群划分为多个租户使用，而无需启动新的物理集群；这对于资源受限的环境尤为重要，因为我们不希望仅为实现多租户而添加新的物理集群

为解决这两个问题，我们必须采用一种新技术，即分布式控制平面，以降低“多个”集群带来的运维开销，并在资源受限的环境中为多租户提供相当于“多个集群”的能力。

分布式控制平面：我们如何实现多集群Kubernetes

我们的平台团队决定为Kubernetes构建一个分布式控制平面，向团队提供Kubernetes API。不过，这些API来自仅存在于控制平面中的“虚拟”集群，即面向虚拟K8s集群的虚拟K8s（vK8s）API服务器（如图1所示）。该控制平面将用户意图映射到多个物理Kubernetes集群，这些集群运行在我们的边缘位置、网络POP和公有云位置。只有分布式控制平面可以访问这些物理集群，任何单个租户或用户均无法访问。

图1：分布式控制平面

此控制平面为每个租户提供一个或多个“虚拟”应用集群，租户可在其中部署应用。控制平面会根据配置，在多个物理Kubernetes集群中复制和管理这些应用。除配置和部署操作外，监控操作也会随此“虚拟”集群进行，无需构建工具来收集和分析多个物理集群中的数据。

以名为productpage的示例UI应用为例，用户希望将其分布式部署在3个位置：pa2-par、ny8-nyc和ams9-ams，每个位置运行2个副本。用户创建vK8s对象并将其附加到虚拟集群后，系统会立即预置一个可与标准kubectl配合使用的vK8s API服务器。

接下来，用户下载此虚拟集群的kubeconfig，并创建标准YAML文件来描述productpage的K8s部署。

创建部署规范后，用户可以继续在此虚拟集群上创建部署：

现在，用户检查部署时会看到已启动6个副本，每个位置各有2个（pa2-par、ny8-nyc和ams9-ams）。

以下输出显示每个位置运行着2个Pod，并映射到特定的物理节点

这个简单示例说明，无需承担任何安装和管理负担，只需几分钟即可轻松实现任意应用的多集群复制。除了映射意图外，分布式控制平面还可提供虚拟集群级别的可观测性，而不是仅针对单个集群。

面向多租户的分布式控制与集中式管理

如图 2所示，我们的集中式管理平面跨两个公有云提供商运行，每个提供商各使用一个区域，其中一个位于AWS，另一个位于Azure，以实现冗余。借助此管理平面，我们的SRE可以创建采用严格多租户隔离的租户。例如，负责VoltMesh服务的开发团队可以作为一个租户，而负责客户POC的客户解决方案团队可以作为另一个租户，并拥有自己的一组用户。

图 2：多租户和多集群

每个租户都可以创建多个命名空间，并分配一组用户在这些命名空间中协作。这些命名空间并非Kubernetes命名空间，而是我们平台中的隔离边界，并为用户配置了RBAC规则和IAM策略。

当命名空间中的用户需要创建应用集群时，可创建一个vK8s对象，该对象随后会在我们的管理平面中创建一个vK8s API服务器。用户可以通过此vK8s对象创建部署、有状态集、PVC等资源。控制平面会根据与该vK8s对象关联的站点，确保这些操作在一个或多个物理集群上执行。

由于每个租户和用户都直接使用未经修改的标准K8s操作，因此系统可兼容多种常用运维工具，例如Spinnaker、Helm和Jenkins等。

分布式控制平面带来的收益

分布式控制平面的主要优势在于，它解决了SRE和DevOps团队的运维开销问题。团队现在可以在虚拟集群中执行配置、部署、监控和策略等操作，控制平面会自动将这些操作映射到多个物理集群。除了简化多集群运维之外，控制平面还解决了多租户环境中的安全和隔离问题。

这种分布式控制平面还提高了开发者为平台添加新功能的效率。每当新增会影响多个集群配置或运维的功能时，他们无需重新构建自动化机制。开发者使用基于意图的配置模型，控制平面便能确定需要执行的操作。此外，他们可以继续使用kubectl与这个分布式多集群对象（虚拟Kubernetes）交互，而无需再使用其他CLI。

在开发测试、预发布和生产环境中运行了一年多后，我们发现，这个在网络POP中运行的全球分布式控制平面还能在可扩展性、性能和可靠性方面带来显著优势，而这是我们早期未曾充分预想到的。我们将在即将举行的KubeCon演讲中介绍这一发现，并将在未来几周另行发布一篇博文。