我們很高興地宣布發布 Kubernetes v1.30: Uwubernetes，這是迄今為止最可愛的版本！

與之前的版本一樣，Kubernetes v1.30 的發布引入了新的穩定（Stable）功能、測試（Beta）功能和預覽（Alpha）功能。通過持續發布高質量版本，我們展示了我們強大的開發周期能力以及來自社區的熱情支持。

這個版本包含了 45 個增強功能，其中有 17 個已升級為穩定版，18 個進入了測試版，還有 10 個被提升至預覽版。

發布主題和標志

1.Kubernetes v1.30: Uwubernetes

Kubernetes v1.30 讓你的集群更可愛！

Kubernetes 是由來自世界各地、各行各業的數千人共同構建和發布的。大多數貢獻者并沒有為此獲得報酬；我們的構建動力源于樂趣、問題解決、學習以及對社區的熱愛。我們中的許多人在這里找到了家、朋友和事業。發布團隊很榮幸能夠參與 Kubernetes 持續發展的過程。

對于那些為它做出貢獻的人，對于那些發布它的人，以及對于那些保持我們所有集群在線的人，我們呈現 Kubernetes v1.30: Uwubernetes，這是迄今為止最可愛的版本。這個名稱是“kubernetes”和“UwU”（一種表示幸?；蚩蓯鄣谋砬榉枺┑慕Y合。我們在這里找到了快樂，并將外部生活的快樂帶到這里，使這個社區變得如此獨特、美妙和充滿激情。我們非常高興能與你分享我們的工作。

2.在 Kubernetes v1.30 中升級為穩定版的改進功能

以下是在 v1.30 版本發布后現在已穩定的一些改進功能的選擇。

3.kubelet 重啟后穩健的 VolumeManager 重建（SIG Storage）

這是卷管理器的重構，允許 kubelet 在啟動過程中填充關于現有卷如何掛載的額外信息?？傮w而言，這使得在 kubelet 重新啟動或機器重啟后的卷清理更加穩健。

對于用戶或集群管理員而言，并沒有任何變化。我們使用功能流程和功能開關 NewVolumeManagerReconstruction，以便在出現問題時能夠回退到之前的行為?，F在該功能已經穩定，功能開關已被鎖定，無法禁用。

4.防止在卷還原過程中未經授權的卷模式轉換（SIG Storage）

在 Kubernetes 1.30，控制平面始終會在將快照還原為持久卷時阻止未經授權的卷模式更改。作為集群管理員，如果你需要在還原時允許該類更改，你將需要授予適當身份主體（例如：代表存儲集成的服務賬號）的權限。

警告：在升級之前，請采取必要的操作。在 external-provisioner v4.0.0 和 external-snapshotter v7.0.0 中，默認啟用了 prevent-volume-mode-conversion 功能標志。如果通過 VolumeSnapshot 創建 PVC 時進行卷模式更改，將被拒絕。除非按照 ?external-provisioner 4.0.0 和 ?external-snapshotter v7.0.0 中的“緊急升級注意事項”部分中的步驟進行操作。

有關此功能的更多信息，請閱讀有關?轉換快照卷模式的說明。

5.Pod 調度可用性（SIG Scheduling）

Pod 調度可用性在 Kubernetes v1.27 中升級為測試版，并在此版本中成為穩定版。

這個現在穩定的功能使得 Kubernetes 可以避免在集群尚未準備好將 Pod 綁定到節點的資源時嘗試調度已定義的 Pod。這不僅僅是一個用例；你還可以使用自定義控制來實現配額機制、安全控制等，以決定是否允許調度 Pod。

將這些 Pod 標記為免于調度可以減少調度器的工作量，避免其在當前集群節點上無法調度的 Pod 上進行調度。如果你的集群啟用了?自動縮放，使用調度門不僅可以減輕調度器的負擔，還可以節省成本。沒有調度門，自動縮放器可能會啟動不需要啟動的節點。

在 Kubernetes v1.30 中，通過指定（或刪除）Pod 的.spec.schedulingGates，你可以控制何時可以考慮將 Pod 調度。這個穩定的功能現已正式成為 Kubernetes API 的一部分。

6.PodTopologySpread 中的最小域數（SIG Scheduling）

PodTopologySpread 的 minDomains 參數在此版本中升級為穩定版，允許你定義最小的域數。此功能設計用于與集群自動縮放器一起使用。

如果你之前嘗試使用該功能，但沒有足夠的域存在，那么 Pod 將被標記為無法調度。然后，集群自動縮放器將在新的域中提供節點，并最終使 Pod 在足夠的域中進行分布。

7.k/k 中的 Go 工作區（SIG Architecture)）

Kubernetes 倉庫現在采用了 Go 工作區。對最終用戶而言，這不會產生任何影響，但對于下游項目的開發人員來說有一定影響。切換到工作區會導致一些 ?k8s.io/code-generator 工具的標志發生變化。下游使用者可以查看 ?staging/src/k8s.io/code-generator/kube_codegen.sh 文件以了解這些變化。

