Kubernetes 1.36 运维升级清单：从安全授权到存储快照
结合 Kubernetes 1.36 的最新变化，整理运维团队升级前需要关注的 kubelet 授权、DRA、存储快照、SELinux 和 HPA scale to zero。
Kubernetes 1.36 已经发布一段时间。对学习者来说，版本号可能只是“又升级了”；但对运维团队来说，每次 minor 版本都意味着一次能力边界变化：哪些功能稳定了，哪些旧用法要避免，哪些安全默认值应该跟上。
本文不做完整 release notes 翻译，而是从运维视角整理 Kubernetes 1.36 中最值得关注的变化，以及升级前应该检查的事项。
先明确：升级不是只换 kubelet 和 kube-apiserver
Kubernetes 升级至少涉及这些层面：
- 控制面组件：
kube-apiserver、kube-controller-manager、kube-scheduler - 节点组件：
kubelet、kube-proxy或 CNI 替代方案 - 容器运行时：containerd、CRI-O
- CNI、CSI、Ingress、监控、日志、安全策略等插件
- 业务工作负载的 API 兼容性
所以生产集群升级前，不建议只看 kubeadm 命令。更稳的做法是先列出集群里所有关键扩展组件，再逐个确认兼容矩阵。
关注点一：细粒度 kubelet API 授权 GA
Kubernetes 1.36 中，细粒度 kubelet API 授权进入 GA。它的意义在于，过去一些监控或排障工具为了访问 kubelet HTTPS API，可能需要比较宽泛的 nodes/proxy 权限；新的授权能力让访问控制更细，可以更接近最小权限原则。
升级检查建议：
kubectl get clusterrole,clusterrolebinding | grep -i node
kubectl auth can-i get nodes/proxy --as <service-account>如果某个监控组件仍然要求非常大的节点代理权限，要重新评估它到底需要读取什么接口。
关注点二：User Namespaces GA
User Namespaces 在 Kubernetes 1.36 中 GA，这是容器隔离方向的重要变化。简单说，它可以让容器内部的 root 和宿主机上的 root 不再是同一个身份空间。
这对安全加固很关键。很多学习者会以为“容器里 root 没关系”，但从 Linux 内核角度看，容器逃逸风险、挂载风险、能力集风险都和 UID 映射有关。
适合优先评估的场景：
- 需要降低容器内 root 对宿主机影响的集群
- 多租户平台
- CI/CD 构建集群
- 不完全可信的插件或任务运行环境
需要注意的是，User Namespaces 是 Linux 特性，也会依赖运行时、内核和工作负载配置，不是单独升级 Kubernetes 就自动万事大吉。
关注点三：VolumeGroupSnapshot GA
很多业务不是单块 PVC，而是一组卷共同构成一致性状态。例如数据库主数据卷、日志卷、配置卷需要在同一时间点形成快照。Kubernetes 1.36 中 VolumeGroupSnapshot 进入 GA，可以让多个 PVC 做 crash-consistent 快照。
升级检查建议：
- CSI 驱动是否支持相关扩展 API
- 备份系统是否已经适配组快照
- 恢复演练是否覆盖“多卷同时恢复”
- 业务是否能接受 crash-consistent，而不是 application-consistent
不要只验证“能创建快照”，还要验证“能恢复并启动服务”。
关注点四：SELinux 卷挂载性能改进 GA
在启用 SELinux 的系统上，卷挂载时递归 relabel 可能导致 Pod 启动慢。Kubernetes 1.36 中相关改进 GA，使用挂载上下文减少递归修改带来的延迟。
这对使用 RHEL、CentOS Stream、Fedora、openEuler 等 SELinux 环境的团队比较有意义。
排查 Pod 启动慢时，可以重点观察：
kubectl describe pod <pod-name>
journalctl -u kubelet如果大量时间消耗在卷挂载和权限处理上，就要把 SELinux、CSI 驱动和 Kubernetes 版本一起纳入分析。
关注点五：HPA scale to zero 进入 Alpha
Kubernetes 1.36 继续推进 HPA scale to zero。这个能力对队列消费、定时任务、AI 推理、低频服务很有吸引力，因为空闲时可以把副本数降到 0。
但它仍然是 Alpha，不建议直接当生产默认能力使用。
更稳的学习路径是：
- 先掌握普通 HPA。
- 再理解 CPU、内存、自定义指标、外部指标的区别。
- 在测试集群验证 scale to zero。
- 评估冷启动时间、队列积压、告警噪声。
省资源不是唯一目标，可恢复性和用户体验同样重要。
升级前建议做的 8 个检查
- 检查 API 废弃项：
kubectl api-resources
kubectl get events -A | grep -i deprecated- 检查 kubelet 权限：
kubectl get clusterrolebinding -A-
检查 CNI 兼容性。
-
检查 CSI 驱动版本和快照能力。
-
检查 containerd 或 CRI-O 支持矩阵。
-
检查 Ingress Controller 是否仍在维护。
-
检查 Prometheus、日志采集、节点 exporter 的权限。
-
在测试集群跑业务回归。
总结
Kubernetes 1.36 的重点不是“多了几个新功能”，而是平台能力继续向安全、硬件资源管理、存储一致性和成本优化推进。
对运维学习者来说，升级 Kubernetes 最值得练习的不是背版本特性，而是建立升级清单：组件兼容、权限收敛、插件验证、业务回归、回滚方案。真正的生产运维能力，往往就体现在这些细节里。