MoeLove

K8S 生态周报| Open Service Mesh 已停止维护，并将归档

 2080  5 分钟

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。

大家好，我是张晋涛。

自上一篇 K8S 生态周报| Docker v24.0.0-beta.1 发布 | MoeLove 后，拖更了几期。这之间发生了一些事情，容我简单总结一下:

  • 4.13 在微软比特熊直播间，分享了 《GPT-4 如何助力开发者在多端效率的提升》。总结来说就是 "所有曾经做过的和没做过的，都可以加上 AI 再做一遍" ，这个领域仍然在持续火热中；
  • 4.15 在大连线下参加了 Kubernetes Community Days China 2023, 分享了 《Kubernetes 安全：实践策略全方位解析》，不过在前一天我嗓子突然哑了，好在当天恢复了一些，顺利完成了演讲，感谢小伙伴们的理解。这也是自疫情几年来我首次去外地和这么多朋友们面基，很多人确实很久都没有见过了，今年这样的机会估计会更多；
  • 4.20 在 APISIX 的视频号分享了 Apache APISIX Ingress controller 项目的近期进展，为即将发布的 v1.7 版本做了些宣传和铺垫；
  • 4.27 在 GoCN 的视频号做了一场直播，作为 Gopher China 2023 云原生专场的预热， 我会在今年 6 月初的 Gopher China 2023 上分享一个与 Service Mesh 有关的主题，同时也欢迎小伙伴们来现场面基；
  • 还有发现之前我参与编写的一本书 《Apache APISIX 实战》已经正式出版了；

此外这中间还伴随着孩子生病，我生病，以及公司的一些事情，所以没有来得及更新。现在身体已经基本恢复健康，可以继续更新了。 同时也提醒小伙伴们注意安全防护，以免生病。

最近这段时间有很多值得关注的事情。我聊几个重点的内容：

Open Service Mesh 将停止更新并归档

Open Service Mesh（简称 OSM ）是一个自 2020 年由微软开源的，轻量级、可扩展的云原生服务网格项目， 旨在为运行在Kubernetes上的应用程序提供统一的控制和安全性。

它是一个基于Envoy代理构建的开源项目，并采用 Service Mesh Interface （简称SMI）作为其标准API，从而允许与支持SMI的其他服务网格实现进行兼容。

OSM 有助于处理在 Kubernetes 集群上运行的微服务的流量管理、策略执行和可观测性等任务，简化了应用程序的部署和管理。

并且该项目在开源后不久就成为了 CNCF sandbox 级别的项目。

我在 2020 年也写过一篇 初试 Open Service Mesh（OSM） | MoeLove 的文章，感兴趣的小伙伴可以再回顾下。

OSM 在 2022 年初正式发布了 v1.0.0 版本。

并且早在 2021 年 Microsoft Azure 上的 Kubernetes cluster 就提供了与 Open Service Mesh 集成的能力。有了 Azure 的加持，OSM 也得到了很强的助力。

不过上周 OSM 项目的官方博客发了一篇文章 OSM Project Update:

The OSM team has always been committed to meeting the needs of the community to deliver much-needed service mesh features to solve the current issues and develop the next generation of service mesh technologies. This decision will allow the team to help accelerate that realization. Additionally, there will be no more new releases of OSM.

其中提到 OSM 维护团队将会转向与 Istio 社区共同合作，来推进 Istio 的发展。并且 OSM 也不会再发布新的版本了。此外，OSM 也向 CNCF 申请了进行项目的归档，目前还没真正执行。

三年时间，还挺遗憾的，OSM 在一些简单和通用的场景已经足够，用做一个服务网格实现的参考也不错，我之前看了很多 OSM 的源码来着。

我现在主要就是关注 Azure 上 OSM 的部分会如何处理了。

Docker Desktop 4.19 正式发布

这个版本提供了一些比较显著的变更：

在 macOS 上，容器与主机之间的网络传输速度提高了5倍

在Docker Desktop 4.19 中，通过使用 gVisor 项目的 TCP/IP 堆栈替换 vpnkit 来使 macOS 上容器与主机之间的网络传输性能提高了5倍。

许多用户正在处理需要容器与本地Docker网络外部服务器通信的项目。其中一个例子是通过 npm install 或 apt-get 从互联网下载软件包的工作负载。这种性能改进应该会在这些情况下有所帮助。

如果发现任何问题，可以通过在Docker Desktop 的 settings.json 配置文件中设置 "networkType": "vpnkit" 来恢复使用旧版 vpnkit 网络堆栈。

这其实就是经常被诟病的一个点，如今终于有了解决办法。

  • docker init 支持了 NodeJS 和 Python，这是一个新的插件，用于初始化 Dockerfile 的。

docker init

如果对 Docker Desktop 新版本感兴趣的小伙伴欢迎进行升级体验，如果想要寻找替代品的话，可以尝试下 Lima：Docker Desktop for Mac 的免费开源且自由的替代品 | MoeLove

上游进展

Kubernetes 中提供了 leader election 机制，在早期版本中使用 Endpoints 或者 ConfigMaps，但是在实践中发现这种方式会带来一些非必要的负载以及一些其他的问题。

后来社区中引入了 Lease API，并逐步的将 Kubernetes 以及一些周边项目中关于 leader election 相关的实现都统一至使用 Lease API 。

比如我之前在 Kubernetes Ingress-NGINX 项目中就将基于 ConfigMap 的 leader election 机制，修改为了基于 Lease API 的实现。

kubectl events 的 --for 参数可以支持带有 full name 的资源名称了。

举个例子：在这个 PR 之前，如果执行如下命令将会报错：

(MoeLove) ➜ kubectl events -n apisix --for deployment.apps/apisix-ingress

但是如下命令可以正常工作：

(MoeLove) ➜ kubectl events -n apisix --for deployment/apisix-ingress

但是 deployment.apps/apisix-ingress 和 deployment/apisix-ingress 本质上是一样的。这个命令应该提供这样的兼容。

在这个 PR 中就添加了这样的支持，可以更加便于使用。

  • kubernetes-sigs/kubefed kubefed v1 项目已经正式被归档，其实这个讨论已经很久了，只不过最近才最终完成归档。

其他

以上就是本周的全部内容了，我们下期再见！

欢迎订阅我的文章公众号【MoeLove】

TheMoeLove

相关文章：

加载评论