“「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”
大家好,我是张晋涛。
还有一周就春节了,想必有一些小伙伴已经开始休假了吧,提前祝大家新春快乐!
BuildKit 我以前有很多篇文章中都有介绍过了。它是 Docker 的下一代构建引擎,目前在 Docker Desktop 中已经默认启用,在 Docker 的下一个版本 v23.0 中也会默认启用,对 Docker 中构建引擎感兴趣的小伙伴可以查看我之前的 《万字长文:彻底搞懂容器镜像构建 | MoeLove》。
同时它也可以作为独立的镜像构建工具使用,很多人在将 Kubernetes 集群中的容器运行时从 Docker 替换为 containerd 后,想要寻找新的镜像构建工具,我推荐可以尝试下 BuildKit。
BuildKit 的发展还是很不错的,目前已经有 6.3K 的 star。本次发布的 v0.11 中有很多值得关注的内容。
更多关于此版本的变更可以查看其 ReleaseNote
Open Policy Agent 我在之前的文章 《Open Policy Agent (OPA) 入门实践 | MoeLove》进行过介绍,感兴趣的小伙伴可以看看。
本次发布的版本中增加了如下值得关注的变更:
例如有如下规则,因为 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
内置函数;更多关于此版本的变更可以查看其 ReleaseNote
在 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 支持上稍有不足,但是后续会补上,另外,该网络堆栈目前主要的一些特性包括:
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 。
所以目前在容器领域,基本可以认为存在有两个阵营,看后续的发展吧。
我之前写了一篇文章 GitOps 应用实践系列 - Argo CD 的基本介绍 | MoeLove ,Argo CD 是 Argo 生态中的一个项目。
Argo 生态目前主要由四个子项目组成,包括:
Argo Rollouts v1.4 中包含了一些主要的变更:
更多关于此版本的更新,请查看其 ReleaseNote
这是 KEP 135 的后续,在 Kubernetes v1.19 中废弃的 seccomp.security.alpha.kubernetes.io/pod
和 container.seccomp.security.alpha.kubernetes.io
这两个 annotation ,在这个 PR 中被彻底删除了。
用户如果想要使用 seccomp 相关配置,请正确设置 securityContext.seccompProfile
即可。
这是春节前的最后一篇 「K8S 生态周报」,祝大家新春快乐!年后继续更新!
[1]
k8s生态: https://zhuanlan.zhihu.com/container