kind で検証用のクラスタを作る

この記事では Docker のコンテナをノードにして手元のマシンにクラスタを作るツールである kind の仕組みを、図で説明します。kind create cluster を実行したときに何が起きるのか、ノードの正体が何なのかがわかります。後半ではこのシリーズで使う検証用クラスタを実際に作る手順を示します。

Kubernetes とは何かを説明した第1回の内容を前提にしています。まだの方は先にこちらをどうぞ。

基本仕様 第1回 Kubernetes とは何かKubernetes が何を解決するのかを図で説明する、シリーズの第1回です。docker run で動かしたコンテナと Deployment で動かしたコンテナを比べ、止まったコンテナが自動で戻る仕組みと、望ましい状態を宣言して任せる管理のしかたを紹介します。

以下の図は、kind で作ったクラスタが手元のマシンの中でどう動いているかを表しています。

タップで拡大クリックで拡大 （図を拡大表示する）

ノードは仮想マシンでも物理マシンでもなく、手元のマシンで動く Docker のコンテナです。Pod のコンテナはそのノードのコンテナの中で動きます。

kind とは

kind は Docker のコンテナを「ノード」として使い、手元のマシンで Kubernetes のクラスタを動かすツールです。名前は「Kubernetes in Docker」に由来します。もともとは Kubernetes そのものをテストするために作られたツール ですが、手元での開発や CI（変更のたびにテストを自動で回す仕組み）にも使えます。

参考：kind、Initial design | kind、Principles | kind

kind はクラスタを作るときに、各ノードを kubeadm で初期化します。kubeadm はクラスタを立ち上げるための kubeadm init と kubeadm join を提供するツールで、kubernetes.io にリファレンスがあります。kind は CNCF（Cloud Native Computing Foundation）から、Kubernetes に適合した（conformant な）インストーラーとして認定を受けています。ここでの適合とは、kind で作ったクラスタが Kubernetes に求められる API を備えていることを指します。kind は Linux、macOS、Windows で動き、複数のノードを持つクラスタも作れます。

参考：kind、Kubeadm | Kubernetes、Software Conformance | CNCF

kind を使うには、手元のマシンに Docker（または Podman、nerdctl）が必要です。このシリーズの手順は Docker を使う前提で書きます。kubernetes.io のツールの紹介ページは、手元でクラスタを動かす道具として kind と minikube を、クラスタを作って管理する道具として kubeadm を挙げています。3 つの違いを次の表にまとめます。

参考：Install Tools | Kubernetes、Kubeadm | Kubernetes、Quick Start | kind

このシリーズでは kind で作るクラスタを 検証用クラスタ と呼びます。第3回以降の「手元で試す」節は、すべてこの記事の手順で作った検証用クラスタで試す前提にします。

なぜ kind が必要なのか

第1回で見たように、クラスタはコントロールプレーンと 1 台以上のノードでできています。ノードは仮想マシンのことも物理マシンのこともあります。学習用や資源が限られた環境では、ノードが 1 台だけのこともあります。

参考：Nodes | Kubernetes

コントロールプレーンのコンポーネントも、クラスタのどれかのマシンの上で動くプログラムです。公式ドキュメントによると、立ち上げの手順では、コントロールプレーンのコンポーネントを同じ 1 台のマシンにまとめ、そのマシンでは利用者のコンテナを動かさないのが一般的です。このシリーズではコントロールプレーンのコンポーネントを動かすノードを コントロールプレーンのノード、利用者の Pod を動かすノードを ワーカーノード と呼びます。以降、区別が必要なとき以外は単に「ワーカー」と書きます。

参考：Cluster Architecture | Kubernetes

kubeadm を使えばクラスタを立ち上げられますが、kubeadm が受け持つのは立ち上げの処理だけです。マシンを用意することは、kubeadm の役目に含まれません。そのため kubeadm だけでクラスタを作るには、ノードにするマシンを先に用意する必要があります。さらにすべてのマシンに、コンテナランタイム（コンテナを実際に動かすソフトウェア）と、kubeadm・kubelet・kubectl を入れておく必要があります。

