K8S 生态周报| Podman 开始废弃 CNI plugins, 推进自己的网络堆栈

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

大家好，我是张晋涛。

BuildKit v0.11 发布

BuildKit 我以前有很多篇文章中都有介绍过了。
它是 Docker 的下一代构建引擎，目前在 Docker Desktop 中已经默认启用，在 Docker 的下一个版本 v23.0 中也会默认启用，对 Docker 中构建引擎感兴趣的小伙伴可以查看我之前的 《万字长文：彻底搞懂容器镜像构建 | MoeLove》。

同时它也可以作为独立的镜像构建工具使用，很多人在将 Kubernetes 集群中的容器运行时从 Docker 替换为 containerd 后，想要寻找新的镜像构建工具，我推荐可以尝试下 BuildKit。

BuildKit 的发展还是很不错的，目前已经有 6.3K 的 star。本次发布的 v0.11 中有很多值得关注的内容。

• 内置的 Dockerfile 前端升级到了 v1.5
• 可以为构建结果生成 SBOM ，以便看到其相关的依赖；
• 可以为构建结果设置 OCI annotations 了，并将其导出为 images;
• 新的 Build History API 允许监听构建开始和完成，以及构建过程的事件；
• 新的 remote cache: Azure Blob Storage 和 S3;
• 支持了 Nydus 格式；

更多关于此版本的变更可以查看其 ReleaseNote

OPA v0.48.0 发布

Open Policy Agent 我在之前的文章 《Open Policy Agent (OPA) 入门实践 | MoeLove》进行过介绍，感兴趣的小伙伴可以看看。

本次发布的版本中增加了如下值得关注的变更：

改善了 opa eval 命令的错误报告

例如有如下规则，因为 0 不能作为除数，所以很明显这两个规则都是错误的。

package play

this_errors(number) := result {
        result := number / 0
}

this_errors_too(number) := result {
        result := number / 0
}

res1 := this_errors(1)

res2 := this_errors_too(1)

而且在 OPA 中，这其实会得到一个 undefined 的错误。

(MoeLove)➜  opa run
> 1/0
> undefined

为了便于调试，OPA 提供了 --strict-builtin-errors 参数，可以允许用户得到执行期间的发现的第一个错误，然后立即终止。效果如下：

(MoeLove)➜  opa eval --strict-builtin-errors -d multi-error.rego data.play
1 error occurred: multi-error.rego:4: eval_builtin_error: div: divide by zero

但很明显，只拿到第一个错误对于调试而言往往是不够的（需要不停的修正错误，然后再次调试，效率很低）。所以在这个版本中新增了 --show-builtin-errors 参数，允许展示所有发现的错误。效果如下：

(MoeLove)➜  opa eval --show-builtin-errors -d multi-error.rego data.play -f pretty
2 errors occurred:
multi-error.rego:4: eval_builtin_error: div: divide by zero
multi-error.rego:8: eval_builtin_error: div: divide by zero

其他

• 新增了 time.format 内置函数；
• 对于 rule 索引进行了一系列优化，索引的查找时间与规则数量成正比；
• 在 bundle fetch 的时候可以支持 AWS 的 Signature Version 4A (SigV4A) 方法了，以便于使用 Amazon S3 Multi-Region Access Points (MRAP);

更多关于此版本的变更可以查看其 ReleaseNote

Podman 开始废弃 CNI plugins

在 Podman 创建之初，它就使用 CNI 作为它的网络堆栈了，但是 CNI 毕竟不是 Podman 原生的组件，所以会有一些 Podman 中想要有的功能，但是 CNI 中并不打算支持，这实际上就出现了一些分歧。

所以 Podman 在去年的时候创建了自己的 containers/netavark: Container network stack 和 containers/aardvark-dns: Authoritative dns server for A/AAAA container records. Forwards other request to host's /etc/resolv.conf 项目，用来构建 Podman 自己的网络堆栈。

