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

Kubernetes v1.31: Elli

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

編輯：Matteo Bianchi、Yigit Demirbas、Abigail McCarthy、Edith Puclla、Rashan Smith

宣佈 Kubernetes v1.31 版本釋出：Elli！

與之前的版本類似，Kubernetes v1.31 引入了新的 Stable、Beta 和 Alpha 特性。高質量版本的持續交付凸顯了我們開發週期的實力以及我們社群的活躍支援。此版本包含 45 項增強功能。其中，11 項已進階至 Stable，22 項進入 Beta，12 項進階至 Alpha。

Kubernetes v1.31 版本的釋出主題是 “Elli”。

Kubernetes v1.31 的 Elli 是一隻可愛快樂的狗，有一顆金子般的心，戴著一頂漂亮的水手帽，這是對 Kubernetes 龐大而多元的貢獻者家庭的一個俏皮的致意。

Kubernetes v1.31 標誌著該專案成功慶祝其第一個 10 年後的首次釋出。自誕生以來，Kubernetes 已經走過了很長的路，並且每個版本仍在朝著令人興奮的新方向發展。10 年後，回顧無數 Kubernetes 貢獻者的努力、奉獻、技能、智慧和辛勤工作，他們使這一切成為現實，這令人敬畏。

然而，儘管執行該專案需要巨大的努力，但仍不乏一次又一次地以熱情、微笑和為社群做出貢獻和成為其中一員的自豪感出現的人。我們從新老貢獻者身上看到的這種“精神”是一個充滿活力的社群的標誌，如果我們願意的話，可以稱之為“快樂”的社群。

Kubernetes v1.31 的 Elli 就是為了慶祝這種美妙的精神！為 Kubernetes 的下一個十年乾杯！

進入 Stable 階段的特性亮點

以下是 v1.31 版本釋出後進入 Stable 階段的一些改進。

AppArmor 支援進入 Stable

Kubernetes 對 AppArmor 的支援現已進入正式釋出（GA）階段。透過在容器的 securityContext 中設定 appArmorProfile.type 欄位，使用 AppArmor 保護你的容器。請注意，在 Kubernetes v1.30 之前，AppArmor 是透過註解控制的；從 v1.30 開始，它透過欄位進行控制。建議你從使用註解遷移到使用 appArmorProfile.type 欄位。

要了解更多資訊，請閱讀 AppArmor 教程。這項工作是 KEP #24 的一部分，由 SIG Node 完成。

提高 kube-proxy 的 Ingress 連線可靠性

Kube-proxy 提高 Ingress 連線可靠性的功能在 v1.31 中進入 Stable 階段。Kubernetes 中負載均衡器的一個常見問題是不同元件之間的同步，以避免流量中斷。該功能在 kube-proxy 中實現了一種機制，供負載均衡器為 type: LoadBalancer 和 externalTrafficPolicy: Cluster 型別的 Service 所暴露的終止節點執行連線排空，併為雲提供商和 Kubernetes 負載均衡器實現建立了一些最佳實踐。

要使用此功能，kube-proxy 需要作為叢集上的預設 Service 代理執行，並且負載均衡器需要支援連線排空。使用此功能無需特殊更改，自 v1.30 起，它在 kube-proxy 中預設啟用，並在 v1.31 中進階至 Stable。

有關此功能的更多詳細資訊，請訪問虛擬 IP 和服務代理文件頁面。

這項工作是 KEP #3836 的一部分，由 SIG Network 完成。

PersistentVolume 的最後階段轉換時間

PersistentVolume 的最後階段轉換時間功能在 v1.31 中進階至 GA。此功能添加了一個 PersistentVolumeStatus 欄位，用於儲存 PersistentVolume 上次轉換到不同階段的時間戳。啟用此功能後，每個 PersistentVolume 物件都會有一個新欄位 .status.lastTransitionTime，用於儲存捲上次轉換階段的時間戳。此更改不是立即生效的；升級到 Kubernetes v1.31 後，當 PersistentVolume 更新並首次在階段（Pending、Bound 或 Released）之間轉換時，將填充新欄位。這使你能夠測量 PersistentVolume 從 Pending 移動到 Bound 之間的時間。這對於提供指標和 SLO 也很有用。

