By Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor | Friday, July 31, 2026

隨著 Kubernetes v1.37 發布日期逼近，專案持續發展與成熟， 部分功能可能被棄用、移除，或以更佳的替代方案替換，以維持專案整體 健康。本文概述 Kubernetes v1.37 版本中已規劃的變更，讓 發行團隊認為您應該了解這些內容，以持續維護 Kubernetes 環境並跟上最新變更。以下資訊反映 v1.37 版本的目前狀態， 在正式發布前可能有所變動。

Deprecations and removals for Kubernetes v1.37

Kubectl: kubectl run --filename/-f 即將被棄用

--filename（或 -f）旗標在 kubectl run 中即將被棄用，因為產生的 Pod 始終完全由 CLI 參數如 NAME 和 --image 所建構。

請參閱 kubernetes/kubernetes#138671 了解原始議題與討論。

Kubelet: 靜態 Pod 無法再參照 Secrets 或 ConfigMaps

靜態 Pod 原本就不該直接讀取 API 資源，因為它們並非透過 API server 建立——但一個 bug 允許它們透過 configMapRef 或 secretRef 等欄位參照 Secrets 或 ConfigMaps。這個 bug 現已修正：自 v1.37 起，這類參照將被嚴格禁止，而先前可讓您退出此限制的 PreventStaticPodAPIReferences 功能閘道也已移除。

請參閱 kubernetes/kubernetes#140226 了解原始議題與討論。

棄用 kube-proxy 對 ipvs 模式的支援

kube-proxy 對 ipvs 模式的支援自 v1.8 引入，以解決 iptables 的效能瓶頸。然而，由於核心 ipvs API 本身無法完整實作 Kubernetes Services，ipvs 模式持續在底下使用 iptables（KEP-3866，「The ipvs mode of kube-proxy will not save us」）。

以 ipvs 模式（或 KubeProxyConfiguration 中的 mode: ipvs）執行 kube-proxy 的叢集，啟動時將會記錄一則棄用警告。棄用時程如下：

  • 至 v1.40 為止，ipvs 模式預設將被停用（仍可透過功能閘道選擇）
  • 至 v1.43 為止，ipvs 模式將被完全移除 KEP-5495, Graduation Criteria。 要確認您目前執行的模式，請使用：
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

要了解此棄用的原因，請參閱 KEP-5495: Deprecate ipvs mode in kube-proxy。

Ongoing major changes

未來將移除 cgroup v1 支援

由於現代 Linux 發行版與容器執行環境已將 cgroup v2 作為預設，傳統的 cgroup v1 支援已正式逐步淘汰。自 v1.35 起，failCgroupV1 設定已預設為 true。因此，除非套用明確的設定覆寫，否則 kubelet 將無法在任何仍依賴 cgroup v1 的節點上初始化。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # temporary override

使用此覆寫應視為短期因應措施。進階資源管理功能（如 In-Place Pod Resizing 與 Tiered Memory Protection）完全依賴 cgroup v2。雖然 Kubernetes v1.37 仍提供此覆寫，但鼓勵使用者遷移至 cgroup v2，因為 cgroup v1 支援計劃在未來版本中移除。

要了解更多關於此棄用的資訊，請參閱 KEP-5573: Remove cgroup v1 support。

Breaking changes in Kubernetes v1.37

SELinux 磁碟區重新標記（「SELinuxMount」）升級至 GA

SELinuxMount 預計在 v1.37 達到 GA 並預設啟用。磁碟區將會以 -o context=<label>（掛載選項預設值）掛載，而非進行遞迴重新標記，但僅限在磁碟區的 CSI 驅動程式透過將 .spec seLinuxMount: true 設定的 CSIDriver 加入支援時。

因為單一掛載只能持有一個 SELinux 內容，在同一節點上共享磁碟區但具有不同 SELinux 標籤的 Pod（先前可在遞迴重新標記下共存），現在可能無法啟動。若要保留特定工作負載的先前遞迴行為，請在 Pod 規格中設定 seLinuxChangePolicy: Recursive。

