面向Kubernetes的多集群資源監(jiān)控方案①

李 軻,竇 亮,楊 靜

(華東師范大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,上海 200062)

云計(jì)算日益成為信息社會(huì)的基礎(chǔ)設(shè)施,微服務(wù)和容器的應(yīng)用越來(lái)越廣泛. 為了讓容器按照計(jì)劃有組織地運(yùn)行并進(jìn)行合理的資源調(diào)度與分配,容器編排工具由此產(chǎn)生. Kubernetes[1]是Google 開(kāi)源的容器編排工具,目前使用率在所有容器編排工具中可達(dá)75%[2]. 隨著業(yè)務(wù)的快速增長(zhǎng),工業(yè)界使用Kubernetes 部署大規(guī)模集群時(shí),其規(guī)?？蛇_(dá)到節(jié)點(diǎn)數(shù)以萬(wàn)計(jì),Pod (Kubernetes 創(chuàng)建或部署的最小基本單位,代表集群上正在運(yùn)行的一個(gè)進(jìn)程)數(shù)以十萬(wàn)計(jì). 為了能夠?qū)崟r(shí)掌握Kubernetes集群的資源使用情況與工作狀態(tài),監(jiān)控工具必不可少,對(duì)于大規(guī)模多集群部署情況,更是迫切需要及時(shí)獲取多集群的資源監(jiān)控信息,實(shí)現(xiàn)有效的運(yùn)維和管理.

Kubernetes 自身提供一定程度的資源監(jiān)控,通過(guò)部署metrics-server[3]和Dashboard[4]能夠可視化地展示集群中節(jié)點(diǎn)級(jí)別和Pod 級(jí)別的CPU 與內(nèi)存使用情況,然而與網(wǎng)絡(luò)和存儲(chǔ)相關(guān)的指標(biāo)并未涉及,并且無(wú)法獲取容器級(jí)別的資源使用情況. 因此,業(yè)界出現(xiàn)了許多適配容器的監(jiān)控工具,典型的如Heapster[5,6]是原生集群監(jiān)控方案,但后被棄用; cAdvisor[7]兼容Docker,現(xiàn)已內(nèi)嵌到Kubernetes 作為監(jiān)控組件,提供獨(dú)立的API 接口; Prometheus[8]是開(kāi)源的業(yè)務(wù)監(jiān)控和時(shí)序數(shù)據(jù)庫(kù),屬于新一代云原生監(jiān)控系統(tǒng). 而傳統(tǒng)的主機(jī)監(jiān)控工具,如Zabbix[9]、Nagios[10]等,也提供了Kubernetes 相關(guān)的監(jiān)控插件[11,12],能夠識(shí)別集群的組件部署狀態(tài).

當(dāng)前,Prometheus 是主流的容器監(jiān)控工具,在所有的用戶(hù)自定義指標(biāo)中,平均有62%由Prometheus 提供[2].通過(guò)對(duì)集群部署node-exporter 和kube-state-metrics,用戶(hù)可采集集群中的監(jiān)控指標(biāo). 文獻(xiàn)[13]提出Kubernetes監(jiān)控體系下的3 種監(jiān)控指標(biāo): 宿主機(jī)監(jiān)控?cái)?shù)據(jù)、Kubernetes 組件的metrics API 以及Kubernetes 核心監(jiān)控?cái)?shù)據(jù),其中宿主機(jī)監(jiān)控?cái)?shù)據(jù)可以通過(guò)部署Prometheus獲取. 目前,有不少工作將Prometheus 作為監(jiān)控模塊的核心工具使用,如搭建云平臺(tái)監(jiān)控告警系統(tǒng)[14]、設(shè)計(jì)實(shí)現(xiàn)基于Kubernetes 云平臺(tái)彈性伸縮方案[15]等. 然而,目前Prometheus 提供的監(jiān)控方式對(duì)于多集群的情況適配性不佳. 如果需要進(jìn)行多集群監(jiān)控,有兩種解決的辦法,一是對(duì)每個(gè)集群部署Prometheus,再進(jìn)行指標(biāo)聚合,這種方式每個(gè)集群都要消耗資源開(kāi)銷(xiāo),因此整體資源開(kāi)銷(xiāo)相對(duì)較大; 二是全局只部署一套Prometheus,統(tǒng)一采集多個(gè)集群的指標(biāo),這種方式需要修改配置文件中的代碼,較為復(fù)雜且容易出錯(cuò).

