Kubernetes①(全7回)｜minikube｜Docker Compose初心者向けKubernetes全体像と環境構築

Last updated at 2026-02-18Posted at 2026-02-18

シリーズ記事一覧

📑 目次

この記事について
この記事のゴール
前提条件
Kubernetesとは？
k8sの登場人物
学習環境の選定：minikube vs kind
環境構築
動作確認で理解を深める
まとめ

1. この記事について

1-1. シリーズ概要

このシリーズは、Docker Compose経験者が「素のKubernetes」を
1週間で実践レベルまで習得することを目指す学習記録です。

「Docker Composeは使えるけど、k8sは未経験」という方が、
既に知っていることとの差分で効率的に学べるように構成しています。

1-2. シリーズ構成

回	テーマ	内容
第1回（本記事）	全体像と環境構築	Docker Composeとの対比、minikube導入
第2回	Pod と Deployment	コンテナ起動〜スケーリング
第3回	Service と Ingress	ネットワークと外部公開
第4回	ConfigMap / Secret / PV	設定管理と永続化
第5回	模擬プロジェクト	全概念を組み合わせて実践
第6回	トラブルシュートと運用	エラー対応、ログ確認
第7回	総まとめ	振り返り

1-3. シリーズで作成するファイル（完成形）

本シリーズのハンズオンを通じて、以下のファイル構成が完成します。

~/k8s-practice/
├── pod-deployment/              ← 第2回
│   └── deployment.yaml
├── service-ingress/             ← 第3回
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── service-nodeport.yaml
│   └── ingress.yaml
├── config-secret-pv/            ← 第4回
│   ├── configmap.yaml
│   ├── secret.yaml
│   ├── pvc.yaml
│   └── deployment-db.yaml

~/k8s-todo/                      ← 第5回（模擬プロジェクト）
├── namespace.yaml
├── configmap.yaml
├── secret.yaml
├── db/
│   ├── headless-service.yaml
│   └── statefulset.yaml
├── redis/
│   ├── service.yaml
│   └── deployment.yaml
├── api/
│   ├── service.yaml
│   └── deployment.yaml
├── web/
│   ├── configmap-nginx.yaml
│   ├── configmap-html.yaml
│   ├── service.yaml
│   └── deployment.yaml
└── ingress.yaml

🔰 Memo：
第1回は環境構築のみ、
第6回・第7回はコマンド操作と座学のため、新規ファイルの作成はありません。

1-4. 対象読者

Docker / Docker Compose を使ったことがある方
Kubernetesは未経験 or 名前だけ知っている方
「k8sって何が嬉しいの？」がわからない方

2. この記事のゴール

本記事を読み終えた時点で、以下の状態になることを目指します。

#	ゴール	確認方法
①	k8sの全体像をDocker Composeとの対比で説明できる	「何が同じで何が違うか」を言語化
②	k8sの主要コンポーネントの役割と関係を説明できる	登場人物マップを見ずに概要を語れる
③	なぜminikubeを選んだか設計判断を説明できる	比較表をもとに理由を語れる
④	minikube環境が構築され、 `kubectl get nodes` で Ready が確認できる	コマンド実行結果で判定

3. 前提条件

3-1. 環境情報

項目	バージョン / 詳細
OS	Windows 11 + WSL2 Ubuntu
Docker	インストール済み
Docker Compose	使用経験あり
kubectl	本記事でインストール
minikube	本記事でインストール

3-2. 前提知識

Docker でコンテナを起動・停止した経験がある
docker-compose.yml を書いた or 読んだことがある
ターミナル（bash）の基本操作ができる

4. Kubernetesとは？

4-1. 一言で言うと

Kubernetes（k8s）は、コンテナの運用を自動化するシステムです。
Docker Composeが、
「コンテナを定義して起動するツール」なのに対して、
k8sは「コンテナを運営するシステム」です。
この「起動」と「運営」の違いがk8sの核心です。

4-2. Docker Compose との根本的な違い

観点	Docker Compose	Kubernetes
目的	1台のマシンで複数コンテナを動かす	複数台のマシンでコンテナを運営する
スケール	小規模（開発・学習）	大規模（本番運用）
障害時	コンテナ落ちたら手動で再起動	自動で復旧してくれる
スケーリング	`scale: 3` で増やせるが手動判断	負荷に応じて自動増減できる
設定ファイル	`docker-compose.yml` 1ファイル	役割別に複数のYAML

4-3. 飲食店で例えると🍽️

🍽️ Docker Compose = 個人経営の飲食店

オーナー（あなた）が全部やる

店員が倒れたら、オーナーが代わりに入る

「今日混んでるから人増やそう」も自分で判断

🍽️ Kubernetes = 飲食チェーンの本部システム

本部（k8s）が自動で管理する

店員が倒れたら、本部が自動で補充する

「混んできたから3人→5人体制に」も自動

オーナーは「5人体制でよろしく」と宣言するだけ

4-4. k8sの最重要キーワード：「宣言的」

Docker Composeとの一番大きな思考の違いがここにあります。

やり方	命令的（Docker Compose寄り）	宣言的（k8s）
考え方	「これをやれ」と手順を指示	「こうなっていてほしい」と状態を宣言
例	「コンテナを3つ起動しろ」	「コンテナは常に3つ存在すべき」
障害時	自分で再起動コマンドを打つ	k8sが「3つあるべき」を維持してくれる

🍽️ 命令的 = 「Aさん、ホールに出て。Bさん、厨房に入って。Cさん、レジお願い」
→ 1人休んだら、オーナーが再配置を指示

🍽️ 宣言的 = 「ホール2人、厨房1人、レジ1人の体制でよろしく」
→ 1人休んでも、本部が自動で代わりを送る

5. k8sの登場人物

5-1. 全体構成図🍽️

5-2. 各コンポーネントの役割

k8sコンポーネント	一言での役割	🍽️飲食チェーンで例えると
API Server	全ての中心・ハブ	本部の受付。全員がここを経由して会話する。
etcd	唯一の真実の情報源	本部の金庫（台帳保管）。 API Serverだけがアクセス可能。
Scheduler	配置の最適化担当	人事配置担当。「この新人はどの店舗に配属？」を決める
Controller Manager	理想と現実のギャップを埋める人	巡回マネージャー。「渋谷店が2人のはずが1人！補充！」
kubelet	現場の実行者	各店舗の店長。本部の指示を受けて現場を管理
Pod	実際に動くコンテナ	店員（実際に働く人）

5-3. Podを3つ起動する流れ 🍽️

「Webアプリを3つ動かして」とk8sに頼んだ場合、以下の流れで処理されます。

🍽️ 飲食チェーンで同じ流れを追うと：

オーナーが本部に電話「渋谷店、3人体制にして」

電話が本部の受付（API Server）につながる

受付が台帳（etcd）に「渋谷店：3人必要」と記録

巡回マネージャー（Controller Manager）が「今0人、3人足りない！」と気づく

人事担当（Scheduler）が「Aさん・Bさん・Cさんが空いてる」と配置決定

渋谷店の店長（kubelet）がスタッフを実際に配置

「3人配置完了」を台帳に記録

5-3-1. 分割版：3つのフェーズで理解する

上の流れを 「受付→判断→実行」 の3フェーズに分けて見てみます。

Phase 1／注文の受付と記録（①〜③）

🍽️ オーナーが本部に電話 → 受付が台帳に「渋谷店：3人必要」と記録するまで

Phase 2／本部内での判断と配置決定（④〜⑨）

🍽️ 巡回マネージャーが「3人足りない！」と気づき、人事担当が配置先を決めるまで

Phase 3／現場での起動と完了報告（⑩〜⑬）

🍽️ 店長がスタッフを実際に配置し、「完了」を台帳に記録するまで

5-4. 障害時の自動復旧フロー 🍽️

k8sの真骨頂は、Podが落ちた時に自動で復旧することです。

🍽️ スタッフCが体調不良で倒れた！

店長（kubelet）→ 本部に報告「1人ダウン」

巡回マネージャー（Controller Manager）→ 「3人のはずが2人？ダメだ」

人事（Scheduler）→ 「Dさんが空いてる、渋谷店へ」

店長 → Dさんを現場に配置

オーナーのあなたは何もしなくていい。寝てても復旧する。

5-4-1. 分割版：3つのフェーズで理解する

上の復旧フローも 「検知→判断→実行」 の3フェーズに分けて見てみます。

Phase 1／障害の検知と報告（①〜③）

🍽️ スタッフCが倒れ、店長が本部に「1人ダウン」と報告するまで

Phase 2／本部の判断と配置決定（④〜⑦）

🍽️ 巡回マネージャーが人員不足に気づき、人事担当が代わりの人を決めるまで

Phase 3／新Podの起動と復旧完了（⑧〜⑪）

🍽️ 店長がスタッフDを現場に配置し、「3人体制に復帰」を台帳に記録するまで

5-5. 重要ポイント：全員がAPI Serverを経由する

Controller ManagerがkubeletにDirectに指示を出すことはありません。
全ての通信はAPI Serverを経由します。

🍽️ 本部の中でも、巡回マネージャーが店長に直電することはない。必ず受付（API Server）を通す。これで情報が一元管理される。

6. 学習環境の選定：minikube vs kind

6-1. ローカルk8s環境の選択肢は？

k8sをローカルで学習する環境は複数あります。

ツール	概要	特徴
minikube	公式推奨のローカルk8s環境	最も学習資料が豊富
kind	Docker内にk8sクラスタを構築	軽量、CI/CD向き
k3s	軽量k8sディストリビューション	IoT/エッジ向き
Docker Desktop	Docker付属のk8s機能	手軽だが制約あり

🍽️ 自炊の練習場所を選ぶ比喩：

minikube = 自宅キッチン（道具が揃ってる）

kind = シェアキッチン（必要なものは自分で持ち込む）

k3s = キャンプ場の簡易キッチン（最小限だがリアル）

Docker Desktop = ホテルの調理コーナー（手軽だが制約あり）

6-2. minikube vs kind 詳細比較

本シリーズでは、主要候補である minikube と kind を比較して選定しました。

比較項目	✅minikube	kind
仕組み	VM or コンテナ内にk8sクラスタ1台	Dockerコンテナをk8sノードに見立てる
WSL2との相性	◎ `--driver=docker` で快適	◎ Docker上でそのまま動く
マルチノード	△ 設定面倒	◎ yamlで簡単に複数ノード
kubectl体験	◎ 素のk8sとほぼ同じ	◎ 同じ
Dashboard	◎ `minikube dashboard` 一発	△ 自分で入れる
リソース消費	やや重い（1.5〜2GB）	軽め（1GB前後）
起動速度	30秒〜1分	10〜20秒
学習資料の多さ	◎ 公式チュートリアルがminikube前提	○ 増えてるが少ない
実務との距離	素のk8s体験に近い	CI/CDテスト用途寄り

6-3. 選定結果：minikube

本シリーズでは minikube を採用します。

選定理由：

#	理由	詳細
①	学習資料の豊富さ	k8s公式チュートリアルがminikube前提。1週間の短期学習ではつまづいた時に情報が見つかることが重要
②	素のk8sに近い体験	kindはCI/CDテスト用途寄り。素のk8sを学ぶ目的にはminikubeが適合
③	Dashboard一発起動	`minikube dashboard` で視覚的にk8sの中身を確認できる。初学者にとって視覚情報は理解を大幅に加速する

7. 環境構築

7-0. 前提条件

以下が完了していることを確認してください。

#	確認項目	確認コマンド	期待される結果
✅	Docker Desktop がインストール済み	`docker --version`	Docker version xx.x.x
✅	Docker が起動している	`docker info`	エラーなく情報が表示される
✅	WSL2統合が有効	（Docker Desktop の Settings > Resources > WSL Integration）	使用中のディストロがON

🔰 Note：
minikubeは --driver=docker でDockerコンテナ内にk8sクラスタを構築します。
Docker が動いていないと minikube start が失敗するため、必ず事前に確認する。

7-1. 構築の全体像

環境構築では、以下の4ステップを実行します。

#	やること	何が起きるか	なぜ必要？
①	kubectl インストール	k8sへの指示ツールを入手	クラスタを操作する「リモコン」クラウドでも使う汎用ツール
②	minikube インストール	ローカルk8s環境管理ツールを入手	クラスタ本体を作る道具 kubectl とは役割が異なるため別途必要
③	minikube 起動	Dockerコンテナ内に、 k8sクラスタが立ち上がる	①のリモコンが操作する対象がここで生まれる
④	動作確認	kubectlから、クラスタに接続できるか確認	リモコン（kubectl）→テレビ（クラスタ）の疎通チェック

🍽️ 比喩：
① 電話機を買う（kubectl = 本部に指示を出すツール）
② オフィスを借りる（minikube = ミニk8s本部）
③ オフィスの電源を入れる
④ 電話がつながるか確認

構築後の環境イメージは以下の通りです。

7-2. 作業ディレクトリ

# WSL2 Ubuntu のホームディレクトリで実行
cd ~

7-3. ① kubectl インストール

# kubectlの最新版をダウンロード
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# 実行権限を付与して /usr/local/bin に配置
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# バージョン確認
kubectl version --client

期待される出力：

Client Version: v1.xx.x

🔰 Note：
この時点ではまだk8sクラスタに接続していません。
「電話機を買っただけ」で、まだ電話をかける先がない状態です。

7-4. ② minikube インストール

# minikubeをダウンロード
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# 実行権限を付与して /usr/local/bin に配置
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# バージョン確認
minikube version

期待される出力：

minikube version: v1.xx.x

🔰 Note： minikubeのバイナリが配置されただけで、まだk8sクラスタは起動していません。「オフィスの鍵をもらっただけ」の状態です。

7-5. ③ minikube 起動

# Dockerドライバでminikubeを起動
minikube start --driver=docker

期待される出力（要点）：

😄  minikube v1.xx.x on Ubuntu ...
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🏄  Done! kubectl is now configured to use "minikube" cluster

🔰 Memo：
このコマンドで裏側では以下が自動実行されます。

--driver=docker とは？：

・minikubeがk8sクラスタをどこで動かすかを指定するオプションです。
・WSL2環境ではDockerドライバが最適です。

