一、前言

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

kubectl top 為什么會報錯？

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

kubectl top pod 怎么計算，包含 pause 嗎？

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

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

以下命令的運行環境為：

k8s 1.8

k8s 1.13

二、使用

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

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的使用量等于其所有業務容器的總和，不包括 pause 容器，值等于 cadvisr中的 container_memory_working_set_bytes 指標

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

三、實現原理

3.1 數據鏈路

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

使用 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 的幾個問題：

四、問題

一般情況下 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 來做接口轉換