Kubernetes 為系統(tǒng)守護進程預留計算資源

為系統(tǒng)守護進程預留計算資源

Kubernetes 的節(jié)點可以按照 ?Capacity ?調(diào)度。默認情況下 pod 能夠使用節(jié)點全部可用容量。 這是個問題，因為節(jié)點自己通常運行了不少驅(qū)動 OS 和 Kubernetes 的系統(tǒng)守護進程。 除非為這些系統(tǒng)守護進程留出資源，否則它們將與 pod 爭奪資源并導致節(jié)點資源短缺問題。

?kubelet ?公開了一個名為 'Node Allocatable' 的特性，有助于為系統(tǒng)守護進程預留計算資源。 Kubernetes 推薦集群管理員按照每個節(jié)點上的工作負載密度配置 “Node Allocatable”。

在開始之前

你必須擁有一個 Kubernetes 的集群，同時你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 建議在至少有兩個節(jié)點的集群上運行本教程，且這些節(jié)點不作為控制平面主機。 如果你還沒有集群，你可以通過 Minikube 構(gòu)建一個你自己的集群，或者你可以使用下面任意一個 Kubernetes 工具構(gòu)建：

• Katacoda
• 玩轉(zhuǎn) Kubernetes

您的 Kubernetes 服務器的版本必須為 1.8 或更高版本。 要檢查版本，請輸入 ?kubectl version?。

你的 kubernetes 服務器版本必須至少是 1.17 版本，才能使用 kubelet 命令行選項 ?--reserved-cpus? 設置 顯式預留 CPU 列表。

節(jié)點可分配

Kubernetes 節(jié)點上的 'Allocatable' 被定義為 pod 可用計算資源量。 調(diào)度器不會超額申請 'Allocatable'。 目前支持 'CPU'、'memory' 和 'ephemeral-storage' 這幾個參數(shù)。

可分配的節(jié)點暴露為 API 中 ?v1.Node? 對象的一部分，也是 CLI 中 ?kubectl describe node? 的一部分。

在 ?kubelet ?中，可以為兩類系統(tǒng)守護進程預留資源。

啟用 QoS 和 Pod 級別的 cgroups 

為了恰當?shù)脑诠?jié)點范圍實施節(jié)點可分配約束，你必須通過 ?--cgroups-per-qos? 標志啟用新的 cgroup 層次結(jié)構(gòu)。這個標志是默認啟用的。 啟用后，?kubelet ?將在其管理的 cgroup 層次結(jié)構(gòu)中創(chuàng)建所有終端用戶的 Pod。

配置 cgroup 驅(qū)動 

?kubelet ?支持在主機上使用 cgroup 驅(qū)動操作 cgroup 層次結(jié)構(gòu)。 驅(qū)動通過 ?--cgroup-driver? 標志配置。

支持的參數(shù)值如下：

• ?cgroupfs ?是默認的驅(qū)動，在主機上直接操作 cgroup 文件系統(tǒng)以對 cgroup 沙箱進行管理。
• ?systemd ?是可選的驅(qū)動，使用 init 系統(tǒng)支持的資源的瞬時切片管理 cgroup 沙箱。

取決于相關(guān)容器運行時的配置，操作員可能需要選擇一個特定的 cgroup 驅(qū)動 來保證系統(tǒng)正常運行。 例如，如果操作員使用 ?containerd ?運行時提供的 ?systemd ?cgroup 驅(qū)動時， 必須配置 ?kubelet ?使用 ?systemd ?cgroup 驅(qū)動。

Kube 預留值 

• Kubelet 標志: ?--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000] ?
• Kubelet 標志: ?--kube-reserved-cgroup=?

?kube-reserved? 用來給諸如 ?kubelet?、容器運行時、節(jié)點問題監(jiān)測器等 kubernetes 系統(tǒng)守護進程記述其資源預留值。 該配置并非用來給以 Pod 形式運行的系統(tǒng)守護進程保留資源。?kube-reserved? 通常是節(jié)點上 ?pod? 密度 的函數(shù)。

除了 ?cpu?，內(nèi)存 和 ?ephemeral-storage? 之外，?pid ?可用來指定為 kubernetes 系統(tǒng)守護進程預留指定數(shù)量的進程 ID。

要選擇性地對 kubernetes 系統(tǒng)守護進程上執(zhí)行 ?kube-reserved? 保護，需要把 kubelet 的 ?--kube-reserved-cgroup? 標志的值設置為 kube 守護進程的父控制組。

