容器平臺已經(jīng)成為支持應用運維和部署的重要基礎設施，當前 vivo 內部容器平臺共有20+生產(chǎn)集群，管理數(shù)萬物理機節(jié)點，運維管理難度不斷增大。為提升運維效率和穩(wěn)定性，容器團隊開發(fā)了北斗運維管理平臺用于解決大規(guī)模集群運維問題。北斗容器運維管理平臺包含資源管理，集群擴縮容，巡檢，事件中心，監(jiān)控中心等功能。通過這些能力的構建，提升了集群的穩(wěn)定性，從而提升了運維效率，節(jié)省了人力投入。

一、容器建設初期面臨的挑戰(zhàn)

vivo 容器平臺已經(jīng)成為支撐應用運維和部署的重要基礎設施，當前vivo內部容器化平臺共有20+生產(chǎn)集群，管理數(shù)萬物理機節(jié)點，運維管理難度不斷增大，容器集群運維問題主要集中在以下幾個方面：

• 黑屏操作流程復雜：黑屏操作依賴工程師個人技能和經(jīng)驗，容器運維操作流程復雜易出錯。
• 人工巡檢耗時費力：巡檢功能對于集群運維尤為重要，但人工巡檢，耗時費力。
• 多集群管理難度大：隨著業(yè)務的不斷接入，集群數(shù)量不斷增加，多集群的運維難度大。
• 自研組件管理復雜：為擴展平臺能力，自研組件越來越多，對這些組件進行高效管理也成為一個難題。
• 歷史事件查詢困難：大規(guī)模容器集群會產(chǎn)生大量的歷史事件，大量歷史事件的存儲和快速查詢較為困難。

僅靠人工很難運維大規(guī)模的容器化平臺，解決當前面臨的問題需從白屏化和自動化入手，將黑屏操作轉為白屏操作，將復雜的運維操作通過程序實現(xiàn)自動化，進而實現(xiàn)運維操作的標準化，提升整體的運維效率。

二、北斗平臺解決方案

2.1 北斗平臺構建目標

針對大規(guī)模容器集群運維面臨的挑戰(zhàn)，我們開始構建統(tǒng)一的容器集群運維管理平臺，平臺構建目標如下：

• 提升運維操作白屏化率: 實現(xiàn)運維操作白屏化率大于90%，實現(xiàn)高頻運維操作白屏化。
• 實現(xiàn)多集群管理: 實現(xiàn)對不同集群的資源、配置的統(tǒng)一管理。
• 實現(xiàn)自動化巡檢: 可根據(jù)具體運維需求制定巡檢策略，執(zhí)行定期巡檢。
• 實現(xiàn)應用中心：實現(xiàn)自研組件的標準化安裝，實現(xiàn)組件配置、組件版本的統(tǒng)一管理。
• 增強問題定位能力：提供事件查詢，日志查詢，監(jiān)控查詢能力，幫助運維研發(fā)快速定位問題。

基于以上的目標和需求，vivo 容器團隊進行了相關能力和工具的開發(fā)，構建了北斗運維管理平臺。

2.2 北斗平臺能力矩陣

以上為北斗運維平臺的能力矩陣，北斗運維平臺包括運營中心、機器管理、集群管理、集群運維、資源管理、基礎服務幾大核心模塊覆蓋了運維管理的各個維度。

• 運營中心：提供關鍵運營數(shù)據(jù)的展示，嵌入了 Grafana 的監(jiān)控面板，為用戶提供全方位立體化的數(shù)據(jù)監(jiān)控。
• 機器管理：支持對集群節(jié)點的統(tǒng)一管理和白屏操作，支持機器的添加，機器變更記錄的查詢，從而便于把控機器的全生命周期。
• 集群管理：支持對集群的基礎資源、服務組件和應用資源的統(tǒng)一管理，提供創(chuàng)建集群，納管已有集群，節(jié)點自動化擴縮容等能力。
• 集群運維：支持集群巡檢，Etcd 的可視化管理，Etcd 數(shù)據(jù)備份恢復，ip地址池管理，鏡像管理，變更管理等能力。
• 資源管理：支持對集群資源和業(yè)務應用的全方位管理。

三、平臺核心能力構建

3.1 節(jié)點擴縮容工具建設

3.1.1 問題背景

集群節(jié)點的擴容和縮容是頻率較高的運維操作，人工按照文檔進行黑屏操作步驟繁瑣，流程復雜，易出現(xiàn)誤操作，影響集群穩(wěn)定性。因此，實現(xiàn)集群節(jié)點擴縮容自動化成為首要解決的問題。

3.1.2 解決方案

3.1.2.1 集群擴縮容白屏化

為了解決集群擴縮容問題，我們借助了 Kubernetes 控制器模型設計了 kubeops-controller 模塊，用于實現(xiàn)節(jié)點的自動擴縮容和集群安裝。我們將所有的操作抽象為 Kubernetes 的 crd 資源 operation，operation 資源定義如下：

apiVersion: vcluster.caas.xxxx.com/v1alpha1
kind: Operation
  name: scaleup-2024
  namespace: beidou-system
spec:
  clusterName: product-cluster
  operationType: ScaleUp
  operationFlow:
    - preCheck
    - scaleUp
    - postCheck
  operationMachines:
    - ip: 127.0.0.1
      role: Compute
  user: admin

左右滑動查看完整代碼

下圖為擴縮容模塊的架構設計圖。

如架構設計圖所示擴縮容組件包含以下主要模塊：

• beidou-api: 北斗平臺的 API 層，用于接收和響應外部請求。
• kube-apiserver: Kubernetes API 層，負責處理和響應來自集群內部和外部的所有API請求。
• kubeops-controller: 用于處理 operation 擴縮容操作的控制器。
• Job: Job 用于創(chuàng)建和管理一次性任務或定時任務，確保任務能夠成功完成并且不會重復運行，這里主要用于執(zhí)行 Ansible 腳本。

用戶在控制臺創(chuàng)建擴容任務后，beidou-api 會捕捉其中的參數(shù)并調用 Kubernetes 接口創(chuàng)建 operation，operation 中包含了集群標識，待擴縮容節(jié)點，操作類型等信息。kubeops-controller 控制器會監(jiān)聽 operation 的創(chuàng)建，并根據(jù) operation 參數(shù)來執(zhí)行相應的流程任務。kubeops-controller 會依據(jù)擴容或縮容參數(shù)來創(chuàng)建 Job，Job 則會執(zhí)行 Ansible 腳本來自動完成集群安裝和節(jié)點擴縮容任務，其中的 Ansible 腳本是基于 Kubespray 項目進行定制化改造而成。

1）擴容操作

擴容分為三個小步：擴容前檢查，擴容，擴容后檢查。通過三個步驟確保能夠成功擴容集群節(jié)點，每個步驟都會啟動一個 Job 來執(zhí)行 Ansible 腳本完成任務。

• 擴容前檢查：通過 Ansible 腳本來檢查磁盤空間是否夠用，內核版本是否符合需求，是否殘留 kubelet 和 Docker 等進程。通過擴容前檢查來確保節(jié)點能夠順利安裝。
• 擴容：擴容節(jié)點則會執(zhí)行 Ansible 腳本將節(jié)點添加到集群。
• 擴容后檢查：節(jié)點是否處于就緒狀態(tài)，網(wǎng)絡是否連通，確保節(jié)點就緒后，會放開調度投入生產(chǎn)。

2）縮容操作

縮容操作主要分為兩個步驟：縮容前檢查，縮容。

• 縮容前檢查：需要先檢查節(jié)點是否存在業(yè)務 Pod。如果存在業(yè)務 Pod，平臺會提供一鍵遷移業(yè)務功能，避免對業(yè)務造成影響。
• 縮容：執(zhí)行 Ansible 腳本刪除節(jié)點的 kubelet，Docker 等服務，并清理殘留數(shù)據(jù)，確保不影響下次的節(jié)點安裝。

3）節(jié)點健康檢查

在進行運維操作時，需隨時檢查集群節(jié)點的健康狀態(tài)，檢查流程包括網(wǎng)絡偵測、pod 是否可正常創(chuàng)建等，通過這個步驟可進行問題排查。節(jié)點健康檢查是通過執(zhí)行 Ansible 腳本來檢查 kubelet、Docker、kube-proxy 服務的運行狀態(tài)，檢測節(jié)點的網(wǎng)絡連通性。

3.1.2.2 擴縮容全流程自動化

擴縮容白屏化功能的構建解決了黑屏操作存在的問題，但節(jié)點的擴容操作依然涉及多個步驟，即使白屏操作，也無法避免繁瑣的流程。為了進一步節(jié)約人力，提升效率，實現(xiàn)一鍵擴縮容節(jié)點迫在眉睫，我們設計實現(xiàn)了全流程自動化功能。為了實現(xiàn)全流程自動化擴縮容功能，我們在 operation 的上層設計了 autooperationtask crd，autooperationtask 的定義如下:

