Claude Media
Docker/Podman/Kubernetes MCPの選び方 — 開発と本番クラスタの分岐点
Claude CodeMCPClaude連携解説

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

コンテナ操作系MCPサーバー3種を実行基盤と権限モデルで比較し、ローカル開発と本番クラスタどちらに向くかを示します。

読了目安 約13分

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

3つとも個別の使い方はDocker MCP Toolkitの使い方・Podman MCPサーバーの使い方・Kubernetes MCPサーバーの使い方がそれぞれ扱っています。この記事は、どれを選ぶかの判断軸と、本番クラスタに向けるときの設定の違いに絞ります。

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

3つは対象レイヤーがそもそも違います。

役割

操作する対象は3系統で別物

  • Docker MCP Toolkit

    Docker Desktopに統合された管理画面です。コンテナ化されたMCPサーバーをカタログから起動し、プロファイルにまとめてクライアントへ渡します。コンテナそのものを操作する道具ではなく、MCPサーバーの管理者です。

  • Podman MCPサーバー

    PodmanまたはDockerの、コンテナ・イメージ・ネットワーク・ボリュームを操作します。単一ホストのコンテナ操作者です。

  • Kubernetes MCPサーバー

    Pod・Namespaceなどクラスタのリソースを操作します。kubeconfigでクラスタのAPIサーバーに接続するクラスタ操作者で、Helm・Tektonなどの拡張ツールセットも持ちます。

前者2つはローカル1台のデーモンやホストの上で動き、Kubernetes MCPサーバーはリモートのクラスタAPIに接続します。この接続先の違いが、そのまま権限設計の重さの違いになります。

どの軸で選ぶか

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

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

Docker MCP ToolkitはDocker Desktop 4.62以降の機能で、古いバージョンはUIが異なります。実行時の制限は、MCPツールのコンテナがCPU 1個・メモリ2GBまで、ホストのファイルシステムには既定でアクセスできない、という内容です。シークレットを含むリクエストは遮断されます。いずれもローカルで安全に試すための仕組みで、KubernetesのRBACのようにユーザー単位でロールを割り当てる機能はありません。組織で承認するサーバーの範囲は、カタログ側で絞れます。

Podman MCPサーバーも同様です。提供ツールはcontainer_runやimage_buildなど、ホストのPodman/Dockerをそのまま呼ぶものです。現行の設定は--port・--output-format・--podman-implの3つで(--sse-portなどは非推奨)、読み取り専用モードやツールの絞り込みはありません。

Kubernetes MCPサーバーだけが、専用ServiceAccountとRBACによる権限分離に加え、サーバー側にもread_onlyとdisable_destructiveという制限を持ちます。Keycloak・Microsoft Entra IDと連携したOAuth/OIDC認証にも対応しており、複数チームでの本番利用を前提にした設計です。

3つを比較する

項目Docker MCP ToolkitPodman MCPサーバーKubernetes MCPサーバー
対象Docker MCP ToolkitMCPサーバー自体の管理Podman MCPサーバー単一ホストのコンテナ操作Kubernetes MCPサーバークラスタリソースの操作
実行基盤Docker MCP ToolkitDocker DesktopPodman MCPサーバーローカルのPodman/DockerKubernetes MCPサーバーkubeconfig / in-cluster
配布形態Docker MCP ToolkitDocker Desktopに統合Podman MCPサーバーnpm / PyPI / バイナリKubernetes MCPサーバーnpm / uvx / バイナリ / コンテナ
権限制御Docker MCP Toolkit実行時のリソース制限Podman MCPサーバーホストのソケット・CLIの権限Kubernetes MCPサーバーRBAC + read_only
手順が載っているクライアントDocker MCP ToolkitClaude Code / Claude Desktop / VS CodeほかPodman MCPサーバーClaude Code / Claude Desktop / VS Code・Cursor / GooseKubernetes MCPサーバーClaude Code / Claude Desktop / VS Code

Claude Codeにつないだら、claude mcp listでMCP_DOCKERがconnectedになるのを確かめます。手順はDocker MCP Toolkitの使い方にあります。

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

