1. <menuitem id="xgxcv"><dfn id="xgxcv"></dfn></menuitem>

              • 自動秒收錄
              • 軟件:1973
              • 資訊:58156|
              • 收錄網站:237397|

              IT精英團

              從Kubectl Top看Kubernetes是如何監控資源的?

              從Kubectl Top看Kubernetes是如何監控資源的?

              瀏覽次數:
              評論次數:
              編輯: 溫瑜
              信息來源: ITPUB
              更新日期: 2022-08-11 21:00:38
              摘要

              一.前言kubectltop可以很方便地查看node、pod的實時資源使用情況:如CPU、內存。這篇文章會介紹其數據鏈路和實現原理,同時借kubectltop闡述k8s中的監控體系,

              • 正文開始
              • 相關閱讀
              • 推薦作品

              一.導言

              Kuctltop可以方便地查看節點和pod的實時資源使用情況,比如CPU和內存。本文將介紹其數據鏈路和實現原理,同時通過kubectl top講解k8s中的監控系統,一窺全豹。最后,將解釋一些常見問題:

              kubectl top為什么報錯?

              kuctl頂節點怎么算,kuctl頂節點和直接頂節點有什么區別?

              kubectl top pod怎么算,包含暫停嗎?

              kubectl top pod和exec進入pod后看到的頂部有區別嗎?

              為什么kuctl toppod和docker stats得到的值不一樣?

              以下命令的運行環境是:

              k8s 1.8

              k8s 1.13

              二。使用

              Kubectl top是基本命令,但是需要部署支持組件來獲得監視值。

              1.8以下內容:部署heapter

              上面的1.8:部署度量服務器

              Kubectl top node:查看節點的使用情況

              Kubectl top pod:檢查pod的使用情況

              如果不指定pod名稱,將顯示命名空間中的所有pod,而containers可以顯示pod中的所有容器。

              指標的含義:

              與k8s中的要求和限制一致,CPU單元100m=0.1內存單元1Mi=1024Ki

              pod的記憶值是它的實際用法,也是限制時判斷oom的依據。pod的使用量等于其所有業務容器的總和,不包括暫停容器,值等于cadvisr中的container _ memory _ working _ set _ bytes指標。

              node的值不等于節點上所有pod值的總和,也不等于直接在機器上運行top或free看到的值。

              三。實現原則

              3.1數據鏈路

              kuctltop、k8s dashboard、HPA等調度組件使用相同的數據,數據鏈接如下:

              3.jpg" width="1080" src="https://image.z.itpub.net/zitpub.net/JPG/2022-08-11/8F0649CECA4BC94ACE8DB0136CEC7523.jpg">

              使用 heapster 時:apiserver 會直接將 metric 請求通過 proxy 的方式轉發給集群內的 hepaster 服務。

              而使用 metrics-server 時:apiserver 是通過 /apis/metrics.k8s.io/ 的地址訪問 metric

              這里可以對比下 kubect get pod 時的日志:

              3.2 metric api

              可以發現,heapster 使用的是 proxy 轉發,而 metric-server 和普通 pod都是使用 api/xx 的資源接口,heapster采用的這種 proxy 方式是有問題的:

              • proxy 只是代理請求,一般用于問題排查,不夠穩定,且版本不可控

              • heapster 的接口不能像 apiserver 一樣有完整的鑒權以及 client 集成,兩邊都維護的話代價高,如 generic apiserver

              • pod 的監控數據是核心指標(HPA調度),應該和 pod 本身擁有同等地位,即 metric 應該作為一種資源存在,如 metrics.k8s.io 的形式,稱之為 Metric Api

              于是官方從 1.8 版本開始逐步廢棄 heapster,并提出了上邊 Metric api 的概念,而 metrics-server 就是這種概念下官方的一種實現,用于從 kubelet獲取指標,替換掉之前的 heapster


              3.3 kube-aggregator

              有了 metrics-server 組件,采集到了需要的數據,也暴露了接口,但走到這一步和 heapster 其實沒有區別,最關鍵的一步就是如何將打到 apiserver的 /apis/metrics.k8s.io 請求轉發給 metrics-server 組件?解決方案就是:kube-aggregator。kube-aggregator 是對 apiserver 的有力擴展,它允許 k8s 的開發人員編寫一個自己的服務,并把這個服務注冊到 k8s 的 api 里面,即擴展 API,metric-server 其實在 1.7版本就已經完成了,只是在等 kube-aggregator 的出現。kube-aggregator 是 apiserver 中的實現,有些 k8s 版本默認沒開啟,你可以加上這些配置來開啟,他的核心功能是動態注冊、發現匯總、安全代理。

              如 metric-server 注冊 pod 和 node 時:

              3.4 監控體系

              在提出 metric api 的概念時,官方也提出了新的監控體系,監控資源被分為了2種:

              • Core metrics(核心指標):從 Kubelet、cAdvisor 等獲取度量數據,再由metrics-server 提供給 Dashboard、HPA 控制器等使用。

              • Custom Metrics(自定義指標):由 Prometheus Adapter 提供 API custom.metrics.k8s.io,由此可支持任意Prometheus采集到的指標。

              核心指標只包含 node 和 pod 的 cpu、內存等,一般來說,核心指標作 HPA 已經足夠,但如果想根據自定義指標:如請求 qps/5xx 錯誤數來實現 HPA,就需要使用自定義指標了。目前 Kubernetes 中自定義指標一般由 Prometheus 來提供,再利用 k8s-prometheus-adpater 聚合到 apiserver,實現和核心指標同樣的效果。

              3.5 kubelet

              前面提到,無論是 heapster 還是 metric-server,都只是數據的中轉和聚合,兩者都是調用的 kubelet 的 api 接口獲取的數據,而 kubelet 代碼中實際采集指標的是 cadvisor 模塊,你可以在 node 節點訪問 10255 端口(1.11版本過后是10250端口)獲取監控數據:

              • Kubelet Summary metrics: 127.0.0.1:10255/metrics,暴露 node、pod 匯總數據

              • Cadvisor metrics: 127.0.0.1:10255/metrics/cadvisor,暴露 container 維度數據

              示例,容器的內存使用量:

              Kubelet 雖然提供了 metric 接口,但實際監控邏輯由內置的 cAdvisor 模塊負責,演變過程如下:

              • 從k8s 1.6開始,kubernetes 將 cAdvisor 開始集成在kubelet中,不需要單獨配置

              • 從k8s 1.7開始,Kubelet metrics API 不再包含 cadvisor metrics,而是提供了一個獨立的 API 接口來做匯總

              • 從 k8s 1.12 開始,cadvisor 監聽的端口在k8s中被刪除,所有監控數據統一由 Kubelet 的 API 提供

              到這里為止,k8s 范圍內的監控體系就結束了。

              3.6 cadvisor

              cadvisor 由谷歌開源,使用 Go 開發,cadvisor 不僅可以搜集一臺機器上所有運行的容器信息,包括 CPU 使用情況、內存使用情況、網絡吞吐量及文件系統使用情況,還提供基礎查詢界面和 http 接口,方便其他組件進行數據抓取。在K8S 中集成在 Kubelet 里作為默認啟動項,k8s 官方標配。cadvisor 拿到的數據結構示例:

              核心邏輯是通過 new 出來的 memoryStorage 以及 sysfs 實例,創建一個manager 實例,manager 的 interface 中定義了許多用于獲取容器和 machine 信息的函數

              cadvisor的指標解讀:cgroup-v1(https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt)

              cadvisor 獲取指標時實際調用的是 runc/libcontainer 庫,而 libcontainer 是對 cgroup 文件 的封裝,即 cadvsior 也只是個轉發者,它的數據來自于cgroup 文件。

              3.7 cgroup

              cgroup 文件中的值是監控數據的最終來源,如

              • mem usage 的值,來自于
                /sys/fs/cgroup/memory/docker/[containerId]/memory.usage_in_bytes

              • 如果沒限制內存,Limit=machine_mem,否則來自于
                /sys/fs/cgroup/memory/docker/[id]/memory.limit_in_bytes

              • 內存使用率=memory.usage_in_bytes/memory.limit_in_bytes

              一般情況下,cgroup文件夾下的內容包括CPU、內存、磁盤、網絡等信息:

              如 memory 下的幾個常用的指標含義:

              memory.stat 中的信息是最全的:

              原理到這里結束,這里解釋下最開始的 kubectl top 的幾個問題:

              四. 問題

              4.1 kubectl top 為什么會報錯

              一般情況下 top 報錯有以下幾種,可以 kubectl top pod -v=10看到具體的調用日志:

              • 沒有部署 heapster 或者 metric-server,或者 pod 運行異常,可以排查對應 pod 日志

              • 要看的 pod 剛剛建出來,還沒來得及采集指標,報 not found 錯誤,默認 1 分鐘

              • 以上兩種都不是,可以檢查下 kubelet 的 10255 端口是否開放,默認情況下會使用這個只讀端口獲取指標,也可以在 heapster 或 metric-server 的配置中增加證書,換成 10250 認證端口

              4.2 kubectl top pod 內存怎么計算,包含 pause容器嗎

              每次啟動 pod,都會有一個 pause 容器,既然是容器就一定有資源消耗(一般在 2-3M 的內存),cgroup 文件中,業務容器和 pause 容器都在同一個 pod的文件夾下。


              但 cadvisor 在查詢 pod 的內存使用量時,是先獲取了 pod 下的container列表,再逐個獲取container的內存占用,不過這里的 container 列表并沒有包含 pause,因此最終 top pod 的結果也不包含 pause 容器pod 的內存使用量計算kubectl top pod 得到的內存使用量,并不是 cadvisor 中的 container_memory_usage_bytes,而是 container_memory_working_set_bytes,計算方式為:

              • container_memory_usage_bytes = container_memory_rss + container_memory_cache + kernel memory

              • container_memory_working_set_bytes = container_memory_usage_bytes – total_inactive_file(未激活的匿名緩存頁)


              container_memory_working_set_bytes 是容器真實使用的內存量,也是 limit限制時的 oom 判斷依據。cadvisor 中的 container_memory_usage_bytes 對應 cgroup 中的 memory.usage_in_bytes 文件,但 container_memory_working_set_bytes 并沒有具體的文件,他的計算邏輯在 cadvisor 的代碼中,如下:


              同理,node 的內存使用量也是 container_memory_working_set_bytes。

              4.3 kubectl top node 怎么計算,和節點上直接 top 有什么區別

              kubectl top node 得到的 cpu 和內存值,并不是節點上所有 pod 的總和,不要直接相加。top node 是機器上 cgroup 根目錄下的匯總統計

              在機器上直接 top 命令看到的值和 kubectl top node 不能直接對比,因為計算邏輯不同,如內存,大致的對應關系是(前者是機器上 top,后者是 kubectl top):

              rss + cache = (in)active_anon + (in)active_file

              4.4 kubectl top pod 和 exec 進入 pod 后看到的 top 不一樣

              top 命令的差異和上邊一致,無法直接對比,同時,就算你對 pod 做了 limit 限制,pod 內的 top 看到的內存和 cpu 總量仍然是機器總量,并不是pod 可分配量

              • 進程的RSS為進程使用的所有物理內存(file_rss+anon_rss),即Anonymous pages+Mapped apges(包含共享內存)

              • cgroup RSS為(anonymous and swap cache memory),不包含共享內存。兩者都不包含file cache

              4.5 kubectl top pod 和 docker stats得到的值為什么不同?

              docker stats dockerID 可以看到容器當前的使用量:

              如果你的 pod 中只有一個 container,你會發現 docker stats 值不等于kubectl top 的值,既不等于 container_memory_usage_bytes,也不等于container_memory_working_set_bytes。因為docker stats 和 cadvisor 的計算方式不同,總體值會小于 kubectl top:計算邏輯是:

              docker stats = container_memory_usage_bytes - container_memory_cache

              五. 后記

              一般情況下,我們并不需要時刻關心 node 或 pod 的使用量,因為有集群自動擴縮容(cluster-autoscaler)和 pod 水平擴縮容(HPA)來應對這兩種資源變化,資源指標的意義更適合使用 prometheus 來持久化 cadvisor 的數據,用于回溯歷史或者發送報警。其他補充:

              • 雖然 kubectl top help 中顯示支持 Storage,但直到 1.16 版本仍然不支持

              • 1.13 之前需要 heapster,1.13 以后需要 metric-server,這部分 kubectl top help 的輸出 有誤,里面只提到了heapster

              • k8s dashboard 中的監控圖默認使用的是 heapster,切換為 metric-server后數據會異常,需要多部署一個metric-server-scraper 的 pod 來做接口轉換,具體參考 pr:https://github.com/kubernetes/dashboard/pull/3504

              六. 參考資料

              • https://github.com/kubernetes-sigs/metrics-server/issues/193

              • https://github.com/kubernetes/kubernetes/pull/83247

              • https://www.cnblogs.com/liuhongru/p/11215447.html

              • https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/walkthrough.md#quantity-values

              • https://github.com/fabric8io/kansible/blob/master/vendor/k8s.io/kubernetes/docs/design/resources.md

              • https://erdong.site/linux/system/computer-unit-conversion.html

              • https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu

              • https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/6/html/resource_management_guide/sec-memory

              • https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

              • https://www.cnblogs.com/liuhongru/p/11215447.html

              • https://github.com/moby/moby/issues/10824

              • https://github.com/docker/cli/pull/80

              標簽:內存 指標 數據
              如何在Linux上正確使用cat命令
              ? 上一篇 2022-08-10
              • 如何在Linux上正確使用cat命令
                0閱讀 0條評論 個贊
                cat可能是您將在Linux上首先學習的命令之一。以下是在Linux上使用cat的正確方法(和錯誤方法)。您將在Linux上使用的最基本的命令之一是cat。乍一看似乎很神秘,但實際……
              • 救火分享:記一次K8s控制平面排障的血淚經歷!
                0閱讀 0條評論 個贊
                集群以及環境信息的信息:k8sv1.18.43節點Master均為8核16G,50Gi-SSD差異化配置的19節點Minioncontrol-plane組件(kube-apise……
              • 淺談低代碼平臺的遠程組件加載方案
                2閱讀 0條評論 個贊
                淺談低代碼平臺遠程組件加載方案https://www.zoo.team/article/low-codehttps:前言低代碼開發平臺(LCDP)是無需編碼(0代碼)或通過少量代碼就可以快速生成應用……
              • 最近對前端構建工具的一些理解
                0閱讀 0條評論 個贊
                前言最近有幸在前端團隊里面做了一次關于webpack的技術分享。在分享的準備過程中,為了能讓大家更好的理解webpack,特意對市面上以前和現在流行的構建工具做了一個梳理總結。在整理和分享的過程……
              • 一萬字長文 手把手教你如何重構
                2閱讀 0條評論 個贊
                為什么要重構1_代碼重構漫畫.jpeg項目在不斷演進過程中,代碼不停地在堆砌。如果沒有人為代碼的質量負責,代碼總是會往越來越混亂的方向演進。當混亂到一定程度之后,量變引起質變,項目的維護成本已經高過重……
              發表評論 共有條評論
              用戶名: 密碼:
              驗證碼: 匿名發表
              • 如何優雅地修改Kubernetes主節點IP?但是沒你想的那么簡單!
                0閱讀 0條評論 個贊
                昨天網絡環境出了點問題,本地的虛擬機搭建的Kubernetes環境沒有固定IP,結果節點IP變了,當然最簡單的方式是將節點重新固定回之前的IP地址,但是自己頭鐵想去修改下集群的IP地……
              • 曾經帶領MongoDB和Docker走向輝煌的前Google Go語言負責人宣布離職!
                0閱讀 0條評論 個贊
                轉自:新智元編輯:HelloGitHub近期,谷歌Go語言產品負責人SteveFrancia宣布離開Google公司。我將辭去谷歌Go語言產品負責人的職務。我為Go團隊在過去六年……
              • Linux內核裁剪框架的初步研究
                3閱讀 0條評論 個贊
                大約是在2000年的時候,老碼農還很年輕,當時希望將Linux作為手機的操作系統,于是才有了進行內核裁剪的想法并輔助實踐,效果尚好,已經能在PDA上執行手機的功能了。一晃20多年過去了,Linux……
              • Redis內存優化技巧 小內存存大數據
                0閱讀 0條評論 個贊
                大家好,我是「碼哥」,大家可以叫我靚仔。這次碼哥跟大家分享一些優化神技,當你面試或者工作中你遇到如下問題,那就使出今天學到的絕招,一招定乾坤!?如何用更少的內存保存更多的數據?我們應該從Redis……
              • 一萬字長文 手把手教你如何重構
                2閱讀 0條評論 個贊
                為什么要重構1_代碼重構漫畫.jpeg項目在不斷演進過程中,代碼不停地在堆砌。如果沒有人為代碼的質量負責,代碼總是會往越來越混亂的方向演進。當混亂到一定程度之后,量變引起質變,項目的維護成本已經高過重……
              • 2022年全球開發者薪資曝光:中國排名第19 平均年薪23790美元
                6閱讀 0條評論 個贊
                ??整理|于軒出品|程序人生(ID:coder_life)近日,技術人才智能招聘平臺CodeSubmit發布了一份軟件工程行業的薪資報告,他們通過查找對比美國、歐盟、印度等20多個國家……
              • 提高數據科學效率的8個Python庫!
                0閱讀 0條評論 個贊
                來源丨數據STUDIO在進行數據科學時,可能會浪費大量時間編碼并等待計算機運行某些東西。所以我選擇了一些Python庫,可以幫助你節省寶貴的時間。1、OptunaOptuna是一個開源的超參數優……
              • 13個實用代碼片段 推薦收藏
                0閱讀 0條評論 個贊
                1、同字母異序詞2、二進制轉十進制3、復制文件4、一行代碼實現快速排序5、扁平化列表6、快速啟動一個httpserver7、非原地翻轉列表8、計算階乘9、統計列表中最長的單詞10、列表、集合、字典……
              • 大廠大數據平臺核心架構全層面圖解
                0閱讀 0條評論 個贊
                我們先來看看這張圖,這是某公司使用的大數據平臺架構圖,大部分公司應該都差不多:從這張大數據的整體架構圖上看來,大數據的核心層應該是:數據采集層、數據存儲與分析層、數據共享層、數據應用層,可能叫法有所不……
              • Python實現8個概率分布公式及可視化
                0閱讀 0條評論 個贊
                在本文中,我們將介紹一些常見的分布并通過Python代碼進行可視化以直觀地顯示它們。概率和統計知識是數據科學和機器學習的核心;我們需要統計和概率知識來有效地收集、審查、分析數據?,F實世界中有幾個現……
              • Kubernetes單機側驅逐策略綜述
                0閱讀 0條評論 個贊
                ?本文轉自Edwardesire的博客,原文:https://edwardesire.com/posts/process-eviction-under-k8s/,版權歸原作者所有。進程驅逐:當機器……
              • 這個困擾程序員50年的問題終于要解決了?
                1閱讀 0條評論 個贊
                作者lHollis來源lHollis(ID:hollischuang)近日,Google、微軟、facebook和亞馬遜終于忍不了了,聯合呼吁廢除閏秒,什么是閏秒呢?閏秒到底做錯了什么?為什……
              • Kubernetes 1.25中的主要變化和刪除
                3閱讀 0條評論 個贊
                隨著Kubernetes的發展和成熟,有些功能可能會被棄用、刪除或替換。Kubernetesv1.25包括幾項重大更改和刪除。KubernetesAPI移除和棄用流程Kubernetes……
              • 為什么還有人問MySQL是怎么存檔數據的?
                0閱讀 0條評論 個贊
                作者介紹陳臣,甲骨文MySQL首席解決方案工程師,公眾號《MySQL實戰》作者,有大規模的MySQL,Redis,MongoDB,ES的管理和維護經驗,擅長MySQL數據庫的性能優化及日常操作的原理剖……
              • K8S中的開發和運維對應用做了什么?
                0閱讀 0條評論 個贊
                在應用的整個生命周期里,開發和運維都和它密不可分。一個塑造它,一個保養它。如果應用需要部署到K8S中,開發和運維在其中都做了什么呢?開發側從開發側來說,我們的應用應該具備以下能力:具有健康檢測接口具有……
              • 重新審視分布式系統:永遠不會有完美的一致性方案.
                0閱讀 0條評論 個贊
                如今使用的幾乎所有軟件都是分布式系統的一部分,手機上的應用程序與托管在云中的服務一起工作,托管服務本身就是大規模的分布式系統,通常運行在遍布全球的機器上,大數據系統和大規模數據庫分布在許多機器上,大多……
              • 當沒有進程可調度時 內核在做什么?
                0閱讀 0條評論 個贊
                內核的主要職責是進程調度,比如當一個進程阻塞時,它會調度另外一個進程來執行。那當沒有進程可以調度時,內核在做什么呢?此時,內核會進入到idle狀態,其大致邏輯是:while(1){while(!n……
              • AI降維來襲 世界上幾乎所有已知的蛋白質結構都是開源的!
                1閱讀 0條評論 個贊
                轉自:機器之心科學界已知的幾乎所有蛋白質結構,都在這里了。蛋白質是生命的基礎構件,它們由氨基酸鏈組成,折疊成不同的復雜形狀。蛋白質的功能通常由其3D結構決定。如果我們了解蛋白質的折疊方式,就可以開……
              • 在Linux和Windows中刪除PDF密碼的極簡應用
                0閱讀 0條評論 個贊
                對于那些想要解鎖/解密PDF文件的人來說,現在有一個傻瓜式的簡單圖形工具可以在Linux中完成這項工作。在UbuntuLinux中加密PDF文件很容易,因為內置的LibreOffi……
              • 老司機的指示:請接受這份操作保養故障排除指南
                0閱讀 0條評論 個贊
                1.故障處理原則故障處理的原則只有兩個:以恢復業務優先及時升級1.1恢復業務優先恢復業務優先是指,不管在任何情況下,也不管任何級別的故障,都要先做到恢復業務,這個和故障定位不同,也有很多人會產生歧義,……
              最近發布資訊
              更多
              大乱纶一级A片
                1. <menuitem id="xgxcv"><dfn id="xgxcv"></dfn></menuitem>