Docker以外のコンテナエンジン完全ガイド：初心者から実践まで

Last updated at 2025-11-03Posted at 2025-11-02

Docker以外のコンテナエンジン完全ガイド：初心者から実践まで

最終更新: 2025年11月（Kubernetes 1.34対応確認済み）

はじめに

「コンテナ = Docker」と思っている方も多いのではないでしょうか？実は、コンテナ技術の世界にはDocker以外にも様々な選択肢が存在します。本記事では、コンテナの基礎から始めて、Docker以外の主要なコンテナエンジンについて詳しく解説します。

2025年11月時点の最新情報

Kubernetes最新版: v1.34（v1.35リリース予定）
本記事は最新のKubernetes環境での動作を確認済みです

この記事で学べること

コンテナ技術の基本概念
Docker以外の主要なコンテナエンジンの特徴
各エンジンの使い分け方
実際のインストール手順と使用例

1. コンテナ技術の基礎知識

1.1 コンテナとは？

"アプリケーションとその依存関係をパッケージ化し、隔離された環境で実行する技術"です。仮想マシン（VM）と比較すると以下のような特徴があります：

項目	仮想マシン	コンテナ
起動時間	数分	数秒
リソース消費	大きい（OS全体）	小さい（必要な部分のみ）
隔離レベル	完全に隔離	プロセスレベルで隔離
ポータビリティ	低い	高い

1.2 コンテナエンジンとは？

"コンテナのライフサイクル（作成、実行、停止、削除）を管理するソフトウェア"です。主な機能は：

イメージ管理: コンテナの元となるイメージの作成・保存・配布
コンテナ実行: イメージからコンテナを起動・管理
ネットワーク管理: コンテナ間の通信設定
ストレージ管理: データの永続化

1.3 コンテナの標準規格

OCI（Open Container Initiative）: "コンテナの実行形式とイメージ形式の標準"
- OCI Runtime Spec: コンテナの実行方法の仕様
- OCI Image Spec: コンテナイメージの形式仕様
CRI（Container Runtime Interface）: "Kubernetesとコンテナランタイム間のインターフェース"

2. なぜDocker以外の選択肢が必要？

Dockerは素晴らしいツールですが、以下のような理由で代替手段が求められています：

2.1 ライセンスとコストの問題

"Docker Desktop（2021年9月以降）は大企業での商用利用が有料化"
小規模チームには無料だが、組織の規模によっては年間費用が発生

2.2 アーキテクチャの課題

Dockerはデーモンプロセス（dockerd）が必要
"デーモンがroot権限で動作するセキュリティリスク"
デーモンが停止すると全コンテナが影響を受ける

2.3 ユースケースの多様化

Kubernetes環境では軽量なランタイムが好まれる
CI/CD環境では特権なしで実行できる方が安全
マイクロサービスアーキテクチャでは特定用途に特化したツールが有効

3. 主要なコンテナエンジン詳細解説

3.1 Podman（ポッドマン）

概要

PodmanはRed Hatが開発する、Dockerの代替として最も人気のあるコンテナエンジンです。

主な特徴

1. デーモンレスアーキテクチャ

バックグラウンドデーモンが不要
コンテナは通常のプロセスとして実行
システムの安定性が向上

2. Rootless実行

root権限なしでコンテナを実行可能
"セキュリティリスクを大幅に削減"
マルチユーザー環境で安全に利用

3. Dockerとの互換性

dockerコマンドをpodmanに置き換えるだけで動作
Dockerfileをそのまま利用可能
Docker Hubなどのレジストリと互換

4. Podの概念

Kubernetes互換のPod（複数コンテナのグループ）をサポート
Kubernetesへの移行が容易

メリット

セキュリティが高い
Dockerからの移行が容易
Red Hatの商用サポートあり
systemdとの統合が優れている

デメリット

Docker Composeの完全互換性はない（podman-composeで対応可能）
Windowsネイティブサポートは限定的
エコシステムがDockerほど成熟していない

適用シーン

セキュリティを重視する環境
開発用マシンでのDockerの代替
CI/CDパイプライン
Linux環境での本番運用

インストールとクイックスタート

# macOS（Homebrewを使用）
brew install podman