8.Kubernetes v1.30 中升級到測試版的改進

這些是在 v1.30 發布后成為測試版的一些改進功能的選擇。

9.節點日志查詢（Windows SIG Scheduling）

為了幫助調試節點上的問題，Kubernetes v1.27 引入了一個功能，允許獲取運行在節點上的服務的日志。要使用此功能，請確保已啟用節點上的 NodeLogQuery 功能門，并將 kubelet 配置選項 enableSystemLogHandler 和 enableSystemLogQuery 都設置為 true。

在 1.30 版本之后，現在是測試版(不過，您仍然需要啟用該特性才能使用它)。

在 Linux 上，假設是可以通過 journald 獲取服務日志。在 Windows 上，假設是可以在應用程序日志提供程序中獲取服務日志。你還可以通過讀取 /var/log/（Linux）或 C:\var\log\（Windows）中的文件來獲取日志。有關更多信息，請參閱?日志查詢文檔。

10.CRD 驗證棘輪（SIG API Machinery）

為了使用此功能，你需要啟用 CRDValidationRatcheting 功能門，然后該行為將應用于集群中的所有 CustomResourceDefinitions。

一旦啟用了功能門，Kubernetes 將對 CustomResourceDefinitions 實施驗證棘輪。API 服務器將接受對已更新但不再有效的資源的更新，前提是更新操作未更改未通過驗證的資源的任何部分。換句話說，任何仍然無效的資源的無效部分必須已經是錯誤的。你不能使用此機制將有效的資源更新為無效的資源。

此功能允許 CRD 的作者在特定條件下自信地向 OpenAPIV3 模式添加新的驗證。用戶可以安全地更新到新的模式，而無需增加對象的版本或破壞工作流程。

11.上下文日志記錄（SIG Instrumentation）

在這個版本中，上下文日志記錄升級為測試版，為開發人員和運維人員提供了將可定制、可關聯的上下文詳細信息（如服務名稱和事務 ID）注入日志的能力，通過 WithValues 和 WithName 方法實現。這一改進簡化了跨分布式系統的日志數據關聯和分析，顯著提高了故障排除的效率。通過更清晰地了解你的 Kubernetes 環境的工作原理，上下文日志記錄確保操作挑戰更易管理，標志著 Kubernetes 可觀察性的重要進展。

12.使 Kubernetes 了解負載均衡行為（SIG Network）

LoadBalancerIPMode 功能標志現已升級為測試版，并且默認啟用。這個功能允許你為類型為 LoadBalancer 的服務設置 .status.loadBalancer.ingress.ipMode 屬性，以指定負載均衡器 IP 的行為方式。只有在同時指定了 .status.loadBalancer.ingress.ip 字段時，才能指定 .ipMode。有關指定負載均衡器狀態的 IPMode 的更多詳細信息，請參?閱相關文檔。

新的 alpha 功能

加速遞歸 SELinux 標簽更改（SIG Storage） 從 v1.27 版本開始，Kubernetes 已經包含了一個優化功能，可以在卷的內容上設置 SELinux 標簽，只需恒定的時間。Kubernetes 通過一個掛載選項實現了這個加速。較慢的舊行為要求容器運行時遞歸遍歷整個卷，并為每個文件和目錄單獨應用 SELinux 標簽；這在具有大量文件和目錄的卷中尤為明顯。

Kubernetes 1.27 將這個功能升級為測試版，但僅限于 ReadWriteOncePod 卷。相應的功能門是 SELinuxMountReadWriteOncePod。它仍然默認啟用，并將在 1.30 中保持測試版。

Kubernetes 1.30 將擴展對 SELinux 掛載選項的支持到所有卷，并將其設為 alpha 版本，使用單獨的功能門 SELinuxMount。當具有不同 SELinux 標簽的多個 Pod 共享同一個卷時，此功能門引入了行為上的變化。詳細信息請參閱 ?KEP。

要在所有卷上測試此功能，必須同時啟用 SELinuxMountReadWriteOncePod 和 SELinuxMount 兩個功能門。

此功能對于 Windows 節點或沒有 SELinux 支持的 Linux 節點沒有影響。

1.遞歸只讀（RRO）掛載（SIG Node）

在此版本中，引入了遞歸只讀（RRO）掛載的 alpha 版本，為你的數據提供了一個新的安全層。此功能允許你將卷及其子掛載設置為只讀，以防止意外修改。想象一下部署關鍵應用程序的情況，其中數據完整性至關重要——RRO Mounts 可以確保你的數據保持不變，通過額外的保護措施加強了集群的安全性。在嚴格受控的環境中，即使是微小的更改也可能產生重大影響，因此這一點尤為重要。

2.作業成功/完成策略（SIG Apps）

從 Kubernetes v1.30 開始，索引作業支持 .spec.successPolicy 屬性，以根據成功的 Pod 來定義何時聲明作業成功。這允許你定義兩種類型的標準：

• succeededIndexes 指示當這些索引成功時，作業可以被聲明為成功，即使其他索引失敗。
• succeededCount 指示當成功索引的數量達到此標準時，作業可以被聲明為成功。在作業滿足成功策略后，作業控制器會終止懸掛的 Pods。

3.服務流量分配（SIG Network）

Kubernetes v1.30 引入了服務的流量分配功能（spec.trafficDistribution），目前處于 alpha 版本。這個新功能允許你定義流量路由到服務端點的偏好。雖然?流量策略主要關注語義保證，但流量分配允許你表達偏好，例如將流量路由到更接近客戶端拓撲的端點。這有助于優化性能、成本或可靠性。要使用此功能，請啟用集群和所有節點上的 ServiceTrafficDistribution 功能門。在 Kubernetes v1.30 中，支持以下字段值：

PreferClose：表示偏好將流量路由到與客戶端拓撲更接近的端點。"拓撲更接近"的具體定義可能因實現而異，可能包括同一節點、機架、區域甚至地理位置內的端點。設置此值即賦予實現在不同權衡之間進行選擇的權力，例如優化接近性而不是均勻分布負載。如果不接受這種權衡，請不要設置此值。

如果未設置該字段，實現（如 kube-proxy）將應用其默認的路由策略。

Kubernetes v1.30 的升級、棄用和移除

升級至穩定版 以下是升級至穩定版（也稱為正式發布版）的所有功能列表。有關包括新功能和從 alpha 到 beta 的升級的完整更新列表，請查閱發布說明。

此版本包含了共 17 個功能的升級至穩定版：

• 基于容器資源的 Pod 自動伸縮：https://kep.k8s.io/1610
• 刪除云控制器管理器（KCCM）中的臨時節點謂詞：https://kep.k8s.io/3458
• k/k 采用 Go 的 workspace 架構：https://kep.k8s.io/4402
• 減少基于 Secret 的 ServiceAccount 令牌：https://kep.k8s.io/2799
• 用于準入控制的 CEL：https://kep.k8s.io/3488
• 基于 CEL 的準入控制的匹配條件：https://kep.k8s.io/3716
• Pod 調度準備就緒：https://kep.k8s.io/3521
• PodTopologySpread 中的最小域：https://kep.k8s.io/3022
• 阻止在卷恢復期間發生未授權的卷模式轉換：https://kep.k8s.io/3141
• API Server 鏈路追蹤：https://kep.k8s.io/647
• 云上雙棧 - -- node - ip 的處理：https://kep.k8s.io/3705
• AppArmor 支持：https://kep.k8s.io/24
• kubelet 重啟后穩定重建 VolumeManager：https://kep.k8s.io/3756
• kubectl 交互式刪除：https://kep.k8s.io/3895
• 指標基準配置：https://kep.k8s.io/2305
• 為 Pod 添加 status.hostIPs 字段：https://kep.k8s.io/2681
• 聚合資源 API 發現：https://kep.k8s.io/3352

棄用和移除：

• 自 v1.27 版本起，已移除對 SecurityContextDeny 準入插件的支持，并標記為棄用。（SIG Auth、SIG Security 和 SIG Testing）
• 隨著 SecurityContextDeny 準入插件的移除，建議使用自 v1.25 版本起可用的 Pod Security Admission 插件。

發布說明

請查看我們的?發布說明，了解 Kubernetes 1.30 版本的完整詳情。

可用性

Kubernetes 1.30 可在?GitHub上下載。要開始使用 Kubernetes，請參考交?互式教程或使用?minikube在本地運行 Kubernetes 集群。你還可以使用?kubeadm輕松安裝 1.30 版本。

發布團隊

Kubernetes 的存在離不開社區的支持、承諾和辛勤工作。每個發布團隊都由專注的社區志愿者組成，他們共同努力構建你所依賴的 Kubernetes 版本的眾多部分。這需要來自社區各個角落的人們的專業技能，從代碼本身到文檔和項目管理。

我們要感謝整個發布團隊為將 Kubernetes v1.30 版本交付給我們的社區所做的辛勤工作。發布團隊的成員由經歷過多個發布周期的首次參與者到經驗豐富的團隊負責人組成。我們特別要感謝我們的發布負責人 Kat Cosgrove，他在成功的發布周期中給予我們支持、代表我們發聲，并確保我們以最佳方式做出貢獻，并推動我們改進發布流程。

項目速度

CNCF K8s DevStats 項目總結了與 Kubernetes 及其子項目的開發速度有關的許多有趣數據。這包括個人貢獻和參與貢獻的公司數量等信息，展示了推進這個生態系統所付出的努力的廣泛和深度。

在為期 14 周的 v1.30 發布周期（2024 年 1 月 8 日至 4 月 17 日）中，我們收到了來自?863 家公司和?1391 位個人的貢獻。

參考文章

• Kubernetes 增強特性：https://kep.k8s.io/
• Kubernetes 1.30 發布團隊：https://github.com/kubernetes/sig-release/blob/master/releases/release-1.30
• Kubernetes 1.30 變更日志：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md
• Kubernetes 1.30 主題討論：kubernetes/sig-release#2424