Kubernetes 節(jié)點(diǎn)

節(jié)點(diǎn)

Kubernetes 通過將容器放入在節(jié)點(diǎn)（Node）上運(yùn)行的 Pod 中來執(zhí)行你的工作負(fù)載。 節(jié)點(diǎn)可以是一個虛擬機(jī)或者物理機(jī)器，取決于所在的集群配置。 每個節(jié)點(diǎn)包含運(yùn)行 Pods 所需的服務(wù)； 這些節(jié)點(diǎn)由 控制面 負(fù)責(zé)管理。

通常集群中會有若干個節(jié)點(diǎn)；而在一個學(xué)習(xí)用或者資源受限的環(huán)境中，你的集群中也可能 只有一個節(jié)點(diǎn)。

節(jié)點(diǎn)上的組件包括 kubelet、 容器運(yùn)行時以及 kube-proxy。

管理 

向 API 服務(wù)器添加節(jié)點(diǎn)的方式主要有兩種：

1. 節(jié)點(diǎn)上的 ?kubelet ?向控制面執(zhí)行自注冊；
2. 你，或者別的什么人，手動添加一個 Node 對象。

在你創(chuàng)建了 Node 對象或者節(jié)點(diǎn)上的 ?kubelet ?執(zhí)行了自注冊操作之后，控制面會檢查新的 Node 對象是否合法。 例如，如果你嘗試使用下面的 JSON 對象來創(chuàng)建 Node 對象：

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes 會在內(nèi)部創(chuàng)建一個 Node 對象作為節(jié)點(diǎn)的表示。Kubernetes 檢查 ?kubelet ?向 API 服務(wù)器注冊節(jié)點(diǎn)時使用的 ?metadata.name? 字段是否匹配。 如果節(jié)點(diǎn)是健康的（即所有必要的服務(wù)都在運(yùn)行中），則該節(jié)點(diǎn)可以用來運(yùn)行 Pod。 否則，直到該節(jié)點(diǎn)變?yōu)榻】抵埃械募夯顒佣紩雎栽摴?jié)點(diǎn)。

Kubernetes 會一直保存著非法節(jié)點(diǎn)對應(yīng)的對象，并持續(xù)檢查該節(jié)點(diǎn)是否已經(jīng)變得健康。 你，或者某個控制器必須顯式地刪除該 Node 對象以停止健康檢查操作。

Node 對象的名稱必須是合法的 DNS 子域名。

節(jié)點(diǎn)名稱唯一性 

節(jié)點(diǎn)的名稱用來標(biāo)識 Node 對象。 沒有兩個 Node 可以同時使用相同的名稱。 Kubernetes 還假定名字相同的資源是同一個對象。 就 Node 而言，隱式假定使用相同名稱的實(shí)例會具有相同的狀態(tài)（例如網(wǎng)絡(luò)配置、根磁盤內(nèi)容） 和類似節(jié)點(diǎn)標(biāo)簽這類屬性。這可能在節(jié)點(diǎn)被更改但其名稱未變時導(dǎo)致系統(tǒng)狀態(tài)不一致。 如果某個 Node 需要被替換或者大量變更，需要從 API 服務(wù)器移除現(xiàn)有的 Node 對象， 之后再在更新之后重新將其加入。

節(jié)點(diǎn)自注冊

當(dāng) kubelet 標(biāo)志 ?--register-node? 為 true（默認(rèn)）時，它會嘗試向 API 服務(wù)注冊自己。 這是首選模式，被絕大多數(shù)發(fā)行版選用。

對于自注冊模式，kubelet 使用下列參數(shù)啟動：

• ?--kubeconfig? - 用于向 API 服務(wù)器執(zhí)行身份認(rèn)證所用的憑據(jù)的路徑。
• ?--cloud-provider? - 與某云驅(qū)動 進(jìn)行通信以讀取與自身相關(guān)的元數(shù)據(jù)的方式。
• ?--register-node? - 自動向 API 服務(wù)注冊。
• ?--register-with-taints? - 使用所給的污點(diǎn)列表 （逗號分隔的 ?<key>=<value>:<effect>?）注冊節(jié)點(diǎn)。當(dāng) ?register-node? 為 false 時無效。
• ?--node-ip? - 節(jié)點(diǎn) IP 地址。
• ?--node-labels? - 在集群中注冊節(jié)點(diǎn)時要添加的標(biāo)簽。
• ?--node-status-update-frequency? - 指定 kubelet 向控制面發(fā)送狀態(tài)的頻率。

啟用Node 鑒權(quán)模式和 NodeRestriction 準(zhǔn)入插件時， 僅授權(quán) ?kubelet ?創(chuàng)建或修改其自己的節(jié)點(diǎn)資源。

正如節(jié)點(diǎn)名稱唯一性一節(jié)所述，當(dāng) Node 的配置需要被更新時， 一種好的做法是重新向 API 服務(wù)器注冊該節(jié)點(diǎn)。例如，如果 kubelet 重啟時其 ?--node-labels? 是新的值集，但同一個 Node 名稱已經(jīng)被使用，則所作變更不會起作用， 因?yàn)楣?jié)點(diǎn)標(biāo)簽是在 Node 注冊時完成的。

如果在 kubelet 重啟期間 Node 配置發(fā)生了變化，已經(jīng)被調(diào)度到某 Node 上的 Pod 可能會出現(xiàn)行為不正常或者出現(xiàn)其他問題，例如，已經(jīng)運(yùn)行的 Pod 可能通過污點(diǎn)機(jī)制設(shè)置了與 Node 上新設(shè)置的標(biāo)簽相排斥的規(guī)則，也有一些其他 Pod， 本來與此 Pod 之間存在不兼容的問題，也會因?yàn)樾碌臉?biāo)簽設(shè)置而被調(diào)到到同一節(jié)點(diǎn)。 節(jié)點(diǎn)重新注冊操作可以確保節(jié)點(diǎn)上所有 Pod 都被排空并被正確地重新調(diào)度。

手動節(jié)點(diǎn)管理 

你可以使用 kubectl 來創(chuàng)建和修改 Node 對象。

如果你希望手動創(chuàng)建節(jié)點(diǎn)對象時，請?jiān)O(shè)置 kubelet 標(biāo)志 ?--register-node=false?。

你可以修改 Node 對象（忽略 ?--register-node? 設(shè)置）。 例如，修改節(jié)點(diǎn)上的標(biāo)簽或標(biāo)記其為不可調(diào)度。

你可以結(jié)合使用 Node 上的標(biāo)簽和 Pod 上的選擇算符來控制調(diào)度。 例如，你可以限制某 Pod 只能在符合要求的節(jié)點(diǎn)子集上運(yùn)行。

如果標(biāo)記節(jié)點(diǎn)為不可調(diào)度（unschedulable），將阻止新 Pod 調(diào)度到該 Node 之上， 但不會影響任何已經(jīng)在其上的 Pod。 這是重啟節(jié)點(diǎn)或者執(zhí)行其他維護(hù)操作之前的一個有用的準(zhǔn)備步驟。

要標(biāo)記一個 Node 為不可調(diào)度，執(zhí)行以下命令：

kubectl cordon $NODENAME

被 DaemonSet 控制器創(chuàng)建的 Pod 能夠容忍節(jié)點(diǎn)的不可調(diào)度屬性。 DaemonSet 通常提供節(jié)點(diǎn)本地的服務(wù)，即使節(jié)點(diǎn)上的負(fù)載應(yīng)用已經(jīng)被騰空， 這些服務(wù)也仍需運(yùn)行在節(jié)點(diǎn)之上。

節(jié)點(diǎn)狀態(tài) 

一個節(jié)點(diǎn)的狀態(tài)包含以下信息:

• 地址（Addresses）
• 狀況（Condition）
• 容量與可分配（Capacity）
• 信息（Info）

你可以使用 ?kubectl ?來查看節(jié)點(diǎn)狀態(tài)和其他細(xì)節(jié)信息：

kubectl describe node <節(jié)點(diǎn)名稱>

下面對每個部分進(jìn)行詳細(xì)描述。

地址 

這些字段的用法取決于你的云服務(wù)商或者物理機(jī)配置。