推薦將 kubernetes 系統(tǒng)守護進程放置于頂級控制組之下（例如 systemd 機器上的 ?runtime.slice?）。 理想情況下每個系統(tǒng)守護進程都應該在其自己的子控制組中運行。 請參考 這個設計方案， 進一步了解關(guān)于推薦控制組層次結(jié)構(gòu)的細節(jié)。

請注意，如果 ?--kube-reserved-cgroup? 不存在，Kubelet 將 不會 創(chuàng)建它。 如果指定了一個無效的 cgroup，Kubelet 將會失敗。

系統(tǒng)預留值 

• Kubelet 標志: ?--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000] ?
• Kubelet 標志: ?--system-reserved-cgroup=?

?system-reserved? 用于為諸如 ?sshd?、?udev ?等系統(tǒng)守護進程記述其資源預留值。 ?system-reserved? 也應該為 ?kernel ?預留 內(nèi)存，因為目前 ?kernel ?使用的內(nèi)存并不記在 Kubernetes 的 Pod 上。 同時還推薦為用戶登錄會話預留資源（systemd 體系中的 ?user.slice?）。

除了 ?cpu?，內(nèi)存 和 ?ephemeral-storage? 之外，?pid ?可用來指定為 kubernetes 系統(tǒng)守護進程預留指定數(shù)量的進程 ID。

要想為系統(tǒng)守護進程上可選地實施 ?system-reserved? 約束，請指定 kubelet 的 ?--system-reserved-cgroup? 標志值為 OS 系統(tǒng)守護進程的父級控制組。

推薦將 OS 系統(tǒng)守護進程放在一個頂級控制組之下（例如 systemd 機器上的 ?system.slice?）。

請注意，如果 ?--system-reserved-cgroup? 不存在，?kubelet ?不會 創(chuàng)建它。 如果指定了無效的 cgroup，?kubelet ?將會失敗。

顯式保留的 CPU 列表

FEATURE STATE: Kubernetes v1.17 [stable]

Kubelet 標志：?--reserved-cpus=0-3 ?

?reserved-cpus? 旨在為操作系統(tǒng)守護程序和 kubernetes 系統(tǒng)守護程序保留一組明確指定編號的 CPU。?reserved-cpus? 適用于不打算針對 cpuset 資源為操作系統(tǒng)守護程序和 kubernetes 系統(tǒng)守護程序定義獨立的頂級 cgroups 的系統(tǒng)。 如果 Kubelet 沒有 指定參數(shù) ?--system-reserved-cgroup? 和 ?--kube-reserved-cgroup?， 則 ?reserved-cpus? 的設置將優(yōu)先于 ?--kube-reserved? 和 ?--system-reserved? 選項。

此選項是專門為電信/NFV 用例設計的，在這些用例中不受控制的中斷或計時器可能會 影響其工作負載性能。 你可以使用此選項為系統(tǒng)或 kubernetes 守護程序以及中斷或計時器顯式定義 cpuset， 這樣系統(tǒng)上的其余 CPU 可以專門用于工作負載，因不受控制的中斷或計時器的影響得以 降低。 要將系統(tǒng)守護程序、kubernetes 守護程序和中斷或計時器移動到此選項定義的顯式 cpuset 上，應使用 Kubernetes 之外的其他機制。 例如：在 Centos 系統(tǒng)中，可以使用 tuned 工具集來執(zhí)行此操作。

驅(qū)逐閾值 

Kubelet 標志：?--eviction-hard=[memory.available<500Mi] ?

節(jié)點級別的內(nèi)存壓力將導致系統(tǒng)內(nèi)存不足，這將影響到整個節(jié)點及其上運行的所有 Pod。 節(jié)點可以暫時離線直到內(nèi)存已經(jīng)回收為止。 為了防止（或減少可能性）系統(tǒng)內(nèi)存不足，kubelet 提供了 資源不足管理。 驅(qū)逐操作只支持 ?memory ?和 ?ephemeral-storage?。 通過 ?--eviction-hard? 標志預留一些內(nèi)存后，當節(jié)點上的可用內(nèi)存降至保留值以下時， ?kubelet ?將嘗試驅(qū)逐 Pod。 如果節(jié)點上不存在系統(tǒng)守護進程，Pod 將不能使用超過 ?capacity-eviction-hard? 所 指定的資源量。因此，為驅(qū)逐而預留的資源對 Pod 是不可用的。

