面向Kubernetes的多集群資源監控方案①

李 軻,竇 亮,楊 靜

(華東師范大學 計算機科學與技術學院,上海 200062)

云計算日益成為信息社會的基礎設施,微服務和容器的應用越來越廣泛. 為了讓容器按照計劃有組織地運行并進行合理的資源調度與分配,容器編排工具由此產生. Kubernetes[1]是Google 開源的容器編排工具,目前使用率在所有容器編排工具中可達75%[2]. 隨著業務的快速增長,工業界使用Kubernetes 部署大規模集群時,其規模可達到節點數以萬計,Pod (Kubernetes 創建或部署的最小基本單位,代表集群上正在運行的一個進程)數以十萬計. 為了能夠實時掌握Kubernetes集群的資源使用情況與工作狀態,監控工具必不可少,對于大規模多集群部署情況,更是迫切需要及時獲取多集群的資源監控信息,實現有效的運維和管理.

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

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

由此,本文提出一種面向Kubernetes 的資源監控方案并基于Java 語言實現,可實時獲取多集群多層級的資源監控指標,設計簡化了集群配置難度,具有良好的可擴展性和靈活性.

1 Kubernetes 容器資源監控指標介紹

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

Kubernetes 的資源監控指標[16]分為系統指標和服務指標. 系統指標是集群中每個組件都能夠采集到的指標,其中能夠被Kubernetes 自身理解并用于了解自身組件與核心的使用情況、作為做出相應指令的依據的指標,稱為核心指標,包括CPU 的累計使用量、內存的當前使用量以及Pod 和容器的磁盤使用量; 其余指標統稱為非核心指標. 服務指標則是Kubernetes 基礎設施組件以及用戶應用提供的指標,其中用于Kubernetes 的Pod 自動水平擴展的指標也可以被稱為自定義指標.

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

表1 接口指標種類與對應層級

Kubernetes 監控指標類型主要有以下4 種: counter、gauge、histogram 和summary. counter 是只增不減的計數器,可以用于統計某種資源的累計消耗或者累計時間; gauge 用于那些具有增減變化的指標,比如當前某種資源的利用率或者可用量等; histogram 表示條形直方統計圖,可以表示數據的分布情況,比如某個時間段內的請求耗時分布; summary 類似與histogram,但是用于標識分位值,根據分位值顯示數據的分布情況.

2 容器資源監控的總體設計

本文設計實現的面向Kubernetes 的多集群資源監控分為4 個模塊: 集群管理模塊,數據采集模塊、數據處理模塊以及外部接口模塊. 集群管理模塊用于配置集群與檢測集群連通性; 采集模塊用于采集集群指定的接口數據與定時采集的設置; 數據處理模塊用于接口數據的解析、指標的提取與計算、數據格式的規范化以及數據的存儲; 接口設計模塊用于提供給可視化界面數據接口.

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

圖1 面向Kubernetes 的多集群資源監控模塊功能示意圖

3 容器資源監控的實現

3.1 集群管理

集群管理分為集群配置管理和集群連通性測試.集群配置管理主要的功能是管理集群的配置信息,包括集群名稱(用戶根據需求自定義)、集群API Server的端口地址(默認為集群的主節點的6443 端口)和相應的 token (用于認證,須預先在集群中配置好),為防止數據重復采集,集群名稱、端口地址須保證唯一. 為了驗證數據配置的準確性,提供集群連通性測試的功能,根據端口地址和token 創建一個API 用戶(ApiClient),使用這個用戶去訪問該集群的某個API 接口,根據是否能夠正常返回接口數據來判斷是否成功連通集群.

3.2 資源數據采集

資源數據的采集分為采集接口的確定,采集算法的設計與定時采集的設計.

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

表2 監控指標詳情

3 類接口中,“api/v1”和“apis/”提供集群級別的數據,直接采集接口數據即可,而“stats/summary”提供節點級別的數據,因此需要先獲取集群的節點列表后對每一個節點進行數據的提取. 為保證采集效率,設計采用多線程并行采集.

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

3.3 資源數據處理與存儲

由于采集的數據包含4 個種類和3 個層級的數據,因此需要對每條數據進行種類和層級的明確區分. 并且,這些數據需要進行結構的解析、字段的提取、數值的計算,將數據結構統一化、扁平化后再進行數據存儲.

3.3.1 資源數據的處理

數據處理的主要工作包括3 部分: 一是數據封裝,提取關鍵字段; 二是根據層級解析數據; 三是對部分數據進行二次計算,得到更直觀的數據.

3 類接口中,Java 相關類庫已將“api/v1”和“apis/”的所需的接口數據封裝成對象,通過現有方法提取關鍵字段即可; 針對不同層級的數據,Kubernetes 提供了不同的接口,無需額外區分層級; 對于數據本身,接口提供的是集群具體組件(Pod、容器、部署任務等)的狀態信息,無需進行數值上的計算. 故這兩類接口的數據處理工作相對簡單. 而“stats/summary”接口僅提供了獲取數據接口的方法,并沒有對數據結構進行封裝; 提供的數據包含節點、Pod、容器級別的數據,需要對數據根據層級進行區分; 接口數據包含gauge 類數據和counter 類數據,需要對部分數據進行二次計算.

“stats/summary”接口數據結構如圖2 所示,每類指標詳情參考表2,數據格式為JSON,可以使用JSON 解析工具(如“json2pojo”)將其封裝成Java 對象.

圖2 “stats/summary”接口數據結構圖

為了使數據扁平化便于存儲,所有層級的數據均添加集群、節點、命名空間、Pod、容器級別的字段,對于高層級數據中的低層級字段默認設置為空. 除此以外,數據中還添加一個“層級”字段,用于表明數據的層級,保證不同層級的數據不會在進行數據查詢時相互污染查詢結果.

另外,針對網絡的多接口添加“接口名”字段用于存放同一組件多個端口的數據,針對存儲的不同類型添加“存儲類型”字段,其中為volume 類型的額外添加“volume 名稱”字段用于保存同一組件中多個掛載volume 的數據.

表2 中顯示的資源指標中,counter 類型的指標和部分gauge 類型的指標需要進行二次計算,根據計算產生的新指標與計算方式如表3 所示. 由于采集可能因為集群通訊故障等原因導致采集的數據可能跨越多個時間間隔,因此,為了能夠表現監控數據的可靠性,表3 中的部分指標可以進行再計算(如單位時間內的平均網絡流量或者多個時間段中的內存使用量的峰值谷值等).

表3 監控新指標詳情

3.3.2 資源數據的存儲

對于“api/v1”和“apis/”的數據,只需要按需求獲取接口數據即可,無需進行數據存儲. 本節中只關注“stats/summary”接口的數據存儲工作.

整個資源數據根據資源類型分為4 類表: CPU表、內存表、網絡表、以及存儲表,每類表分為3 張表: 原始數據表(metadata),數據表(data)和最近一次數據表(last_data).

metadata 表用于存儲采集數據未處理過的指標,data 表用于存儲二次處理的字段,其中包含了metadata表中需要計算得到的指標以及需要轉換單位格式的指標,這張表將主要用于資源數據的展示與時間序列數據列的提取和分析; last_data 表中存放的是各組件最近一次采集到的指標數據,這張表的作用一是參與data 表字段數據的生成,主要針對metadata 表中counter類型的數據,生成相鄰時間戳間隔的指標數據; 二是用于資源數據的展示. 以容器為例,由于容器的生命周期十分短暫,當一個容器因為故障或者達到使用壽命后,Kubernetes 會將這個容器殺死,然后根據相同的鏡像生成一個新的容器繼續維持服務的運作,因此,在Kubernetes 集群中無法查找曾經生成過的容器. 盡管可以通過data 表來獲取歷史組件信息,但是表數據量的逐漸增大會逐漸降低查詢效率. 通過last_data 表,便可以獲取到歷史中某個集群所有能夠查詢到監控數據的組件的列表,根據這個列表就能夠獲取具體某個時間段中集群內存活的組件信息(包括節點,Pod,容器),并且數據增長速率相較于其余兩種表非常低,可以保證查詢的效率.

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

3.3.3 資源數據定時任務算法

第3.2 節中提到“stats/summary”接口提供的監控數據需要進行定時采集、處理和存儲,本文將這3 個部分統合成一個定時任務來實現.

算法1 給出任務的整體功能實現偽代碼. 根據集群列表獲取各集群的節點信息,接著按節點依次獲取監控數據,根據數據結構進行分層,再按照數據種類進行處理與存儲. 算法中,將同一類數據的處理與存儲封裝成一個服務(service)用于優化代碼格式; 實際實現中,在所有的for 循環中均使用了多線程用于提高算法運行的效率.

算法1. 資源數據定時任務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. //創建訪問API Server 的客戶端9. apiClient ← createApiClient(host,token)10. //獲取當前集群的節點列表11. nodeList ← getNodeList(apiClient)12. for node in nodeList

13. //獲取節點的監控數據14. i ← getStatsSummary(apiClient,node)15. //將數據解析成json 16. toJson(nodeStatsSummaryData)17. //c m對節點級別的4 類數據進行處理與存儲18. puService(i.getCpu())19. emoryService(i.getMemory())20. networkService(i.getNetwork())21. fsService(i.getFs())22. //獲取Pod 數據的列表,存放在i 中23. podStatsSummaryList ← i.getPodList()24. for j in podStatsSummaryList 25. //對Pod 級別的4 類數據進行處理與存儲26. cpuService(j.getCpu())27. memoryService(j.getMemory())28. networkService(j.getNetwork())29. fsService(j.getEphemeralStorage())30. fsService(j.getVolume())31. //獲取容器數據的列表,存放在j 中32. containerStatsSummaryList ← j.getContainerList()33. for k in containerStatsSummaryList 34. //對容器級別的3 類數據進行處理和存儲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

對于處理4 類資源的服務(service),主要實現的功能是第3.3.2 節中3 張表字段的提取與計算、表數據的添加與更新的功能,偽代碼見算法2.

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

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

4類數據均適用算法2,不過網絡和存儲類數據因為第3.3.1 節中提到的注意事項,需要添加一些循環來滿足功能需求,具體算法的實現過程基本一致.

3.4 外部訪問接口設計

外部訪問接口分為3 類,第1 類用于集群配置的增刪改查; 第2 類用于集群組件信息的查詢,如查詢集群的節點或者Pod 信息等,向用戶提供對應接口字段精簡后的數據; 第3 類用于查詢定時采集得到的監控指標,比如某個容器最近1 小時的CPU 使用情況等.具體實現的接口見表4.

表4 接口設計列表

除此以外,本文設計了2 個參數模板用于傳遞接口參數,用戶可以根據查詢的需求添加相應的參數,其中“K8sServer”用于用戶交互與API Server 類接口,“K8sConfig”用于數據庫類接口. 模板具體字段見表5.

表5 參數模型設計

對于監控指標查詢,由于集群之間邏輯上互相隔離,集群間的監控數據基本沒有邏輯關系,并且多集群的監控數據量很大,會大大影響查詢的效率,因此接口均基于某個特定的集群進行數據查詢.

4 實驗設計

本次實驗使用到4 個Kubernetes 集群,具體配置如表6 所示,其中集群1、2 操作系統為CentOS 7 ,集群3、4 操作系統為CentOS 8.

表6 集群信息

其中172.16 與10.168 兩個子網能夠相互通信,監控工具的IP 為172.16.2.183. 本次性能測試實驗主要測試集群資源開銷和訪問接口延時.

4.1 集群資源開銷

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

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

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

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

4.2 訪問接口延時

對于接口延時,設計在定時任務觸發后30 s 對接口進行數據訪問,分別采集集群級別、節點級別、Pod 級別、容器級別最近1 個小時的接口數據,定時任務和數據訪問頻率均為1 次/min. 接口數據的格式如圖3 所示.

圖3 接口數據展示

接口累計采集時間為2 235 min,單表數據條數從0 至35 萬余條,展示的數據為近10 min 的平均延時,延時單位為ms,具體的延時情況見表9.

表9 監控數據接口延時(ms)

接口延時的變化情況有如下幾個原因導致: 一是表數據量的增長增加了檢索數據的時間,二是采集的數據量的變化,由于獲取集群級別的數據量大于節點級別的數據量,其得到的接口延時也相對更高,三是網絡本身,由于網絡流量的波動,會在一定程度上影響接口的訪問延時,在計算2 160 min 處節點級別的10 條延時數據中,最短延時為1 981 ms,而最長的則為5 450 ms,可見其影響程度.

除了數據本身與網絡的影響,數據庫也是其中的影響之一,本次設計采用的是PostgreSQL 進行數據的存取,針對Kubernetes 監控數據量大、結構單一、時間屬性強的數據在性能上顯得有些不足. 如果使用針對性的時序數據庫,如InfluxDB,可以提高整個數據的存取性能.

5 結束語

本文基于Java 語言提出了一種面向Kubernetes的多集群資源監方案,實現了針對多個Kubernetes 集群的資源監控,此方案具有良好的可擴展性和靈活性,且實驗表明對集群資源的消耗低. 下一步的研究方向是采用時序數據庫來優化接口性能,還可以設計日志監控與告警功能來實現容器級別的立體化監控.