• HostName：由節(jié)點(diǎn)的內(nèi)核報告。可以通過 kubelet 的 ?--hostname-override? 參數(shù)覆蓋。
• ExternalIP：通常是節(jié)點(diǎn)的可外部路由（從集群外可訪問）的 IP 地址。
• InternalIP：通常是節(jié)點(diǎn)的僅可在集群內(nèi)部路由的 IP 地址。

狀況

?conditions ?字段描述了所有 ?Running ?節(jié)點(diǎn)的狀況。狀況的示例包括：

如果使用命令行工具來打印已保護(hù)（Cordoned）節(jié)點(diǎn)的細(xì)節(jié)，其中的 Condition 字段可能包括 ?SchedulingDisabled?。?SchedulingDisabled ?不是 Kubernetes API 中定義的 Condition，被保護(hù)起來的節(jié)點(diǎn)在其規(guī)約中被標(biāo)記為不可調(diào)度（Unschedulable）。

在 Kubernetes API 中，節(jié)點(diǎn)的狀況表示節(jié)點(diǎn)資源中?.status? 的一部分。 例如，以下 JSON 結(jié)構(gòu)描述了一個健康節(jié)點(diǎn)：

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

如果 Ready 狀況的 ?status ?處于 ?Unknown ?或者 ?False ?狀態(tài)的時間超過了 ?pod-eviction-timeout? 值（一個傳遞給 kube-controller-manager 的參數(shù)），節(jié)點(diǎn)控制器會對節(jié)點(diǎn)上的所有 Pod 觸發(fā) API-發(fā)起的驅(qū)逐。 默認(rèn)的逐出超時時長為 5 分鐘。

某些情況下，當(dāng)節(jié)點(diǎn)不可達(dá)時，API 服務(wù)器不能和其上的 kubelet 通信。 刪除 Pod 的決定不能傳達(dá)給 kubelet，直到它重新建立和 API 服務(wù)器的連接為止。 與此同時，被計(jì)劃刪除的 Pod 可能會繼續(xù)在游離的節(jié)點(diǎn)上運(yùn)行。

節(jié)點(diǎn)控制器在確認(rèn) Pod 在集群中已經(jīng)停止運(yùn)行前，不會強(qiáng)制刪除它們。 你可以看到可能在這些無法訪問的節(jié)點(diǎn)上運(yùn)行的 Pod 處于 ?Terminating ?或者 ?Unknown ?狀態(tài)。 如果 kubernetes 不能基于下層基礎(chǔ)設(shè)施推斷出某節(jié)點(diǎn)是否已經(jīng)永久離開了集群， 集群管理員可能需要手動刪除該節(jié)點(diǎn)對象。 從 Kubernetes 刪除節(jié)點(diǎn)對象將導(dǎo)致 API 服務(wù)器刪除節(jié)點(diǎn)上所有運(yùn)行的 Pod 對象并釋放它們的名字。

當(dāng)節(jié)點(diǎn)上出現(xiàn)問題時，Kubernetes 控制面會自動創(chuàng)建與影響節(jié)點(diǎn)的狀況對應(yīng)的 污點(diǎn)。 調(diào)度器在將 Pod 指派到某 Node 時會考慮 Node 上的污點(diǎn)設(shè)置。 Pod 也可以設(shè)置容忍度， 以便能夠在設(shè)置了特定污點(diǎn)的 Node 上運(yùn)行。

容量（Capacity）與可分配（Allocatable） 

這兩個值描述節(jié)點(diǎn)上的可用資源：CPU、內(nèi)存和可以調(diào)度到節(jié)點(diǎn)上的 Pod 的個數(shù)上限。

?capacity ?塊中的字段標(biāo)示節(jié)點(diǎn)擁有的資源總量。 ?allocatable ?塊指示節(jié)點(diǎn)上可供普通 Pod 消耗的資源量。

信息（Info）

Info 指的是節(jié)點(diǎn)的一般信息，如內(nèi)核版本、Kubernetes 版本（?kubelet ?和 ?kube-proxy? 版本）、 容器運(yùn)行時詳細(xì)信息，以及節(jié)點(diǎn)使用的操作系統(tǒng)。 ?kubelet ?從節(jié)點(diǎn)收集這些信息并將其發(fā)布到 Kubernetes API。

心跳 

