「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】