参考：Kubeadm | Kubernetes、Installing kubeadm | Kubernetes

kind はこのマシンの代わりに Docker のコンテナを使います。ノードにするコンテナを作り、その中で kubeadm を実行するところまでを、kind create cluster という 1 つのコマンドで行います。消すときも kind delete cluster の 1 つのコマンドです。一般的に、学習のためにクラスタを作っては壊す使い方では、仮想マシンを何台も用意するより手間が少ないと考えられます。

参考：Quick Start | kind、Configuration | kind

kind の仕組み

ノードは Docker のコンテナ

kind のクラスタでは、ノード 1 つが Docker のコンテナ 1 つです。ノードのコンテナは kind が用意したコンテナイメージから作られます。このイメージは ノードイメージ と呼ばれ、Docker Hub の kindest/node で配布されています。ノードイメージには、特定のバージョンの Kubernetes があらかじめ入っています。

参考：Quick Start | kind、Release v0.33.0 · kubernetes-sigs/kind

Kubernetes から見ると、このコンテナは普通のノードです。ノードで動くコンポーネントは、kubelet、コンテナランタイム、kube-proxy です。kube-proxy は Service（後の回で扱うリソース）のためのコンポーネントで、ここでは名前だけ覚えておけば十分です。

参考：Nodes | Kubernetes

kind のノードのコンテナの中では、コンテナランタイムとして containerd が動いています。kind の公式ドキュメントのうち、手元に置いたイメージの置き場（レジストリ）を使う手順のページが根拠です。この手順では各ノードの containerd の設定を書き換えています。Pod のコンテナは、ノードのコンテナの中の containerd が動かします。つまり Pod のコンテナはノードのコンテナの中で動くコンテナ です。手元の Docker が管理しているのはノードのコンテナで、Pod のコンテナは管理していません。

参考：Local Registry | kind、Cluster Architecture | Kubernetes

同じものを手元のマシンから見た場合と Kubernetes から見た場合に分けて、次の表にまとめます。

参考：Principles | kind、Quick Start | kind

kind そのものは作ったクラスタの記録を別の場所に持ちません。その記録は、ノードのコンテナに付けたラベル、コンテナの中のファイル、コンテナの中で動くプロセスとして、ノードのコンテナの側にあります（後で出てくる kubeconfig への書き込みは、kubectl が接続するための情報です）。ここでのラベルは Docker のコンテナやイメージに付けられる付加情報（メタデータ）のことです。後の回で扱う Kubernetes のラベルとは別物です。

参考：Principles | kind、Docker object labels | Docker Docs

kind create cluster で起きること

kind create cluster を実行すると、kind はノードのコンテナを作り、その中で kubeadm を実行してクラスタを立ち上げます。kind と kubeadm がそれぞれ何をするかを、次の表にまとめます。表の行は分担を並べたもので、実行の順番を表すものではありません。

参考：Configuration | kind、Quick Start | kind

kindnetd を入れるのは、Pod に IP アドレスを割り当てて Pod どうしを通信させる部分が、Kubernetes 本体ではなくネットワークプラグインという別のソフトウェアの担当だからです。kubeadm の公式ドキュメントも、kubeadm でクラスタを作ったあとに、Pod どうしが通信できるようにするネットワークのアドオンを入れる必要があるとしています。kind はこれを kindnetd で済ませています。ネットワークの仕組みは後の回で扱います。

参考：Cluster Architecture | Kubernetes、Creating a cluster with kubeadm | Kubernetes、Configuration | kind

kubeadm init は kube-apiserver などのコントロールプレーンのコンポーネントを Pod として動かすためのマニフェストを、ノードの /etc/kubernetes/manifests に書き出します。ノードの kubelet はこのディレクトリを見ていて、このディレクトリのマニフェストに書かれた Pod を起動します。そのため kind のクラスタでは、コントロールプレーンのコンポーネントも、コントロールプレーンのノードのコンテナの中でコンテナとして動きます。各コンポーネントの役割は第4回で扱います。

参考：kubeadm init | Kubernetes、Configuration | kind