Kubernetes 節(jié)點(diǎn)發(fā)送的心跳幫助你的集群確定每個節(jié)點(diǎn)的可用性，并在檢測到故障時采取行動。

對于節(jié)點(diǎn)，有兩種形式的心跳:

• 更新節(jié)點(diǎn)的 ?.status ?
• ?kube-node-lease? 名字空間中的 Lease（租約）對象。 每個節(jié)點(diǎn)都有一個關(guān)聯(lián)的 Lease 對象。

與 Node 的 ?.status? 更新相比，Lease 是一種輕量級資源。 使用 Lease 來表達(dá)心跳在大型集群中可以減少這些更新對性能的影響。

kubelet 負(fù)責(zé)創(chuàng)建和更新節(jié)點(diǎn)的 ?.status?，以及更新它們對應(yīng)的 Lease。

• 當(dāng)節(jié)點(diǎn)狀態(tài)發(fā)生變化時，或者在配置的時間間隔內(nèi)沒有更新事件時，kubelet 會更新 ?.status?。 ?.status? 更新的默認(rèn)間隔為 5 分鐘（比節(jié)點(diǎn)不可達(dá)事件的 40 秒默認(rèn)超時時間長很多）。
• ?kubelet ?會創(chuàng)建并每 10 秒（默認(rèn)更新間隔時間）更新 Lease 對象。 Lease 的更新獨(dú)立于 Node 的 ?.status? 更新而發(fā)生。 如果 Lease 的更新操作失敗，kubelet 會采用指數(shù)回退機(jī)制，從 200 毫秒開始重試， 最長重試間隔為 7 秒鐘。

節(jié)點(diǎn)控制器 

節(jié)點(diǎn)控制器是 Kubernetes 控制面組件， 管理節(jié)點(diǎn)的方方面面。

節(jié)點(diǎn)控制器在節(jié)點(diǎn)的生命周期中扮演多個角色。 第一個是當(dāng)節(jié)點(diǎn)注冊時為它分配一個 CIDR 區(qū)段（如果啟用了 CIDR 分配）。

第二個是保持節(jié)點(diǎn)控制器內(nèi)的節(jié)點(diǎn)列表與云服務(wù)商所提供的可用機(jī)器列表同步。 如果在云環(huán)境下運(yùn)行，只要某節(jié)點(diǎn)不健康，節(jié)點(diǎn)控制器就會詢問云服務(wù)是否節(jié)點(diǎn)的虛擬機(jī)仍可用。 如果不可用，節(jié)點(diǎn)控制器會將該節(jié)點(diǎn)從它的節(jié)點(diǎn)列表刪除。

第三個是監(jiān)控節(jié)點(diǎn)的健康狀況。節(jié)點(diǎn)控制器負(fù)責(zé)：

• 在節(jié)點(diǎn)不可達(dá)的情況下，在 Node 的 ?.status? 中更新 ?Ready ?狀況。 在這種情況下，節(jié)點(diǎn)控制器將 NodeReady 狀況更新為 ?Unknown ?。
• 如果節(jié)點(diǎn)仍然無法訪問：對于不可達(dá)節(jié)點(diǎn)上的所有 Pod 觸發(fā) API 發(fā)起的逐出操作。 默認(rèn)情況下，節(jié)點(diǎn)控制器在將節(jié)點(diǎn)標(biāo)記為 ?Unknown ?后等待 5 分鐘提交第一個驅(qū)逐請求。

默認(rèn)情況下，節(jié)點(diǎn)控制器每 5 秒檢查一次節(jié)點(diǎn)狀態(tài)，可以使用 ?kube-controller-manager? 組件上的 ?--node-monitor-period? 參數(shù)來配置周期。

逐出速率限制 

大部分情況下，節(jié)點(diǎn)控制器把逐出速率限制在每秒 ?--node-eviction-rate? 個（默認(rèn)為 0.1）。 這表示它每 10 秒鐘內(nèi)至多從一個節(jié)點(diǎn)驅(qū)逐 Pod。

當(dāng)一個可用區(qū)域（Availability Zone）中的節(jié)點(diǎn)變?yōu)椴唤】禃r，節(jié)點(diǎn)的驅(qū)逐行為將發(fā)生改變。 節(jié)點(diǎn)控制器會同時檢查可用區(qū)域中不健康（?Ready ?狀況為 ?Unknown ?或 ?False?） 的節(jié)點(diǎn)的百分比：

