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

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

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

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

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

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

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

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

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

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

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

（Anthos的部署選項(xiàng)們）

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

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

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

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

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

什么叫做統(tǒng)一的管理呢？指的是不管是在Google Cloud、本地?cái)?shù)據(jù)中心、其他云廠商部署了k8s集群，Anthos因?yàn)橛兄鳤CM、ASM功能，以及統(tǒng)一的運(yùn)維管理、統(tǒng)一的Marketplace，它沒有集群管理的限制，都可以進(jìn)行管理。

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

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

借助Anthos Config Management進(jìn)行配置策略

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

（Anthos Config Management架構(gòu)）

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

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

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

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

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

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

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

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

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

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

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

多土壤生存，因?yàn)锳nthos部署應(yīng)用的靈活性

在Anthos的核心組件中，最上層是面向開發(fā)者的應(yīng)用開發(fā)層，其重要的技術(shù)亮點(diǎn)就是無服務(wù)器架構(gòu)。

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

借助Cloud Run for Anthos隨時(shí)隨地享受無服務(wù)器服務(wù)

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

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

展望

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

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