Kubernetes+Federation打造跨多雲管理服務


 Kubernetes日漸普及,在公有雲、私有雲等多個環境中部署kubernetes集群已是常規做法,而隨着環境的復雜多樣和集群數量增長,如何高效地管理這些集群成為新的問題。於是跨多雲管理服務應運而生。

    華為雲高級工程師Fisher在Cloud Native Days China 2019杭州站發表了名為《Kubernetes+Federation打造跨多雲管理服務》的議題,介紹了基於Federation的多雲管理現狀及未來計划。本文整理自Fisher現場分享實錄。

    大家好,我是華為雲的Fisher。今天和大家分享基於Kubernetes+Federation打造跨多雲服務。跨多雲概念在2018年比較火,相信大家或多或少都聽說過,今天主要介紹如何打造跨多雲管理,包括公有雲和私有雲。

    首先介紹場景——PAAS混合雲典型場景。它的需求第一是高可用,業務負載從集群故障中快速恢復;第二是資源容量溢出,單個集群的擴容速度或者是機房的機器擴容速度跟不上應用擴容速度,利用多雲可進行快速擴容;第三是避免廠商綁定,服務只是在一家雲廠商里,假如廠商宕機服務就會中斷,而在多雲上更加保險;第四就是資源池划分,用於私有雲和公有雲,數據根據敏感程度分布到線上或者線下。

這4個需求,也是跨多雲管理服務主要解決的問題。

0409_1.jpg

如上圖場景,就是我剛剛所說的私有雲和公有雲聯動的狀態。運維人員統一應用交付。對於APP用戶來說,是一個平面,可以進行統一訪問控制。

V1版本

    接下來和大家一起看看Federation項目以及Multicluster SIG的發展歷程。

    Kubernetes Federation發展歷程中,15—17年是前期的V1版本。如下圖所示,上面是管理面,下面是被管理的集群。Federated APIServer 兼容Kubernetes的API,通過Federated Controller驅動,將對象同步到各集群。

0409_2.jpg

0409_3.jpg

    上圖為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的演進。

0409_4.jpg

    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

0409_5.jpg

    上圖是服務發現—Multicluster DNS。服務發現主要基於Federation的設計規則,即認為多個集群之間的網絡不一定是通的,因此現在主要是把服務發現的規則配置在華為的DNS服務器上,多個集群通過DNS實現服務發現。

未來計划

    后續我們打算結合Istio實現K8S多雲上多集群的流量治理。第一種方案如下圖,這要求底層是互通的,只需部署一個Istio控制面,就可以watch所有集群的Service。目前這個方案的限制還比較多,因為不同集群的Service網段不能沖突,現階段方案還在規划中。

0409_6.jpg

    Istio還有如下圖所示的另外一種方案:每個集群都部署一個Istio控制面板,把其他集群的服務配置成本集群的外部服務,跨集群群服務類似Istio訪問外部服務,顯然配置是比較繁瑣的,當前也在規划中。

0409_7.jpg

相關服務請訪問:https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM