vivo 大規(guī)模容器集群運維平臺實踐
容器平臺已經(jīng)成為支持應(yīng)用運維和部署的重要基礎(chǔ)設(shè)施，當(dāng)前 vivo 內(nèi)部容器平臺共有20+生產(chǎn)集群，管理數(shù)萬物理機(jī)節(jié)點，運維管理難度不斷增大。為提升運維效率和穩(wěn)定性，容器團(tuán)隊開發(fā)了北斗運維管理平臺用于解決大規(guī)模集群運維問題。北斗容器運維管理平臺包含資源管理，集群擴(kuò)縮容，巡檢，事件中心，監(jiān)控中心等功能。通過這些能力的構(gòu)建，提升了集群的穩(wěn)定性，從而提升了運維效率，節(jié)省了人力投入。
一、容器建設(shè)初期面臨的挑戰(zhàn)
vivo 容器平臺已經(jīng)成為支撐應(yīng)用運維和部署的重要基礎(chǔ)設(shè)施，當(dāng)前vivo內(nèi)部容器化平臺共有20+生產(chǎn)集群，管理數(shù)萬物理機(jī)節(jié)點，運維管理難度不斷增大，容器集群運維問題主要集中在以下幾個方面：
- 黑屏操作流程復(fù)雜：黑屏操作依賴工程師個人技能和經(jīng)驗，容器運維操作流程復(fù)雜易出錯。
- 人工巡檢耗時費力：巡檢功能對于集群運維尤為重要，但人工巡檢，耗時費力。
- 多集群管理難度大：隨著業(yè)務(wù)的不斷接入，集群數(shù)量不斷增加，多集群的運維難度大。
- 自研組件管理復(fù)雜：為擴(kuò)展平臺能力，自研組件越來越多，對這些組件進(jìn)行高效管理也成為一個難題。
- 歷史事件查詢困難：大規(guī)模容器集群會產(chǎn)生大量的歷史事件，大量歷史事件的存儲和快速查詢較為困難。
僅靠人工很難運維大規(guī)模的容器化平臺，解決當(dāng)前面臨的問題需從白屏化和自動化入手，將黑屏操作轉(zhuǎn)為白屏操作，將復(fù)雜的運維操作通過程序?qū)崿F(xiàn)自動化，進(jìn)而實現(xiàn)運維操作的標(biāo)準(zhǔn)化，提升整體的運維效率。
二、北斗平臺解決方案
2.1 北斗平臺構(gòu)建目標(biāo)
針對大規(guī)模容器集群運維面臨的挑戰(zhàn)，我們開始構(gòu)建統(tǒng)一的容器集群運維管理平臺，平臺構(gòu)建目標(biāo)如下：
- 提升運維操作白屏化率: 實現(xiàn)運維操作白屏化率大于90%，實現(xiàn)高頻運維操作白屏化。
- 實現(xiàn)多集群管理: 實現(xiàn)對不同集群的資源、配置的統(tǒng)一管理。
- 實現(xiàn)自動化巡檢: 可根據(jù)具體運維需求制定巡檢策略，執(zhí)行定期巡檢。
- 實現(xiàn)應(yīng)用中心：實現(xiàn)自研組件的標(biāo)準(zhǔn)化安裝，實現(xiàn)組件配置、組件版本的統(tǒng)一管理。
- 增強(qiáng)問題定位能力：提供事件查詢，日志查詢，監(jiān)控查詢能力，幫助運維研發(fā)快速定位問題。
基于以上的目標(biāo)和需求，vivo 容器團(tuán)隊進(jìn)行了相關(guān)能力和工具的開發(fā)，構(gòu)建了北斗運維管理平臺。
2.2 北斗平臺能力矩陣
以上為北斗運維平臺的能力矩陣，北斗運維平臺包括運營中心、機(jī)器管理、集群管理、集群運維、資源管理、基礎(chǔ)服務(wù)幾大核心模塊覆蓋了運維管理的各個維度。
- 運營中心：提供關(guān)鍵運營數(shù)據(jù)的展示，嵌入了 Grafana 的監(jiān)控面板，為用戶提供全方位立體化的數(shù)據(jù)監(jiān)控。
- 機(jī)器管理：支持對集群節(jié)點的統(tǒng)一管理和白屏操作，支持機(jī)器的添加，機(jī)器變更記錄的查詢，從而便于把控機(jī)器的全生命周期。
- 集群管理：支持對集群的基礎(chǔ)資源、服務(wù)組件和應(yīng)用資源的統(tǒng)一管理，提供創(chuàng)建集群，納管已有集群，節(jié)點自動化擴(kuò)縮容等能力。
- 集群運維：支持集群巡檢，Etcd 的可視化管理，Etcd 數(shù)據(jù)備份恢復(fù)，ip地址池管理，鏡像管理，變更管理等能力。
- 資源管理：支持對集群資源和業(yè)務(wù)應(yīng)用的全方位管理。
三、平臺核心能力構(gòu)建
3.1 節(jié)點擴(kuò)縮容工具建設(shè)
3.1.1 問題背景
集群節(jié)點的擴(kuò)容和縮容是頻率較高的運維操作，人工按照文檔進(jìn)行黑屏操作步驟繁瑣，流程復(fù)雜，易出現(xiàn)誤操作，影響集群穩(wěn)定性。因此，實現(xiàn)集群節(jié)點擴(kuò)縮容自動化成為首要解決的問題。
3.1.2 解決方案
3.1.2.1 集群擴(kuò)縮容白屏化
為了解決集群擴(kuò)縮容問題，我們借助了 Kubernetes 控制器模型設(shè)計了 kubeops-controller 模塊，用于實現(xiàn)節(jié)點的自動擴(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左右滑動查看完整代碼
下圖為擴(kuò)縮容模塊的架構(gòu)設(shè)計圖。
如架構(gòu)設(shè)計圖所示擴(kuò)縮容組件包含以下主要模塊：
- beidou-api: 北斗平臺的 API 層，用于接收和響應(yīng)外部請求。
- kube-apiserver: Kubernetes API 層，負(fù)責(zé)處理和響應(yīng)來自集群內(nèi)部和外部的所有API請求。
- kubeops-controller: 用于處理 operation 擴(kuò)縮容操作的控制器。
- Job: Job 用于創(chuàng)建和管理一次性任務(wù)或定時任務(wù)，確保任務(wù)能夠成功完成并且不會重復(fù)運行，這里主要用于執(zhí)行 Ansible 腳本。
用戶在控制臺創(chuàng)建擴(kuò)容任務(wù)后，beidou-api 會捕捉其中的參數(shù)并調(diào)用 Kubernetes 接口創(chuàng)建 operation，operation 中包含了集群標(biāo)識，待擴(kuò)縮容節(jié)點，操作類型等信息。kubeops-controller 控制器會監(jiān)聽 operation 的創(chuàng)建，并根據(jù) operation 參數(shù)來執(zhí)行相應(yīng)的流程任務(wù)。kubeops-controller 會依據(jù)擴(kuò)容或縮容參數(shù)來創(chuàng)建 Job，Job 則會執(zhí)行 Ansible 腳本來自動完成集群安裝和節(jié)點擴(kuò)縮容任務(wù)，其中的 Ansible 腳本是基于 Kubespray 項目進(jìn)行定制化改造而成。
1）擴(kuò)容操作
擴(kuò)容分為三個小步：擴(kuò)容前檢查，擴(kuò)容，擴(kuò)容后檢查。通過三個步驟確保能夠成功擴(kuò)容集群節(jié)點，每個步驟都會啟動一個 Job 來執(zhí)行 Ansible 腳本完成任務(wù)。
- 擴(kuò)容前檢查：通過 Ansible 腳本來檢查磁盤空間是否夠用，內(nèi)核版本是否符合需求，是否殘留 kubelet 和 Docker 等進(jìn)程。通過擴(kuò)容前檢查來確保節(jié)點能夠順利安裝。
- 擴(kuò)容：擴(kuò)容節(jié)點則會執(zhí)行 Ansible 腳本將節(jié)點添加到集群。
- 擴(kuò)容后檢查：節(jié)點是否處于就緒狀態(tài)，網(wǎng)絡(luò)是否連通，確保節(jié)點就緒后，會放開調(diào)度投入生產(chǎn)。
2）縮容操作
縮容操作主要分為兩個步驟：縮容前檢查，縮容。
- 縮容前檢查：需要先檢查節(jié)點是否存在業(yè)務(wù) Pod。如果存在業(yè)務(wù) Pod，平臺會提供一鍵遷移業(yè)務(wù)功能，避免對業(yè)務(wù)造成影響。
- 縮容：執(zhí)行 Ansible 腳本刪除節(jié)點的 kubelet，Docker 等服務(wù)，并清理殘留數(shù)據(jù)，確保不影響下次的節(jié)點安裝。
3）節(jié)點健康檢查
在進(jìn)行運維操作時，需隨時檢查集群節(jié)點的健康狀態(tài)，檢查流程包括網(wǎng)絡(luò)偵測、pod 是否可正常創(chuàng)建等，通過這個步驟可進(jìn)行問題排查。節(jié)點健康檢查是通過執(zhí)行 Ansible 腳本來檢查 kubelet、Docker、kube-proxy 服務(wù)的運行狀態(tài)，檢測節(jié)點的網(wǎng)絡(luò)連通性。
3.1.2.2 擴(kuò)縮容全流程自動化
擴(kuò)縮容白屏化功能的構(gòu)建解決了黑屏操作存在的問題，但節(jié)點的擴(kuò)容操作依然涉及多個步驟，即使白屏操作，也無法避免繁瑣的流程。為了進(jìn)一步節(jié)約人力，提升效率，實現(xiàn)一鍵擴(kuò)縮容節(jié)點迫在眉睫，我們設(shè)計實現(xiàn)了全流程自動化功能。為了實現(xiàn)全流程自動化擴(kuò)縮容功能，我們在 operation 的上層設(shè)計了 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)圖所示，全流程自動化主要包含如下模塊：
- AutoOperationTask-controller：全流程自動化控制器，會對 autooperationtask 進(jìn)行處理。
- 網(wǎng)絡(luò)模塊: 網(wǎng)絡(luò)模塊的作用是處理網(wǎng)絡(luò)相關(guān)的任務(wù)，如調(diào)用網(wǎng)絡(luò)接口配置節(jié)點網(wǎng)絡(luò)
- 任務(wù)處理模塊：此模塊的主要作用是根據(jù)需求按順序創(chuàng)建operation。
- kubeops-controller: 任務(wù)處理控制器，會對 operation進(jìn)行處理。
AutoOperationTask-controller會持續(xù)監(jiān)聽autooperationtask crd 的創(chuàng)建事件，任務(wù)處理模塊會根據(jù) autotask 定義的流程和步驟，創(chuàng)建 operation（上文提到的對擴(kuò)縮容等任務(wù)的抽象）。kubeops-controller 會監(jiān)聽 operation 的創(chuàng)建，并創(chuàng)建 Job 執(zhí)行腳本。
上圖是可視化的擴(kuò)縮容流程，通過這種設(shè)計，我們將所有能夠順序執(zhí)行的任務(wù)簡化成一個自動化任務(wù)，全流程自動化將所有的操作串聯(lián)起來，不僅可以節(jié)省人工操作的時間，而且支持實時追蹤任務(wù)進(jìn)程，觀測任務(wù)狀態(tài)。
3.1.3 達(dá)成效果
通過擴(kuò)縮容全流程自動化的建設(shè)，我們將擴(kuò)容20臺機(jī)器的時間從60分鐘縮短到10分鐘，從原本的人工十幾個步驟才能完成的流程變?yōu)橐绘I部署，且沒有出現(xiàn)過由于人工操作失誤而引入的問題。目前，通過北斗系統(tǒng)執(zhí)行了5000+ 的擴(kuò)縮容任務(wù)，交付了上萬臺機(jī)器。未來團(tuán)隊將持續(xù)優(yōu)化擴(kuò)容效率，縮短健康檢測時間。
3.2 集群巡檢工具建設(shè)
3.2.1 問題背景
集群常會出現(xiàn)一些不可預(yù)料的問題，這些問題都嚴(yán)重影響集群的穩(wěn)定性。
- 集群節(jié)點問題：cpu, 內(nèi)存使用率過高，磁盤占滿，內(nèi)核死鎖，文件系統(tǒng)崩潰等。這些都會導(dǎo)致節(jié)點 Pod 不可用，影響用戶的業(yè)務(wù)。及時發(fā)現(xiàn)節(jié)點問題對于運維來說至關(guān)重要，盡早介入處理才可以避免更為嚴(yán)重的問題發(fā)生。
- 資源配置問題：除了節(jié)點問題外，集群配置問題，證書過期和資源定義不規(guī)范，都可能導(dǎo)致集群不可用，帶來嚴(yán)重隱患，為避免這些潛在問題影響到生產(chǎn)環(huán)境，巡檢能力的構(gòu)建變得尤為重要。
集群巡檢需要具備如下能力：
- Kubernetes資源巡檢：巡檢 Kubernetes 集群的Deployment、StatefulSet 等資源配置是否符合要求。
- 集群節(jié)點巡檢：巡檢節(jié)點磁盤、內(nèi)存、cpu 使用率、內(nèi)核日志是否存在問題。
- 自定義腳本巡檢：支持自定義腳本巡檢。
3.2.2 解決方案
為解決如上問題，實現(xiàn)巡檢目標(biāo)，我們開發(fā)了 kube-doctor 組件來對集群進(jìn)行巡檢。
上圖為 kube-doctor 的架構(gòu)設(shè)計：
- inspection crd：用于記錄巡檢的基本信息，包括巡檢名稱、巡檢腳本、巡檢集群、巡檢時間、巡檢策略等
- inspection-operator：inspection-operator 控制器會監(jiān)聽 inspection 的創(chuàng)建，并對其進(jìn)行處理，inspection 會根據(jù) inspection 定義的巡檢時間和巡檢內(nèi)容，交給 cron-controller 模塊處理。
- cron-controller: cron-controller 負(fù)責(zé)按照巡檢任務(wù) inspection 定義的巡檢周期驅(qū)動 worker 定時執(zhí)行任務(wù)，worker則負(fù)責(zé)具體巡檢任務(wù)的執(zhí)行。
- work-pool: worker 資源池，當(dāng)有新的巡檢任務(wù)需執(zhí)行時，cron-controlle 會從 worker 池中獲取 worker，驅(qū)動 worker 執(zhí)行定時任務(wù)。
- 巡檢驅(qū)動：為了支持不同類型和不同場景的巡檢，我們設(shè)計了巡檢驅(qū)動功能。巡檢驅(qū)動需要實現(xiàn)兩個標(biāo)準(zhǔ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í)行具體巡檢任務(wù)，例如到指定節(jié)點執(zhí)行腳本，并獲取結(jié)果。StoreReport 的作用則是存儲巡檢報告，存儲巡檢報告支持將數(shù)據(jù)存儲到 MySQL 或者 Elasticsearch。目前定義了自定義腳本，數(shù)據(jù)指標(biāo)和節(jié)點指標(biāo)三種 driver。
- 自定義腳本: 用戶可以自定義的腳本，到指定的集群節(jié)點執(zhí)行，并獲取到執(zhí)行結(jié)果。
- 數(shù)據(jù)指標(biāo)：數(shù)據(jù)指標(biāo)來自于監(jiān)控模塊 promethuse。
- 節(jié)點指標(biāo)：獲取 node-problem-detector（用于發(fā)現(xiàn)節(jié)點問題的開源組件） 的執(zhí)行數(shù)據(jù)。
3.2.3 達(dá)成效果
目前 kube-doctor 已經(jīng)執(zhí)行了數(shù)千次的巡檢任務(wù)，生成數(shù)千份巡檢報告，幫助運維及時發(fā)現(xiàn)容器集群問題。
3.3 應(yīng)用中心建設(shè)
3.3.1 問題背景
隨著業(yè)務(wù)的發(fā)展，集群內(nèi)自研組件的增多使得對組件的管理變得復(fù)雜，基于此問題我們需著手構(gòu)建應(yīng)用中心能力，對組件進(jìn)行統(tǒng)一管理。應(yīng)用中心需要具備如下能力：
- 應(yīng)用模版管理：支持上傳 Chart 包到 vivo 對象存儲，可發(fā)布到應(yīng)用中心，發(fā)布成功后支持對 Chart 模版進(jìn)行更新，按照版本管理。
- 應(yīng)用部署管理：支持將應(yīng)用直接部署到不同的集群和 Namespace，部署過程中可監(jiān)聽修改參數(shù)。常用參數(shù)支持配置在 values.yml 文件中直接編輯修改，無需重新打 Chart 包，使部署流程更方便高效。
- 應(yīng)用實例管理：支持查看應(yīng)用在哪些集群部署了哪些實例，點擊應(yīng)用實例可以跳轉(zhuǎn)到實例詳情，查看實例的配置等相關(guān)信息，進(jìn)行相應(yīng)的配置修改和升級。
3.3.2 解決方案
為解決如上問題，我們開發(fā)了應(yīng)用中心功能，將集群中各類組件和服務(wù)托管到北斗平臺進(jìn)行統(tǒng)一管理。通過 Kubernetes 提供的應(yīng)用安裝管理組件 Helm 執(zhí)行應(yīng)用的安裝、部署、升級及配置修改等，方便在不同集群中分發(fā)和部署應(yīng)用，支持服務(wù)的全生命周期管理。下圖為應(yīng)用中心的架構(gòu)設(shè)計：
3.3.2.1 模板管理
為管理應(yīng)用模板，我們定義了 helmapp CRD和helmappversion CRD。用戶可以上傳 chart 包，前端將解析其內(nèi)容并傳遞給 beidou-api，以創(chuàng)建 helmapp CRD 并存儲到 vivo 對象存儲系統(tǒng)，同時會創(chuàng)建一個 helmappversion CRD，用于記錄版本和存儲地址，以便進(jìn)行安裝操作。
- helmapp crd: 用于記錄 chart 包的基本信息，如應(yīng)用名稱、應(yīng)用描述、應(yīng)用 log 等信息。
- helmappversion crd: 用于記錄 chart 包的版本信息和存儲地址，便于安裝包的獲取。
3.3.2.2 實例管理
應(yīng)用安裝包安裝到集群后會生成一個運行中的應(yīng)用，也就是一個應(yīng)用實例，對此我們設(shè)計了 release crd 用于表示一個應(yīng)用實例，通過調(diào)用 beidou-api 接口創(chuàng)建 release（實例），控制器監(jiān)聽到創(chuàng)建事件后從 crd 中獲取需要安裝的chart包名稱和版本，并從 vivo 對象存儲系統(tǒng)中獲取 chart 包，從 values 中讀取相關(guān)參數(shù)，最后獲取 cluster crd 中的 kubeconfig 數(shù)據(jù)，通過這種方式就能夠?qū)?yīng)用安裝到不同集群中。
- release crd：存儲應(yīng)用實例信息，包括 chart 包名稱、版本等信息
- beidou-release-controller：監(jiān)聽 release 創(chuàng)建事件，并對 release 進(jìn)行處理。
- values: release spec 中定義的應(yīng)用配置參數(shù)。
3.3.3 達(dá)成效果
目前通過應(yīng)用中心管理的應(yīng)用達(dá)到了50+，管理的應(yīng)用實例達(dá)到200+，實現(xiàn)了降低組件管理復(fù)雜度，提升管理效率，且與AI和數(shù)據(jù)部門合作用于復(fù)雜應(yīng)用的部署和管理。
3.4 事件采集和監(jiān)控體系構(gòu)建
3.4.1 問題背景
在 Kubernetes 中，事件（Events）是集群在特定對象上發(fā)生的特定時間點上的狀態(tài)變化記錄。事件涵蓋有關(guān) Pod 的調(diào)度決策、Container 的狀態(tài)變化、節(jié)點的壓力情況等重要信息。事件可幫助開發(fā)工程師和集群運維工程師理解集群內(nèi)部發(fā)生的事件。通過 Kubernetes 中的事件，可快速發(fā)現(xiàn)和定位問題。但當(dāng)前集群的事件都存儲于 Etcd，事件查看較為麻煩，由于 Etcd 空間限制，無法長期存儲事件，這些問題為追溯歷史問題造成困難。
3.4.2 解決方案
針對此問題，平臺開發(fā)了事件采集存儲組件 beidou-event，上圖 beidou-event 架構(gòu)圖。
- beidou-event: beidou-event模塊會實時監(jiān)聽kube-apiserver 的事件，并將事件按照一定的格式輸出到主機(jī)的某一個目錄。
- vivo 日志系統(tǒng)：vivo 日志系統(tǒng)由 vivo 開發(fā)用于專門的日志采集和存儲的系統(tǒng)，這里也可以使用ELK等日志采集方案。
- Elasticsearch: vivo 日志系統(tǒng)采集完數(shù)據(jù)后會將數(shù)據(jù)存儲到Elasticsearch。
- Beidou-api: beidou-api 會調(diào)用 Elasticsearch 獲取事件數(shù)據(jù)并在前端作展示。
3.4.3 達(dá)成效果
當(dāng)前 Elasticsearch 保持在30億+的事件數(shù)量，歷史事件的查詢幫助運維和研發(fā)快速定位歷史問題，在問題追溯上發(fā)揮了重要作用。
四、總結(jié)與展望
經(jīng)過幾年的能力建設(shè)，我們基本實現(xiàn)了北斗平臺構(gòu)建目標(biāo)。
- 90%以上高頻操作實現(xiàn)白屏化：北斗運維平臺已經(jīng)將90%的黑屏運維操作實現(xiàn)白屏化。各種高頻率文件配置，資源配置，資源調(diào)整，問題定位都可以通過北斗運維管理平臺進(jìn)行。操作人，操作內(nèi)容皆可通過審計功能進(jìn)行追溯。
- 集群安裝和擴(kuò)縮容工具大幅提效：通過北斗平臺安裝數(shù)個k8s集群，擴(kuò)容了上萬臺機(jī)器。標(biāo)準(zhǔn)化的程序執(zhí)行規(guī)避了由于人為操作導(dǎo)致的失誤，保證了集群的穩(wěn)定性和可靠性。通過白屏化簡化了操作流程，擴(kuò)容由原本的人工執(zhí)行十幾個步驟，實現(xiàn)了一鍵擴(kuò)縮容，縮減了擴(kuò)縮容時間，提升了運維的效率。
- 運營中心實現(xiàn)全方位運營監(jiān)控：通過運營中心的資源概覽和監(jiān)控功能可幫助及時掌握集群數(shù)量，集群規(guī)模，資源填充率，集群資源使用情況等關(guān)鍵指標(biāo)，便于對資源進(jìn)行治理，避免由于資源問題影響業(yè)務(wù)。
- 巡檢能力助力問題及時發(fā)現(xiàn)解決：集群巡檢功能自投入使用已經(jīng)生成了3000+份的巡檢報告，詳細(xì)記錄了巡檢過程中發(fā)現(xiàn)的不符合規(guī)范和巡檢規(guī)則的風(fēng)險項。通過巡檢功能及時發(fā)現(xiàn)集群存在的不穩(wěn)定因素，幫助運維同事及時排除問題。
- 事件采集助力集群問題排查：事件采集和查詢功能在問題定位過程發(fā)揮重要作用，為問題的解決提供重要線索。同時，事件中心歸納了核心且關(guān)鍵的事件指標(biāo)，便于掌控集群的運行狀況。
- 應(yīng)用中心標(biāo)準(zhǔn)化組件安裝：應(yīng)用中心功能管理所有的自研組件，組件的安裝、升級和配置修改變得更加便利。同時，此功能開放給高級用戶用于復(fù)雜應(yīng)用的部署。
北斗容器自動化運維平臺的構(gòu)建進(jìn)一步解放了人力，提升了運維效率，支撐了上萬臺機(jī)器數(shù)十個容器集群的運維。容器運維平臺未來會向智能化自動化方向發(fā)展，實現(xiàn)平臺自動偵測問題，解決問題，結(jié)合人工智能技術(shù)，提供更加智能的運維平臺，進(jìn)一步提升運維效率和集群穩(wěn)定性。