實施節(jié)點可分配約束 

Kubelet 標志：?--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved] ?

調(diào)度器將 'Allocatable' 視為 Pod 可用的 ?capacity?（資源容量）。

?kubelet ?默認對 Pod 執(zhí)行 'Allocatable' 約束。 無論何時，如果所有 Pod 的總用量超過了 'Allocatable'，驅(qū)逐 Pod 的措施將被執(zhí)行。 有關(guān)驅(qū)逐策略的更多細節(jié)可以在 節(jié)點壓力驅(qū)逐頁找到。 可通過設置 kubelet ?--enforce-node-allocatable? 標志值為 ?pods ?控制這個措施。

可選地，通過在同一標志中同時指定 ?kube-reserved? 和 ?system-reserved? 值， 可以使 ?kubelet ?強制實施 ?kube-reserved? 和 ?system-reserved? 約束。 請注意，要想執(zhí)行 ?kube-reserved? 或者 ?system-reserved? 約束， 需要對應設置 ?--kube-reserved-cgroup? 或者 ?--system-reserved-cgroup?。

一般原則 

系統(tǒng)守護進程一般會被按照類似 Guaranteed pods 一樣對待。 系統(tǒng)守護進程可以在與其對應的控制組中出現(xiàn)突發(fā)資源用量，這一行為要作為 kubernetes 部署的一部分進行管理。 例如，?kubelet ?應該有它自己的控制組并和容器運行時共享 ?kube-reserved? 資源。 不過，如果執(zhí)行了 ?kube-reserved? 約束，則 kubelet 不可出現(xiàn)突發(fā)負載并用光 節(jié)點的所有可用資源。

在執(zhí)行 ?system-reserved? 預留策略時請加倍小心，因為它可能導致節(jié)點上的 關(guān)鍵系統(tǒng)服務出現(xiàn) CPU 資源短缺、因為內(nèi)存不足而被終止或者無法在節(jié)點上創(chuàng)建進程。 建議只有當用戶詳盡地描述了他們的節(jié)點以得出精確的估計值， 并且對該組中進程因內(nèi)存不足而被殺死時，有足夠的信心將其恢復時， 才可以強制執(zhí)行 ?system-reserved? 策略。

• 作為起步，可以先針對 ?pods ?上執(zhí)行 'Allocatable' 約束。
• 一旦用于追蹤系統(tǒng)守護進程的監(jiān)控和告警的機制到位，可嘗試基于用量估計的 方式執(zhí)行 ?kube-reserved? 策略。
• 隨著時間推進，在絕對必要的時候可以執(zhí)行 ?system-reserved? 策略。

隨著時間推進和越來越多特性被加入，kube 系統(tǒng)守護進程對資源的需求可能也會增加。 以后 kubernetes 項目將嘗試減少對節(jié)點系統(tǒng)守護進程的利用，但目前這件事的優(yōu)先級 并不是最高。 所以，將來的發(fā)布版本中 ?Allocatable ?容量是有可能降低的。

示例場景 

這是一個用于說明節(jié)點可分配（Node Allocatable）計算方式的示例：

• 節(jié)點擁有 32Gi memeory，16 CPU 和 100Gi Storage 資源
• ?--kube-reserved? 被設置為 cpu=1,memory=2Gi,ephemeral-storage=1Gi
• ?--system-reserved? 被設置為 cpu=500m,memory=1Gi,ephemeral-storage=1Gi
• ?--eviction-hard? 被設置為 memory.available<500Mi,nodefs.available<10%

在這個場景下，'Allocatable' 將會是 14.5 CPUs、28.5Gi 內(nèi)存以及 88Gi 本地存儲。 調(diào)度器保證這個節(jié)點上的所有 Pod 的內(nèi)存 ?requests ?總量不超過 28.5Gi， 存儲不超過 '88Gi'。 當 Pod 的內(nèi)存使用總量超過 28.5Gi 或者磁盤使用總量超過 88Gi 時， kubelet 將會驅(qū)逐它們。 如果節(jié)點上的所有進程都盡可能多地使用 CPU，則 Pod 加起來不能使用超過 14.5 CPUs 的資源。

當沒有執(zhí)行 ?kube-reserved? 或 ?system-reserved? 策略且系統(tǒng)守護進程 使用量超過其預留時，如果節(jié)點內(nèi)存用量高于 31.5Gi 或 ?storage ?大于 90Gi， kubelet 將會驅(qū)逐 Pod。