手元のマシンから kubectl でクラスタを操作するときは、kube-apiserver に接続します。kube-apiserver はクラスタの窓口になるコントロールプレーンのコンポーネントです。kube-apiserver はノードのコンテナの中で動いていますが、手元のマシンからも接続できるように、kind は手元のマシンのポートからノードのコンテナへ転送する設定をします。考え方は docker run -p でコンテナのポートを手元のマシンに公開するのと同じです。kind の既定の設定では、手元のマシンの側のアドレスはループバックアドレス（そのマシンの中からしか届かないアドレス）の 127.0.0.1、ポートは空いているポートからランダムに選んだものです。kubectl は、kind が kubeconfig（接続先を書いたファイル）に書き込んだ情報を使って、このアドレスとポートに接続します。

参考：Configuration | kind、Port publishing and mapping | Docker Docs、Kubernetes Components | Kubernetes、Quick Start | kind

kubectl は、環境変数 KUBECONFIG を設定していなければ ${HOME}/.kube/config を kubeconfig として使います。kind も、KUBECONFIG を設定していなければこのファイルに接続情報を書き込みます。すでに別のクラスタの接続情報が入っている場合も、同じファイルに追加されます。kubeconfig の中で、接続先などの設定をまとめて名前を付けたものをコンテキストと呼びます。公式ドキュメントの例では、クラスタ名 kind のコンテキストは kind-kind、クラスタ名 kind-2 のコンテキストは kind-kind-2 です。kubeconfig とコンテキストの仕組みは第3回で扱います。

参考：Quick Start | kind、Organizing Cluster Access Using kubeconfig Files | Kubernetes

シングルノードとマルチノード

設定を何も渡さずに kind create cluster を実行すると、コントロールプレーンのノードが 1 つだけのクラスタができます。クラスタ名は、指定しなければ kind です。ノードを増やすときは、設定ファイルの nodes にノードを並べ、それぞれの role に control-plane か worker を書きます。

参考：Configuration | kind、Quick Start | kind

以下の図は、設定ファイルの有無で、作られるノードのコンテナがどう変わるかを表しています。左右はそれぞれ別々にクラスタを作った場合です。

タップで拡大クリックで拡大 （図を拡大表示する）

設定ファイルの role を 1 行書くごとに、ノードのコンテナが 1 つ作られます。control-plane を複数書くと、コントロールプレーンを冗長化した構成（高可用性の構成）も試せます。3 つの構成を次の表にまとめます。

参考：Configuration | kind、Quick Start | kind

「向いている使い方」はこのシリーズでの使い分けです。

シングルノードのクラスタにはワーカーがありません。では利用者の Pod はどこで動くのでしょうか。kubeadm の公式ドキュメントによると、kubeadm で作ったクラスタは、既定では安全のためにコントロールプレーンのノードへ Pod を配置しません。そのうえで、1 台だけのクラスタのようにコントロールプレーンのノードでも Pod を動かしたい場合に、この制限を外す方法を示しています。kind の公式ドキュメントには、シングルノードのときの扱いが書かれていません。kind のソースコードを見ると、ノードが 1 つだけのときはこの制限を外しているので、利用者の Pod もコントロールプレーンのノードで動くと考えられます。Pod がどのノードで動いたかを確かめる方法は、後の回で扱います。

参考：Creating a cluster with kubeadm | Kubernetes、kind のソースコード（kubeadminit/init.go）

Kubernetes のバージョンはノードイメージで決まる

クラスタの Kubernetes のバージョンは、ノードイメージで決まります。kind のリリースごとに既定のノードイメージがあり、--image を付けなければ既定のノードイメージが使われます。2026年10月現在の最新の kind v0.33.0 では、既定のノードイメージは Kubernetes v1.37.0 のものです。v0.33.0 向けにはほかに v1.36.4、v1.35.8、v1.34.11 のノードイメージも用意されています。

参考：Release v0.33.0 · kubernetes-sigs/kind、Quick Start | kind

