Docker/Podman/Kubernetes MCPの選び方 — 開発と本番クラスタの分岐点

コンテナを操作するMCPサーバーには、Docker MCP Toolkit・Podman MCPサーバー・Kubernetes MCPサーバーの3系統があります。同じ「コンテナをClaudeから触る」入口に見えますが、実行基盤も権限モデルも別物です。ローカルの1台で完結する開発と、複数人が触る本番クラスタでは、選ぶべきものが変わります。

3つとも個別の使い方はDocker MCP Toolkitの使い方・Podman MCPサーバーの使い方・Kubernetes MCPサーバーの使い方がそれぞれ扱っています。本記事はその手前、どれを選ぶかの判断軸だけに絞ります。

Docker/Podman/Kubernetes MCPはそれぞれ何を操作するものか

3つは対象レイヤーがそもそも違います。Docker MCP ToolkitはDocker Desktopに統合された管理画面で、コンテナ化されたMCPサーバー自体をカタログから起動・管理する用途です。Podman MCPサーバーはPodmanまたはDockerのコンテナ・イメージ・ネットワーク・ボリュームをCRUD操作するツール群です。Kubernetes MCPサーバーはPod・Namespaceといったクラスタリソースを対象にし、Helm・Tekton・KubeVirtなど拡張ツールセットも持ちます。

つまりDocker MCP Toolkitは「MCPサーバーの管理者」、Podman MCPサーバーは「単一ホストのコンテナ操作者」、Kubernetes MCPサーバーは「クラスタの操作者」という役割分担です。前者2つはローカル1台のDocker/Podmanデーモンに接続し、後者はkubeconfigやin-cluster認証でリモートのクラスタAPIサーバーに接続します。この接続先の違いが、そのまま権限設計の重さの違いになります。

どの軸で選ぶべきか

選定で効くのは次の3つの軸だけです。

• 実行基盤: 単一ホストのDocker/Podmanデーモンか、複数ノードのKubernetesクラスタAPIか
• 権限モデル: OS権限そのままか、RBACで絞れるか
• 運用主体: 個人の開発マシンか、チームが共有する本番環境か

Docker MCP Toolkitは実行基盤がDocker Desktop固定なので、そもそも本番サーバーへの展開を想定していません。CPU 1個・メモリ2GBという実行時制限とファイルシステム隔離はローカルでの安全な実験を目的にした設計で、複数人でのアクセス制御機能は持ちません。

Podman MCPサーバーも同様です。提供ツールはcontainer_runやimage_buildなど単一ホストのDocker/Podman APIをそのまま叩くラッパーで、認証はローカルのソケット権限に委ねられています。RBACのような多人数向けアクセス制御の仕組みはドキュメント上に見当たりません。

Kubernetes MCPサーバーだけが、専用ServiceAccountとRole/RoleBindingによる権限分離、--read-onlyでの読み取り専用起動、--disable-destructiveでの破壊的操作の無効化を明示的にサポートします。Keycloak・Microsoft Entra IDと連携したOAuth/OIDC認証にも対応しており、本番の複数チーム利用を前提にした設計です。

3つを比較する

Docker MCP ToolkitはClaude Codeを対応クライアント一覧に明記していませんが、docker mcp gateway runをstdioサーバーとして登録すればClaude Codeからも呼び出せます(手順はDocker MCP Toolkitの使い方を参照)。GUIでの管理を主眼にした製品なので、CLI中心のワークフローでは一手間かかると考えておくのが実態に近い理解です。

ツールの広さも選定軸になる

権限モデルだけでなく、1回のツール呼び出しで何ができるかにも差があります。Podman MCPサーバーが持つのはコンテナ・イメージ・ネットワーク・ボリュームに対する基本的なCRUD操作(container_run / image_build / network_listなど)に限られ、対象を広げる拡張機構は用意されていません。

Kubernetes MCPサーバーは逆に、コア機能(Pod・Namespace・汎用リソース操作)に加えて--toolsetsフラグで機能を積み増せる設計です。Helm(チャート管理)・Tekton(パイプライン)・KubeVirt(仮想マシン)・Kiali(Istioメッシュ可視化)・NetObserv(ネットワークフロー分析)がオプションとして用意されており、クラスタで動かしている周辺コンポーネントに応じて有効化するツールを選べます。