有關此功能的更多詳細資訊，請訪問PersistentVolume 文件頁面。

這項工作是 KEP #3762 的一部分，由 SIG Storage 完成。

進入 Beta 階段的特性亮點

以下是 v1.31 版本釋出後進入 Beta 階段的一些改進。

kube-proxy 的 nftables 後端

nftables 後端在 v1.31 中進入 Beta 階段，受 NFTablesProxyMode 特性門控保護，該門控現已預設啟用。

nftables API 是 iptables API 的後繼者，旨在提供比 iptables 更好的效能和可伸縮性。nftables 代理模式能夠比 iptables 模式更快、更高效地處理 Service 端點的更改，並且還能在核心中更高效地處理資料包（儘管這隻有在具有數萬個 Service 的叢集中才變得明顯）。

截至 Kubernetes v1.31，nftables 模式仍然相對較新，可能與所有網路外掛不相容；請查閱你的網路外掛的文件。此代理模式僅在 Linux 節點上可用，並且需要核心 5.13 或更高版本。在遷移之前，請注意某些功能，特別是圍繞 NodePort Service 的功能，在 nftables 模式下的實現與在 iptables 模式下的實現不完全相同。請檢視遷移指南，瞭解是否需要覆蓋預設配置。

這項工作是 KEP #3866 的一部分，由 SIG Network 完成。

PersistentVolume 回收策略的更改

“始終遵守 PersistentVolume 回收策略”功能已在 Kubernetes v1.31 中進階至 Beta。此增強功能確保即使在關聯的 PersistentVolumeClaim（PVC）被刪除後，PersistentVolume（PV）的回收策略也能得到遵守，從而防止卷洩漏。

在此功能之前，與 PV 關聯的回收策略可能會在特定條件下被忽略，具體取決於 PV 或 PVC 是否先被刪除。因此，即使回收策略設定為“Delete”，外部基礎架構中相應的儲存資源也可能不會被刪除。這導致了潛在的不一致性和資源洩漏。

隨著此功能的引入，Kubernetes 現在保證“Delete”回收策略將被強制執行，確保從後端基礎架構中刪除底層儲存物件，無論 PV 和 PVC 的刪除順序如何。

這項工作是 KEP #2644 的一部分，由 SIG Storage 完成。

繫結的 Service Account 令牌改進

ServiceAccountTokenNodeBinding 功能在 v1.31 中進階至 Beta。此功能允許請求僅繫結到節點而不繫結到 Pod 的令牌，這在令牌的宣告中包含節點資訊，並在使用令牌時驗證節點的存在。有關更多資訊，請閱讀繫結服務帳戶令牌文件。

這項工作是 KEP #4193 的一部分，由 SIG Auth 完成。

多個 Service CIDR

支援具有多個 Service CIDR 的叢集的功能在 v1.31 中進入 Beta 階段（預設停用）。

在 Kubernetes 叢集中，有多個元件消耗 IP 地址：節點、Pod 和 Service。節點和 Pod 的 IP 範圍可以動態更改，因為它們分別取決於基礎設施或網路外掛。然而，Service IP 範圍是在叢集建立期間作為 kube-apiserver 中的硬編碼標誌定義的。IP 耗盡一直是長期執行或大型叢集的問題，因為管理員需要擴充套件、縮小甚至完全替換分配的 Service CIDR 範圍。這些操作從未得到原生支援，並且透過複雜而精細的維護操作執行，通常會導致叢集停機。這項新功能允許使用者和叢集管理員動態修改 Service CIDR 範圍，而不會造成停機。

有關此功能的更多詳細資訊，請訪問虛擬 IP 和服務代理文件頁面。

這項工作是 KEP #1880 的一部分，由 SIG Network 完成。

