vivo大規模Kubernetes叢集自動化運維實踐

　　 一、背景

　　隨著vivo業務遷移到k8s的增長，我們需要將k8s部署到多個資料中心。如何高效、可靠地在資料中心管理多個大規模的k8s叢集是我們面臨的關鍵挑戰。kubernetes的節點需要對os、docker、etcd、k8s、cni和網路外掛的安裝和配置，維護這些依賴關係繁瑣又容易出錯。

　　以前叢集的部署和擴縮容主要透過ansible編排任務，黑屏化操作、配置叢集的inventory和vars執行ansible playbook。叢集運維的主要困難點如下：

　　需要人工黑屏化叢集運維操作，存在操作失誤和叢集配置差異。

　　部署指令碼工具沒有具體的版本控制，不利於叢集的升級和配置變更。

　　部署指令碼上線需要花費大量的時間驗證，沒有具體的測試用例和CI驗證。

　　ansible任務沒有拆分為模組化安裝，應該化整為零。具體到k8s、etcd、addons的等角色的模組化管理，可以單獨執行ansible任務。

　　主要是透過二進位制部署，需要自己維護一套叢集管理體系。部署流程繁瑣，效率較低。

　　元件的引數管理比較混亂，透過命令列指定引數。k8s的元件最多有100以上的引數配置。每個大版本的迭代都在變化。

　　本文將分享我們開發的Kubernetes-Operator，採用K8s的宣告式API設計，可以讓叢集管理員和Kubernetes-Operator的CR資源進行互動，以簡化、降低任務風險性，只需要一個叢集管理員就可以維護成千上萬個k8s節點。

　　 二、叢集部署實踐

　　1、叢集部署介紹

　　主要基於ansible定義的OS、docker、etcd、k8s和addons等叢集部署任務。

　　主要流程如下：

　　①Bootstrap OS

　　②Preinstall step

　　③Install Docker

　　④Install etcd

　　⑤Install Kubernetes Master

　　⑥Install Kubernetes node

　　⑦Configure network plugin

　　⑧Install Addons

　　⑨Postinstall setup

　　上面是叢集一鍵部署關鍵流程。當在多個資料中心部署完k8s叢集后，比如叢集元件的安全漏洞、新功能的上線、元件的升級等對線上叢集進行變更時，需要小心謹慎地處理。我們做到了化整為零，對單個模組去處理。避免全量地去執行ansible指令碼，增加維護的難度。針對如docker、etcd、k8s、network-plugin和addons的模組化管理和運維，需提供單獨的ansible指令碼入口，更加精細的運維操作，覆蓋到叢集大部分的生命週期管理。同時kubernetes-operator的api設計的時候可以方便選擇對應操作yml去執行操作。

　　叢集部署最佳化操作如下：

　　1）k8s的元件引數管理透過ConmponentConfig提供的API去標識配置檔案

　　【可維護性】當元件引數超過50個以上時配置變得難以管理。

　　【可升級性】對於升級，版本化配置的引數更容易管理。因為社群一個大版本的引數沒有變化。

　　【可程式設計性】可以對元件（JSON/YAML）物件的模板進行修補。如果你啟用動態kubelet配置選項，修改引數會自動生效，不需要重啟服務。

　　【可配置性】許多型別的配置不能表示為key-value形式。

　　2）計劃切換到kubeadm部署

　　使用kubeadm對k8s叢集的生命週期管理，減少自身維護叢集的成本。

　　使用kubeadm的證書管理，如證書上傳到secret裡減少證書在主機複製的時間消耗和重新生成證書功能等。

　　使用kubeadm的kubeconfig生成admin kubeconfig檔案。

　　kubeadm其它功能如image管理、配置中心upload-config、自動給控制節點打標籤和汙點等。

　　安裝coredns和kube-proxy addons。

　　3）ansible使用規範

　　使用ansible自帶模組處理部署邏輯。

　　避免使用hostvars。

　　避免使用delegate_to。

　　啟用–limit 模式。

　　等等。

　　2、CI 矩陣測試

　　部署出來的叢集，需要進行大量的場景測試和模擬，保證線上環境變更的可靠性和穩定性。

　　CI矩陣部分測試案例如下。

　　1）語法測試

　　ansible-lint

　　shellcheck

　　yamllint

　　syntax-check

　　pep8

　　2）叢集部署測試

　　部署叢集

