K8S Ecological Weekly | Podman は CNI プラグインを破棄し、独自のネットワーク スタックを促進し始めました

「K8Sエコロジカルウィークリーレポート」の内容は、主に私が触れたK8Sエコロジーに関するおすすめの週刊情報です。Zhihu コラムの購読を歓迎します「k8s エコロジー」.

皆さんこんにちは、張錦濤です。

BuildKit v0.11 リリース

BuildKit については、これまで多くの記事で紹介してきました。これは Docker の次世代ビルド エンジンです. 現在、Docker Desktop でデフォルトで有効になっており、Docker v23.0 の次のバージョンでもデフォルトで有効になる予定です. Docker のビルド エンジンに興味のある友人は、私の前 "千字超長編記事: コンテナイメージ構築を徹底解説 | MoeLove"。

同時に、独立したイメージ構築ツールとしても使用できます. Kubernetes クラスタ内のコンテナ ランタイムを Docker から containerd に置き換えた後、新しいイメージ構築ツールを探したいという多くの人. BuildKit を試してみることをお勧めします.

BuildKit の開発は今でも非常に順調で、すでに 6.3K の星があります。この v0.11 のリリースには、気に入った点がたくさんあります。

  • v1.5 にアップグレードされた組み込みの Dockerfile フロントエンド
  • ビルド結果の SBOM を生成して、関連する依存関係を確認できます。
  • ビルド結果に OCI アノテーションを設定し、イメージとしてエクスポートできます。
  • 新しい Build History API を使用すると、ビルドの開始と終了、およびビルド プロセス イベントをリッスンできます。
  • 新しいリモート キャッシュ: Azure Blob Storage と S3。
  • サポートされている Nydus 形式。

このバージョンの変更点の詳細については、そのリリースノート

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 stackcontainers/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 Desktopyouki

这些项目基本上是对照着 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

上游进展

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

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

其他

  • ARMO が作成した Kubescape は、主に Kubernetes セキュリティ プラットフォームとして、サンドボックス レベルのプロジェクトとして CNCF に承認されました。

私の記事の公開アカウント [MoeLove] への登録を歓迎します。

TheMoeLove

おすすめ

転載: juejin.im/post/7194218389718433847