看到“Kubernetes发布”几个字，很多人的第一反应可能是又一波繁杂的功能堆叠。但仔细读完1.36版的更新列表会发现，这次有至少五个能力，是平台工程师、SRE和管理员每天都会遇到的痛点，而且它们都指向同一个方向：帮你扔掉一些外部依赖，把运维复杂度压回集群内部解决。

先从一项正式步入GA的特性说起——Mutating Admission Policies。以往如果想自动给Pod打标签、注入Sidecar容器、或者强制设置组织级默认值，一般的做法是部署一个准入Webhook。这个外部服务不光要自己维护，还要管TLS证书、监控可用性、调试API Server超时。一旦Webhook挂了，全集群的负载创建都可能被阻塞。Kubernetes 1.36把这类需求直接收进API Server，用CEL表达式就能完成常见的变更，不再依赖外部组件。这意味着一条故障链路被砍掉了，运维同学不用半夜起来念叨“为什么Webhook又超时”。

另一项长跑多年的能力——User Namespaces——也终于标上了生产就绪。没有User Namespaces时，容器内以root运行的进程，在宿主机眼里同样是root。开启后，容器里的root会映射成节点上一个无特权用户。哪怕真有容器逃逸漏洞被利用，攻击者能拿到的权限也会大打折扣。只要在Pod规格里把hostUsers设为false即可。这不是那种让人眼前一亮的新功能，却是近几年Kubernetes在容器隔离层面最实在的加强。

接下来两个改动都跟权限治理和排错效率有关。细粒度的kubelet授权让各类监控和排障工具不再需要绑上nodes/proxy这种宽泛的权限，而是可以精确开放特定端点，让RBAC配置更干净、更符合最小权限原则。节点日志查询功能则解决了另一个常见操作：ssh到工作节点上翻kubelet日志。现在通过Kubernetes API就能直接拉取，一句kubectl get --raw就能拿到日志内容。少开一次ssh，排查就快一步，自动化也更顺畅。

个人最欣赏的OCI卷支持也正式稳定下来。Kubernetes现在可以将OCI镜像仓库里的内容直接挂载成数据卷。团队不用再纠结是把ML模型、静态资源、配置包或者参考数据集打进容器镜像，还是单独维护一套存储系统。继续用同一个OCI仓库做分发，与容器镜像共存，让整个发布管线保持统一。这个设计直接回应了以同一套制品机制覆盖代码、配置和数据的长期需求。

如果把这五个改进放在一起看，1.36版传递了一个清晰的趋势——把那些曾经需要独立服务、额外权限、手工操作的事情，一步步收进平台的内生能力中。对日常跑在大规模集群上的人来说，这些升级带来的不是炫技，而是更少的依赖、更快的排查，以及更不容易出错的配置。