Kubectl Top數(shù)據(jù)鏈路和實(shí)現(xiàn)原理

一、前言

kubectl top 可以很方便地查看node、pod 的實(shí)時(shí)資源使用情況：如CPU、內(nèi)存。這篇文章會(huì)介紹其數(shù)據(jù)鏈路和實(shí)現(xiàn)原理，同時(shí)借 kubectl top 闡述 k8s 中的監(jiān)控體系，窺一斑而知全豹。最后會(huì)解釋常見的一些問題：

kubectl top 為什么會(huì)報(bào)錯(cuò)？

kubectl top node 怎么計(jì)算，和節(jié)點(diǎn)上直接 top 有什么區(qū)別？

kubectl top pod 怎么計(jì)算，包含 pause 嗎？

kubectl top pod 和exec 進(jìn)入 pod 后看到的 top 不一樣？

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

以下命令的運(yùn)行環(huán)境為：

k8s 1.8

k8s 1.13

二、使用

kubectl top 是基礎(chǔ)命令，但是需要部署配套的組件才能獲取到監(jiān)控值

1.8以下：部署 heapter

1.8以上：部署 metric-server

kubectl top node: 查看node的使用情況

kubectl top pod: 查看 pod 的使用情況

不指定pod 名稱，則顯示命名空間下所有 pod，–containers可以顯示 pod 內(nèi)所有的container

指標(biāo)含義：

和 k8s中 的 request、limit 一致，CPU單位100m=0.1 內(nèi)存單位1Mi=1024Ki

pod 的內(nèi)存值是其實(shí)際使用量，也是做 limit 限制時(shí)判斷 oom 的依據(jù)。pod的使用量等于其所有業(yè)務(wù)容器的總和，不包括 pause 容器，值等于 cadvisr中的 container_memory_working_set_bytes 指標(biāo)

node 的值并不等于該 node 上所有 pod 值的總和，也不等于直接在機(jī)器上運(yùn)行 top 或 free 看到的值

三、實(shí)現(xiàn)原理

3.1 數(shù)據(jù)鏈路

kubectl top、 k8s dashboard 以及 HPA 等調(diào)度組件使用的數(shù)據(jù)是一樣，數(shù)據(jù)鏈路如下：

使用 heapster 時(shí)：apiserver 會(huì)直接將 metric 請(qǐng)求通過 proxy 的方式轉(zhuǎn)發(fā)給集群內(nèi)的 hepaster 服務(wù)。

而使用 metrics-server 時(shí)：apiserver 是通過 /apis/metrics.k8s.io/ 的地址訪問 metric

這里可以對(duì)比下 kubect get pod 時(shí)的日志：

3.2 metric api

可以發(fā)現(xiàn)，heapster 使用的是 proxy 轉(zhuǎn)發(fā)，而 metric-server 和普通 pod都是使用 api/xx 的資源接口，heapster采用的這種 proxy 方式是有問題的：

proxy 只是代理請(qǐng)求，一般用于問題排查，不夠穩(wěn)定，且版本不可控

heapster 的接口不能像 apiserver 一樣有完整的鑒權(quán)以及 client 集成，兩邊都維護(hù)的話代價(jià)高，如 generic apiserver

pod 的監(jiān)控?cái)?shù)據(jù)是核心指標(biāo)（HPA調(diào)度），應(yīng)該和 pod 本身?yè)碛型鹊匚?，?metric 應(yīng)該作為一種資源存在，如 metrics.k8s.io 的形式，稱之為 Metric Api

于是官方從 1.8 版本開始逐步廢棄 heapster，并提出了上邊 Metric api 的概念，而 metrics-server 就是這種概念下官方的一種實(shí)現(xiàn)，用于從 kubelet獲取指標(biāo)，替換掉之前的 heapster。

3.3 kube-aggregator

有了 metrics-server 組件，采集到了需要的數(shù)據(jù)，也暴露了接口，但走到這一步和 heapster 其實(shí)沒有區(qū)別，最關(guān)鍵的一步就是如何將打到 apiserver的 /apis/metrics.k8s.io 請(qǐng)求轉(zhuǎn)發(fā)給 metrics-server 組件？解決方案就是：kube-aggregator。kube-aggregator 是對(duì) apiserver 的有力擴(kuò)展，它允許 k8s 的開發(fā)人員編寫一個(gè)自己的服務(wù)，并把這個(gè)服務(wù)注冊(cè)到 k8s 的 api 里面，即擴(kuò)展 API，metric-server 其實(shí)在 1.7版本就已經(jīng)完成了，只是在等 kube-aggregator 的出現(xiàn)。kube-aggregator 是 apiserver 中的實(shí)現(xiàn)，有些 k8s 版本默認(rèn)沒開啟，你可以加上這些配置來開啟，他的核心功能是動(dòng)態(tài)注冊(cè)、發(fā)現(xiàn)匯總、安全代理。

如 metric-server 注冊(cè) pod 和 node 時(shí)：

3.4 監(jiān)控體系

在提出 metric api 的概念時(shí)，官方也提出了新的監(jiān)控體系，監(jiān)控資源被分為了2種：

Core metrics(核心指標(biāo))：從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù)，再由metrics-server 提供給 Dashboard、HPA 控制器等使用。

Custom Metrics(自定義指標(biāo))：由 Prometheus Adapter 提供 API custom.metrics.k8s.io，由此可支持任意Prometheus采集到的指標(biāo)。

核心指標(biāo)只包含 node 和 pod 的 cpu、內(nèi)存等，一般來說，核心指標(biāo)作 HPA 已經(jīng)足夠，但如果想根據(jù)自定義指標(biāo)：如請(qǐng)求 qps/5xx 錯(cuò)誤數(shù)來實(shí)現(xiàn) HPA，就需要使用自定義指標(biāo)了。目前 Kubernetes 中自定義指標(biāo)一般由 Prometheus 來提供，再利用 k8s-prometheus-adpater 聚合到 apiserver，實(shí)現(xiàn)和核心指標(biāo)同樣的效果。

3.5 kubelet

前面提到，無(wú)論是 heapster 還是 metric-server，都只是數(shù)據(jù)的中轉(zhuǎn)和聚合，兩者都是調(diào)用的 kubelet 的 api 接口獲取的數(shù)據(jù)，而 kubelet 代碼中實(shí)際采集指標(biāo)的是 cadvisor 模塊，你可以在 node 節(jié)點(diǎn)訪問 10255 端口（1.11版本過后是10250端口）獲取監(jiān)控?cái)?shù)據(jù)：

Kubelet Summary metrics: 127.0.0.1:10255/metrics，暴露 node、pod 匯總數(shù)據(jù)

Cadvisor metrics: 127.0.0.1:10255/metrics/cadvisor，暴露 container 維度數(shù)據(jù)

示例，容器的內(nèi)存使用量：

Kubelet 雖然提供了 metric 接口，但實(shí)際監(jiān)控邏輯由內(nèi)置的 cAdvisor 模塊負(fù)責(zé)，演變過程如下：

從k8s 1.6開始，kubernetes 將 cAdvisor 開始集成在kubelet中，不需要單獨(dú)配置

從k8s 1.7開始，Kubelet metrics API 不再包含 cadvisor metrics，而是提供了一個(gè)獨(dú)立的 API 接口來做匯總

從 k8s 1.12 開始，cadvisor 監(jiān)聽的端口在k8s中被刪除，所有監(jiān)控?cái)?shù)據(jù)統(tǒng)一由 Kubelet 的 API 提供

到這里為止，k8s 范圍內(nèi)的監(jiān)控體系就結(jié)束了。

3.6 cadvisor

cadvisor 由谷歌開源，使用 Go 開發(fā)，cadvisor 不僅可以搜集一臺(tái)機(jī)器上所有運(yùn)行的容器信息，包括 CPU 使用情況、內(nèi)存使用情況、網(wǎng)絡(luò)吞吐量及文件系統(tǒng)使用情況，還提供基礎(chǔ)查詢界面和 http 接口，方便其他組件進(jìn)行數(shù)據(jù)抓取。在K8S 中集成在 Kubelet 里作為默認(rèn)啟動(dòng)項(xiàng)，k8s 官方標(biāo)配。cadvisor 拿到的數(shù)據(jù)結(jié)構(gòu)示例：

核心邏輯是通過 new 出來的 memoryStorage 以及 sysfs 實(shí)例，創(chuàng)建一個(gè)manager 實(shí)例，manager 的 interface 中定義了許多用于獲取容器和 machine 信息的函數(shù)。

cadvisor的指標(biāo)解讀：cgroup-v1(https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt) cadvisor 獲取指標(biāo)時(shí)實(shí)際調(diào)用的是 runc/libcontainer 庫(kù)，而 libcontainer 是對(duì) cgroup 文件 的封裝，即 cadvsior 也只是個(gè)轉(zhuǎn)發(fā)者，它的數(shù)據(jù)來自于cgroup 文件。

3.7 cgroup

cgroup 文件中的值是監(jiān)控?cái)?shù)據(jù)的最終來源，如

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

如果沒限制內(nèi)存，Limit=machine_mem，否則來自于
/sys/fs/cgroup/memory/docker/[id]/memory.limit_in_bytes

內(nèi)存使用率=memory.usage_in_bytes/memory.limit_in_bytes

一般情況下，cgroup文件夾下的內(nèi)容包括CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等信息：

如 memory 下的幾個(gè)常用的指標(biāo)含義：

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

原理到這里結(jié)束，這里解釋下最開始的 kubectl top 的幾個(gè)問題：

四、問題

一般情況下 top 報(bào)錯(cuò)有以下幾種，可以 kubectl top pod -v=10看到具體的調(diào)用日志：

沒有部署 heapster 或者 metric-server，或者 pod 運(yùn)行異常，可以排查對(duì)應(yīng) pod 日志

要看的 pod 剛剛建出來，還沒來得及采集指標(biāo)，報(bào) not found 錯(cuò)誤，默認(rèn) 1 分鐘

以上兩種都不是，可以檢查下 kubelet 的 10255 端口是否開放，默認(rèn)情況下會(huì)使用這個(gè)只讀端口獲取指標(biāo)，也可以在 heapster 或 metric-server 的配置中增加證書，換成 10250 認(rèn)證端口

4.2 kubectl top pod 內(nèi)存怎么計(jì)算，包含 pause容器嗎

每次啟動(dòng) pod，都會(huì)有一個(gè) pause 容器，既然是容器就一定有資源消耗（一般在 2-3M 的內(nèi)存），cgroup 文件中，業(yè)務(wù)容器和 pause 容器都在同一個(gè) pod的文件夾下。

但 cadvisor 在查詢 pod 的內(nèi)存使用量時(shí)，是先獲取了 pod 下的container列表，再逐個(gè)獲取container的內(nèi)存占用，不過這里的 container 列表并沒有包含 pause，因此最終 top pod 的結(jié)果也不包含 pause 容器pod 的內(nèi)存使用量計(jì)算kubectl top pod 得到的內(nèi)存使用量，并不是 cadvisor 中的 container_memory_usage_bytes，而是 container_memory_working_set_bytes，計(jì)算方式為：

container_memory_usage_bytes = container_memory_rss + container_memory_cache + kernel memory

container_memory_working_set_bytes = container_memory_usage_bytes – total_inactive_file（未激活的匿名緩存頁(yè)）

container_memory_working_set_bytes 是容器真實(shí)使用的內(nèi)存量，也是 limit限制時(shí)的 oom 判斷依據(jù)。cadvisor 中的 container_memory_usage_bytes 對(duì)應(yīng) cgroup 中的 memory.usage_in_bytes 文件，但 container_memory_working_set_bytes 并沒有具體的文件，他的計(jì)算邏輯在 cadvisor 的代碼中，如下：

同理，node 的內(nèi)存使用量也是 container_memory_working_set_bytes。

4.3 kubectl top node 怎么計(jì)算，和節(jié)點(diǎn)上直接 top 有什么區(qū)別

kubectl top node 得到的 cpu 和內(nèi)存值，并不是節(jié)點(diǎn)上所有 pod 的總和，不要直接相加。top node 是機(jī)器上 cgroup 根目錄下的匯總統(tǒng)計(jì)。

在機(jī)器上直接 top 命令看到的值和 kubectl top node 不能直接對(duì)比，因?yàn)橛?jì)算邏輯不同，如內(nèi)存，大致的對(duì)應(yīng)關(guān)系是(前者是機(jī)器上 top，后者是 kubectl top)：

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

4.4 kubectl top pod 和 exec 進(jìn)入 pod 后看到的 top 不一樣

top 命令的差異和上邊一致，無(wú)法直接對(duì)比，同時(shí)，就算你對(duì) pod 做了 limit 限制，pod 內(nèi)的 top 看到的內(nèi)存和 cpu 總量仍然是機(jī)器總量，并不是pod 可分配量

進(jìn)程的RSS為進(jìn)程使用的所有物理內(nèi)存（file_rss＋anon_rss），即Anonymous pages＋Mapped apges（包含共享內(nèi)存）

cgroup RSS為（anonymous and swap cache memory），不包含共享內(nèi)存。兩者都不包含file cache

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

docker stats dockerID 可以看到容器當(dāng)前的使用量：

如果你的 pod 中只有一個(gè) container，你會(huì)發(fā)現(xiàn) docker stats 值不等于kubectl top 的值，既不等于 container_memory_usage_bytes，也不等于container_memory_working_set_bytes。因?yàn)閐ocker stats 和 cadvisor 的計(jì)算方式不同，總體值會(huì)小于 kubectl top：計(jì)算邏輯是：

docker stats = container_memory_usage_bytes - container_memory_cache

五、后記

一般情況下，我們并不需要時(shí)刻關(guān)心 node 或 pod 的使用量，因?yàn)橛屑鹤詣?dòng)擴(kuò)縮容(cluster-autoscaler)和 pod 水平擴(kuò)縮容（HPA）來應(yīng)對(duì)這兩種資源變化，資源指標(biāo)的意義更適合使用 prometheus 來持久化 cadvisor 的數(shù)據(jù)，用于回溯歷史或者發(fā)送報(bào)警。其他補(bǔ)充：

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

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

k8s dashboard 中的監(jiān)控圖默認(rèn)使用的是 heapster，切換為 metric-server后數(shù)據(jù)會(huì)異常，需要多部署一個(gè)metric-server-scraper 的 pod 來做接口轉(zhuǎn)換