別のバージョンを使うときは、kind のリリースノートに載っているノードイメージを、タグと sha256 のダイジェスト（イメージの中身から計算した識別子）付きで --image に指定します。kind が動作を保証するのは、そのノードイメージと一緒にリリースされた kind のバージョンで使った場合です。ほかの kind のバージョンとの組み合わせは、できる範囲での対応（best effort）とされています。

参考：Quick Start | kind、Node Image | kind

手元で試す

ここまでの内容を手元のマシンで試す手順を示します。シングルノードとマルチノードのクラスタを作り、ノードの正体が Docker のコンテナであることを確かめます。試す環境は次のとおりです。

参考：Release v0.33.0 · kubernetes-sigs/kind、Version Skew Policy | Kubernetes

kind と kubectl を入れる

Docker が動いている状態で、kind を入れます。macOS で Homebrew を使っている場合は、次のコマンドで入れられます。

$ brew install kind

Go を入れている場合は、次のコマンドでも入れられます。

$ go install sigs.k8s.io/kind@v0.33.0

Homebrew などのパッケージマネージャーで配布されている kind は、kind の開発チームではなくコミュニティが管理しているものです。Linux 向けのバイナリや Windows での入れ方は、公式ドキュメントの Quick Start を見てください。

入れたら、次のコマンドで kind のバージョンを確かめます。

$ kind version

表示の中の v0.33.0 のような部分が kind のバージョンです。この記事より新しい kind が入った場合は、既定のノードイメージ、つまり Kubernetes のバージョンも変わっている可能性があります。そのバージョンの kind のリリースノートで、既定のノードイメージを確かめてください。

参考：Quick Start | kind、kind のリリース一覧

kind は kubectl がなくても動きますが、クラスタを操作するには kubectl が必要です。kubectl は Kubernetes のクラスタにコマンドを送るためのツールで、使い方は第3回で扱います。kind には含まれていないので、別に入れます。macOS で Homebrew を使っている場合は、次のコマンドで入れられます。

$ brew install kubectl

ほかの OS での入れ方は kubernetes.io の Install Tools のページから選べます。入れたら、次のコマンドで kubectl のバージョンを確かめます。

$ kubectl version --client

v1.37 時点の Version Skew Policy では、kubectl が対応するのは kube-apiserver との差がマイナーバージョン 1 つ以内の場合です。v1.37 のクラスタなら、v1.36、v1.37、v1.38 の kubectl を使います。

参考：Quick Start | kind、Install Tools | Kubernetes、Install and Set Up kubectl on macOS | Kubernetes、Version Skew Policy | Kubernetes

シングルノードのクラスタを作る

設定ファイルを渡さずに、クラスタを作ります。

$ kind create cluster

kind は既定のノードイメージから、コントロールプレーンのノードのコンテナを 1 つ作ります。クラスタ名は kind です。一般的に、Docker は手元にないイメージを使うときにダウンロードするので、初回はノードイメージのダウンロードの分だけ時間がかかると考えられます。

参考：Quick Start | kind、Configuration | kind

クラスタができたら、kubectl でクラスタに接続できることを確かめます。--context には、接続するクラスタのコンテキスト名を指定します。

$ kubectl cluster-info --context kind-kind

--context を付けないと、kubectl は kubeconfig の「現在のコンテキスト」の接続先を使います。kind がクラスタを作ったときに現在のコンテキストを切り替えるかどうかは、kind の公式ドキュメントに書かれていません。kubeconfig に別のクラスタの接続情報がある場合に、意図しないクラスタを操作しないよう、この記事では毎回 --context を付けます。

kubectl cluster-info は、コントロールプレーンのアドレスを表示するコマンドです。127.0.0.1 のような手元のマシンのアドレスとポートが表示されれば、kubeconfig を通して kube-apiserver に接続できています。

参考：Quick Start | kind、Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl cluster-info | Kubernetes、Configuration | kind

続けて、クラスタのノードを一覧します。

$ kubectl get nodes --context kind-kind