由此,本文提出一種面向Kubernetes 的資源監(jiān)控方案并基于Java 語(yǔ)言實(shí)現(xiàn),可實(shí)時(shí)獲取多集群多層級(jí)的資源監(jiān)控指標(biāo),設(shè)計(jì)簡(jiǎn)化了集群配置難度,具有良好的可擴(kuò)展性和靈活性.

1 Kubernetes 容器資源監(jiān)控指標(biāo)介紹

Kubernetes 自身提供集群相關(guān)的指標(biāo),可以通過(guò)API Server 提供的REST 接口獲取. 為了保證集群的安全性,Kubernetes 默認(rèn)使用HTTPS (6443 端口)API,需要進(jìn)行認(rèn)證才能訪問(wèn)集群接口,認(rèn)證方式有賬戶(hù)密碼認(rèn)證、證書(shū)認(rèn)證以及token 認(rèn)證等.

Kubernetes 的資源監(jiān)控指標(biāo)[16]分為系統(tǒng)指標(biāo)和服務(wù)指標(biāo). 系統(tǒng)指標(biāo)是集群中每個(gè)組件都能夠采集到的指標(biāo),其中能夠被Kubernetes 自身理解并用于了解自身組件與核心的使用情況、作為做出相應(yīng)指令的依據(jù)的指標(biāo),稱(chēng)為核心指標(biāo),包括CPU 的累計(jì)使用量、內(nèi)存的當(dāng)前使用量以及Pod 和容器的磁盤(pán)使用量; 其余指標(biāo)統(tǒng)稱(chēng)為非核心指標(biāo). 服務(wù)指標(biāo)則是Kubernetes 基礎(chǔ)設(shè)施組件以及用戶(hù)應(yīng)用提供的指標(biāo),其中用于Kubernetes 的Pod 自動(dòng)水平擴(kuò)展的指標(biāo)也可以被稱(chēng)為自定義指標(biāo).

Kubernetes 發(fā)展至今,向用戶(hù)提供了以下幾類(lèi)指標(biāo)接口: (1)“stats”,該接口相對(duì)較老,可以查詢(xún)具體某個(gè)特定的容器下的指標(biāo)數(shù)據(jù); (2)“metrics.k8s.io”,該接口由metrics-server 提供,為kube-scheduler、Horizontal Pod Autoscaler 等核心組件以及“kubectl top”命令和Dashboard 等UI 組件提供數(shù)據(jù)來(lái)源; (3)“metrics”和“metrics/cadvisor”,分別提供了Kubernetes 自身的監(jiān)控指標(biāo)以及內(nèi)嵌的cAdvisor 獲取的監(jiān)控指標(biāo),數(shù)據(jù)格式適配Prometheus 監(jiān)控工具; (4)“stats/summary”[17],該接口是Kubernetes 社區(qū)目前主推的數(shù)據(jù)接口. “stats”已被Kubernetes 現(xiàn)版本廢棄,其余3 類(lèi)接口能夠提供的指標(biāo)種類(lèi)與對(duì)應(yīng)層級(jí)如表1 所示.

表1 接口指標(biāo)種類(lèi)與對(duì)應(yīng)層級(jí)

Kubernetes 監(jiān)控指標(biāo)類(lèi)型主要有以下4 種: counter、gauge、histogram 和summary. counter 是只增不減的計(jì)數(shù)器,可以用于統(tǒng)計(jì)某種資源的累計(jì)消耗或者累計(jì)時(shí)間; gauge 用于那些具有增減變化的指標(biāo),比如當(dāng)前某種資源的利用率或者可用量等; histogram 表示條形直方統(tǒng)計(jì)圖,可以表示數(shù)據(jù)的分布情況,比如某個(gè)時(shí)間段內(nèi)的請(qǐng)求耗時(shí)分布; summary 類(lèi)似與histogram,但是用于標(biāo)識(shí)分位值,根據(jù)分位值顯示數(shù)據(jù)的分布情況.

2 容器資源監(jiān)控的總體設(shè)計(jì)

