vivo大規(guī)模 Kubernetes 集群自動化運維實踐
作者：vivo 互聯(lián)網(wǎng)服務(wù)器團隊-Zhang Rong
一、背景
隨著vivo業(yè)務(wù)遷移到k8s的增長，我們需要將k8s部署到多個數(shù)據(jù)中心。如何高效、可靠的在數(shù)據(jù)中心管理多個大規(guī)模的k8s集群是我們面臨的關(guān)鍵挑戰(zhàn)。kubernetes的節(jié)點需要對os、docker、etcd、k8s、cni和網(wǎng)絡(luò)插件的安裝和配置，維護這些依賴關(guān)系繁瑣又容易出錯。
以前集群的部署和擴縮容主要通過ansible編排任務(wù)，黑屏化操作、配置集群的inventory和vars執(zhí)行ansible playbook。集群運維的主要困難點如下：
需要人工黑屏化集群運維操作，存在操作失誤和集群配置差異。
部署腳本工具沒有具體的版本控制，不利于集群的升級和配置變更。
部署腳本上線需要花費大量的時間驗證，沒有具體的測試用例和CI驗證。
ansible任務(wù)沒有拆分為模塊化安裝，應(yīng)該化整為零。具體到k8s、etcd、addons的等角色的模塊化管理，可以單獨執(zhí)行ansible任務(wù)。
主要是通過二進制部署，需要自己維護一套集群管理體系。部署流程繁瑣，效率較低。
組件的參數(shù)管理比較混亂，通過命令行指定參數(shù)。k8s的組件最多有100以上的參數(shù)配置。每個大版本的迭代都在變化。
本文將分享我們開發(fā)的Kubernetes-Operator，采用K8s的聲明式API設(shè)計，可以讓集群管理員和Kubernetes-Operator的CR資源進行交互，以簡化、降低任務(wù)風(fēng)險性。只需要一個集群管理員就可以維護成千上萬個k8s節(jié)點。
二、集群部署實踐
2.1 集群部署介紹
主要基于ansible定義的OS、docker、etcd、k8s和addons等集群部署任務(wù)。
主要流程如下：
Bootstrap OS
Preinstall step
Install Docker
Install etcd
Install Kubernetes Master
Install Kubernetes node
Configure network plugin
Install Addons
Postinstall setup
上面看到是集群一鍵部署關(guān)鍵流程。當(dāng)在多個數(shù)據(jù)中心部署完k8s集群后，比如集群組件的安全漏洞、新功能的上線、組件的升級等對線上集群進行變更時，需要小心謹慎的去處理。我們做到了化整為零，對單個模塊去處理。避免全量的去執(zhí)行ansible腳本，增加維護的難度。針對如docker、etcd、k8s、network-plugin和addons的模塊化管理和運維，需提供單獨的ansible腳本入口，更加精細的運維操作，覆蓋到集群大部分的生命周期管理。同時kubernetes-operator的api設(shè)計的時候可以方便選擇對應(yīng)操作yml去執(zhí)行操作。
集群部署優(yōu)化操作如下：
（1）k8s的組件參數(shù)管理通過
ConmponentConfig[1]提供的API去標識配置文件。
【可維護性】當(dāng)組件參數(shù)超過50個以上時配置變得難以管理。
【可升級性】對于升級，版本化配置的參數(shù)更容易管理。因為社區(qū)一個大版本的參數(shù)沒有變化。
【可編程性】可以對組件（JSON/YAML）對象的模板進行修補。如果你啟用動態(tài)kubelet配置選項，修改參數(shù)會自動生效，不需要重啟服務(wù)。
【可配置性】許多類型的配置不能表示為key-value形式。
（2）計劃切換到kubeadm部署
使用kubeadm對k8s集群的生命周期管理，減少自身維護集群的成本。
使用kubeadm的證書管理，如證書上傳到secret里減少證書在主機拷貝的時間消耗和重新生成證書功能等。
使用kubeadm的kubeconfig生成admin kubeconfig文件。
kubeadm其它功能如image管理、配置中心upload-config、自動給控制節(jié)點打標簽和污點等。
安裝coredns和kube-proxy addons。
（3）ansible使用規(guī)范
使用ansible自帶模塊處理部署邏輯。
避免使用hostvars。
避免使用delegate_to。
啟用–limit 模式。
等等。
2.2 CI 矩陣測試
部署出來的集群，需要進行大量的場景測試和模擬。保證線上環(huán)境變更的可靠性和穩(wěn)定性。
CI矩陣部分測試案例如下。
（1）語法測試：
ansible-lint
shellcheck
yamllint
syntax-check
pep8
（2）集群部署測試：
部署集群
擴縮容控制節(jié)點、計算節(jié)點、etcd
升級集群
etcd、docker、k8s和addons參數(shù)變更等
（3）性能和功能測試：
檢查kube-apiserver是否正常工作
檢查節(jié)點之間網(wǎng)絡(luò)是否正常
檢查計算節(jié)點是否正常
k8s e2e測試
k8s conformance 測試
其他測試
這里利用了GitLab、gitlab-runner[2]、ansible和kubevirt[3]等開源軟件構(gòu)建了CI流程。
詳細的部署步驟如下：
在k8s集群部署gitlab-runner，并對接GitLab倉庫。
在k8s集群部署Containerized-Data-Importer (CDI)[4]組件，用于創(chuàng)建pvc的存儲虛擬機的映像文件。
在k8s集群部署kubevirt，用于創(chuàng)建虛擬機。
在代碼倉庫編寫gitlab-ci.yaml[5], 規(guī)劃集群測試矩陣。
如上圖所示，當(dāng)開發(fā)人員在GitLab提交PR時會觸發(fā)一系列操作。這里主要展示了創(chuàng)建虛擬機和集群部署。其實在我們的集群還部署了語法檢查和性能測試gitlab-runner，通過這些gitlab-runner創(chuàng)建CI的job去執(zhí)行CI流程。
具體CI流程如下：
開發(fā)人員提交PR。
觸發(fā)CI自動進行ansible語法檢查。
執(zhí)行ansible腳本去創(chuàng)建namespace，pvc和kubevirt的虛擬機模板，最終虛擬機在k8s上運行。這里主要用到ansible的k8s模塊[6]去管理這些資源的創(chuàng)建和銷毀。
調(diào)用ansible腳本去部署k8s集群。
集群部署完進行功能驗證和性能測試等。
銷毀kubevirt、pvc等資源。即刪除虛擬機，釋放資源。
如上圖所示，當(dāng)開發(fā)人員提交多個PR時，會在k8s集群中創(chuàng)建多個job，每個job都會執(zhí)行上述的CI測試，互相不會產(chǎn)生影響。這種主要使用kubevirt的能力，實現(xiàn)了k8s on k8s的架構(gòu)。
kubevirt主要能力如下：
提供標準的K8s API，通過ansible的k8s模塊就可以管理這些資源的生命周期。
復(fù)用了k8s的調(diào)度能力，對資源進行了管控。
復(fù)用了k8s的網(wǎng)絡(luò)能力，以namespace隔離，每個集群網(wǎng)絡(luò)互相不影響。
三、Kubernetes-Operator 實踐
3.1 Operator 介紹
Operator是一種用于特定應(yīng)用的控制器，可以擴展 K8s API的功能，來代表k8s的用戶創(chuàng)建、配置和管理復(fù)雜應(yīng)用的實例?；趉8s的資源和控制器概念構(gòu)建，又涵蓋了特定領(lǐng)域或應(yīng)用本身的知識。用于實現(xiàn)其所管理的應(yīng)用生命周期的自動化。
總結(jié) Operator功能如下：
kubernetes controller
部署或者管理一個應(yīng)用，如數(shù)據(jù)庫、etcd等
用戶自定義的應(yīng)用生命周期管理
部署
升級
擴縮容
備份
自我修復(fù)
等等
3.2 Kubernetes-Operator CR 介紹
kubernetes-operator的使用很多自定義的CR資源和控制器，這里簡單的介紹功能和作用。
【ClusterDeployment】:? 管理員配置的唯一的CR，其中MachineSet、Machine和Cluster它的子資源或者關(guān)聯(lián)資源。ClusterDeployment是所有的配置參數(shù)入口，定義了如etcd、k8s、lb、集群版本、網(wǎng)路和addons等所有配置。
【MachineSet】：集群角色的集合包括控制節(jié)點、計算節(jié)點和etcd的配置和執(zhí)行狀態(tài)。
【Machine】：每臺機器的具體信息，包括所屬的角色、節(jié)點本身信息和執(zhí)行的狀態(tài)。
【Cluster】：和ClusterDeployment對應(yīng)，它的status定義為subresource，減少
clusterDeployment的觸發(fā)壓力。主要用于存儲ansible執(zhí)行器執(zhí)行腳本的狀態(tài)。
【ansible執(zhí)行器】：主要包括k8s自身的job、configMap、Secret和自研的job控制器。其中job主要用來執(zhí)行ansible的腳本，因為k8s的job的狀態(tài)有成功和失敗，這樣job 控制器很好觀察到ansible執(zhí)行的成功或者失敗，同時也可以通過job對應(yīng)pod日志去查看ansible的執(zhí)行詳細流程。configmap主要用于存儲ansible執(zhí)行時依賴的inventory和變量，掛在到j(luò)ob上。secret主要存儲登陸主機的密鑰，也是掛載到j(luò)ob上。
【擴展控制器】：主要用于擴展集群管理的功能的附加控制器，在部署kubernetes-operator我們做了定制，可以選擇自己需要的擴展控制器。比如addons控制器主要負責(zé)addon插件的安裝和管理。clusterinstall主要生成ansible執(zhí)行器。remoteMachineSet用于多集群管理，同步元數(shù)據(jù)集群和業(yè)務(wù)集群的machine狀態(tài)。還有其它的如對接公有云、dns、lb等控制器。
3.3 Kubernetes-Operator 架構(gòu)
vivo的應(yīng)用分布在數(shù)據(jù)中心的多個k8s集群上，提供了具有集中式多云管理、統(tǒng)一調(diào)度、高可用性、故障恢復(fù)等關(guān)鍵特性。主要搭建了一個元數(shù)據(jù)集群的pass平臺去管理多個業(yè)務(wù)k8s集群。在眾多關(guān)鍵組件中，其中kubernetes-operator就部署在元數(shù)據(jù)集群中，同時單獨運行了machine控制器去管理物理資源。
下面舉例部分場景如下：
場景一：
當(dāng)大量應(yīng)用遷移到kubernets上，管理員評估需要擴容集群。首先需要審批物理資源并通過pass平臺生成對應(yīng)machine的CR資源，此時的物理機處于備機池里，machine CR的狀態(tài)為空閑狀態(tài)。當(dāng)管理員創(chuàng)建ClusterDeploment時所屬的MachineSet會去關(guān)聯(lián)空閑狀態(tài)的machine，拿到空閑的machine資源，我們就可以觀測到當(dāng)前需要操作機器的IP地址生成對應(yīng)的inventory和變量，并創(chuàng)建configmap并掛載給job。執(zhí)行擴容的ansible腳本，如果job成功執(zhí)行完會去更新machine的狀態(tài)為deployed。同時跨集群同步node的控制器會檢查當(dāng)前的擴容的node是否為ready，如果為ready，會更新當(dāng)前的machine為Ready狀態(tài)，才完成整個擴容流程。
場景二：
當(dāng)其中一個業(yè)務(wù)集群出現(xiàn)故障，無法提供服務(wù)，觸發(fā)故障恢復(fù)流程，走統(tǒng)一資源調(diào)度。同時業(yè)務(wù)的策略是分配在多個業(yè)務(wù)集群，同時配置了一個備用集群，并沒有在備用集群上分配實例，備用集群并不實際存在。
有如下2種情況：
其它的業(yè)務(wù)集群可以承載故障集群的業(yè)務(wù)，kubernetes-operator不需要執(zhí)行任何操作。
如果其他業(yè)務(wù)集群不能承載故障集群的業(yè)務(wù)。容器平臺開始預(yù)估資源，調(diào)用kubernetes-operator創(chuàng)建集群，即創(chuàng)建
clusterDeployment從備機池里選擇物理機器，觀測到當(dāng)前需要操作機器的IP地址生成對應(yīng)的inventory和變量，創(chuàng)建configmap并掛載給job。執(zhí)行集群安裝的ansible腳本, 集群正常部署完成后開始業(yè)務(wù)的遷移。
3.4 Kubernetes-Operator 執(zhí)行流程
集群管理員或者容器平臺觸發(fā)創(chuàng)建ClusterDeployment的CR，去定義當(dāng)前集群的操作。
ClusterDeployment控制器感知到變化進入控制器。
開始創(chuàng)建machineSet和關(guān)聯(lián)machine 資源。
ClusterInstall 控制器感知ClusterDeployment和Machineset的變化，開始統(tǒng)計machine資源，創(chuàng)建configmap和job，參數(shù)指定操作的ansible yml入口，執(zhí)行擴縮容、升級和安裝等操作。
調(diào)度器感知到j(luò)ob創(chuàng)建的pod資源，進行調(diào)度。
調(diào)度器調(diào)用k8s客戶端更新pod的binding資源。
kubelet感知到pod的調(diào)度結(jié)果，創(chuàng)建pod開始執(zhí)行ansible playbook。
job controller感知job的執(zhí)行狀態(tài)，更新ClusterDeployment狀態(tài)。一般策略下job controller會去清理configmap和job資源。
NodeHealthy感知k8s的node是否為ready，并同步machine的狀態(tài)。
addons 控制器感知集群是否ready，如果為ready去執(zhí)行相關(guān)的addons插件的安裝和升級。
四、總結(jié)
vivo大規(guī)模的K8s集群運維實踐中，從底層的集群部署工具的優(yōu)化，到大量的CI矩陣測試保證了我們線上集群運維的安全和穩(wěn)定性。采用了K8s托管K8s的方式來自動化管理集群（K8s as a service），當(dāng)operator檢測當(dāng)前的集群狀態(tài)，判斷是否與目標一致，出現(xiàn)不一致時，operator會發(fā)起具體的操作流程，驅(qū)動整個集群達到目標狀態(tài)。
當(dāng)前vivo的應(yīng)用主要分布在自建的數(shù)據(jù)中心的多個K8s集群中，隨著應(yīng)用的不斷的增長和復(fù)雜的業(yè)務(wù)場景，需要提供跨自建機房和云的多個K8s集群去運行原云生的應(yīng)用程序。就需要Kubernetes-Operator提供對接公有云基礎(chǔ)設(shè)施、apiserver的負載均衡、網(wǎng)絡(luò)、dns和Cloud Provider 等。需要后續(xù)不斷完善，降低K8s集群的運維難度。