InfoQ|Google早已看到未来多容器的挑战，利用Anthos能否实现多集群统一管理？( 二 )

2应对挑战，利用 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 进行配置策略【InfoQ|Google早已看到未来多容器的挑战，利用Anthos能否实现多集群统一管理？】借助 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 服务网格的关注度还不是很高。现在云原生的理念普及是进行时，企业对新技术的应用也有观望的态度。一个原因是出现时间短，对于其真正在业务上能够提升或帮助哪些不够明晰。