# Podman Machine（macOS/Windows用）の初期化
podman machine init
podman machine start

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y podman

# RHEL/CentOS/Fedora
sudo dnf install -y podman

# バージョン確認
podman --version

# Nginxコンテナを実行
podman run -d -p 8080:80 --name web nginx

# コンテナ一覧表示
podman ps

# コンテナ停止と削除
podman stop web
podman rm web

Dockerコマンドとの対応

# Dockerコマンド → Podmanコマンド
docker run    → podman run
docker ps     → podman ps
docker build  → podman build
docker images → podman images

# エイリアスを設定すれば完全互換
alias docker=podman

3.2 containerd（コンテイナーディー）

概要

"containerdは、もともとDockerのコアコンポーネントとして開発され、現在はCNCF（Cloud Native Computing Foundation）のプロジェクト"です。

2025年11月時点の最新情報

最新版: containerd 2.0.x（2024年リリース）
安定版: containerd 1.7.x（メンテナンスフェーズ）
推奨: 新規構築は2.0.x、既存環境は1.7.xも利用可能
Ubuntu 24.04: 公式リポジトリは1.7.x、2.0.xはGitHubリリースから入手

主な特徴

1. 軽量でシンプル

コンテナ実行に必要な最小限の機能のみ
低レベルAPIを提供
オーバーヘッドが少ない

2. Kubernetes標準ランタイム

Kubernetesの推奨コンテナランタイム
CRI（Container Runtime Interface）に完全準拠
多くのマネージドKubernetesサービスで採用

3. 業界標準

"Docker、Kubernetes、AWS ECS、Google Cloud Runなどで使用"
OCI準拠
安定性と信頼性が高い

メリット

非常に軽量でパフォーマンスが高い
Kubernetesとの相性が抜群
安定した本番環境実績
CNCFプロジェクトで中立的

デメリット

CLIが基本的（高度な操作はnerdctlが必要）
初心者向けではない
Dockerのような統合開発体験はない
イメージビルド機能は別ツール（BuildKit）が必要

適用シーン

Kubernetesクラスタのランタイム
本番環境での軽量ランタイム
コンテナランタイムを組み込むプロダクト開発
クラウドネイティブアーキテクチャ

インストールとクイックスタート

方法1: Ubuntu公式リポジトリ（containerd 1.7.x）

# Ubuntu/Debianでのインストール
# 依存関係のインストール
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release

# Dockerの公式GPGキーを追加
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# リポジトリ設定
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# containerdのインストール
sudo apt-get update
sudo apt-get install -y containerd.io

# バージョン確認
containerd --version
# containerd containerd.io 1.7.x

# containerdの起動
sudo systemctl enable --now containerd

方法2: GitHubリリース（containerd 2.0.x - 最新版）

# 最新版のcontainerd 2.0.xをインストール
# バージョンを確認: https://github.com/containerd/containerd/releases

CONTAINERD_VERSION="2.0.6"

# バイナリのダウンロード
wget https://github.com/containerd/containerd/releases/download/v${CONTAINERD_VERSION}/containerd-${CONTAINERD_VERSION}-linux-amd64.tar.gz

# インストール
sudo tar Cxzvf /usr/local containerd-${CONTAINERD_VERSION}-linux-amd64.tar.gz

# systemdサービスファイルのダウンロード
sudo wget -O /etc/systemd/system/containerd.service https://raw.githubusercontent.com/containerd/containerd/main/containerd.service

# サービスの有効化と起動
sudo systemctl daemon-reload
sudo systemctl enable --now containerd

# バージョン確認
containerd --version
# containerd github.com/containerd/containerd v2.0.6

# 設定ファイルの生成
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

containerd 2.0への移行時の注意点

v1.xからv2.0への設定ファイル形式が変更されています
移行前に containerd config migrate コマンドで設定を検証
CRI v1alpha2は2.0で削除（v1.6/v1.7ではサポート継続）

nerdctl（Docker互換CLI）のインストール

# nerdctlのインストール（containerd 1.7/2.0共通）
NERDCTL_VERSION="1.7.6"
wget https://github.com/containerd/nerdctl/releases/download/v${NERDCTL_VERSION}/nerdctl-full-${NERDCTL_VERSION}-linux-amd64.tar.gz
sudo tar Cxzvf /usr/local nerdctl-full-${NERDCTL_VERSION}-linux-amd64.tar.gz

