Apache APISIX Ingress controller 1.5.0-rc1 发布

目前 Apache APISIX Ingress controller^[2]^ 项目已经进入了 v1.5 的发布窗口，目前会先发布 1.5.0-rc1 版本， 待投票流程结束后，将会有正式的公告和对应的 Release 发布。

距离上一个特性版本 v1.4.0 发布已经过去了将近 7 个月的时间，这期间我们进行了大量的开发工作，有 144 次提交和 28 位贡献者参与，感谢大家的参与让这个版本有了很大的不同。这里我列一些主要的变化，后续还会有专门的发版公告和特性解读文章等。

在这个版本中，正式将所有 CRD 资源的 API version 升级到了 v2 stable ，这也标志着用户使用起来会更加的方便和统一，同时这些资源也已经过多个版本迭代和用户在生产环境的使用，达到了足够稳定的级别。

此外，在这个版本中提供了对 Gateway API 的支持，不过此特性目前尚处于实验性质，默认不开启，用户可以通过为它传递 enable_gateway_api=true 的配置项来开启此能力。在下个版本中我们将引入 Gateway API 项目的一致性测试，来保证我们的实现与 Gateway API 项目的一致性。这样做的好处在于凡是通过了 Gateway API 一致性校验的实现，均可进行互相替换，不会存在锁定的情况。而且在迁移的过程中，也可以保证配置的兼容性。

Apache APISIX Ingress controller 项目是支持多种配置方式的，无论使用 CRD 的方式，或者使用 Kubernetes 中原生的 Ingress 资源都是可以的。但在之前版本中，对于 Ingress 资源来说，想要使用 APISIX 提供的 plugin 能力，就必须先实现一个对应的 annotation，这种方式可扩展能力很差。在这个版本中，我们为 Ingress 资源提供了一个新的 annotation 允许所有的 Ingress 资源可以直接使用 APISIX 所提供的 70+ 种 plugin 的能力，这对于一些使用开源的仅支持配置 Ingress 资源的用户而言，是非常有用的。

除去这些新功能外，目前无论是开源项目的维护者，还是使用者，都在积极的关注供应链安全。在 Apache APISIX Ingress controller 中，我们也其所使用的 Golang 版本，以及所依赖的所有模块均升级到了最新版本，并且借助 GitHub 的 Dependabot 进行依赖的周期性扫描和更新，尽可能的提供安全可信的软件。

这里我先介绍这么多，大家如果对此项目感兴趣，欢迎在 GitHub 加个 star https://github.com/apache/apisix-ingress-controller

发布流程未结束前，也可直接从最新的代码中构建镜像尝试使用。

上游进展

#104907 · kubernetes/kubernetes 这是一个持续了将近一年的 PR，在这个 PR 中引入了一项新的特性：ContainerCheckpoint。

对 Docker 比较熟悉的小伙伴，可能知道在 Docker 中存在一个 docker checkpoint 的子命令。这个子命令实际上是可以帮助我们为某个正在运行的容器创建一个状态点的快照，并将其保存到磁盘中。

后续，我们可以使用此 checkpoint 启动容器，恢复其原先的状态，或者将容器迁移到其他的机器上。

同样的，在 Kubernetes 中提供的这个 ContainerCheckpoint 的新特性是自 v1.25 开始作为 alpha 特性加入的，默认是关闭的。利用此特性可以通过 kubelet 提供的 API，为 container 创建一个有状态的快照，然后将其移动到另一个节点上进行调试，或者其他类似的需求。

此处需要注意的是，创建 checkpoint 可能会产生一些安全隐患，比如 checkpoint 实际上是对当前运行中 container 的内存快照，所以如果在 container 的内存中包含了某些隐私数据，那么有可能在迁移到其他机器上也可以访问到。

另一方面，创建 checkpoint 会产生一些文件，这些文件是需要占用磁盘的。如果频繁的创建 checkpoint 则可能导致磁盘压力过大。checkpoint 的存档，默认情况下会放在 /var/lib/kubelet/checkpoints 目录下，并且以 checkpoint-<podFullName>-<containerName>-<timestamp>.tar 进行命名。

这个特性使用起来也很简单，直接给 Kubelet 发送一个请求即可：

POST /checkpoint/{namespace}/{pod}/{container}

然后将获取到的归档文件，通过以下命令进行恢复：

crictl restore --import=<archive>

另一个值得注意的变更是，kube-proxy 的 container image 将要变更为 distroless 的了。#111060 · kubernetes/kubernetes

这可以规避很多安全隐患，提升集群的安全性。