apiVersion: vcluster.caas.xxxx.com/v1alpha1
kind: AutoOperationTask
metadata:
  name: scaleup-xxxxxx
  namespace: beidou-system
spec:
  cluster: cluster-example
  clusterType: native
  operationIds:
    - scale-up
  operationTaskMachines:
    - name: xx.xx.xx.xx
    - name: xx.xx.xx.xx
  operationTaskStep:
    - step: ScaleUpPreCheck   
    - step: ScaleUpWorkprocess
    - step: ScaleUp
    - step: UncordonNodes
    - step: ScaleUpSubWorkprocess
  operationTaskType: ScaleUp

如上架構圖所示，全流程自動化主要包含如下模塊：

• AutoOperationTask-controller：全流程自動化控制器，會對 autooperationtask 進行處理。
• 網(wǎng)絡模塊: 網(wǎng)絡模塊的作用是處理網(wǎng)絡相關的任務，如調用網(wǎng)絡接口配置節(jié)點網(wǎng)絡
• 任務處理模塊：此模塊的主要作用是根據(jù)需求按順序創(chuàng)建operation。
• kubeops-controller: 任務處理控制器，會對 operation進行處理。

AutoOperationTask-controller會持續(xù)監(jiān)聽autooperationtask crd 的創(chuàng)建事件，任務處理模塊會根據(jù) autotask 定義的流程和步驟，創(chuàng)建 operation（上文提到的對擴縮容等任務的抽象）。kubeops-controller 會監(jiān)聽 operation 的創(chuàng)建，并創(chuàng)建 Job 執(zhí)行腳本。

上圖是可視化的擴縮容流程，通過這種設計，我們將所有能夠順序執(zhí)行的任務簡化成一個自動化任務，全流程自動化將所有的操作串聯(lián)起來，不僅可以節(jié)省人工操作的時間，而且支持實時追蹤任務進程，觀測任務狀態(tài)。

3.1.3 達成效果

通過擴縮容全流程自動化的建設，我們將擴容20臺機器的時間從60分鐘縮短到10分鐘，從原本的人工十幾個步驟才能完成的流程變?yōu)橐绘I部署，且沒有出現(xiàn)過由于人工操作失誤而引入的問題。目前，通過北斗系統(tǒng)執(zhí)行了5000+ 的擴縮容任務，交付了上萬臺機器。未來團隊將持續(xù)優(yōu)化擴容效率，縮短健康檢測時間。

3.2 集群巡檢工具建設

3.2.1 問題背景

集群常會出現(xiàn)一些不可預料的問題，這些問題都嚴重影響集群的穩(wěn)定性。

• 集群節(jié)點問題：cpu, 內存使用率過高，磁盤占滿，內核死鎖，文件系統(tǒng)崩潰等。這些都會導致節(jié)點 Pod 不可用，影響用戶的業(yè)務。及時發(fā)現(xiàn)節(jié)點問題對于運維來說至關重要，盡早介入處理才可以避免更為嚴重的問題發(fā)生。
• 資源配置問題：除了節(jié)點問題外，集群配置問題，證書過期和資源定義不規(guī)范，都可能導致集群不可用，帶來嚴重隱患，為避免這些潛在問題影響到生產(chǎn)環(huán)境，巡檢能力的構建變得尤為重要。

集群巡檢需要具備如下能力：

• Kubernetes資源巡檢：巡檢 Kubernetes 集群的Deployment、StatefulSet 等資源配置是否符合要求。
• 集群節(jié)點巡檢：巡檢節(jié)點磁盤、內存、cpu 使用率、內核日志是否存在問題。
• 自定義腳本巡檢：支持自定義腳本巡檢。

3.2.2 解決方案

為解決如上問題，實現(xiàn)巡檢目標，我們開發(fā)了 kube-doctor 組件來對集群進行巡檢。

上圖為 kube-doctor 的架構設計：

• inspection crd：用于記錄巡檢的基本信息，包括巡檢名稱、巡檢腳本、巡檢集群、巡檢時間、巡檢策略等
• inspection-operator：inspection-operator 控制器會監(jiān)聽 inspection 的創(chuàng)建，并對其進行處理，inspection 會根據(jù) inspection 定義的巡檢時間和巡檢內容，交給 cron-controller 模塊處理。
• cron-controller: cron-controller 負責按照巡檢任務 inspection 定義的巡檢周期驅動 worker 定時執(zhí)行任務，worker則負責具體巡檢任務的執(zhí)行。
• work-pool: worker 資源池，當有新的巡檢任務需執(zhí)行時，cron-controlle 會從 worker 池中獲取 worker，驅動 worker 執(zhí)行定時任務。
• 巡檢驅動：為了支持不同類型和不同場景的巡檢，我們設計了巡檢驅動功能。巡檢驅動需要實現(xiàn)兩個標準的巡檢接口 RunInspectionTask 和 StoreReport。

