Google 早已看到未来多容器的挑战，利用 Anthos 能

小提示：您能找到这篇{Google 早已看到未来多容器的挑战，利用 Anthos 能}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Google 早已看到未来多容器的挑战，利用 Anthos 能内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

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

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

< font-size: 16px;">另一个国内开发者对Anth网络营销搜索引擎os比较陌生的原因是：大部分企业还在寻找好用的Kubernetes(k8s)。而作为k8s的开创者，当大家都在讲Docker时，Google已经开始讲k8s，并有了GKE(Google Kubernetes Engine)这样的容器管理工具，大家开始讲k8s时，Google开始讲多容器集群管理，并推出了Anthos这样的多集群管理平台。

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

< font-size: 16px;">

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

< font-size: 16px;">Google在k8s和云原生生态系统中有着举足轻重的影响力，Anthos也是围绕着k8s快速构建的企业级战略。

< font-size: 16px;">向企业拓展，Anthos看到未来多容器的挑战

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

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

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

< font-size: 16px;">

< font-size: 16px;">（Anthos的部署选项们）

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

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

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

< font-size: 16px;">应对挑战，利用Anthos实现多集群统一管理

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

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

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

< font-size: 16px;">

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

< font-size: 16px;">借助Anthos Config Management进行配置策略

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

< font-size: 16px;">

< font-size: 16px;">（Anthos Config Management架构）

< font-size: 16px;">如上图所示，ACM被部署为每个Anthos GKE集群中的自定义控制器，并且包含三个关键组件:

< font-size: 16px;">从Git中央代码库读取数据的导入器

< font-size: 16px;">用于将存储的配置数据同步并合并到Kubernetes对象中的一个组件

< font-size: 16px;">监控存储的有效集群配置之间的漂移并根据需要进行协调的一个组件

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

< font-size: 16px;">利用Anthos Service Mesh监控和管理服务

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

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

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

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

< font-size: 16px;">但是，对Service Mesh服务网格技术，开发者可以做到先知后用，技术的布道永远是漫长的过程。

< font-size: 16px;">多土壤生存，因为Anthos部署应用的灵活性

< font-size: 16px;">在Anthos的核心组件中，最上层是面向开发者的应用开发层，其重要的技术亮点就是无服务器架构。

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

< font-size: 16px;">借助Cloud Run for Anthos随时随地享受无服务器服务

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

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

< font-size: 16px;">展望

< font-size: 16px;">面向未来，Google设想，未来所有企业应用程序都将在k8s上运行。为此，它买下了Velostra舆情预警ta等技术，这些技术可以直接把VM变成容器。在现在这个能力也被集成进Anthos，Migrate for Anthos这个组件可以把VM变成Docker，迁移到k8s集群中去。

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