Kubernetes日漸普及,在公有云、私有云等多個環境中部署kubernetes集羣已經是常規作法,而隨着環境的複雜多樣和集羣數量增加,如何高效地管理這些集羣成爲新的問題。因而跨多雲管理服務應運而生。html
華爲雲高級工程師Fisher在Cloud Native Days China 2019杭州站發表了名爲《Kubernetes+Federation打造跨多雲管理服務》的議題,介紹了基於Federation的多雲管理現狀及將來計劃。本文整理自Fisher現場分享實錄。服務器
你們好,我是華爲雲的Fisher。今天和你們分享基於Kubernetes+Federation打造跨多雲服務。跨多雲概念在2018年比較火,相信你們或多或少都據說過,今天主要介紹如何打造跨多雲管理,包括公有云和私有云。網絡
首先介紹場景——PAAS混合雲典型場景。它的需求第一是高可用,業務負載從集羣故障中快速恢復;第二是資源容量溢出,單個集羣的擴容速度或者是機房的機器擴容速度跟不上應用擴容速度,利用多雲可進行快速擴容;第三是避免廠商綁定,服務只是在一家雲廠商裏,假如廠商宕機服務就會中斷,而在多雲上更加保險;第四就是資源池劃分,用於私有云和公有云,數據根據敏感程度分佈到線上或者線下。架構
這4個需求,也是跨多雲管理服務主要解決的問題。運維
如上圖場景,就是我剛剛所說的私有云和公有云聯動的狀態。運維人員統一應用交付。對於APP用戶來講,是一個平面,能夠進行統一訪問控制。ide
V1版本設計
接下來和你們一塊兒看看Federation項目以及Multicluster SIG的發展歷程。版本控制
Kubernetes Federation發展歷程中,15—17年是前期的V1版本。以下圖所示,上面是管理面,下面是被管理的集羣。Federated APIServer 兼容Kubernetes的API,經過Federated Controller驅動,將對象同步到各集羣。htm
上圖爲V1中RepicaSet的配置,把聯邦的全部配置信息都寫到annotations裏,整個建立流程與Kubernetes相似。配置信息先到Federated APIServer,再經過Federated Schduler調度,最後經過Federated Controller把應用建立到各子集羣。Federated Schduler會根據各集羣的配置比重與集羣中資源的使用狀況進行綜合調度。對象
這個版本的問題是:
聯邦層從新實現K8S API ——致使對象攜帶許多Federation專屬的Annotation;
缺乏獨立的API對象版本控制——K8S Deployment GA,可是Federation v1中的Deployment還是Beta;
原封不動映射K8S API——聯邦層對象在調度、生命週期管理等方面可作的加強點很受限;
V2版本
Federation V2版本,吸收V1的教訓作了不少改進。架構上採用了流行的CRD+Controller模型,其能夠運行在任意Kubernetes集羣中。把Federation專用的Annotation剝離出來做爲獨立的API對象,經過CRD來定義,將K8S對象封裝到Federation API對象裏,這樣不會影響Federation層API的演進。
V2版本總體架構如上圖,有4種類型的CRD:CLuster,Type,Schedule,DNS。
Cluster configuration
首先看集羣註冊,經過Kubefed2 join向聯邦添加集羣,Controller讀取集羣的Context信息,轉化爲Cluster Registry項目定義的Kubernetes Cluster API並保存。Cluster Registry項目對Cluster API對象標準化和加強,將做爲後續多集羣發展的基礎模塊,管理了member集羣的API Endpoint及認證信息等。
Type configuration
再介紹一下Type Configuration,其定義了Federation能夠處理哪些資源對象(在v1版本中靠獨立APIServer來過濾),例如使Federation處理Deployment,就建立一個Deployment Type Configuration,其中包含三個比較重要的點:
① Template:Federated API 中封裝的K8S對象
② Plocement:配置對象實例分佈到哪些集羣
③ Overider:指定集羣中的特定字段定製化,用於解決不一樣的雲廠商之間的配置差別。
Schedule
調度的關鍵是配置了集羣的比重,比重決定了調度時實例的分佈。主要分爲按權重分配和按資源利用狀況分配。
MultiClusterDNS
上圖是服務發現—Multicluster DNS。服務發現主要基於Federation的設計規則,即認爲多個集羣之間的網絡不必定是通的,所以如今主要是把服務發現的規則配置在華爲的DNS服務器上,多個集羣經過DNS實現服務發現。
將來計劃
後續咱們打算結合Istio實現K8S多雲上多集羣的流量治理。第一種方案以下圖,這要求底層是互通的,只需部署一個Istio控制面,就能夠watch全部集羣的Service。目前這個方案的限制還比較多,由於不一樣集羣的Service網段不能衝突,現階段方案還在規劃中。
Istio還有以下圖所示的另一種方案:每一個集羣都部署一個Istio控制面板,把其餘集羣的服務配置成本集羣的外部服務,跨集羣羣服務相似Istio訪問外部服務,顯然配置是比較繁瑣的,當前也在規劃中。
相關服務請訪問:https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019