关于cloud-native:K8S-生态周报-Knative-进入-CNCF-孵化K8S-ingressnginx-解决多实例问题

8次阅读

共计 1886 个字符，预计需要花费 5 分钟才能阅读完成。

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s 生态」。

就在明天 Kubernetes ingress-nginx 我的项目公布了 v1.1.2 版本。
我是这个版本的 release manager。

间隔上个版本公布有将近两个月了，咱们来看看这个版本中值得关注的一些变更。

在 #8221 中，咱们对 ingress-nginx 的 Admission controller 的逻辑做了一些调整，
次要是能够用来修改自 v1.0 版本后，如果 Kubernetes 集群中同时运行多个 ingress-nginx 的话，在创立 Ingress 资源的时候，可能导致每个 ingres-nginx 的 Admission 都会去进行查看的问题。
而该问题最大的影响是，如果创立的 Ingress 配置雷同的话，则会被间接回绝掉。

在 #8253 中则是为 ingress-nginx 减少了一个 ssl_certificate_info 的 metric，间接公开以后被加载的证书的信息。
这个性能的最大的益处就是能够防止 Ingress controller Pod 加载了旧证书，进而导致客户端连贯失败的问题。

此外 #8256 是为了修改在 nginx.ingress.kubernetes.io/auth-url 中传递有效 URL 的问题，
倡议降级。

此外还有一些小的 bugfix 和优化，更多详细信息请参考 ReleaseNote。

在这次公布过程中还有一些比拟乏味的事件，
本次公布过程从工夫线看，从我开始公布流程，到最初实现公布，共继续了一周的工夫，由几个人异步合作实现。
这跟平常差异还是比拟大的，平常咱们可能会约某个工夫，同时在线一起来实现。这次各种起因吧，也比较忙，
往后兴许就会放弃这种模式了（对多时区的合作比拟敌对）。

在之前的《K8S 生态周报 | Istio 行将公布重大安全更新，多个版本受影响》中，我曾介绍过 Istio v1.13 的次要性能，
以及 Istio 会在 v1.13.1 中修复一个重大安全漏洞 CVE-2022-23635。

当初蕴含该漏洞补丁的相干版本曾经公布，包含 v1.11.7、v1.12.3 和 v1.13.1。
该破绽次要是会影响在多集群中运行的 Istio，或者裸露在公网环境中的 Istio。
攻击者能够通过拜访未经身份验证的接口发送特定申请，进而导致 istiod 拒绝服务。

更多详情请参考 Istio / ISTIO-SECURITY-2022-003

上周，CNCF 技术监督委员会(TOC) 投票决定承受 Knative 作为 CNCF 孵化我的项目。

这个事件早在 2021 年的 11 月，过后 Google[1] 和 Knative[2] 我的项目均公布文章示意曾经申请成为 CNCF 的孵化我的项目。

现在终于顺利成为 CNCF 的孵化我的项目，这无论对 Knative，CNCF 还是社区都是十分好的。

在我之前的文章中也曾介绍过，Knative 最早是由 Google 在 2018 年创建并开源的，之后又与 IBM，Red Hat，VMware 等公司单干
开发。

现在 Knative 简直能够说是云原生畛域中装置最为宽泛的 Serverless 我的项目了（数据来自 CNCF 的报告），并且它也曾经达到了 v1.0 版本。
此外 Google 还推出了基于 Knative 的 Cloud Run 和 Cloud Run For Anthos 等产品，这些都对 Knative 的遍及起到了很大的作用。

将来，Knative 将在 CNCF 下培养其社区，并在基金会下转向齐全凋谢的治理模式，
很有可能就会是云原生时代下开源 Serverless 畛域的事实标准了。

布告详情请参考：Knative accepted as a CNCF incubating project

#107638 · kubernetes/kubernetes 更新了 k8s.io/utils 的依赖，次要是为了解决 kubelet 中的 inotify 透露的问题，更多细节可参考 kubelet uses 120GB memory after 20,000 job created and retains 80GB memory after jobs completed and deleted · Issue #100241 · kubernetes/kubernetes