如下為 go 語言實現(xiàn)的 driver 接口：

type InspectionInterface interface {
    RunInspectionTask(ctx context.Context, cluster []ScheduledCluster) (error, []string, *AlertInfo)
    StoreReport(result interface{}, cluster ScheduledClusteralertMessages *SyncMessages) error
}

左右滑動查看完整代碼

RunInspectionTask 執(zhí)行具體巡檢任務，例如到指定節(jié)點執(zhí)行腳本，并獲取結果。StoreReport 的作用則是存儲巡檢報告，存儲巡檢報告支持將數(shù)據(jù)存儲到 MySQL 或者 Elasticsearch。目前定義了自定義腳本，數(shù)據(jù)指標和節(jié)點指標三種 driver。

• 自定義腳本: 用戶可以自定義的腳本，到指定的集群節(jié)點執(zhí)行，并獲取到執(zhí)行結果。
• 數(shù)據(jù)指標：數(shù)據(jù)指標來自于監(jiān)控模塊 promethuse。
• 節(jié)點指標：獲取 node-problem-detector（用于發(fā)現(xiàn)節(jié)點問題的開源組件） 的執(zhí)行數(shù)據(jù)。

3.2.3 達成效果

目前 kube-doctor 已經(jīng)執(zhí)行了數(shù)千次的巡檢任務，生成數(shù)千份巡檢報告，幫助運維及時發(fā)現(xiàn)容器集群問題。

3.3 應用中心建設

3.3.1 問題背景

隨著業(yè)務的發(fā)展，集群內自研組件的增多使得對組件的管理變得復雜，基于此問題我們需著手構建應用中心能力，對組件進行統(tǒng)一管理。應用中心需要具備如下能力：

• 應用模版管理：支持上傳 Chart 包到 vivo 對象存儲，可發(fā)布到應用中心，發(fā)布成功后支持對 Chart 模版進行更新，按照版本管理。
• 應用部署管理：支持將應用直接部署到不同的集群和 Namespace，部署過程中可監(jiān)聽修改參數(shù)。常用參數(shù)支持配置在 values.yml 文件中直接編輯修改，無需重新打 Chart 包，使部署流程更方便高效。
• 應用實例管理：支持查看應用在哪些集群部署了哪些實例，點擊應用實例可以跳轉到實例詳情，查看實例的配置等相關信息，進行相應的配置修改和升級。

3.3.2 解決方案

為解決如上問題，我們開發(fā)了應用中心功能，將集群中各類組件和服務托管到北斗平臺進行統(tǒng)一管理。通過 Kubernetes 提供的應用安裝管理組件 Helm 執(zhí)行應用的安裝、部署、升級及配置修改等，方便在不同集群中分發(fā)和部署應用，支持服務的全生命周期管理。下圖為應用中心的架構設計：

3.3.2.1 模板管理

為管理應用模板，我們定義了 helmapp CRD和helmappversion CRD。用戶可以上傳 chart 包，前端將解析其內容并傳遞給 beidou-api，以創(chuàng)建 helmapp CRD 并存儲到 vivo 對象存儲系統(tǒng)，同時會創(chuàng)建一個 helmappversion CRD，用于記錄版本和存儲地址，以便進行安裝操作。

• helmapp crd: 用于記錄 chart 包的基本信息，如應用名稱、應用描述、應用 log 等信息。
• helmappversion crd: 用于記錄 chart 包的版本信息和存儲地址，便于安裝包的獲取。

3.3.2.2 實例管理

應用安裝包安裝到集群后會生成一個運行中的應用，也就是一個應用實例，對此我們設計了 release crd 用于表示一個應用實例，通過調用 beidou-api 接口創(chuàng)建 release（實例），控制器監(jiān)聽到創(chuàng)建事件后從 crd 中獲取需要安裝的chart包名稱和版本，并從 vivo 對象存儲系統(tǒng)中獲取 chart 包，從 values 中讀取相關參數(shù)，最后獲取 cluster crd 中的 kubeconfig 數(shù)據(jù)，通過這種方式就能夠將應用安裝到不同集群中。

• release crd：存儲應用實例信息，包括 chart 包名稱、版本等信息
• beidou-release-controller：監(jiān)聽 release 創(chuàng)建事件，并對 release 進行處理。
• values: release spec 中定義的應用配置參數(shù)。