本文設(shè)計(jì)實(shí)現(xiàn)的面向Kubernetes 的多集群資源監(jiān)控分為4 個(gè)模塊: 集群管理模塊,數(shù)據(jù)采集模塊、數(shù)據(jù)處理模塊以及外部接口模塊. 集群管理模塊用于配置集群與檢測(cè)集群連通性; 采集模塊用于采集集群指定的接口數(shù)據(jù)與定時(shí)采集的設(shè)置; 數(shù)據(jù)處理模塊用于接口數(shù)據(jù)的解析、指標(biāo)的提取與計(jì)算、數(shù)據(jù)格式的規(guī)范化以及數(shù)據(jù)的存儲(chǔ); 接口設(shè)計(jì)模塊用于提供給可視化界面數(shù)據(jù)接口.

整體模塊功能示意圖如圖1 所示: ① 外部訪問(wèn)與接口的交互,包括配置集群與獲取監(jiān)控指標(biāo); ② 通過(guò)外部接口將集群配置數(shù)據(jù)傳遞給集群管理模塊; ③ 集群管理模塊與數(shù)據(jù)庫(kù)集群配置表交互,針對(duì)集群配置表進(jìn)行增刪改查; ④ 集群管理模塊將集群配置信息傳遞給數(shù)據(jù)采集模塊; ⑤ 數(shù)據(jù)采集模塊通過(guò)訪問(wèn)API Server接口獲取集群的資源監(jiān)控指標(biāo); ⑥ 將采集到的資源監(jiān)控指標(biāo)送入數(shù)據(jù)處理模塊進(jìn)行數(shù)據(jù)處理; ⑦ 將處理完畢的數(shù)據(jù)存儲(chǔ)至數(shù)據(jù)庫(kù)的資源監(jiān)控指標(biāo)表中; ⑧ 提供獲取資源監(jiān)控指標(biāo)的外部接口; ⑨ 提供獲取集群配置的外部接口; ⑩ 提供獲取Kubernetes 集群組件狀態(tài)信息的外部接口.

圖1 面向Kubernetes 的多集群資源監(jiān)控模塊功能示意圖

3 容器資源監(jiān)控的實(shí)現(xiàn)

3.1 集群管理

集群管理分為集群配置管理和集群連通性測(cè)試.集群配置管理主要的功能是管理集群的配置信息,包括集群名稱(chēng)(用戶(hù)根據(jù)需求自定義)、集群API Server的端口地址(默認(rèn)為集群的主節(jié)點(diǎn)的6443 端口)和相應(yīng)的 token (用于認(rèn)證,須預(yù)先在集群中配置好),為防止數(shù)據(jù)重復(fù)采集,集群名稱(chēng)、端口地址須保證唯一. 為了驗(yàn)證數(shù)據(jù)配置的準(zhǔn)確性,提供集群連通性測(cè)試的功能,根據(jù)端口地址和token 創(chuàng)建一個(gè)API 用戶(hù)(ApiClient),使用這個(gè)用戶(hù)去訪問(wèn)該集群的某個(gè)API 接口,根據(jù)是否能夠正常返回接口數(shù)據(jù)來(lái)判斷是否成功連通集群.

3.2 資源數(shù)據(jù)采集

資源數(shù)據(jù)的采集分為采集接口的確定,采集算法的設(shè)計(jì)與定時(shí)采集的設(shè)計(jì).

本設(shè)計(jì)對(duì)以下3 類(lèi)接口[18]進(jìn)行數(shù)據(jù)采集: “api/v1”接口獲取核心的集群指標(biāo),包括集群的節(jié)點(diǎn)、Pod、命名空間、服務(wù)等架構(gòu)資源的數(shù)據(jù); “apis/”接口獲取集群相關(guān)部署情況的指標(biāo),如Daemon Sets、Deployments、Replica Sets 等; “stats/summary”接口獲取集群資源使用情況的監(jiān)控指標(biāo),具體指標(biāo)詳情見(jiàn)表2. 需要注意的是,表1 中網(wǎng)絡(luò)指標(biāo)提供的是端口(interface)級(jí)別的數(shù)據(jù)指標(biāo),因此需要針對(duì)節(jié)點(diǎn)和Pod 的每個(gè)端口進(jìn)行數(shù)據(jù)處理與存儲(chǔ); 存儲(chǔ)指標(biāo)根據(jù)層級(jí)使用了不同的名稱(chēng)(節(jié)點(diǎn)為“fs”,Pod 為“volume”和“ephemeral-storage”,容器為“rootfs”). 另外,每個(gè)Pod 可以掛載多個(gè)volume,每個(gè)volume 都有Pod 內(nèi)唯一的名稱(chēng),因此對(duì)每個(gè)volume都要單獨(dú)生成一條數(shù)據(jù). 每個(gè)指標(biāo)都會(huì)有自己的生成時(shí)間,這是因?yàn)槊總€(gè)指標(biāo)是獨(dú)立生成的,從接口中獲取的數(shù)據(jù)也并非是實(shí)時(shí)數(shù)據(jù),而是數(shù)據(jù)接口最近一次刷新后的數(shù)據(jù),為保證二次計(jì)算的準(zhǔn)確性,把該字段單獨(dú)進(jìn)行存放.

