Kubernetes v1.37 计划发布：kubectl run 与存储健康检查先做兼容排查

如果集群里还保留着用 kubectl run -f 生成 Pod 的脚本，或者平台团队正准备接入 CSI 卷健康状态，Kubernetes v1.37 的升级预告值得提前看一遍。官方计划在 2026 年 8 月 26 日发布 v1.37，当前最需要关注的不是“新增了多少功能”，而是旧参数和状态字段会怎样影响现有自动化。

v1.37 这次最实际的变化是兼容边界

官方预告把 kubectl run 的 --filename（短参数 -f）列为待弃用项。这个参数与“通过命令行参数生成一个 Pod”并不是同一件事：前者更像把文件入口塞进了一个本来用于快速生成 Pod 的命令，脚本作者容易误以为两种写法可以长期互换。

预告还提到 Volume Health Monitor 的方向变化。它计划通过 CSI 控制器和 kubelet 获取卷健康状态，把结果写入 PVC.status.healthStatus、Pod.status.volumeHealth 和 CSINode.status.storageHealth。这些字段对排查“卷不可访问”很有价值，但当前实现仍需按 Alpha 能力评估，不能直接写成监控平台的永久契约。

先从代码库找出 -f 的真实使用位置

第一步不是立刻改 YAML，而是确认参数到底出现在什么链路里。开发机脚本、发布流水线、定时任务和故障应急手册都要查到；只搜 Deployment 文件，往往会漏掉真正会被调用的 Shell 和 CI 配置。

rg -n --hidden --glob '!vendor/**' \
  'kubectl[[:space:]]+run|--filename([ =]|$)|(^|[[:space:]])-f([[:space:]]|$)' .

把结果按“人工临时命令、流水线生成、长期任务”分组。临时命令可以改成清晰的 Pod 清单；流水线要补上 YAML 校验和差异检查；长期任务则需要把镜像、标签、资源限制和服务账号权限都迁移到可审查的清单里。

迁移时不要把生成式命令和声明式清单混成一条路径

迁移后的验收重点不是命令返回成功，而是对象结果一致：镜像摘要、容器端口、资源请求、服务账号和重启策略都要与旧环境对比。对平台脚本来说，清单化的价值在于变更可审查、回滚有依据，而不只是躲开一个弃用警告。

Volume Health Monitor 先按“可选信号”接入

卷健康信息适合辅助告警，不适合在 Alpha 阶段成为唯一的自动修复条件。控制器侧和节点侧的报告来源不同，状态字段也可能随着版本和 CSI 驱动实现变化。接入时建议给每条告警保留对象名称、节点、存储类、驱动名、健康状态、reason 和 message，并把原始对象快照放进排查记录。

kubectl get pvc data-store -o json
kubectl get pod app-0 -o json
kubectl get csinode worker-01 -o json

测试时至少覆盖三种结果：卷正常、卷不可访问、驱动暂时没有提供健康数据。第三种不能被误报成“卷已损坏”；监控规则应区分 Unknown、字段不存在和明确的 Inaccessible 等状态，并设置观察窗口，避免一次短暂的 CSI 响应异常就触发迁移。

升级前用一套小型回归集验证风险

1. 在测试集群安装与生产相同版本的 CSI 驱动，记录 PVC、Pod 和 CSINode 的原始 JSON。
2. 跑一遍历史流水线，确认不再依赖 kubectl run -f，并比较渲染前后的对象差异。
3. 模拟节点不可用或卷访问异常，检查健康状态能否到达告警系统。
4. 把“没有字段”“Unknown”和明确故障分别投递，确认值班规则不会过度升级。
5. 按正式发布说明复核弃用和 Alpha 状态，再决定是否扩大灰度范围。

如果 CSI 驱动没有实现相应能力，平台仍应依靠驱动日志、事件和业务探针完成基础监控；不要为了填满一个新字段而替换现有证据链。

相关问题

v1.37 发布后 -f 会立即失效吗？

官方预告描述的是弃用计划，不等于当前版本发布后立刻删除。应以最终版本说明和弃用指南为准，但提前迁移能避开后续升级窗口的集中改动。

为什么不直接把 Volume Health Monitor 当成故障自动修复开关？

它涉及控制器、kubelet 和 CSI 驱动多个来源，当前又处于 Alpha 阶段。信号缺失或延迟时，自动修复可能把“没有数据”误判为“卷损坏”。

生产对象都应该改成 Pod 清单吗？

长期运行的对象建议使用可审查的声明式清单；临时排障仍可以保留简短的生成式命令，但要把它和生产发布链路隔离。

什么时候可以开始使用新健康字段？

可以先在测试集群采集和观察，但要将字段视为实验性信号，设置缺失兼容、驱动差异和回滚方案，等最终版本说明明确后再扩大用途。

Kubernetes v1.37 的升级准备，核心不是追逐预告里的每个新名词，而是先清理旧入口、保留对象证据，再把实验性健康信号放进可回退的观察链路。这样即使最终版本调整了字段或实现，平台也不会因为一次升级失去基本的发布和故障判断能力。