Kubernetes 1.37（代号 “Garhwal”）发布，重点落在稳定性、安全性以及 AI/ML 工作负载优化上。本次版本尤其值得平台工程团队关注的变化，是 Metrics API 迈向稳定，以及 Rootless Kubelet 进入 Beta。前者有助于降低监控与自动扩缩容接口的长期维护成本，后者则为减少节点级权限暴露提供了更现实的试用路径。
从“能用”走向“可依赖”的 Metrics API
Metrics API 是 Kubernetes 暴露资源使用量的重要接口，常见使用者包括 kubectl top、HPA，以及集群平台上的容量分析工具。API 稳定化的价值不只是版本号变化，更重要的是让下游组件可以围绕更明确的兼容性预期构建。
不过，Metrics API 本身并不会自动产生 CPU 和内存数据。集群仍需要部署并正确配置 Metrics Server 或其他兼容实现，同时确认 kubelet、证书和网络访问路径都正常。升级到 Kubernetes 1.37 后，建议把“API 可发现”和“数据可用”分别验证。
可以在测试集群中运行：
# 检查集群服务端版本
kubectl version --output=yaml
# 检查 Metrics API 是否已经注册
kubectl get --raw='/apis/metrics.k8s.io/'
# 查看节点和 Pod 的资源指标
kubectl top nodes
kubectl top pods --all-namespaces
如果最后两个命令失败，不要直接把问题归因于 Kubernetes 1.37。先检查 Metrics Server 是否运行、APIService 是否为 Available=True，以及 kubelet 的认证和授权配置是否满足 Metrics Server 的要求：
kubectl get apiservice v1beta1.metrics.k8s.io
kubectl -n kube-system get deploy metrics-server
kubectl -n kube-system logs deploy/metrics-server --tail=100
在生产环境中，HPA、告警规则和容量报表应继续使用经过验证的客户端库或查询路径。升级前后对比指标延迟、缺失率和扩缩容行为，比单纯检查 API 版本更加重要。
Rootless Kubelet：降低节点权限暴露
Rootless Kubelet 的核心方向，是让 kubelet 尽可能以非 root 身份运行，从而缩小节点控制面的权限范围。这对共享基础设施、开发测试环境以及对节点安全边界要求较高的场景有吸引力，也符合 Kubernetes 持续强化安全基线的趋势。
但它不是一个只改 User= 就能完成的开关。kubelet 需要访问容器运行时、网络、设备、挂载点和节点级资源；其中一些能力天然依赖特权操作。Rootless 模式进入 Beta，意味着它更适合在明确支持矩阵的环境中验证，而不是直接作为所有生产节点的默认配置。
下面是一个用于验证配置思路的 systemd drop-in 示例。它是实验性模板，运行前必须根据发行版、容器运行时和 kubelet 安装方式调整路径与参数：
# 假设已经创建专用用户，并确认该用户具备实验环境所需的运行时权限
sudo useradd --system --create-home --shell /usr/sbin/nologin kubelet-rootless
sudo mkdir -p /etc/systemd/system/kubelet.service.d
sudo tee /etc/systemd/system/kubelet.service.d/20-rootless.conf >/dev/null <<'EOF'
[Service]
User=kubelet-rootless
Group=kubelet-rootless
Environment=KUBELET_CONFIG_ARGS=--config=/etc/kubernetes/kubelet-rootless.yaml
EOF
sudo systemctl daemon-reload
sudo systemctl restart kubelet
sudo systemctl status kubelet --no-pager
不要把这段配置直接复制到生产集群。部署前至少需要确认以下边界：
- 使用的容器运行时是否支持目标 Rootless Kubelet 场景。
- CNI、CSI、设备插件和日志采集组件是否依赖 root 权限。
- kubelet 的证书、状态目录、插件目录和挂载路径是否对非 root 用户可访问。
- 节点重启、证书轮换和故障恢复流程是否仍然成立。
- 发行版或托管 Kubernetes 服务是否已经提供官方支持矩阵。
更稳妥的推进方式，是先在独立节点池中运行一小组无状态工作负载，再验证 DaemonSet、存储、网络和节点升级流程。Rootless Kubelet 的安全收益必须和运行兼容性、运维复杂度一起评估。
面向 AI/ML 工作负载的版本选择
Kubernetes 1.37 的发布重点还包括 AI/ML 工作负载优化。对平台团队而言，这并不意味着升级后 GPU 任务会自动获得更高吞吐，而是说明 Kubernetes 的演进继续围绕异构资源、批处理调度和工作负载隔离展开。
AI/ML 集群通常同时面对几类问题：GPU 或其他加速器资源稀缺、任务启动时间长、训练与推理工作负载相互干扰，以及资源指标难以准确反映实际瓶颈。Metrics API 的稳定化可以改善资源观测的基础，但 GPU 利用率、显存、网络和存储吞吐仍需要配套的节点级或厂商级监控。
可以把升级验证拆成一组可执行的检查：
# 记录升级前后的节点、组件和关键工作负载状态
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get events -A --sort-by=.lastTimestamp | tail -n 50
# 对训练或推理命名空间进行资源观察
kubectl top pods -n ml
kubectl describe nodes | sed -n '/Allocatable:/,/System Info:/p'
这类检查不能替代完整的 GPU、网络和存储基准测试，但能帮助团队快速发现节点不可调度、指标缺失、Pod 重启或资源分配异常。
升级前的落地清单
Kubernetes 1.37 的变化适合分阶段采用，而不是把所有新能力一次性推向生产：
- 在预生产集群升级控制面和节点，记录 API、kubelet、CNI、CSI 以及监控组件的兼容性。
- 验证 Metrics API 的发现、查询延迟和数据完整性，并观察 HPA 的实际行为。
- 为 Rootless Kubelet 建立独立节点池，只承载已经验证过的工作负载。
- 针对 AI/ML 任务补充 GPU、显存、网络和存储指标，不要只依赖 CPU 与内存使用率。
- 准备回滚或节点替换方案，尤其要覆盖证书轮换、节点重启和容器运行时故障。
总体来看，Kubernetes 1.37 的信号很清晰：平台基础能力正在向更稳定的 API、更小的权限边界和更适合异构计算的运行方式演进。升级价值不在于追逐版本号，而在于把这些能力转化为可验证的监控契约、安全边界和运维流程。