目前promethues可以說是容器監控的標配，在k8s集群里面基本都會安裝promethues。promethues結合grafana可以通過豐富的指標展現。下面通過一個壓測的demo演示，容器底層對CPU和內存限制。

CPU

我們先介紹指標

# 容器CPU使用時間
rate(container_cpu_usage_seconds_total{pod=~"compute-.*", image!="", container!="POD"}[5m])

# 容器cpu request
avg(kube_pod_container_resource_requests_cpu_cores{pod=~"compute-.*"})

# 容器limit
avg(kube_pod_container_resource_limits_cpu_cores{pod=~"compute-.*"})

# 容器限流時間
rate(container_cpu_cfs_throttled_seconds_total{pod=~"compute-.*", container!="POD", image!=""}[5m])

最開始，系統沒有任何壓力

cpu的占用（藍色）0，限流（紅色）0，request（綠色） 0.5核，limit（黃色） 0.7 核。然后我們開始加壓?？梢钥吹剿{色線打到 request 和limt 之間的 0.6 核。此時限流還是 0，沒有觸發紅色限流。

當我們繼續加壓，請求超過limit的時候，CPU被控制在limit水位線。此時紅色的限流開始增加。

可以看到紅色限流大概處于0.3核的位置，那么應用總的請求就是 0.3 + 0.7 ，只不過其中的0.3 被CPU限流了，實際只使用了 0.7 （limit）。當把應用負載降下來的時候，限流再次回到0。

內存

內存的限制就比較簡單了，因為內存在底層是不可壓縮的資源。同樣的是我們先設置監控指標

# 內存用量
container_memory_working_set_bytes{pod_name=~"compute-.*", image!="", container!="POD"}

# 內存request
avg(kube_pod_container_resource_requests_memory_bytes{pod=~"compute-.*"})

# 內存limit
avg(kube_pod_container_resource_limits_memory_bytes{pod=~"compute-.*"})

期初也是0壓力，藍色線為0.

然后開始加壓，申請內存，沒有超過limit，正常運行

然后我們嘗試超過limit，結果悲劇了

容器直接被干掉了，可以查看事件，發生了OOM。通過get event查看。

default     22s         Warning   OOMKilling   node/aaa-resources-test-default-pool-6cad87bd-bgf4 
Memory cgroup out of memory: Kill process 134119 (stress) score 1962 or sacrifice child
Killed process 134119 (stress) total-vm:519288kB, anon-rss:508260kB, file-rss:268kB, shmem-rss:0kB