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

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。對於執行時間非常長的工作負載的 Kubernetes 終端使用者，以及希望 Pod 儘可能保持執行的情況，減少因節點維護而損失的時間是一個好處。

Kubernetes 的年度支援期已經使得年度升級成為可能。使用者可以升級到最新的補丁版本以獲取安全修復，並每年進行一次連續 3 個小版本的升級，以“趕上”最新的受支援小版本。

以前，為了保持在支援的版本傾斜範圍內，計劃進行年度升級的叢集操作員需要升級他們的節點兩次（可能僅相隔數小時）。現在，有了 Kubernetes v1.28，您可以選擇每年只對節點進行一次小版本升級，同時仍然保持在上游支援範圍內。

如果你想保持最新狀態並更頻繁地升級你的叢集，那也完全沒問題，並且仍然完全受支援。

正式釋出：從非平滑節點關閉中恢復

如果節點意外關閉或進入不可恢復狀態（可能是由於硬體故障或作業系統無響應），Kubernetes 允許你事後進行清理，並讓有狀態的工作負載在不同的節點上重新啟動。對於 Kubernetes v1.28，這現在是一個穩定功能。

這使得有狀態的工作負載在原始節點關閉或處於不可恢復狀態（如硬體故障或作業系統損壞）後，能夠成功地故障轉移到另一個節點。

v1.20 之前的 Kubernetes 版本缺乏對 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 將具有相同的名稱）。

儲存方面也存在問題。如果 Pod 使用了卷，現有的 VolumeAttachments 將不會與原始的、現已關閉的節點解除關聯，因此這些 Pod 使用的 PersistentVolumes 無法附加到另一個健康的節點上。結果，執行在受影響的 StatefulSet 上的應用程式可能無法正常執行。如果原始的、已關閉的節點恢復執行，那麼它的 Pod 將被其 kubelet 刪除，新的 Pod 可以在另一個執行中的節點上建立。如果原始節點沒有恢復執行（在使用不可變基礎設施設計時很常見），那些 Pod 將永遠停留在已關閉節點上的 `Terminating` 狀態。

要了解更多關於如何在非平滑節點關閉後觸發清理的資訊，請閱讀非平滑節點關閉。

CustomResourceDefinition 驗證規則的改進

通用表示式語言（CEL）可用於驗證自定義資源。主要目標是允許大多數驗證用例，而這些用例過去可能需要你作為 CustomResourceDefinition (CRD) 的作者來設計和實現一個 webhook。相反，作為一個 Beta 功能，你可以將**驗證表示式**直接新增到 CRD 的模式中。

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

在 1.28 中，添加了兩個可選欄位 `reason` 和 `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`。

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

這以一種受控、可預測的方式為節點添加了交換空間支援，以便 Kubernetes 使用者可以進行測試並提供資料，從而在交換空間之上繼續構建叢集能力。

交換空間有兩種截然不同的使用者型別，他們可能會重疊：

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

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

混合版本代理 (Alpha)

當叢集中有多個不同版本的 API 伺服器時（例如在升級/降級期間或當執行時配置發生變化並進行滾動更新時），並非每個 API 伺服器都能處理所有資源的所有版本。

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

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

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

Kubernetes 貢獻者已經開始重組 kube-apiserver 的程式碼，以構建一個新的暫存（staging）倉庫。該倉庫消費 k/apiserver，但包含了一個更大、經過精心挑選的 kube-apiserver 功能子集，以便可以重用。

這是一個漸進的重組；最終會有一個新的 git 倉庫，其中包含從 Kubernetes 的 API 伺服器中抽象出的通用功能。

支援向容器注入 CDI (alpha)

CDI 提供了一種將複雜設備註入容器的標準化方法（即，那些邏輯上需要注入多個 /dev 節點才能工作的裝置）。這個新功能使得外掛開發者可以利用在 1.27 版本 CRI 中新增的 CDIDevices 欄位，將 CDI 裝置直接傳遞給支援 CDI 的執行時（其中 containerd 和 crio-o 在最近的版本中已經支援）。

Sidecar 容器的 API 感知 (alpha)

Kubernetes 1.28 為初始化容器引入了一個 alpha 版本的 `restartPolicy` 欄位，並用它來指示一個初始化容器是否也是一個**sidecar 容器**。kubelet 將按照定義的順序啟動 `restartPolicy: Always` 的初始化容器，以及其他初始化容器。kubelet 不會等待該 sidecar 容器完成後再啟動 Pod 的主容器，而只會等待 sidecar 初始化容器已經啟動。

如果啟動探針成功且 postStart 處理器完成，kubelet 將認為 sidecar 容器的啟動已經完成。這種情況由 ContainerStatus 型別的 Started 欄位表示。如果你沒有定義啟動探針，kubelet 將在 postStart 處理器完成後立即認為容器啟動完成。

對於 Init 容器，你可以省略 `restartPolicy` 欄位，或者將其設定為 `Always`。省略該欄位意味著你想要一個真正的 Init 容器，它在應用程式啟動前執行至完成。

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

一旦 sidecar 容器已經啟動（程序正在執行，`postStart` 已成功，並且任何配置的啟動探針都透過），然後如果出現故障，即使 Pod 的整體 `restartPolicy` 是 `Never` 或 `OnFailure`，該 sidecar 容器也會被重啟。此外，sidecar 容器將在**Pod 終止期間**被重啟（無論是因為故障還是正常退出）。

要了解更多資訊，請閱讀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 終止後才能找到節點。如果啟用了叢集自動伸縮器，提前建立替換 Pod 可能會產生不希望的擴容。

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

按索引計數的 Job 重試退避限制 (alpha)

此功能擴充套件了 Job API，以支援索引式 Job，其中退避限制是按索引計數的，即使某些索引失敗，Job 也可以繼續執行。

目前，索引式作業的索引共享一個單一的退避限制。當作業達到這個共享的退避限制時，作業控制器會將整個作業標記為失敗，並清理資源，包括那些尚未執行完成的索引。

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

例如，如果使用索引式作業作為一套長時間執行的整合測試的基礎，那麼每次測試執行只能發現一個測試失敗。

欲瞭解更多資訊，請閱讀 Kubernetes 文件中的處理 Pod 和容器故障。

更正：功能“無 cAdvisor 的 CRI 容器和 Pod 統計”已被移除，因為它未包含在此版本中。最初的釋出公告曾宣告 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 位個人的貢獻。

即將舉行的釋出網路研討會

歡迎在 2023 年 9 月 6 日（星期三）太平洋夏令時間上午 9 點加入 Kubernetes v1.28 釋出團隊成員的線上研討會，瞭解此版本的主要功能，以及棄用和移除的內容，以幫助規劃升級。更多資訊和註冊，請訪問 CNCF 線上專案網站上的活動頁面。

參與其中

參與 Kubernetes 的最簡單方法是加入與你興趣相符的眾多特別興趣小組（SIG）之一。

有什麼想向 Kubernetes 社群廣播的內容嗎？在我們每週的社群會議上分享你的聲音，並透過以下渠道進行分享：