Service 流量分發

Service 的流量分發在 v1.31 中進入 Beta 階段，並預設啟用。

在為 Service 網路尋找最佳使用者體驗和流量工程能力的多次迭代之後，SIG Networking 在 Service 規範中實現了 trafficDistribution 欄位，該欄位作為底層實現在做出路由決策時考慮的指南。

有關此功能的更多詳細資訊，請閱讀 1.30 釋出部落格或訪問 Service 文件頁面。

這項工作是 KEP #4444 的一部分，由 SIG Network 完成。

Kubernetes VolumeAttributesClass ModifyVolume

VolumeAttributesClass API 在 v1.31 中進入 Beta 階段。VolumeAttributesClass 提供了一個通用的、Kubernetes 原生的 API，用於修改動態卷引數，如已配置的 IO。這允許工作負載線上垂直擴充套件其卷以平衡成本和效能，如果其提供商支援的話。此功能自 Kubernetes 1.29 以來一直處於 Alpha 階段。

這項工作是 KEP #3751 的一部分，由 SIG Storage 領導。

進入 Alpha 階段的新功能

以下是 v1.31 版本釋出後進入 Alpha 階段的一些改進。

新的 DRA API，用於更好的加速器和其他硬體管理

Kubernetes v1.31 帶來了更新的動態資源分配（DRA）API 和設計。更新的主要重點是結構化引數，因為它們使資源資訊和請求對 Kubernetes 和客戶端透明，並能夠實現諸如叢集自動縮放等功能。kubelet 中的 DRA 支援已更新，以便 kubelet 和控制平面之間的版本偏差成為可能。透過結構化引數，排程程式在排程 Pod 時分配 ResourceClaim。透過 DRA 驅動程式控制器進行的分配仍然透過現在稱為“經典 DRA”的方式得到支援。

在 Kubernetes v1.31 中，經典 DRA 有一個單獨的特性門控，名為 DRAControlPlaneController，你需要顯式啟用它。透過這樣的控制平面控制器，DRA 驅動程式可以實現尚不支援透過結構化引數實現的分配策略。

這項工作是 KEP #3063 的一部分，由 SIG Node 完成。

支援映象卷

Kubernetes 社群正朝著未來實現更多人工智慧（AI）和機器學習（ML）用例的方向發展。

滿足這些用例的要求之一是直接支援開放容器倡議（OCI）相容的映象和工件（稱為 OCI 物件）作為原生卷源。這允許使用者專注於 OCI 標準，並使他們能夠使用 OCI 倉庫儲存和分發任何內容。

鑑於此，v1.31 添加了一個新的 Alpha 功能，允許在 Pod 中使用 OCI 映象作為卷。此功能允許使用者在 Pod 中將映象引用指定為卷，同時在容器內將其重用為卷掛載。你需要啟用 ImageVolume 特性門控才能試用此功能。

這項工作是 KEP #4639 的一部分，由 SIG Node 和 SIG Storage 完成。

透過 Pod 狀態暴露裝置健康資訊

透過 Pod 狀態暴露裝置健康資訊作為 v1.31 中的新 Alpha 功能新增，預設停用。

在 Kubernetes v1.31 之前，瞭解 Pod 是否與故障裝置關聯的方法是使用 PodResources API。

啟用此功能後，allocatedResourcesStatus 欄位將新增到每個容器的狀態中，位於每個 Pod 的 .status 內。allocatedResourcesStatus 欄位報告分配給容器的每個裝置的健康資訊。

這項工作是 KEP #4680 的一部分，由 SIG Node 完成。

基於選擇器的更細粒度授權

此功能允許 webhook 授權器和未來的（但目前尚未設計的）樹內授權器允許 list 和 watch 請求，前提是這些請求使用標籤和/或欄位選擇器。例如，現在授權器可以表示：此使用者不能列出所有 Pod，但可以列出 .spec.nodeName 匹配某個特定值的所有 Pod。或者允許使用者監視名稱空間中所有未標記為 confidential: true 的 Secret。結合 CRD 欄位選擇器（也在 v1.31 中進入 Beta），可以編寫更安全的每節點擴充套件。

