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

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

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

發(fā)布主題和標志

1.Kubernetes v1.30: Uwubernetes

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

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

對于那些為它做出貢獻的人，對于那些發(fā)布它的人，以及對于那些保持我們所有集群在線的人，我們呈現(xiàn) Kubernetes v1.30: Uwubernetes，這是迄今為止最可愛的版本。這個名稱是“kubernetes”和“UwU”（一種表示幸福或可愛的表情符號）的結合。我們在這里找到了快樂，并將外部生活的快樂帶到這里，使這個社區(qū)變得如此獨特、美妙和充滿激情。我們非常高興能與你分享我們的工作。

2.在 Kubernetes v1.30 中升級為穩(wěn)定版的改進功能

以下是在 v1.30 版本發(fā)布后現(xiàn)在已穩(wěn)定的一些改進功能的選擇。

3.kubelet 重啟后穩(wěn)健的 VolumeManager 重建（SIG Storage）

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

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

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

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

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

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

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

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

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

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

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

6.PodTopologySpread 中的最小域數(shù)（SIG Scheduling）

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

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

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

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

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

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

9.節(jié)點日志查詢（Windows SIG Scheduling）

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

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

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

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

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

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

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

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

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

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

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

新的 alpha 功能

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

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

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

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

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

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

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

2.作業(yè)成功/完成策略（SIG Apps）

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

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

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

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

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

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

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

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

此版本包含了共 17 個功能的升級至穩(wěn)定版：

• 基于容器資源的 Pod 自動伸縮：https://kep.k8s.io/1610
• 刪除云控制器管理器（KCCM）中的臨時節(jié)點謂詞：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
• 阻止在卷恢復期間發(fā)生未授權的卷模式轉換：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 重啟后穩(wěn)定重建 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 發(fā)現(xiàn)：https://kep.k8s.io/3352

棄用和移除：

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

發(fā)布說明

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

可用性

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

發(fā)布團隊

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

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

項目速度

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

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

參考文章

• Kubernetes 增強特性：https://kep.k8s.io/
• Kubernetes 1.30 發(fā)布團隊：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