　　擴縮容控制節點、計算節點、etcd

　　升級叢集

　　etcd、docker、k8s和addons引數變更等

　　3）效能和功能測試

　　檢查kube-apiserver是否正常工作

　　檢查節點之間網路是否正常

　　檢查計算節點是否正常

　　k8s e2e測試

　　k8s conformance 測試

　　其他測試

　　這裡利用了GitLab、gitlab-runner、ansible和kubevirt等開源軟體構建了CI流程。

　　詳細的部署步驟如下：

　　①在k8s叢集部署gitlab-runner，並對接GitLab倉庫。

　　②在k8s叢集部署Containerized-Data-Importer (CDI)元件，用於建立pvc的儲存虛擬機器的映像檔案。

　　③在k8s叢集部署kubevirt，用於建立虛擬機器。

　　④在程式碼倉庫編寫gitlab-ci.yaml, 規劃叢集測試矩陣。　　

　　如上圖所示，當開發人員在GitLab提交PR時會觸發一系列操作。這裡主要展示了建立虛擬機器和叢集部署。其實在我們的叢集還部署了語法檢查和效能測試gitlab-runner，透過這些gitlab-runner建立CI的job去執行CI流程。　　

　　具體CI流程如下：

　　①開發人員提交PR。

　　②觸發CI自動進行ansible語法檢查。

　　③執行ansible指令碼去建立namespace，pvc和kubevirt的虛擬機器模板，最終虛擬機器在k8s上執行。這裡主要用到ansible的k8s模組去管理這些資源的建立和銷燬。

　　④呼叫ansible指令碼去部署k8s叢集。

　　⑤叢集部署完進行功能驗證和效能測試等。

　　⑥銷燬kubevirt、pvc等資源，即刪除虛擬機器，釋放資源。

　　如上圖所示，當開發人員提交多個PR時，會在k8s叢集中建立多個job，每個job都會執行上述的CI測試，互相不會產生影響。這種主要使用kubevirt的能力，實現了k8s on k8s的架構。

　　kubevirt主要能力如下：

　　提供標準的K8s API，透過ansible的k8s模組就可以管理這些資源的生命週期。

　　複用了k8s的排程能力，對資源進行了管控。

　　複用了k8s的網路能力，以namespace隔離，每個叢集網路互相不影響。

　　 三、Kubernetes-Operator 實踐

　　1、Operator 介紹

　　Operator是一種用於特定應用的控制器，可以擴充套件 K8s API的功能，來代表k8s的使用者建立、配置和管理複雜應用的例項。基於k8s的資源和控制器概念構建，又涵蓋了特定領域或應用本身的知識，用於實現其所管理的應用生命週期的自動化。

　　總結 Operator功能如下：

　　1）kubernetes controller

　　2）部署或者管理一個應用，如資料庫、etcd等

　　3）使用者自定義的應用生命週期管理

　　部署

　　升級

　　擴縮容

　　備份

　　自我修復

　　等等

　　2、Kubernetes-Operator CR 介紹　　

　　kubernetes-operator使用很多自定義的CR資源和控制器，這裡簡單地介紹功能和作用。

　　【ClusterDeployment】：管理員配置的唯一的CR，其中MachineSet、Machine和Cluster它的子資源或者關聯資源。ClusterDeployment是所有的配置引數入口，定義瞭如etcd、k8s、lb、叢集版本、網路和addons等所有配置。

　　【MachineSet】：叢集角色的集合包括控制節點、計算節點和etcd的配置和執行狀態。

　　【Machine】：每臺機器的具體資訊，包括所屬的角色、節點本身資訊和執行的狀態。

　　【Cluster】：和ClusterDeployment對應，它的status定義為subresource，減少clusterDeployment的觸發壓力。主要用於儲存ansible執行器執行指令碼的狀態。

　　【ansible執行器】：主要包括k8s自身的job、configMap、Secret和自研的job控制器。其中job主要用來執行ansible的指令碼，因為k8s的job的狀態有成功和失敗，這樣job 控制器很好觀察到ansible執行的成功或者失敗，同時也可以透過job對應pod日誌去檢視ansible的執行詳細流程。configmap主要用於儲存ansible執行時依賴的inventory和變數，掛到job上。secret主要儲存登陸主機的金鑰，也是掛載到job上。