Docker MCP Toolkitはこの2つと軸が異なり、自分自身がコンテナを直接操作するのではなく、カタログにある他のMCPサーバーをコンテナとして起動・管理する立ち位置です。「ツールの広さ」はカタログに載っているMCPサーバーの数に依存するため、単体の機能一覧で比較する対象にはなりません。

ローカルからクラスタへ持ち込むときに変わること

Podman MCPサーバーで検証したワークフローをそのままKubernetes環境に移せるわけではありません。container_runは単一ホスト上にプロセスを1つ立てる操作ですが、Kubernetesではそれに相当する操作がPodやDeploymentの作成になり、AIに渡す語彙(ツール名と引数)自体が別物になります。接続先を切り替えるだけでなく、指示の出し方も作り直す前提で移行を計画してください。

インストール方法も実行系ごとに違います。参考までに、それぞれの最小構成での起動例です。

# Podman MCPサーバー(ローカル、npm経由)
npx -y podman-mcp-server@latest
 
# Kubernetes MCPサーバー(読み取り専用、本番想定)
npx -y kubernetes-mcp-server@latest --read-only --disable-destructive

同じnpx起動でも、Kubernetes側に--read-onlyと--disable-destructiveを必ず添える運用にしておくと、開発機で試した設定をそのまま本番に流用してしまう事故を防げます。

それぞれの強みと弱み

Docker MCP Toolkit — GUI管理と実行時の安全策が強み

強みはゼロコンフィグでの起動と、CPU・メモリ制限やシークレットフィルタリングといった実行時の安全策がデフォルトで効くことです。イメージ署名とSBOM(構成部品の透明性を示す文書)によるサプライチェーン対策も組み込まれています。利用にはDocker Desktop 4.62以降が必要で、古いバージョンのままでは機能自体が現れません。弱みはDocker Desktopに縛られる点で、CI環境やヘッドレスサーバーでの利用には向きません。

Podman MCPサーバー — 軽量さと2ランタイム対応が強み

強みは単一バイナリで依存関係がなく、PodmanとDockerの両方を自動検出して同じツールセットで扱える点です。ローカル開発機やCIランナーへの組み込みが簡単です。弱みは前節のとおりアクセス制御機構を持たないことで、複数人が同じホストを共有する環境では権限設計を自分で作り込む必要があります。

Kubernetes MCPサーバー — RBACと本番運用機能が強み

強みは読み取り専用モードや破壊的操作の無効化フラグ、OAuth/OIDC連携など、本番クラスタで求められる制御が最初から用意されている点です。TOML設定ファイルでの永続化管理や、複数クラスタの同時操作にも対応します。弱みはセットアップの手間で、専用ServiceAccountの作成とRoleBindingの設計が事前に必要になり、Docker MCP ToolkitやPodman MCPサーバーのように起動するだけでは終わりません。

ローカル開発と本番クラスタでの使い分け

最後の行だけは注意が必要です。Kubernetesを使わずDockerホストだけで本番運用しているチームは、Podman MCPサーバーの権限モデルの薄さをそのまま持ち込むことになります。この構成を選ぶなら、MCPサーバーの手前にリバースプロキシやサービスメッシュでアクセス制御を足すか、読み取り専用のAPIエンドポイントだけを公開するといった追加策が要ります。

本番のKubernetesクラスタに接続する具体的な設定手順(ServiceAccount作成からTOML設定まで)は、Kubernetes MCPサーバーの権限設計にまとめてあります。イメージの検索・選定だけが目的なら、コンテナ実行そのものではなくDocker Hub MCPサーバーのほうが用途に近いこともあります。

まとめ

3つのMCPサーバーは対象レイヤーが違うため、優劣ではなく用途で決まります。個人の開発機やCIならPodman MCPサーバー、Docker Desktopの管理画面を軸にするならDocker MCP Toolkit、本番Kubernetesクラスタに触るならKubernetes MCPサーバーの読み取り専用モードが起点です。迷ったら、まず「デーモンは1台か、クラスタか」を自問すると選択肢が半分に絞れます。