Kubernetes v1.33: Octarine

作者：Kubernetes v1.33 釋出團隊 |

編輯： Agustina Barbetta、Aakanksha Bhende、Udi Hofesh、Ryota Sawada、Sneha Yadav

與之前的版本類似，Kubernetes v1.33 的釋出引入了新的穩定、Beta 和 Alpha 功能。持續交付高質量的版本突顯了我們強大的開發週期和社群充滿活力的支援。

此版本包含 64 項增強功能。其中，18 項已升級為穩定版，20 項進入 Beta 版，24 項進入 Alpha 版，還有 2 項被棄用或撤回。

此版本中還有一些值得注意的棄用和移除；如果您已經在執行舊版本的 Kubernetes，請務必閱讀相關內容。

Kubernetes v1.33 的主題是魔法的顏色：Octarine1，靈感來自特里·普拉切特的《碟形世界》系列。此版本突顯了 Kubernetes 在整個生態系統中實現的開源魔法2。

如果您熟悉《碟形世界》，您可能會認出一隻小小的沼澤龍棲息在無形大學的塔頂，仰望著 Ankh-Morpork 城上空的 Kubernetes 月亮，背景中有 64 顆星星3。

隨著 Kubernetes 邁入第二個十年，我們慶祝其維護者的精湛技藝、新貢獻者的好奇心以及推動專案前進的協作精神。v1.33 版本提醒我們，正如普拉切特所寫：“即使你知道它是如何完成的，它仍然是魔法。”即使你對 Kubernetes 程式碼庫的裡裡外外瞭如指掌，在釋出週期結束時回望，你也會意識到 Kubernetes 依然充滿魔力。

Kubernetes v1.33 證明了開源創新的持久力量，來自世界各地的數百名貢獻者4共同創造了真正非凡的成果。在每一個新功能的背後，Kubernetes 社群都在努力維護和改進專案，確保其安全、可靠並按時釋出。每個版本都建立在前一個版本的基礎上，創造出比我們獨自能實現的更偉大的東西。

1. Octarine 是神話中的第八種顏色，只有那些對奧術有感知的人才能看到——巫師、女巫，當然還有貓。偶爾，某個盯著 IPtable 規則太久的人也能看到。
2. 任何足夠先進的技術都與魔法無異……？
3. v1.33 中也包含 64 個 KEP（Kubernetes 增強提案），這並非巧合。
4. 請參閱 v1.33 的“專案速度”部分 🚀

重點更新聚焦

Kubernetes v1.33 包含了許多新功能和改進。以下是釋出團隊希望重點介紹的一些更新！

穩定版：Sidecar 容器

Sidecar 模式涉及部署單獨的輔助容器來處理網路、日誌記錄和指標收集等領域的額外功能。Sidecar 容器在 v1.33 中升級為穩定版。

Kubernetes 將 Sidecar 實現為一種特殊的 Init 容器，其 `restartPolicy: Always`，確保 Sidecar 在應用容器之前啟動，在 Pod 的整個生命週期中保持執行，並在主容器退出後自動終止。

此外，Sidecar 可以利用探針（啟動、就緒、存活）來表明其執行狀態，並且其記憶體不足（OOM）分數調整與主容器保持一致，以防止在記憶體壓力下過早終止。

要了解更多資訊，請閱讀Sidecar 容器。

這項工作是作為 KEP-753：Sidecar 容器 的一部分完成的，由 SIG Node 領導。

Beta 版：用於 Pod 垂直擴充套件的就地資源調整

工作負載可以使用 Deployment、StatefulSet 等 API 來定義。這些 API 描述了應該執行的 Pod 的模板，包括記憶體和 CPU 資源，以及應該執行的 Pod 副本數量。工作負載可以透過更新 Pod 副本數量進行水平擴充套件，或者透過更新 Pod 容器中所需的資源進行垂直擴充套件。在此增強功能之前，Pod 的 `spec` 中定義的容器資源是不可變的，更新 Pod 模板中的任何這些細節都會觸發 Pod 替換。

但是，如果您可以動態更新現有 Pod 的資源配置而無需重啟它們呢？

KEP-1287 正是為了允許這種就地 Pod 更新而設計的。它在 v1.27 中作為 Alpha 版本釋出，並在 v1.33 中升級為 Beta 版。這為有狀態程序的垂直擴充套件提供了多種可能性，無需任何停機時間，在流量低時可以無縫縮減，甚至可以在啟動期間分配更大的資源，然後在初始設定完成後減少資源。

這項工作是作為 KEP-1287：就地更新 Pod 資源 的一部分完成的，由 SIG Node 和 SIG Autoscaling 領導。

Alpha 版：kubectl 新增 `.kuberc` 配置檔案選項用於使用者偏好設定

在 v1.33 中，`kubectl` 引入了一個新的 Alpha 功能，即使用可選的配置檔案 `.kuberc` 來設定使用者偏好。該檔案可以包含 `kubectl` 的別名和覆蓋設定（例如，預設使用伺服器端應用），同時將叢集憑據和主機資訊保留在 kubeconfig 中。這種分離允許共享相同的 `kubectl` 互動使用者偏好，而不管目標叢集和使用的 kubeconfig 是什麼。

要啟用此 Alpha 功能，使用者可以設定環境變數 `KUBECTL_KUBERC=true` 並建立一個 `.kuberc` 配置檔案。預設情況下，`kubectl` 會在 `~/.kube/kuberc` 中尋找此檔案。您也可以使用 `--kuberc` 標誌指定一個替代位置，例如：`kubectl --kuberc /var/kube/rc`。

這項工作是作為 KEP-3104：將 kubectl 使用者偏好與叢集配置分離 的一部分完成的，由 SIG CLI 領導。

升級為穩定版的功能

這是 v1.33 釋出後升級為穩定版的部分改進。

索引 Job 的按索引回退限制

此版本將一個功能升級為穩定版，該功能允許為索引 Job 設定按索引的回退限制。傳統上，Kubernetes Job 中的 `backoffLimit` 引數指定了在將整個 Job 視為失敗之前的重試次數。此增強功能允許索引 Job 中的每個索引都有自己的回退限制，從而為單個任務的重試行為提供更精細的控制。這確保了特定索引的失敗不會過早地終止整個 Job，從而允許其他索引獨立繼續處理。

這項工作是作為 KEP-3850：索引 Job 的按索引回退限制 的一部分完成的，由 SIG Apps 領導。

Job 成功策略

透過使用 `.spec.successPolicy`，使用者可以指定哪些 Pod 索引必須成功（`succeededIndexes`）、必須有多少個 Pod 成功（`succeededCount`），或兩者的組合。此功能適用於各種工作負載，包括部分完成即足夠滿足要求的模擬場景，以及只有領導者成功才能決定整個 Job 結果的領導者-工作者模式。

這項工作是作為 KEP-3998：Job 成功/完成策略 的一部分完成的，由 SIG Apps 領導。

繫結的 ServiceAccount 令牌安全性改進

此增強功能引入了一些特性，例如在令牌中包含唯一令牌識別符號（即 JWT ID 宣告，也稱為 JTI）和節點資訊，從而實現更精確的驗證和審計。此外，它支援節點特定的限制，確保令牌只能在指定的節點上使用，從而降低令牌被濫用和潛在安全漏洞的風險。這些改進現已正式可用，旨在增強 Kubernetes 叢集內 Service Account 令牌的整體安全態勢。

這項工作是作為 KEP-4193：繫結的 Service Account 令牌改進 的一部分完成的，由 SIG Auth 領導。

kubectl 對子資源的支援

`--subresource` 引數現在已在 kubectl 的 `get`、`patch`、`edit`、`apply` 和 `replace` 等子命令中正式可用，允許使用者獲取和更新所有支援子資源的資源的子資源。要了解更多關於支援的子資源的資訊，請訪問 kubectl 參考。

這項工作是作為 KEP-2590：為 kubectl 新增子資源支援 的一部分完成的，由 SIG CLI 領導。

多個 Service CIDR

此增強功能引入了一種新的 Service IP 分配邏輯實現。在整個叢集中，每個 `type: ClusterIP` 的 Service 都必須分配一個唯一的 IP 地址。嘗試使用一個已經被分配的特定叢集 IP 建立 Service 將會返回錯誤。更新後的 IP 地址分配器邏輯使用了兩個新的穩定 API 物件：`ServiceCIDR` 和 `IPAddress`。這些 API 現已正式可用，允許叢集管理員（透過建立新的 ServiceCIDR 物件）動態增加可用於 `type: ClusterIP` 服務的 IP 地址數量。

這項工作是作為 KEP-1880：多個 Service CIDR 的一部分完成的，由 SIG Network 領導。

kube-proxy 的 `nftables` 後端

kube-proxy 的 `nftables` 後端現已穩定，它增加了一個新的實現，顯著提高了 Kubernetes 叢集內 Service 實現的效能和可伸縮性。出於相容性原因，`iptables` 仍然是 Linux 節點上的預設後端。如果您想嘗試它，請查閱遷移指南。

這項工作是作為 KEP-3866：nftables kube-proxy 後端 的一部分完成的，由 SIG Network 領導。

具有 `trafficDistribution: PreferClose` 的拓撲感知路由

此版本將拓撲感知路由和流量分發升級為正式可用（GA），這將使我們能夠最佳化多區域叢集中的服務流量。EndpointSlices 中的拓撲感知提示將使像 kube-proxy 這樣的元件能夠優先將流量路由到同一區域內的端點，從而降低延遲和跨區域資料傳輸成本。在此基礎上，Service 規範中添加了 `trafficDistribution` 欄位，`PreferClose` 選項會根據網路拓撲將流量導向最近的可用端點。此配置透過最小化區域間通訊來提高效能和成本效益。

這項工作是作為 KEP-4444：Service 的流量分發 和 KEP-2433：拓撲感知路由 的一部分完成的，由 SIG Network 領導。

拒絕非 SMT 對齊工作負載的選項

此功能為 CPU 管理器添加了策略選項，使其能夠拒絕不符合同時多執行緒（SMT）配置的工作負載。此增強功能現已正式可用，確保當一個 Pod 請求獨佔使用 CPU 核心時，CPU 管理器可以在啟用 SMT 的系統上強制分配整個核心對（包括主執行緒和兄弟執行緒），從而防止工作負載以非預期的方式共享 CPU 資源。

這項工作是作為 KEP-2625：node: cpumanager: 新增拒絕非 SMT 對齊工作負載的選項 的一部分完成的，由 SIG Node 領導。

使用 `matchLabelKeys` 和 `mismatchLabelKeys` 定義 Pod 親和性或反親和性

`matchLabelKeys` 和 `mismatchLabelKeys` 欄位現在在 Pod 親和性術語中可用，使使用者能夠精細控制 Pod 應該共存（親和性）或不共存（反親和性）的範圍。這些新的穩定選項補充了現有的 `labelSelector` 機制。親和性欄位有助於增強通用滾動更新的排程，以及基於全域性配置隔離由工具或控制器管理的服務。

這項工作是作為 KEP-3633：為 Pod 親和性和 Pod 反親和性引入 MatchLabelKeys 的一部分完成的，由 SIG Scheduling 領導。

計算 Pod 拓撲分佈偏差時考慮汙點和容忍

此功能透過引入兩個欄位增強了 `PodTopologySpread`：`nodeAffinityPolicy` 和 `nodeTaintsPolicy`。這些欄位允許使用者指定在計算 Pod 在節點間的分佈時是否應考慮節點親和性規則和節點汙點。預設情況下，`nodeAffinityPolicy` 設定為 `Honor`，這意味著只有匹配 Pod 節點親和性或選擇器的節點才會被包含在分佈計算中。`nodeTaintsPolicy` 預設為 `Ignore`，表示除非特別指定，否則不考慮節點汙點。此增強功能提供了對 Pod 放置的更精細控制，確保 Pod 被排程到同時滿足親和性和汙點容忍要求的節點上，從而防止因未滿足約束而導致 Pod 保持 Pending 狀態的情況。

這項工作是作為 KEP-3094：計算 PodTopologySpread 偏差時考慮汙點/容忍 的一部分完成的，由 SIG Scheduling 領導。

卷填充器

在 v1.24 作為 Beta 版本釋出後，*卷填充器* 已經在 v1.33 中升級為正式可用（GA）。這個新的穩定功能提供了一種方式，允許使用者使用來自各種來源的資料預填充卷，而不僅僅是從持久卷宣告（PVC）克隆或卷快照中。該機制依賴於 PersistentVolumeClaim 中的 `dataSourceRef` 欄位。該欄位比現有的 `dataSource` 欄位提供了更大的靈活性，並允許使用自定義資源作為資料來源。

一個特殊的控制器 `volume-data-source-validator` 會驗證這些資料來源引用，同時還有一個新的穩定 CustomResourceDefinition (CRD)，用於一個名為 VolumePopulator 的 API 型別。VolumePopulator API 允許卷填充器控制器註冊它們支援的資料來源型別。您需要使用適當的 CRD 設定您的叢集才能使用卷填充器。

這項工作是作為 KEP-1495：通用資料填充器 的一部分完成的，由 SIG Storage 領導。

始終遵循持久捲回收策略

此增強功能解決了一個問題，即持久卷（PV）回收策略未被一致地遵循，導致潛在的儲存資源洩漏。具體來說，如果一個 PV 在其關聯的持久卷宣告（PVC）之前被刪除，“Delete”回收策略可能不會被執行，從而使底層儲存資產保持完整。為了緩解這個問題，Kubernetes 現在在相關的 PV 上設定了 finalizers，確保無論刪除順序如何，回收策略都會被強制執行。此增強功能防止了儲存資源的意外保留，並保持了 PV 生命週期管理的一致性。

這項工作是作為 KEP-2644：始終遵循持久捲回收策略 的一部分完成的，由 SIG Storage 領導。

Beta 版新功能

這是 v1.33 釋出後升級為 Beta 版的部分改進。

Windows kube-proxy 支援直接伺服器返回（DSR）

DSR 透過允許透過負載均衡器路由的返回流量繞過負載均衡器直接響應客戶端，從而提供了效能最佳化；這減少了負載均衡器的負載，也降低了整體延遲。有關 Windows 上的 DSR 的資訊，請閱讀直接伺服器返回（DSR）簡述。

最初在 v1.14 中引入的 DSR 支援，已由 SIG Windows 作為 KEP-5100：在 Windows kube-proxy 中支援直接伺服器返回（DSR）和覆蓋網路 的一部分提升為 Beta 版。

結構化引數支援

雖然結構化引數支援在 Kubernetes v1.33 中仍然是 Beta 功能，但作為動態資源分配（DRA）的核心部分，它已經有了顯著的改進。一個新的 v1beta2 版本簡化了 `resource.k8s.io` API，並且具有名稱空間叢集 `edit` 角色的普通使用者現在可以使用 DRA。

現在 `kubelet` 包含了無縫升級支援，使得作為 DaemonSet 部署的驅動程式能夠使用滾動更新機制。對於 DRA 實現，這可以防止 ResourceSlice 的刪除和重新建立，使其在升級期間保持不變。此外，在 `kubelet` 清理未註冊的驅動程式之前，引入了一個 30 秒的寬限期，為不使用滾動更新的驅動程式提供了更好的支援。

這項工作是作為 KEP-4381：DRA：結構化引數 的一部分完成的，由 WG Device Management 領導，這是一個跨職能團隊，包括 SIG Node、SIG Scheduling 和 SIG Autoscaling。

用於網路介面的動態資源分配（DRA）

在 v1.32 中引入的透過 DRA 標準化報告網路介面資料的功能，已在 v1.33 中升級為 Beta 版。這使得更原生的 Kubernetes 網路整合成為可能，簡化了網路裝置的開發和管理。這在之前的 v1.32 釋出公告部落格中已有介紹。

這項工作是作為 KEP-4817：DRA：帶有可能的標準化網路介面資料的資源宣告狀態 的一部分完成的，由 SIG Network、SIG Node 和 WG Device Management 領導。

當排程器在 activeQ 中沒有任何 Pod 時，提早處理未排程的 Pod

此功能改進了佇列排程行為。在幕後，排程器透過在 *activeQ* 為空時從 *backoffQ* 中彈出因錯誤而未被回退的 Pod 來實現這一點。以前，即使 *activeQ* 為空，排程器也會變得空閒；此增強功能透過防止這種情況來提高排程效率。

這項工作是作為 KEP-5142：當 activeQ 為空時從 backoffQ 中彈出 Pod 的一部分完成的，由 SIG Scheduling 領導。

Kubernetes 排程器中的非同步搶佔

搶佔透過驅逐較低優先順序的 Pod 來確保較高優先順序的 Pod 獲得它們所需的資源。非同步搶佔，在 v1.32 中作為 Alpha 版本引入，已在 v1.33 中升級為 Beta 版。透過此增強功能，諸如刪除 Pod 的 API 呼叫等繁重操作將並行處理，允許排程器繼續排程其他 Pod 而不會出現延遲。此改進在 Pod 流失率高或排程頻繁失敗的叢集中尤其有益，可確保更高效、更有彈性的排程過程。

這項工作是作為 KEP-4832：排程器中的非同步搶佔 的一部分完成的，由 SIG Scheduling 領導。

ClusterTrustBundles

ClusterTrustBundle，一個用於存放 X.509 信任錨（根證書）的叢集範圍資源，已在 v1.33 中升級為 Beta 版。此 API 使叢集內證書籤署者更容易向叢集工作負載釋出和傳達 X.509 信任錨。

這項工作是作為 KEP-3257：ClusterTrustBundles（以前稱為 Trust Anchor Sets） 的一部分完成的，由 SIG Auth 領導。

精細化的 SupplementalGroups 控制

此功能在 v1.31 中引入，在 v1.33 中升級為 Beta 版，並且現在預設啟用。如果您的叢集啟用了 `SupplementalGroupsPolicy` 特性門控，Pod 的 `securityContext` 中的 `supplementalGroupsPolicy` 欄位支援兩種策略：預設的 Merge 策略透過將指定的組與容器映象的 `/etc/group` 檔案中的組合來保持向後相容性，而新的 Strict 策略僅適用於明確定義的組。

此增強功能有助於解決安全問題，即容器映象中隱式的組成員身份可能導致意外的檔案訪問許可權並繞過策略控制。

這項工作是作為 KEP-3619：精細化的 SupplementalGroups 控制 的一部分完成的，由 SIG Node 領導。

支援將映象掛載為卷

在 v1.31 中引入的、支援在 Pod 中使用開放容器倡議（OCI）映象作為卷的功能，已升級為 Beta 版。此功能允許使用者將映象引用指定為 Pod 中的一個卷，同時在容器內將其作為卷掛載重複使用。這開啟了將卷資料分開打包，並在 Pod 內的容器間共享的可能性，而無需將它們包含在主映象中，從而減少了漏洞並簡化了映象建立。

這項工作是作為 KEP-4639：VolumeSource：OCI 製品和/或映象 的一部分完成的，由 SIG Node 和 SIG Storage 領導。

支援在 Linux Pod 內使用使用者名稱空間

截至撰寫本文時，最古老的開放 KEP 之一是 KEP-127，即透過為 Pod 使用 Linux 使用者名稱空間來提高 Pod 安全性。此 KEP 最初於 2016 年底提出，經過多次迭代，在 v1.25 中釋出了 Alpha 版本，在 v1.30 中首次釋出 Beta 版（預設停用），並作為 v1.33 的一部分轉為預設啟用的 Beta 版。

此支援不會影響現有的 Pod，除非您手動指定 `pod.spec.hostUsers` 來選擇加入。正如 v1.30 預覽部落格中強調的，這是緩解漏洞的重要里程碑。

這項工作是作為 KEP-127：支援在 Pod 中使用使用者名稱空間 的一部分完成的，由 SIG Node 領導。

Pod 的 `procMount` 選項

`procMount` 選項，在 v1.12 中作為 Alpha 版本引入，在 v1.31 中作為預設停用的 Beta 版本，已在 v1.33 中轉為預設啟用的 Beta 版本。此增強功能透過允許使用者微調對 `/proc` 檔案系統的訪問來提高 Pod 的隔離性。具體來說，它在 Pod 的 `securityContext` 中添加了一個欄位，讓您可以覆蓋預設的遮蔽和將某些 `/proc` 路徑標記為只讀的行為。這對於使用者希望在 Kubernetes Pod 內使用使用者名稱空間執行非特權容器的場景特別有用。通常，容器執行時（透過 CRI 實現）會以嚴格的 `/proc` 掛載設定啟動外部容器。然而，為了成功執行帶有非特權 Pod 的巢狀容器，使用者需要一種機制來放寬這些預設設定，而此功能正是為此而生。

這項工作是作為 KEP-4265：新增 ProcMount 選項 的一部分完成的，由 SIG Node 領導。

CPUManager 策略：跨 NUMA 節點分配 CPU

此功能為 CPU 管理器添加了一個新的策略選項，以跨非均勻記憶體訪問（NUMA）節點分配 CPU，而不是將它們集中在單個節點上。它透過在多個 NUMA 節點之間平衡工作負載來最佳化 CPU 資源分配，從而在多 NUMA 系統中提高效能和資源利用率。

這項工作是作為 KEP-2902：新增 CPUManager 策略選項以跨 NUMA 節點分配 CPU 而不是打包它們 的一部分完成的，由 SIG Node 領導。

容器 PreStop 鉤子的零秒休眠

Kubernetes 1.29 在 Pod 的 `preStop` 生命週期鉤子中引入了一個 Sleep 動作，允許容器在終止前暫停指定的時長。這提供了一種延遲容器關閉的直接方法，有助於執行連線排空或清理操作等任務。

現在，`preStop` 鉤子中的 Sleep 動作可以接受零秒時長，這是一個 Beta 功能。這允許定義一個無操作的 `preStop` 鉤子，當需要 `preStop` 鉤子但不需要任何延遲時非常有用。

這項工作是作為 KEP-3960：為 PreStop 鉤子引入 Sleep 動作 和 KEP-4818：允許 PreStop 鉤子的 Sleep 動作為零值 的一部分完成的，由 SIG Node 領導。

用於宣告式驗證 Kubernetes 原生型別的內部工具

在幕後，Kubernetes 的內部正在開始使用一種新的機制來驗證物件和物件的變更。Kubernetes v1.33 引入了 `validation-gen`，這是一個 Kubernetes 貢獻者用來生成宣告式驗證規則的內部工具。總體目標是透過使開發人員能夠宣告式地指定驗證約束，減少手動編碼錯誤並確保整個程式碼庫的一致性，從而提高 API 驗證的健壯性和可維護性。

這項工作是作為 KEP-5073：使用 validation-gen 宣告式驗證 Kubernetes 原生型別 的一部分完成的，由 SIG API Machinery 領導。

進入 Alpha 階段的新功能

這是 v1.33 釋出後升級為 Alpha 版的部分改進。

HorizontalPodAutoscalers 的可配置容忍度

此功能為 HorizontalPodAutoscalers 引入了可配置的容忍度，從而減弱了對微小指標變化的擴縮反應。

這項工作是作為 KEP-4951：Horizontal Pod Autoscaler 的可配置容忍度 的一部分完成的，由 SIG Autoscaling 領導。

可配置的容器重啟延遲

此功能在 v1.32 中作為 alpha1 引入，提供了一組 kubelet 級別的配置，用於微調 CrashLoopBackOff 的處理方式。

這項工作是作為 KEP-4603：調整 CrashLoopBackOff 的一部分完成的，由 SIG Node 領導。

自定義容器停止訊號

在 Kubernetes v1.33 之前，停止訊號只能在容器映象定義中設定（例如，透過映象元資料中的 `StopSignal` 配置欄位）。如果您想修改終止行為，就需要構建一個自定義容器映象。透過在 Kubernetes v1.33 中啟用（Alpha）`ContainerStopSignals` 特性門控，您現在可以直接在 Pod 規範中定義自定義停止訊號。這在容器的 `lifecycle.stopSignal` 欄位中定義，並要求 Pod 的 `spec.os.name` 欄位存在。如果未指定，容器將回退到映象定義的停止訊號（如果存在），或容器執行時的預設訊號（對於 Linux 通常是 SIGTERM）。

這項工作是作為 KEP-4960：容器停止訊號 的一部分完成的，由 SIG Node 領導。

DRA 增強功能 galore！

Kubernetes v1.33 繼續開發動態資源分配（DRA），其功能專為當今複雜的基礎設施而設計。DRA 是一種用於在 Pod 內部的 Pod 和容器之間請求和共享資源的 API。通常這些資源是 GPU、FPGA 和網路介面卡等裝置。

以下是 v1.33 中引入的所有 Alpha DRA 特性門控

  • 與節點汙點類似，透過啟用 `DRADeviceTaints` 特性門控，裝置支援汙點和容忍。管理員或控制平面元件可以對裝置進行汙點標記，以限制其使用。依賴這些裝置的 Pod 的排程可以在存在汙點時暫停，和/或使用被汙點標記的裝置的 Pod 可以被驅逐。
  • 透過啟用 `DRAPrioritizedList` 特性門控，DeviceRequest 獲得了一個名為 `firstAvailable` 的新欄位。該欄位是一個有序列表，允許使用者指定一個請求可以透過不同方式滿足，包括在某些特定硬體不可用時完全不分配。
  • 啟用 `DRAAdminAccess` 特性門控後，只有被授權在帶有 `resource.k8s.io/admin-access: "true"` 標籤的名稱空間中建立 ResourceClaim 或 ResourceClaimTemplate 物件的使用者才能使用 `adminAccess` 欄位。這確保了非管理員使用者不能濫用 `adminAccess` 功能。
  • 雖然自 v1.31 以來就可以使用裝置分割槽，但供應商必須預先對裝置進行分割槽並相應地進行通告。透過在 v1.33 中啟用 `DRAPartitionableDevices` 特性門控，裝置供應商可以通告多個分割槽，包括重疊的分割槽。Kubernetes 排程器將根據工作負載請求選擇分割槽，並防止同時分配衝突的分割槽。此功能使供應商能夠在分配時動態建立分割槽。分配和動態分割槽對使用者來說是自動和透明的，從而提高了資源利用率。

除非您同時啟用 `DynamicResourceAllocation` 特性門控，否則這些特性門控無效。

這項工作是作為 KEP-5055：DRA：裝置汙點和容忍、KEP-4816：DRA：裝置請求中的優先備選方案、KEP-5018：DRA：ResourceClaim 和 ResourceClaimTemplate 的 AdminAccess 以及 KEP-4815：DRA：新增對可分割槽裝置的支援 的一部分完成的，由 SIG Node、SIG Scheduling 和 SIG Auth 領導。

穩健的映象拉取策略，用於對 `IfNotPresent` 和 `Never` 的映象進行身份驗證

此功能允許使用者確保 kubelet 對每組新的憑據都要求進行映象拉取身份驗證檢查，無論該映象是否已存在於節點上。

這項工作是作為 KEP-2535：確保 Secret 拉取映象 的一部分完成的，由 SIG Auth 領導。

節點拓撲標籤可透過 downward API 獲得

此功能使節點拓撲標籤能夠透過 downward API 暴露。在 Kubernetes v1.33 之前，一種變通方法是使用一個 Init 容器來查詢 Kubernetes API 以獲取底層節點；這個 Alpha 功能簡化了工作負載訪問節點拓撲資訊的方式。

這項工作是作為 KEP-4742：透過 downward API 暴露節點標籤 的一部分完成的，由 SIG Node 領導。

透過 generation 和 observed generation 改善 Pod 狀態

在此更改之前，`metadata.generation` 欄位在 Pod 中未被使用。除了擴充套件以支援 `metadata.generation` 之外，此功能還將引入 `status.observedGeneration` 以提供更清晰的 Pod 狀態。

這項工作是作為 KEP-5067：Pod Generation 的一部分完成的，由 SIG Node 領導。

kubelet 的 CPU 管理器支援分離式三級快取架構

之前的 kubelet CPU 管理器無法感知分離式 L3 快取架構（也稱為末級快取，或 LLC），並且可能在不考慮分離式 L3 快取的情況下分配 CPU，導致“吵鬧的鄰居”問題。這個 Alpha 功能改進了 CPU 管理器，以更好地分配 CPU 核心，從而提高效能。

這項工作是作為 KEP-5109：CPU 管理器中的分離式 L3 快取拓撲感知 的一部分完成的，由 SIG Node 領導。

用於改進排程的 PSI（壓力停滯資訊）指標

此功能在 Linux 節點上增加了使用 cgroupv2 提供 PSI 統計資料和指標的支援。它可以檢測資源短缺，併為節點提供更精細的 Pod 排程控制。

這項工作是作為 KEP-4205：基於 cgroupv2 支援 PSI 的一部分完成的，由 SIG Node 領導。

kubelet 無 Secret 映象拉取

kubelet 的磁碟憑據提供程式現在支援可選的 Kubernetes ServiceAccount (SA) 令牌獲取。這透過允許雲提供商更好地與相容 OIDC 的身份解決方案整合，簡化了與映象倉庫的身份驗證。

這項工作是作為 KEP-4412：用於 Kubelet 映象憑據提供程式的投影服務帳戶令牌 的一部分完成的，由 SIG Auth 領導。

v1.33 中的升級、棄用和移除

升級到穩定版

此列表列出了所有已升級為穩定版（也稱為*正式可用*）的功能。有關包括新功能和從 Alpha 升級到 Beta 的完整更新列表，請參閱釋出說明。

此版本總共包含 18 項升級為穩定版的增強功能

棄用和移除

隨著 Kubernetes 的發展和成熟，某些功能可能會被棄用、移除或被更好的功能替代，以提高專案的整體健康狀況。有關此過程的更多詳細資訊，請參閱 Kubernetes 棄用和移除策略。其中許多棄用和移除已在棄用和移除部落格文章中宣佈。

棄用穩定的 Endpoints API

自 v1.21 起，EndpointSlices API 已穩定，它有效地取代了最初的 Endpoints API。雖然最初的 Endpoints API 簡單直接，但在擴充套件到大量網路端點時也帶來了一些挑戰。EndpointSlices API 引入了雙棧網路等新功能，使得最初的 Endpoints API 已經可以被棄用了。

此棄用僅影響那些直接從工作負載或指令碼中使用 Endpoints API 的使用者；這些使用者應遷移到使用 EndpointSlices。將會有一篇專門的部落格文章，詳細介紹此棄用的影響和遷移計劃。

您可以在 KEP-4974：棄用 v1.Endpoints 中找到更多資訊。

從節點狀態中移除 kube-proxy 版本資訊

繼在 v1.31 中被棄用，如 v1.31 釋出公告中所強調的，節點的 `.status.nodeInfo.kubeProxyVersion` 欄位已在 v1.33 中被移除。

此欄位由 kubelet 設定，但其值並不總是準確的。由於自 v1.31 起預設停用，此欄位已在 v1.33 中被完全移除。

您可以在 KEP-4004：棄用 status.nodeInfo.kubeProxyVersion 欄位 中找到更多資訊。

移除樹內 gitRepo 卷驅動

gitRepo 卷型別自 v1.11 起已被棄用，至今已有近 7 年。自棄用以來，一直存在安全問題，包括 gitRepo 卷型別如何被利用以在節點上以 root 身份獲得遠端程式碼執行。在 v1.33 中，樹內驅動程式碼已被移除。

有 git-sync 和 initContainers 等替代方案。Kubernetes API 中的 `gitVolumes` 並未移除，因此帶有 `gitRepo` 卷的 Pod 仍會被 kube-apiserver 接受，但將 `GitRepoVolumeDriver` 特性門控設定為 false 的 kubelet 將不會執行它們，並會向用戶返回適當的錯誤。這允許使用者選擇重新啟用該驅動程式 3 個版本，以便他們有足夠的時間修復工作負載。

計劃在 v1.39 版本中移除 kubelet 中的特性門控和樹內外掛程式碼。

您可以在 KEP-5040：移除 gitRepo 卷驅動 中找到更多資訊。

移除對 Windows Pod 的主機網路支援

Windows Pod 網路旨在實現與 Linux 的功能對等，並透過允許容器使用節點的網路名稱空間來提高叢集密度。最初的實現作為 Alpha 版本於 v1.26 落地，但由於面臨意外的 containerd 行為以及存在替代解決方案，Kubernetes 專案決定撤回相關的 KEP。在 v1.33 中，支援已完全移除。

請注意，這不影響 HostProcess 容器，它提供主機網路以及主機級別的訪問許可權。v1.33 中撤回的 KEP 僅涉及提供主機網路，由於 Windows 網路邏輯的技術限制，該功能從未穩定過。

您可以在 KEP-3503：Windows Pod 的主機網路支援 中找到更多資訊。

釋出說明

請在我們的釋出說明中檢視 Kubernetes v1.33 釋出的全部詳細資訊。

可用性

Kubernetes v1.33 可在 GitHub 或 Kubernetes 下載頁面上下載。

要開始使用 Kubernetes，請檢視這些互動式教程，或使用 minikube 執行本地 Kubernetes 叢集。您也可以使用 kubeadm 輕鬆安裝 v1.33。

釋出團隊

Kubernetes 的成功離不開其社群的支援、承諾和辛勤工作。釋出團隊由敬業的社群志願者組成，他們共同努力構建 Kubernetes 版本的各個部分，為您提供可靠的釋出。這需要來自我們社群各個角落的人們的專業技能，從程式碼本身到其文件和專案管理。

我們要感謝整個釋出團隊為向我們的社群交付 Kubernetes v1.33 版本所付出的辛勤工作。釋出團隊的成員範圍從首次參與的影子成員到經驗豐富的迴歸團隊負責人，他們的經驗是在多個釋出週期中鍛造的。在此釋出週期中，採用了新的團隊結構，即將釋出說明和文件子團隊合併為一個統一的文件子團隊。得益於新文件團隊在組織相關資訊和資源方面的 meticulous 努力，釋出說明和文件跟蹤都實現了平穩成功的過渡。最後，特別感謝我們的釋出負責人 Nina Polshakova，感謝她在一個成功的釋出週期中提供的支援、她的倡導、她為確保每個人都能有效貢獻所做的努力，以及她對改進發布過程的挑戰。

專案速度

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

在 v1.33 釋出週期中，從 2025 年 1 月 13 日到 4 月 23 日，為期 15 周，Kubernetes 收到了多達 121 家不同公司和 570 名個人的貢獻（截至撰寫本文時，即釋出日期前幾周）。在更廣泛的雲原生生態系統中，這一數字上升到 435 家公司，總計 2400 名貢獻者。您可以在此儀表板中找到資料來源。與上一個版本 v1.32 的速度資料相比，我們看到公司和個人的貢獻水平相似，表明社群興趣和參與度依然強勁。

請注意，“貢獻”是指某人提交了提交、程式碼審查、評論、建立了 issue 或 PR、審查了 PR（包括部落格和文件）或對 issue 和 PR 進行了評論。如果您有興趣做出貢獻，請訪問我們貢獻者網站上的入門指南。

檢視 DevStats 以瞭解有關 Kubernetes 專案和社群整體速度的更多資訊。

活動更新

探索即將舉行的 Kubernetes 和雲原生活動，包括 KubeCon + CloudNativeCon、KCD 和全球其他著名會議。隨時瞭解最新資訊並參與 Kubernetes 社群！

2025 年 5 月

2025 年 6 月

2025 年 7 月

2025 年 8 月

您可以在此處找到最新的 KCD 詳細資訊。

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

請於 2025 年 5 月 16 日星期五下午 4:00 (UTC) 加入 Kubernetes v1.33 釋出團隊的成員，瞭解此版本的釋出亮點，以及棄用和移除的內容，以幫助規劃升級。更多資訊和註冊，請訪問 CNCF 線上計劃網站上的活動頁面。

參與其中

參與 Kubernetes 的最簡單方法是加入眾多與您興趣相符的特殊興趣小組（SIG）之一。您有想向 Kubernetes 社群廣播的內容嗎？請在我們每週的社群會議上分享您的聲音，並透過以下渠道。感謝您持續的反饋和支援。