はじめに
この実験では、Kubernetes でデプロイできる最小単位である Pod について学びます。
Pod は、Kubernetes が Node にスケジュールするオブジェクトです。通常、Kubernetes ではコンテナを単独で直接実行せず、コンテナを Pod の中に配置します。
1 つの Pod には、ネットワークとストレージのコンテキストを共有する 1 つ以上のコンテナを含めることができます。初心者向けの例では 1 つのコンテナを使用することが多いですが、この共有環境の設計が重要な概念です。
この実験では、次の操作を行います。
- YAML 設定ファイル(設計図)を使って Pod を定義する。
kubectlを使ってクラスター内に Pod を作成する。- Pod のステータスを確認し、実行中であることを確かめる。
- Pod の詳細な設定と履歴を確認する。
この実験が終わるころには、クラスター内の Pod で実際に Web サーバーが実行されています。
Pod を定義する
このステップでは、最初の Pod を定義します。Kubernetes では YAML を使って設定を記述します。YAML ファイルは、アプリケーションをどのような構成にするかを正確に記述する設計図やレシピのようなものです。
Pod は Kubernetes がスケジュールする最小のオブジェクトですが、コンテナと同じものではありません。コンテナは、実行中のアプリケーションプロセスとそのファイルシステムイメージです。Pod は、1 つ以上のコンテナを囲む Kubernetes のラッパーです。このラッパーによって、コンテナはネットワーク ID、ライフサイクル、必要に応じてストレージを共有します。
Pod の定義には、主に次の 4 つの要素が必要です。
- apiVersion:使用する Kubernetes API のバージョン。
- kind:作成するオブジェクトの種類(この場合は
Pod)。 - metadata:名前やラベルなど、オブジェクトを識別する情報。
- spec:「仕様」を表す項目です。実行するコンテナを記述します。
nginx-pod.yaml というファイルを作成します。このファイルでは、nginx-pod という名前の Pod を定義し、nginx イメージ(広く使われている Web サーバー)を使用する 1 つのコンテナを実行します。
nano テキストエディターでファイルを作成します。
nano nginx-pod.yaml
次の内容をファイルにコピーして貼り付けます。先ほど説明した 4 つのセクションを確認しながら、内容を注意深く読んでください。
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
標準的な nano で保存して終了するには、Ctrl+X を押し、保存を確認するために Y を入力してから、ファイル名への書き込みを実行するために Enter を押します。
これで、最初の Kubernetes の設計図を作成できました。このファイルは Kubernetes に対して、「nginx-pod という名前の Pod が必要です。その中で nginx イメージを使う 1 つの コンテナを実行してください」と指示します。
Pod を作成する
設計図(nginx-pod.yaml)を作成できたので、次はそれを Kubernetes に渡します。
この操作には kubectl apply コマンドを使います。このコマンドは Kubernetes に対して、「これが実現したい状態です。この状態になるようにしてください」と設定を伝えます。
望ましい状態(desired state)は、Kubernetes の中心的な考え方の 1 つです。システムに実行すべき細かな手順をすべて指示するのではありません。実現したい最終状態を宣言し、Kubernetes のコントローラーが実際の状態と宣言した状態が一致するまで処理を続けます。
次のコマンドを実行して Pod を作成します。
kubectl apply -f nginx-pod.yaml
次の確認メッセージが表示されます。
pod/nginx-pod created
このコマンドを実行すると、設計図が Kubernetes API サーバー(Control Plane)に送信されます。その後、Scheduler が Pod に適した Node を見つけ、その Node 上の Kubelet が Nginx イメージのダウンロードを開始してコンテナを実行します。
ステータスを確認する
このステップでは、新しく作成した Pod の進行状況を確認します。Pod の作成はすぐに完了するとは限りません。コンテナイメージのダウンロードとアプリケーションの起動に少し時間がかかります。
ここで覚えておきたい点があります。kubectl apply は通常、リクエストを送信するだけなので、すぐに終了します。実際の処理はクラスター内で非同期に行われます。そのため、ステータスを確認することは通常の次の手順であり、問題が発生したという意味ではありません。
Pod のステータスを確認するには、get コマンドを使います。
kubectl get pods
Pod の一覧が表形式で表示されます。STATUS 列を確認してください。
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 15s
STATUS:最も重要な項目です。
ContainerCreating:イメージのダウンロード中、またはコンテナの起動中です。Running:成功です。Pod が起動し、正常に動作しています。Pending:クラスターが Pod を配置する場所を決定中です。ErrorまたはCrashLoopBackOff:問題が発生しています(例:アプリケーションがクラッシュした)。
READY:
1/1と表示される場合、Pod で定義した 1 個のコンテナのうち、1 個がトラフィックを処理できる状態であることを示します。
ContainerCreating と表示された場合は数秒待ってから、もう一度 kubectl get pods を実行してください。Running と表示されれば、Nginx Web サーバーが稼働しています。
詳細を確認する
このステップでは、Pod の内部で何が起きているかを確認する方法を学びます。get コマンドでは概要を確認できますが、特に問題が発生した場合は、正確な状況を確認する必要があります。
describe コマンドを使うと、Kubernetes リソースの詳細なレポートを表示できます。
初心者の方は、kubectl get と kubectl describe を、情報を確認する 2 つの異なるレベルとして考えると分かりやすいでしょう。get は「現在の概要ステータスは何か」を示し、describe は「そこに至るまでに何が起きたか」を示します。このイベント履歴は、多くの場合、根本原因を最も早く特定する手がかりになります。
次のコマンドを実行して、nginx-pod を確認します。
kubectl describe pod nginx-pod
大量の情報が表示されます。出力の下部までスクロールし、Events セクションを探してください。ここには Pod の起動時に発生した出来事が時系列で表示されます。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled ... default-scheduler Successfully assigned default/nginx-pod...
Normal Pulling ... kubelet Pulling image "nginx:latest"
Normal Pulled ... kubelet Successfully pulled image "nginx:latest"...
Normal Created ... kubelet Created container nginx
Normal Started ... kubelet Started container nginx
このイベントログは、問題を調査するときの最初の確認場所です。Pod が Pending または Error の状態で停止している場合、通常は Events セクションに原因が表示されます(例:Insuficient CPU や ImagePullBackOff)。
これで、最初の Kubernetes Pod を作成し、状態を確認し、詳細を調べることができました。
まとめ
この実験では、Kubernetes の基本的な構成要素である Pod の概念を学びました。
次の操作を正常に完了しました。
- Nginx Pod の YAML 設計図を作成した。
kubectl applyを使ってクラスターにデプロイした。kubectl getを使ってRunning状態であることを確認した。kubectl describeを使って起動履歴の詳細を確認した。
Pod を理解することは重要です。Kubernetes の他の概念である Deployment、Service、StatefulSet も、最終的にはこれらの Pod を管理するための仕組みだからです。これで、さらに高度なトピックに取り組む準備ができました。


