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

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

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

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

僅靠人工很難運(yùn)維大規(guī)模的容器化平臺(tái)，解決當(dāng)前面臨的問(wèn)題需從白屏化和自動(dòng)化入手，將黑屏操作轉(zhuǎn)為白屏操作，將復(fù)雜的運(yùn)維操作通過(guò)程序?qū)崿F(xiàn)自動(dòng)化，進(jìn)而實(shí)現(xiàn)運(yùn)維操作的標(biāo)準(zhǔn)化，提升整體的運(yùn)維效率。

二、北斗平臺(tái)解決方案

2.1 北斗平臺(tái)構(gòu)建目標(biāo)

針對(duì)大規(guī)模容器集群運(yùn)維面臨的挑戰(zhàn)，我們開(kāi)始構(gòu)建統(tǒng)一的容器集群運(yùn)維管理平臺(tái)，平臺(tái)構(gòu)建目標(biāo)如下：

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

基于以上的目標(biāo)和需求，vivo 容器團(tuán)隊(duì)進(jìn)行了相關(guān)能力和工具的開(kāi)發(fā)，構(gòu)建了北斗運(yùn)維管理平臺(tái)。

2.2 北斗平臺(tái)能力矩陣

以上為北斗運(yùn)維平臺(tái)的能力矩陣，北斗運(yùn)維平臺(tái)包括運(yùn)營(yíng)中心、機(jī)器管理、集群管理、集群運(yùn)維、資源管理、基礎(chǔ)服務(wù)幾大核心模塊覆蓋了運(yùn)維管理的各個(gè)維度。

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

三、平臺(tái)核心能力構(gòu)建

3.1 節(jié)點(diǎn)擴(kuò)縮容工具建設(shè)

3.1.1 問(wèn)題背景

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

3.1.2 解決方案

3.1.2.1 集群擴(kuò)縮容白屏化

為了解決集群擴(kuò)縮容問(wèn)題，我們借助了 Kubernetes 控制器模型設(shè)計(jì)了 kubeops-controller 模塊，用于實(shí)現(xiàn)節(jié)點(diǎn)的自動(dòng)擴(kuò)縮容和集群安裝。我們將所有的操作抽象為 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

左右滑動(dòng)查看完整代碼

下圖為擴(kuò)縮容模塊的架構(gòu)設(shè)計(jì)圖。

如架構(gòu)設(shè)計(jì)圖所示擴(kuò)縮容組件包含以下主要模塊：

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

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

1）擴(kuò)容操作

擴(kuò)容分為三個(gè)小步：擴(kuò)容前檢查，擴(kuò)容，擴(kuò)容后檢查。通過(guò)三個(gè)步驟確保能夠成功擴(kuò)容集群節(jié)點(diǎn)，每個(gè)步驟都會(huì)啟動(dòng)一個(gè) Job 來(lái)執(zhí)行 Ansible 腳本完成任務(wù)。

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

2）縮容操作

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

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

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

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

3.1.2.2 擴(kuò)縮容全流程自動(dòng)化

擴(kuò)縮容白屏化功能的構(gòu)建解決了黑屏操作存在的問(wèn)題，但節(jié)點(diǎn)的擴(kuò)容操作依然涉及多個(gè)步驟，即使白屏操作，也無(wú)法避免繁瑣的流程。為了進(jìn)一步節(jié)約人力，提升效率，實(shí)現(xiàn)一鍵擴(kuò)縮容節(jié)點(diǎn)迫在眉睫，我們?cè)O(shè)計(jì)實(shí)現(xiàn)了全流程自動(dòng)化功能。為了實(shí)現(xiàn)全流程自動(dòng)化擴(kuò)縮容功能，我們?cè)?operation 的上層設(shè)計(jì)了 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

如上架構(gòu)圖所示，全流程自動(dòng)化主要包含如下模塊：

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

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

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

3.1.3 達(dá)成效果

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

3.2 集群巡檢工具建設(shè)

3.2.1 問(wèn)題背景

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

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

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

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

3.2.2 解決方案

為解決如上問(wèn)題，實(shí)現(xiàn)巡檢目標(biāo)，我們開(kāi)發(fā)了 kube-doctor 組件來(lái)對(duì)集群進(jìn)行巡檢。

上圖為 kube-doctor 的架構(gòu)設(shè)計(jì)：

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

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

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

左右滑動(dòng)查看完整代碼

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

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

3.2.3 達(dá)成效果

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

3.3 應(yīng)用中心建設(shè)

3.3.1 問(wèn)題背景

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

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

3.3.2 解決方案

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

3.3.2.1 模板管理

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

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

3.3.2.2 實(shí)例管理

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

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

3.3.3 達(dá)成效果

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

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

3.4.1 問(wèn)題背景

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

3.4.2 解決方案

針對(duì)此問(wèn)題，平臺(tái)開(kāi)發(fā)了事件采集存儲(chǔ)組件 beidou-event，上圖 beidou-event 架構(gòu)圖。

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

3.4.3 達(dá)成效果

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

四、總結(jié)與展望

經(jīng)過(guò)幾年的能力建設(shè)，我們基本實(shí)現(xiàn)了北斗平臺(tái)構(gòu)建目標(biāo)。

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

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