表2 監(jiān)控指標(biāo)詳情

3 類(lèi)接口中,“api/v1”和“apis/”提供集群級(jí)別的數(shù)據(jù),直接采集接口數(shù)據(jù)即可,而“stats/summary”提供節(jié)點(diǎn)級(jí)別的數(shù)據(jù),因此需要先獲取集群的節(jié)點(diǎn)列表后對(duì)每一個(gè)節(jié)點(diǎn)進(jìn)行數(shù)據(jù)的提取. 為保證采集效率,設(shè)計(jì)采用多線程并行采集.

對(duì)于定時(shí)采集,“api/v1”和“apis/”提供的數(shù)據(jù)主要是Kubernetes 集群的部署或者配置資源,因此不進(jìn)行定時(shí)采集. 而“stats/summary”獲取的是實(shí)時(shí)的集群各資源使用量的情況,需要進(jìn)行定時(shí)采集. 由于Kubernetes接口的刷新間隔最短是10 s,因此采集間隔最好長(zhǎng)于刷新時(shí)間,防止重復(fù)采集數(shù)據(jù). 本設(shè)計(jì)定為1 分鐘采集1 次.

3.3 資源數(shù)據(jù)處理與存儲(chǔ)

由于采集的數(shù)據(jù)包含4 個(gè)種類(lèi)和3 個(gè)層級(jí)的數(shù)據(jù),因此需要對(duì)每條數(shù)據(jù)進(jìn)行種類(lèi)和層級(jí)的明確區(qū)分. 并且,這些數(shù)據(jù)需要進(jìn)行結(jié)構(gòu)的解析、字段的提取、數(shù)值的計(jì)算,將數(shù)據(jù)結(jié)構(gòu)統(tǒng)一化、扁平化后再進(jìn)行數(shù)據(jù)存儲(chǔ).

3.3.1 資源數(shù)據(jù)的處理

數(shù)據(jù)處理的主要工作包括3 部分: 一是數(shù)據(jù)封裝,提取關(guān)鍵字段; 二是根據(jù)層級(jí)解析數(shù)據(jù); 三是對(duì)部分?jǐn)?shù)據(jù)進(jìn)行二次計(jì)算,得到更直觀的數(shù)據(jù).

3 類(lèi)接口中,Java 相關(guān)類(lèi)庫(kù)已將“api/v1”和“apis/”的所需的接口數(shù)據(jù)封裝成對(duì)象,通過(guò)現(xiàn)有方法提取關(guān)鍵字段即可; 針對(duì)不同層級(jí)的數(shù)據(jù),Kubernetes 提供了不同的接口,無(wú)需額外區(qū)分層級(jí); 對(duì)于數(shù)據(jù)本身,接口提供的是集群具體組件(Pod、容器、部署任務(wù)等)的狀態(tài)信息,無(wú)需進(jìn)行數(shù)值上的計(jì)算. 故這兩類(lèi)接口的數(shù)據(jù)處理工作相對(duì)簡(jiǎn)單. 而“stats/summary”接口僅提供了獲取數(shù)據(jù)接口的方法,并沒(méi)有對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行封裝; 提供的數(shù)據(jù)包含節(jié)點(diǎn)、Pod、容器級(jí)別的數(shù)據(jù),需要對(duì)數(shù)據(jù)根據(jù)層級(jí)進(jìn)行區(qū)分; 接口數(shù)據(jù)包含gauge 類(lèi)數(shù)據(jù)和counter 類(lèi)數(shù)據(jù),需要對(duì)部分?jǐn)?shù)據(jù)進(jìn)行二次計(jì)算.

“stats/summary”接口數(shù)據(jù)結(jié)構(gòu)如圖2 所示,每類(lèi)指標(biāo)詳情參考表2,數(shù)據(jù)格式為JSON,可以使用JSON 解析工具(如“json2pojo”)將其封裝成Java 對(duì)象.

圖2 “stats/summary”接口數(shù)據(jù)結(jié)構(gòu)圖

為了使數(shù)據(jù)扁平化便于存儲(chǔ),所有層級(jí)的數(shù)據(jù)均添加集群、節(jié)點(diǎn)、命名空間、Pod、容器級(jí)別的字段,對(duì)于高層級(jí)數(shù)據(jù)中的低層級(jí)字段默認(rèn)設(shè)置為空. 除此以外,數(shù)據(jù)中還添加一個(gè)“層級(jí)”字段,用于表明數(shù)據(jù)的層級(jí),保證不同層級(jí)的數(shù)據(jù)不會(huì)在進(jìn)行數(shù)據(jù)查詢(xún)時(shí)相互污染查詢(xún)結(jié)果.

另外,針對(duì)網(wǎng)絡(luò)的多接口添加“接口名”字段用于存放同一組件多個(gè)端口的數(shù)據(jù),針對(duì)存儲(chǔ)的不同類(lèi)型添加“存儲(chǔ)類(lèi)型”字段,其中為volume 類(lèi)型的額外添加“volume 名稱(chēng)”字段用于保存同一組件中多個(gè)掛載volume 的數(shù)據(jù).

表2 中顯示的資源指標(biāo)中,counter 類(lèi)型的指標(biāo)和部分gauge 類(lèi)型的指標(biāo)需要進(jìn)行二次計(jì)算,根據(jù)計(jì)算產(chǎn)生的新指標(biāo)與計(jì)算方式如表3 所示. 由于采集可能因?yàn)榧和ㄓ嵐收系仍驅(qū)е虏杉臄?shù)據(jù)可能跨越多個(gè)時(shí)間間隔,因此,為了能夠表現(xiàn)監(jiān)控?cái)?shù)據(jù)的可靠性,表3 中的部分指標(biāo)可以進(jìn)行再計(jì)算(如單位時(shí)間內(nèi)的平均網(wǎng)絡(luò)流量或者多個(gè)時(shí)間段中的內(nèi)存使用量的峰值谷值等).

表3 監(jiān)控新指標(biāo)詳情

3.3.2 資源數(shù)據(jù)的存儲(chǔ)

對(duì)于“api/v1”和“apis/”的數(shù)據(jù),只需要按需求獲取接口數(shù)據(jù)即可,無(wú)需進(jìn)行數(shù)據(jù)存儲(chǔ). 本節(jié)中只關(guān)注“stats/summary”接口的數(shù)據(jù)存儲(chǔ)工作.

整個(gè)資源數(shù)據(jù)根據(jù)資源類(lèi)型分為4 類(lèi)表: CPU表、內(nèi)存表、網(wǎng)絡(luò)表、以及存儲(chǔ)表,每類(lèi)表分為3 張表: 原始數(shù)據(jù)表(metadata),數(shù)據(jù)表(data)和最近一次數(shù)據(jù)表(last_data).

metadata 表用于存儲(chǔ)采集數(shù)據(jù)未處理過(guò)的指標(biāo),data 表用于存儲(chǔ)二次處理的字段,其中包含了metadata表中需要計(jì)算得到的指標(biāo)以及需要轉(zhuǎn)換單位格式的指標(biāo),這張表將主要用于資源數(shù)據(jù)的展示與時(shí)間序列數(shù)據(jù)列的提取和分析; last_data 表中存放的是各組件最近一次采集到的指標(biāo)數(shù)據(jù),這張表的作用一是參與data 表字段數(shù)據(jù)的生成,主要針對(duì)metadata 表中counter類(lèi)型的數(shù)據(jù),生成相鄰時(shí)間戳間隔的指標(biāo)數(shù)據(jù); 二是用于資源數(shù)據(jù)的展示. 以容器為例,由于容器的生命周期十分短暫,當(dāng)一個(gè)容器因?yàn)楣收匣蛘哌_(dá)到使用壽命后,Kubernetes 會(huì)將這個(gè)容器殺死,然后根據(jù)相同的鏡像生成一個(gè)新的容器繼續(xù)維持服務(wù)的運(yùn)作,因此,在Kubernetes 集群中無(wú)法查找曾經(jīng)生成過(guò)的容器. 盡管可以通過(guò)data 表來(lái)獲取歷史組件信息,但是表數(shù)據(jù)量的逐漸增大會(huì)逐漸降低查詢(xún)效率. 通過(guò)last_data 表,便可以獲取到歷史中某個(gè)集群所有能夠查詢(xún)到監(jiān)控?cái)?shù)據(jù)的組件的列表,根據(jù)這個(gè)列表就能夠獲取具體某個(gè)時(shí)間段中集群內(nèi)存活的組件信息(包括節(jié)點(diǎn),Pod,容器),并且數(shù)據(jù)增長(zhǎng)速率相較于其余兩種表非常低,可以保證查詢(xún)的效率.

