Podman 6.0.0がもたらした変更点｜cgroup v1廃止とAMD GPU対応

Podman 6.0.0が「節目」である理由

コンテナランタイムとして着実に採用が広がってきたPodmanが、2024年末から2025年初頭にかけてメジャーバージョン6系へと移行しました。メジャーバージョンアップという区切りは、単なる機能追加にとどまらず、後方互換を意図的に切る変更を含むことを意味します。Podman 6.0.0における最大の破壊的変更が cgroup v1サポートの廃止 であり、加えて AMD GPUのコンテナ内利用 という新機能が正式にサポートされました。

この2点は運用現場に対して正反対の意味合いを持ちます。cgroup v1廃止は既存環境への影響リスク、AMD GPU対応は機械学習・映像処理ワークロードへの扉を開く恩恵です。本記事ではそれぞれの背景と実際の確認・移行手順を、環境差分も含めて整理します。

cgroup v1廃止の背景

cgroup（Control Groups）はLinuxカーネルがプロセスのリソース使用量を管理する仕組みです。v1は2008年から存在するレガシー実装で、サブシステムごとに個別のヒエラルキーを持つ複雑な構造になっています。v2はそれを統一ヒエラルキーに整理し直したもので、カーネル4.5（2016年）から段階的に導入が進みました。

systemdは2019年のv244でcgroup v2をデフォルトに切り替え、主要ディストリビューションも追随してきました。Fedora 31（2019年）・RHEL 9（2022年）・Ubuntu 22.04（2022年）はいずれもcgroup v2のみで稼働します。Podman側でも以前からv2推奨の姿勢を明確にしており、6.0.0でv1のコードパスを正式に削除しました。

削除の主な理由は保守コストです。二系統のサポートを継続することで、バグ修正・新機能追加のたびにv1・v2双方での動作検証が必要になります。カーネルコミュニティもv1の積極的な機能追加を行っておらず、将来的な廃止が見込まれていることから、Podmanとしても切り離しのタイミングを6.0系に設定したとされています。

影響を受ける環境の見極め方

現在の環境がcgroup v1・v2のどちらを使用しているかは、次のコマンドで確認できます。

stat -fc %T /sys/fs/cgroup/

出力が cgroup2fs であればv2、tmpfs であればv1または混在モードです。RHEL 8系・CentOS 7・Debian 10以前の環境ではv1のままになっているケースがあります。特にオンプレ環境で長期稼働しているホストは要確認です。

v1のままのホストでPodman 6.x系を動かそうとすると、コンテナの起動時にエラーが返ります。エラーメッセージは環境によって異なりますが、「cgroup v2 is required」に類する文言が含まれる場合がほとんどです。アップグレード前に上記コマンドで事前確認することが現場での基本手順になります。

cgroup v2への移行手順の概要

カーネルがv2をサポートしているにもかかわらず、ブートパラメータでv1が明示されている場合があります。GRUBの設定ファイルで systemd.unified_cgroup_hierarchy=1 を追加し、再起動することでv2に切り替えられます。

# /etc/default/grub の GRUB_CMDLINE_LINUX に追記
GRUB_CMDLINE_LINUX="... systemd.unified_cgroup_hierarchy=1"

# GRUBを更新（UEFI環境の場合）
sudo grub2-mkconfig -o /boot/efi/EFI/$(ls /boot/efi/EFI/)/grub.cfg

再起動後、前述の stat コマンドで cgroup2fs になっていることを確認してから、Podman 6.x系のインストールへ進むのが安全な順序です。cgroup v2への移行はコンテナ外のsystemdサービスにも影響するため、ステージング環境で先行検証することを強く推奨します。

AMD GPUサポートの概要と利用シナリオ

Podman 6.0.0のもう一方の柱がAMD GPUのコンテナ内パススルー対応です。これまでNVIDIAのGPUはnvidia-container-toolkitを介してDockerおよびPodmanから利用できましたが、AMD製GPUはホスト側のROCm（Radeon Open Compute）ドライバと組み合わせた形での公式サポートが限定的でした。

