Container Runtime Meetup #5 Podman,CRI-O最新情報 (2024年春) Manabu Ori Red Hat 2024-02-21 1 v1.2

2 ▸ 名前: 織 学 (@orimanabu) ▸ 所属: Red Hat ▸ 仕事: OpenStack、OpenShiftのコンサルティング 自己紹介

3 Podman update

4 ▸ https://github.com/containers/podman ▸ コンテナを構築、管理、実行する次世代のコンテナエンジン ▸ Open Container Initiative（OCI）を標準フォーマットとして採用 ▸ Dockerとの互換性（コマンドライン、 Dockerイメージ、Compose、Docker互換API、など） ▸ Red Hatの開発チームを中心に OSSで開発 ▸ Fedora/CentOS/RHEL 系 Linux ディストリビューションに同梱 ･ RHEL8 以降、OS 同梱のコンテナエンジンが Docker から Podman に変更（RHEL 8以降は Docker非サポート） ･ Red Hat 製品の中ではPodmanが多く使われる ▸ Linuxだけでなく、macOS、Windowsでも使用可能 Podmanとは podman desktop

5 ▸ デーモンレス ▸ Fork & Execモデル ▸ ルートレス実行前提の設計 ▸ systemdとの連携 ▸ Kubernetesと互換のあるPod ▸ Podmanの関連ツール（Buildah、Skopeo） ▸ etc… Podmanの特徴

