はじめに
Kubernetes は、コンテナオーケストレーションシステムです。クラスター全体で、コンテナ化されたアプリケーションのスケジュール設定、実行、公開、復旧を管理します。
Kubernetes クラスターを操作するには、通常 kubectl を使用します。アプリケーションをデプロイする前に、実行中のクラスターと、正しい接続先を指すクライアント設定が必要です。
この実験では、Kubernetes クラスターへのアクセスを設定する基本的な手順を実行します。ローカルでシングルノードの Kubernetes クラスターを実行できる Minikube を使用します。Minikube は、学習や開発に適しています。
この実験では、次のことを学びます。
- ローカル Kubernetes クラスターを起動する。
kubectlのコンテキストを確認し、正しいクラスターを操作対象にしていることを確認する。- クラスターの基本情報を取得する。
- クラスター内のノードを一覧表示し、その状態を確認する。
クラスターを起動する
このステップでは、Minikube を使用してローカル Kubernetes クラスターを起動します。Minikube はローカルマシン上に仮想マシンまたはコンテナを作成し、その中にシンプルなクラスターをデプロイします。これにより、クラウドプロバイダーを使わずに Kubernetes のコマンドを練習できます。
ここでは、次の 3 つの概念を明確に区別しておきましょう。クラスターは、Kubernetes 環境全体を指します。ノードは、そのクラスター内にあるマシンです。コントロールプレーンは、API リクエストを受け付け、実行すべき処理を決定する部分です。Minikube はこれらの要素をローカルの学習環境にまとめているため、クラウドインフラストラクチャを扱う前に Kubernetes の概念に集中できます。
まず、プロジェクトディレクトリに移動します。
cd ~/project
次に、Minikube クラスターを起動します。この実験環境に適した docker ドライバーを指定し、Docker コンテナ内でクラスターを実行します。
minikube start --driver=docker
必要な Kubernetes イメージのダウンロードとコントロールプレーンの起動が行われるため、完了まで数分かかることがあります。Minikube がイメージを取得し、コンテナを起動して、クラスターを設定していることを示す出力が表示されます。
コマンドが完了したら、Minikube の状態を確認して、正常に実行されていることを確認します。
minikube status
出力に host、kubelet、apiserver が "Running" と表示されます。
コンテキストを確認する
このステップでは、kubectl コマンドラインツールが、新しく作成した Minikube クラスターと通信するように設定されていることを確認します。
Kubernetes は、通常 ~/.kube/config にある設定ファイルを使用して、クラスターへのアクセス情報を保存します。このファイルには、複数のクラスターに関する情報を保存できます。「コンテキスト」は、kubectl がコマンドを送信するクラスターを決定します。前のステップで Minikube を起動したとき、この設定は自動的に更新され、コンテキストが minikube に設定されています。
この仕組みを理解しておくことは重要です。kubectl はクライアントであり、クラスター自体を「内蔵」しているわけではありません。接続情報、証明書、現在選択されているコンテキストを読み込み、Kubernetes API サーバーにリクエストを送信します。実際の作業では、開発、ステージング、本番のクラスターを切り替えることがよくあるため、現在のコンテキストを確認することは形式的な作業ではなく、安全のための習慣です。
現在のコンテキストを確認するには、次のコマンドを実行します。
kubectl config current-context
次のように表示されます。
minikube
クラスターサーバーの URL やユーザー証明書（安全のため一部が非表示）など、設定の詳細をすべて確認する場合は、次のコマンドを実行します。
kubectl config view
これにより、以降に実行する kubectl コマンドが、ローカルの Minikube クラスターに対して実行されることを確認できます。
クラスター情報を確認する
このステップでは、クラスターへの接続を確認し、Kubernetes コントロールプレーンが実行されている場所を確認するために、クラスターの基本情報を取得します。
cluster-info コマンドを使用すると、kubectl が API サーバーと正常に通信できるかどうかを簡単に確認できます。
Kubernetes は API 駆動型のシステムです。Pod の作成から Deployment のスケーリングまで、ほぼすべての操作がコントロールプレーンへの API リクエストになります。そのため、「クライアントは API サーバーに到達できるか」は、クラスターを調査するときに最初に確認する項目の 1 つです。
次のコマンドを実行します。
kubectl cluster-info
次のような出力が表示されます。
Kubernetes control plane is running at https://127.0.0.1:32769
CoreDNS is running at https://127.0.0.1:32769/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
IP アドレスとポートは異なる場合があります。重要なのは、"Kubernetes control plane is running" と表示されることです。これは、クライアント（kubectl）がサーバー（クラスター）に正常に接続できていることを示します。
ノードを一覧表示する
このステップでは、クラスター内のノードを確認します。ノードは、Kubernetes 内で動作するワーカーマシン（仮想または物理）です。Minikube を使用しているため、コントロールプレーンとワーカーの両方の役割を持つ単一のノードが表示されます。
大規模なクラスターでは、通常これらの役割は分離されています。コントロールプレーンノードはオーケストレーションを担当し、ワーカーノードはアプリケーションのワークロードを実行します。Minikube では学習環境をシンプルにするため、これらを 1 つのノードにまとめています。ただし、コマンドの出力には、本番環境で目にするものと同じ概念が表れます。
クラスター内のすべてのノードを一覧表示するには、get nodes コマンドを使用します。
kubectl get nodes
次のような出力が表示されます。
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 5m20s v1.26.1
各列の意味は次のとおりです。
- NAME: ノード名です。この例では
minikubeです。 - STATUS: ノードの状態です。
Readyと表示されていれば、ノードが正常で、ワークロードを受け入れる準備ができています。 - ROLES: ノードの役割を示します（例：
control-plane）。 - AGE: ノードが起動してから経過した時間です。
- VERSION: ノードにインストールされている Kubernetes のバージョンです。
状態が NotReady の場合、通常はノードの起動中であるか、ネットワークに問題があります。ここでは状態が Ready なので、クラスターは完全に動作しています。
まとめ
この実験では、Kubernetes クラスターにアクセスできるように環境を正常に設定しました。次の操作を行いました。
- Minikube を使用してローカル Kubernetes クラスターを起動しました。
- kubectl のコンテキストがローカルクラスターを操作対象として正しく設定されていることを確認しました。
- クラスター情報を取得し、API サーバーへの接続を確認しました。
- ノードを一覧表示し、クラスターのインフラストラクチャが準備完了で正常な状態であることを確認しました。
これらは、Kubernetes にアプリケーションをデプロイする前に必要となる基本的な手順です。これで、Kubernetes の学習を続けるための動作するローカル環境が整いました。
