Kubernetes Zukai

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

Wed, 21 Oct 2026 00:00:00 +0900

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

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

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

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

手元のマシンの Docker のコンテナがノードになり、その中で Pod が動く kind のクラスタ

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

kind とは

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

kubectl apply と kubectl edit の違い

Wed, 21 Oct 2026 00:00:00 +0900

この記事ではクラスタにあるオブジェクトを更新する 2 つのコマンド kubectl apply と kubectl edit の違いを、図で説明します。それぞれが何をもとに、どこを書き換えるのかがわかります。更新のたびに変わる resourceVersion と、kubectl apply が残す last-applied-configuration（以下、last-applied）の役割もわかります。後半では kind のクラスタで、同じ Deployment を 2 つのコマンドで交互に更新し、この 2 つの値の変化を比べる手順を示します。

マニフェストと宣言的 API を扱った第5回の内容を前提にしています。まだの方は先にこちらをどうぞ。

基本仕様第5回マニフェストと宣言的 API の仕組みKubernetes に渡すマニフェストの構造と、望ましい状態を書いて任せる宣言的 API の仕組みを図で説明します。apiVersion・kind・metadata・spec・status の役割と、spec と status を誰が書くのかを押さえ、kind のクラスタで kubectl explain を使い、Pod の spec と status を作成直後と数秒後で比べる手順を紹介します。

以下の図は、kubectl apply と kubectl edit が、kube-apiserver を通して etcd に保存されている同じ Deployment を更新する流れを表しています。

kubectl apply と kubectl edit が Deployment を更新する流れ（kubectl apply は、既定どおり kubectl の側で差分を計算する場合）

kubectl apply は、利用者が手元に置いたマニフェストをもとに、変わった部分だけを計算します。すでにあるオブジェクトを更新するときは、その部分を patch というリクエストで送ります。kubectl edit は、クラスタにある今のオブジェクトを取り出してエディタで開き、利用者が書き換えて保存した内容を送ります。どちらで更新しても、オブジェクトの中身が変わるので、resourceVersion は変わります。last-applied というアノテーションは、kubectl apply が書き換えます。kubectl edit は、--save-config を付けない限り、このアノテーションを変えません。

kubectl と kubeconfig の仕組み

Wed, 21 Oct 2026 00:00:00 +0900

この記事ではクラスタを操作するコマンドの kubectl と、その接続先を決めるファイルの kubeconfig の仕組みを、図で説明します。kubectl がどうやって接続するクラスタを選んでいるのか、get・describe・explain の 3 つのコマンドをどう使い分けるのかがわかります。後半では第2回の手順で 2 つのクラスタを作り、コンテキストを切り替えて接続先が変わることを確かめる手順を示します。

kind で検証用クラスタを作った第2回の内容を前提にしています。まだの方は先にこちらをどうぞ。

基本仕様第2回 kind で検証用のクラスタを作るDocker のコンテナをノードにして、手元のマシンに Kubernetes のクラスタを作るツール kind の仕組みを図で説明します。kind create cluster で何が起きるかを押さえ、シングルノードとマルチノードのクラスタを作って、ノードの正体が Docker のコンテナであることを確かめる手順を紹介します。

以下の図は、kubectl が kubeconfig を読んで接続先のクラスタを選ぶ様子を表しています。後半の「手元で試す」で 2 つのクラスタを作り、kind-multi-node に切り替えたときの例です。

kubeconfig の現在のコンテキストで決まる、kubectl の接続先

kubectl はフラグで指定しなければ、kubeconfig の現在のコンテキストが指すクラスタの kube-apiserver に接続します。コンテキストを切り替えれば、同じコマンドでも別のクラスタを操作することになります。

Kubernetes とは何か

Wed, 21 Oct 2026 00:00:00 +0900

この記事ではコンテナで動くアプリケーションを管理するための基盤である Kubernetes の仕組みを、図で説明します。Docker でコンテナを直接動かす場合と比べて何が変わるのか、コンテナのプロセスが止まったときに誰が何をするのかがわかります。

この記事はシリーズの第1回で、前提となる回はありません。Docker でコンテナを動かしたことがあれば読み進められます。

以下の図は Kubernetes の全体像を表しています。

利用者が渡した望ましい状態を、コントロールプレーンがノード上の Pod で保つ構成

利用者は「nginx の Pod を 3 つ動かしてほしい」という望ましい状態を書いて渡すだけです。どのノードで動かすか、止まったときにどうするかは、Kubernetes が引き受けます。図では、右上にアイコンが付いた破線の枠がノードです。

Kubernetes とは