# コンテナ実行（nerdctlを使用）
sudo nerdctl run -d -p 8080:80 --name web nginx

# コンテナ一覧
sudo nerdctl ps

# イメージ一覧
sudo nerdctl images

containerdの設定

# デフォルト設定の生成
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 設定の編集（systemd cgroupドライバーを使用する場合）
sudo nano /etc/containerd/config.toml
# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
#   SystemdCgroup = true に変更

# containerdの再起動
sudo systemctl restart containerd

3.3 CRI-O（クライオー）

概要

"CRI-OはKubernetes専用に設計された軽量コンテナランタイム"で、Kubernetesとの統合に特化しています。

主な特徴

1. Kubernetes専用設計

CRI（Container Runtime Interface）の実装に特化
Kubernetesに不要な機能は一切なし
Kubernetesのバージョンに完全追従

2. OCI準拠

"Open Container Initiative標準に完全準拠"
runc、crun、Kataなど複数のランタイムをサポート
柔軟なアーキテクチャ

3. セキュリティ重視

最小権限の原則
SELinux、AppArmorとの統合
Seccompプロファイルのサポート

メリット

Kubernetes環境で最適化されたパフォーマンス
セキュリティが強化されている
Red Hat OpenShiftでデフォルト採用
Kubernetesとのバージョン同期が保証

デメリット

Kubernetes以外での使用は想定されていない
スタンドアロンでの開発用途には不向き
ドキュメントがKubernetes前提
学習リソースが限定的

適用シーン

Kubernetesクラスタ（特にセキュリティ重視）
Red Hat OpenShift環境
エンタープライズKubernetes環境
コンプライアンスが厳しい環境

インストール（Kubernetesノードでの例）

# Ubuntu 20.04でのインストール
# 前提条件
sudo apt-get update
sudo apt-get install -y software-properties-common curl

# CRI-Oリポジトリの追加（バージョン1.30用 - Kubernetes 1.34対応）
export OS=xUbuntu_20.04
export VERSION=1.30

echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -

# インストール
sudo apt-get update
sudo apt-get install -y cri-o cri-o-runc

# CRI-Oの起動
sudo systemctl enable --now crio

# ステータス確認
sudo systemctl status crio

# crictl（CRI-O CLI）の使用
sudo crictl version
sudo crictl images
sudo crictl ps

Kubernetesとの連携

Kubernetes 1.34対応の設定例
以下の設定はKubernetes 1.34環境で動作確認済みです。

# kubeadm設定例（/etc/kubernetes/kubeadm-config.yaml）
# Kubernetes 1.34対応 - v1beta4を使用
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  criSocket: unix:///var/run/crio/crio.sock
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

3.4 LXC/LXD（Linux Containers）

概要

"LXCはLinuxコンテナの老舗で、LXDはその上位レイヤー"です。仮想マシンとコンテナの中間的な「システムコンテナ」を提供します。

主な特徴

1. システムコンテナ

完全なLinuxシステムを実行
initシステム（systemd）を含む
仮想マシンに近い使用感

2. 長時間実行に最適化

ステートフルなワークロード向け
仮想マシン代替として利用可能
マイグレーション機能

3. LXD独自機能

RESTful API
イメージサーバー
クラスタリング機能
スナップショットとバックアップ

メリット

仮想マシンより軽量で高速
完全なLinux環境が利用可能
ネットワークとストレージの柔軟な管理
Canonicalのサポートあり

デメリット

アプリケーションコンテナ（Docker等）とは思想が異なる
イメージエコシステムが小さい
クラウドネイティブな用途には不向き
学習曲線がやや高い

適用シーン

開発・テスト環境
仮想マシンの軽量代替
ステートフルなアプリケーション
マルチテナント環境

インストールとクイックスタート

# Ubuntu/Debianでのインストール
sudo apt-get update
sudo apt-get install -y lxd

# 初期設定（対話式）
sudo lxd init
# デフォルト設定でEnterを押していくだけでOK

# ユーザーをlxdグループに追加
sudo usermod -aG lxd $USER
newgrp lxd