6 ▸ OCIランタイム ･ runc ･ crun ･ youki ･ kataはv2でShim v2のみのインターフェースとなり、 OCI compatible CLIの提供を止めたため Podmanで実行できなくなった (kata #722, podman #8579) ･ runscはrootlessでは動かない (gvisor #311) ▸ Networking ･ CNI ･ Netavark + Aardvark-DNS ･ iptables/nft/firewalld, slirp4netns/pasta, DNS ▸ バックエンドデータベース ･ Pod、コンテナ等の構成情報、終了ステータス等を格納 ･ BoltDB → SQLiteに移行 Podmanのコンポーネント (1)

7 ▸ ライブラリ ･ containers/storage ･ レイヤー化されたコンテナイメージを展開しルートファイルシステムを汲み上げる処理 ･ Dockerのgraphdriversからforkして大幅に書き換え ･ containers/image ･ コンテナレジストリからイメージを pullする処理 ･ containers/common ･ containers orgで共通に使う処理 ･ 入力のparse、systemdのscope操作、cgroup周りの操作、認証、sysinfo、seccomp、 capabilities、selinux/apparmor、設定ファイル関連、 etc ▸ conmon (container monitor) ･ コンテナのライフサイクルを管理する、 Cで書かれた小さい常駐プログラム ･ 1コンテナにつき1個のconmon ･ containerd-shimに相当 (コンテナプロセスのsubreaper) ･ ロギング、TTY制御、アタッチ処理、 etc Podmanのコンポーネント (2)

8 YoukiもRootless Podmanで動くようになりました！

9 Podman黎明期 (〜v4.0) Project begins Forked from CRI-O Was called kpod 2017 2018 Podman v0.2 Released First public release Project is renamed Podman Move fast with weekly releases Podman v1.0 Released First stable release Default in RHEL 8 2019 2020 Podman v2.0 released First release with REST API Beginning of modern Podman Podman v3.0 released First release with Compose support 2021 2022 Podman v4.0 and v4.1 released New network stack

10 ▸ 2022-02 v4.0.0 ▸ 2022-02 v4.0.1 ▸ 2022-03 v4.0.2 ▸ 2022-04 v4.0.3 Podman history (v4.0〜) ▸ 2022-05 v4.1.0 ▸ 2022-06 v4.1.1 ▸ 2022-08 v4.2.0 ▸ 2022-09 v4.2.1 ▸ 2022-10 v4.3.0 ▸ 2022-11 v4.3.1 ▸ 2023-02 v4.4.0 ▸ 2023-02 v4.4.1 ▸ 2023-02 v4.4.2 ▸ 2023-03 v4.4.3 ▸ 2023-03 v4.4.4 ▸ 2023-04 v4.5.0 ▸ 2023-05 v4.5.1 ▸ 2023-06 v4.6.0 ▸ 2023-08 v4.6.1 ▸ 2023-08 v4.6.2 ▸ 2023-09 v4.7.0 ▸ 2023-10 v4.7.1 ▸ 2023-10 v4.7.2 ▸ 2023-11 v4.8.0 ▸ 2023-12 v4.8.1 ▸ 2023-12 v4.8.2 ▸ 2024-01 v4.8.3 ▸ 2024-01 v4.9.0 ▸ 2024-02 v4.9.1 ▸ 2024-02 v4.9.2 ▸ 2024-02 v4.9.3 ▸ 2024-02-08 v5.0.0-rc1 ▸ 2024-02-16 v5.0.0-rc2

11 ▸ 互換性のない破壊的なAPI変更 ▸ cgroups v1の非推奨化 (v6で非サポート予定) ▸ BoltDBからSQLiteへの変更 ･ 過去バージョンからのアップグレード時は引き続きBoltDBを使用 ▸ コア部分はほぼ安定、podman machine周りはまだ不安定 ･ macOS: Apple Hypervisor ･ Windows: WSL2 ▸ 予定 ･ 2/8にv5.0.0-rc1がリリース (2/20現在、v5.0.0-rc2) ･ 3月はじめにGA...できるといいな... (Fedora40) Podman v5.0

12 ▸ 互換性を目指してはいますが... Dockerとのコマンドラインオプションとの違いを見てみる podman run vs docker run podman build vs docker build https://docs.google.com/spreadsheets/d/1SFqvwQS9Tl_520fTxFFJFSLah42a6hRMTx0Ml3ceXuo/edit?usp=sharing

13 ▸ 互換性を目指してはいますが... Dockerとのコマンドラインオプションとの違いを見てみる podman ps vs docker ps podman kill vs docker kill https://docs.google.com/spreadsheets/d/1SFqvwQS9Tl_520fTxFFJFSLah42a6hRMTx0Ml3ceXuo/edit?usp=sharing

14 ▸ ネットワークプラグイン ･ 従来のCNI pluginから、以下の組み合わせに変更 ･ Netavark https://github.com/containers/netavark ･ Aardvark-dns https://github.com/containers/aardvark-dns ･ v4.0で登場、v4.4からPodman新規インストール時は Netavarkがデフォルトに ･ CNIはdeprecated(非推奨)扱い、v5.0から使えなくなる ･ CNI deprecation and removal from Podman 5.0 https://blog.podman.io/2023/11/cni-deprecation-and-removal-from-podman- 5-0/ ･ 複数ネットワーク接続、 IPv6等のサポート ▸ ユーザーモードネットワーク ･ pastaのサポート ･ https://github.com/containers/podman/pull/16141 ･ https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstraction ･ slirp4netnsに比べてパフォーマンスがよく、 IPv6をサポートしている ネットワークスタック

15 ▸ Podmanコンテナとsystemdとの連携をより簡単に、宣言的に行うための仕組み ▸ 従来: ･ podman generate system → service unitファイルを生成 ▸ Quadletの場合: ･ Quadlet用のsystemd generatorファイルを作成し、所定のディレクトリに配置する ･ Quadletがサポートするgenerator: .volume, .network, .image, .container, .kube ･ 配置先: ･ /etc/containers/systemd (rootful) ･ ${HOME}/.config/containers/systemd (rootless) ･ generatorを手動で呼び出して service unitファイルを生成する ･ systemctl daemon-reload (rootful) ･ systemctl --user daemon-reload (rootless) ･ service unitは下記パスに生成される ･ /run/systemd/generator/*.service (rootful) ･ /run/user/${UID}/systemd/generator/*.service (rootless) Quadlet (1)

16 ▸ generatorファイルの例 Quadlet (2) $ cat ${HOME}/.config/containers/systemd/redis.container [Unit] Description=Redis container [Container] Image=docker.io/redis PublishPort=6379:6379 User=999 [Service] Restart=always [Install] WantedBy=local.target

$ /usr/libexec/podman/quadlet -user -dryrun quadlet-generator[753080]: Loading source unit file /home/ori/.config/containers/systemd/redis.container ---redis.service--- [Unit] Description=Redis container SourcePath=/home/ori/.config/containers/systemd/redis.container RequiresMountsFor=%t/containers [X-Container] Image=docker.io/redis PublishPort=6379:6379 User=999 [Service] Restart=always Environment=PODMAN_SYSTEMD_UNIT=%n KillMode=mixed ExecStop=/usr/bin/podman rm -f -i --cidfile=%t/%N.cid ExecStopPost=-/usr/bin/podman rm -f -i --cidfile=%t/%N.cid Delegate=yes Type=notify NotifyAccess=all SyslogIdentifier=%N ExecStart=/usr/bin/podman run --name=systemd-%N --cidfile=%t/%N.cid --replace --rm --cgroups=split --sdnotify=conmon -d --user 999 --publish 6379:6379 docker.io/redis [Install] WantedBy=local.target 17 ▸ generatorからservice unitを生成 (ドライラン) Quadlet (3)

18 ▸ ユーザーのログインシェルを、 Quadletで定義されたPodmanコンテナにする仕組み ･ ユーザーがアクセスできるボリュームマウントや、 Capability設定等をQuadletで定義する ▸ ユーザーからのリソースアクセスはコンテナ環境に制限される ･ SELinuxはじめ、標準的なコンテナのリソース分離の仕組みを活用 ▸ ユーザーからの複数のログインは同じコンテナを使用する ･ ユーザーからの全て接続が終了するとコンテナは終了する ▸ Podman v4.6 Introduces Podmansh: A Revolutionary Login Shell ･ https://blog.podman.io/2023/08/podman-v4-6-introduces-podmansh-a-revolutionary-lo gin-shell/ Podmansh (1)

19 Podmansh (2) # useradd -s /usr/bin/podmansh lockedu # grep lockedu /etc/passwd lockedu:x:4008:4008::/home/lockedu:/usr/bin/podmansh # USER_ID=$(id -u lockedu) # mkdir -p /etc/containers/systemd/users/${USER_ID} # cat > /etc/containers/systemd/users/${USER_ID}/podmansh.container << _EOF [Unit] Description=The Podmansh container After=local-fs.target [Container] Image=registry.fedoraproject.org/fedora ContainerName=podmansh RemapUsers=keep-id RunInit=yes DropCapability=all NoNewPrivileges=true Exec=sleep infinity [Install] RequiredBy=default.target _EOF

20 ▸ 複数の異なるCPUアーキテクチャのPodman Machineに対してコンテナビルドを実行する ▸ ビルドしたコンテナイメージは podman farmを実行した手元に転送され、ひとつのイメージ Manifestとし て登録される Build Farm podman farm create NAME CONNECTION1 CONNECTION2 ... podman farm --farm NAME build -t TAG -f Dockerfile . podman farm list デモ動画: https://asciinema.org/a/V6WufoZX0Kglvlgq2YfmqZhH7

21 Build Farm (2)

22 Build Farm (3)

23 Build Farm (4)

24 ▸ macOS: Apple Virtualization.framework ･ MVP for Podman Machine with AppleHV #18402 ･ サポートツール ･ vfkit https://github.com/crc-org/vfkit ･ Apple Hypervisor.frameworkのGo bindingであるvzを使ったCLI ･ gvproxy https://github.com/containers/gvisor-tap-vsock ･ vsockを使ってホスト↔ゲスト通信をプロキシする ･ https://fedorapeople.org/groups/podman/testing/applehv/ ▸ Windows: Hyper-V ･ basic hypverv machine implementation #17838 ･ WSLではFedora CoreOS (FCOS) を実行することが難しい ･ Ignitionを渡せないため ･ 現時点でのWindows版Podmanでは、FCOSではなくFedoranのイメージを使っている ･ Podman開発陣としては、Windows版もFCOSにそろえたい → Hyper-Vで頑張る ･ https://fedorapeople.org/groups/podman/testing/hyperv/aarch64/ Native Hypervisor Support % ./bin/darwin/podman machine ls NAME VM TYPE CREATED LAST UP CPUS MEMORY DISK SIZE applehv applehv About a minute ago Currently running 4 2GiB 100GiB

25 ▸ 仕掛けその1: crun実行時にrun.oci.handlerを指定することで、実行時のハンドラを指定することができる ･ https://github.com/containers/crun/blob/main/crun.1.md#runocihandlerhandler ▸ 仕掛けその2: libkrunを使ってKVM仮想化環境の中でプロセスを実行する ･ libkrun: プロセスをKVM仮想環境内で実行できるようにするライブラリ ･ https://github.com/containers/libkrun ▸ crun実行時にrun.oci.handlerでkrunを指定 → crunがlibkrunをdlopen(3)し、コンテナをKVM仮想環境内で実行 PodmanでコンテナをKVM isolation実行

26 ▸ プロセスをKVM仮想環境内で実行できるようにするライブラリ ･ https://github.com/containers/libkrun ･ https://kvmforum2021.sched.com/event/ke36/libkrun-more-than-a-vmm-in-dynamic-libr ary-form-sergio-lopez-pascual-red-hat ▸ Kataよりも軽量、最小限の virtioデバイス ･ virtio-console ･ virtio-vsock (specialized for TSI, Transparent Socket Impersonation) ･ virtio-fs ･ virtio-baloon (only free-page reporting) ･ virtio-rng ･ virtio-block (for AMD SEV) ▸ 去年末にブログ記事書きました ･ libkrunで遊ぶ ･ libkrunでのネットワーク通信 libkrun

27 Podman+crun+libkrunでKVM isolation実行 ● crun+libkrunでコンテナを実行する $ podman run -d \ -v /dev/kvm:/dev/kvm \ --annotation=run.oci.handler=krun \ --name nginx nginx ● コンテナプロセスのPIDを確認する ● KVMの仮想環境でコンテナプロセスが動いていることを確認する $ ls -l /proc/${pid}/fd | grep kvm lrwx------. 1 ori ori 64 Nov 16 00:40 19 -> anon_inode:kvm-vm lrwx------. 1 ori ori 64 Nov 16 00:43 29 -> anon_inode:kvm-vcpu:0 lrwx------. 1 ori ori 64 Nov 16 00:43 31 -> anon_inode:kvm-vcpu:1 lrwx------. 1 ori ori 64 Nov 16 00:43 33 -> anon_inode:kvm-vcpu:2 lrwx------. 1 ori ori 64 Nov 16 00:43 35 -> anon_inode:kvm-vcpu:3 lrwx------. 1 ori ori 64 Nov 16 00:43 37 -> anon_inode:kvm-vcpu:4 lrwx------. 1 ori ori 64 Nov 16 00:43 39 -> anon_inode:kvm-vcpu:5 lrwx------. 1 ori ori 64 Nov 16 00:43 41 -> anon_inode:kvm-vcpu:6 lrwx------. 1 ori ori 64 Nov 16 00:43 43 -> anon_inode:kvm-vcpu:7 $ podman inspect nginx | jq '.[].State.Pid' 190597 $ pid=$(podman inspect nginx | jq '.[].State.Pid') $ ps -p ${pid} f PID TTY STAT TIME COMMAND 190597 ? Ssl 0:00 [libcrun:krun] /docker-entrypoint.sh nginx -g daemon off;

28 Podman+crun+WasmEdgeでWasmバイナリを実行 ● Wasmバイナリを生成する準備をする $ rustup target add wasm32-wasi ● Wasmバイナリをビルドする ● Wasmバイナリをそのまま実行してみる $ wasmedge target/wasm32-wasi/debug/hello.wasm world hello world ● Dockerを作成する $ cat > Dockerfile <

29 Wasm実行方法の違い Podman / CRI-O Docker / Containerd

30 ▸ crun-vm (少し前までcrun-qemuという名前でした) https://github.com/containers/crun-vm Podmanで仮想マシンを実行 …

31 ▸ crun-vm (少し前までcrun-qemuという名前でした) https://github.com/containers/crun-vm Podmanで仮想マシンを実行 …

32 ▸ 2024-02-20 (昨夜) のPodman Community Cabal Meetingで、podman-composeをどうするかにつ いて議論がありました ▸ 背景 ･ PodmanでComposeを実行するには、現状 2つのやり方がある ･ Docker Compose (Dockerのバイナリを使用) → だいたいうまく動く ･ podman-compose (コミュニティでスクラッチ開発したもの、 Pythonで実装) → いろいろ足りない機能が多く、あまり開発も活発ではない、でも名前だけ見てこっちを 試して文句を言う人が結構多い ▸ 現状 ･ 278 issues、10ヶ月リリースなし、7ヶ月メンテナからの返信がない (via email/GitHub) ･ Red Hatに支援を求められたが (containers orgのプロジェクトという理由で )、Red Hat的にはで きることがあまりなさそう ･ (元々Red Hatの人は関与していなかった ) ▸ 議論 ･ 新しいメンテナ候補はいるっぽい ･ 名前を変える？ containers umbrellaに残す？残さない？ ▸ 方針 ･ もうちょっと様子を見る、名前を変えるかどうかは一旦保留 ･ Fedora 40にはもうパッケージが入っている ･ Fedora 41 or 42の時期までには結論を出したい podman-compose問題

33 ▸ 動作環境: macOS, Windows, Linux ▸ コンテナの管理 (build, run, etc) ･ Docker Compose ▸ Podの管理 (PodmanもしくはKubernetesで実行) ･ Kind ･ OpenShift Local ･ 外部のKubernetes/OpenShift ▸ イメージ管理 ･ 複数のレジストリに対してtag, push, pull, etc Podman Desktop

Linux Mac Windows Virtualization Stack WSL ➡ HyperV [1] podman-client [1] HyperV under active development [2] Apple Hypervisor support in early (but active) planning QEMU ➡ Apple HV [2] podman-client Native podman or podman-client Desktop Client Electron Cross-platform framework to desktop applications. UI Framework Node.JS Tailwind CSS - CSS framework Svelte - Reactive UI/UX framework 34 Podman Desktop: Behind the Scenes

Supports Docker Desktop extensions But Podman Desktop extensions can also do much more: ➤ Container engine providers ➤ Kubernetes providers ➤ Add actions ➤ Add menus ➤ Add configuration ➤ Add default registries ➤ Add to status bar ➤ Add to system tray Current extensions: Podman Docker Kind OpenShift Local Lima 35 & more! Extensibility with Podman Desktop

36 ▸ Podmanの生みの親であるDaniel Walshによる原著 ･ https://www.manning.com/books/podman-in-action ▸ Red Hatの有志で翻訳 ▸ デーモンレス、Fork & Execモデルの実行、ルートレス等の設計 思想や仕組みについて詳しく解説 ▸ https://www.amazon.co.jp/dp/4798070203/ 「Podmanイン・アクション」でました

37 Dan WalshとDocker Inc. https://lwn.net/Articles/676831/ I say no to systemd specific PRs https://twitter.com/Docker/status/747945675380260864 accept no imitations...

38 ▸ Improvements for Podman Machine ･ Native Apple hypervisor support ･ Windows Hyper-V hypervisor support ▸ Faster container startup ▸ Enhancements for Podman’s Kubernetes YAML support ▸ Better rootless networking Podmanの今後

39 CRI-O update

40 ▸ https://github.com/cri-o/cri-o ▸ KubernetesからgRPCでCRIの命令を受け、OCI準拠のコンテナを管理する高レベルランタイム ▸ 2023年7月に無事CNCF graduated projectになりました ▸ Kubernetesから呼び出されることにフォーカス ･ Kubernetesの全e2eテストを通す ･ それ以外のユースケースはスコープ外、余計な機能は入れない ･ 例: コンテナイメージのpullはできるがpushの機能はない ･ サポートのライフサイクル、バージョン (major, minor)もKubernetesにアライン ･ CRI-O v1.29.*はKubernetes v1.29.*で稼働 ･ CRI-O v1.28.*はKubernetes v1.28.*で稼働 ▸ セキュリティ、パフォーマンス、安定性を重視 ▸ 開発メンバーの所属 : Red Hat, SuSE, Intel, IBM, ... ▸ CRI-Oを使用する製品/サービス ･ Red Hat OpenShift, Oracle Linux Cloud Native Environment, Lyft, Reddit, Adobe, ... ･ https://github.com/cri-o/cri-o/blob/main/ADOPTERS.md ▸ CRI-Oとは

41 アーキテクチャ https://cri-o.io/assets/images/architecture.png

42 ▸ OCIランタイム ･ runc, crun, kata ▸ ライブラリ ･ containers/storage ･ レイヤー化されたコンテナイメージを展開しルートファイルシステムを汲み上げる処理 ･ Dockerのgraphdriversからforkして大幅に書き換え ･ containers/image ･ コンテナレジストリからイメージを pullする処理 ･ containers/common ･ containers orgで共通に使う処理 ･ 入力のparse、systemdのscope操作、cgroup周りの操作、認証、sysinfo、 seccomp、capabilities、selinux/apparmor、設定ファイル関連、 etc ▸ CNI plugins ▸ conmon (container monitor) ･ コンテナのライフサイクルを管理する、 Cで書かれた小さい常駐プログラム ･ 1コンテナにつき1個のconmon ･ containerd-shimに相当 (コンテナプロセスのsubreaper) ･ ロギング、TTY制御、アタッチ処理、 etc CRI-Oのコンポーネント

43 CRI-O history ▸ 2021-12 v1.23.0 ▸ 2022-02 v1.23.1 ▸ 2022-03 v1.23.2 ▸ 2022-06 v1.23.3 ▸ 2022-10 v1.23.4 ▸ 2023-01 v1.23.5 ▸ 2022-05 v1.24.0 ▸ 2022-06 v1.24.1 ▸ 2022-08 v1.24.2 ▸ 2022-10 v1.24.3 ▸ 2023-01 v1.24.4 ▸ 2023-04 v1.24.5 ▸ 2023-06 v1.24.6` ▸ 2022-08 v1.25.0 ▸ 2022-10 v1.25.1 ▸ 2023-01 v1.25.2 ▸ 2023-04 v1.25.3 ▸ 2023-08 v1.25.4 ▸ 2023-11 v1.25.5 ▸ 2022-12 v1.26.0 ▸ 2023-01 v1.26.1 ▸ 2023-03 v1.26.2 ▸ 2023-04 v1.26.3 ▸ 2023-07 v1.26.4 ▸ 2023-04 v1.27.0 ▸ 2023-07 v1.27.1 ▸ 2023-12 v1.27.2 ▸ 2024-01 v1.27.3 ▸ 2023-08 v1.28.0 ▸ 2023-09 v1.28.1 ▸ 2023-11 v1.28.2 ▸ 2024-01 v1.28.3 ▸ 2023-12 v1.29.0 ▸ 2024-01 v1.29.1

44 ▸ Seccomp default対応 ･ https://kubernetes.io/blog/2021/08/25/seccomp-default/ ･ seccompのデフォルト設定をUnconfinedからRuntimeDefaultに変更する ･ kubeletの--seccomp-default ･ CRI-Oではseccomp profileが空の場合、UnconfinedではなくRuntimeDefaultに設定する ▸ Seccomp notifierサポート ･ https://kubernetes.io/blog/2022/12/02/seccomp-notifier/ ･ seccompによって発生したイベントをカーネルからユーザーランドに通知する仕組み ･ Linux 5.9+, runc v1.1.0+ (or crun v0.19+), CRI-O v1.26.0+ ▸ Capabilities ･ 以下を追加でドロップ (#1240) ･ CAP_AUDIT_WRITE ･ CAP_MKNOD ･ CAP_NET_RAW ･ CAP_SYS_CHROOT ･ でもCAP_SYS_CHROOTはやっぱり戻した (#1373) 最近の主な変更点 (1)

45 ▸ conmon-rs ･ (後述) ▸ User namespace ･ 独自annotationで先行実装 (#3944) ･ 例: io.kubernetes.cri-o.userns-mode: "private:uidmapping=0:1000:5000;gidmapping=0:1000:4000" ･ 後にk8sのuserns設計方針が固まったのに合わせて、独自 annotationはdeprecate (#6004, #7592) ･ pod.spec.hostUsers: false ▸ Sigstore対応 ･ Podmanでsign & push → CRI-Oでpull & verify ･ Rekor, Fulcioを使用 ･ (GPGを使ったイメージの署名検証は CRI-Oは以前から対応済み ) ･ CRI-Oのリリースバイナリを cosignで署名して配布 ▸ Evented PLEG対応 ･ (後述) ▸ CNCF Graduation ･ (後述) 最近の主な変更点 (2)

46 ▸ Checkpoint & Restore対応 ･ https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/ ･ KEP2008 (Forensic Container Checkpointing) ･ まずはforensic analysis目的？ ▸ CRI stats/metrics対応 ･ KEP2371 (cAdvisor-less, CRI-full Container and Pod Stats) ･ 役割分担上、コンテナの stats/metricsはCRIランタイムが収集するべき (cAdvisorが越境している？) ･ cAdvisorがモノリシックで大きくなりすぎ ･ 現状、cAdvisorとCRIランタイムで重複した stats/metricsを取っている 最近の主な変更点 (3) /metrics/cadvisor /stats/summary /metrics/resource Node level stats Eviction manager Interpreted from Stats/Metrics object of CRI Still depends on cAdvisor

47 ▸ CNCF blog: Cloud Native Computing Foundation Announces Graduation of CRI-O ▸ 3年くらいかけてGraduation Processを遂行 ･ 多くのpaperworkは書くだけ ･ CI best practices badge ･ GOVERNANCE.md, OWNERS.md, MAINTAINERS.md ･ メンテナが複数の組織から参加していること ･ CRI-Oの場合、多くはRed Hat、それ以外はSuSE、Intel、IBM ･ 一番大きなハードルは 3rd partyによるセキュリティ監査 ･ CNCF blog: OSTIF’s audit of CRI-O is complete – high severity issues found and fixed ･ OSTIF.org blog: Our Audit of CRI-O is Complete – High Severity Issues Found and Fixed ･ Full audit report: https://ostif.org/wp-content/uploads/2022/06/CRI-O-audit-by-ada-logics-chainguard-ostif.pdf ･ 余談 ･ CRI-Oのsecurity auditで見つかった脆弱性が Containerdでも該当することが発覚して Containerdでも 修正 → CVE-2022-31030 CNCF Graduation

48 ▸ conmonの課題 ･ コンテナごとに1個 (あとkubectl execするごとに1個)conmonが起動する ･ conmonのインターフェースは CLI呼び出し ･ Cで実装、glibを使用しており、スタティックリンクが難しい ▸ そこでconmon-rs ･ Rustで書き直し (with async tokio runtime) ･ メモリ使用率はconmonと同程度に小さい ･ Podごとに1個conmon-rsを起動するようにアーキテクチャを見直し ･ exec時のrespawningも必要なし ･ API提供、Golang client ･ Cap’n Protoを使用 https://capnproto.org/ ･ protocol bufferよりも高速、低フットプリント ･ 実装はだいたい一段落、テストも通過 ･ critest ･ CRI-O integration tests ･ k8s e2e node conformance and all feature tests ･ Podmanへの統合も計画中 conmon-rs https://kccncna2022.sched.com/event/182Ok/cri-os-senior-year-peter-hunt-urvashi-mohnani-mrunal-patel-red-hat https://github.com/containers/conmon-rs

49 ▸ PLEG = Pod Lifecycle Event Generator ▸ KubeletがCRI経由で定期的にコンテナの状態を取得して、ステータスを更新する ▸ 今の実装 (Generic PLEG) ･ CRI経由のコンテナ状態取得を Kubeletからポーリングで行う ･ CPU負荷が高い ･ 状態が変わっていなくても状態取得処理が走る ･ コンテナごとに並列で負荷がかかる ▸ Evented PLEG ･ CRI経由のコンテナ状態更新を CRI実装からのイベントに基づいて行う ･ イベントを使ってCRIから更新を受け取る ･ イベントの取りこぼしに対応するため、たまに relistする ▸ v1.26でAlpha、v1.27でBeta ▸ CRIランタイムのサポート ･ Containerd v1.7+ ･ CRI-O v1.26+ Evented PLEG

50 ▸ Rust based NRI framework ▸ WASM plugins loaded directly into CRI-O (instead of NRI) ▸ Handle wasm workloads as container images ▸ More portability for non-Linux 今後の予定 https://github.com/orgs/cri-o/projects/1/views/1

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 51 Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you

52 付録: Podmanリリースノート抜粋

53 ▸ 2022-02 v4.0.0 ･ v4.0紹介ブログ記事 ･ CVE-2022-1227 (Podman publishes a malicious image to public registries) ･ 新しいネットワークスタックとして Netavarkを追加 (デフォルトは引き続き CNI) ･ macvlan, ipvlanサポート ･ podman play kube, podman generate systemd, podman container checkpoint/restoreの改良 ･ podman dial-stdio追加 (for Docker compatibility) ･ --formatオプションのDocker互換性向上 ･ Breaking changes ･ Database schema migration ･ Docker compatible API improvement (shortnameの扱い等) ･ Podman API improvement ･ いくつかのサブコマンドの挙動の変更 (podman system reset等) ▸ 2022-02 v4.0.1 ▸ 2022-03 v4.0.2 ▸ 2022-04 v4.0.3 ･ CVE-2022-27649 (Podman's default inheritable capabilities for linux container not empty) Podman v4.0

54 ▸ 2022-05 v4.1.0 ･ v4.1紹介ブログ記事 ･ Docker Compose v2.2 or higherのサポート (ただしDOCKER_BUILDKIT=0) ･ podman machineで自動的に$HOMEをVMにマウント ･ podman container {checkpoint,restore}でOCIイメージへのアーカイブ保存をサポート ･ 新しいコマンド ･ podman container clone ･ podman machine inspect ･ podman volume {mount,unmount} ▸ 2022-06 v4.1.1 Podman v4.1

55 ▸ 2022-08 v4.2.0 ･ v4.2紹介ブログ記事 ･ Podman Desktop始動 ･ Gitlab Runnerサポート (Docker executor使用) ･ podman play kube強化 (Podのsystemd unit化等) ･ podman machine周りの改善いろいろ ･ podman events周りの改善いろいろ ･ 新しいコマンド ･ podman pod clone ･ podman volume reload ･ podman machine info ･ Docker compatible API v1.41 ･ A new macOS installer (via pkginstaller) ▸ 2022-09 v4.2.1 ･ podman image trust {set,show}のSigstore署名のサポート Podman v4.2

56 ▸ 2022-10 v4.3.0 ･ v4.3紹介ブログ記事 ･ Docker互換性の向上 (コマンドラインオプション等 ) ･ kube関連コマンドの整理 ･ podman generate kube → podman kube generate ･ podman play kube → podman kube play ･ podman kube強化(SecretやemptyDirのサポート等) ･ 新しいコマンド ･ podman generate spec ･ podman update ･ podman kube down (= podman kube play --down) ･ Windowsインストーラの改善 ･ podman machineのssh接続周りを再実装、多くの問題を解決 ･ FreeBSDへのポーティング進行中 ･ podman {create,run}のパフォーマンス改善 ▸ 2022-11 v4.3.1 Podman v4.3

57 ▸ 2023-02 v4.4.0 ･ v4.4紹介ブログ記事 ･ Podmanのsystemd unitを宣言的に記述できる quadlet (systemd-generator) 登場 ･ podman kube, podman events等の改善いろいろ ･ podman runで、checkpointで作成したイメージを実行できるように ･ healthcheckの強化 (regular healthcheck, startup healthcheck) ･ 新しいコマンド ･ podman buildx version ･ podman manifest annotate ･ podman system events (podman eventsのエイリアス) ･ podman kube apply ･ rootless時のネットワークスタックとして pastaをサポート (podman run --net=pasta) ･ CNIがdeprecated、Netavarkが推奨 ･ Windows on ARM64の実験的サポート ･ macOSのpkginstallerにおいて、podman-mac-helperをデフォルトでインストール Podman v4.4 (1)

58 ▸ 2023-02 v4.4.1 ･ デフォルトのcapabilities設定で、以下をドロップ ･ CAP_SYS_CHROOT, CAP_AUDIT_WRITE, CAP_NET_RAW, CAP_MKNOD ▸ 2023-02 v4.4.2 ･ CVE-2023-0778 (Podman Time-of-check Time-of-use (TOCTOU) Race Condition) ▸ 2023-03 v4.4.3 ･ CVE-2022-41723 (Uncontrolled Resource Consumption) ･ CAP_SYS_CHROOTをデフォルトのCapabilityに再度含める ▸ 2023-03 v4.4.4 Podman v4.4 (2)

59 ▸ 2023-04 v4.5.0 ･ v4.5紹介ブログ記事 ･ podman kube {play,generate}改善いろいろ ･ podman quadlet改善いろいろ ･ 新しいコマンド ･ podman secret exists ･ podman machine os apply ･ Pod内コンテナの自動アップデート ･ Netavark pluginのサポート ･ podman network create -d PLUGIN ･ Netavark plugin API (example plugins) ･ CAP_SYS_CHROOTをデフォルトのCapabilityに再度含める ･ podman imagesのパフォーマンス改善 ▸ 2023-05 v4.5.1 Podman v4.5

60 ▸ 2023-06 v4.6.0 ･ v4.6紹介ブログ記事 ･ イメージをDigest値で検索するときの動きを Docker v20.10.20に合わせて変更 ･ podman machine改善いろいろ ･ 安定性向上 ･ podman network改善いろいろ ･ podman quadlet改善いろいろ ･ FreeBSDでpodman system serviceサポート ･ 新しいコマンド ･ podmansh (ログインシェルをPodmanコンテナにしてホストへのリソースアクセスを制限する ) ▸ 2023-08 v4.6.1 ▸ 2023-08 v4.6.2 Podman v4.6

61 ▸ 2023-09 v4.7.0 ･ v4.7紹介ブログ記事 ･ podman kube改善いろいろ ･ podman quadlet強化いろいろ ･ podman generate systemdのdeprecate化、今後はpodman quadletを推奨 ･ 新しいコマンド ･ podman farm {create,list,remove,update} (異なるCPUアーキテクチャのイメージビルドをまとめて行う、実験的 サポート) ･ podman compose (docker-compose or podman-composeのwrapper) ▸ 2023-10 v4.7.1 ▸ 2023-10 v4.7.2 ･ GHSA-jq35-85cj-fj4p (/sys/devices/virtual/powercap accessible by default to containers) Podman v4.7

62 ▸ 2023-11 v4.8.0 ･ v4.8紹介ブログ記事 ･ Windows環境でのpodman machineとしてHyperVをサポート ･ Dockerfileのheredocサポート ･ podman machine {init,set} --usbでUSB passthroughのサポート ･ podman network create時のオプションとして vrfをサポート ･ podman run --rdt-class=Class_Of_Service (resctrlカーネルドライバを使って Intel RDT CATを利用) ･ 新規インストール時のバックエンドデータベースを SQLiteに変更 ･ Podmanのリモートクライアント実行時、 commitのプログレスバーを表示 ･ podman kube関連の改善 ･ podman quadlet関連の改善 ▸ 2023-12 v4.8.1 ▸ 2023-12 v4.8.2 ▸ 2024-01 v4.8.3 ･ CVE-2023-48795 (Prefix Truncation Attack against ChaCha20-Poly1305 and Encrypt-then-MAC aka Terrapin) Podman v4.8

63 ▸ 2024-01 v4.9.0 ･ podman farmのフルサポート ▸ 2024-02 v4.9.1 ▸ 2024-02 v4.9.2 ･ CVE-2024-23651 (BuildKit vulnerable to possible race condition with accessing subpaths from cache mounts) ･ CVE-2024-23652 (BuildKit vulnerable to possible host system access from mount stub cleaner) ･ CVE-2024-23653 (Buildkit's interactive containers API does not validate entitlements check) ▸ 2024-02 v4.9.3 Podman v4.9

64 付録: CRI-Oリリースノート抜粋

65 ▸ 2021-12 v1.23.0 ･ CRI v1alpha2 → v1 ･ PodAndContainerStatsFromCRI feature gateでの{,List}PodSandboxStatsのサポート ･ CNI plugin v1.0.1サポート ･ TARGET namespaceサポート (ephemeral container) ･ swap CRI fieldサポート ･ unified CRI fieldサポート (cgroup v2) ･ /run/.containerenvファイルの作成 (アプリがコンテナ内で稼働しているかを判断できるようにするため ) ･ OpenTelemetryのトレースデータを出力するオプションの追加 ▸ 2022-02 v1.23.1 ▸ 2022-03 v1.23.2 ･ CVE-2022-0811 (cri-o: Arbitrary code execution in cri-o via abusing “kernel.core_pattern” kernel parameter) ･ CDI device injectionサポート ▸ 2022-06 v1.23.3 ･ CVE-2022-1708 (Node DOS by way of memory exhaustion through ExecSync request in CRI-O) ▸ 2022-10 v1.23.4 ･ 高負荷時にPod作成に失敗した場合、どこまで進んだかをログに残るように変更 ･ CVE-2022-27652 (Incorrect Default Permissions in CRI-O) (その後リスクがほとんどないとして revert) ･ CVE-2022-1708 対応の改善 ▸ 2023-01 v1.23.5 CRI-O v1.23

66 ▸ 2022-05 v1.24.0 ･ デフォルトのseccomp profileとして、CAP_SYS_ADMINがなければコンテナからの unshare(2)呼び出しをブロック ･ seccomp defaultの準備として、空のruntime/defaultをデフォルトのseccompとして設定 ･ metrics追加 ･ conmon-rsの実験的サポート ･ CDI device injectionサポート ･ CNI plugin v1.1.1サポート ･ CVE-2022-27652 (Incorrect Default Permissions in CRI-O) ▸ 2022-06 v1.24.1 ･ CVE-2022-1708 (Node DOS by way of memory exhaustion through ExecSync request in CRI-O) ▸ 2022-08 v1.24.2 ･ CVE-2022-1708 対応の改善 ▸ 2022-10 v1.24.3 ･ CVE-2022-27652 修正のrevert (リスクがほとんどないため ) ･ minimal checkpoint/restart support ▸ 2023-01 v1.24.4 ･ CVE-2022-4318 (CRI-O vulnerable to /etc/passwd tampering resulting in Privilege Escalation) ･ CRI v1alpha2サポートのドロップ ･ conmon-rs経由のOTLP tracingサポート ･ Evented PLEGのサポート CRI-O v1.24

67 ▸ 2022-08 v1.25.0 ･ static binary bundleに対してSBOMおよびsigstore署名を提供 ･ cosignによるartifact signature検証、bomによるSPDXフォーマットのSBOM検証に対応 ･ (従来のCRI-O専用annotationではなく) k8sのuser namespace指定に対応 ･ 低消費電力設定のannotation追加 (CPU C-stateを指定) ･ minimal checkpoint/restart support ▸ 2022-10 v1.25.1 ･ CVE-2022-27652 修正のrevert (リスクがほとんどないため ) ･ 高負荷時にPod作成に失敗した場合、どこまで進んだかをログに残るように変更 ▸ 2023-01 v1.25.2 ･ CVE-2022-4318 (CRI-O vulnerable to /etc/passwd tampering resulting in Privilege Escalation) ･ CRI v1alpha2サポートのドロップ ･ conmon-rs経由のOTLP tracingサポート ･ Evented PLEGのサポート ･ seccomp notifier ･ NRI v0.2.0の実験的サポート ･ checkpointアーカイブをOCIイメージとしてコンテナレジストリに push可能に ▸ 2023-04 v1.25.3 ･ CVE-2022-4318 の追加対応 ▸ 2023-08 v1.25.4 CRI-O v1.25

68 ▸ 2022-12 v1.26.0 ･ CVE-2022-4318 (CRI-O vulnerable to /etc/passwd tampering resulting in Privilege Escalation) ･ CVE-2022-27652 修正のrevert (リスクがほとんどないため ) ･ 高負荷時にPod作成に失敗した場合、どこまで進んだかをログに残るように変更 ･ CRI v1alpha2サポートのドロップ ･ conmon-rs経由のOTLP tracingサポート ･ Evented PLEGのサポート ･ seccomp notifier ･ NRI v0.2.0の実験的サポート ･ checkpointアーカイブをOCIイメージとしてコンテナレジストリに push可能に ▸ 2023-01 v1.26.1 ▸ 2023-03 v1.26.2 ･ NRI関連の変更いろいろ (要設定変更) ▸ 2023-04 v1.26.3 ･ CNI plugin v1.2.0 ▸ 2023-07 v1.26.4 ･ CPU load balancingの設定をsysfs経由からcgroup経由で行うよう変更 (新しいカーネルでは sysfsの該当ファイル がread onlyになったため) CRI-O v1.26

69 ▸ 2023-04 v1.27.0 ･ NRI関連の変更いろいろ (要設定変更) ･ CNI plugin v1.2.0 ･ checkpointのメタデータにcheckpoint実施時刻を追加 ･ CPU load balancingの設定をsysfs経由からcgroup経由で行うよう変更 (新しいカーネルでは sysfsの該当ファイ ルがread onlyになったため) ▸ 2023-07 v1.27.1 ･ namespaced signiture policyのサポート ▸ 2023-12 v1.27.2 ･ CVE-2023-39325 (HTTP/2 rapid reset can cause excessive work in net/http) ･ CVE-2023-4448 (A vulnerability was found in OpenRapid RapidCMS 1.3.1 and...) ▸ 2024-01 v1.27.3 ･ CVE-2023-6476 (CRI-O's pods can break out of resource confinement on cgroupv2) CRI-O v1.27

70 ▸ 2023-08 v1.28.0 ･ namespaced signiture policyのサポート ･ 低消費電力設定のアップデート (CPU C-stateを指定) ･ annotationベースのseccomp notifierサポートの終了、k8s native wayの設定のみ ▸ 2023-09 v1.28.1 ▸ 2023-11 v1.28.2 ･ CVE-2023-39325 (HTTP/2 rapid reset can cause excessive work in net/http) ･ CVE-2023-4448 (A vulnerability was found in OpenRapid RapidCMS 1.3.1 and...) ▸ 2024-01 v1.28.3 ･ CVE-2023-6476 (CRI-O's pods can break out of resource confinement on cgroupv2) ･ cgroup v2対応のCPU load balancing用annotationの追加 ･ io.kubernetes.cri-o.Devices annotationのデフォルトのruntime classで許可するデバイスとして /dev/fuseを追加 CRI-O v1.28

71 ▸ 2023-12 v1.29.0 ･ CNI plugin v1.4.0 ･ user namespaceの使用方法をk8s native wayのみに (CRI-O特有の io.kubernetes.cri-o.userns-mode annotationをdeprecate) ･ cgroup v2対応のCPU load balancing用annotationの追加 ･ io.kubernetes.cri-o.Devices annotationのデフォルトのruntime classで許 可するデバイスとして /dev/fuseを追加 ▸ 2024-01 v1.29.1 ･ CVE-2023-6476 (CRI-O's pods can break out of resource confinement on cgroupv2) CRI-O v1.29