除此以外,每條數(shù)據(jù)再插入以下2 個(gè)字段: “id”字段作為主鍵,用于記錄數(shù)據(jù)的序號(hào),便于對(duì)數(shù)據(jù)進(jìn)行排序; “create_time”字段用于記錄插入當(dāng)前數(shù)據(jù)的時(shí)間,這個(gè)字段主要用于刪除超過(guò)存放時(shí)限的數(shù)據(jù). 對(duì)于4 張最近一次數(shù)據(jù)表中,額外添加了“update_time”字段,用于記錄最近一次數(shù)據(jù)表的時(shí)間,那么就可以通過(guò)“create_time”和“update_time” 2 個(gè)字段表示某個(gè)組件資源數(shù)據(jù)的始末時(shí)間.

3.3.3 資源數(shù)據(jù)定時(shí)任務(wù)算法

第3.2 節(jié)中提到“stats/summary”接口提供的監(jiān)控?cái)?shù)據(jù)需要進(jìn)行定時(shí)采集、處理和存儲(chǔ),本文將這3 個(gè)部分統(tǒng)合成一個(gè)定時(shí)任務(wù)來(lái)實(shí)現(xiàn).

算法1 給出任務(wù)的整體功能實(shí)現(xiàn)偽代碼. 根據(jù)集群列表獲取各集群的節(jié)點(diǎn)信息,接著按節(jié)點(diǎn)依次獲取監(jiān)控?cái)?shù)據(jù),根據(jù)數(shù)據(jù)結(jié)構(gòu)進(jìn)行分層,再按照數(shù)據(jù)種類(lèi)進(jìn)行處理與存儲(chǔ). 算法中,將同一類(lèi)數(shù)據(jù)的處理與存儲(chǔ)封裝成一個(gè)服務(wù)(service)用于優(yōu)化代碼格式; 實(shí)際實(shí)現(xiàn)中,在所有的for 循環(huán)中均使用了多線程用于提高算法運(yùn)行的效率.

算法1. 資源數(shù)據(jù)定時(shí)任務(wù)1. function statsSummaryJob()2. 從配置表中獲取Kubernetes 集群列表clusterList 3. for cluster in clusterList 4. ip ← cluster.ip 5. port ← cluster.port 6. token ← cluster.token 7. host ← ip + ”:“+port 8. //創(chuàng)建訪問(wèn)API Server 的客戶(hù)端9. apiClient ← createApiClient(host,token)10. //獲取當(dāng)前集群的節(jié)點(diǎn)列表11. nodeList ← getNodeList(apiClient)12. for node in nodeList

13. //獲取節(jié)點(diǎn)的監(jiān)控?cái)?shù)據(jù)14. i ← getStatsSummary(apiClient,node)15. //將數(shù)據(jù)解析成json 16. toJson(nodeStatsSummaryData)17. //c m對(duì)節(jié)點(diǎn)級(jí)別的4 類(lèi)數(shù)據(jù)進(jìn)行處理與存儲(chǔ)18. puService(i.getCpu())19. emoryService(i.getMemory())20. networkService(i.getNetwork())21. fsService(i.getFs())22. //獲取Pod 數(shù)據(jù)的列表,存放在i 中23. podStatsSummaryList ← i.getPodList()24. for j in podStatsSummaryList 25. //對(duì)Pod 級(jí)別的4 類(lèi)數(shù)據(jù)進(jìn)行處理與存儲(chǔ)26. cpuService(j.getCpu())27. memoryService(j.getMemory())28. networkService(j.getNetwork())29. fsService(j.getEphemeralStorage())30. fsService(j.getVolume())31. //獲取容器數(shù)據(jù)的列表,存放在j 中32. containerStatsSummaryList ← j.getContainerList()33. for k in containerStatsSummaryList 34. //對(duì)容器級(jí)別的3 類(lèi)數(shù)據(jù)進(jìn)行處理和存儲(chǔ)35. cpuService(k.getCpu())36. memoryService(k.getMemory())37. fsService(k.getRootfs())38. end for 39. end for 40. end for 41. end for 42. end function