• 如果不健康節(jié)點(diǎn)的比例超過 ?--unhealthy-zone-threshold? （默認(rèn)為 0.55）， 驅(qū)逐速率將會降低。
• 如果集群較小（意即小于等于 ?--large-cluster-size-threshold? 個節(jié)點(diǎn) - 默認(rèn)為 50）， 驅(qū)逐操作將會停止。
• 否則驅(qū)逐速率將降為每秒 ?--secondary-node-eviction-rate? 個（默認(rèn)為 0.01）。

在逐個可用區(qū)域中實(shí)施這些策略的原因是， 當(dāng)一個可用區(qū)域可能從控制面脫離時其它可用區(qū)域可能仍然保持連接。 如果你的集群沒有跨越云服務(wù)商的多個可用區(qū)域，那（整個集群）就只有一個可用區(qū)域。

跨多個可用區(qū)域部署你的節(jié)點(diǎn)的一個關(guān)鍵原因是當(dāng)某個可用區(qū)域整體出現(xiàn)故障時， 工作負(fù)載可以轉(zhuǎn)移到健康的可用區(qū)域。 因此，如果一個可用區(qū)域中的所有節(jié)點(diǎn)都不健康時，節(jié)點(diǎn)控制器會以正常的速率 ?--node-eviction-rate? 進(jìn)行驅(qū)逐操作。 在所有的可用區(qū)域都不健康（也即集群中沒有健康節(jié)點(diǎn)）的極端情況下， 節(jié)點(diǎn)控制器將假設(shè)控制面與節(jié)點(diǎn)間的連接出了某些問題，它將停止所有驅(qū)逐動作 （如果故障后部分節(jié)點(diǎn)重新連接，節(jié)點(diǎn)控制器會從剩下不健康或者不可達(dá)節(jié)點(diǎn)中驅(qū)逐 Pod）。

節(jié)點(diǎn)控制器還負(fù)責(zé)驅(qū)逐運(yùn)行在擁有 ?NoExecute ?污點(diǎn)的節(jié)點(diǎn)上的 Pod， 除非這些 Pod 能夠容忍此污點(diǎn)。 節(jié)點(diǎn)控制器還負(fù)責(zé)根據(jù)節(jié)點(diǎn)故障（例如節(jié)點(diǎn)不可訪問或沒有就緒） 為其添加污點(diǎn)。 這意味著調(diào)度器不會將 Pod 調(diào)度到不健康的節(jié)點(diǎn)上。

資源容量跟蹤 

Node 對象會跟蹤節(jié)點(diǎn)上資源的容量（例如可用內(nèi)存和 CPU 數(shù)量）。 通過自注冊機(jī)制生成的 Node 對象會在注冊期間報告自身容量。 如果你手動添加了 Node， 你就需要在添加節(jié)點(diǎn)時手動設(shè)置節(jié)點(diǎn)容量。

Kubernetes 調(diào)度器 保證節(jié)點(diǎn)上有足夠的資源供其上的所有 Pod 使用。 它會檢查節(jié)點(diǎn)上所有容器的請求的總和不會超過節(jié)點(diǎn)的容量。 總的請求包括由 kubelet 啟動的所有容器，但不包括由容器運(yùn)行時直接啟動的容器， 也不包括不受 ?kubelet ?控制的其他進(jìn)程。

節(jié)點(diǎn)拓?fù)?nbsp;

FEATURE STATE: Kubernetes v1.18 [beta]

如果啟用了 ?TopologyManager ?特性門控， ?kubelet ?可以在作出資源分配決策時使用拓?fù)涮崾尽?/p>

節(jié)點(diǎn)體面關(guān)閉

FEATURE STATE: Kubernetes v1.21 [beta]

kubelet 會嘗試檢測節(jié)點(diǎn)系統(tǒng)關(guān)閉事件并終止在節(jié)點(diǎn)上運(yùn)行的 Pods。

在節(jié)點(diǎn)終止期間，kubelet 保證 Pod 遵從常規(guī)的 Pod 終止流程。

