Kubernetes Ingress-NGINX v1.3.0 正式发布

本周我们发布了 Kubernetes Ingress-NGINX 的 v1.3.0 版本， 正如我在之前的文章 K8S 生态周报| Ingress NGINX 项目暂停接收新功能将专注于稳定性提升 中介绍的， 我们接下来会投入 6 个月的时间，用于项目稳定性的提升。

本次发布的 v1.3.0 版本，将会是正式进入功能冻结期前的最后一个功能版本，接下来 6 个月不会再发布新的功能版本，但如果有需要会发布一些 bugfix 版本。

以下是此版本中的最值得关注的变更：

• 删除了对 Kubernetes v1.19 版本及以下的变更；
• 增加了对 Kubernetes v1.24 版本的支持；
• 从这个版本开始，需要增加 coordination.k8s.io/leases 资源的授权来进行 leaderelection

本次共有 18 位贡献者参与，感谢大家的贡献！

如果大家在使用中有遇到问题，或者发现 bug 等，欢迎在 GitHub 上提交 issue 进行反馈。

更多详细变更，请参考其 ReleaseNote

Kubernetes Gateway API 达到 Beta 阶段

随着 Kubernetes Gateway API 项目的 v0.5.0 版本的发布，其中最重要的几个 API 资源已经达到了 Beta 阶段， 同时社区也发展的很快，各类实现都在积极跟进。比如我正在做的 Apache APISIX Ingress 项目，目前 已经基本实现了 Gateway API 中主要资源的支持， 如果有小伙伴想要体验可以直接使用项目源代码进行构建，或者等下个 Release 发布。

那么什么是 Gateway API 呢？实际上它就是一套自定义资源的规范集合，各类 Ingress controller 项目通过实现此规范 来进行集成。并且 Gateway API 相比于 Ingress 资源来讲，它具备更加丰富的表现力，同时社区也在积极的扩展其应用场景。

本次的 v0.5.0 版本的发布，主要是将以下 3 种资源升级到了 v1beta1:

• GatewayClass
• Gateway
• HTTPRoute

你可以通过官方文档中的 Implementations 查看到当前各种实现对 Gateway API 的支持程度。

另一方面：Gateway API 也在探索其与 Service mesh 的结合点。本次也重点宣布了其与 Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX Service Mesh 以及 Open Service Mesh 等社区的协作， 共同组成 GAMMA Initiative ，共同探索 Gateway API 与这些项目的集成等。

当然，Gateway API 项目也与另一个项目 SMI 进行了讨论，探索通过 Gateway API 来替换 SMI 规范中流量切割特性的可能性， 不过目前还没有讨论结果，我很期待后续的进展。

如果真的实现了，那么相当于是使用一套 CRD 或者说使用一套规范来完成了南北向和东西向流量的定义。对应的这些 controller 实现，也都将变成全流量代理平台！这其实和 Apache APISIX 做的事情是一样的，但 APISIX 是具体的实现，而非定义规范。

我个人对 Gateway API 项目的发展是很看好的，无论是我在维护的 Kubernetes Ingress-NGINX 还是 Apache APISIX Ingress 项目都会很积极的拥抱此项目的。期待后续进展！

Kyverno 项目达到 CNCF 孵化阶段

Kyverno 是一个为 Kubernetes 实现的策略引擎，用户可以通过 YAML 配置策略，并应用到集群中。如果对 Kyverno 不太熟悉的小伙伴可以看看我之前的文章 《云原生策略引擎 Kyverno》

Kyverno 的上手是非常简单的，我在上述文章中也有介绍。

此外，该项目是在 2020 年 11 月进入 CNCF 成为 sandbox 级别项目的，从进入 CNCF 至今，无论是社区，用户等都有着显著的发展和提升。现在能达到 CNCF 的孵化阶段，也证明了该项目是非常成功的，有着丰富的用户基数，并且其社区也发展的很健康。

对此项目感兴趣的小伙伴欢迎去其官网查看文档 https://kyverno.io/ ，文档及示例很丰富。

上游进展

近期 Kubernetes 上游仓库处于特性冻结期，所以相对来说变更并不是特别多。这里说一些比较值得注意的内容：

• Migrate Ginkgo from v1 to v2 · kubernetes/kubernetes 这个 PR 持续了将近三个月，主要是将 Kubernetes 项目中使用的 Ginkgo 从已经废弃的 v1 版本升级到 v2 版本。

其实目前很多项目都在积极的推进此事，但不同的项目对 Ginkgo 的依赖和使用程度不同，在这个 PR 中修改了超过 600 个文件，非常的庞大。而之前在 Apache APISIX Ingress controller 项目中，从 Ginkgo v1 升级到 v2 时，仅仅用了一周时间，修改文件不算太多。此外目前 Kubernetes Ingress-NGINX 项目也同样在进行此升级，可能工作量也不小。

• Introduce KUBECACHEDIR environment variable to override default discovery cache dir by ardaguclu · kubernetes/kubernetes 这个 PR 说起来是比较小的一个改动，但是它的影响却很大。

在这个 PR 中引入了一个新的 KUBECACHEDIR 环境变量，来替代默认的 ~/.kube/cache 缓存目录。通过这个 PR 就有可能会导致用户在使用 kubectl 的时候，可以通过这个环境变量来跳过 缓存。进而可能会引起一些性能问题。

• kube-apiserver: default --enable-logs-handler flag to false · kubernetes/kubernetes kube-apiserver 中的 /logs 由于安全问题，默认情况下会进行关闭，然后通过 --enable-logs-handler 标签进行启用。如果要进行日志采集的话，需要额外注意下。