# 使用可能なイメージ一覧
lxc image list images: | grep ubuntu

# Ubuntu 22.04コンテナの作成と起動
lxc launch images:ubuntu/22.04 my-ubuntu

# コンテナ一覧
lxc list

# コンテナにシェルでログイン
lxc exec my-ubuntu -- /bin/bash

# コンテナの停止
lxc stop my-ubuntu

# コンテナの削除
lxc delete my-ubuntu

実践例：Webサーバーの構築

# Ubuntu 22.04でNginxサーバーを構築
lxc launch images:ubuntu/22.04 webserver

# コンテナに入る
lxc exec webserver -- bash

# コンテナ内でNginxインストール
apt update
apt install -y nginx
systemctl enable nginx
exit

# ポートフォワーディング設定
lxc config device add webserver myport80 proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80

# ブラウザでlocalhost:8080にアクセス

3.5 Buildah（ビルダー）

概要

"Buildahはコンテナイメージのビルドに特化したツール"です。Dockerfileを使わずにスクリプトでイメージを構築できます。

主な特徴

1. ビルド専用

イメージビルドのみに集中
実行はPodmanなど他のツールで行う
単一責任の原則

2. Dockerfileレス

Bashスクリプトでイメージ構築
より細かい制御が可能
Dockerfileも使用可能

3. レイヤー制御

レイヤーの作成タイミングを制御
最適化されたイメージサイズ
キャッシュ戦略の柔軟性

メリット

イメージサイズの最適化が容易
root権限不要でビルド可能
スクリプトによる自動化が簡単
既存のシェルスクリプト資産を活用

デメリット

学習曲線がDockerfileより高い
コンテナ実行は別ツールが必要
コミュニティがDockerより小さい
ドキュメントが限定的

適用シーン

CI/CDパイプライン
イメージサイズの最適化が重要な場面
複雑なビルドプロセス
Dockerfileでは表現しにくいビルド

インストールとクイックスタート

# Ubuntu/Debianでのインストール
sudo apt-get update
sudo apt-get install -y buildah

# RHEL/CentOS/Fedora
sudo dnf install -y buildah

# バージョン確認
buildah --version

# 基本的な使い方：Dockerfileからビルド
cat << 'EOF' > Dockerfile
FROM alpine:latest
RUN apk add --no-cache nginx
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
EOF

buildah bud -t my-nginx .

# スクリプトでイメージビルド（Dockerfileレス）
#!/bin/bash

# ベースコンテナの作成
container=$(buildah from alpine:latest)

# パッケージのインストール
buildah run $container apk add --no-cache nginx

# 設定ファイルのコピー
buildah copy $container ./nginx.conf /etc/nginx/nginx.conf

# ポート公開
buildah config --port 80 $container

# 起動コマンド設定
buildah config --cmd "nginx -g 'daemon off;'" $container

# イメージとしてコミット
buildah commit $container my-nginx:custom

# クリーンアップ
buildah rm $container

# イメージ一覧
buildah images

# イメージをPodmanで実行
podman run -d -p 8080:80 my-nginx:custom

高度な例：マルチステージビルド

#!/bin/bash

# ビルドステージ
builder=$(buildah from golang:1.21-alpine)
buildah run $builder apk add --no-cache git
buildah copy $builder . /app
buildah config --workingdir /app $builder
buildah run $builder go build -o myapp .

# ビルド成果物を取得
buildah mount $builder
container_path=$(buildah mount $builder)
cp $container_path/app/myapp ./myapp
buildah umount $builder

# 実行ステージ
runtime=$(buildah from alpine:latest)
buildah run $runtime apk add --no-cache ca-certificates
buildah copy $runtime ./myapp /usr/local/bin/myapp
buildah config --entrypoint '["/usr/local/bin/myapp"]' $runtime
buildah commit $runtime myapp:latest

# クリーンアップ
buildah rm $builder $runtime
rm ./myapp

4. コンテナエンジン比較表

4.1 機能比較

機能	Docker	Podman	containerd	CRI-O	LXC/LXD	Buildah
デーモンレス	❌	✅	❌	❌	❌	✅
Rootless実行	△	✅	△	△	❌	✅
Docker互換CLI	✅	✅	△※	❌	❌	△
Kubernetes統合	△	✅	✅	✅	❌	❌
イメージビルド	✅	✅	△	❌	✅	✅
Pod対応	❌	✅	✅	✅	❌	❌
システムコンテナ	❌	❌	❌	❌	✅	❌
商用サポート	✅	✅	✅	✅	✅	✅

※nerdctlを使用すればDocker互換

4.2 パフォーマンス比較

指標	Docker	Podman	containerd	CRI-O	LXC/LXD
起動時間	普通	やや速い	高速	高速	速い
メモリ使用量	普通	少ない	最小	最小	普通
イメージプル速度	普通	普通	高速	高速	普通
ビルド速度	普通	やや遅い	-	-	普通

4.3 ユースケース別推奨

ユースケース	推奨エンジン	理由
ローカル開発（Docker代替）	Podman	"Docker互換のCLIで移行が容易、rootless実行で安全"
Kubernetesクラスタ	containerd / CRI-O	軽量で最適化されている
CI/CDパイプライン	Podman + Buildah	rootlessで安全、ビルド最適化
仮想マシン代替	LXD	システムコンテナで完全なOS環境
イメージビルド最適化	Buildah	細かい制御、サイズ最適化
エンタープライズ本番	Docker Enterprise / Podman	商用サポート、実績
マルチテナントホスティング	LXD	分離性が高い
エッジコンピューティング	containerd	軽量、最小リソース

5. 実践編：Dockerから他のエンジンへの移行

5.1 PodmanへのDockerからの移行

ステップ1: Podmanのインストール

# macOS
brew install podman
podman machine init
podman machine start

# Linux
sudo apt-get install -y podman  # Ubuntu/Debian
sudo dnf install -y podman      # RHEL/Fedora

ステップ2: Dockerコマンドの置き換え

# エイリアス設定（bashの場合）
echo "alias docker=podman" >> ~/.bashrc
source ~/.bashrc

# または、podman-dockerパッケージをインストール（Linuxのみ）
sudo apt-get install -y podman-docker

ステップ3: 既存のイメージとコンテナの移行

# Dockerからイメージをエクスポート
docker save -o myimage.tar myimage:latest

# Podmanでインポート
podman load -i myimage.tar

# または、Docker Hubから直接プル
podman pull docker.io/library/nginx:latest

ステップ4: Docker Composeの代替

# podman-composeのインストール
pip3 install podman-compose

# 使い方はDocker Composeと同じ
podman-compose up -d
podman-compose ps
podman-compose down

docker-compose.yml例

version: '3'
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html
  db:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

ステップ5: systemdによる自動起動設定

# コンテナからsystemdユニットファイル生成
podman generate systemd --new --name web > ~/.config/systemd/user/container-web.service

# サービスの有効化
systemctl --user enable container-web.service
systemctl --user start container-web.service

# 状態確認
systemctl --user status container-web.service

5.2 Kubernetesでcontainerdを使用

既存クラスタでDockerからcontainerdへ移行

# 1. containerdのインストール（全ノード）
sudo apt-get install -y containerd.io

# 2. containerd設定
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 3. systemd cgroup ドライバーを有効化
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# 4. containerd起動
sudo systemctl enable --now containerd

# 5. kubeletの設定変更
sudo nano /var/lib/kubelet/kubeadm-flags.env
# --container-runtime=remote
# --container-runtime-endpoint=unix:///run/containerd/containerd.sock

# 6. kubelet再起動
sudo systemctl restart kubelet

# 7. ノードの状態確認
kubectl get nodes -o wide
# CONTAINER-RUNTIME列がcontainerdになっていることを確認

新規Kubernetesクラスタ構築（containerd使用）

Kubernetes 1.34対応の設定（kubeadm v1beta4）

以下はKubernetes 1.34環境での推奨設定です。

v1beta4の主な変更点（v1beta3から）:

extraArgs が構造化形式に変更
- 旧: extraArgs: { "key": "value" }
- 新: extraArgs: [{ name: "key", value: "value" }]
タイムアウト設定の再構成
- ClusterConfiguration.timeoutForControlPlane → timeouts.controlPlaneComponentHealthCheck
- JoinConfiguration.discovery.timeout → timeouts.discovery
新機能
- encryptionAlgorithm: 証明書暗号化（RSA-2048/3072/4096、ECDSA-P256/P384）
- certificateValidityPeriod / caCertificateValidityPeriod: 証明書有効期限制御
- dns.disabled / proxy.disabled: CoreDNS/kube-proxyの無効化
- extraEnvs: コントロールプレーンコンポーネントの環境変数設定
- dryRun: ドライランモード対応
新しい設定タイプ
- ResetConfiguration: kubeadm reset 用
- UpgradeConfiguration: kubeadm upgrade 用

v1beta3からの移行:

kubeadm config migrate --old-config old-v1beta3.yaml --new-config new-v1beta4.yaml

:::note warn
v1beta3は非推奨です。Kubernetes 3マイナーバージョン後（v1.34以降）にサポート終了予定。

# kubeadm設定ファイル（v1beta4 - Kubernetes 1.34対応）
cat << EOF > kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
nodeRegistration:
  criSocket: unix:///run/containerd/containerd.sock
  imagePullSerial: false  # v1beta4: 並列イメージプル（デフォルト）
# dryRun: false  # v1beta4: ドライランモード
# timeouts:  # v1beta4: タイムアウト設定
#   controlPlaneComponentHealthCheck: 4m0s
#   kubeletHealthCheck: 4m0s
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/16
# encryptionAlgorithm: RSA-2048  # v1beta4: 証明書暗号化アルゴリズム
# certificateValidityPeriod: 8760h  # v1beta4: 証明書有効期限（1年）
# caCertificateValidityPeriod: 87600h  # v1beta4: CA証明書有効期限（10年）
apiServer:
  # v1beta4: extraArgsは構造化形式に変更
  extraArgs:
    - name: "enable-admission-plugins"
      value: "NodeRestriction,PodSecurity"
  # extraEnvs:  # v1beta4: 環境変数設定
  #   - name: "HTTP_PROXY"
  #     value: "http://proxy.example.com:8080"
# dns:
#   disabled: false  # v1beta4: CoreDNSを無効化する場合はtrue
# proxy:
#   disabled: false  # v1beta4: kube-proxyを無効化する場合はtrue
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF

# クラスタ初期化
sudo kubeadm init --config=kubeadm-config.yaml

# kubeconfigセットアップ
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# CNIプラグインインストール（例：Calico）
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# ノード確認
kubectl get nodes

6. 最新のKubernetes API非推奨情報（2025年版）

:::note warn
重要：Kubernetes 1.32-1.34での非推奨API

以下のAPIが非推奨または削除されています：

Kubernetes v1.32（2025年初頭）

flowcontrol.apiserver.k8s.io/v1beta3 の削除
- FlowSchema と PriorityLevelConfiguration は v1 を使用してください
- v1.29から利用可能

Kubernetes v1.33（2025年4月リリース）

Endpoints API の非推奨
- ワークロードやスクリプトから直接 Endpoints APIを使用している場合は、EndpointSlices に移行してください
status.nodeInfo.kubeProxyVersion フィールドの削除
- v1.31で非推奨化され、v1.33で完全削除

移行の推奨事項

kubectl api-resources で使用中のAPIバージョンを確認
kubectl convert コマンドでマニフェストを最新バージョンに変換
CI/CDパイプラインのKubernetes APIクライアントを更新

詳細: https://kubernetes.io/docs/reference/using-api/deprecation-guide/

7. トラブルシューティング

7.1 Podman関連

問題: "permission denied"エラー

# 原因: rootlessモードでのストレージ権限問題
# 解決策: サブUID/サブGIDの設定確認
cat /etc/subuid
cat /etc/subgid

# ユーザーがない場合は追加
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USER

# Podman設定のリセット
podman system reset

問題: "Error: short-name resolution"

# 原因: イメージ名の曖昧さ
# 解決策: 完全なレジストリパスを指定
podman pull docker.io/library/nginx:latest

# または、registries.confで優先レジストリを設定
sudo nano /etc/containers/registries.conf
# unqualified-search-registries = ["docker.io"]

問題: ポート8080が使用できない

