Kubernetes v1.27 新特性一览

大家好，我是张晋涛。

Kubernetes v1.27 是 2023 年的第一个大版本更新，包含了近 60 项主要的更新。 而 1.26 只有 37 项，所以这个版本可以说是一个变化非常显著的版本了。

其中 18 个增强功能正在进入 Alpha 阶段，29 个将升级到 Beta 阶段，而另外 13 个则将升级到稳定版。

尽管这个版本中包含了这么多的特性变更，但值得一提的是，这个版本应该算是第一个完全按照即定流程，恪守每个 deadline 的版本。之前的版本中，每次都或多或少会有一些变数，不过这也从侧面可以看到 release team 做了很多幕后的工作。

我每期的 「k8s生态周报」都有一个叫上游进展的部分，所以很多值得关注的内容在之前的文章中已经发过了。这篇中我会再额外介绍一些之前未涵盖的，和之前介绍过的值得关注的内容。

我们一起来具体看看吧！

SeccompDefault 达到 Stable

如果想要默认使用 seccomp profile，则必须在每个想要使用它的节点上为 kubelet 启用 --seccomp-default 选项。如果启用了该选项，则 kubelet 将默认使用由容器运行时定义的 RuntimeDefault seccomp profile，而不是使用 Unconfined（禁用seccomp）模式。“

默认配置文件旨在提供强大的安全性设置，并保留工作负载功能。容器运行时的不同发布版本之间可能存在不同的默认配置文件。

印象里很早之前 Docker 的配置文件就因为修补安全漏洞而调整过。

Pod 调度就绪机制达到 Beta

这个功能实际上是从 Kubernetes v1.26 开始增加的。是 KEP 3521 的第一部分。

首先我们来简单的回顾一下 Pod 的创建过程。

当 client 通过 kube-apiserver 创建成功 Pod 资源后，kube-scheduler 会去检查尚未被调度的 Pod，然后为其进行调度，分配 Node。之后 Node 获取到调度到该 Node 上的 Pod 然后进行创建。这里省略了很多细节，但其他的部分与我们此处要介绍的内容关系不太大，就不展开了。

根据上述的过程，我们可以发现，在 Pod 创建成功后，其实就默认该 Pod 是可以被调度了，kube-scheduler 就应该开始工作了。

但在实际的场景中，Pod 通常还会需要一些其他的资源，最典型的比如存储。在一些环境中，这些资源是需要预先进行创建的，尤其是在一些云厂商的场景中，还需要检查用户账户中是否还有余额可以用于创建云盘等。

一但前置的依赖无法满足，假如 kube-scheduler 已经完成了 Pod 的调度，那么 kubelet 侧就会处于尝试创建 Pod ，但失败的情况。

这个 KEP 的出现就可以很好的解决这个问题，增加了一个 Pod 是否准备好被调度的机制。如果前置依赖不满足，那么 Pod 就无需被调度，这也不会消耗资源。kube-scheduler 和 kubelet 都无需进行处理。待条件满足，Pod 再被调度和创建即可。<