MoeLove

K8S 生态周报| Lima 已正式加入 CNCF

 1688  4 分钟

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

大家好，我是张晋涛。

上周太忙，缺席了一周。本周继续更新。

cert-manager 成为 CNCF 孵化级项目

本周我花时间写了篇文章，介绍 cert-manager 如何通过 Vault 进行证书签发， 并且在 Apache APISIX Ingress controller 中配合使用，为部署在 Kubernetes 中的服务提供 TLS 代理。（这篇文章过几天会发布出来）

写文章的时候 cert-manager 还是 CNCF sandbox 级别的项目，写完它就已经成为 CNCF incubating 级别的项目了。

cert-manager 可以说是当前云原生场景下，证书管理方面应用最多的软件了。它除了可用于证书管理，还可以与多种服务集成，进行证书的签发和续期。 并且它还积极的融入到了很多项目的生态中，比如和各类 Ingress controller 项目的集成，和服务网格相关的项目进行整合等。

目前该项目已经有 9.4k star ,300 名贡献者。

本次成为 CNCF incubating 级别的项目，是个里程碑，希望它继续扩展生态。

(而且我想起来我草稿箱里还有一篇未完成的关于 cert-manager 的文章，过段时间抽空完成后再发出来)

nerdctl 正式发布 v1.0

去年在我为大家介绍 Docker Desktop 的替代品 Lima 的文章中，曾为大家介绍过 nerdctl 。

nerdctl 出现的原因是由于 containerd 项目的核心范围仅限于非面向用户的区域，因此用户很难直接与 containerd 进行交互。

nerdctl 的功能和用法几乎与 Docker CLI 相同，但是 nerdctl 还支持 Docker 中不存在的几个 containerd 的前沿功能。此类功能包括但不限于 延迟拉取(stargz) 和 运行加密镜像（ocicrypt）等。

到目前为止，nerdctl 已经开发了将近 2 年的时间，有超过 80 个贡献者和 4600 star ，以及大量的用户。这里我主要介绍几个 nerdctl 的重要阶段：

  • v0.3 (2020 年 12 月): nerdctl run --publish=<PORT>
  • v0.8 (2021 年 4 月): nerdctl compose up 支持 compose
  • v0.9 (2021 年 6 月): nerdctl run --gpus=<GPU> 支持 GPU
  • v0.13 (2021 年 11 月): nerdctl run --platform=<PLATFORM> 支持多平台
  • v0.19 (2022 年 4 月): nerdctl cp 支持文件复制
  • v0.22 (2022 年 7 月): nerdctl system prune 允许清理未使用的数据

到目前为止，nerdctl 已经实现了所有除了 swarm 相关的 Docker CLI 的命令，也额外实现了类似 nerdctl diff 之类的命令。

近期 nerdctl 有很多新的特性，比如：

  • 增加了多种日志驱动：journald , fluentd, syslog 和外部驱动；
  • 除了默认的 bridge CNI 外，还支持了 macvlan 和 ipvlan 网络驱动；
  • 支持了多种清理命令， nerdctl (container|image|volume|network|system) prune；

目前 containerd 正在被越来越多的 Kubernetes 集群使用，所以一个好用的 CLI 也非常的重要。 不出意外的话，以后 nerdctl 的用户应该会变的更多，期待它发展的更好。

此外另一个很重要的事情是： Lima 已经正式加入 CNCF 成为 Sandbox 级别的项目。 Lima 实际运行的就是 containerd 和 nerdctl ，这样也会加速 nerdctl 的发展。

Docker v20.10.20 发布

Docker 最近相继发布了 v20.10.19 和 v20.10.20，主要是一些 bugfix 和安全修复。这里我主要介绍一个比较有意思的 CVE-2022-39253 。

CVE-2022-39253

这个漏洞其实和 Docker 没有直接的关系。这个漏洞是 Git 的。

之所以在这里聊是因为 Docker 中进行 docker build 时，可以直接指向 Git 仓库进行构建。 在构建过程中，实际上会先将 Git 仓库拉入到本地的临时目录，并作为构建上下文传递给 Docker daemon 。

而且可以通过为指定的 Git 仓库后添加参数的方式来扩展具体构建使用的内容。比如：

2022-10-23.png

这次 Git 的 CVE-2022-39253 漏洞，是由于 Git 在 clone 的时候存在对本地仓库的优化，可以绕过 "Git aware" 的传输机制，然后可以通过硬链接的方式来节省空间。 但是攻击者可以通过诱导受害者在同一个机器上 clone 恶意仓库，并且利用这种硬链接的方式来将敏感信息暴露给恶意攻击者。

具体的修复方式包括避免使用 --recurse-submodules 和增加 protocol.file.allow=never 参数，以此来避免受漏洞的影响。

另外，这个漏洞也在 Git 的 2.37.4 之后的版本进行了修复。

其他修复

  • moby/moby#44122 通过更新 buildkit 的依赖，修复了执行 docker builder prune 和 docker system prune 期间可能出现的 panic ；
  • moby/moby#44238 修复了一个当已经开启 "live restore" 并进行了重启，当执行 docker volume prune 时，有可能会删掉仍然在使用的 volume ，解决办法是在 restore 的时候，先确保准备好了 volume ;
  • moby/moby#4b9902b 更新了 Docker daemon 在处理通过 digest pull 镜像时的处理逻辑，即使用 image:tag@digest 的形式。原先是直接通过内容寻址的方式直接获取镜像的，并没有利用到 tag 和 digest ，这有可能会被攻击者利用来运行已经存在于本地的镜像。现在 Docker daemon 将会检查 digest 是否与其名字匹配；

上游进展

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

TheMoeLove

相关文章：

加载评论