Podmanのコンテナネットワークをrootlessで再設計する｜CNIからNetavarkへの切替と疎通確認

CNIからNetavarkへ——なぜバックエンドが変わったのか

Podman 4.0（2022年2月リリース）を境に、コンテナネットワークのデフォルトバックエンドがCNI（Container Network Interface）からNetavarkへ切り替わりました。2026年現在、RHEL 9・Fedora 38以降・Ubuntu 22.04 LTS向けのPodmanパッケージではNetavarkがすでに標準で組み込まれており、新規インストール環境でCNIを意識する機会は減っています。

とはいえ、既存のCNI構成のまま運用を続けているサーバや、古いコンテナイメージに同梱された設定ファイルが残存している環境も少なくありません。「なぜネットワークが繋がらないのか」「podman network lsの出力が想定と違う」といった問い合わせの背景には、CNIとNetavarkが混在しているケースが多く見られます。本記事では、切替の背景理解から実際の手順・疎通確認・切り戻しまでを一連の運用シナリオとして整理します。

CNIはKubernetesエコシステムから派生したプラグイン方式で、/etc/cni/net.d/にJSONで設定を記述し、実行バイナリをシェルから呼び出す仕組みです。柔軟性は高い反面、rootlessコンテナとの相性が悪く、ユーザー名前空間を跨ぐネットワーク操作に外部依存（slirp4netns）が必要でした。Netavarkは対照的に、PodmanプロジェクトがRustで内製したスタックで、ネットワーク名前空間の制御をより直接的に行います。DNS解決は別プロセスのAardvark-dnsが担い、コンテナ名による名前解決がすぐに機能するのが特徴です。

rootless Podmanとネットワーク名前空間の関係

rootlessコンテナとは、root権限を持たない一般ユーザーがコンテナを起動する運用形態です。カーネルのユーザー名前空間（user namespace）を利用するため、コンテナ内の「root」はホスト上の非特権ユーザーにマッピングされます。セキュリティ境界を強化できる一方、ネットワーク名前空間の操作には制約が生じます。

CNI時代のrootless Podmanは、外向き通信をslirp4netnsに依存していました。slirp4netnsはユーザー空間でTCP/UDPをエミュレートするプロセスで、信頼性は確保できるものの、オーバーヘッドが大きく、コンテナ間通信の設計に制限が伴いました。

Netavark環境では、rootlessコンテナでもpodman network createで作成したユーザー定義ネットワークを使えば、コンテナ同士がコンテナ名で直接通信できます。外向き通信についてはpastaというユーザー空間ネットワークスタックへの移行も進んでおり、Podman 5.x系ではpastaがslirp4netnsに代わるデフォルト候補として位置づけられています。

現在のバックエンド確認と切替前の準備

切替作業に入る前に、現在の環境がどのバックエンドを使っているかを確認します。

podman info | grep -A2 "networkBackend"

出力にnetworkBackend: netavarkと表示されていれば、すでにNetavark環境です。cniと表示されている場合は以下の手順で切替が必要です。

切替前に既存のネットワーク設定とコンテナ一覧を記録しておきます。

podman network ls
podman ps -a --format "{{.Names}}\t{{.Networks}}"

CNI時代に作成したカスタムネットワークはNetavark移行後に自動変換されません。ネットワーク定義を再作成する必要があるため、サブネットやゲートウェイ情報を事前に控えておきます。

podman network inspect <ネットワーク名> | grep -E '"subnet"|"gateway"'

設定ファイルの変更場所は~/.config/containers/containers.conf（rootlessの場合）または/etc/containers/containers.conf（システム全体）です。該当ファイルを開き、[network]セクションを確認します。

[network]
network_backend = "netavark"

この1行を追記または変更するだけで、次回以降のpodman networkコマンドがNetavarkを使用します。変更後、既存コンテナがある場合は一旦停止してから再起動するのが安全です。

Netavarkでのネットワーク再設計と疎通確認

バックエンドをNetavarkに切り替えたら、ユーザー定義ネットワークを作成し、コンテナ間通信が正しく機能するか確認します。

まず、サブネットを明示したネットワークを作成します。

podman network create --subnet 10.89.1.0/24 --gateway 10.89.1.1 myapp-net

次に、同一ネットワーク上に2つのコンテナを起動します。