Kubernetes はコンテナで動くワークロード（アプリケーションなど、クラスタで動かす処理）とサービス（ここでは、アプリケーションが提供する機能のこと。後の回で扱う Service というリソースとは別の意味）を管理するための、オープンソースのプラットフォームです。公式ドキュメントは Kubernetes を 宣言的な設定と自動化の両方を進めやすくするもの と説明しています。

名前はギリシャ語で「操舵手」や「水先案内人」を意味する言葉に由来します。K と s の間の 8 文字を数えて、K8s とも略されます。Google が 2014 年にオープンソースとして公開しました。

参考：Overview | Kubernetes

Kubernetes は複数のマシンをまとめた クラスタ の上で動きます。クラスタは全体を管理するコントロールプレーンと、1 台以上のノードでできています。Kubernetes に作って管理させるもの（Pod や Deployment など）を、このシリーズではリソースと呼びます。公式ドキュメントではオブジェクト（object）とも呼ばれます。この回で使う用語を、次の表にまとめます。

コントロールプレーンとノードの構成

Wed, 21 Oct 2026 00:00:00 +0900

この記事ではクラスタを形づくる 2 つの部分である コントロールプレーン と ノード の構成を、図で説明します。それぞれの中でどんなコンポーネントが動き、何を受け持っているのか、互いにどうやり取りしているのかがわかります。後半では kind のマルチノードのクラスタで kube-system の Pod を一覧し、各コンポーネントの役割と対応づける手順を示します。

kubectl と kubeconfig を扱った第3回の内容を前提にしています。まだの方は先にこちらをどうぞ。

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

以下の図は、コントロールプレーンとノードのそれぞれで動くコンポーネントと、そのつながりを表しています。

kube-apiserver を中心にやり取りする、コントロールプレーンとノードのコンポーネント

kube-scheduler や kubelet などのコンポーネントは、互いに直接やり取りせず、kube-apiserver を通してやり取りします。クラスタのデータを etcd に読み書きするのも kube-apiserver です。例外はノードの中の kubelet とコンテナランタイムで、kubelet はコンテナランタイムに直接指示を出します。

マニフェストと宣言的 API の仕組み

Wed, 21 Oct 2026 00:00:00 +0900

この記事では Kubernetes に作ってほしいものとその望ましい状態を書いたファイルである マニフェスト と、マニフェストを受け取る 宣言的 API の仕組みを、図で説明します。マニフェストの apiVersion・kind・metadata・spec・status がそれぞれ何を表すのか、spec と status を誰が書くのかがわかります。後半では kind のクラスタで kubectl explain を使ってフィールドの意味を確かめ、Pod の spec と status を作成直後と数秒後で比べる手順を示します。

コントロールプレーンとノードの構成を扱った第4回の内容を前提にしています。まだの方は先にこちらをどうぞ。

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

以下の図は、1 つの Pod について、spec と status をどのコンポーネントが書き込むかを表しています。

Pod のオブジェクトの spec と status に書き込むコンポーネント

利用者がマニフェストで書くのは spec までで、status は書きません。status に Pod の実際の状態を主に書き込むのは、Pod が動くノードの kubelet です。kubelet 以外が Pod の status を書き換える場合もあります。たとえばノードが止まったりクラスタから切り離されたりすると、Kubernetes はそのノードの Pod の phase を Failed にします。spec には、kube-scheduler がノードを選んで割り当てる（binding）と、Pod を動かすノードの名前（spec.nodeName）が入ります。マニフェストを書く線を除き、図の線はどれも kube-apiserver を通ります。第4回で見たとおり、コンポーネントどうしは kube-apiserver を通してやり取りするからです。

消した Pod が戻ってくる仕組み（調整ループ）

Wed, 21 Oct 2026 00:00:00 +0900

この記事では、コントローラーが実際の状態を望ましい状態に近づける繰り返しである 調整ループ（Reconciliation Loop） の仕組みを、図で説明します。Deployment で動かしている Pod を手で消したときに、誰がそれに気づき、どうやって代わりの Pod を作るのかがわかります。後半では kind のクラスタで Deployment の Pod を削除し、作り直される様子を観察する手順を示します。

マニフェストの spec と status を扱った第5回の内容を前提にしています。まだの方は先にこちらをどうぞ。

以下の図は、ReplicaSet のコントローラーが Pod の数を 3 に保つ調整ループを表しています。

replicaset-controller が見る・比べる・変えるを繰り返し、Pod の数を 3 に保つ調整ループ

replicaset-controller は ReplicaSet を受け持つコントローラーです。kube-apiserver を通して ReplicaSet と Pod を監視し（見る）、ReplicaSet の spec.replicas と、実際にある Pod の数を比べます（比べる）。足りなければ、Pod を作るよう kube-apiserver に頼みます（変える）。この 3 つを終わりなく繰り返すのが調整ループです。