# 原因: rootlessモードでは1024未満のポートは特権が必要
# 解決策: 高い番号のポートを使用するか、net.ipv4.ip_unprivileged_port_startを変更
sudo sysctl net.ipv4.ip_unprivileged_port_start=80
echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee -a /etc/sysctl.conf

7.2 containerd関連

問題: nerdctlでイメージがプルできない

# 原因: 名前空間の問題
# 解決策: 明示的に名前空間を指定
sudo nerdctl -n k8s.io images
sudo nerdctl -n default images

# デフォルト名前空間の設定
echo 'export CONTAINERD_NAMESPACE=default' >> ~/.bashrc

問題: Kubernetesのポッドが起動しない

# デバッグ: containerdのログ確認
sudo journalctl -u containerd -f

# crictl（CRI互換CLI）でデバッグ
sudo crictl ps -a
sudo crictl logs <container-id>
sudo crictl inspect <container-id>

# runtimeエンドポイントの確認
sudo crictl info

7.3 CRI-O関連

問題: CRI-Oサービスが起動しない

# ログ確認
sudo journalctl -u crio -f

# 設定ファイルの検証
sudo crio config > /tmp/crio-config.toml
# エラーがあればここで表示される

# 設定の再読み込み
sudo systemctl daemon-reload
sudo systemctl restart crio

7.4 共通問題

イメージレジストリへの接続エラー

# プロキシ設定が必要な場合
sudo mkdir -p /etc/systemd/system/containerd.service.d
cat << EOF | sudo tee /etc/systemd/system/containerd.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1"
EOF

sudo systemctl daemon-reload
sudo systemctl restart containerd

ストレージ容量不足

# 未使用イメージの削除（Podman）
podman image prune -a

# 未使用コンテナとイメージの削除（containerd）
sudo nerdctl system prune -a

# ストレージ使用状況の確認
df -h /var/lib/containers  # Podman
df -h /var/lib/containerd  # containerd

8. まとめと選択ガイド

8.1 シナリオ別最適解

シナリオ1: 開発環境でDocker Desktopの代替が欲しい

推奨: Podman

理由：
- Docker互換のCLI
- Dockerfileがそのまま使える
- rootlessで安全
- 無料で制限なし

クイック移行パス：
brew install podman
podman machine init
podman machine start
alias docker=podman

シナリオ2: Kubernetesクラスタを構築したい

推奨: containerd または CRI-O

containerdの場合：
- 広く採用されている
- パフォーマンスが高い
- ドキュメントが豊富

CRI-Oの場合：
- Kubernetes専用で最適化
- セキュリティ重視
- Red Hat環境との相性が良い

シナリオ3: CI/CDパイプラインでイメージをビルドしたい

推奨: Podman + Buildah

理由：
- rootlessで安全にビルド可能
- GitLab CI、GitHub Actionsで使用可能
- Dockerfileも使える
- イメージサイズの最適化が容易

GitLab CI例：
build:
  image: quay.io/podman/stable
  script:
    - buildah bud -t myimage:$CI_COMMIT_SHA .
    - podman push myimage:$CI_COMMIT_SHA

シナリオ4: 開発・テスト環境を素早く構築したい

推奨: LXD

理由：
- 完全なLinux環境
- スナップショットで状態管理
- 複数環境の並行管理が容易

使用例：
lxc launch images:ubuntu/22.04 dev-env
lxc exec dev-env -- bash
# 開発完了後
lxc snapshot dev-env clean-state

8.2 組み合わせ戦略

実際の開発では、複数のツールを組み合わせることで最大の効果を発揮します：

パターン1: フルPodmanスタック

開発: Podman
ビルド: Buildah
本番: Podman（systemd統合）
オーケストレーション: Kubernetes + CRI-O

パターン2: クラウドネイティブスタック

開発: Docker / Podman
ビルド: CI/CDのネイティブ機能
本番: Kubernetes + containerd

パターン3: ハイブリッドスタック

開発: Podman（ローカル）
テスト環境: LXD（複数環境）
本番: Kubernetes + CRI-O

8.3 移行のベストプラクティス

段階的移行アプローチ

フェーズ1: 評価（1-2週間）

非本番環境で試用
パフォーマンステスト
既存スクリプトの互換性確認

フェーズ2: パイロット（1-2ヶ月）

特定チーム・プロジェクトで導入
問題点の洗い出し
ドキュメント整備

フェーズ3: 本格展開（3-6ヶ月）

全チームへの展開
トレーニング実施
サポート体制確立

チェックリスト

□ チームメンバーのトレーニング完了
□ CI/CDパイプラインの更新
□ Dockerfileの互換性確認
□ イメージレジストリの動作確認
□ ネットワーク設定の確認
□ ストレージ設定の確認
□ セキュリティポリシーの更新
□ ドキュメントの更新
□ ロールバック手順の準備

9. バージョン互換性情報

2025年11月時点の推奨バージョン

コンポーネント	推奨バージョン	Kubernetes対応	備考
Kubernetes	v1.34 (v1.35近日)	-	kubeadm config v1beta4
kubeadm config API	v1beta4	v1.31+	v1beta3は非推奨
containerd	2.0.x (推奨) / 1.7.x	Kubernetes 1.30-1.34	2.0が最新、1.7はメンテナンス
CRI-O	1.30.x	Kubernetes 1.30-1.34	-
Podman	4.x	-	-
Buildah	1.x	-	-
LXD	5.x	-	-

バージョン選択のガイドライン

Kubernetesクラスタの場合
- CRI-OとcontainerdはKubernetesのマイナーバージョンに合わせる
- 例: Kubernetes 1.34 → CRI-O 1.30 / containerd 1.7
スタンドアロン使用の場合
- 最新の安定版（stable）を使用
- セキュリティパッチが適用された最新版を推奨
本番環境
- LTS（Long Term Support）版がある場合は優先
- 最低6ヶ月の実績があるバージョンを選択

10. 参考リソース

公式ドキュメント

Podman: https://docs.podman.io/
containerd: https://containerd.io/docs/
CRI-O: https://cri-o.io/
LXD: https://linuxcontainers.org/lxd/
Buildah: https://buildah.io/
Kubernetes: https://kubernetes.io/docs/ (最新: v1.34)

コミュニティとサポート

Podman GitHub: https://github.com/containers/podman
containerd Slack: https://slack.cncf.io/ (#containerd)
Kubernetes Slack: https://slack.k8s.io/ (#cri-o, #containerd)
LXD Forum: https://discuss.linuxcontainers.org/

学習リソース

Red Hat Blog: https://www.redhat.com/en/blog - Podman/CRI-O関連記事
CNCF YouTube: https://www.youtube.com/c/cloudnativefdn - containerd/Kubernetes動画
Kubernetes Documentation: https://kubernetes.io/docs/setup/production-environment/container-runtimes/

ツールとユーティリティ

nerdctl: containerd用のDocker互換CLI
- https://github.com/containerd/nerdctl
podman-compose: Docker Compose互換ツール
- https://github.com/containers/podman-compose
crictl: CRI互換ランタイム用CLIツール
- https://github.com/kubernetes-sigs/cri-tools
skopeo: コンテナイメージ操作ツール
- https://github.com/containers/skopeo

おわりに

コンテナ技術の世界は、Dockerだけではありません。本記事で紹介した各コンテナエンジンは、それぞれ異なる強みと用途を持っています。

重要なポイント:

"目的に応じた選択：開発、CI/CD、本番環境それぞれで最適なツールは異なる"
標準への準拠：OCI/CRI準拠により、ツール間の互換性が保たれている
段階的な移行：一度に全てを変える必要はなく、段階的に導入可能
コミュニティの活用：オープンソースコミュニティが活発で、サポートが充実

コンテナエンジンの選択は、技術的要件だけでなく、チームのスキルセット、組織のポリシー、コスト要因なども考慮する必要があります。本記事が、あなたのプロジェクトに最適なコンテナエンジンを選択する助けになれば幸いです。

執筆日: 2025年11月
最終更新: 2025年11月
対象バージョン:

Kubernetes: v1.34 (v1.35リリース予定)
Podman: 4.x
containerd: 1.7.x
CRI-O: 1.30.x
LXD: 5.x
Buildah: 1.x

ご質問やフィードバックがあれば、コメント欄でお気軽にお知らせください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up