Kubernetes Cloud Provider演進以及在Azure上的應用

Go中國倪朋飛2018-03-17 11:07:49

作者介紹:倪飛,現於微軟負責Kubernetes OpenSource相關工作,是Kubernetes項目的maintainer。

本文主要是關於 “ 如何讓Kubernetes更好地在公有云平臺上運行 ” 。選擇的主要切入點是Cloud Provider,同時也會介紹一下在Azure中的相關實踐。

圖1 列出了今天分享的主要內容:首先是Kubernetes的介紹;然後是Cloud Provider在Kubernetes中的位置,“究竟是什麼樣的一個東西”,及其過去現在還有未來版本中演進的過程;最後是它在Azure上的實踐。

圖 1

首先看一下kubernetes的架構。它的架構比較直觀,是一個master/slave結構,包括master和node。

圖 2

Master節點中主要有四個組件。首先是Kubernetes中負責數據存儲的部分,即存儲了所有需要持久化數據ETCD。然後是Kubernetes中主要的三個控制層面的組件:API Server,Controller ManagerScheduler。

API Server是整個集群數據訪問的入口,同時也是暴露restful api給用戶的一個接口。並且無論是集群內部還是外部的組件必須通過API Server來訪問數據。

Controller Manager是Kubernetes的“大腦”,換句話說,Kubernetes中所有需要維護狀態一致性相關的工作都是由其來實現的。同時Controller Manager中還包括有維護各種資源的控制器。

Scheduler的作用很直觀,就是把特定的容器調度到特定的節點上。

下面部分是和Node相關的(Slave部分),即容器真正運行的節點,其上也同時運行一些服務,如負責服務發現和負載均衡的kube-proxy,負責容器、鏡像生命週期的Kubelet,負責真正運行鏡像的Container Runtime以及網絡插件Networking Plugins

Kubernetes除了這些核心的組件以外,還有很多豐富的功能,而這些額外的功能都是通過“Addon”的方式來部署的。


接下來就是我們今天所要講述的主題:如何更好地在公有云平臺上運行Kubernetes。這裡就涉及到了Cloud Provider。Cloud Provider在Kubernetes架構中主要所處的位置就是如圖所示加亮的部分:Controller Manager、API Server 和 Kubelet。API Server需要Cloud Provider是因為其中包含了一系列Admission Controller。其中的兩個是需要和Cloud Provider進行交互的:分別是PV Label 和 PV Resize。Controller Manager是和Cloud Provider交互最多的一個組件,它最主要的功能是維護集群和Node的狀態。比如說它可以檢測VM是否存活,然後作出相應的標記;再比如Load Balance相關的服務,創建LB或者Health Check,或者是暴露一個公網IP來讓外網進行訪問。再有就是Kubelet,它在啟動、狀態維護的時候需要去Cloud Provider中查看一些基本的信息,如內網、外網的IP地址,屬於哪一個zone,標籤,所處VM的狀態等信息。

圖 3

讓我們來看一下Cloud Provider。它是Kubernetes中開放給雲服務商的通用接口,包含一系列的API。它存在的主要目的就是為了讓Kubernetes更好地運行在雲平臺上。比如說:在網絡方面,就是上述提到的負載均衡,給負載均衡創建公網IP,給Kubernetes中的各個Node創建路由;存儲上,是提供數據持久化存儲的方式;最後的話還有Node狀態的維護,Node所在VM的狀態、IP的變更等。Kubernetes內部也提供了Cloud Provider的支持。對於國內一些暫無內部支持的廠商,也是有方案支持的。

圖 4

接下來,讓我們來看一下Cloud Provider的架構。正如前所述,Cloud Provider作為一個通用的接口,雲廠商會基於這些接口實現自己的邏輯,然後在這些邏輯之上,Controller Manager會和Cloud Provider進行交互,維護整個集群的四個部分的狀態:Node、Route(路由)、Service(負載均衡、公網IP)、Volume(持久化存儲)。除此之外還有Kubelet。Kubelet會維護Node的狀態和基本信息。最後是API ServeAdmission Controller,包括 PV Label和PV Resize,如果用到這兩個的話需要顯示地使用。凡是用到Cloud Provider,都需要配置這三個組件。

圖 5

來講一下Cloud Provider接口。實際上它是很多接口定義的集合,這些接口定義是由雲廠商自己去實現即可。而這些接口定義又分成不同的組,圖5 中就是這些組。其中PV略有不同,因為其它幾個均是標準的接口,而PV沒有,這主要是因為不同雲廠商所支持的PV也是不同的。因為PV自身的特殊性,所以在Cloud Provider的演進中,也出現了一些問題,後面會進行一些介紹。

圖 6

Instances主要是維護Node的狀態。

圖 7

LoadBalancer主要是和負載均衡相關,在實現的過程中保證最終一致性即可。

圖 8

Cluster以及Zones,這兩個接口主要是為了查詢VM所在的位置,即哪一個集群或者哪一個Zone中,這在多集群管理中是需要的。Routes就是配置路由,也是比較關鍵的一部分。

圖 9

PV接口,不同的雲平臺的實現是不同的,此處舉了一個AzureFile/AzureDisk 的實例。

圖 10

Kubernetes從誕生時,就是一個雲原生的平臺。因此在Cloud Provider在第一個Release版本中就已經定義好了。當然,這個接口也在不斷的演進過程中,功能也得到不斷的豐富,得到不同廠商的支持。

由於Cloud Provider是一系列Go的接口,因此其實現需要提交到Kubernetes的核心代碼庫中。這裡就容易產生了一些問題,這主要是因為雲平臺的數量眾多,根本不可能全部維護。因此從1.6版本開始,就把Cloud Provider核心功能拆分出來,形成一個Cloud-Controller-Manager。它目前還是alpha階段,因此目前還是推薦本文上述的Controller Manager、API Server和Kubelet的方式來實現,但是今後是肯定會往Cloud-Controller-Manager這個方向去演進的。而有了Cloud-Controller-Manager之後,各個雲廠商只需要把接口實現代碼保存在自己的代碼庫中,然後以Addon的方式來使用即可。在1.10後的版本後,計劃就是完全使用Cloud-Controller-Manager。當然這裡還是有一些挑戰的,比如和PV相關的。

接下來是一個更詳細的介紹。

這就是當前的Cloud Provider的架構圖,也是目前所推薦的架構。通過配置Controller Manager、Kubelet 和 API Server來配置Cloud Provider的一些選項,即in-tree Cloud Provider。

圖 11

這是使用 Cloud Controller Manager 來管理。在阿里雲等非 in-tree 的雲服務上,就推薦使用該結構。該結構將Controller Manager、Kubelet 和 API Server都移到Cloud Controller Manager中。雲廠商實現好這些接口後將它們部署到 Kubernetes 集群中,部署格式和上述的Kube Controller Manager是類似的。在這個階段只是將和PV不相關的都挪到Cloud-controller-manager中,但是和PV相關的還是要放在Kube-controller-manager中,這主要是因為PV的接口是沒有統一的定義,這在未來的Cloud Provider中也是有所體現的。

圖 12

在接下來的版本中,會將所有邏輯都移到Cloud-controller-manager中,而Kubelet和Kube-controller-manager這兩個組件就不需要考慮Cloud Provider了。而剛才提到的PV,就放在這裡的Container Storage Interface中來管理。它實際上是一個通用的存儲接口,是由社區規範標準化的一個grpc接口,因此它的實現可以用很多不同語言來實現。而之前和Cloud Provider相關的PV,就可以通過這個CSI的方式來實現,這樣PV和Kubernetes就實現瞭解耦。

說到CSI,實際上現在社區中擴展Volume還有另外一種方式,Flex Volume。它的目的和CSI一樣,都是為了方便存儲提供商給Kubernetes提供一些存儲的架構,並且在提供存儲支持時,不需要修改Kubernetes的核心代碼。Flex Volume的一個缺點是,在部署時需要以二進制文件的形式來部署,而這些二進制文件本身的管理是相當麻煩的,CSI是沒有這個缺點的。

圖 13

最後一部分是介紹Kubernetes Cloud Provider在Azure中的實踐。Kubernetes在1.4版本的時候就加入了Azure Cloud Provider中,實現了上述所有的接口,同時支出AzureFile和AzureDisk持久化存儲,還支持一些額外的功能。

在Azure上一系列的容器服務,如AKS、Azure Container Service Engine 和ACS 等使用了 Azure  Cloud Provider。AKS目前是在preview階段,18年上半年會 GA。AKS主要是提供一個託管的Kubernetes集群,並且其控制平面是完全免費。它的控制平面是保證了高可用的,後期的更新維護是完全不用用戶操心的。Azure Container Service Engine 是一個開源的項目,在github上叫acs-engine,通過該項目可以在Azure上部署自己管理的Kubernetes集群。它的好處是,用戶可以完全自己來管理Kubernetes。最後的ACS實際上是一個老版本的Azure Container Service,在AKS GA之後,還是推薦使用AKS。

圖 14

來看一些配置相關的。即在使用Cloud Provider的時候需要對Kubelet、Kube-controller-manager和API Server中的配置。如指定所需要使用的雲平臺類型、認證密鑰的參數。還有是配置格式,儘管參數繁多,但當前的雲平臺大多是幫用戶配置好了這些參數,不需要用戶去操心。

Azure上支持如下兩種持久化存儲方式:AzureFile和AzureDisk。

AzureFile是基於SMB協議,它的最大的一個好處就是支持跨主機共享。同時對於Windows Server支持Cache。圖15中可以看到一個AzureFile實例。

圖 15

AzureDisk相當於是一個Block設備,首先會掛載到Node所在的VM上。AzureDisk在Azure中使用時,首先需要一個存儲賬戶。這個賬戶可以由用戶來管理(Blob Disk),也可以由平臺來管理(Managed Disk)。AzureDisk的缺點,是它不支持共享。不過它的性能相比AzureFile會更好一些。

圖 16

圖 17

圖17是一個AzureDisk實例。同時說到應用的話,還有一個重要的點就是負載均衡。它主要是為LoadBalancer 服務分配公網IP和負載均衡器、健康檢查器。圖18中列出的一個子集。

圖 18

這是我今天講的內容,今天講的內容比較粗略的,如果要做自己的cloud provider,可以參考一下設計文檔

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md

也可以看一下我這裡整理的Kubernetes指南

https://github.com/feiskyer/kubernetes-handbook




第四屆 Gopher China 大會4月將在上海舉辦,本屆大會將會3個容器微服務相關的 topic 

相關閱讀:

重磅發佈-2018 Gopher China 議題揭曉

國際名師 William 帶來終極 Go 培訓

Go 語言發展史及史上最全 Go 語言知識圖譜!

Go的2017回顧和2018展望


點擊閱讀原文報名2018 Gopher China 大會,最後一波早鳥票!

4月1日起恢復888原價〜

Go 中國粉絲獨家福利優惠碼GopherChina

報名輸入可享85折優惠!數量有限,先到先得〜


閱讀原文

TAGS: