2 章

ローカル環境

minikube・kind・Docker Desktop k8s のどれを使うかを決めます。3つのオプションの動作方式・長短所を比較し、kubectl をインストールしたあと kind で最初のクラスタを起動してノードとシステム Pod を確認する流れまで一度にたどります。

第1章 Kubernetes とはで control plane と worker node に分かれたクラスタの全体像を見ました。本章ではその図を実際に目にします。ノートパソコン1台の上に K8s クラスタを起動する3つのオプション (minikube・kind・Docker Desktop k8s) を比較し、kubectl をインストールしたあと kind で最初のクラスタを起動してノードとシステム Pod を確認する流れまで一度にたどります。

本章の終わりには ローカルクラスタ1台と、そのクラスタを覗き込める kubectl までが用意されます。その状態が第3章 kubectl と最初の Pod からの出発点になります。

ローカル K8s の3つのオプション #

3つのツールはどれも「ローカルに K8s クラスタを1台起動する」という同じことをしますが、動作方式と長短所が少しずつ異なります。

ツール	動作方式	マルチノード	起動時間	おすすめ対象
Docker Desktop k8s	Docker Desktop 内部の VM の上で単一ノード K8s を実行	× (単一ノード)	普通	macOS・Windows ですでに Docker Desktop を使うユーザー
minikube	VM またはコンテナドライバから選んでクラスタを実行	○ (オプション)	普通	アドオン (ingress、dashboard など) を豊富に使いたいとき
kind	docker コンテナ1台1台を K8s ノードとして使用	○	速い	軽く、またはマルチノードを YAML で定義したいとき / CI

もう少しかみ砕いて説明するとこうです。

Docker Desktop k8s は macOS と Windows で最も手のかからないオプションです。Docker Desktop をすでに使っているなら、設定メニューの Kubernetes タブでチェック1つでクラスタが起動し、kubectl のコンテキストも自動で docker-desktop に設定されます。短所は macOS・Windows 限定 という点で (Linux 用 Docker Desktop も同じオプションを提供しますが、環境ごとに事情が異なります)、どのみち Docker Desktop が起動した VM の中で動く K8s なので、メモリ・CPU をかなり使います。

minikube はローカル K8s ツールの中で最も古い部類に入ります。環境によって docker / hyperkit / kvm / virtualbox などいくつかのドライバのうち1つが自動選択されたり、ユーザーが選んで使えたりします。最大の長所は アドオン (addon) が豊富という点です。ingress、metrics-server、dashboard、registry といったよく必要になる付加機能をコマンド1行でオンにできます。

kind は名前がそのまま動作の説明です — Kubernetes IN Docker。docker コンテナ1台を K8s ノードとして使う方式なので、VM を別途起動する minikube / Docker Desktop より軽くて速いです。マルチノードクラスタを短い YAML で定義 できるので control plane と worker を分離した環境を真似るのによく、そのため K8s 自体の CI でも使われます。

どれを選ぶか #

すでに macOS・Windows で Docker Desktop を使っているなら、最初は Docker Desktop k8s が最も楽です。チェックボックス1つでクラスタが起動し、普段使っている docker 環境と自然につながります。Linux ユーザーだったり、マルチノード環境を真似てみたかったり、クラスタを頻繁に作って消したかったりするなら kind がよく合います。アドオンを1行コマンドでオン・オフしながらあれこれ試してみたいなら minikube もよい選択です。

本書は kind をメインオプションに据えて進めます。軽くて速く、コマンド1〜2行でクラスタを作って消せるので学習用に適しているからです。ただし どれを選んでも第3章からの kubectl コマンドは同じです。 クラスタを起動する方法だけが違うだけで、その上で扱う K8s リソースは同じです。ご自身の環境に合うものを選んでついてきていただければ大丈夫です。

kubectl のインストール #

クラスタをどこに起動するにせよ、そのクラスタと対話するクライアントは共通して kubectl です。K8s コントロールプレーンの API サーバー (kube-apiserver) に HTTP でコマンドを送る CLI です。

macOS — Homebrew #

kubectl のインストール (macOS)

brew install kubectl

Windows — winget または Chocolatey #

kubectl のインストール (Windows)

winget install -e --id Kubernetes.kubectl
# または
choco install kubernetes-cli

Linux — 公式バイナリ #

kubectl のインストール (Linux)

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

ディストリビューションによってはパッケージマネージャ (apt、dnf など) でもインストールできますが、K8s はクライアントとサーバーのバージョンの互換範囲を合わせておくほうが安全です。正確なインストール手順が必要なら kubernetes.io のインストール案内を参照してください。

インストールが終わったらクライアントのバージョンを確認します。

インストール確認

kubectl version --client

出力例

Client Version: v1.32.x
Kustomize Version: v5.x.x

この時点ではまだクラスタがないため、サーバーバージョンは表示されません。クラスタを起動するとその次に表示されます。

kind で最初のクラスタを起動する #

本章のメインの流れです。まず kind 自体をインストールします。

kind のインストール (macOS)

brew install kind

kind のインストール (Windows)

winget install -e --id Kubernetes.kind
# または
choco install kind

kind のインストール (Linux)

curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64
chmod +x kind
sudo mv kind /usr/local/bin/

kind は docker デーモンを使います。Docker Desktop または docker エンジンが先に実行中でなければなりません。

ではクラスタを1つ作ります。単一ノードならコマンド1行で終わります。

クラスタ作成

kind create cluster

出力例

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.32.x)
 ✓ Preparing nodes
 ✓ Writing configuration
 ✓ Starting control-plane
 ✓ Installing CNI
 ✓ Installing StorageClass
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

最後の行が核心です。kubectl のコンテキストが自動で kind-kind に設定されます。 これで kubectl コマンドはこのクラスタに向かいます。

kind はどう動作するのか #

kind は docker コンテナ1台を K8s ノードとして使うと言いました。本当にそうなのか docker 側で確認できます。

kind が起動したコンテナを見る

docker ps

出力例

CONTAINER ID   IMAGE                  COMMAND                  PORTS                       NAMES
abc123def456   kindest/node:v1.32.x   "/usr/local/bin/entr…"   127.0.0.1:xxxxx->6443/tcp   kind-control-plane

kindest/node イメージで作られたコンテナ1台が起動していて、その中で control plane と worker が一緒に動作します。ホストの任意のポートがコンテナの 6443 (K8s API サーバーのデフォルトポート) にマッピングされています。kubectl はこのポートにコマンドを送ります。

最初のコマンド — ノードとシステム Pod を見て回る #

クラスタが起動したので、第1章で名前だけ出てきたコンポーネントが実際に起動している様子を確認してみましょう。

ノード一覧

kubectl get nodes

出力例

NAME                 STATUS   ROLES           AGE   VERSION
kind-control-plane   Ready    control-plane   45s   v1.32.x

単一ノードクラスタなので1行だけ見えます。このノード1台が control plane の役割もし、同時にワークロードも受ける形です (ローカル環境のよくある構成です)。

次に すべてのネームスペースの Pod を見ます。K8s コンポーネントはクラスタの上に Pod の形で起動している場合が多いからです。

すべてのネームスペースの Pod

kubectl get pods -A

出力例

NAMESPACE            NAME                                         READY   STATUS    RESTARTS   AGE
kube-system          coredns-xxxxxxxxxx-aaaaa                     1/1     Running   0          1m
kube-system          coredns-xxxxxxxxxx-bbbbb                     1/1     Running   0          1m
kube-system          etcd-kind-control-plane                      1/1     Running   0          1m
kube-system          kindnet-xxxxx                                1/1     Running   0          1m
kube-system          kube-apiserver-kind-control-plane            1/1     Running   0          1m
kube-system          kube-controller-manager-kind-control-plane   1/1     Running   0          1m
kube-system          kube-proxy-xxxxx                             1/1     Running   0          1m
kube-system          kube-scheduler-kind-control-plane            1/1     Running   0          1m
local-path-storage   local-path-provisioner-xxxxxxxxxx-yyyyy      1/1     Running   0          1m

第1章で名前だけ聞いたコンポーネントがそのまま見えます — kube-apiserver、etcd、kube-scheduler、kube-controller-manager、kube-proxy、そしてクラスタ DNS の coredns です。そこに kind 特有のネットワークプラグイン kindnet と、ローカル環境で PersistentVolume を真似てくれる local-path-provisioner まで一緒に起動しています。

kube-system ネームスペースは K8s が自分の運用のために使う Pod たちが集まる空間 です。これから作るアプリは default ネームスペース (または自分で作ったネームスペース、第7章 Namespace とラベル) へ行きます。

最後にクラスタ自体のメタ情報を確認します。

クラスタ情報

kubectl cluster-info

出力例

Kubernetes control plane is running at https://127.0.0.1:xxxxx
CoreDNS is running at https://127.0.0.1:xxxxx/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

この出力の最初の行に書かれた IP とポートが、まさに上で見た docker ps のポートマッピングと同じ場所です。つまり kubectl はホストで docker が公開したポートを通じてノードコンテナの中の kube-apiserver と対話しているわけです。

kubeconfig — kubectl がどこへコマンドを送るか #

kubectl がどのクラスタへコマンドを送るかは kubeconfig ファイル が決めます。デフォルトパスは次の通りです。

macOS / Linux — ~/.kube/config
Windows — %USERPROFILE%\.kube\config

このファイルには3種類の情報が入っています。

項目	意味
clusters	どんなクラスタがあるか (API サーバーアドレス、CA 証明書)
users	そのクラスタにどんな資格情報でアクセスするか (証明書、トークンなど)
contexts	「このクラスタ + このユーザー + このネームスペース」のまとまり。`kubectl` が一度に1つのコンテキストを使用

kind がクラスタを作りながら kind-kind というコンテキストを自動で追加し、現在のコンテキストをそこに合わせておきます。直接確認してみましょう。

コンテキストを見る

kubectl config get-contexts

出力例

CURRENT   NAME             CLUSTER          AUTHINFO         NAMESPACE
*         kind-kind        kind-kind        kind-kind

現在のコンテキスト

kubectl config current-context

出力例

kind-kind

複数のクラスタを同時に扱うようになると (例: ローカルの kind、会社の dev クラスタ、会社の prod クラスタ) kubectl config get-contexts に項目が複数出てきます。そのうち1つを選んで現在のコンテキストに変えるときに使うコマンドが use-context です。

コンテキスト切り替え

kubectl config use-context kind-kind

会社のクラスタとローカルを行き来しながら作業するときは、コマンドを間違ったクラスタに送らないようにコンテキストを常に意識する習慣 が重要です。シェルプロンプトに現在のコンテキストを表示してくれるツール (kube-ps1、starship など) もよく使われます。この観点は4部 EKS 実戦 (第21章 EKS クラスタセットアップ) で再び強調されます。

Docker Desktop k8s で起動する場合 #

Docker Desktop をすでに使っている環境なら、設定メニューで K8s をオンにするだけでクラスタが起動します。正確なメニュー経路は Docker Desktop のバージョンによって少しずつ異なりますが、おおむね次の通りです。

Docker Desktop 実行 → Settings (または Preferences) に入る
左のメニューから Kubernetes タブを選択
Enable Kubernetes をチェック → Apply & Restart

初めて有効化するときは K8s コンポーネントのイメージを取得するため数分かかります。終わると kubectl のコンテキストが自動で追加されます。

Docker Desktop k8s コンテキストへ切り替え

kubectl config use-context docker-desktop
kubectl get nodes

出力例

NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   2m    v1.32.x

以降の kubectl コマンドは kind と完全に同じです。

minikube で起動する場合 #

minikube も似ています。まず minikube CLI をインストールしたあと (公式案内: minikube.sigs.k8s.io)、クラスタを開始します。

minikube クラスタ開始

minikube start

ドライバを明示的に選びたいなら --driver オプションを与えます。デフォルトドライバは環境によって docker / hyperkit / kvm などへ自動選択されます。

ドライバを明示した開始

minikube start --driver=docker

minikube が起動するとコンテキストが minikube に設定されます。

確認

kubectl config use-context minikube
kubectl get nodes

minikube の魅力の1つであるアドオンは minikube addons コマンドで扱います。たとえば ingress コントローラをオンにするにはこうします。

ingress アドオン

minikube addons enable ingress

後片付け・クリーンアップ #

学習が終わったり、クラスタを新しく作り直したかったりするとき、きれいに片付ける方法も知っておくとよいです。

kind

kind クラスタ削除

kind delete cluster

名前を別途付けたことがなければデフォルト名 (kind) のクラスタが消えます。複数のクラスタを同時に運用していたなら --name で指定してください。

Docker Desktop k8s

設定の Kubernetes タブで Disable Kubernetes をチェックすればよいです。または同じ画面の Reset Kubernetes Cluster ボタンで初期化することもできます。

minikube

minikube 停止/削除

minikube stop      # 一時停止 (次にまた start 可能)
minikube delete    # 完全に削除

ローカルクラスタは いつでも消して作り直せるという身軽さ が大きな長所です。何かがこじれたと判断したら、きれいに消して起動し直すほうが速いことが多いです。

練習問題 #

ご自身の環境 (OS、Docker Desktop 使用の有無、マルチノード学習の意図の有無) に照らして、3つのオプション (Docker Desktop k8s / minikube / kind) のうちどれをメインに使うかを一行で決定し、その理由を §「どれを選ぶか」の基準に合わせて一段落で書いておいてください。4部 EKS 実戦では結局同じ kubectl で EKS コントロールプレーンと対話することになるので、ローカルの選択が EKS の流れとどうつながるかも併せてメモしておきます。
上の本文どおり kind でクラスタを起動したあと kubectl get pods -A 出力に登場したシステム Pod 9個の役割を第1章 §「K8s クラスタの全体像」のコンポーネント説明と対にして表に整理してみてください。kindnet と local-path-provisioner は第1章に登場しないコンポーネントですが、どの領域 (ネットワーク / ストレージ) に属するのかを併せてメモします。
kubectl config get-contexts が現在ご自身の環境でどんなコンテキストたちを見せてくれるかを確認してみてください。コンテキストが2つ以上なら (例: kind-kind と docker-desktop が一緒に出ている場合) 両者の間を use-context で行き来しながら kubectl get nodes の結果がどう変わるかを直接確認してみます。会社のクラスタを併せて扱うようになるとき、この習慣が安全装置になります。

一行まとめ: ローカル K8s は Docker Desktop k8s・minikube・kind の3つのオプションがあり、どれを選んでもその上で扱う K8s リソースは同じである。本書のメインオプションは kind である。kubectl がどのクラスタへコマンドを送るかは kubeconfig のコンテキストが決定する。

次の章 #

次の第3章 kubectl と最初の Pod では、K8s の最小実行単位である Pod を扱います。kubectl run で命令型に起動する道と YAML マニフェストで宣言型に起動する道の両方を見て、kubectl get / describe / logs / exec といった日常コマンドで Pod を覗き込む流れまで整理します。本格的な K8s の始まりになります。