深刻理解kubernetes容器指標

經過cAdvisor收集容器指標

Google的cAdvisor項目最初是一個獨立項目，用於從節點上收集運行的容器的資源和性能指標。在Kubernetes中，cAdvisor嵌入到kubelet中。kubelet控制着集羣中每一個節點上的全部容器。這就很方便了，由於不須要在每一個節點中都運行另外一個進程來收集容器指標。

kubelet以Prometheus指標格式在/metrics端點上公開了全部運行時指標和全部cAdvisor指標。

從cAdvisor提供的「容器」度量標準最終是底層Linux cgroup提供報告的度量標準。就像節點指標同樣，它們衆多且詳細。可是，咱們關注基礎節點提供的資源的容器使用。具體來講，咱們對CPU，內存，網絡和磁盤感興趣。一樣，在處理資源時，最好在選擇這些指標的報告時使用USE方法。

容器指標概述

因爲這些度量標準的來源從節點（node_exporter）更改成容器（cAdvisor），所以度量標準的名稱也將更改。此外，每一個指標都是集羣中全部容器的報告。要得到應用程序的總體視圖，必須在Prometheus中使用sum方法。

在開始討論各個資源指標以前，咱們須要討論Kubernetes中的一項功能，該功能將使飽和度的計算更加容易。此功能是資源「requests」和「limits」。

Requests 和 Limits

Kubernetes系統的核心是一個調度程序，它將容器調度在節點上。就像用不一樣大小的物品包裝一堆不一樣大小的盒子同樣，調度程序須要知道節點的容量以及放在這些節點上的容器的大小。在不知道容器的「大小」的狀況下，您能夠輕鬆地對羣集中的節點進行過分配置，從而由​​於擁擠而致使性能問題。

請求和限制將做爲部署的一部分應用於容器規範。從Kubernetes 1.10開始，能夠設置兩種資源類型的請求和限制; CPU和內存。將CPU指定爲core數，並以字節爲單位指定內存。

請求是對容器將須要的最少資源量。請求並無說明您將使用多少資源，而是須要多少資源。您正在告訴調度程序容器需​​要多少資源來完成其工做。請求由Kubernetes調度程序用於調度。對於CPU請求，它們還用於配置Linux內核如何調度容器。

限制是您的容器將要使用的最大資源量。限制必須大於或等於請求。若是僅設置限制，則請求將與限制相同。

限制容許容器有必定的餘量來超過資源請求。限制爲您提供了一個旋鈕，能夠過分使用節點上的資源，由於Kubernetes調度程序不考慮限制。話雖如此，若是您的容器超出了限制，則操做取決於資源；若是您超過CPU限制，將受到限制；若是超過內存限制，將被殺死。

CPU Utilization, Saturation, 和 Errors

對於CPU利用率，Kubernetes僅爲咱們提供了每一個容器的三個指標:

1. container_cpu_user_seconds_total--「user」時間總數（即，不在內核中花費的時間）
2. container_cpu_system_seconds_total--「system」時間的總數（即在內核中花費的時間）
3. container_cpu_usage_seconds_total--以上的總和。在Kubernetes 1.9以前的版本中，將爲全部節點中的每一個CPU報告此錯誤。在1.10中發生了變化。

全部這些指標都是計數器，須要對其應用rate。該查詢將爲咱們提供每一個容器正在使用的核心數。對於整個系統中該名稱的全部容器：

sum(
    rate(container_cpu_usage_seconds_total[5m]))
by (container_name)

當使用CPU限制運行時，因爲定義了CPU使用上限，飽和度的計算變得容易得多。當容器超出其CPU限制時，Linux運行時將「限制」該容器並在container_cpu_cfs_throttled_seconds_total系列中記錄其被限制的時間。再次按容器跟蹤每一個容器，所以採用一個比率：

sum(
    rate(container_cpu_cfs_throttled_seconds_total[5m])) 
by (container_name)

這是跟蹤具備CPU限制的運行時間的重要指標。

就像node_exporter同樣，cAdvisor不會暴露CPU錯誤。

內存 Utilization, Saturation 和Errors

cAdvisor中跟蹤的內存指標是從node_exporter公開的43個內存指標的子集。如下是容器內存指標：

container_memory_cache -- Number of bytes of page cache memory.
container_memory_rss -- Size of RSS in bytes.
container_memory_swap -- Container swap usage in bytes.
container_memory_usage_bytes -- Current memory usage in bytes,       
                                including all memory regardless of
                                when it was accessed.
container_memory_max_usage_bytes -- Maximum memory usage recorded 
                                    in bytes.
container_memory_working_set_bytes -- Current working set in bytes.
container_memory_failcnt -- Number of memory usage hits limits.
container_memory_failures_total -- Cumulative count of memory 
                                   allocation failures.

您可能認爲能夠經過container_memory_usage_bytes輕鬆跟蹤內存利用率，可是，該指標還包括能夠在內存壓力下驅逐的緩存（認爲是文件系統緩存）項。更好的指標是container_memory_working_set_bytes，由於這是OOM殺手正在關注的對象。

要計算容器的內存利用率，咱們使用：

sum(container_memory_working_set_bytes{name!~"POD"})
  by (name)

在上述查詢中，咱們須要排除名稱中包含「POD」的容器。這是此容器的父級cgroup，將跟蹤pod中全部容器的統計信息。

在有內存限制的狀況下運行時，容器的內存飽和度會變得更容易。咱們將從飽和度定義飽和度爲可用內存量：

sum(container_memory_working_set_bytes) by (container_name) / sum(label_join(kube_pod_container_resource_limits_memory_bytes,
    "container_name", "", "container")) by (container_name)

在這裏，咱們必須加入兩個系列，一個來自cAdvisor，一個來自kube-state-metrics。不幸的是，容器名稱標籤沒有對齊，可是PromQL在這裏可使用label_join幫助。

kubelet不會暴露內存錯誤。

磁盤 Utilization, Saturation, 和Errors

在處理磁盤I / O時，咱們首先經過查找以及讀取和寫入跟蹤全部磁盤利用率。 cAdvisor具備針對container_fs_io_time_seconds_total和container_fs_io_time_weighted_seconds_total的系列。這些應該在節點級別跟蹤類似的指標，可是在個人安裝中，它們始終爲零。

最基本的磁盤I/O利用率是讀/寫的字節數：

sum(rate(container_fs_writes_bytes_total[5m])) by (container_name,device)
sum(rate(container_fs_reads_bytes_total[5m])) by (container_name,device)

對這些求和求和，以得到每一個容器的整體磁盤I/O利用率。

Kubelet沒有公開足夠的細節，沒法對容器磁盤飽和或錯誤進行有意義的查詢。

網絡 Utilization, Saturation 和Errors

您能夠在容器級別的網絡利用率之間進行選擇，以字節或數據包爲單位進行發送和接收。該查詢有些不一樣，由於全部網絡記賬都在Pod級別上進行，而不是在容器上進行！

此查詢將按Pod名稱顯示每一個Pod的網絡利用率：

sum(rate(container_network_receive_bytes_total[5m])) by (name)
sum(rate(container_network_transmit_bytes_total[5m])) by (name)

一樣，在不知道最大網絡帶寬是多少的狀況下，網絡的飽和度定義不明確。您也許可使用丟棄的數據包做爲代理。 cAdvisor會同時提供container_network_receive_packets_dropped_total和container_network_transmit_packets_dropped_total。

cAdvisor還將顯示系列container_network_receive_errors_total和container_network_transmit_errors_total的錯誤數量。