Podman 6.0では --device フラグと --group-add フラグを組み合わせることで、コンテナにAMDのGPUデバイスを渡す手順が整理されました。ROCmに対応するPyTorchやTensorFlowのコンテナイメージを使えば、機械学習の推論・学習をコンテナ内で完結させられます。

podman run --device /dev/kfd --device /dev/dri \
  --group-add video \
  rocm/pytorch:latest \
  python3 -c "import torch; print(torch.cuda.is_available())"

上記の例では /dev/kfd（AMD GPU のカーネルフュージョンドライバ）と /dev/dri（Direct Rendering Infrastructure）をコンテナに渡しています。--group-add video はコンテナ内プロセスが video グループとしてデバイスにアクセスするために必要です。

利用シナリオとして現場で注目されているのは、データセンターでのAI推論サービスのコンテナ化です。NVIDIA一択だったGPU選定にAMDという選択肢が加わることで、調達コストや在庫リスクの分散が図れます。映像トランスコードやレンダリングのパイプラインをPodmanで管理したいケースにも適用の余地があります。

2026年時点での現行環境との差分

2026年7月時点で、主要ディストリビューションとPodman 6.x系の組み合わせは概ね安定した状態にあります。ただし、いくつかの環境固有の注意点が報告されています。

RHEL 9 / Rocky Linux 9 / AlmaLinux 9：cgroup v2はデフォルト有効であり、Podman 6.x系との組み合わせは基本的に問題ありません。ただし、SELinuxポリシーとAMD GPUデバイスアクセスの組み合わせでは、audit.log にdeniedが出るケースが確認されています。--security-opt label=disable で一時回避できますが、本番環境では適切なSELinuxコンテキスト設定を行うことが望ましいです。

Ubuntu 22.04 / 24.04：Snapdパッケージ版のPodmanはバージョンが古い場合があります。6.x系を利用する際はsnapではなくaptリポジトリまたはCubehouse PPAから導入する方が確実です。

Podman Desktop（GUI）との連携：Podman Desktopも6.x系のAPIに対応済みですが、拡張機能（Extensions）によっては6.0の変更点に追随していないものがあります。Podman Desktop側のバージョンも同時に確認する習慣をつけておくと、原因切り分けがスムーズです。

Kubernetes連携（podman generate kube）：cgroup v2前提のリソース制限が、一部のKubernetesバージョンとのマニフェスト互換性に影響する場合があります。Podman側で生成したKubernetesマニフェストをそのまま本番クラスタに適用する運用では、リソース制限の項目を重点的に確認してください。

切り戻し・トラブルシューティングの考え方

Podman 6.x系への移行後に問題が発生した場合、切り戻しの選択肢はいくつかあります。パッケージマネージャでのバージョン固定（apt-mark hold・dnf versionlock）で5.x系に留める方法が現実的です。ただし、cgroup v2への切り替えはPodman以外のサービスにも影響するため、cgroup設定とPodmanバージョンをセットで管理・記録しておくことが重要です。

AMD GPUが認識されない場合のチェックポイントは次の順序で確認するのが効率的です。まずホスト側でROCmドライバが正常にロードされているか（rocm-smi コマンドで確認）、次に /dev/kfd および /dev/dri デバイスが存在するか、最後にコンテナを実行するユーザが video グループに属しているかを確認します。

cgroup v2移行後のパフォーマンス変化については、一般的にはメモリ管理の精度向上が期待できますが、v1時代にチューニングしていたパラメータが意味を持たなくなるケースもあります。移行前後でリソース使用量の計測を行い、差分を記録する運用が、長期的な安定稼働の観点から有効です。

Podman 6.0.0はコンテナランタイムとしての成熟を示す一方で、レガシー環境を抱える組織には一定の移行コストをもたらします。変更の意図とスコープを正確に把握した上で、環境ごとの検証計画を立てることが、安定した移行の鍵となります。