一个Kubernetes开发者眼中的Anthos

Google Cloud Platform在Cloud Next 2019上正式推出Anthos。Antos是谷歌少有的在很短时间就获得GA地位的技术之一。尽管Antos已经GA，但它并不是一个支持自助服务的GCP产品。它花了将近一年的时间才出现在GCP控制台上。与其他GCP服务不同，其文档少而不完整。

之前，除了Anthos是基于Google Kubernetes Engine（GKE）这一显而易见的事实之外，社区对这个平台知之甚少。但到2020年，情况开始发生重大变化。Anthos现在可以在Google Cloud Comsole上使用。相关文档提供了有关平台架构、各种组件的安装和配置的详细信息。 

尽管如此，Anthos可能还是会让普通的Kubernetes用户感到困惑。本文试图向熟悉Kubernetes的开发人员或用户介绍Anthos。

从VM Sprawl到集群Sprawl 

在过去的十年中，企业IT面临着虚拟机（VM）扩张的挑战。任何有权访问VMware环境的用户、开发人员或管理员都启动一个新的虚拟机。很快，IT意识到，有数百个虚拟机跨多个部门运行，这些虚拟机对IT不可见或不由IT管理。这导致了资源的失控和碎片化。IT引入了一个工作流，需要部门IT主管的批准才能启动虚拟机。它还强制实施了一个策略，以确保虚拟机是由它集中管理的预先批准的镜像创建的。预先批准的镜像用作模板，其中包含强制的安全策略和修补程序，确保每个虚拟机都基于经过强化、测试和信任的镜像。             

到2020年，企业IT正在经历Kubernetes集群的蔓延。部门级的用户正在内部、私有云和公有云环境中构建集群。每个部门都运行多个集群，这些集群是通过Kubespray和Kops等工具提供的，或者是托管的CaaS产品（如Google Kubernetes Engine和Azure Kubernetes Service）提供的。

企业IT正面临着与虚拟机蔓延一样的集群蔓延挑战。Kubernetes集群已经成为应用程序的新部署边界。尽管命名空间提供了所需的隔离和边界，但是客户发现通过在不同的集群上运行应用程序来隔离应用程序是很容易的。             

每个部门都有多个集群运行在不同的环境中——内部部署、私有云、公有云中的自提供集群、公有云中的托管集群。枚举并管理这些集群对IT和DevOps团队来说是一个巨大的挑战。             

要使所有集群达到所需的状态，需要在每个集群上运行一组kubectl命令，以确保它们具有一致的配置。将配置、策略、配额、RBAC角色应用到每个集群是一件费力且容易出错的事情。             

元控制平面——控制平面的控制平面

企业IT所需要的是一个元控制平面，作为在一个组织内启动的所有Kubernetes集群的总控制平面。通过元控制平面，可以保证每个集群符合一组预定义的策略。元控制平面还可以强制执行严格的规则，这些规则可以检测集群配置中的漂移，并将它们恢复到所需的配置状态。             

我们称它为元控制平面，因为它管理每个Kubernetes集群的控制平面（主节点）。发送到元控制平面的命令将自动应用于每个集群的控制平面。由于元控制平面可以看到每个集群，因此它可以收集和聚合与基础设施和应用程序运行状况相关的指标。元控制平面成为配置和可观测性的单一面板。             

与Kubernetes控制器如何维持所需的部署、状态集、作业和守护程序状态类似，元控制平面确保整个集群维持所需的配置状态。             

例如，如果参与集群有一个预期的运行角色和rolebinding，那么元控制平面可以检测角色何时被删除并自动重新应用配置。这类似于Kubernetes控制器如何维持所需的部署副本计数。             

因此，元控制平面对于Kubernetes集群就像控制器对于部署一样。 

Kubernetes master和元控制平面之间还有一个共同点。调度工作负载时，可以通过标签/选择器或节点关联性的组合来影响放置。部署规范中的nodeSelector或NodeAffinity子句将确保工作负载落在符合条件的某个节点上。类似地，可以指示元控制平面仅将部署、配置或策略推送到参与集群的子集。此机制与Kubernetes调度的nodeSelector模式非常相似。与标记节点和在部署到目标特定节点时使用选择器类似，我们标记每个参与的集群，并在元控制平面使用选择器来减少或筛选目标集群。        

随着组织内集群数目的增长，用户需要一个元控制平面来负责集群管理。元控制平面将确保参与的集群是规范化的，并且与其配置一致。             

Anthos——一个来自谷歌的元控制平面

简而言之，Anthos是来自谷歌的Kubernetes元控制平面。而除了作为一个元控制平面，Antos还扮演着在混合和多云环境中管理基础设施和工作负载的角色。 

Antos的核心组件是以GCP为基础的元控制平面。在大多数情况下，用户是看不见它的。类似于谷歌如何隐藏GKE集群的主节点，它也隐藏了Antos控制平面。这个控制平面公开了用于管理Kubernetes集群生命周期和向Antos注册外部集群的API。      

Antos——混合和多云控制平面

虽然Antos的控制平面运行在GCP的上下文中，但它可以在各种环境中启动托管的Kubernetes集群，包括本地数据中心、AWS和Azure。通过Antos启动的托管Kubernetes集群与运行在GCP中的典型GKE集群具有相同的可靠性和稳定性。

Antos要在内部启动托管的Kubernetes集群，它依赖于vSphere 6.5、vCenter、vSphere存储和F5 BIG-IP或基于谷歌开源项目Seesaw的捆绑软件负载均衡器。Anthos首先在vSphere中提供了一个管理集群（它可以生成多个用户集群）。把该管理集群看作本地Antos控制平面，它处理vSphere中运行的托管集群的生命周期。            

Antos for AWS于2020年5月GA，它可以在AWS环境下运行托管的Kubernetes集群。利用Amazon EC2、Amazon EBS、AWS VPC和Amazon ELB，Anthos可以启动高可用性的Kubernetes集群，这些集群跨多个可用区域。与vSphere中的管理集群类似，Antos首先在AWS VPC中启动一个管理集群，它负责启动其他用户集群。             

当Antos for Azure可用时，它将利用Azure VMs、Azure Premium Storage、Azure Virtual Networks和Azure Load Balancer来运行HA Kubernetes集群。从技术上讲，Antos可以在任何支持在高可用性模式下运行Kubernetes的可编程基础设施中启动托管集群。             

除了管理通过Antos启动的集群外，该平台还支持将外部的非托管集群连接到控制平面。托管与非托管的关键区别在于生命周期管理。Antos可以拥有从创建和终止托管集群的所有内容，也可以部分控制外部的非托管集群。           

Anthos的关键组件              

Antos除了是Kubernetes集群的混合、多云控制平面外，还可以管理跨集群部署的工作负载的网络策略、路由、安全性和配置管理。             

让我们来看看Antos的关键组件：             

Antos Control Plane：该组件是Antos的元控制平面。它负责管理托管集群的生命周期以及外部非托管集群的注册和取消注册。Antos通过Hub和Connect服务公开了这个API。             

Antos Service Mesh：这个组件是为Antos优化的Istio服务网格的商用实现。它提供三种功能：1）微服务之间的安全通信，2）网络和路由策略，3）可观测性。             

Anthos Config Management：这个基于GitOps的组件支持中心化的机制，可以将部署、配置和策略推送到所有参与的集群（包括托管集群和非托管集群）。一个可中心化访问的Git存储库充当所有集群的真相来源。在每个集群中运行的Antos Config Management代理会监视集群中的状态更改。当与Git中定义的不同时，代理会自动应用配置，使集群返回到所需的状态。             

Cloud Run for Antos：Cloud Run是一个在GCP中运行容器的无服务器无集群环境。它是Knative之上的一层，提供了部署和运行容器的最佳开发体验，而无需启动GKE集群或定义pod规范。Cloud Run for Antos为托管集群带来了开发人员体验。      

Ingress for Anthos：这个组件将流量路由到微服务，并与通过Antos Service Mesh配置的Envoy代理一起使用。Ingress for Anthos成为访问Antos集群中运行的工作负载的入口点。它目前只适用于Antos启动的在GKE集群中运行的工作负载。           

Kubernetes Apps on GCP Marketplace：它充当针对Kubernetes的各种无状态和有状态工作负载的目录。用户可以按下一个按钮，在Antos管理的集群中部署来自marketplace的应用程序，而不管它们是在哪里提供的。