體面節(jié)點(diǎn)關(guān)閉特性依賴于 systemd，因?yàn)樗?nbsp;systemd 抑制器鎖機(jī)制， 在給定的期限內(nèi)延遲節(jié)點(diǎn)關(guān)閉。

體面節(jié)點(diǎn)關(guān)閉特性受 ?GracefulNodeShutdown ?特性門控控制， 在 1.21 版本中是默認(rèn)啟用的。

注意，默認(rèn)情況下，下面描述的兩個配置選項(xiàng)，shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 都是被設(shè)置為 0 的，因此不會激活體面節(jié)點(diǎn)關(guān)閉功能。 要激活此功能特性，這兩個 kubelet 配置選項(xiàng)要適當(dāng)配置，并設(shè)置為非零值。

在體面關(guān)閉節(jié)點(diǎn)過程中，kubelet 分兩個階段來終止 Pod：

1. 終止在節(jié)點(diǎn)上運(yùn)行的常規(guī) Pod。
2. 終止在節(jié)點(diǎn)上運(yùn)行的關(guān)鍵 Pod。

節(jié)點(diǎn)體面關(guān)閉的特性對應(yīng)兩個 ?KubeletConfiguration ?選項(xiàng)：

• ?shutdownGracePeriod?：
• 指定節(jié)點(diǎn)應(yīng)延遲關(guān)閉的總持續(xù)時間。此時間是 Pod 體面終止的時間總和，不區(qū)分常規(guī) Pod 還是關(guān)鍵 Pod。
• ?shutdownGracePeriodCriticalPods?：
• 在節(jié)點(diǎn)關(guān)閉期間指定用于終止關(guān)鍵 Pod 的持續(xù)時間。該值應(yīng)小于 ?shutdownGracePeriod?。

例如，如果設(shè)置了 ?shutdownGracePeriod=30s? 和 ?shutdownGracePeriodCriticalPods=10s?， 則 kubelet 將延遲 30 秒關(guān)閉節(jié)點(diǎn)。 在關(guān)閉期間，將保留前 20（30 - 10）秒用于體面終止常規(guī) Pod， 而保留最后 10 秒用于終止關(guān)鍵 Pod。

當(dāng) Pod 在正常節(jié)點(diǎn)關(guān)閉期間被驅(qū)逐時，它們會被標(biāo)記為已經(jīng)失敗（Failed）。 運(yùn)行 ?kubectl get pods? 時，被驅(qū)逐的 Pod 的狀態(tài)顯示為 ?Shutdown?。 并且 ?kubectl describe pod? 表示 Pod 因節(jié)點(diǎn)關(guān)閉而被驅(qū)逐：

Reason:         Terminated
Message:        Pod was terminated in response to imminent node shutdown.

        

基于 Pod 優(yōu)先級的體面節(jié)點(diǎn)關(guān)閉 

FEATURE STATE: Kubernetes v1.23 [alpha]

為了在體面節(jié)點(diǎn)關(guān)閉期間提供更多的靈活性，尤其是處理關(guān)閉期間的 Pod 排序問題， 體面節(jié)點(diǎn)關(guān)閉機(jī)制能夠關(guān)注 Pod 的 PriorityClass 設(shè)置，前提是你已經(jīng)在集群中啟用了此功能特性。 此功能特性允許集群管理員基于 Pod 的優(yōu)先級類（Priority Class） 顯式地定義體面節(jié)點(diǎn)關(guān)閉期間 Pod 的處理順序。

前文所述的體面節(jié)點(diǎn)關(guān)閉特性能夠分兩個階段關(guān)閉 Pod， 首先關(guān)閉的是非關(guān)鍵的 Pod，之后再處理關(guān)鍵 Pod。 如果需要顯式地以更細(xì)粒度定義關(guān)閉期間 Pod 的處理順序，需要一定的靈活度， 這時可以使用基于 Pod 優(yōu)先級的體面關(guān)閉機(jī)制。

當(dāng)體面節(jié)點(diǎn)關(guān)閉能夠處理 Pod 優(yōu)先級時，體面節(jié)點(diǎn)關(guān)閉的處理可以分為多個階段， 每個階段關(guān)閉特定優(yōu)先級類的 Pod。kubelet 可以被配置為按確切的階段處理 Pod， 且每個階段可以獨(dú)立設(shè)置關(guān)閉時間。

