Google 早已看到未來多容器的挑戰(zhàn)，利用 Anthos 能否實現(xiàn)多集群

首次聽到Anthos，是在Cloud Next 2019大會由Google正式推出。不過在它推出的兩年里，大部分開發(fā)者甚至Kubernetes開發(fā)者們都對它不夠熟悉。

一個原因是Anthos雖然推出，但是相關文檔很少而且當時不支持自助服務，在GCP(Google Cloud Platform)控制臺上找不到。但到2020年，情況終于改變，Anthos現(xiàn)在可以在GCP控制臺上使用，相關文檔也進行了豐富。

另一個國內(nèi)開發(fā)者對Anthos比較陌生的原因是：大部分企業(yè)還在尋找好用的Kubernetes(k8s)。而作為k8s的開創(chuàng)者，當大家都在講Docker時，Google已經(jīng)開始講k8s，并有了GKE(Google Kubernetes Engine)這樣的容器管理工具，大家開始講k8s時，Google開始講多容器集群管理，并推出了Anthos這樣的多集群管理平臺。

我們先來看一看它的核心組件，Anthos可以支持在Google Cloud、本地數(shù)據(jù)中心、其他云廠商、邊緣節(jié)點部署。核心組件包括了容器管理Anthos GKE、服務管理ASM(Anthos Service Mesh)、應用部署Cloud Run for Anthos，以及策略管理ACM(Anthos Config Management)和運維管理。其中GKE是Anthos的中央指揮和控制中心。

所以它是一項新技術嗎？不算，因為它的核心組件里都是大家熟悉的技術：基于k8s的GKE、基于Istio的ASM、基于Knative的Cloud Run。官方說法是“一個開放式混合云和多云端應用平臺”。但我們也可以說，Anthos就是一個容器、服務網(wǎng)格、無服務器技術的合集，是“打包”了這些技術的新品牌名稱。它解決的則是多k8s集群的管理問題。

Google在k8s和云原生生態(tài)系統(tǒng)中有著舉足輕重的影響力，Anthos也是圍繞著k8s快速構建的企業(yè)級戰(zhàn)略。

向企業(yè)拓展，Anthos看到未來多容器的挑戰(zhàn)

過去十年，企業(yè)IT面臨著虛擬機(VM)擴張的挑戰(zhàn)。任何有權訪問VMware環(huán)境的用戶、開發(fā)人員或管理員都可以啟動一個新的VM，這就導致企業(yè)內(nèi)部有數(shù)百個VM跨多部門運行，而這些對IT部門不可見，也不由IT部門管理，帶來了難以控制和資源分散的問題。為此，IT部門引進一個工作流，需要部門IT主管批準才能啟動虛擬機。

今天，隨著容器技術的發(fā)展，k8s集群已經(jīng)成為應用程序的新部署邊界。企業(yè)又發(fā)現(xiàn)了k8s集群擴張的問題，大量的集群在自建數(shù)據(jù)中心、公有云、私有云上進行部署，可能每個部門都有多個集群運行在不同的環(huán)境中，這時，IT和DevOps團隊面臨了如何管理多環(huán)境集群的問題。

Google Cloud早已看到了多k8s集群擴張帶來的管理挑戰(zhàn)，如何平衡多計算資源、如何連接多平臺集群在統(tǒng)一平臺管理呢？Anthos的推出就是為了解決這些問題。它可以在各種環(huán)境中啟動托管的k8s集群。

（Anthos的部署選項們）

Anthos已支持和計劃支持的部署環(huán)境如上，如果使用GKE集群，則支持部署在Google Cloud、vSphere數(shù)據(jù)中心、AWS EC2(目前是beta版本)；如果不是使用GKE，而是自己的k8s集群，比如AWS EKS和Azure AKS上，則通過Connected Clusters進行連接部署。下半年Anthos將會陸續(xù)支持邊緣計算節(jié)點以及Azure。

另外，企業(yè)IT需要一個組織內(nèi)啟動的所有k8s集群的總控制平面，Anthos也提供了這樣一個元控制平面，AnthosControl Plane：該組件是Anthos的元控制平面，它負責管理托管集群的生命周期以及外部非托管集群的注冊和取消注冊。

Google發(fā)布Anthos的核心意圖是幫助企業(yè)實現(xiàn)應用程序的現(xiàn)代化，作為Google Cloud云戰(zhàn)略的核心，它希望未來所有的應用程序都將運行在k8s上，作為云廠商巨頭之一，支持多個公有云，通過k8s生態(tài)向企業(yè)級拓展，也是Google Cloud實現(xiàn)彎道超車的重要舉措。

應對挑戰(zhàn)，利用Anthos實現(xiàn)多集群統(tǒng)一管理

企業(yè)希望打造低延遲、高可用的服務，在不同的地域部署，希望應用能盡可能的靠近用戶；或有本地化的數(shù)據(jù)中心，需要管理數(shù)據(jù)中心和公有云上的數(shù)據(jù)；以及多租戶環(huán)境/多云環(huán)境等多集群場景……實際需求催生集群分離，不可避免的會用到多k8s集群。

什么叫做統(tǒng)一的管理呢？指的是不管是在Google Cloud、本地數(shù)據(jù)中心、其他云廠商部署了k8s集群，Anthos因為有著ACM、ASM功能，以及統(tǒng)一的運維管理、統(tǒng)一的Marketplace，它沒有集群管理的限制，都可以進行管理。

先來看一個Anthos的典型部署樣例，這是在GKE和GKE On-Prem里搭建的一個環(huán)境，兩邊包含了k8s的集群，以及Istio和ACM，可以公用的包括GCP Marketplace，可以將第三方應用都部署在k8s集群上，以及共用Stackdriver進行日志和監(jiān)控，兩邊打通則是通過Google的專線，實現(xiàn)兩個集群的統(tǒng)一管理。

