K8S 生态周报| Ingress NGINX 项目暂停接收新功能将专注于稳定性提升-工具盒子

Ingress NGINX 项目暂停接收新功能将专注于稳定性提升

熟悉我的小伙伴可能知道，我是 Kubernetes Ingress NGINX 项目的 maintainer 。

经过我们开发团队的长时间讨论，我们发现 Kubernetes Ingress NGINX 项目自 2016 年到现在已经走过了 6 年时间，在这 6 年的时间里，在 GitHub 上达到了 13K star，同时也有 800+ 位 Contributor 参与贡献此项目，同时也收到了 4000+ 的 Issue 反馈，以及 4000+ 的 PR 。

在这个过程中，Ingress NGINX 项目的功能得到了极大的丰富，但作为一个软件，不可避免的也会有各种 bug，漏洞等存在。目前对于此项目来说，大家会在需要某些功能的时候快速的去实现它（感谢大家贡献的 PR），但是当出现 bug 或漏洞的时候，却很少有人来修正它。（在开源项目中，这是一个普遍情况，修正 bug 或漏洞，相比于增加新功能，需要对项目自身更加的熟悉）

这种情况实际上为维护者们增加了很多负担，我们需要把时间放在处理 issue，添加和 review 新功能的 PR，以及进行 bug 和漏洞修正，以及考虑新功能是否可能会带来一些连锁反应等。

在上面的数据中，可以看到此项目和社区都是比较活跃的，我们在业余时间进行此项目的维护和开发，整体上压力是比较大的，而且无法做到非常及时的响应。

近期 Ingress NGINX 项目中报告了一些安全漏洞（已经进行了修复），但在修正过程中，我们发现要完美的修正这些漏洞是比较难的，而且任意的改动都有可能会引起其他的连锁反应，包括引入其他的漏洞，或者影响用户的某些功能/行为等。

基于以上的考虑，我们一致达成了决定，暂停接收新功能，并专注于修复和提升 Ingress NGINX 项目的稳定性。可能你有新的 PR 正在等待合并，但是很抱歉，希望你能够理解，在我们提升了此项目的稳定性后，我们可以迭代的更快！

目前我们的计划是用 6 个月的时间来完成此目标，并且我们已经确定了一些具体需要做的事情，你可以通过以下链接了解我们的进度：https://github.com/kubernetes/ingress-nginx/projects/52

同时，我们也正式发出了一项社区调查，用于帮助我们决定在此冻结期后，我们应该发展的方向。如果你是 Ingress NGINX 的用户，请填写此表单，谢谢！

https://www.surveymonkey.com/r/ingressngx2022

上游进展

为 kubectl 引入 kuberc 配置文件

KEP-3104 这个 KEP 旨在为 kubectl 引入一个新的配置文件 kuberc，用来配置一些用户的自定义配置。这在很多的项目，或者工具中都有类似的用法。比如 Vim 中可以通过 -u 指定用户自己的配置文件，或者使用默认的 ~/.vimrc 来完成自定义配置。

这样做的好处就在于可以让 kubeconfig 更加的专注，仅仅需要保留和集群、用户凭证相关的信息即可，对于用户的自定义配置则分离开来。具体而言，这个配置文件看起来就会是这样：

apiVersion: v1alpha1
kind: Preferences

command:
  aliases:
    - alias: getdbprod
      command: get pods -l what=database --namespace us-2-production
      
  overrides:
    - command: apply
      flags:
        - name: server-side
          default: "true"
    - command: delete
      flags:
        - name: confirm
          default: "true"
    - command: "*"
      flags:
        - name: exec-auth-allowlist
          default: /var/kubectl/exec/...

看起来也比较直观，可以用来增加一些 alias 和覆盖一些默认的配置，这样大家不再需要定义很多的 alias，以后使用 kubectl 的时候敲的命令也能少很多。此特性未实现之前，在这里顺便推荐另一个项目 kubectl-aliases，此项目中包含了很多 alias，可以让使用 kubectl 的过程更加简单。

但也有一些弊端，就像是每个 Vim 用户都要有自己的 vimrc 配置文件一样，这会养成一定的习惯。在一些没有自己自定义配置的机器上使用时，会有些不习惯。同时，这在排查问题时，也可能增加排查的链路（比如 kuberc 中增加了一个错误的配置之类的）。

举例来说，我在排查 Vim 的问题时候，通常会直接 vim -u /dev/null 这样，以防使用了任何自定义配置造成影响。那么后续如果这个功能完全实现了，那么大家在排查问题的时候，需要注意使用 kubectl --kuberc /dev/null 类似这样的方式来避免本地自定义配置造成影响。