假設(shè)集群中存在以下自定義的 Pod 優(yōu)先級類。

在 kubelet 配置中， ?shutdownGracePeriodByPodPriority ?可能看起來是這樣：

對應(yīng)的 kubelet 配置 YAML 將會是：

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60

上面的表格表明，所有 ?priority ?值大于等于 100000 的 Pod 會得到 10 秒鐘期限停止， 所有 ?priority ?值介于 10000 和 100000 之間的 Pod 會得到 180 秒鐘期限停止， 所有 ?priority ?值介于 1000 和 10000 之間的 Pod 會得到 120 秒鐘期限停止， 所有其他 Pod 將獲得 60 秒的時間停止。

用戶不需要為所有的優(yōu)先級類都設(shè)置數(shù)值。例如，你也可以使用下面這種配置：

在上面這個場景中，優(yōu)先級類為 ?custom-class-b? 的 Pod 會與優(yōu)先級類為 ?custom-class-c? 的 Pod 在關(guān)閉時按相同期限處理。

如果在特定的范圍內(nèi)不存在 Pod，則 kubelet 不會等待對應(yīng)優(yōu)先級范圍的 Pod。 kubelet 會直接跳到下一個優(yōu)先級數(shù)值范圍進(jìn)行處理。

如果此功能特性被啟用，但沒有提供配置數(shù)據(jù)，則不會出現(xiàn)排序操作。

使用此功能特性需要啟用 ?GracefulNodeShutdownBasedOnPodPriority ?特性門控， 并將 kubelet 配置中的 ?shutdownGracePeriodByPodPriority ?設(shè)置為期望的配置， 其中包含 Pod 的優(yōu)先級類數(shù)值以及對應(yīng)的關(guān)閉期限。

kubelet 子系統(tǒng)中會生成 ?graceful_shutdown_start_time_seconds ?和 ?graceful_shutdown_end_time_seconds ?度量指標(biāo)以便監(jiān)視節(jié)點(diǎn)關(guān)閉行為。

交換內(nèi)存管理

FEATURE STATE: Kubernetes v1.22 [alpha]

在 Kubernetes 1.22 之前，節(jié)點(diǎn)不支持使用交換內(nèi)存，并且默認(rèn)情況下， 如果在節(jié)點(diǎn)上檢測到交換內(nèi)存配置，kubelet 將無法啟動。 在 1.22 以后，可以逐個節(jié)點(diǎn)地啟用交換內(nèi)存支持。

要在節(jié)點(diǎn)上啟用交換內(nèi)存，必須啟用kubelet 的 ?NodeSwap ?特性門控， 同時使用 ?--fail-swap-on? 命令行參數(shù)或者將 ?failSwapOn ?配置設(shè)置為 false。

用戶還可以選擇配置 ?memorySwap.swapBehavior? 以指定節(jié)點(diǎn)使用交換內(nèi)存的方式。例如:

memorySwap:
  swapBehavior: LimitedSwap

可用的 ?swapBehavior ?的配置選項(xiàng)有：

• ?LimitedSwap?：Kubernetes 工作負(fù)載的交換內(nèi)存會受限制。 不受 Kubernetes 管理的節(jié)點(diǎn)上的工作負(fù)載仍然可以交換。
• ?UnlimitedSwap?：Kubernetes 工作負(fù)載可以使用盡可能多的交換內(nèi)存請求， 一直到達(dá)到系統(tǒng)限制為止。

如果啟用了特性門控但是未指定 ?memorySwap ?的配置，默認(rèn)情況下 kubelet 將使用 ?LimitedSwap ?設(shè)置。

?LimitedSwap ?這種設(shè)置的行為取決于節(jié)點(diǎn)運(yùn)行的是 v1 還是 v2 的控制組（也就是 ?cgroups?）：

• cgroupsv1: Kubernetes 工作負(fù)載可以使用內(nèi)存和交換，上限為 Pod 的內(nèi)存限制值（如果設(shè)置了的話）。
• cgroupsv2: Kubernetes 工作負(fù)載不能使用交換內(nèi)存。