設定ファイルを渡していないので、ノードは 1 つだけ表示されるはずです。ノードの状態が Ready になっていれば、Pod を受け入れられる状態です。Ready になっていなければ、少し待ってからもう一度実行します。kind create cluster に --wait 5m のように待つ時間の上限を付けると、コントロールプレーンの準備ができるまで待ってからコマンドが終わります。

参考：Configuration | kind、kubectl get | Kubernetes、Node Status | Kubernetes、Quick Start | kind

ノードの正体を確かめる

今度は Kubernetes ではなく Docker の側から見てみます。まず、動いているコンテナを一覧します。

$ docker ps

docker ps は動いている Docker のコンテナを一覧するコマンドです。kind が作ったノードのコンテナが表示されます。公式ドキュメントの例では、クラスタ名 kind のコントロールプレーンのノードのコンテナは kind-control-plane という名前です。名前は NAMES 列で確かめます。ほかに動かしているコンテナがあれば、それも一緒に表示されます。

一方、kube-apiserver のような、ノードの中で動くコンテナは docker ps には出てこないはずです。それらを動かしているのは手元の Docker ではなくノードのコンテナの中の containerd だからです。

参考：docker container ls | Docker Docs、Quick Start | kind、Local Registry | kind

ノードの中のコンテナを見るには、ノードのコンテナの中でコマンドを実行します。

$ docker exec kind-control-plane crictl ps

docker exec は動いているコンテナの中でコマンドを実行する Docker のコマンドです。crictl はノードのコンテナランタイムの様子を確かめるためのコマンドで、crictl ps は動いているコンテナを一覧します。crictl はノードのコンテナの中で実行されるので、手元のマシンに入れる必要はありません。kind の公式ドキュメントもノードのイメージを一覧する例として docker exec でノードのコンテナの中の crictl を実行しています。

このノードでは kubeadm init が実行されているので、一覧の中に kube-apiserver のコンテナが見つかるはずです。ほかにも見慣れない名前が並びますが、ここでは kube-apiserver が見つかれば十分です。ほかのコンポーネントは第4回で扱います。Docker から見れば 1 つのコンテナの中で、Kubernetes のコンテナがいくつも動いていることがわかります。

参考：docker container exec | Docker Docs、Debugging Kubernetes nodes with crictl | Kubernetes、Quick Start | kind、kubeadm init | Kubernetes

マルチノードのクラスタを作る

次に、コントロールプレーン 1 つとワーカー 2 つのクラスタを作ります。以下は、そのための kind の設定ファイルです。公式ドキュメントの例をそのまま引用しています。kind-multi-node.yaml という名前で、コマンドを実行するディレクトリに保存します。

# three node (two workers) cluster config
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

参考：Quick Start | kind

この設定ファイルは kind create cluster が読むもので、クラスタに渡すマニフェストではありません。kind: Cluster と apiVersion: kind.x-k8s.io/v1alpha4 は、kind の設定ファイルであることを表すフィールドです。kind: はツールの kind と同じ綴りですが、マニフェストと同じく種類を表すフィールドです。nodes の 3 行がそれぞれ 1 つのノードのコンテナになります。

参考：Configuration | kind、Objects In Kubernetes | Kubernetes

ここではシングルノードのクラスタを残したまま、2 つ目のクラスタを作ります。docker ps で 2 つのクラスタのコンテナを並べて見比べるためです。手元のマシンの資源（メモリなど）に余裕がなければ、先に「片付け」の kind delete cluster でシングルノードのクラスタを消してからでも構いません。シングルノードのクラスタと名前がぶつからないように、--name でクラスタ名を multi-node にして作ります。

$ kind create cluster --name multi-node --config kind-multi-node.yaml

参考：Quick Start | kind

作ったクラスタを一覧します。

$ kind get clusters

kind と multi-node の 2 つが表示されるはずです（シングルノードのクラスタを先に消した場合は multi-node だけ）。kind ではこのように複数のクラスタを同時に動かせます。

参考：Quick Start | kind

マルチノードのクラスタのノードを、Kubernetes の側と Docker の側からそれぞれ一覧します。公式ドキュメントの例（クラスタ名 kind-2 のコンテキストが kind-kind-2）に倣うと、コンテキスト名は kind-multi-node になります。

$ kubectl get nodes --context kind-multi-node
$ docker ps

kubectl get nodes にはノードが 3 つ表示されるはずです。docker ps には、3 つのコンテナが増えているはずです（シングルノードのクラスタを残していれば、そのコンテナも並びます）。2 つの一覧の名前を見比べてみてください。設定ファイルに書いた role の数だけ、ノードとコンテナができていることを確かめられます。

参考：Configuration | kind、Quick Start | kind、docker container ls | Docker Docs

ワーカーのノードでも docker exec <ノードの名前> crictl ps を実行できます。<ノードの名前> には、docker ps の NAMES 列に表示された、ワーカーのノードのコンテナの名前を入れます。ワーカーのノードでは kubeadm init ではなく kubeadm join が実行されます。kubeadm join でコントロールプレーンのコンポーネントのマニフェストを作るのは、コントロールプレーンのノードとして参加させる場合だけです。そのため、ワーカーの一覧には kube-apiserver が出てこないはずです。

参考：Configuration | kind、kubeadm join | Kubernetes、Quick Start | kind

片付け

作った 2 つのクラスタを削除します。--name を付けなければ、クラスタ名 kind のクラスタが削除されます。

$ kind delete cluster
$ kind delete cluster --name multi-node

kind は存在しないクラスタを指定して削除してもエラーを返しません。何度実行しても同じ結果になるよう、意図してそうしています。そのため、削除のコマンドがエラーなく終わったことだけでは、クラスタが消えたかどうかはわかりません。最後に kind get clusters を実行し、2 つのクラスタが表示されなくなったことを確かめます。docker ps で、ノードのコンテナが残っていないかも見ておくと確実です。

参考：Quick Start | kind

第3回以降の「手元で試す」節では、節の初めにこの記事へのリンクを置きます。試すときは、そのつどこの記事の手順でクラスタを作ってから始めてください。シングルノードとマルチノードのどちらを使うかは、各回の「手元で試す」節に書きます。

注意点

kind を使い始めるときにつまずきやすい点と、バージョンで変わる点を、次の表にまとめます。

参考：Configuration | kind、Known Issues | kind、Version Skew Policy | Kubernetes、Release v0.33.0 · kubernetes-sigs/kind、Node Image | kind

kind の公式ドキュメントは主な用途を Kubernetes そのもののテストとし、手元での開発や CI にも使えると説明しています。トップページには、kind はまだ開発途中（work in progress）だとも書かれています。このメディアでは kind を学習と検証のためだけに使い、本番のサービスを動かすクラスタの作り方としては扱いません。

参考：kind

関連記事

kind が書き込んだ kubeconfig と、kubectl の基本の操作については、以下の記事で解説しています。

基本仕様 第3回 kubectl と kubeconfig の仕組みkubectl がどのクラスタに接続するかを決める kubeconfig の仕組みを図で説明します。clusters・users・contexts の関係と、接続先が決まる順番を押さえ、get・describe・explain の使い分けと、コンテキストを切り替えると接続先が変わることを kind のクラスタで確かめる手順を紹介します。

crictl ps で見えたコントロールプレーンのコンポーネントの役割については、以下の記事で解説しています。

基本仕様 第4回 コントロールプレーンとノードの構成クラスタを形づくるコントロールプレーンとノードの構成を図で説明します。kube-apiserver・etcd・kube-scheduler・kube-controller-manager と、kubelet・コンテナランタイム・kube-proxy の役割を押さえ、kind のクラスタで kube-system の Pod を一覧して各コンポーネントと対応づける手順を紹介します。

kind で作ったクラスタが何を引き受けてくれる仕組みなのかは、第1回で解説しています。

基本仕様 第1回 Kubernetes とは何かKubernetes が何を解決するのかを図で説明する、シリーズの第1回です。docker run で動かしたコンテナと Deployment で動かしたコンテナを比べ、止まったコンテナが自動で戻る仕組みと、望ましい状態を宣言して任せる管理のしかたを紹介します。