Kubernetes v1.30:Uwubernetes
編輯:Amit Dsouza、Frederick Kautz、Kristin Martin、Abigail McCarthy、Natali Vlatko
公告 Kubernetes v1.30 版本:Uwubernetes,最可愛的版本!
與之前的版本類似,Kubernetes v1.30 版本的發佈引入了新的穩定、Beta 和 Alpha 功能。頂級版本的持續交付突顯了我們開發週期的實力和社群的蓬勃發展支持。
此版本包含 45 項增強功能。在這些增強功能中,有 17 項已升級為穩定版,18 項進入 Beta 版,10 項已升級為 Alpha 版。
發佈主題和標誌
Kubernetes v1.30:Uwubernetes

Kubernetes v1.30 讓您的叢集更可愛!
Kubernetes 由來自世界各地、各行各業的數千人建構和發佈。大多數貢獻者並未因此獲得報酬;我們建構它只是為了好玩、解決問題、學習新事物,或單純地為了熱愛社群。我們許多人在這裡找到了歸宿、朋友和事業。發佈團隊很榮幸能成為 Kubernetes 持續成長的一份子。
為了建構它的人們、發佈它的人們,以及為了讓所有叢集保持在線的毛茸茸朋友們,我們向您呈現 Kubernetes v1.30:Uwubernetes,迄今為止最可愛的版本。這個名稱是「kubernetes」和「UwU」的混成詞,「UwU」是一種表情符號,用於表示快樂或可愛。我們在這裡找到了快樂,但我們也從外部生活中帶來了快樂,這有助於使這個社群變得如此古怪、美好和熱情。我們很高興與您分享我們的成果。
UwU ♥️
Kubernetes v1.30 中升級為穩定的改進
以下是 v1.30 版本發佈後,現已穩定的一些改進的選集。
kubelet 重新啟動後穩健的 VolumeManager 重建 (SIG Storage)
這是一個磁碟區管理員重構,允許 kubelet 在 kubelet 啟動期間填入關於現有磁碟區如何掛載的其他資訊。總體而言,這使得 kubelet 重新啟動或機器重新啟動後的磁碟區清理更加穩健。
這不會為使用者或叢集管理員帶來任何變更。我們使用了功能流程和功能閘道 NewVolumeManagerReconstruction
,以便在出現問題時能夠回退到先前的行為。現在該功能已穩定,功能閘道已鎖定且無法停用。
防止在磁碟區還原期間未經授權的磁碟區模式轉換 (SIG Storage)
對於 Kubernetes v1.30,當將快照還原到 PersistentVolume 時,控制平面始終會防止未經授權變更磁碟區模式。作為叢集管理員,如果您需要允許在還原時進行此類變更,則需要向適當的身份主體 (例如:代表儲存整合的 ServiceAccount) 授予權限。
警告
升級前需要採取行動。prevent-volume-mode-conversion
功能旗標在 external-provisioner v4.0.0
和 external-snapshotter v7.0.0
中預設為啟用。除非您執行 external-provisioner 4.0.0 和 external-snapshotter v7.0.0 的「緊急升級注意事項」章節中描述的步驟,否則從 VolumeSnapshot 建立 PVC 時,將會拒絕磁碟區模式變更。如需此功能的更多資訊,另請參閱轉換快照的磁碟區模式。
Pod 排程就緒狀態 (SIG Scheduling)
Pod 排程就緒狀態在此版本中升級為穩定版,在 Kubernetes v1.27 中升級為 Beta 版之後。
這個現已穩定的功能讓 Kubernetes 避免在叢集尚未佈建資源以實際將 Pod 繫結到節點時,嘗試排程已定義的 Pod。這不是唯一的使用案例;對是否允許排程 Pod 的自訂控制,也讓您可以實作配額機制、安全控制等等。
至關重要的是,將這些 Pod 標記為免於排程,減少了排程器原本會執行的工作,即處理無法或不會排程到您叢集目前擁有的節點上的 Pod。如果您啟用了叢集自動擴展,則使用排程閘道不僅可以減少排程器的負載,還可以省錢。如果沒有排程閘道,自動擴展器可能會啟動一個不需要啟動的節點。
在 Kubernetes v1.30 中,透過指定 (或移除) Pod 的 .spec.schedulingGates
,您可以控制 Pod 何時準備好被視為可排程。這是一項穩定功能,現在已正式成為 Pod 的 Kubernetes API 定義的一部分。
PodTopologySpread 中的最小網域數 (SIG Scheduling)
PodTopologySpread 限制的 minDomains
參數在此版本中升級為穩定版,這讓您可以定義最小網域數。此功能旨在與叢集自動擴展器搭配使用。
如果您先前嘗試使用且沒有足夠的網域已存在,則 Pod 會被標記為不可排程。然後,叢集自動擴展器將在新網域中佈建節點,您最終會讓 Pod 分散到足夠的網域上。
k/k 的 Go 工作區 (SIG Architecture)
Kubernetes 儲存庫現在使用 Go 工作區。這應該完全不會影響終端使用者,但確實會對下游專案的開發人員產生影響。切換到工作區導致各種 k8s.io/code-generator 工具的旗標發生一些重大變更。下游消費者應查看 staging/src/k8s.io/code-generator/kube_codegen.sh
以查看變更。
如需關於 Go 工作區的變更和引入原因的完整詳細資訊,請閱讀 在 Kubernetes 中使用 Go 工作區。
Kubernetes v1.30 中升級為 Beta 版的改進
以下是 v1.30 版本發佈後,現已成為 Beta 版的一些改進的選集。
節點記錄查詢 (SIG Windows)
為了協助偵錯節點上的問題,Kubernetes v1.27 引入了一項功能,允許擷取在節點上執行的服務記錄。若要使用此功能,請確保為該節點啟用 NodeLogQuery
功能閘道,並且 kubelet 組態選項 enableSystemLogHandler
和 enableSystemLogQuery
都設定為 true。
在 v1.30 版本發佈後,這現在是 Beta 版 (不過您仍然需要啟用該功能才能使用它)。
在 Linux 上,假設服務記錄可透過 journald 取得。在 Windows 上,假設服務記錄可在應用程式記錄提供者中取得。記錄也可以透過讀取 /var/log/
(Linux) 或 C:\var\log\
(Windows) 中的檔案取得。如需更多資訊,請參閱記錄查詢文件。
CRD 驗證棘輪機制 (SIG API Machinery)
您需要啟用 CRDValidationRatcheting
功能閘道 才能使用此行為,然後該行為將套用至您叢集中的所有 CustomResourceDefinition。
如果您啟用了功能閘道,Kubernetes 會為 CustomResourceDefinition 實作驗證棘輪機制。API 伺服器願意接受對資源的更新,這些資源在更新後無效,前提是資源中每個驗證失敗的部分在更新操作中沒有變更。換句話說,資源中任何保持無效的無效部分必定已經是錯誤的。您不能使用此機制更新有效的資源,使其變為無效。
此功能允許 CRD 的作者在特定條件下,放心地將新的驗證新增至 OpenAPIV3 結構描述。使用者可以安全地更新至新的結構描述,而無需跳轉物件版本或中斷工作流程。
情境記錄 (SIG Instrumentation)
情境記錄在此版本中推進到 Beta 版,讓開發人員和營運商能夠透過 WithValues
和 WithName
將可自訂、可關聯的情境詳細資訊 (例如服務名稱和交易 ID) 注入到記錄中。此增強功能簡化了分散式系統中記錄資料的關聯和分析,顯著提高了疑難排解工作的效率。透過更清楚地了解您的 Kubernetes 環境的運作方式,情境記錄確保營運挑戰更易於管理,標誌著 Kubernetes 可觀測性方面向前邁進了一大步。
讓 Kubernetes 了解 LoadBalancer 行為 (SIG Network)
LoadBalancerIPMode
功能閘道現在是 Beta 版,並且預設為啟用。此功能允許您為 type
設定為 LoadBalancer
的 Service 設定 .status.loadBalancer.ingress.ipMode
。.status.loadBalancer.ingress.ipMode
指定負載平衡器 IP 的行為方式。只有在同時指定 .status.loadBalancer.ingress.ip
欄位時,才能指定此欄位。請參閱關於指定負載平衡器狀態的 IPMode的更多詳細資訊。
結構化驗證組態 (SIG Auth)
結構化驗證組態在此版本中升級為 Beta 版。
Kubernetes 長期以來一直需要更靈活且可擴展的驗證系統。目前的系統雖然功能強大,但仍存在一些限制,使其在某些情況下難以使用。例如,無法使用相同類型的多個驗證器 (例如,多個 JWT 驗證器),或在不重新啟動 API 伺服器的情況下變更組態。結構化驗證組態功能是解決這些限制並提供更靈活且可擴展的方式來組態 Kubernetes 中的驗證的第一步。請參閱關於結構化驗證組態的更多詳細資訊。
結構化授權組態 (SIG Auth)
結構化授權組態在此版本中升級為 Beta 版。
Kubernetes 持續發展以滿足系統管理員和開發人員的複雜需求。確保叢集安全性和完整性的 Kubernetes 的一個關鍵方面是 API 伺服器授權。直到最近,kube-apiserver 中授權鏈的組態仍然有些僵化,僅限於一組命令列旗標,並且在授權鏈中僅允許單一 webhook。這種方法雖然有效,但限制了叢集管理員定義複雜、精細授權策略所需的彈性。最新的結構化授權組態功能旨在透過引入更結構化和通用的方式來組態授權鏈,從而徹底改變這方面,重點是啟用多個 webhook 並提供明確的控制機制。請參閱關於結構化授權組態的更多詳細資訊。
新的 Alpha 功能
加速遞迴 SELinux 標籤變更 (SIG Storage)
從 v1.27 版本開始,Kubernetes 已經包含一個最佳化,僅使用恆定時間在磁碟區內容上設定 SELinux 標籤。Kubernetes 透過使用掛載選項來實現該加速。較慢的舊版行為需要容器執行階段遞迴地遍歷整個磁碟區,並個別將 SELinux 標籤套用至每個檔案和目錄;對於包含大量檔案和目錄的磁碟區,這尤其明顯。
Kubernetes v1.27 將此功能升級為 Beta 版,但將其限制為 ReadWriteOncePod 磁碟區。對應的功能閘道為 SELinuxMountReadWriteOncePod
。它仍然預設為啟用,並且在 v1.30 中仍然是 Beta 版。
Kubernetes v1.30 將 SELinux 掛載選項的支援擴展到所有磁碟區,作為 Alpha 版,並具有單獨的功能閘道:SELinuxMount
。當具有不同 SELinux 標籤的多個 Pod 共用同一個磁碟區時,此功能閘道會引入行為變更。請參閱 KEP 以了解詳細資訊。
我們強烈建議在啟用 SELinux 的情況下執行 Kubernetes 的使用者測試此功能,並在 KEP 問題上提供任何意見回饋。
功能閘道 | v1.30 中的階段 | 行為變更 |
---|---|---|
SELinuxMountReadWriteOncePod | Beta | 否 |
SELinuxMount | Alpha | 是 |
必須同時啟用 SELinuxMountReadWriteOncePod
和 SELinuxMount
功能閘道,才能在所有磁碟區上測試此功能。
此功能對 Windows 節點或沒有 SELinux 支援的 Linux 節點沒有影響。
遞迴唯讀 (RRO) 掛載 (SIG Node)
在此版本中推出 Alpha 版的遞迴唯讀 (RRO) 掛載,您會發現資料安全性的新層級。此功能讓您可以將磁碟區及其子掛載設定為唯讀,防止意外修改。想像一下部署一個資料完整性至關重要的關鍵應用程式 — RRO 掛載確保您的資料保持原樣,並透過額外的安全防護來加強叢集的安全性。這在嚴格控制的環境中尤其重要,在這些環境中,即使是最輕微的變更也可能產生重大影響。
Job 成功/完成政策 (SIG Apps)
從 Kubernetes v1.30 開始,索引 Job 支援 .spec.successPolicy
,以定義何時可以根據成功的 Pod 宣告 Job 成功。這讓您可以定義兩種準則類型
succeededIndexes
表示當這些索引成功時,即使其他索引失敗,也可以宣告 Job 成功。succeededCount
表示當成功索引的數量達到此準則時,可以宣告 Job 成功。
在 Job 滿足成功政策後,Job 控制器會終止持續存在的 Pod。
服務的流量分配 (SIG Network)
Kubernetes v1.30 在 Kubernetes Service 中引入了 spec.trafficDistribution
欄位作為 Alpha 版。這讓您可以表達如何將流量路由到服務端點的偏好。雖然 流量政策 側重於嚴格的語意保證,但流量分配允許您表達偏好 (例如,路由到拓撲上更接近的端點)。這有助於最佳化效能、成本或可靠性。您可以透過為您的叢集及其所有節點啟用 ServiceTrafficDistribution
功能閘道來使用此欄位。在 Kubernetes v1.30 中,支援以下欄位值
PreferClose
:表示偏好將流量路由到拓撲上靠近用戶端的端點。「拓撲上靠近」的解釋可能因實作而異,並且可能包含相同節點、機架、區域甚至區域內的端點。設定此值會授予實作權限以進行不同的權衡,例如最佳化接近度而不是負載的平均分配。如果無法接受此類權衡,則不應設定此值。
如果未設定該欄位,則實作 (例如 kube-proxy) 將套用其預設路由策略。
請參閱 流量分配 以了解更多詳細資訊。
儲存版本遷移 (SIG API Machinery)
Kubernetes v1.30 引入了一個新的內建 API 用於儲存版本遷移。Kubernetes 依賴於主動重寫的 API 資料,以支援與靜態儲存相關的一些維護活動。兩個突出的範例是儲存資源的版本化結構描述 (也就是說,給定資源的慣用儲存結構描述從 v1 變更為 v2) 和靜態加密 (也就是說,根據資料應加密方式的變更來重寫過時的資料)。
StorageVersionMigration 是 Alpha API,之前在 樹狀結構外 可用。
請參閱 儲存版本遷移 以了解更多詳細資訊。
Kubernetes v1.30 的升級、棄用和移除
升級為穩定版
這列出了所有升級為穩定版 (也稱為正式發佈) 的功能。如需包含從 Alpha 版升級到 Beta 版的新功能和升級的完整更新清單,請參閱 發行說明。
此版本總共包含 17 項升級為穩定版的增強功能
- 基於容器資源的 Pod 自動擴展
- 從 KCCM 的服務控制器中移除暫時節點謂詞
- k/k 的 Go 工作區
- 減少基於 Secret 的服務帳戶權杖
- 用於允許控制的 CEL
- 基於 CEL 的允許 webhook 比對條件
- Pod 排程就緒狀態
- PodTopologySpread 中的最小網域數
- 防止在磁碟區還原期間未經授權的磁碟區模式轉換
- API 伺服器追蹤
- 雲端雙堆疊 --node-ip 處理
- AppArmor 支援
- kubelet 重新啟動後穩健的 VolumeManager 重建
- kubectl delete:新增互動式 (-i) 旗標
- 指標基數強制執行
- 為 Pod 新增欄位
status.hostIPs
- 彙總探索
棄用和移除
移除了 SecurityContextDeny 允許外掛程式,自 v1.27 起已棄用
(SIG Auth、SIG Security 和 SIG Testing) 隨著 SecurityContextDeny 允許外掛程式的移除,建議改用自 v1.25 起可用的 Pod 安全允許外掛程式。
發行說明
請在我們的 發行說明 中查看 Kubernetes v1.30 發行的完整詳細資訊。
可用性
Kubernetes v1.30 可在 GitHub 上下載。若要開始使用 Kubernetes,請查看這些互動式教學課程,或使用 minikube 執行本機 Kubernetes 叢集。您也可以使用 kubeadm 輕鬆安裝 v1.30。
發佈團隊
Kubernetes 的成功僅可能來自其社群的支持、投入和辛勤工作。每個發佈團隊都由敬業的社群志工組成,他們共同努力建構組成您所依賴的 Kubernetes 發行的許多部分。這需要來自我們社群各個角落的人員的專業技能,從程式碼本身到其文件和專案管理。
我們要感謝整個 發佈團隊 花費數小時努力工作,向我們的社群交付 Kubernetes v1.30 版本。發佈團隊的成員資格範圍從首次參與的見習生到經驗豐富的回歸團隊負責人,他們的經驗是在多個發佈週期中累積的。非常感謝我們的發佈負責人 Kat Cosgrove,感謝她在成功的發佈週期中支持我們、為我們發聲、確保我們都能以最佳方式做出貢獻,並挑戰我們改進發佈流程。
專案速度
CNCF K8s DevStats 專案彙總了許多與 Kubernetes 和各種子專案的速度相關的有趣資料點。這包括從個人貢獻到正在做出貢獻的公司數量的一切,並且說明了投入發展這個生態系統的努力的深度和廣度。
在 v1.30 發佈週期 (從 1 月 8 日到 4 月 17 日,為期 14 週) 中,我們看到了來自 863 家公司 和 1391 位個人 的貢獻。
活動更新
- KubeCon + CloudNativeCon China 2024 將於 2024 年 8 月 21 日至 23 日在香港舉行!您可以在 活動網站上找到有關會議和註冊的更多資訊。
- KubeCon + CloudNativeCon North America 2024 將於 2024 年 11 月 12 日至 15 日在美利堅合眾國猶他州鹽湖城舉行!您可以在 活動網站上找到有關會議和註冊的更多資訊。
即將舉行的版本網路研討會
加入 Kubernetes v1.30 發佈團隊成員於 2024 年 5 月 23 日星期四上午 9 點 (太平洋時間) 舉行的會議,以了解此版本的主要功能,以及有助於規劃升級的棄用和移除。如需更多資訊和註冊,請造訪 CNCF 線上計畫網站上的 活動頁面。
參與其中
參與 Kubernetes 最簡單的方式是加入與您的興趣一致的眾多特殊興趣小組 (SIG) 之一。有想要向 Kubernetes 社群廣播的內容嗎?在我們的每週社群會議以及透過以下管道分享您的聲音。感謝您持續的意見回饋和支持。
- 在 𝕏 上關注我們 @Kubernetesio 以取得最新更新
- 加入 Discuss 上的社群討論
- 在 Slack 上加入社群
- 在 Stack Overflow 上發佈問題 (或回答問題)
- 分享您的 Kubernetes 故事
- 在 部落格 上深入了解 Kubernetes 的最新動態
- 深入了解 Kubernetes 發佈團隊
此部落格已於 2024 年 4 月 19 日更新,以重點介紹最初未包含在發佈部落格中的兩個額外變更。