该项目经过一年时间的打磨和用户的反馈，目前与上游的 CNI 插件相比，只是在 MACVLAN 的 DHCP 支持上稍有不足，但是后续会补上，另外，该网络堆栈目前主要的一些特性包括：

• 通过 JSON 配置文件配置容器网络；
• 创建和管理网络接口，包括 MACVLAN 网络；
• 配置防火墙规则，NAT 和端口转发等能力；
• 目前支持 iptables 和 firewalld ，未来会支持 nftables ；
• 支持 rootless 容器；
• 支持 IPv4 和 IPv6；
• 可以通过 aardvark-dns 项目完成容器 DNS 解析的能力；

Podman 团队打算接下来开始废弃 CNI Plugins 的支持，但这可能会持续很长时间。目前 Podman 自己的网络堆栈是从 Podman 4.x 开始引入的，用户可以通过 podman info 命令查看自己在用的网络堆栈，比如：

$ sudo podman info
host:
  arch: amd64
  buildahVersion: 1.29.0-dev
  ...
  memFree: 16088698880
  memTotal: 33380950016
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.7.2-3.fc37.x86_64
    ...

在输出中的 networkBackend: netavark 就表示在用 Podman 自己的网络堆栈了。

其实这件事情也不算是啥大事儿，很多人可能根本没用过 Podman，但从这个事情中也反映出一些问题，以下是我的一些想法：

Podman 早期属于尽可能贴近开源社区和一些现成标准，然后基本上是照着 Docker 把所有的功能复制了一遍，所以早期宣传 Podman 的时候有一句话是：你可以添加一条 alias alias docker='podman' 完成替换。

后来随着 Podman 有了一些用户基础，开始照着 Docker 的生态构造自己的组件了，比如 Podman, Buildah, Skopeo, conmon-rs, crun, Podman Desktop 和 youki。

这些项目基本上是对照着 Docker 生态中的组件来自己实现了一遍，并且纳入到了该组织下。它的背后最主要的公司是 Red Hat 。

所以目前在容器领域，基本可以认为存在有两个阵营，看后续的发展吧。

Argo Rollouts v1.4 发布

我之前写了一篇文章 GitOps 应用实践系列 - Argo CD 的基本介绍 | MoeLove ，Argo CD 是 Argo 生态中的一个项目。

Argo 生态目前主要由四个子项目组成，包括：

• Argo Workflows -- 第一个 Argo 项目，是 Kubernetes 的原生工作流引擎，支持 DAG 和 step-based 的工作流；
• Argo Events -- Kubernetes 上的基于事件的依赖管理器，用于触发 Kubernetes 中的 Argo 工作流和其他操作。
• Argo CD -- 是 Argo 社区和 Intuit 带来的开源项目，支持基于 GitOps 的声明性部署 Kubernetes 资源。
• Argo Rollouts -- 支持声明式渐进式交付策略，例如 canary 、blue-green 和更多形式。

Argo Rollouts v1.4 中包含了一些主要的变更：

• 支持基于 revisions 的快速回滚，这在生产环境中想要快速回滚的时候，非常有用；
• 提供了 Apache APISIX Ingress 的支持，用户可以在这个版本中配合 Apache APISIX Ingress 进行渐进式交付；
• 允许为 canary 发布的时候设置最小 ReplicaSet 的 Pod 数；

更多关于此版本的更新，请查看其 ReleaseNote

上游进展

• Make seccomp annotations non-functional by saschagrunert · Pull Request #114947 · kubernetes/kubernetes

这是 KEP 135 的后续，在 Kubernetes v1.19 中废弃的 seccomp.security.alpha.kubernetes.io/pod 和 container.seccomp.security.alpha.kubernetes.io 这两个 annotation ，在这个 PR 中被彻底删除了。

用户如果想要使用 seccomp 相关配置，请正确设置 securityContext.seccompProfile 即可。

其他

• 由 ARMO 创建的 Kubescape 被 CNCF 接受成为了 sandbox 级别的项目，主要是作为 Kubernetes 安全平台。

---

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