未啟用 SELinux 的叢集完全不受影響。欲了解更多資訊，請參閱 SELinux Volume Label Changes goes GA (and likely implications in v1.37)

Featured enhancements of Kubernetes v1.37

Metrics API 升級至 GA

metrics.k8s.io API 預計在 Kubernetes v1.37 升級至 Stable（GA），歷經近九年的 Beta 階段。此 API 提供取得 Pod 與節點 CPU 及記憶體使用量的標準方式，為 Horizontal Pod Autoscaler (HPA) 與 kubectl top 等指令提供動力。

此升級肯定了該 API 的穩定性與廣泛採用，預計不會有功能性變更。v1 與 v1beta1 在過渡期間仍可使用，讓開發者能依自己的步調採用穩定 API，而不中斷現有工作流程。

要了解更多關於此增強功能的資訊，請參閱 KEP-5207: metrics.k8s.io API definition。

Kubelet in UserNS 又稱 Rootless Mode

傳統上，Kubernetes 節點元件如 kubelet 以主機上的 root 權限執行。雖然這對許多部署是必要的，但也意味著這些元件中的漏洞可能對底層系統造成更大影響。

隨著 Kubernetes v1.37，kubelet in User Namespace (Rootless Mode) 預計升級至 Beta。此增強功能允許 Kubernetes 節點元件在 Linux 使用者命名空間內以主機上的非特權使用者執行，同時在命名空間內仍表現為 root。透過減少對主機層級 root 權限的需求，它增加了額外的隔離層，並有助於限制影響節點元件的潛在漏洞。

要了解更多關於此增強功能的資訊，請參閱 KEP-2033: Kubelet in UserNS(aka Rootless Mode)。

磁碟區健康監控

過去，Kubernetes 缺乏讓 CSI 驅動程式回報儲存故障的 API，這些故障僅在掛載失敗或 I/O 停滯時才會顯現。由於修復控制器沒有機器可讀的資料可供操作，找出這些故障的根本原因的唯一方法是交叉參照 Kubernetes 物件與外部供應商儀表板。

在 Kubernetes v1.37 中，此 KEP 在 v1.21 的初始實作後重新設定為 Alpha 階段，並引入四個新的 CSI RPC。控制器外掛程式使用 ControllerListVolumeHealth（列出不健康的磁碟區）與 ControllerGetVolumeHealth（檢查特定磁碟區）回報儲存磁碟區的健康狀態。控制器端健康監控會輪詢這些 CSI 控制器，並將結果儲存在 PersistentVolumeClaim.status.healthStatus 中。

在節點端，kubelet 呼叫 NodeGetVolumeHealth 以取得該節點上個別磁碟區的健康狀態，並將其記錄在 Pod.status.volumeHealth 中，而 NodeGetStorageHealth 則在 CSINode.status.storageHealth 中回報已註冊至節點的驅動程式的健康狀態。

錯誤詞彙保持簡單、可擴展且可由機器解析（Inaccessible、Degraded 等），並可透過 reason 與 message 進一步提供驅動程式特定細節。最後，控制器端與節點端的報告保持獨立，因此會分別顯示，為使用者提供更全面的儲存健康檢視。

要了解更多關於此增強功能的資訊，請參閱 KEP-1432: Volume Health Monitor。

Want to know more?

新功能與棄用項目也會在 Kubernetes 發行說明中公布。我們將在該版本的 CHANGELOG 中正式公布 Kubernetes v1.37 的新功能。

Kubernetes v1.37 發行計劃於 2026 年 8 月 26 日（星期三）。敬請關注更新！

您可以查看以下版本的發行說明中的變更公告：

Get involved

參與 Kubernetes 最簡單的方式是加入符合您興趣的眾多 Special Interest Groups（SIGs）之一。

如果您不知道從何開始，請加入我們的每月 New Contributor Orientations ，我們將教導社群專案的結構，並引導您如何對專案做出首次貢獻。