本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes v1.28：Planternetes

作者：Kubernetes v1.28 發布團隊 |

宣布 Kubernetes v1.28 Planternetes 版本發布，這是 2023 年的第二個版本！

此版本包含 45 項增強功能。在這些增強功能中，有 19 項進入 Alpha 階段，14 項已升級至 Beta 階段，12 項已升級至 Stable 階段。

Kubernetes v1.28：Planternetes

Kubernetes v1.28 的主題是 Planternetes。

每個 Kubernetes 版本都是我們社群中數千名個人辛勤工作的結晶。此版本背後的人們來自各行各業，我們有些人是業界資深人士、家長，有些人是學生和開源新手。我們結合獨特的經驗，創造具有全球影響力的集體成果。

就像花園一樣，我們的發布版本不斷變化成長、面臨挑戰和機會。這個主題讚揚了為使發布版本達到今天的狀態所付出的細心呵護、意圖和努力。和諧共處，我們才能成長得更好。

新功能（主要主題）

控制平面和節點版本之間支援的偏差變更

Kubernetes v1.28 將核心節點和控制平面元件之間支援的偏差擴大了一個次要版本，從 n-2 擴大到 n-3，因此最舊支援的次要版本的節點元件（kubelet 和 kube-proxy）可以與最新支援的次要版本的控制平面元件（kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）搭配運作。

有些叢集運營商避免節點維護，尤其是節點行為的變更，因為節點是工作負載運行的位置。對於 kubelet 的次要版本升級，支援的流程包括排空該節點，因此會中斷任何原先在那裡執行的 Pod。對於具有長時間運行工作負載且 Pod 應盡可能保持運行的 Kubernetes 終端使用者來說，減少節點維護所花費的時間是一項優勢。

Kubernetes 的年度支援週期已經讓年度升級成為可能。使用者可以升級到最新的修補程式版本以取得安全性修正，並每年進行 3 次連續的次要版本升級，以「趕上」最新的支援次要版本。

先前，為了保持在支援的偏差範圍內，計畫年度升級的叢集運營商將需要升級其節點兩次（可能僅間隔數小時）。現在，有了 Kubernetes v1.28，您可以選擇在每個日曆年僅對節點進行一次次要版本升級，並且仍然保持在上游支援範圍內。

如果您想要保持最新狀態並更頻繁地升級叢集，這也很好，並且仍然完全受到支援。

正式發布：從非正常節點關機中復原

如果節點意外關機或最終處於無法復原的狀態（可能是由於硬體故障或 OS 無回應），Kubernetes 允許您在事後清理並允許有狀態工作負載在不同的節點上重新啟動。對於 Kubernetes v1.28，這現在是一項穩定功能。

這允許有狀態工作負載在原始節點關機或處於無法復原的狀態（例如硬體故障或 OS 損壞）後，成功容錯移轉到不同的節點。

Kubernetes v1.20 之前的版本缺乏對 Linux 上節點關機的處理，kubelet 與 systemd 整合並實作正常節點關機（beta 版，預設啟用）。但是，即使是故意的關機也可能無法妥善處理，原因可能是

  • 節點執行 Windows
  • 節點執行 Linux，但使用不同的 init（不是 systemd）
  • 關機未觸發系統抑制鎖定機制
  • 由於節點層級組態錯誤（例如未為 shutdownGracePeriod 和 shutdownGracePeriodCriticalPods 設定適當的值）。

當節點關機或故障，且 kubelet 未偵測到該關機時，屬於 StatefulSet 的 Pod 將會卡在關機節點上的終止狀態。如果停止的節點重新啟動，則該節點上的 kubelet 可以清理（DELETE）Kubernetes API 仍然視為繫結到該節點的 Pod。但是，如果節點保持停止狀態 - 或者如果 kubelet 在重新啟動後無法啟動 - 則 Kubernetes 可能無法建立替換 Pod。當關機節點上的 kubelet 無法刪除舊的 Pod 時，相關聯的 StatefulSet 無法建立新的 Pod（其名稱會相同）。

儲存也存在問題。如果 Pod 使用了磁碟區，則現有的 VolumeAttachment 將不會與原始節點（現在已關機）取消關聯，因此這些 Pod 使用的 PersistentVolume 無法連接到不同的健康節點。因此，在受影響的 StatefulSet 上運行的應用程式可能無法正常運作。如果原始的關機節點啟動，則其 Pod 將被其 kubelet 刪除，並且可以在不同的運行節點上建立新的 Pod。如果原始節點未啟動（在 不可變基礎架構 設計中很常見），則這些 Pod 將永遠卡在關機節點上的 Terminating 狀態。

有關如何在非正常節點關機後觸發清理的更多資訊，請參閱非正常節點關機。

CustomResourceDefinition 驗證規則的改進

通用表達式語言 (CEL) 可用於驗證自訂資源。主要目標是允許大多數驗證用例，這些用例可能曾經需要您（作為 CustomResourceDefinition (CRD) 作者）設計和實作 Webhook。相反地，作為 Beta 功能，您可以將驗證表達式直接新增到 CRD 的結構描述中。

CRD 需要對非簡單驗證的直接支援。雖然准入 Webhook 確實支援 CRD 驗證，但它們顯著地使 CRD 的開發和可操作性複雜化。

在 1.28 中，新增了兩個可選欄位 reason 和 fieldPath，以允許使用者在驗證失敗時指定失敗原因和 fieldPath。

有關更多資訊，請參閱 CRD 文件中的驗證規則。

ValidatingAdmissionPolicies 升級至 Beta 階段

通用表達式語言用於准入控制，是對 Kubernetes API 伺服器的請求進行可自訂的、進程內驗證，作為驗證准入 Webhook 的替代方案。

這建立在 1.25 中升級至 Beta 階段的 CRD 驗證規則功能的基礎上，但重點是驗證准入控制的策略強制執行功能。

這將降低強制執行可自訂策略的基礎架構障礙，並提供有助於社群建立和遵守 K8s 及其擴充功能的最佳實務的基礎元素。

若要使用 ValidatingAdmissionPolicies，您需要同時啟用 admissionregistration.k8s.io/v1beta1 API 群組和叢集控制平面中的 ValidatingAdmissionPolicy 功能閘道。

准入 Webhook 的比對條件

Kubernetes v1.27 允許您為准入 Webhook 指定比對條件，這可讓您縮小 Kubernetes 在准入時進行遠端 HTTP 呼叫的範圍。ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 的 matchCondition 欄位是 CEL 表達式，必須評估為 true，才會將准入請求傳送至 Webhook。

在 Kubernetes v1.28 中，該欄位已移至 Beta 階段，並且預設為啟用。

若要瞭解更多資訊，請參閱 Kubernetes 文件中的 matchConditions。

Beta 支援在 Linux 上啟用交換空間

這以受控、可預測的方式將交換支援新增至節點，以便 Kubernetes 使用者可以執行測試並提供資料，以繼續在交換之上建構叢集功能。

交換空間有兩種不同的使用者類型，它們可能會重疊

  • 節點管理員，他們可能希望交換空間可用於節點層級的效能調整和穩定性/減少吵雜鄰居問題。

  • 應用程式開發人員，他們編寫了可以從使用交換記憶體中受益的應用程式。

混合版本 Proxy（Alpha 階段）

當叢集有多個混合版本的 API 伺服器時（例如在升級/降級期間或 runtime-config 變更且發生推出時），並非每個 API 伺服器都可以在每個版本中為每個資源提供服務。

對於 Kubernetes v1.28，您可以在 API 伺服器的聚合層中啟用混合版本 Proxy。混合版本 Proxy 會尋找本機 API 伺服器無法辨識，但控制平面內部的另一個 API 伺服器能夠支援的請求。在找到合適的對等點後，聚合層會將請求 Proxy 到相容的 API 伺服器；這對用戶端來說是透明的。

當在叢集上執行升級或降級時，在一段時間內，控制平面內的 API 伺服器可能處於不同的版本；當這種情況發生時，不同子集的 API 伺服器能夠為不同組的內建資源提供服務（不同的群組、版本和資源都是可能的）。這種新的 Alpha 機制可讓您向用戶端隱藏這種偏差。

控制平面元件的原始碼重組

Kubernetes 貢獻者已開始重組 kube-apiserver 的程式碼，以建構在新的暫存儲存庫之上，該儲存庫使用 k/apiserver，但具有 kube-apiserver 功能的更大、精心挑選的子集，使其可重複使用。

這是一個漸進式的重組；最終將會有一個新的 Git 儲存庫，其中包含從 Kubernetes API 伺服器中提取的通用功能。

支援將 CDI 注入到容器中（Alpha 階段）

CDI 提供了一種標準化的方式，將複雜的裝置注入到容器中（即邏輯上需要注入多個 /dev 節點才能運作的裝置）。這項新功能使外掛程式開發人員能夠利用 1.27 中新增到 CRI 的 CDIDevices 欄位，將 CDI 裝置直接傳遞給啟用 CDI 的執行階段（其中 containerd 和 crio-o 是在最近的版本中）。

API 感知 Sidecar 容器（Alpha 階段）

Kubernetes 1.28 為 初始化容器 引入了 Alpha restartPolicy 欄位，並使用它來指示初始化容器何時也是Sidecar 容器。kubelet 將依照定義的順序，以及其他初始化容器，啟動具有 restartPolicy: Always 的初始化容器。kubelet 不會等待該 Sidecar 容器完成，才啟動 Pod 的主要容器，而只會等待 Sidecar 初始化容器啟動。

如果啟動探針成功且 postStart 處理常式已完成，則 kubelet 會將 Sidecar 容器的啟動視為已完成。此條件以 ContainerStatus 類型的欄位 Started 表示。如果您未定義啟動探針，則 kubelet 會在 postStart 處理常式完成後立即將容器啟動視為已完成。

對於初始化容器，您可以省略 restartPolicy 欄位，或將其設定為 Always。省略該欄位表示您想要一個真正的初始化容器，它會在應用程式啟動之前運行完成。

Sidecar 容器不會阻止 Pod 完成：如果所有常規容器都已完成，則該 Pod 中的 Sidecar 容器將會終止。

一旦 Sidecar 容器啟動（程序正在運行、postStart 成功，且任何已組態的啟動探針都通過），然後發生故障，即使 Pod 的整體 restartPolicy 為 Never 或 OnFailure，該 Sidecar 容器也會重新啟動。此外，即使在 Pod 終止期間，Sidecar 容器也會重新啟動（在故障或正常退出時）。

若要瞭解更多資訊，請參閱Sidecar 容器的 API。

自動、追溯分配預設 StorageClass 升級至穩定階段

如果您未提供值，Kubernetes 會自動為 PersistentVolumeClaim (PVC) 設定 storageClassName。控制平面也會為任何未定義 storageClassName 的現有 PVC 設定 StorageClass。先前版本的 Kubernetes 也具有此行為；對於 Kubernetes v1.28，它是自動且始終處於活動狀態；此功能已升級至穩定階段（正式發布）。

若要瞭解更多資訊，請參閱 Kubernetes 文件中關於 StorageClass 的資訊。

Job 的 Pod 替換策略（Alpha 階段）

Kubernetes 1.28 為 Job API 新增了一個欄位，可讓您指定是否希望控制平面在先前的 Pod 開始終止時立即建立新的 Pod（現有行為），還是僅在現有的 Pod 完全終止後才建立（新的可選行為）。

許多常見的機器學習框架，例如 Tensorflow 和 JAX，每個索引都需要唯一的 Pod。使用較舊的行為，如果屬於 Indexed Job 的 Pod 進入終止狀態（由於搶佔、驅逐或其他外部因素），則會建立替換 Pod，但隨即由於與尚未關閉的舊 Pod 衝突而立即啟動失敗。

在資源稀缺或預算緊張的叢集中，在先前的 Pod 完全終止之前出現替換 Pod 也可能導致問題。這些資源可能難以取得，因此 Pod 可能只有在現有的 Pod 終止後才能找到節點。如果啟用了叢集自動擴展器，則提前建立替換 Pod 可能會產生不希望出現的擴展。

若要瞭解更多資訊，請參閱 Job 文件中的延遲建立替換 Pod。

Job 重試退避限制，每個索引（Alpha 階段）

這擴充了 Job API，以支援每個索引都有退避限制的索引 Job，並且即使某些索引失敗，Job 也可以繼續執行。

目前，索引 Job 的索引共用單一退避限制。當 Job 達到此共用退避限制時，Job 控制器會將整個 Job 標記為失敗，並且會清理資源，包括尚未運行完成的索引。

因此，現有的實作未涵蓋工作負載真正極易並行化的情況：每個索引完全獨立於其他索引。

例如，如果索引 Job 用作一組長時間運行的整合測試的基礎，則每次測試運行只能找到單一測試失敗。

有關更多資訊，請參閱 Kubernetes 文件中的處理 Pod 和容器故障。

更正：CRI 容器和 Pod 統計資訊（不含 cAdvisor）功能已被移除，因為它未包含在此版本中。原始版本公告聲明 Kubernetes 1.28 包含此新功能。

Kubernetes v1.28 中的功能升級和棄用

升級至穩定階段

此版本總共包含 12 項升級至穩定階段的增強功能

棄用和移除

移除

棄用

發行說明

Kubernetes v1.28 版本的完整詳細資訊可在我們的發行說明中找到。

可用性

Kubernetes v1.28 可在 GitHub 上下載。若要開始使用 Kubernetes，您可以使用 minikube、kind 等執行本機 Kubernetes 叢集。您也可以使用 kubeadm 輕鬆安裝 v1.28。

發布團隊

Kubernetes 的實現離不開社群的支援、投入和辛勤工作。每個發布團隊都由專門的社群志工組成，他們共同努力建構組成您所依賴的 Kubernetes 發布版本的眾多部分。這需要我們社群各個角落的人員的專業技能，從程式碼本身到文件和專案管理。

我們要感謝整個發布團隊付出的時間和辛勤工作，以確保我們為社群交付穩定的 Kubernetes v1.28 版本。

特別感謝我們的發布負責人 Grace Nguyen，感謝她引導我們完成順利且成功的發布週期。

生態系統更新

  • KubeCon + CloudNativeCon China 2023 將於 2023 年 9 月 26 日至 28 日在中國上海舉行！您可以在活動網站上找到有關會議和註冊的更多資訊。
  • KubeCon + CloudNativeCon North America 2023 將於 2023 年 11 月 6 日至 9 日在美利堅合眾國伊利諾州芝加哥舉行！您可以在活動網站上找到有關會議和註冊的更多資訊。

專案速度

CNCF K8s DevStats 專案彙總了許多與 Kubernetes 和各種子專案的速度相關的有趣資料點。這包括從個人貢獻到貢獻公司的數量等所有內容，並且說明了為發展這個生態系統所付出的努力的深度和廣度。

在 v1.28 發布週期中（持續了 14 週，從 5 月 15 日到 8 月 15 日），我們看到了來自 911 家公司 和 1440 位個人的貢獻。

即將舉行的版本發布網路研討會

加入 Kubernetes v1.28 發布團隊成員，於 2023 年 9 月 6 日星期三太平洋夏令時間上午 9 點，瞭解此版本的主要功能，以及有助於規劃升級的棄用和移除。有關更多資訊和註冊，請造訪 CNCF 線上課程網站上的活動頁面。

參與其中

參與 Kubernetes 最簡單的方式是加入與您的興趣相符的眾多特殊興趣小組 (SIG) 之一。

有想向 Kubernetes 社群廣播的內容嗎？在我們的每週社群會議上以及透過以下管道分享您的聲音