権限モデルだけでなく、1回のツール呼び出しで何ができるかにも差があります。Podman MCPサーバーが持つのは、コンテナ(container_run・container_logsなど)、イメージ(image_build・image_pushなど)、network_list、volume_listの基本操作です。

Podman側にはもう1つ、バックエンドの選択肢があります。apiはUnixソケット経由でPodman REST APIを呼ぶ実装で、cliはpodmanまたはdockerのバイナリを呼び出す実装です。何も指定しなければ自動検出され、Podmanのソケットがあればapiが優先されます。Dockerしか入っていないホストではcliに落ちるため、--podman-impl=cliで固定することもできます。

Kubernetes MCPサーバーは、既定で有効なのがcore(Pod・汎用リソース・イベントなど)とconfig(kubeconfigの参照)の2つです。toolsetsで積み増すと、Helm・Tekton・KubeVirt・Kiali・NetObservが使えます。有効にするツールセットを絞ると、モデルに見せるツールが減ってツール選択の精度が上がる、とREADMEは説明しています。

Docker MCP Toolkitは軸が違い、自分でコンテナを操作せず、カタログにある他のMCPサーバーをコンテナとして動かします。ツールの広さはカタログのサーバー数で決まるため、単体の機能一覧では比べられません。

Kubernetes MCPサーバーを読み取り専用で本番に向ける

Kubernetes側の設定には、古い記事や設定例と食い違うところがあります。v0.0.67のREADMEと設定ドキュメントでは、実行時の設定はTOMLファイルが担い、コマンドラインに残るのは--version・--config・--config-dirだけです。--read-only・--disable-destructive・--toolsets・--portは廃止されており、渡すとコンテナのargsでもunknown flagで起動に失敗します。

手順

Claude Codeから読み取り専用で接続する流れ

  1. 1

    ServiceAccountに読み取り権限だけを渡す

    名前空間とServiceAccountを作り、組み込みのviewロールに結び付けます。クラスタ全体ならkubectl create clusterrolebinding、1つの名前空間に限るならkubectl create rolebindingを使います。トークンの発行(kubectl create token)にはKubernetes v1.24以降が必要です。

  2. 2

    ServiceAccount用のkubeconfigを作る

    発行したトークンを使ったkubeconfigを別ファイルとして用意します。管理者の~/.kube/configをそのまま渡さない点が、本番向けの前提です。

  3. 3

    TOMLに制限を書く

    read_only = trueと、見せたくないリソースのdenied_resourcesを書いたTOMLファイルを置きます。

  4. 4

    claude mcp add-jsonで登録する

    --configにTOMLのパスを、KUBECONFIG環境変数にServiceAccountのkubeconfigを渡します。

3つ目のTOMLは、たとえば次のように書きます。

read_only = true
toolsets = ["core", "config", "helm"]
 
[[denied_resources]]
group = ""
version = "v1"
kind = "Secret"

4つ目の登録は、設定ドキュメントの例を元にするとこうなります。

claude mcp add-json kubernetes-mcp-server \
  '{"command":"npx","args":["-y","kubernetes-mcp-server@latest","--config","'"${HOME}"'/.config/kubernetes-mcp-server.toml"],"env":{"KUBECONFIG":"'"${HOME}"'/.kube/mcp-viewer.kubeconfig"}}' \
  -s user

制限の設定は2つあり、効き方が違います。

くらべる

read_only と disable_destructive

書き込みを丸ごと止める

read_only = true

readOnlyHint=trueと注釈されたツールだけを公開します。クラスタへの書き込み系の操作は、そもそもモデルに見えません。

破壊的な操作だけを止める

disable_destructive = true

destructiveHint=trueのツール(削除・更新)を無効にします。作成系は残ります。read_onlyがtrueのときは効果がないので、両方を並べて書く必要はありません。

OAuth/OIDC認証はHTTPモード専用です。stdioのままrequire_oauth = trueを書くと、設定の読み込みが失敗します。Claude Codeからnpxで直接起動する構成では、認証の主役はServiceAccountのkubeconfigで、OIDCはサーバーを共有HTTPサービスとして立てるときの話になります。

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

Podman MCPサーバーで試した流れが、そのままKubernetesに移るわけではありません。container_runは単一ホストにプロセスを1つ立てる操作です。Kubernetesではそれに当たる操作がPodやDeploymentの作成になり、モデルに渡すツール名と引数が別物になります。接続先を替えるだけでなく、指示の出し方も作り直す前提で移行を考えます。

起動コマンドも対照的です。

# Podman MCPサーバー(ローカル、npm経由。設定フラグなしで動く)
npx -y podman-mcp-server@latest
# Claude Codeへの登録は次のとおり(claude mcp listで確認)
claude mcp add podman -- npx -y podman-mcp-server@latest
 
# Kubernetes MCPサーバー(設定はTOMLに寄せる)
npx -y kubernetes-mcp-server@latest --config ~/.config/kubernetes-mcp-server.toml

Podman側は何も渡さずに動き、Kubernetes側は--configが起点になります。開発機で試した設定ファイルをそのまま本番に流用しないよう、read_onlyを書いたTOMLを本番用として別に持っておくと、取り違えを避けられます。

それぞれの強みと弱み

Docker MCP Toolkit: プロファイル管理と実行時の安全策

強みは、MCPサーバーをプロファイルにまとめて切り替えられることと、実行時の制限が最初から効くことです。カタログのmcp/配下のイメージはDockerがビルドして署名しており、SBOM(構成部品を示す文書)も付いています。GitHubなどOAuthが要るサーバーは、ブラウザで認可するだけで接続できます。プロファイルはレジストリにpushしてチームに共有でき、メンバーはpullして同じ構成を使えます。弱みはDocker Desktopが前提になる点です。

Podman MCPサーバー: 軽さと2ランタイム対応

強みは、PodmanとDockerのどちらでも同じツールセットで扱えることです。npxとリリースバイナリで起動でき、--portを付ければStreamable HTTPでも動きます。弱みは「どの軸で選ぶか」で触れたとおり、アクセス制御の仕組みを持たないことです。複数人が同じホストを共有するなら、権限の設計を自分で作り込む必要があります。

Kubernetes MCPサーバー: RBACと本番向けの制御

強みは、読み取り専用モードや破壊的操作の無効化、リソースの拒否リスト、OAuth/OIDC連携が最初から用意されていることです。複数クラスタを同時に扱う機能も持ち、その場合は各ツールにcontext引数が加わります。弱みはセットアップの手間で、ServiceAccountとRoleBindingを先に設計する必要があります。

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

状況おすすめ度理由
個人の開発マシンでコンテナを触るおすすめ度◎ Podman MCPサーバー理由npxだけで起動でき、ローカル権限で完結する
Docker Desktopの管理画面から一元管理したいおすすめ度◎ Docker MCP Toolkit理由プロファイルとカタログ管理が主目的に合う
CI/CDパイプラインへの組み込みおすすめ度○ Podman MCPサーバー理由バイナリで起動でき、HTTPモードもある
本番Kubernetesクラスタへの接続おすすめ度◎ Kubernetes MCPサーバー(read_only)理由RBACとサーバー側の制限を重ねられる
ステージング〜本番の運用チームで共有おすすめ度◎ Kubernetes MCPサーバー理由HTTPモードのOIDC連携とマルチクラスタに対応
本番のDocker単体ホスト(k8s未導入)おすすめ度△ Podman MCPサーバー + 別途アクセス制御理由権限分離の仕組みを自前で用意する前提が付く

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

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

まとめ

3つは優劣ではなく、対象レイヤーで選びます。個人の開発機ならPodman、Docker Desktopの管理画面が軸ならDocker MCP Toolkitです。本番クラスタなら、Kubernetes MCPサーバーにread_onlyのTOMLを添えるのが起点です。Kubernetesの設定例は、フラグ式の古い書き方かTOML式かを先に見分けてください。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →