前言

?承接上文?,我們?cè)诨?span style="background-color: #F3F4F4;">Ubuntu 2204使用kubeadm部署了k8s集群,且基于helm部署了metrics-server.

然后我們可以很歡快的使用kubectl top命令查看node、pod的實(shí)時(shí)資源使用情況：如CPU、內(nèi)存。

本文將介紹其數(shù)據(jù)鏈路和實(shí)現(xiàn)原理，同時(shí)會(huì)闡述k8s中的監(jiān)控體系。

kubectl top

kubectl top是我們經(jīng)常使用的基礎(chǔ)命令，但是必須需要部署metrics-server組件，才能獲取到監(jiān)控值。

• 在kubernetes 1.8版本之前，則需要部署heapter， 現(xiàn)已被廢棄。
• 在kubernetes1.8以及以上，則需要部署metrics-server。

我們所使用的版本是1.24.3的最新版本，所以一定要部署metrics-server。

查看node的資源使用情況。

$ kubectl top node
NAME         CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-unode1   158m         7%     1814Mi          47%
k8s-unode2   50m          2%     874Mi           23%
k8s-unode3   51m          2%     943Mi           24%
k8s-unode4   45m          2%     905Mi           23%
$ kubectl top node k8s-unode1
NAME         CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-unode1   160m         8%     1811Mi          47%

查看pod的資源使用情況，--containers可以顯示pod內(nèi)所有的container。

$ kubectl top pod -n metrics-server
NAME                              CPU(cores)   MEMORY(bytes)
metrics-server-56c6866684-w6n9b   5m           17Mi
$ kubectl top pod --containers -n metrics-server
POD                               NAME             CPU(cores)   MEMORY(bytes)
metrics-server-56c6866684-w6n9b   metrics-server   5m           17Mi

指標(biāo)的具體含義：

• 這里CPU 的m 和 memory 的 mi 與k8s中 request、limit是一致的，cpu單位的100m=0.1 內(nèi)存單位 1MI=1204Ki。
• pod的內(nèi)存值是其內(nèi)存的實(shí)際使用量，也是做limit限制時(shí)判斷oom的依據(jù)。pod的使用量等于其所有業(yè)務(wù)容器的綜合，但是不包含pause容器。與Cadvisr中的container_memory_working_set_bytes 指標(biāo)值相等。
• node的值并不等于該node上所有pod值的總和，也不等于直接在機(jī)器上執(zhí)行top或free所得到的值。

kubectl top pod 內(nèi)存計(jì)算

每次啟動(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（未激活的匿名緩存頁）。

container_memory_working_set_bytes是容器真實(shí)使用的內(nèi)存量，也是limit限制時(shí)的 oom 判斷依據(jù)。

kubectl top命令和 top 的差異和上邊 一致，無法直接對(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。

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

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

k8s dashboard、kubectl top等都是通過apiserver獲取監(jiān)控?cái)?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。

監(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)（metric-server)同樣的效果。

kubelet

無論是廢棄的heapster還是metric-server，都只是數(shù)據(jù)的中轉(zhuǎn)和聚合；兩者都是調(diào)用的kubelet的api接口獲取的數(shù)據(jù)。kubelet代碼中實(shí)際集成了采集指標(biāo)的cAdvisor模塊，可以通過kubelet暴露的10250端口獲取監(jiān)控?cái)?shù)據(jù)。

• Kubelet Summary metrics: 127.0.0.1:10250/metrics，暴露 node、pod 匯總數(shù)據(jù)。
• Cadvisor metrics: 127.0.0.1:10250/metrics/cadvisor，暴露 container 維度數(shù)據(jù)。

kubelet雖然提供了 metric 接口，但實(shí)際監(jiān)控邏輯由內(nèi)置的cAdvisor模塊負(fù)責(zé)。

cAdvisor

cAdvisor由谷歌開源，使用go語言開發(fā)。項(xiàng)目地址：https://github.com/google/cadvisor。

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獲取指標(biāo)時(shí)實(shí)際調(diào)用的是 runc/libcontainer庫，而libcontainer是對(duì) cgroup文件 的封裝，即 cadvsior也只是個(gè)轉(zhuǎn)發(fā)者，它的數(shù)據(jù)來自于cgroup文件。

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ò)等信息。

device：設(shè)備控制權(quán)限
cpuset：分配指定的CPU和內(nèi)存節(jié)點(diǎn)
cpu：控制CPU占用率
cpuacct：統(tǒng)計(jì)CPU使用情況
memory：限制內(nèi)存的使用上限
freezer：凍結(jié)Cgroup中的進(jìn)程
net_cls：配合（traffic controller）限制網(wǎng)絡(luò)帶寬
net_prio：設(shè)置進(jìn)程的網(wǎng)絡(luò)流量?jī)?yōu)先級(jí)
huge_tlb：限制HugeTLB的使用
pref_event：允許perf工具基于cgrgoup分組做性能監(jiān)測(cè)

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

memory.usage_in_bytes: 已使用的內(nèi)存量（包含cache和buffer）字節(jié)，相當(dāng)于linux的userd_mem
memory.limit_in_bytes: 限制的內(nèi)存總量（字節(jié)），相當(dāng)于linux的total_mem
memory.failcnt:    申請(qǐng)內(nèi)存失敗次數(shù)計(jì)數(shù)
memory.stat: 內(nèi)存相關(guān)狀態(tài)
memory.memsw.usage_in_bytes:  已使用內(nèi)存和swap
memory.memsw.limit_in_bytes: 限制的內(nèi)存和swap
memory.memsw.failcnt: 申請(qǐng)內(nèi)存和swap失敗次數(shù)計(jì)數(shù)