3.3.3 達成效果

目前通過應用中心管理的應用達到了50+，管理的應用實例達到200+，實現(xiàn)了降低組件管理復雜度，提升管理效率，且與AI和數(shù)據(jù)部門合作用于復雜應用的部署和管理。

3.4 事件采集和監(jiān)控體系構建

3.4.1 問題背景

在 Kubernetes 中，事件（Events）是集群在特定對象上發(fā)生的特定時間點上的狀態(tài)變化記錄。事件涵蓋有關 Pod 的調度決策、Container 的狀態(tài)變化、節(jié)點的壓力情況等重要信息。事件可幫助開發(fā)工程師和集群運維工程師理解集群內部發(fā)生的事件。通過 Kubernetes 中的事件，可快速發(fā)現(xiàn)和定位問題。但當前集群的事件都存儲于 Etcd，事件查看較為麻煩，由于 Etcd 空間限制，無法長期存儲事件，這些問題為追溯歷史問題造成困難。

3.4.2 解決方案

針對此問題，平臺開發(fā)了事件采集存儲組件 beidou-event，上圖 beidou-event 架構圖。

• beidou-event: beidou-event模塊會實時監(jiān)聽kube-apiserver 的事件，并將事件按照一定的格式輸出到主機的某一個目錄。
• vivo 日志系統(tǒng)：vivo 日志系統(tǒng)由 vivo 開發(fā)用于專門的日志采集和存儲的系統(tǒng)，這里也可以使用ELK等日志采集方案。
• Elasticsearch: vivo 日志系統(tǒng)采集完數(shù)據(jù)后會將數(shù)據(jù)存儲到Elasticsearch。
• Beidou-api: beidou-api 會調用 Elasticsearch 獲取事件數(shù)據(jù)并在前端作展示。

3.4.3 達成效果

當前 Elasticsearch 保持在30億+的事件數(shù)量，歷史事件的查詢幫助運維和研發(fā)快速定位歷史問題，在問題追溯上發(fā)揮了重要作用。

四、總結與展望

經(jīng)過幾年的能力建設，我們基本實現(xiàn)了北斗平臺構建目標。

• 90%以上高頻操作實現(xiàn)白屏化：北斗運維平臺已經(jīng)將90%的黑屏運維操作實現(xiàn)白屏化。各種高頻率文件配置，資源配置，資源調整，問題定位都可以通過北斗運維管理平臺進行。操作人，操作內容皆可通過審計功能進行追溯。
• 集群安裝和擴縮容工具大幅提效：通過北斗平臺安裝數(shù)個k8s集群，擴容了上萬臺機器。標準化的程序執(zhí)行規(guī)避了由于人為操作導致的失誤，保證了集群的穩(wěn)定性和可靠性。通過白屏化簡化了操作流程，擴容由原本的人工執(zhí)行十幾個步驟，實現(xiàn)了一鍵擴縮容，縮減了擴縮容時間，提升了運維的效率。
• 運營中心實現(xiàn)全方位運營監(jiān)控：通過運營中心的資源概覽和監(jiān)控功能可幫助及時掌握集群數(shù)量，集群規(guī)模，資源填充率，集群資源使用情況等關鍵指標，便于對資源進行治理，避免由于資源問題影響業(yè)務。
• 巡檢能力助力問題及時發(fā)現(xiàn)解決：集群巡檢功能自投入使用已經(jīng)生成了3000+份的巡檢報告，詳細記錄了巡檢過程中發(fā)現(xiàn)的不符合規(guī)范和巡檢規(guī)則的風險項。通過巡檢功能及時發(fā)現(xiàn)集群存在的不穩(wěn)定因素，幫助運維同事及時排除問題。
• 事件采集助力集群問題排查：事件采集和查詢功能在問題定位過程發(fā)揮重要作用，為問題的解決提供重要線索。同時，事件中心歸納了核心且關鍵的事件指標，便于掌控集群的運行狀況。
• 應用中心標準化組件安裝：應用中心功能管理所有的自研組件，組件的安裝、升級和配置修改變得更加便利。同時，此功能開放給高級用戶用于復雜應用的部署。

北斗容器自動化運維平臺的構建進一步解放了人力，提升了運維效率，支撐了上萬臺機器數(shù)十個容器集群的運維。容器運維平臺未來會向智能化自動化方向發(fā)展，實現(xiàn)平臺自動偵測問題，解決問題，結合人工智能技術，提供更加智能的運維平臺，進一步提升運維效率和集群穩(wěn)定性。