The content of "K8S Ecological Weekly Report" mainly includes some recommended weekly information related to the K8S ecology that I have come into contact with. Welcome to subscribe to Zhihu column"k8s ecology".

Hello everyone, I am Zhang Jintao.

BuildKit v0.11 released

I have introduced BuildKit in many articles before. It is Docker's next-generation build engine. It is currently enabled by default in Docker Desktop, and it will also be enabled by default in the next version of Docker v23.0. Friends who are interested in the build engine in Docker can check my previous "Thousand-character long article: Thoroughly understand container image construction | MoeLove".

At the same time, it can also be used as an independent image building tool. After replacing the container runtime in the Kubernetes cluster from Docker to containerd, many people want to find a new image building tool. I recommend you to try BuildKit.

The development of BuildKit is still very good, there are already 6.3K stars. There's a lot to like in this release of v0.11.

Built-in Dockerfile frontend upgraded to v1.5
SBOM can be generated for the build result to see its related dependencies;
OCI annotations can be set for build results and exported as images;
The new Build History API allows listening to build start and finish, and build process events;
New remote cache: Azure Blob Storage and S3;
Supported Nydus format;

More about the changes in this version can be found in itsReleaseNote

OPA v0.48.0 released

Open Policy Agent In my previous article "Open Policy Agent (OPA) Getting Started | MoeLove" has been introduced, and interested friends can take a look.

The following noteworthy changes have been added to this release:

Improved error reporting for the opa eval command

For example, there are the following rules, because 0 cannot be used as a divisor, so it is obvious that both rules are wrong.

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 即可。

其他

Kubescape created by ARMO was accepted by CNCF as a sandbox level project, mainly as a Kubernetes security platform.

Welcome to subscribe to my article public account [MoeLove]

TheMoeLove

K8S Ecological Weekly | Podman began to discard CNI plugins and promote its own network stack