podman run -d --name backend --network myapp-net docker.io/library/nginx:alpine
podman run -d --name frontend --network myapp-net docker.io/library/alpine sleep 3600

frontendコンテナからbackendコンテナへ、コンテナ名を使ったDNS名前解決で疎通できるかを確認します。

podman exec frontend ping -c3 backend
podman exec frontend wget -qO- http://backend/

CNI環境ではdnsnameプラグインを別途インストールしないとコンテナ名での名前解決ができませんでしたが、NetavarkではAardvark-dnsが自動で動作するため、追加設定なしに解決できます。ping backendが応答を返し、wgetがnginxのデフォルトページを返せば、Netavarkへの移行は正常に完了しています。

ホスト外への疎通も確認します。rootless環境でpastaが有効な場合、デフォルトネットワークへの接続はpastaが処理します。

podman exec frontend wget -qO- https://example.com | head -5

外部通信が失敗する場合は、podman info | grep pastaでpastaの有効状態を確認し、未インストールであればpastaパッケージを追加します（Fedora/RHELではpasstパッケージ）。

切り戻しと既知の注意点

Netavarkに切り替えた後で問題が生じた場合、containers.confのnetwork_backendをcniに戻すことでCNIに切り戻せます。ただし、Netavark環境で作成したネットワークはCNIから認識されないため、CNI側でも再作成が必要です。ネットワーク情報は~/.local/share/containers/storage/networks/（rootless）に保存されており、バックエンドごとにディレクトリが分かれています。

運用上よく遭遇する問題をいくつか挙げます。

• Aardvark-dnsが起動しない：aardvark-dnsパッケージが未インストールの場合に発生します。dnf install aardvark-dnsまたはapt install aardvark-dnsで解消します。
• 既存のCNIネットワークが表示される：バックエンド切替後も古いCNI定義ファイルが/etc/cni/net.d/に残ると、podman network lsに混在して表示されることがあります。不要なCNIファイルは手動で削除します。
• ポートフォワードが機能しない：rootless環境で1024番未満のポートをバインドしようとすると失敗します。sysctl net.ipv4.ip_unprivileged_port_startの値を確認し、必要なら下げるか、1024番以上のポートにマッピングします。
• firewalldとの競合：RHEL 9環境でfirewalldが有効な場合、Netavarkが作成するiptablesルールと競合することがあります。firewall-cmd --zone=trusted --add-interface=podman0 --permanentでインターフェースをトラステッドゾーンに追加すると解消するケースが多いです。

2026年の現行環境における差分と今後の動向

2026年時点での主要ディストリビューション別の状況を整理します。RHEL 9およびCentOS Stream 9では、Podman 4.x以降がデフォルトでNetavarkを使用します。Fedora 40以降ではPodman 5.x系が標準となり、rootless環境でのデフォルトネットワークにpastaが採用されています。Ubuntu 24.04 LTS（Noble Numbat）はPodman 4.xをAPTで提供しており、Netavarkとslirp4netnsの組み合わせが一般的です。Debian 12（Bookworm）はPodman 4.3系が収録されており、CNIからNetavarkへの移行期にあたります。

Podman 5.x系で注目すべき変更点は、podman networkコマンドのサブコマンド体系が整理され、podman network connectやpodman network disconnectの動作がNetavarkベースで安定したことです。また、Quadlet（systemdのユニットファイルでコンテナを管理する仕組み）との組み合わせで、rootlessコンテナのネットワーク設定をsystemdサービス定義に統合できるようになっています。

Netavark自体もRustコードベースのメンテナンスが活発で、2025年後半にはマルチホームネットワーク（コンテナを複数ネットワークに同時接続）の安定性が向上しています。CNIプラグインのエコシステムに依存していた高度なネットワーク設定も、Netavarkのネイティブ機能で賄えるケースが増えており、特別な理由がなければNetavarkへの移行を進めることが現在の標準的な判断といえます。

移行の優先度としては、新規構築環境ではNetavarkを迷わず選択し、既存のCNI環境は次回のメンテナンスウィンドウで計画的に切り替えるのが現実的な進め方です。上述の疎通確認手順をステージング環境で先に実施し、問題がないことを確認してから本番に適用するという手順が、運用現場での一般的なアプローチとなっています。