這項工作是 KEP #4601 的一部分，由 SIG Auth 完成。

對匿名 API 訪問的限制

透過啟用特性門控 AnonymousAuthConfigurableEndpoints，使用者現在可以使用身份驗證配置檔案來配置可由匿名請求訪問的端點。這允許使用者保護自己免受可能給予匿名使用者對叢集廣泛訪問許可權的 RBAC 錯誤配置的影響。

這項工作是 KEP #4633 的一部分，由 SIG Auth 完成。

v1.31 中的進階、棄用和移除

升級為穩定版

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

此版本共包含 11 項進階至 Stable 的增強功能

棄用和移除

隨著 Kubernetes 的發展和成熟，為了專案的整體健康，功能可能會被棄用、移除或替換為更好的功能。有關此過程的更多詳細資訊，請參閱 Kubernetes 棄用和移除策略。

Cgroup v1 進入維護模式

隨著 Kubernetes 不斷發展並適應容器編排不斷變化的格局，社群決定在 v1.31 中將 cgroup v1 支援移入維護模式。這一轉變與更廣泛的行業向 cgroup v2 的轉變相一致，後者提供了改進的功能、可伸縮性和更一致的介面。Kubernetes 維護模式意味著不會向 cgroup v1 支援新增新功能。關鍵的安全修復仍將提供，但是，錯誤修復現在是盡力而為，這意味著如果可行，主要錯誤可能會被修復，但某些問題可能仍未解決。

建議你儘快開始切換到使用 cgroup v2。此轉換取決於你的架構，包括確保底層作業系統和容器執行時支援 cgroup v2，並測試工作負載以驗證工作負載和應用程式在 cgroup v2 下能正常執行。

請透過提交 issue 報告你遇到的任何問題。

這項工作是 KEP #4569 的一部分，由 SIG Node 完成。

關於 SHA-1 簽名支援的說明

在 go1.18 （2022 年 3 月釋出）中，crypto/x509 庫開始拒絕使用 SHA-1 雜湊函式簽名的證書。雖然 SHA-1 已被確定為不安全，並且自 2015 年以來，公共信任的證書頒發機構已不再頒發 SHA-1 證書，但在 Kubernetes 的上下文中，可能仍存在使用者提供的證書透過私有機構使用 SHA-1 雜湊函式簽名並用於聚合 API 伺服器或 webhook 的情況。如果你依賴於基於 SHA-1 的證書，你必須透過在環境中設定 GODEBUG=x509sha1=1 來明確選擇重新支援它。

鑑於 Go 的 GODEBUG 相容性策略，x509sha1 GODEBUG 和對 SHA-1 證書的支援將在 go1.24 中完全取消，該版本將於 2025 年上半年釋出。如果你依賴於 SHA-1 證書，請開始遷移。

請參閱 Kubernetes issue #125689，以更好地瞭解 SHA-1 支援取消的時間表，Kubernetes 版本計劃何時採用 go1.24，以及有關如何透過指標和審計日誌檢測 SHA-1 證書使用情況的更多詳細資訊。

棄用 Node 的 status.nodeInfo.kubeProxyVersion 欄位（KEP 4004）

Node 的 .status.nodeInfo.kubeProxyVersion 欄位已在 Kubernetes v1.31 中棄用，並將在以後的版本中移除。棄用它的原因是因為此欄位的值不準確。此欄位由 kubelet 設定，kubelet 並沒有關於 kube-proxy 版本或 kube-proxy 是否正在執行的可靠資訊。

DisableNodeKubeProxyVersion 特性門控在 v1.31 中將預設設定為 true，kubelet 將不再嘗試為其關聯的 Node 設定 .status.kubeProxyVersion 欄位。

移除所有與雲提供商的樹內整合