ドライバ	仕組み	WSL2での推奨
docker	Dockerコンテナ内にk8sを構築	◎ 推奨
virtualbox	仮想マシン内にk8sを構築	× WSL2と競合
none	ホストOSに直接k8sを構築	△ 上級者向け

kubeconfigの自動生成について：

・minikube start は ~/.kube/config にk8sクラスタへの接続情報を自動で書き込みます。
・kubeconfigとは「kubectlがどのクラスタに・誰として接続するかの設定ファイル」です。

kubeconfigの要素	役割	🍽️飲食チェーン比喩
cluster	接続先のk8sクラスタ情報	「渋谷本部の住所と電話番号」
user	認証情報（証明書）	「あなたの社員証」
context	clusterとuserの組み合わせ	「渋谷本部に、この社員証で接続する」

7-6. ④ 動作確認

# クラスタの状態確認
kubectl cluster-info

# ノード一覧を表示
kubectl get nodes

期待される出力：

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   xxs   v1.xx.x

🔰 出力の読み方：

列	意味	今回の値
NAME	ノード名	minikube（ノード1台のみ）
STATUS	状態	Ready（正常に稼働中）
ROLES	役割	control-plane（本部機能を持つ）
AGE	起動からの経過時間	起動直後なら数秒〜数分
VERSION	k8sのバージョン	インストールされたバージョン

Ready が表示されていれば環境構築は成功です！

8. 動作確認で理解を深める

環境が構築できたら、kubectlコマンドでk8sの中身を覗いてみます。

8-1. クラスタ内のコンポーネントを確認

# k8sのシステムコンポーネントを確認
kubectl get pods -n kube-system

🔰 Memo：
・-n kube-system は「kube-systemという名前空間（Namespace）を指定」する意味です
・k8sの内部コンポーネント（API Server、etcd等）は kube-system Namespaceで動いています

🍽️ Namespaceとは「フロア分け」です。

kube-system = バックオフィス（本部スタッフがいるフロア）

default = 営業フロア（あなたのアプリが動く場所）

期待される出力（例）：

NAME                               READY   STATUS    RESTARTS   AGE
coredns-xxxxxxxx-xxxxx             1/1     Running   0          5m
etcd-minikube                      1/1     Running   0          5m
kube-apiserver-minikube            1/1     Running   0          5m
kube-controller-manager-minikube   1/1     Running   0          5m
kube-proxy-xxxxx                   1/1     Running   0          5m
kube-scheduler-minikube            1/1     Running   0          5m

先ほど学んだ登場人物が実際に動いているのが確認できます！

Pod名	対応するコンポーネント	🍽️飲食チェーン比喩
kube-apiserver	API Server	本部の受付
etcd	etcd	金庫（台帳保管）
kube-controller-manager	Controller Manager	巡回マネージャー
kube-scheduler	Scheduler	人事配置担当
coredns	DNS	内線電話の番号案内
kube-proxy	Proxy	店舗間の連絡係

8-2. kubeconfigの中身を確認

# 現在のcontext（接続先）を確認
kubectl config current-context

# kubeconfigの全体を確認
kubectl config view

期待される出力（current-context）：

minikube

🔰 Memo：
minikubeが自動で「自分のクラスタをデフォルトの接続先」に設定してくれています。

8-3. Dashboardで視覚的に確認（オプション）

# minikubeのDashboardを起動
minikube dashboard

ブラウザが自動で開き、k8sクラスタの状態をGUIで確認できます。
ターミナルで見た情報と同じものが、視覚的に表示されます。

9. まとめ

9-1. 本記事で学んだこと

#	学んだこと	キーポイント
①	k8sの全体像	Docker Compose = 個人店経営、k8s = チェーン本部運営
②	「宣言的」という思考	「こうなってほしい」と宣言 → k8sが自動で維持
③	各コンポーネントの役割	全員がAPI Serverを経由、Controller Managerが自動修復
④	minikubeの選定理由	学習資料の豊富さ、素のk8sに近い体験、Dashboard一発起動
⑤	環境構築	kubectl + minikube で5分で構築完了

9-2. ゴールの達成確認

#	ゴール	達成状況
①	k8sの全体像をDocker Composeとの対比で説明できる	✅ セクション4で解説
②	主要コンポーネントの役割と関係を説明できる	✅ セクション5で解説
③	なぜminikubeを選んだか設計判断を説明できる	✅ セクション6で解説
④	`kubectl get nodes` で Ready が確認できる	🔲 実行して確認

9-3. 次回予告

第2回：Pod と Deployment を理解する

次回は、実際にk8s上でコンテナ（Pod）を起動し、Deploymentを使ったスケーリングを体験します。Docker Composeの services と scale に対応する概念を深掘りします。

（つづく）

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