介紹

使用 Kubernetes 時，內(nèi)存不足 (OOM) 錯誤和 CPU 節(jié)流是云應用程序中資源處理的主要難題。

這是為什么？

云應用程序中的 CPU 和內(nèi)存要求變得越來越重要，因為它們與您的云成本直接相關。

通過 limits 和 requests ，您可以配置 pod 應如何分配內(nèi)存和 CPU 資源，以防止資源匱乏并調(diào)整云成本。

如果節(jié)點沒有足夠的資源， Pod 可能會通過搶占或節(jié)點壓力被驅當一個進程運行內(nèi)存不足 (OOM) 時，它會被終止，因為它沒有所需的資源。

如果 CPU 消耗高于實際限制，進程將開始節(jié)流。

但是，如何主動監(jiān)控 Kubernetes Pod 到達 OOM 和 CPU 節(jié)流的距離有多近？

Kubernetes OOM

Pod 中的每個容器都需要內(nèi)存才能運行。

Kubernetes limits 是在 Pod 定義或 Deployment 定義中為每個容器設置的。

所有現(xiàn)代 Unix 系統(tǒng)都有一種方法來終止進程，以防它們需要回收內(nèi)存。這將被標記為錯誤 137 或OOMKilled.

State:Running
Started:Thu,10Oct20191113+0200
LastState:Terminated
Reason:OOMKilled
ExitCode:137
Started:Thu,10Oct20191103+0200
Finished:Thu,10Oct20191111+0200

此退出代碼 137 表示該進程使用的內(nèi)存超過允許的數(shù)量，必須終止。

這是 Linux 中存在的一個特性，內(nèi)核oom_score為系統(tǒng)中運行的進程設置一個值。此外，它允許設置一個名為 oom_score_adj 的值，Kubernetes 使用該值來允許服務質量。它還具有一個 OOM Killer功能，它將審查進程并終止那些使用比他們應該使用上限更多的內(nèi)存的進程。

請注意，在 Kubernetes 中，進程可以達到以下任何限制：

在容器上設置的 Kubernetes Limit。

在命名空間上設置的 Kubernetes ResourceQuota。

節(jié)點的實際內(nèi)存大小。

內(nèi)存過量使用

Limits 可以高于 requests，因此所有限制的總和可以高于節(jié)點容量。這稱為過度使用，這很常見。實際上，如果所有容器使用的內(nèi)存都比請求的多，它可能會耗盡節(jié)點中的內(nèi)存。這通常會導致一些 pod 被殺死以釋放一些內(nèi)存。

監(jiān)控 Kubernetes OOM

在 Prometheus 中使用 node exporter 時，有一個指標稱為node_vmstat_oom_kill. 跟蹤 OOM 終止發(fā)生的時間很重要，但您可能希望在此類事件發(fā)生之前提前了解此類事件。

相反，您可以檢查進程與 Kubernetes 限制的接近程度：

(sumby(namespace,pod,container)
(rate(container_cpu_usage_seconds_total{container!=""}[5m]))/sumby
(namespace,pod,container)
(kube_pod_container_resource_limits{resource="cpu"}))>0.8

Kubernetes CPU 節(jié)流

CPU 節(jié)流 是一種行為，當進程即將達到某些資源限制時，進程會變慢。

與內(nèi)存情況類似，這些限制可能是：

在容器上設置的 Kubernetes Limit。

在命名空間上設置的 Kubernetes ResourceQuota。

節(jié)點的實際CPU大小。

想想下面的類比。我們有一條有一些交通的高速公路，其中：

CPU 就是路。

車輛代表進程，每個車輛都有不同的大小。

多條通道代表有多個核心。

一個 request 將是一條專用道路，如自行車道。這里的節(jié)流表現(xiàn)為交通堵塞：最終，所有進程都會運行，但一切都會變慢。

Kubernetes 中的 CPU 進程

CPU 在 Kubernetes 中使用 shares 處理。每個 CPU 核心被分成 1024 份，然后使用 Linux 內(nèi)核的 cgroups（控制組）功能在所有運行的進程之間分配。

如果 CPU 可以處理所有當前進程，則不需要任何操作。如果進程使用超過 100% 的 CPU，那么份額就會到位。與任何 Linux Kernel 一樣，Kubernetes 使用 CFS（Completely Fair Scheduler）機制，因此擁有更多份額的進程將獲得更多的 CPU 時間。

與內(nèi)存不同，Kubernetes 不會因為節(jié)流而殺死 Pod。

可以在 /sys/fs/cgroup/cpu/cpu.stat 中查看 CPU 統(tǒng)計信息

CPU 過度使用

正如我們在 限制和請求一文 中看到的，當我們想要限制進程的資源消耗時，設置限制或請求很重要。然而，請注意不要將請求總數(shù)設置為大于實際 CPU 大小，因為這意味著每個容器都應該有一定數(shù)量的 CPU。

監(jiān)控 Kubernetes CPU 節(jié)流

您可以檢查進程與 Kubernetes 限制的接近程度：

(sumby(namespace,pod,container)(rate(container_cpu_usage_seconds_total
{container!=""}[5m]))/sumby(namespace,pod,container)
(kube_pod_container_resource_limits{resource="cpu"}))>0.8

如果我們想跟蹤集群中發(fā)生的節(jié)流量，cadvisor 提供container_cpu_cfs_throttled_periods_total和container_cpu_cfs_periods_total. 有了這兩個，你就可以輕松計算出所有 CPU 周期的 throttling 百分比。

最佳實踐

注意 limits 和 requests

限制是在節(jié)點中設置最大資源上限的一種方法，但需要謹慎對待這些限制，因為您可能最終會遇到一個進程被限制或終止的情況。

做好被驅逐的準備

通過設置非常低的請求，您可能認為這會為您的進程授予最少的 CPU 或內(nèi)存。但是kubelet會首先驅逐那些使用率高于請求的 Pod，因此您將它們標記為第一個被殺死！

如果您需要保護特定 Pod 免遭搶占（當kube-scheduler需要分配新 Pod 時），請為最重要的進程分配優(yōu)先級。

節(jié)流是無聲的敵人

通過設置不切實際的限制或過度使用，您可能沒有意識到您的進程正在受到限制，并且性能受到影響。主動監(jiān)控您的 CPU 使用率并了解您在容器和命名空間中的實際限制。

審核編輯：劉清