正如上一篇文章中所強調的，最後剩餘的對雲提供商整合的樹內支援已作為 v1.31 版本的一部分被移除。這並不意味著你不能與雲提供商整合，但是你現在必須使用推薦的方法，即使用外部整合。一些整合是 Kubernetes 專案的一部分，而另一些是第三方軟體。

這個里程碑標誌著所有云提供商的整合從 Kubernetes 核心（KEP-2395）中外部化過程的完成，這個過程始於 Kubernetes v1.26。這一變化有助於 Kubernetes 更接近成為一個真正的供應商中立平臺。

有關雲提供商整合的更多詳細資訊，請閱讀我們的 v1.29 雲提供商整合功能部落格。有關樹內程式碼移除的更多背景資訊，我們邀請你檢視（v1.29 棄用部落格）。

後一篇部落格還為需要遷移到 v1.29 及更高版本的使用者提供了有用的資訊。

移除樹內提供商特性門控

在 Kubernetes v1.31 中，以下 alpha 特性門控 InTreePluginAWSUnregister、InTreePluginAzureDiskUnregister、InTreePluginAzureFileUnregister、InTreePluginGCEUnregister、InTreePluginOpenStackUnregister 和 InTreePluginvSphereUnregister 已被移除。引入這些特性門控是為了方便測試從程式碼庫中移除樹內卷外掛的場景，而無需實際移除它們。由於 Kubernetes 1.30 已棄用這些樹內卷外掛，這些特性門控是多餘的，不再有任何用途。唯一仍然存在的 CSI 遷移門控是 InTreePluginPortworxUnregister，它將保持在 alpha 階段，直到 Portworx 的 CSI 遷移完成並且其樹內卷外掛準備好被移除。

移除 kubelet 的 --keep-terminated-pod-volumes 命令列標誌

kubelet 的標誌 --keep-terminated-pod-volumes 於 2017 年被棄用，現已作為 v1.31 版本的一部分被移除。

你可以在拉取請求 #122082 中找到更多詳細資訊。

移除 CephFS 卷外掛

在此版本中， CephFS 卷外掛被移除，cephfs 卷型別變得不可用。

建議你使用 CephFS CSI 驅動作為第三方儲存驅動。如果你在將叢集版本升級到 v1.31 之前正在使用 CephFS 卷外掛，你必須重新部署你的應用程式以使用新的驅動。

CephFS 卷外掛在 v1.28 中被正式標記為已棄用。

移除 Ceph RBD 卷外掛

v1.31 版本移除了 Ceph RBD 卷外掛及其 CSI 遷移支援，使得 rbd 卷型別不可用。

建議你在叢集中使用 RBD CSI 驅動。如果你在將叢集版本升級到 v1.31 之前正在使用 Ceph RBD 卷外掛，你必須重新部署你的應用程式以使用新的驅動。

Ceph RBD 卷外掛在 v1.28 中被正式標記為已棄用。

棄用 kube-scheduler 中的非 CSI 卷限制外掛

v1.31 版本將棄用所有非 CSI 卷限制排程器外掛，並將從預設外掛中移除一些已棄用的外掛，包括

  • AzureDiskLimits
  • CinderLimits
  • EBSLimits
  • GCEPDLimits

建議你使用 NodeVolumeLimits 外掛，因為它可以處理與已移除外掛相同的功能，因為這些卷型別已經遷移到 CSI。如果你在排程器配置中明確使用它們，請將已棄用的外掛替換為 NodeVolumeLimits 外掛。AzureDiskLimits、CinderLimits、EBSLimits 和 GCEPDLimits 外掛將在未來的版本中移除。

這些外掛將從預設排程器外掛列表中移除，因為它們自 Kubernetes v1.14 以來已被棄用。

釋出說明和所需升級操作

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

當啟用 SchedulerQueueingHints 時，排程器現在使用 QueueingHint

增加了對排程器的支援，以開始使用為 Pod/Updated 事件註冊的 QueueingHint，以確定對先前不可排程 Pod 的更新是否使它們變得可排程。當特性門控 SchedulerQueueingHints 啟用時，新支援生效。

