首次听到 Anthos，是在 Cloud Next 2019 大会由 Google 正式推出。不过在它推出的两年里，大部分开发者甚至 Kubernetes 开发者们都对它不够熟悉。

一个原因是 Anthos 虽然推出，但是相关文档很少而且当时不支持自助服务，在 GCP(Google Cloud Platform) 控制台上找不到。但到 2020 年，情况终于改变，Anthos 现在可以在 GCP 控制台上使用，相关文档也进行了丰富。

另一个国内开发者对 Anthos 比较陌生的原因是：大部分企业还在寻找好用的 Kubernetes(k8s)。而作为 k8s 的开创者，当大家都在讲 Docker 时，Google 已经开始讲 k8s，并有了 GKE(Google Kubernetes Engine) 这样的容器管理工具，大家开始讲 k8s 时，Google 开始讲多容器集群管理，并推出了 Anthos 这样的多集群管理平台。

我们先来看一看它的核心组件，Anthos 可以支持在 Google Cloud、本地数据中心、其他云厂商、边缘节点部署。核心组件包括了容器管理 Anthos GKE、服务管理 ASM(Anthos Service Mesh)、应用部署 Cloud Run for Anthos，以及策略管理 ACM(Anthos Config Management) 和运维管理。其中 GKE 是 Anthos 的中央指挥和控制中心。

所以它是一项新技术吗？不算，因为它的核心组件里都是大家熟悉的技术：基于 k8s 的 GKE、基于 Istio 的 ASM、基于 Knative 的 Cloud Run。官方说法是“一个开放式混合云和多云端应用平台”。但我们也可以说，Anthos 就是一个容器、服务网格、无服务器技术的合集，是“打包”了这些技术的新品牌名称。它解决的则是多 k8s 集群的管理问题。

Google 在 k8s 和云原生生态系统中有着举足轻重的影响力，Anthos 也是围绕着 k8s 快速构建的企业级战略。

向企业拓展，Anthos 看到未来多容器的挑战

过去十年，企业 IT 面临着虚拟机 (VM) 扩张的挑战。任何有权访问 VMware 环境的用户、开发人员或管理员都可以启动一个新的 VM，这就导致企业内部有数百个 VM 跨多部门运行，而这些对 IT 部门不可见，也不由 IT 部门管理，带来了难以控制和资源分散的问题。为此，IT 部门引进一个工作流，需要部门 IT 主管批准才能启动虚拟机。

今天，随着容器技术的发展，k8s 集群已经成为应用程序的新部署边界。企业又发现了 k8s 集群扩张的问题，大量的集群在自建数据中心、公有云、私有云上进行部署，可能每个部门都有多个集群运行在不同的环境中，这时，IT 和 DevOps 团队面临了如何管理多环境集群的问题。

Google Cloud 早已看到了多 k8s 集群扩张带来的管理挑战，如何平衡多计算资源、如何连接多平台集群在统一平台管理呢？Anthos 的推出就是为了解决这些问题。它可以在各种环境中启动托管的 k8s 集群。

（Anthos 的部署选项们）

Anthos 已支持和计划支持的部署环境如上，如果使用 GKE 集群，则支持部署在 Google Cloud、vSphere 数据中心、AWS EC2(目前是 beta 版本)；如果不是使用 GKE，而是自己的 k8s 集群，比如 AWS EKS 和 Azure AKS 上，则通过 Connected Clusters 进行连接部署。下半年 Anthos 将会陆续支持边缘计算节点以及 Azure。

另外，企业 IT 需要一个组织内启动的所有 k8s 集群的总控制平面，Anthos 也提供了这样一个元控制平面，AnthosControl Plane：该组件是 Anthos 的元控制平面，它负责管理托管集群的生命周期以及外部非托管集群的注册和取消注册。

Google 发布 Anthos 的核心意图是帮助企业实现应用程序的现代化，作为 Google Cloud 云战略的核心，它希望未来所有的应用程序都将运行在 k8s 上，作为云厂商巨头之一，支持多个公有云，通过 k8s 生态向企业级拓展，也是 Google Cloud 实现弯道超车的重要举措。

应对挑战，利用 Anthos 实现多集群统一管理

企业希望打造低延迟、高可用的服务，在不同的地域部署，希望应用能尽可能的靠近用户；或有本地化的数据中心，需要管理数据中心和公有云上的数据；以及多租户环境 / 多云环境等多集群场景……实际需求催生集群分离，不可避免的会用到多 k8s 集群。

什么叫做统一的管理呢？指的是不管是在 Google Cloud、本地数据中心、其他云厂商部署了 k8s 集群，Anthos 因为有着 ACM、ASM 功能，以及统一的运维管理、统一的 Marketplace，它没有集群管理的限制，都可以进行管理。

先来看一个 Anthos 的典型部署样例，这是在 GKE 和 GKE On-Prem 里搭建的一个环境，两边包含了 k8s 的集群，以及 Istio 和 ACM，可以公用的包括 GCP Marketplace，可以将第三方应用都部署在 k8s 集群上，以及共用 Stackdriver 进行日志和监控，两边打通则是通过 Google 的专线，实现两个集群的统一管理。

Anthos 的配置管理功能 ACM 支持通过集群控制器，修改单个集群、多租户集群和多个容器集群的配置部署。Anthos 服务网格 ASM 功能，可帮助客户在本地或 Google Cloud 上创建和部署服务网格，监控健康状态，实现流量调度。两者都是在实现统一管理上非常重要的功能。

借助 Anthos Config Management 进行配置策略

借助 ACM，运维人员可以跨所有 Anthos GKE 集群大规模创建和推行通用配置和策略。这个基于 GitOps 的组件支持中心化的机制，可以将部署、配置和策略推送到所有参与的集群。它采用声明式方式而非命令式操作，在每个集群中运行的 ACM 代理会监视集群状态与 Git 仓库的状态差异，当发现集群与 Git 中定义的不同时，代理会自动应用配置，将集群同步到 Git 所定义的状态，从而保证所有纳管集群都处于一个确定并一致的状态。

（Anthos Config Management 架构）

如上图所示，ACM 被部署为每个 Anthos GKE 集群中的自定义控制器，并且包含三个关键组件:

从 Git 中央代码库读取数据的导入器
用于将存储的配置数据同步并合并到 Kubernetes 对象中的一个组件
监控存储的有效集群配置之间的漂移并根据需要进行协调的一个组件

Git 中央配置和策略代码库可以托管在本地或 Google Cloud 上，也可以使用任何托管式 Git 服务提供方 (例如，GitLab 或 Github)。唯一的要求是导入器组件必须能与 Git 代码库建立网络连接。

利用 Anthos Service Mesh 监控和管理服务

这个组件是为 Anthos 优化的 Istio 服务网格的商用实现。它提供三种功能：1）统一的可视化界面；2）容器之间 (东西向) 和集群内外 (南北向) 的访问控制，并保证操作的敏捷性和准确性；3）微服务之间的安全通信：传输中加密，使用服务身份进行服务的认证和授权，保证通讯的数据安全和可信。

与其他服务网格平台一样，ASM 依赖于两个主要组件: 数据层面和控制层面。在 ASM 部署中，数据层面作为一组分布式代理部署，可调解各项服务之间的所有入站和出站网络流量；控制层面作为全托管式服务在 GKE 集群外运行，这样可缩减管理开销，并确保尽可能实现最高的可用性。

但是国内开发者对 Service Mesh 服务网格的关注度还不是很高。现在云原生的理念普及是进行时，企业对新技术的应用也有观望的态度。一个原因是出现时间短，对于其真正在业务上能够提升或帮助哪些不够明晰。

而且在采用服务网格技术之前，应用团队需要构建对常见的管理、网络或安全功能 (例如服务的身份验证 / 授权控制机制、加密服务通信或精细化流量管理) 的支持等，增加了使用难度和管理复杂度。

但是，对 Service Mesh 服务网格技术，开发者可以做到先知后用，技术的布道永远是漫长的过程。

多土壤生存，因为 Anthos 部署应用的灵活性

在 Anthos 的核心组件中，最上层是面向开发者的应用开发层，其重要的技术亮点就是无服务器架构。

Google Cloud 非常好地支持了 Knative，Knative 是基于 k8s 的开源运营平台，可为集群引入无服务器应用服务和事件处理功能。Knative 最初由 Google 打造，现在有 50 多家不同公司向其贡献过代码。而 Cloud Run 就是 Anthos 里基于 Knative 的一种 serverless 服务。

借助 Cloud Run for Anthos 随时随地享受无服务器服务

在 k8s 上运行微服务时开发者可能面临很多难题。k8s 本身只提供容器编排服务，而应用开发者需要的是更加高级的功能来帮助他们实现基于应用层的负载均衡、自动伸缩、版本切换比如灰度发布，回滚，流量镜像、事件处理等与具体业务无关的需求。如果仅仅使用 k8s，开发者将不得不把精力投入到解决这些问题上，而不能专注于解决业务问题。

有了 Cloud Run，事情就变得不一样了：只需向这些平台提供你的部署单元 (函数、应用或容器映像)，平台的基础架构就可以搞定运行和扩缩应用涉及的一切工作。开发人员可以将更多的精力投入到解决业务需求中，极大的提升生产力。

展望

面向未来，Google 设想，未来所有企业应用程序都将在 k8s 上运行。为此，它买下了 Velostrata 等技术，这些技术可以直接把 VM 变成容器。在现在这个能力也被集成进 Anthos，Migrate for Anthos 这个组件可以把 VM 变成 Docker，迁移到 k8s 集群中去。

未来，Anthos 还将允许其客户管理在第三方云服务 (例如 AWS 和 Azure) 上运行的工作负载，Anthos 可能会因其运行的灵活性而在其他云计算平台上生存下来，为其客户提供在自己的硬件或云服务中部署、管理和运行其应用程序的位置的选择。

想了解更多关于 Google Cloud 和 Anthos 的内容，关注 Google Cloud 技术专区。

创作场景

Google 早已看到未来多容器的挑战，利用 Anthos 能否实现多集群