壹、背景
隨著vivo業務遷移到k8s的增長，我們需要將k8s部署到多個數據中心。如何高效、可靠的在數據中心管理多個大規模的k8s集群是我們面臨的關鍵挑戰。kubernetes的節點需要對os、docker、etcd、k8s、cni和網絡插件的安裝和配置，維護這些依賴關系繁瑣又容易出錯。
以前集群的部署和擴縮容主要通過ansible編排任務，黑屏化操作、配置集群的inventory和vars執行ansible playbook。集群運維的主要困難點如下：
二、集群部署實踐
2.1 集群部署介紹
主要基於ansible定義的OS、docker、etcd、k8s和addons等集群部署任務。
主要流程如下：
上面看到是集群壹鍵部署關鍵流程。當在多個數據中心部署完k8s集群後，比如集群組件的安全漏洞、新功能的上線、組件的升級等對線上集群進行變更時，需要小心謹慎的去處理。我們做到了化整為零，對單個模塊去處理。避免全量的去執行ansible腳本，增加維護的難度。針對如docker、etcd、k8s、network-plugin和addons的模塊化管理和運維，需提供單獨的ansible腳本入口，更加精細的運維操作，覆蓋到集群大部分的生命周期管理。同時kubernetes-operator的api設計的時候可以方便選擇對應操作yml去執行操作。
集群部署優化操作如下：
（1）k8s的組件參數管理通過
ConmponentConfig[1]提供的API去標識配置文件。
（2）計劃切換到kubeadm部署
（3）ansible使用規範
2.2 CI 矩陣測試
部署出來的集群，需要進行大量的場景測試和模擬。保證線上環境變更的可靠性和穩定性。
CI矩陣部分測試案例如下。
（1）語法測試：
（2）集群部署測試：
（3）性能和功能測試：
這裏利用了GitLab、gitlab-runner[2]、ansible和kubevirt[3]等開源軟件構建了CI流程。
詳細的部署步驟如下：
如上圖所示，當開發人員在GitLab提交PR時會觸發壹系列操作。這裏主要展示了創建虛擬機和集群部署。其實在我們的集群還部署了語法檢查和性能測試gitlab-runner，通過這些gitlab-runner創建CI的job去執行CI流程。
具體CI流程如下：
如上圖所示，當開發人員提交多個PR時，會在k8s集群中創建多個job，每個job都會執行上述的CI測試，互相不會產生影響。這種主要使用kubevirt的能力，實現了k8s on k8s的架構。
kubevirt主要能力如下：
三、Kubernetes-Operator 實踐
3.1 Operator 介紹
Operator是壹種用於特定應用的控制器，可以擴展 K8s API的功能，來代表k8s的用戶創建、配置和管理復雜應用的實例。基於k8s的資源和控制器概念構建，又涵蓋了特定領域或應用本身的知識。用於實現其所管理的應用生命周期的自動化。
總結 Operator功能如下：
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.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種情況：
3.4 Kubernetes-Operator 執行流程
四、總結
vivo大規模的K8s集群運維實踐中，從底層的集群部署工具的優化，到大量的CI矩陣測試保證了我們線上集群運維的安全和穩定性。采用了K8s托管K8s的方式來自動化管理集群（K8s as a service），當operator檢測當前的集群狀態，判斷是否與目標壹致，出現不壹致時，operator會發起具體的操作流程，驅動整個集群達到目標狀態。
當前vivo的應用主要分布在自建的數據中心的多個K8s集群中，隨著應用的不斷的增長和復雜的業務場景，需要提供跨自建機房和雲的多個K8s集群去運行原雲生的應用程序。就需要Kubernetes-Operator提供對接公有雲基礎設施、apiserver的負載均衡、網絡、dns和Cloud Provider 等。需要後續不斷完善，降低K8s集群的運維難度。
本文作者:Zhang Rong 來源:vivo互聯網技術
CIO之家 www.ciozj.com 微信公眾號:imciow