　　【擴充套件控制器】：主要用於擴充套件叢集管理的功能的附加控制器，在部署kubernetes-operator我們做了定製，可以選擇自己需要的擴充套件控制器。比如addons控制器主要負責addon外掛的安裝和管理。clusterinstall主要生成ansible執行器。remoteMachineSet用於多叢集管理，同步後設資料叢集和業務叢集的machine狀態。還有其它的如對接公有云、dns、lb等控制器。

　　3、Kubernetes-Operator 架構

　　vivo的應用分佈在資料中心的多個k8s叢集上，提供了具有集中式多雲管理、統一排程、高可用性、故障恢復等關鍵特性。主要搭建了一個後設資料叢集的pass平臺去管理多個業務k8s叢集。在眾多關鍵元件中，其中kubernetes-operator就部署在後設資料叢集中，同時單獨執行了machine控制器去管理物理資源。

　　下面舉例部分場景如下：

　　場景一：

　　當大量應用遷移到kubernets上，管理員評估需要擴容叢集。首先需要審批物理資源並透過pass平臺生成對應machine的CR資源，此時的物理機處於備機池裡，machine CR的狀態為空閒狀態。當管理員建立ClusterDeploment時所屬的MachineSet會去關聯空閒狀態的machine，拿到空閒的machine資源，我們就可以觀測到當前需要操作機器的IP地址生成對應的inventory和變數，並建立configmap並掛載給job。執行擴容的ansible指令碼，如果job成功執行完會去更新machine的狀態為deployed。同時跨叢集同步node的控制器會檢查當前的擴容的node是否為ready，如果為ready，會更新當前的machine為Ready狀態，才完成整個擴容流程。

　　場景二：

　　當其中一個業務叢集出現故障，無法提供服務，觸發故障恢復流程，走統一資源排程。同時業務的策略是分配在多個業務叢集，同時配置了一個備用叢集，並沒有在備用叢集上分配例項，備用叢集並不實際存在。

　　有如下2種情況：

　　其它的業務叢集可以承載故障叢集的業務，kubernetes-operator不需要執行任何操作。

　　如果其他業務叢集不能承載故障叢集的業務。容器平臺開始預估資源，呼叫kubernetes-operator建立叢集，即建立clusterDeployment從備機池裡選擇物理機器，觀測到當前需要操作機器的IP地址生成對應的inventory和變數，建立configmap並掛載給job。執行叢集安裝的ansible指令碼, 叢集正常部署完成後開始業務的遷移。

　　4、Kubernetes-Operator 執行流程　　

　　1）叢集管理員或者容器平臺觸發建立ClusterDeployment的CR，去定義當前叢集的操作。

　　2）ClusterDeployment控制器感知到變化進入控制器。

　　3）開始建立machineSet和關聯machine資源。

　　4）ClusterInstall控制器感知ClusterDeployment和Machineset的變化，開始統計machine資源，建立configmap和job，引數指定操作的ansible yml入口，執行擴縮容、升級和安裝等操作。

　　5）排程器感知到job建立的pod資源，進行排程。

　　6）排程器呼叫k8s客戶端更新pod的binding資源。

　　7）kubelet感知到pod的排程結果，建立pod開始執行ansible playbook。

　　8）job controller感知job的執行狀態，更新ClusterDeployment狀態。一般策略下job controller會去清理configmap和job資源。

　　9）NodeHealthy感知k8s的node是否為ready，並同步machine的狀態。

　　10）addons控制器感知叢集是否ready，如果為ready去執行相關的addons外掛的安裝和升級。

　　 四、總結

　　vivo大規模的K8s叢集運維實踐中，從底層的叢集部署工具的最佳化，到大量的CI矩陣測試，保證了我們線上叢集運維的安全和穩定性。採用了K8s託管K8s的方式來自動化管理叢集（K8s as a service），operator檢測當前的叢集狀態，判斷是否與目標一致，當出現不一致時，operator會發起具體的操作流程，驅動整個叢集達到目標狀態。

　　當前vivo的應用主要分佈在自建的資料中心的多個K8s叢集中，隨著應用的不斷的增長和複雜的業務場景，需要提供跨自建機房和雲的多個K8s叢集去執行原雲生的應用程式，就需要Kubernetes-Operator提供對接公有云基礎設施、apiserver的負載均衡、網路、dns和Cloud Provider 等，同時也需要後續不斷完善，降低K8s叢集的運維難度。