Anthos的配置管理功能ACM支持通過集群控制器，修改單個集群、多租戶集群和多個容器集群的配置部署。Anthos服務網(wǎng)格ASM功能，可幫助客戶在本地或Google Cloud上創(chuàng)建和部署服務網(wǎng)格，監(jiān)控健康狀態(tài)，實現(xiàn)流量調(diào)度。兩者都是在實現(xiàn)統(tǒng)一管理上非常重要的功能。

借助Anthos Config Management進行配置策略

借助ACM，運維人員可以跨所有Anthos GKE集群大規(guī)模創(chuàng)建和推行通用配置和策略。這個基于GitOps的組件支持中心化的機制，可以將部署、配置和策略推送到所有參與的集群。它采用聲明式方式而非命令式操作，在每個集群中運行的ACM代理會監(jiān)視集群狀態(tài)與Git倉庫的狀態(tài)差異，當發(fā)現(xiàn)集群與Git中定義的不同時，代理會自動應用配置，將集群同步到Git所定義的狀態(tài)，從而保證所有納管集群都處于一個確定并一致的狀態(tài)。

（Anthos Config Management架構）

如上圖所示，ACM被部署為每個Anthos GKE集群中的自定義控制器，并且包含三個關鍵組件:

從Git中央代碼庫讀取數(shù)據(jù)的導入器

用于將存儲的配置數(shù)據(jù)同步并合并到Kubernetes對象中的一個組件

監(jiān)控存儲的有效集群配置之間的漂移并根據(jù)需要進行協(xié)調(diào)的一個組件

Git中央配置和策略代碼庫可以托管在本地或Google Cloud上，也可以使用任何托管式Git服務提供方(例如，GitLab或Github)。唯一的要求是導入器組件必須能與Git代碼庫建立網(wǎng)絡連接。

利用Anthos Service Mesh監(jiān)控和管理服務

這個組件是為Anthos優(yōu)化的Istio服務網(wǎng)格的商用實現(xiàn)。它提供三種功能：1）統(tǒng)一的可視化界面；2）容器之間(東西向)和集群內(nèi)外(南北向)的訪問控制，并保證操作的敏捷性和準確性；3）微服務之間的安全通信：傳輸中加密，使用服務身份進行服務的認證和授權，保證通訊的數(shù)據(jù)安全和可信。

與其他服務網(wǎng)格平臺一樣，ASM依賴于兩個主要組件:數(shù)據(jù)層面和控制層面。在ASM部署中，數(shù)據(jù)層面作為一組分布式代理部署，可調(diào)解各項服務之間的所有入站和出站網(wǎng)絡流量；控制層面作為全托管式服務在GKE集群外運行，這樣可縮減管理開銷，并確保盡可能實現(xiàn)最高的可用性。

但是國內(nèi)開發(fā)者對Service Mesh服務網(wǎng)格的關注度還不是很高。現(xiàn)在云原生的理念普及是進行時，企業(yè)對新技術的應用也有觀望的態(tài)度。一個原因是出現(xiàn)時間短，對于其真正在業(yè)務上能夠提升或幫助哪些不夠明晰。

而且在采用服務網(wǎng)格技術之前，應用團隊需要構建對常見的管理、網(wǎng)絡或安全功能(例如服務的身份驗證/授權控制機制、加密服務通信或精細化流量管理)的支持等，增加了使用難度和管理復雜度。

但是，對Service Mesh服務網(wǎng)格技術，開發(fā)者可以做到先知后用，技術的布道永遠是漫長的過程。

多土壤生存，因為Anthos部署應用的靈活性

在Anthos的核心組件中，最上層是面向開發(fā)者的應用開發(fā)層，其重要的技術亮點就是無服務器架構。

Google Cloud非常好地支持了Knative，Knative是基于k8s的開源運營平臺，可為集群引入無服務器應用服務和事件處理功能。Knative最初由Google打造，現(xiàn)在有50多家不同公司向其貢獻過代碼。而Cloud Run就是Anthos里基于Knative的一種serverless服務。

借助Cloud Run for Anthos隨時隨地享受無服務器服務

在k8s上運行微服務時開發(fā)者可能面臨很多難題。k8s本身只提供容器編排服務，而應用開發(fā)者需要的是更加高級的功能來幫助他們實現(xiàn)基于應用層的負載均衡、自動伸縮、版本切換比如灰度發(fā)布，回滾，流量鏡像、事件處理等與具體業(yè)務無關的需求。如果僅僅使用k8s，開發(fā)者將不得不把精力投入到解決這些問題上，而不能專注于解決業(yè)務問題。

有了Cloud Run，事情就變得不一樣了：只需向這些平臺提供你的部署單元(函數(shù)、應用或容器映像)，平臺的基礎架構就可以搞定運行和擴縮應用涉及的一切工作。開發(fā)人員可以將更多的精力投入到解決業(yè)務需求中，極大的提升生產(chǎn)力。

展望

面向未來，Google設想，未來所有企業(yè)應用程序都將在k8s上運行。為此，它買下了Velostrata等技術，這些技術可以直接把VM變成容器。在現(xiàn)在這個能力也被集成進Anthos，Migrate for Anthos這個組件可以把VM變成Docker，遷移到k8s集群中去。

未來，Anthos還將允許其客戶管理在第三方云服務(例如AWS和Azure)上運行的工作負載，Anthos可能會因其運行的靈活性而在其他云計算平臺上生存下來，為其客戶提供在自己的硬件或云服務中部署、管理和運行其應用程序的位置的選擇。