minikubeは、自分のPCの中にKubernetesクラスタを1つ立てるためのツールです。Kubernetesプロジェクト自身が開発しており、公式チュートリアル「Hello Minikube」もこのツールを前提にしています。リリースノートの日付が2026年9月1日のv1.39.0では、既定のKubernetesが1.37.0になり、コンテナランタイムの既定がDockerからcontainerdへ切り替わりました。古い手順のまま eval $(minikube docker-env) を打つと、ここでつまずきます。この記事では、インストールからダッシュボードの起動、サービスの公開、跡を残さない削除まで、v1.39.0のソースとドキュメントで確かめた手順をまとめます。
まとめ:minikubeを使い始める前に押さえる要点
- minikubeは学習・開発用のローカルKubernetesです。公式ドキュメントも、本番クラスタには使わないよう案内しています。
- 前提はCPU 2コア以上、空きメモリ2GB、空きディスク20GBと、Docker・Hyper-V・QEMUなどのコンテナ/VM実行環境です。
- v1.39.0の既定はKubernetes 1.37.0とcontainerdです。
docker-envを使うならminikube start --container-runtime=dockerで作ります。 minikube dashboardはアドオンの有効化からブラウザ起動まで1コマンドで行います。ただし上流のKubernetes Dashboardは2026年1月にアーカイブされたので、継続して使う画面にはHeadlampアドオンを選びます。- NodePortは
minikube service、LoadBalancerはminikube tunnelで手元から開きます。 - 跡を残さず消すには
minikube delete --all --purgeを実行してから、本体のバイナリを削除します。
minikubeとは:ローカルに単一ノードのKubernetesを立てる公式ツール
minikubeは、GitHubの kubernetes/minikube リポジトリで開発されています。READMEには、macOS・Linux・Windowsでローカルクラスタを動かし、ローカルでのアプリ開発に最適なツールであることを目標にしていると書かれています。公式サイトは minikube.sigs.k8s.io です。読み方は「ミニキューブ」が一般的ですが、公式に定められた読み方はありません。
クラスタを置く場所は「ドライバ」で選びます。Dockerドライバはコンテナを1つ立ててその中でKubernetesを動かし、Hyper-VやQEMUなどのドライバは仮想マシンを1台立てます。既定は1ノード構成で、--nodes を指定すれば複数ノードも作れます。Kubernetesの用語(Pod・Deployment・Service)が初めてなら、先にKubernetes(クバネティス)とは?仕組み・Dockerとの違い・読み方をわかりやすく解説で全体像をつかんでおくと、以降のコマンドが読みやすくなります。
kind・K3s・Docker DesktopのKubernetesとの違い
手元でKubernetesを動かす手段はほかにもあります。違いが出るのは、何の上でノードを動かすかと、付属機能の量です。
| ツール | ノードの実体 | 向いている用途 |
|---|---|---|
| minikube | コンテナまたはVM(ドライバで選択) | 学習・アドオンを使った検証 |
| kind | コンテナ(Docker・Podman・nerdctl) | CI・マルチノードの使い捨て |
| K3s | Linuxホストに直接導入 | エッジ・小規模な本番 |
| Docker Desktop | Docker Desktop内蔵 | Docker Desktop利用者の手軽な確認 |
kindのREADMEは自身を、Dockerコンテナを「ノード」としてローカルクラスタを動かすツールと説明しています(Podmanとnerdctlにも対応)。VMドライバを選べて、Ingressやダッシュボードをアドオンで足せるのがminikubeです。kindはノードをコンテナに限る代わりに、設定ファイル1つでマルチノード構成を作って捨てられます。kindでの手順はk8sをローカルで動かす手順|kindでクラスタ構築からDeployment公開・撤収まで、Linuxに直接入れる軽量版はK3sとは?読み方・k8sとの違いとインストール手順、構成の選び方で扱っています。
minikube v1.39.0の変更点:containerdの既定化とKubernetes 1.37対応
v1.39.0のリリースノート(記載日2026-09-01)のうち、日常の操作に効く変更は次の4つです。
- 既定のKubernetesが1.37.0:1.36と1.37に対応しました。ソースの定数では、テスト対象の最古の版は1.28.0です。
- 既定のコンテナランタイムがcontainerd:「Breaking changes」に分類されています。新しく作るクラスタは、指定しなければcontainerdで動きます。
- VirtualBoxドライバがApple Siliconに対応:VirtualBox 7.1以降が条件です。
- Traefikのingressアドオンを追加:Helmで入れる方式です。HeadlampアドオンもHeadlamp 0.45.0へ上がりました。
containerdが既定になって困るのは、ホストの docker コマンドをクラスタ内のDockerデーモンへ向ける minikube docker-env です。公式ハンドブックは、この方法には --container-runtime=docker での起動が必要だと明記しています(containerdでは実験的扱い)。v1.38以前の記事の手順をそのまま追う場合は、起動オプションを1つ足してください。
手元の版は minikube version で表示でき、minikube update-check を使えば現在の版と最新版を並べて確認できます。
インストール手順:前提要件とOS別のコマンド
公式の開始ガイドが挙げる前提は、CPU 2コア以上、空きメモリ2GB、空きディスク20GB、インターネット接続、そしてコンテナかVMの実行環境です。Docker Desktop・Podman・Hyper-V・QEMU・VirtualBoxなどのどれか1つを先に入れておきます。kubectlは必須ではありません。minikube kubectl がクラスタの版に合ったkubectlを取得して使います。kubectlを入れない場合は、この記事の kubectl で始まるコマンドを minikube kubectl -- に置き換えて実行してください(例:minikube kubectl -- get pods)。
macOSへのminikube導入:Homebrewのコマンド
brew install minikube
minikube version
導入後に which minikube が見つからないときは、公式の案内どおり古いリンクを外して張り直します。
brew unlink minikube
brew link minikube
Windowsへのminikube導入:winget・Chocolateyのコマンド
winget install Kubernetes.minikube
# Chocolateyを使う場合
choco install minikube
インストール後は、PATHを読み直すためにターミナルを開き直してから minikube version を実行します。Hyper-Vドライバを使うなら、Windowsの機能でHyper-Vを有効にしておきます。Hyper-VはWindowsのPro・Enterprise・Educationエディションの機能で、Homeエディションでは使えません。HomeではDocker Desktopを入れてDockerドライバを選びます。
Linuxへのminikube導入:バイナリの取得と配置
curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64
ARM64機ではファイル名の amd64 を arm64 に置き換えます。公式ガイドにはDebianパッケージ(.deb)とRPMの取得先も載っています。
ドライバの選び方:OSごとの推奨
公式のドライバ一覧で「preferred(推奨)」とされているのは次のとおりです。迷ったら表の左側から選びます。
| OS | 推奨(preferred) | 実験的(experimental) |
|---|---|---|
| Linux | Docker、KVM2 | Podman |
| macOS | Docker、vfkit | Podman、krunkit |
| Windows | Hyper-V、Docker | QEMU、Podman |
macOSで以前よく使われたHyperkitは、Homebrewのhyperkitパッケージが上流の保守終了で非推奨になり、2025年6月21日に無効化されました。公式ドキュメントはApple Siliconの代替としてvfkit(推奨)、krunkit(実験的)、QEMUを挙げています。ドライバは minikube start --driver=docker のように指定し、毎回同じものを使うなら minikube config set driver docker で既定にします。
minikube startと基本操作:起動・停止・削除・プロファイル
最初の起動は1コマンドです。イメージを取得するので、初回は数分かかります。
minikube start
minikube kubectl -- get po -A
よく使う起動オプションは次の4つです。CPUの既定は2、ディスクの既定は20000MBで、--cpus=max や --memory=max を渡すとホストの上限まで割り当てます。
# Kubernetesの版を指定する(既定はstable=v1.37.0)
minikube start --kubernetes-version=v1.34.0
# docker-envを使うためにDockerランタイムで作る
minikube start --container-runtime=docker
# CPUとメモリを増やす(既存クラスタには効かないので delete してから)
minikube start --cpus=4 --memory=8192
# 3ノードのクラスタを作る
minikube start --nodes=3
起動後の操作は次のコマンドで足ります。pause はKubernetes本体を一時停止するコマンドで、公式ガイドはデプロイ済みのアプリに影響しないと説明しています。stop はクラスタ全体を止め、状態は残ります。
minikube status # 状態の確認
minikube pause # Kubernetesを一時停止
minikube unpause # 再開
minikube stop # 停止(次回のstartで再開)
minikube delete # クラスタを削除
minikubeプロファイルによる複数クラスタの管理
minikube start が作るクラスタの名前は既定で「minikube」です。-p(--profile)で別名を付けると、版やドライバの違うクラスタを並べて置けます。プロファイルごとに版・ドライバ・CPUやメモリの割り当てを持てます。ただし minikube config set で決めた既定値は全プロファイル共通で、新しいプロファイルを作るときに使われます。
minikube start -p aged --kubernetes-version=v1.34.0
minikube profile list # 一覧を表示
minikube profile aged # 以降のコマンドの対象をagedへ切り替え
minikube profile default # 既定のminikubeへ戻す
アップグレード前の互換性確認に便利です。今の版で動いているマニフェストを、1つ古い版のプロファイルでも動かしてみられます。Kubernetes本体の版とサポート期限はKubernetesの最新バージョンは1.37|確認方法・EOL一覧とアップグレード手順にまとめています。
minikube dashboard:Web UIの起動とHeadlampへの切り替え
minikube dashboardが裏で行う3つの処理
v1.39.0の dashboard.go を読むと、minikube dashboard は次の順で動いています。
- dashboardアドオンが無効なら有効化する(入るのは
kubernetesui/dashboard:v2.7.0) - ホスト側で
kubectl proxyを起動し、到達できるまで待つ - 既定のブラウザでURLを開く
リモートのLinux機などブラウザを開けない環境では --url を付けてURLだけを表示させます。プロキシのポートは既定でランダムに選ばれるので、固定したいときは --port で指定します。
minikube dashboard --url --port=8001
このコマンドはプロキシを保つために動き続け、止めると画面にもつながらなくなります。Ctrl+Cで止まるのはプロキシだけで、クラスタ内のダッシュボードは動いたままです。dashboardアドオンを有効にしたとき、minikubeは「一部の機能にはmetrics-serverアドオンが必要」と案内します。PodのCPU・メモリのグラフが空のままなら、dashboardを止めずに別のターミナルでmetrics-serverを入れてください。
minikube addons enable metrics-server
Kubernetes Dashboardのアーカイブと、Headlampアドオンの使い方
Kubernetes Dashboardの上流リポジトリはアーカイブされ、最後の更新(push)は2026年1月21日です。READMEは、保守者不足で保守を終えたことを告げ、後継としてHeadlampを勧めています。minikubeのdashboardアドオンは今もv2.7.0を配っており、導入はできます。ただし上流で修正が出ないため、新しいKubernetesでの互換性は自分で確かめる必要があります。今後も更新される画面を使い続けたいなら、Headlampアドオンへ移るのが安全です。
minikube addons enable headlamp
minikube service headlamp -n headlamp
macOS・WindowsのDockerドライバでは、2行目の minikube service がトンネルを保つために動き続けます。ログイン画面で求められるトークンは、そのターミナルを開いたまま、別のターミナルで発行します。
kubectl create token headlamp --duration 24h -n headlamp
公式ハンドブックのHeadlampのページには、Secretからトークンを取り出す古い手順が残っています。しかしv1.39.0のアドオンのマニフェストにトークン用のSecretは無く、ソース(addons.go)もKubernetes 1.24以上には kubectl create token を案内しています。既定のKubernetes 1.37.0では上のコマンドを使ってください。HeadlampのServiceはNodePort型で、minikube service で開く仕組みは次の章と同じです。
アプリを公開する:minikube serviceとminikube tunnelの使い分け
Serviceの種類によって、手元のブラウザから開くコマンドが変わります。公式の開始ガイドと同じ kicbase/echo-server:1.0 イメージで試します。
# NodePort型を作り、minikube service でURLを得る
kubectl create deployment hello-minikube --image=kicbase/echo-server:1.0
kubectl expose deployment hello-minikube --type=NodePort --port=8080
minikube service hello-minikube --url
macOS・Windows・WSLのDockerドライバでは、最後の minikube service が動き続けるので、続きは別のターミナルで実行します。
# LoadBalancer型を作る
kubectl create deployment balanced --image=kicbase/echo-server:1.0
kubectl expose deployment balanced --type=LoadBalancer --port=8080
LoadBalancer型は、別のターミナルで minikube tunnel を動かしたままにします。
minikube tunnel
tunnelを開いたまま、元のターミナルで EXTERNAL-IP を確認します。
kubectl get services balanced
- NodePort:
minikube serviceがノードのIPとポートを組み立ててURLを返します。 - LoadBalancer:
minikube tunnelがホストに経路を作り、ServiceのEXTERNAL-IPに到達できるIPが入ります。止めると経路も片付けられます。 - どの型でも:
kubectl port-forward service/hello-minikube 7080:8080でlocalhost:7080に転送できます。
macOS・Windows・WSLでDockerドライバを使っている場合は注意が必要です。公式ハンドブックによると、この構成ではホストからノードのIPに直接届きません。そのため minikube service --url がSSHトンネルを張り、127.0.0.1 のURLを返します。URLが有効なのは、そのターミナルを開いている間だけです。Linux上のDockerドライバではトンネルは作られず、ノードのIPへ直接アクセスします。Deploymentの書き方やServiceの型の違いを詳しく知りたい場合は、kindの記事のService章が参考になります。
ローカルでビルドしたイメージをminikubeへ渡す方法
手元でビルドしたイメージは、そのままではクラスタから見えません。公式ハンドブックが挙げる方法から、v1.39.0の既定(containerd)で使えるものを選びます。
| 方法 | 使えるランタイム | 向く場面 |
|---|---|---|
minikube image load |
すべて | ホストでビルド済みのイメージを入れる |
minikube image build |
すべて | クラスタ内で直接ビルドする |
minikube docker-env |
docker(containerdは実験的) | docker build をそのまま使う |
docker build -t myapp:dev .
minikube image load myapp:dev
minikube image ls | grep myapp
読み込んだイメージを使うマニフェストでは imagePullPolicy: IfNotPresent(または Never)を指定します。imagePullPolicy を省略し、タグが latest か未指定の場合、Kubernetesは取得方針を自動でAlwaysにします。するとレジストリへ取りに行き、そこにイメージが無ければ ErrImagePull になります。docker-env に慣れているなら、クラスタを --container-runtime=docker で作り直すほうが早く済みます。
起動しないときの切り分け:確認する順番
minikube start が失敗したら、次の順に確かめます。
- ドライバ側が動いているか:Dockerドライバなら、Docker Desktop(またはDockerデーモン)が起動しているか確認します。
docker infoがエラーになる状態ではminikubeも起動できません。 - 前回のクラスタが壊れていないか:ドライバを変えた、OSを更新した、途中で強制終了した後は、
minikube deleteで作り直すと直ることが多いです。VMドライバで作ったクラスタをDockerドライバに替えるときも、公式FAQは削除して作り直すか、別名のプロファイルで作るよう案内しています。 - リソースが足りているか:要求したCPU数が最低値を下回る、またはホストのCPU数を超えると、起動前のチェックで止まります。Docker Desktopを使う場合は、Docker Desktop側の割り当ても前提要件以上にします。
- ログを読む:
minikube logs --problemsで既知の問題に該当する行だけを出し、報告用にはminikube logs --file=logs.txtで全体をファイルに保存します。
kubectlが別のクラスタを向いていて、つながらないように見えることもあります。kubectl config current-context の結果がプロファイル名(既定は「minikube」)になっているか確かめ、違っていれば kubectl config use-context minikube で戻します。
minikubeのアンインストールと完全削除:delete --all --purgeの手順
minikubeを消すときは、クラスタを先に削除してから本体を消します。逆の順にすると、VMやコンテナが残ってしまいます。
# 全プロファイルのクラスタと ~/.minikube を削除
minikube delete --all --purge
# 本体を削除(入れた方法に合わせて1つ)
brew uninstall minikube # macOS
winget uninstall Kubernetes.minikube # Windows(winget)
choco uninstall minikube # Windows(Chocolatey)
sudo rm /usr/local/bin/minikube # Linux(バイナリ配置)
minikube delete は、kubeconfig(~/.kube/config)からもそのクラスタのコンテキストを削除します。--purge はキャッシュしたイメージや証明書を含む ~/.minikube ディレクトリ全体を消すオプションです。注意点として、プロファイルが2つ以上ある状態で --all を付けずに minikube delete --purge を打つと、削除は行われません。VMやコンテナの置き去りを防ぐため、ソース(delete.go)が minikube delete --all --purge を使うよう促して止める作りになっています。
Docker Desktopなどドライバ側の実行環境はminikubeの削除では消えないので、不要ならそれぞれの手順でアンインストールします。Docker Desktopのライセンスや代替はDocker Desktopの導入手順とライセンス境界|4.89系の要件と無料代替への移行で整理しています。
minikubeを選ぶ場面と選ばない場面
minikubeが向くのは、Kubernetesを一から学ぶとき、Ingress・metrics-server・Headlampなどをアドオンで足して確かめたいとき、ホストとは別のゲストOSを持つVMの上でノードを動かしたいときです。1台のPCに版の違うクラスタを並べて、アップグレード前の動作確認をするのにも向いています。
一方で、CIでテストのたびにクラスタを作っては捨てる用途で、VMドライバもアドオンも要らないなら、コンテナだけでノードを組むkindを選びます。本番やエッジの常設クラスタはminikubeの守備範囲外で、公式ドキュメントも学習・開発用と明言しています。本番はマネージドKubernetesかK3sなどのディストリビューションを検討してください。メモリ8GBのノートPCでは、前提要件の空き2GBを確保できるかを先に確かめてください。macOSとWindowsのDockerドライバも、Docker Desktopの内部VMの上で動くので、VMドライバと同じくホストのメモリを消費します。足りなければ --memory を2GBを下回らない範囲で絞るか、ほかのアプリを閉じてから起動します。
minikubeに関するよくある質問
minikubeの読み方は何ですか?
「ミニキューブ」と読むのが一般的です。公式に定められた読み方はありません。「kube」はKubernetesの略として広く使われる表記です。
minikubeの公式サイトはどこですか?
公式サイトは minikube.sigs.k8s.io、ソースとリリースはGitHubの kubernetes/minikube です。インストール手順は公式サイトの「Get Started!」にOS・CPU別にまとまっています。
minikubeのバージョンを確認・更新するには?
minikube version で手元の版を、minikube update-check で最新版との差を確認できます。更新はインストールと同じ方法で行い、Homebrewなら brew upgrade minikube です。本体を更新しても、既存クラスタのKubernetesの版は自動では上がりません。
minikube dashboardが起動しない、またはURLだけ知りたいときは?
URLだけが必要なら minikube dashboard --url を使います。起動しないときは、まず minikube status でクラスタが動いているか確認します。続けて minikube addons list でdashboardアドオンの状態を見て、それでも開けなければ minikube addons disable dashboard の後に再度 minikube dashboard を実行します。
minikubeは本番環境で使えますか?
本番用途には推奨されていません。公式ドキュメントは、minikubeは学習と開発のためのツールで、本番クラスタはKubernetes公式の本番環境ガイドを参照するよう案内しています。本番にはマネージドサービスか、本番運用を想定したディストリビューションを選びます。