“大規模Kubernetes叢集”主要體現在幾十個Kubernetes叢集，十萬級別的Kubernetes Worker節點。螞蟻金服使用Operator的模式去運維Kubernetes叢集，能便捷、自動化的管理Kubernetes叢集生命週期，做到“Kubernetes as a Service”。

1、Kubernetes架構介紹

此章節簡單介紹了Kubernetes叢集的架構，主要是面向剛學習Kubernetes的同學，對於熟悉Kubernetes的同學，此章節可以跳過。

如上圖，一個Kubernete叢集由Master節點和Worker節點組成。

在一個高可用Kubernetes叢集下面，Master節點一般為3臺，在它們上面需要執行Kubernetes Master元件。Kubernetes Master元件包括etcd、Apsierver、Scheduler和Controller-Manager。每個Master元件一般都是3個例項，以保證它們的高可用。Master節點使用Static Pod方式啟動Master元件，即將每個元件的Pod描述檔案放入Master節點的指定目錄，Kubelet會在啟動時將它們讀取，並以Static Pod方式啟動。

Kubernetes Worker節點為Kubernetes叢集提供排程資源和應用執行環境，即所有的Pod（可以理解為應用的一個個最小化部署單元）都執行在Worker節點上。一個Worker節點將Pod執行上去需要一些on-host軟體，包括: kubelet、Runtime Service（docker、pouch等實現方案）、CNI外掛等。

2、Operator介紹

我們在這裡將用很少的篇幅向剛學習Kubernetes的同學介紹一下Operator。如果期望獲得更詳細的解讀，請參考coreos上關於Operator的介紹。

一個Operator實際上是為了解決某個複雜應用在Kubernetes的自動化部署、恢復。有了Operator，使用者只需要向Kubernetes Apiserver提交一個CRD Resource（yaml或者JSON，一個CRD Resource其實就是對應一個應用例項，CRD Resource用於描述這個應用例項的配置），Operator就會根據使用者的需求去完成這個應用例項的初始化，在應用某個模組發生故障時，Operator也會做出自動恢復功能。Operator是用程式碼運維應用最好的實踐之一。

比如我們有一個etcd-operator，我們只需要使用者根據需求向Kubernetes Apiserer提交如下的CRD Resource，etcd-operator就能初始化完成一個etcd叢集:

apiVersion: etcd.database.coreos.com/v1beta2kind: EtcdClustermetadata: name: xxx-etcd-clusterspec: size: 5

其中，上面的Spec.Size=5代表了我們需要一個由5個etcd節點組成的etcd叢集。etcd-operator會根據上面的配置，初始化完成etcd叢集。相應的，如果你又需要另一個3節點的etcd叢集，你只需要提交新的一個Spec.Size=3的CRD Resource即可。

在螞蟻金服，我們面臨著需要運維幾十個Kubernetes叢集，以及十萬級別以上的Kubernetes Worker節點的難題。

我們將運維Kubernetes的工作拆分兩部分：

我們總結了這兩部分運維的難點：

難點1：運維Kubernetes叢集Master角色

難點2：運維Kubernetes Worker節點

在實現方案的選擇上，我們使用了Kube-on-Kube-Operator和Node-Operator組合的方式來解決上述的難題：

“元叢集”只用於管理所有“業務叢集”所需的Master元件。“業務叢集”是真正提供給業務方執行Pod的Kubernetes叢集。也就說，在螞蟻金服我們只有一個“元叢集”， 在這個“元叢集”中，我們使用Kube-on-Kube-Operator自動化管理了螞蟻金服所有的“Kubernetes 業務叢集”的Master元件。

當然，“元叢集”也會部署Node-Operator，用於“元叢集”Worker節點的上下線，“元叢集”的Worker節點也是各個“業務叢集”的Master節點。

1、Kube-on-Kube-Operator

Kube-on-Kube-Operator用於Watch Cluster CRD Resource的變更，將“Cluster”所描述表示的Kubernetes業務叢集的所有Master元件達到最終狀態。如下圖，是“元叢集”和它所管理的兩個“Kubernetes 業務叢集”的最終狀態：

Cluster CRD的定義包含如下一些資訊：

一個業務叢集的Master元件部署實際是元叢集中的一系列Resource組成，即包括Deployment、Secret、Pod、PVC等組合使用。各Master元件所需要的部署Resource如下：

Kube-on-Kube-Operator除了能夠部署上述的Master元件之外，還能維護任何擴充套件元件，如kube-proxy、kube-dns等。只需要使用者提供擴充套件元件部署模板和擴充套件外掛版本，Kube-on-Kube-Operator能渲染出部署Resource，並保持這些部署Resource到最終態。由於篇幅原因，我們這裡不再贅述。

2、Node-Operator

Node-Operator用於Watch Machine CRD Resource的變更，將“Machine”所描述表示的Worker節點上的on-host軟體（docker、kubelet、cni）達到最終態，最終能讓“Machine”所對應的“Node”在Kubernetes叢集中達到“Ready”狀態。架構圖如下:

Machine CRD的定義包含如下一些資訊：

Node-Operator用Watch Machine對應Node的狀態，當發生一些能處理的Condition（比如kubelet執行中程序消失了）時，Node-Operator會做出恢復處理；Node-Operator會Watch ClusterPackageVersion CRD的變更，這個CRD表示整個Kubernetes叢集kubelet、docker等元件的預設版本，Node-Operator會根據ClusterPackageVersion描述的資訊，控制各個節點的kubelet、docker等元件的版本；Node-Operator還支援控制某些元件灰度釋出到某些節點中，使用者只要提交描述這個灰度釋出的CRD到Apiserver，Node-Operator會有序的執行灰度釋出，並將釋出狀態反饋到CRD中。由於篇幅原因，我們不再贅述。

在運維大規模Kubernetes叢集的實踐中，我們擯棄了傳統的模式，使用了Operator模式和麵向Apiserver程式設計。Kubernetes叢集的上下線、升級實現了“Kubernetes as a Service”，就像向雲廠商買一個服務一樣簡單。而Worker節點的運維，使用Operator模式能夠讓我們統一管理元資料，自動化初始化、恢復Worker節點所需元件。