以前，當不可排程的 Pod 被更新時，排程器總是將 Pod 放回佇列中（activeQ / backoffQ）。然而，並非所有對 Pod 的更新都使 Pod 可排程，特別是考慮到現在許多排程約束是不可變的。在新的行為下，一旦不可排程的 Pod 被更新，排程佇列會與 QueueingHint 檢查更新是否可能使 Pod 可排程，並且只有當至少一個 QueueingHint 返回 Queue 時，才會將它們重新排隊到 activeQ 或 backoffQ。

自定義排程器外掛開發者所需的操作：如果外掛的拒絕可以透過更新未排程的 Pod 本身來解決，則外掛必須為 Pod/Update 事件實現一個 QueueingHint。示例：假設你開發了一個自定義外掛，該外掛拒絕具有 schedulable=false 標籤的 Pod。鑑於具有 schedulable=false 標籤的 Pod 如果移除了 schedulable=false 標籤，它們將變得可排程，此外掛將為 Pod/Update 事件實現 QueueingHint，當在未排程的 Pod 中進行此類標籤更改時返回 Queue。你可以在拉取請求 #122234 中找到更多詳細資訊。

移除 kubelet --keep-terminated-pod-volumes 命令列標誌

kubelet 的標誌 --keep-terminated-pod-volumes 於 2017 年被棄用，已作為 v1.31 版本的一部分被移除。

你可以在拉取請求 #122082 中找到更多詳細資訊。

可用性

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

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

釋出團隊

Kubernetes 的存在離不開其社群的支援、承諾和辛勤工作。每個釋出團隊都由敬業的社群志願者組成，他們共同努力，構建構成你所依賴的 Kubernetes 版本的許多部分。這需要我們社群各個角落的人員的專業技能，從程式碼本身到其文件和專案管理。

我們想感謝整個釋出團隊，感謝他們為向我們的社群交付 Kubernetes v1.31 版本而付出的辛勤工作。釋出團隊的成員範圍從首次參與的“影子”到經驗豐富的團隊負責人，他們的經驗是在幾個釋出週期中鍛造的。特別感謝我們的釋出負責人 Angelos Kolaitis，感謝他在一個成功的釋出週期中支援我們，為我們發聲，確保我們都能以最佳方式做出貢獻，並挑戰我們改進發布流程。

專案速度

CNCF K8s DevStats 專案彙總了許多與 Kubernetes 和各種子專案的速度相關的有趣資料點。這包括從個人貢獻到做出貢獻的公司數量的所有內容，並且是說明這個生態系統演變所付出的努力的深度和廣度的例證。

在 v1.31 釋出週期中，該週期持續了 14 周（5 月 7 日至 8 月 13 日），我們看到了來自 113 家不同公司和 528 名個人的對 Kubernetes 的貢獻。

在整個雲原生生態系統中，我們有 379 家公司，總計 2268 名貢獻者——這意味著與上一個釋出週期相比，我們經歷了個人貢獻者數量驚人的 63% 的增長！

此資料來源

我們所說的貢獻是指某人進行提交、程式碼審查、評論、建立問題或 PR、審查 PR（包括部落格和文件）或對問題和 PR 發表評論。

如果你有興趣做出貢獻，請訪問此頁面開始。

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

活動更新

探索 2024 年 8 月至 11 月即將舉行的 Kubernetes 和雲原生活動，包括 KubeCon、KCD 和全球其他著名會議。保持資訊靈通，並與 Kubernetes 社群互動。

2024 年 8 月

2024 年 9 月

2024 年 10 月

2024 年 11 月

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

請於 2024 年 9 月 12 日星期四上午 10 點（太平洋時間）加入 Kubernetes v1.31 釋出團隊的成員，瞭解此版本的主要功能，以及有助於規劃升級的棄用和移除。有關更多資訊和註冊，請訪問 CNCF 線上計劃網站上的活動頁面。

參與其中

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