對(duì)于處理4 類(lèi)資源的服務(wù)(service),主要實(shí)現(xiàn)的功能是第3.3.2 節(jié)中3 張表字段的提取與計(jì)算、表數(shù)據(jù)的添加與更新的功能,偽代碼見(jiàn)算法2.

算法2. 資源服務(wù)(包含CPU、內(nèi)存、網(wǎng)絡(luò)、存儲(chǔ))輸入: 指標(biāo)原始數(shù)據(jù)1. function service(metadata)2. //將原始數(shù)據(jù)插入metadata 表中3. addMetadata(metadata)4. //從lastData 表中取出該組件的最近一次數(shù)據(jù)5. lastData ← findLastData(metadata)6. //處理gauge 類(lèi)數(shù)據(jù)7. gaugeData ← calGauge(metadata)8. if lastData != null then 9. //處理counter 類(lèi)數(shù)據(jù)10. counterData ← calCounter(metadata,lastData)11. totalData ← gaugeData+counterData 12. //存儲(chǔ)處理后的數(shù)據(jù)到data 表中13. addData(totalData)14. //更新最近一次數(shù)據(jù)15. updateLastData(metadata)16. else

17. totalData ← gaugeData 18. addDa //將此ta(totalData)19.數(shù)據(jù)添加作為最近一次數(shù)據(jù)20. addLastData(metadata)21. end if 22. end function

4類(lèi)數(shù)據(jù)均適用算法2,不過(guò)網(wǎng)絡(luò)和存儲(chǔ)類(lèi)數(shù)據(jù)因?yàn)榈?.3.1 節(jié)中提到的注意事項(xiàng),需要添加一些循環(huán)來(lái)滿足功能需求,具體算法的實(shí)現(xiàn)過(guò)程基本一致.

3.4 外部訪問(wèn)接口設(shè)計(jì)

外部訪問(wèn)接口分為3 類(lèi),第1 類(lèi)用于集群配置的增刪改查; 第2 類(lèi)用于集群組件信息的查詢(xún),如查詢(xún)集群的節(jié)點(diǎn)或者Pod 信息等,向用戶(hù)提供對(duì)應(yīng)接口字段精簡(jiǎn)后的數(shù)據(jù); 第3 類(lèi)用于查詢(xún)定時(shí)采集得到的監(jiān)控指標(biāo),比如某個(gè)容器最近1 小時(shí)的CPU 使用情況等.具體實(shí)現(xiàn)的接口見(jiàn)表4.

表4 接口設(shè)計(jì)列表

除此以外,本文設(shè)計(jì)了2 個(gè)參數(shù)模板用于傳遞接口參數(shù),用戶(hù)可以根據(jù)查詢(xún)的需求添加相應(yīng)的參數(shù),其中“K8sServer”用于用戶(hù)交互與API Server 類(lèi)接口,“K8sConfig”用于數(shù)據(jù)庫(kù)類(lèi)接口. 模板具體字段見(jiàn)表5.

表5 參數(shù)模型設(shè)計(jì)

對(duì)于監(jiān)控指標(biāo)查詢(xún),由于集群之間邏輯上互相隔離,集群間的監(jiān)控?cái)?shù)據(jù)基本沒(méi)有邏輯關(guān)系,并且多集群的監(jiān)控?cái)?shù)據(jù)量很大,會(huì)大大影響查詢(xún)的效率,因此接口均基于某個(gè)特定的集群進(jìn)行數(shù)據(jù)查詢(xún).

4 實(shí)驗(yàn)設(shè)計(jì)

本次實(shí)驗(yàn)使用到4 個(gè)Kubernetes 集群,具體配置如表6 所示,其中集群1、2 操作系統(tǒng)為CentOS 7 ,集群3、4 操作系統(tǒng)為CentOS 8.

表6 集群信息

其中172.16 與10.168 兩個(gè)子網(wǎng)能夠相互通信,監(jiān)控工具的IP 為172.16.2.183. 本次性能測(cè)試實(shí)驗(yàn)主要測(cè)試集群資源開(kāi)銷(xiāo)和訪問(wèn)接口延時(shí).

4.1 集群資源開(kāi)銷(xiāo)

