はじめに
Rocky Linux 9上で、kindを使って学習・検証用のKubernetesクラスタを作成します。
今回の構成は、コントロールプレーン1台とワーカー2台の合計3ノードです。
| 項目 | 設定 |
|---|---|
| クラスタ名 | training |
| コントロールプレーン | 1ノード |
| ワーカー | 2ノード |
| Kubernetes | v1.31.0 |
| ノードイメージ | kindest/node:v1.31.0 |
kindでは、各ノードがホスト上のコンテナとして動作します。今回の構成では、1台のホスト上に3つのノードを作成します。
1. 前提条件
以下の準備が完了していることを前提とします。
- Docker Engineがインストールされ、起動している
- 作業ユーザーが
sudoなしでDockerを実行できる - kubectl v1.31.4がインストールされている
- kind v0.24.0がインストールされている
- ノードイメージを取得するためのネットワーク接続がある
本記事では、クラスタ作成から確認まで、同じユーザーで作業します。ユーザーを切り替えると、ホームディレクトリやkubectlの接続設定の保存先が変わるためです。
2. 作業ディレクトリを作成する
作業ディレクトリを作成し、そのディレクトリへ移動します。
mkdir -p ~/kcna && cd ~/kcna
以降のコマンドは、~/kcnaで実行します。
-
mkdir -p：ディレクトリを作成する。すでに存在する場合もエラーにしない -
&&：左側のコマンドが成功した場合に、右側のコマンドを実行する -
~：現在のユーザーのホームディレクトリを表す
3. クラスタの設定ファイルを作成する
コントロールプレーン1台、ワーカー2台の構成を、kind-training.yamlに定義します。
cat <<'EOF' > kind-training.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: training
nodes:
- role: control-plane
image: kindest/node:v1.31.0
- role: worker
image: kindest/node:v1.31.0
- role: worker
image: kindest/node:v1.31.0
EOF
設定内容
| 項目 | 意味 |
|---|---|
kind: Cluster |
kindのクラスタ設定であることを指定 |
apiVersion |
kindの設定ファイルのAPIバージョン |
name: training |
クラスタ名をtrainingに指定 |
nodes |
作成するノードの一覧 |
role: control-plane |
コントロールプレーンとして使用するノード |
role: worker |
ワーカーとして使用するノード |
image |
ノードに使用するコンテナイメージ |
apiVersionは設定ファイルの形式を表すものであり、Kubernetes本体のバージョンではありません。Kubernetesのバージョンは、ここではimageで指定しています。
<<'EOF'は、終端のEOFまでを入力として扱うヒアドキュメントです。> kind-training.yamlによって、その内容をファイルへ保存します。既存ファイルがある場合は上書きします。
4. クラスタを作成する
設定ファイルを指定して、クラスタを作成します。
kind create cluster --config kind-training.yaml
初回はノードイメージのダウンロードも行うため、数分かかることがあります。所要時間はネットワーク速度やホストの性能によって変わります。
kubectlの接続設定
作成が成功すると、kubectlからクラスタへ接続するための設定が登録され、通常はkind-trainingコンテキストが選択されます。
接続設定は、標準では~/.kube/configに保存されます。環境変数KUBECONFIGや、kindの--kubeconfigオプションを指定している場合は、保存先が変わります。
5. 接続先のクラスタを確認する
ノードの確認や操作を行う前に、kubectlの接続先を確認します。
kubectl config current-context
kubectl cluster-info
kubectl config current-contextの想定出力：
kind-training
異なるコンテキストが選択されている場合は、次のコマンドで切り替えます。
kubectl config use-context kind-training
コンテキストとは
コンテキストは、以下をまとめた設定です。
- 接続先クラスタ
- 使用する認証情報
- 既定の名前空間
kubectl cluster-infoは、現在の接続先について、APIサーバーなどの接続先情報を表示します。
複数のクラスタを使用する場合は、操作前にコンテキストを確認することで、意図しないクラスタへの操作を防ぎやすくなります。
参考：Kubernetes公式ドキュメント：kubeconfigによるクラスタアクセスの整理
6. ノードの状態を確認する
kubectl get nodes -o wide
-o wideを指定すると、通常の表示に加えて、ノードのIPアドレスやOS、コンテナランタイムなども表示されます。
以下は、今回の設定で期待される主要な列を抜粋した表示例です。実際の実行ログではありません。
NAME STATUS ROLES VERSION
training-control-plane Ready control-plane v1.31.0
training-worker Ready <none> v1.31.0
training-worker2 Ready <none> v1.31.0
確認するポイント
- 3つのノードが表示されている
- すべてのノードの
STATUSがReadyになっている -
VERSIONが設定したv1.31.0になっている
ワーカーのROLESが<none>でも、それだけで異常とは限りません。この列はノードのロールラベルに基づく表示です。
作成直後にNotReadyが表示された場合は、少し待って再確認してください。状態が変わらない場合は、後述の調査手順で詳細を確認します。
7. kube-systemのPodを確認する
Kubernetesの主要コンポーネントや、DNS・ネットワーク関連のPodを確認します。
kubectl get pods -n kube-system
-n kube-systemは、確認対象の名前空間をkube-systemに指定するオプションです。
主なコンポーネント
| Pod名の先頭・名称 | 役割 |
|---|---|
kube-apiserver |
kubectlなどからの操作を受け付けるAPIの窓口 |
etcd |
クラスタの設定や状態を保存するデータストア |
kube-scheduler |
新しいPodをどのノードで実行するか決定 |
kube-controller-manager |
実際の状態が指定した状態に近づくよう調整 |
coredns |
クラスタ内でServiceなどの名前解決を提供 |
kube-proxy |
Service宛ての通信を対応するPodへ転送するための通信ルールを管理 |
kindnet |
kindでPod間の通信を支えるネットワーク機能 |
確認するポイント
- 主要なPodの
STATUSがRunningになっている -
READYが1/1など、必要なコンテナ数を満たしている -
RESTARTSが短時間に増え続けていない
Pod名の末尾、経過時間、再起動回数は環境によって異なります。
また、RunningはPodの動作状態を表し、READYはコンテナの準備状態を表します。両方を確認してください。
参考：Kubernetes公式ドキュメント：Kubernetes Components
8. クラスタ作成に失敗した場合の確認方法
作成コマンドが失敗した場合と、作成後にノードがNotReadyになる場合では、確認できる情報が異なります。
まず、クラスタやノードコンテナが残っているかを確認します。
8.1 kindとDockerの状態を確認する
kind get clusters
docker ps -a
kind get clustersでtrainingが表示されるか、docker ps -aで以下のノードコンテナが存在するかを確認します。
training-control-planetraining-workertraining-worker2
8.2 APIサーバーに接続できる場合
kubectlで接続できる場合は、ノードの状態と詳細を確認します。
kubectl --context kind-training get nodes -o wide
kubectl --context kind-training describe node training-worker
describe nodeでは、主に以下を確認します。
| 項目 | 確認内容 |
|---|---|
Conditions |
Readyの状態や、メモリ・ディスクなどの不足 |
Allocated resources |
CPU・メモリのRequestsとLimits |
Events |
ノードで発生したイベント |
末尾だけを確認したい場合は、次のように表示できます。
kubectl --context kind-training describe node training-worker | tail -n 20
ただし、tailではConditionsなどの情報が省略されるため、調査時は全体の出力も確認してください。
イベントにWarning Rebootedが表示されていても、その記録だけではクラスタ作成失敗の原因と断定できません。現在のノード状態や、ほかのイベントと合わせて判断します。
8.3 kubectlで接続できない場合
APIサーバーに接続できない場合は、kubectl describeも実行できません。
ノードコンテナが残っている場合は、kindのログを保存して確認します。
kind export logs ./kind-logs --name training
クラスタの状態によっては、ログを取得できない場合もあります。その場合は、作成コマンドのエラーメッセージとDocker側の状態を確認してください。
参考：kind公式ドキュメント：Exporting Cluster Logs
9. クラスタを削除して再作成する
原因の確認や必要な修正を行ったうえで、検証環境を作り直す場合は、クラスタを削除して再作成します。
クラスタを削除すると、そのクラスタ内に作成したリソースや、ノードコンテナ内のデータは失われます。必要な設定やログは、削除前に保存してください。
kind delete cluster --name training
kind create cluster --config kind-training.yaml
再作成後は、接続先とノードの状態を確認します。
kubectl config current-context
kubectl --context kind-training get nodes -o wide
kubectl --context kind-training get pods -n kube-system
3ノードがReadyになり、主要なPodが準備できていれば、学習・検証用クラスタの基本的な動作確認は完了です。