「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅专栏「k8s 生态」。
题外话
大家好，我是张晋涛。
本次我将这个局部放在结尾。聊聊最近的一些状况。
「K8S 生态周报」暂停了 2 个多月的工夫，期间也有小伙伴来催更，感激大家的继续关注！！！
次要有两方面的起因，一是我近期的确比较忙，另一方面是我进行了一些思考和总结，分享给大家。
「K8S 生态周报」从 2019 年的 3 月开始，到当初曾经是第四年了，我也始终在思考，它能为我，还有关注我的读者小伙伴们带来什么。
对我而言，这是一个总结归档，分享反馈的过程，在此期间我也成长了很多。
我比拟开心的事件是，相比于其他人 / 其余社区发的日报，周报等，「K8S 生态周报」并不单纯的是在搬运链接，或者搬运 ChangeLog，
在每期的内容中，除去资讯自身外，我也会减少我的一些集体认识，还有我所理解到的一些其余内容，包含一些背景常识等。
此外，还会包含一些代码的剖析 / 性能的实际和比照等。能够说「K8S 生态周报」是更有技术性的内容。
基于以上的一些剖析和集体的一些思考，我决定后续「K8S 生态周报」中将退出更多我集体的思考的了解，
在提供这些有价值的资讯的同时，与小伙伴们减少更多的交换和沟通。
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 的用户，请填写此表单，谢谢！
https://www.surveymonkey.com/…
上游停顿
为 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 相似这样的形式来防止本地自定义配置造成影响。
PodSecurity 个性达到 GA
近期在 #110459 · kubernetes/kubernetes 中正式将 PodSecurity 个性降级到 GA。如果我没有记错，这个
个性应该是从引入到 GA 最快的个性之一了。
PodSecurity 是自 Kubernetes v1.22 引入的 alpha 个性，作为 PodSecurityPolicy 的一个代替。在 v1.23 达到 beta 级别，通过上述 PR，在 v1.25 正式 GA，并且默认启用，能够看到
整个倒退过程还是很快的。
PodSecurity 定义了 3 种级别：
- Enforce：如果 Pod 违反策略，则不会被创立；
- Audit：如果 Pod 违反策略，则在审计日志中会被记录，然而 Pod 仍将失常创立；
- Warn：如果 Pod 违反策略，则会在 console 中打印 warning 信息，Pod 仍将失常创立；
应用起来也很简略，只须要给 namespace 增加 pod-security.kubernetes.io/<mode>=<standard> 标签即可。
然而如果你的集群版本较低，并且还心愿能有一个绝对通用的办法，我倡议你能够看看我之前写的文章。《理清 Kubernetes 中的准入管制（Admission Controller)》
和《云原生策略引擎 Kyverno（上）》
通过应用 Admission controller、OPA/GateKeeper、Kyverno 等来实现对立配置。
欢送订阅我的文章公众号【MoeLove】