由于本文設(shè)計(jì)的面向Kubernetes 多集群資源監(jiān)控僅涉及到API 接口的訪問(wèn),因此只需關(guān)注部署在集群內(nèi)部的API Server 的資源消耗情況. 實(shí)驗(yàn)首先采集4 個(gè)小時(shí)平時(shí)資源使用情況的數(shù)據(jù),然后使用壓測(cè)工具Tsung,以每秒10 次的頻率(高于定時(shí)任務(wù)的采集頻率)訪問(wèn)4 個(gè)小時(shí),獲取這段時(shí)間的資源使用情況,具體數(shù)據(jù)分別見(jiàn)表7 和表8.

表7 平時(shí)集群API Server 資源使用情況(%)

表8 模擬訪問(wèn)時(shí)集群API Server 資源使用情況(%)

可以看出,模擬訪問(wèn)期間相較于空閑時(shí)集群的CPU、內(nèi)存的 使用量均有一定程度的提升,但是平均使用量幅度不超過(guò)2%,可以看出這種訪問(wèn)方式對(duì)于集群的影響是較小的.

4.2 訪問(wèn)接口延時(shí)

對(duì)于接口延時(shí),設(shè)計(jì)在定時(shí)任務(wù)觸發(fā)后30 s 對(duì)接口進(jìn)行數(shù)據(jù)訪問(wèn),分別采集集群級(jí)別、節(jié)點(diǎn)級(jí)別、Pod 級(jí)別、容器級(jí)別最近1 個(gè)小時(shí)的接口數(shù)據(jù),定時(shí)任務(wù)和數(shù)據(jù)訪問(wèn)頻率均為1 次/min. 接口數(shù)據(jù)的格式如圖3 所示.

圖3 接口數(shù)據(jù)展示

接口累計(jì)采集時(shí)間為2 235 min,單表數(shù)據(jù)條數(shù)從0 至35 萬(wàn)余條,展示的數(shù)據(jù)為近10 min 的平均延時(shí),延時(shí)單位為ms,具體的延時(shí)情況見(jiàn)表9.

表9 監(jiān)控?cái)?shù)據(jù)接口延時(shí)(ms)

接口延時(shí)的變化情況有如下幾個(gè)原因?qū)е? 一是表數(shù)據(jù)量的增長(zhǎng)增加了檢索數(shù)據(jù)的時(shí)間,二是采集的數(shù)據(jù)量的變化,由于獲取集群級(jí)別的數(shù)據(jù)量大于節(jié)點(diǎn)級(jí)別的數(shù)據(jù)量,其得到的接口延時(shí)也相對(duì)更高,三是網(wǎng)絡(luò)本身,由于網(wǎng)絡(luò)流量的波動(dòng),會(huì)在一定程度上影響接口的訪問(wèn)延時(shí),在計(jì)算2 160 min 處節(jié)點(diǎn)級(jí)別的10 條延時(shí)數(shù)據(jù)中,最短延時(shí)為1 981 ms,而最長(zhǎng)的則為5 450 ms,可見(jiàn)其影響程度.

除了數(shù)據(jù)本身與網(wǎng)絡(luò)的影響,數(shù)據(jù)庫(kù)也是其中的影響之一,本次設(shè)計(jì)采用的是PostgreSQL 進(jìn)行數(shù)據(jù)的存取,針對(duì)Kubernetes 監(jiān)控?cái)?shù)據(jù)量大、結(jié)構(gòu)單一、時(shí)間屬性強(qiáng)的數(shù)據(jù)在性能上顯得有些不足. 如果使用針對(duì)性的時(shí)序數(shù)據(jù)庫(kù),如InfluxDB,可以提高整個(gè)數(shù)據(jù)的存取性能.

5 結(jié)束語(yǔ)

本文基于Java 語(yǔ)言提出了一種面向Kubernetes的多集群資源監(jiān)方案,實(shí)現(xiàn)了針對(duì)多個(gè)Kubernetes 集群的資源監(jiān)控,此方案具有良好的可擴(kuò)展性和靈活性,且實(shí)驗(yàn)表明對(duì)集群資源的消耗低. 下一步的研究方向是采用時(shí)序數(shù)據(jù)庫(kù)來(lái)優(yōu)化接口性能,還可以設(shè)計(jì)日志監(jiān)控與告警功能來(lái)實(shí)現(xiàn)容器級(jí)別的立體化監(jiān)控.