一. 前言

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

• kubectl top 為什么會報錯？
• kubectl top node 怎么計算，和節(jié)點上直接 top 有什么區(qū)別？
• kubectl top pod 怎么計算，包含 pause 嗎？
• kubectl top pod 和exec 進入 pod 后看到的 top 不一樣？
• kubectl top pod 和 docker stats得到的值為什么不同？

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

• k8s 1.8
• k8s 1.13

二. 使用

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

• 1.8以下：部署 heapter
• 1.8以上：部署 metric-server

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

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

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

指標含義：

• 和 k8s中 的 request、limit 一致，CPU單位100m=0.1 內存單位1Mi=1024Ki
• pod 的內存值是其實際使用量，也是做 limit 限制時判斷 oom 的依據。pod的使用量等于其所有業(yè)務容器的總和，不包括 pause 容器，值等于 cadvisr中的 container_memory_working_set_bytes 指標
• node 的值并不等于該 node 上所有 pod 值的總和，也不等于直接在機器上運行 top 或 free 看到的值

三. 實現原理

3.1 數據鏈路

kubectl top 、 k8s dashboard 以及 HPA 等調度組件使用的數據是一樣，數據鏈路如下：

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

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

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

3.2 metric api

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

• proxy 只是代理請求，一般用于問題排查，不夠穩(wěn)定，且版本不可控
• heapster 的接口不能像 apiserver 一樣有完整的鑒權以及 client 集成，兩邊都維護的話代價高，如 generic apiserver
• pod 的監(jiān)控數據是核心指標（HPA調度），應該和 pod 本身擁有同等地位，即 metric 應該作為一種資源存在，如 metrics.k8s.io 的形式，稱之為 Metric Api

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

3.3 kube-aggregator

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

如 metric-server 注冊 pod 和 node 時:

3.4 監(jiān)控體系

在提出 metric api 的概念時，官方也提出了新的監(jiān)控體系，監(jiān)控資源被分為了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 節(jié)點訪問 10255 端口（1.11版本過后是10250端口）獲取監(jiān)控數據：

• Kubelet Summary metrics: 127.0.0.1:10255/metrics，暴露 node、pod 匯總數據
• Cadvisor metrics: 127.0.0.1:10255/metrics/cadvisor，暴露 container 維度數據

示例，容器的內存使用量：

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

• 從k8s 1.6開始，kubernetes 將 cAdvisor 開始集成在kubelet中，不需要單獨配置
• 從k8s 1.7開始，Kubelet metrics API 不再包含 cadvisor metrics，而是提供了一個獨立的 API 接口來做匯總
• 從 k8s 1.12 開始，cadvisor 監(jiān)聽的端口在k8s中被刪除，所有監(jiān)控數據統(tǒng)一由 Kubelet 的 API 提供

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

3.6 cadvisor

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

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

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

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

3.7 cgroup

cgroup 文件中的值是監(jiān)控數據的最終來源，如

• 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 文件中，業(yè)務容器和 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 怎么計算，和節(jié)點上直接 top 有什么區(qū)別

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

在機器上直接 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，你會發(fā)現 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
的數據，用于回溯歷史或者發(fā)送報警。其他補充：

• 雖然 kubectl top help 中顯示支持 Storage，但直到 1.16 版本仍然不支持
• 1.13 之前需要 heapster，1.13 以后需要 metric-server，這部分 kubectl top help 的輸出 有誤，里面只提到了heapster
• k8s dashboard 中的監(jiān)控圖默認使用的是 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