介紹

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

這是為什么？

云應(yīng)用程序中的 CPU 和內(nèi)存要求變得越來(lái)越重要，因?yàn)樗鼈兣c您的云成本直接相關(guān)。

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

如果節(jié)點(diǎn)沒(méi)有足夠的資源， Pod 可能會(huì)通過(guò)搶占或節(jié)點(diǎn)壓力被驅(qū)當(dāng)一個(gè)進(jìn)程運(yùn)行內(nèi)存不足 (OOM) 時(shí)，它會(huì)被終止，因?yàn)樗鼪](méi)有所需的資源。

如果 CPU 消耗高于實(shí)際限制，進(jìn)程將開(kāi)始節(jié)流。

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

Kubernetes OOM

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

Kubernetes limits 是在 Pod 定義或 Deployment 定義中為每個(gè)容器設(shè)置的。

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

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

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

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

請(qǐng)注意，在 Kubernetes 中，進(jìn)程可以達(dá)到以下任何限制：

在容器上設(shè)置的 Kubernetes Limit。

在命名空間上設(shè)置的 Kubernetes ResourceQuota。

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

內(nèi)存過(guò)量使用

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

監(jiān)控 Kubernetes OOM

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

相反，您可以檢查進(jìn)程與 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é)流 是一種行為，當(dāng)進(jìn)程即將達(dá)到某些資源限制時(shí)，進(jìn)程會(huì)變慢。

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

在容器上設(shè)置的 Kubernetes Limit。

在命名空間上設(shè)置的 Kubernetes ResourceQuota。

節(jié)點(diǎn)的實(shí)際CPU大小。

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

CPU 就是路。

車(chē)輛代表進(jìn)程，每個(gè)車(chē)輛都有不同的大小。

多條通道代表有多個(gè)核心。

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

Kubernetes 中的 CPU 進(jìn)程

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

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

與內(nèi)存不同，Kubernetes 不會(huì)因?yàn)楣?jié)流而殺死 Pod。

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

CPU 過(guò)度使用

正如我們?cè)?限制和請(qǐng)求一文 中看到的，當(dāng)我們想要限制進(jìn)程的資源消耗時(shí)，設(shè)置限制或請(qǐng)求很重要。然而，請(qǐng)注意不要將請(qǐng)求總數(shù)設(shè)置為大于實(shí)際 CPU 大小，因?yàn)檫@意味著每個(gè)容器都應(yīng)該有一定數(shù)量的 CPU。

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

您可以檢查進(jìn)程與 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. 有了這兩個(gè)，你就可以輕松計(jì)算出所有 CPU 周期的 throttling 百分比。

最佳實(shí)踐

注意 limits 和 requests

限制是在節(jié)點(diǎn)中設(shè)置最大資源上限的一種方法，但需要謹(jǐn)慎對(duì)待這些限制，因?yàn)槟赡茏罱K會(huì)遇到一個(gè)進(jìn)程被限制或終止的情況。

做好被驅(qū)逐的準(zhǔn)備

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

如果您需要保護(hù)特定 Pod 免遭搶占（當(dāng)kube-scheduler需要分配新 Pod 時(shí)），請(qǐng)為最重要的進(jìn)程分配優(yōu)先級(jí)。

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

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

審核編輯：劉清