前言¶
Kubernetes 1.37 定於 2026 年 8 月 26 日正式發佈。7 月 31 日，Kubernetes 官方博客發佈了 v1.37 Sneak Peek，Release Team 列出了運維側需要提前知曉的棄用項與重點增強。根據 Kubernetes 增強追蹤器 與社區 mid-cycle 統計，本版本共跟蹤 86 項增強，其中約 16 項計劃畢業至 Stable（GA）。
對平臺團隊而言，1.37 不是「功能堆砌」型版本，而是幾條長期演進線的交匯點：HPA 原生縮容至零進入 Beta 並默認開啓、DRA 設備污點容忍正式 GA、kube-proxy IPVS 模式啓動棄用時間線，同時 metrics.k8s.io 在 Beta 停留近九年後畢業穩定。如果你正在規劃三四季度升級窗口，下面幾項值得優先評估。
發佈時間與版本概況¶
Kubernetes 1.37 的正式發佈日已寫入 Release 日曆：2026 年 8 月 26 日（週三）。需要強調的是，Sneak Peek 文首已說明：文中內容反映當前發佈狀態，正式發佈前仍可能調整。
從增強分佈看（數據來源：Cloudsmith 對官方 Tracker 的梳理）：
- 86 項有效增強（排除 Deferred / Removed from Milestone）
- 28 項處於 Graduating 階段，其中 16 項目標 Stable
- 34 項 Net New Alpha
除本文重點外，1.37 還涉及 Pod 級資源請求（KEP-2837）GA、KYAML 輸出穩定、Kubelet Rootless Mode Beta、Volume Health Monitor 重新進入 Alpha 等變更。完整清單可參考 Cloudsmith 1.37 特性梳理 與官方 CHANGELOG（發佈日同步）。
HPA 縮容至零：Beta 默認開啓¶
背景與意義¶
隊列型 Worker、定時批處理、事件驅動微服務等場景，業務空閒時 Pod 長期佔着節點卻幾乎不幹活。過去要實現「閒時縮到 0」，常見做法是引入 KEDA 或 Knative，在 HPA 之上再掛一層事件源適配。
KEP-2021 從 1.16 Alpha 起就跟蹤「基於對象/外部指標縮容至零、再擴容回來」的能力；1.36 完成 Alpha 重實現後，1.37 計劃將 HPAScaleToZero 特性門控提升至 Beta 並默認開啓（參見 kubernetes/kubernetes#139648）。
這意味着：對具備合適指標源的工作負載，原生 HPA 即可覆蓋「閒時零副本」，不必再爲這一基礎能力單獨引入第三方控制器。
使用約束（務必讀）¶
縮容至零不支持 CPU/內存利用率類指標。原因很簡單：副本數爲 0 時沒有 Pod 在跑，Resource Metrics API 讀不到利用率，HPA 無法計算目標副本數。
該能力僅適用於 Object 或 External 指標——例如消息隊列深度、自定義 Prometheus 指標、雲廠商觀測指標等，這些信號與當前 Pod 數量無關。
1.37 Beta 還引入了 HPA Status 中的 ScaledToZero 條件，用於區分「控制器自動縮到 0」與「人工暫停 Deployment」等狀態，避免擴容邏輯誤判。
配置示例¶
以下是一個基於外部指標的 HPA 示例：minReplicas: 0，當隊列消息可見數降爲 0 時縮容至零：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: queue-worker
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: queue-worker
minReplicas: 0
maxReplicas: 10
metrics:
- type: External
external:
metric:
name: queue_messages_visible
target:
type: Value
value: "0"
實踐建議：
- 首次啓用時，Deployment 建議從至少 1 個副本啓動，讓 HPA 記錄初始狀態後再縮至 0（KEP 對 scale-from-zero 觸發條件有說明）。
- 默認 5 分鐘 scale-down 穩定窗口 會抑制抖動；突發流量場景可在
spec.behavior中按需調整。 - KEDA 在事件源連接器生態上仍有優勢；但若你的需求僅是「隊列空了就不佔機器」，1.37 的原生 HPA 已值得在預發環境驗證。
DRA 設備污點容忍 GA：GPU 集羣運維的關鍵拼圖¶
DRA 與設備污點是什麼¶
Dynamic Resource Allocation（DRA） 是 Kubernetes 面向 GPU、FPGA、SR-IOV 等專用硬件的新一代資源分配模型。驅動通過 ResourceSlice 上報設備清單，用戶通過 ResourceClaim 申請設備，調度器在分配階段完成選型。
在 GPU 集羣裏，一個長期痛點是：某張卡出現 ECC 錯誤、驅動超時或需要維護下線時，怎麼阻止新 Pod 調度上去，並安全驅逐已在跑的 workload？ 傳統 Device Plugin 模型缺少與 Node Taint 對等的設備級隔離手段。
KEP-5055 引入 Device Taints and Tolerations，機制與節點污點類似：
| 效果 | 行爲 |
|---|---|
NoSchedule |
禁止新 Pod 調度到該設備 |
NoExecute |
驅逐當前使用該設備、且未容忍污點的 Pod |
None |
僅作信息標記，不影響調度 |
DRA 驅動可在 ResourceSlice 中直接標記設備；集羣管理員也可創建 DeviceTaintRule，按 driver、pool、device 名稱等選擇器批量打污點，無需改動驅動配置。
1.37 的 GA 意義¶
KEP-5055 的里程碑爲：Alpha 1.33 → Beta 1.36 → Stable 1.37。對應 PR #138676 已合併，Device TaintRule 通過 resource.k8s.io/v1 API 正式可用。
對 GPU 集羣調度而言，這意味着：
- 故障 GPU 可被標記爲
NoSchedule，新訓練 Job 不會踩坑 - 維護窗口可對特定 pool 打
NoExecute，配合 Pod 容忍策略滾動遷出 - 結合 1.37 同步推進的 DRA 增強（如 KEP-5304 Device Attributes Downward API、KEP-6072 標準
numaNode屬性 Alpha），分佈式訓練獲取拓撲信息、做 NUMA/PCIe 親和調度會更順暢
若你已在 1.35+ 集羣試點 DRA GPU Driver，1.37 是把污點容忍納入生產 SOP 的合適版本。
kube-proxy IPVS 退場，nftables 接棒¶
爲何要棄用 IPVS¶
kube-proxy 的 IPVS 模式自 1.8 引入，初衷是緩解 iptables 規則膨脹帶來的性能問題。但 Kubernetes 社區在 KEP-3866 中已明確指出：內核 IPVS API alone 無法完整實現 Service 語義，IPVS 模式底層仍依賴 iptables 做兜底，維護成本高、行爲難統一。
1.37 起，運行 IPVS 模式的集羣在 kube-proxy 啓動時會收到 棄用警告。官方 Sneak Peek 給出的時間線（KEP-5495）：
| 版本 | 變化 |
|---|---|
| 1.37 | 啓動時記錄 deprecation warning |
| 1.40 | IPVS 模式預計默認禁用（仍可通過特性門控手動開啓） |
| 1.43 | 完全移除 IPVS 支持 |
如何確認當前模式¶
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
若輸出 mode: ipvs，應開始規劃遷移。社區普遍建議的目標後端是 nftables——Kubernetes 自 1.31 起 nftables 模式 Beta，2025 年 2 月官方博客 已有專題介紹。
1.37 還新增了 KEP-5343（Alpha）：爲尚未切換默認後端的集羣打預防針——仍使用 iptables 默認值的節點會收到日誌警告，提醒在 1.40 默認切換 nftables 之前完成顯式配置或遷移。同版本的 KEP-6032 則爲 nftables 補齊 localhost NodePort 用戶態代理能力（Alpha）。
遷移前請確認節點內核 ≥ 5.13（nftables kube-proxy 要求），並在預發環境驗證 Service、NodePort、externalTrafficPolicy: Local 等關鍵路徑。
metrics.k8s.io 正式 GA¶
HPA、kubectl top、各類監控集成背後，都依賴 Metrics API（metrics.k8s.io）。該 API 自早期版本起長期處於 Beta，1.37 計劃將其畢業至 Stable（GA）（KEP-5207）。
官方說明：功能層面無預期變更，v1 與 v1beta1 在過渡期內均可使用。這更像是一次「穩定性蓋章」，讓依賴 Metrics Server 的平臺團隊少一層「Beta API 隨時變」的心理負擔。
升級前檢查清單¶
在 8 月 26 日正式發佈前，建議按下面順序做摸底（部分項來自官方 Sneak Peek，部分來自社區升級指南，正式升級請以 Release Notes 爲準）：
1. 檢查 kube-proxy 模式
見上文 grep 命令。IPVS 用戶請排期遷移至 iptables 或 nftables。
2. 確認 containerd 版本
Kubernetes 自 1.34 棄用 containerd 1.6/1.7，1.35 爲最後支持 containerd 1.x 的版本；1.37 繼續移除 kubelet 遺留配置項，KubeletCgroupDriverFromCRI（1.36 GA）成爲 cgroup driver 檢測的唯一路徑。節點若仍運行 containerd 1.x，應在升級 1.37 之前遷移至 containerd 2.0+：
containerd --version
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
遷移前可在 1.7.21+ 上執行 ctr deprecations list 排查不兼容項；直接訪問 containerd socket 的監控/運維工具需確認使用 CRI v1（containerd 2.0 已移除 CRI v1alpha2）。
3. 確認 cgroup 版本
自 1.35 起 failCgroupV1 默認爲 true，1.37 仍可通過 failCgroupV1: false 臨時 override，但 cgroup v1 支持將在後續版本移除（KEP-5573）。In-Place Pod Resize、分層內存保護等能力依賴 cgroup v2：
stat -fc %T /sys/fs/cgroup/
4. 在預發驗證 HPAScaleToZero
隊列/事件驅動類 Deployment，用 External 或 Object 指標配置 minReplicas: 0，觀察縮容、擴容與 ScaledToZero 條件是否符合預期。
5. GPU 集羣評估 DRA 污點規則
若已啓用 DRA，在 staging 創建 DeviceTaintRule，驗證 NoSchedule / NoExecute 與 ResourceClaim 容忍策略是否按預期工作。
小結¶
Kubernetes 1.37 把幾條「說了很久」的演進線同時推到了可行動階段：HPA 縮容至零讓閒時成本可控，DRA 設備污點讓 GPU 集羣故障隔離有了原生語義，IPVS 退場則倒逼 kube-proxy 向 nftables 統一。86 項增強裏或許沒有單一「殺手特性」，但對負責集羣生命週期的人來說，這恰好是制定 Q3–Q4 升級路線圖的正確時間點。
正式發佈還有約三週。建議現在就用上面的命令摸清 kube-proxy 模式、containerd 版本和 cgroup 狀態；8 月 26 日 CHANGELOG 出爐後，再對照 diff 做最終 Go/No-Go 決策。
