はじめに
この実験では、実行中の Pod を操作するための基本的なテクニックを学びます。Kubernetes ではワークロードが分散しており、ローカルプロセスのように直接確認できないことが多いため、これらは重要なデバッグスキルです。
ここでは、次の 3 つの強力なデバッグスキルを扱います。
- ログ：アプリケーションの「声」を読み取り、何が起きているかを確認します。
- Exec：コンテナ内に入り、内部を確認したりコマンドを実行したりします。
- ポート転送：ローカルコンピューターからアプリケーションにアクセスするための一時的なトンネルを作成します。
これらのスキルは、DevOps エンジニアや開発者にとって基本的なものです。この実験を終えるころには、実行中の Pod を自信を持って調査できるようになります。
ログを確認する
このステップでは、実行中の Pod のログを確認する方法を学びます。ログはアプリケーションの「声」だと考えてください。問題が発生した場合、通常はログが最初に手がかりを探す場所になります。
内部では、kubectl logs は通常、メインコンテナのプロセスが標準出力と標準エラー出力に書き込んだ内容を読み取ります。そのため、多くのコンテナ化されたアプリケーションは、ローカルファイルに書き込むのではなく、ターミナルにログを出力するように設計されています。Kubernetes では、ターミナルの出力のほうがプラットフォームで一貫して収集・公開しやすいためです。
環境では、my-nginx という名前の Pod がバックグラウンドで起動しています。まず、Pod が作成されるまで待ちます。
until kubectl get pod my-nginx > /dev/null 2>&1; do sleep 2; done
次に、コンテナの準備が完了するまで待ちます。
kubectl wait --for=condition=ready pod/my-nginx --timeout=300s
Pod が実行中であることを確認します。
kubectl get pods
my-nginx のステータスが Running になっていることを確認してください。まだ準備が完了していない場合は、少し待ってからもう一度実行します。
Pod が実行中になったら、kubectl logs コマンドを使って、コンテナが標準出力に出力した内容を確認します。
kubectl logs my-nginx
Nginx は安定した Web サーバーなので、最初は出力が少ないか、接続を受け付ける準備ができたことを示すメッセージだけが表示される場合があります。
ログをリアルタイムで監視するには、-f（follow）フラグを追加します。
kubectl logs -f my-nginx
カーソルがその場で待機し、新しいメッセージを待っている状態になります。これは、実際に送られてくるトラフィックをリアルタイムで確認するのに便利です。ログの追跡を停止してターミナルのプロンプトに戻るには、Ctrl+C を押します。
コンテナ内で Exec を実行する
このステップでは、ログを読むだけでなく、Pod 内でコマンドを実行します。設定ファイルが存在するか、ツールがインストールされているか、Pod の 内部 からネットワーク接続できるかを確認する必要がある場合があります。
この操作には kubectl exec コマンドを使用します。このコマンドを使うと、実行中のコンテナ内でコマンドを実行できます。通常は対話型シェルを開くために使い、コンテナの内部に「テレポート」するような操作を行います。
ここで重要な点があります。kubectl exec は、SSH のように別のマシンへ「移動」するものではありません。ノード上の kubelet に対して、すでに実行中のコンテナ内で新しいプロセスを開始するよう要求します。そのため、表示されるのはローカルターミナルの環境ではなく、コンテナのファイルシステムと環境です。
次のコマンドを実行して、my-nginx Pod 内で bash シェルを開きます。
kubectl exec -it my-nginx -- /bin/bash
各フラグの意味を確認しましょう。
-i（Interactive）：入力を開いたままにし、文字を入力できるようにします。-t（TTY）：擬似ターミナルを割り当て、通常のコマンドプロンプトのように表示します。--：この位置以降は kubectl のオプションではなく、コンテナ内で実行するコマンドであることを kubectl に伝えます。
コマンドプロンプトが root@my-nginx:/# のような表示に変わります。これで、Kubernetes クラスター内の特定のコンテナに入った状態です。
新しい環境にいることを確認するため、ディレクトリ内のファイルを一覧表示します。
ls -F
ここで表示されるのは Nginx コンテナ内のファイルです。LabEx ワークスペースのファイルとは完全に別のものです。
環境を調査する
このステップでは、コンテナ内の環境を調査します。よくあるデバッグ作業の 1 つは、コンテナで実行されているオペレーティングシステム（OS）を確認することです。これにより、apt や apk など、使用できるコマンドを把握できます。
ここでは、コンテナに関する重要な点も学びます。利用できるユーザー空間のツールとファイルは、コンテナイメージによって決まります。2 つの Pod がどちらも「Linux」であっても、一方のイメージが Debian ベース、もう一方が Alpine ベースであれば、利用できる環境は大きく異なります。また、シェルツールがほとんど含まれていないイメージもあります。
プロンプトがまだ root@my-nginx:/# の状態で、次のコマンドを実行して OS のリリース情報ファイルを読み取ります。
cat /etc/os-release
Linux ディストリビューションを示す出力が表示されます。おそらく Debian GNU/Linux です。これは、公式の Nginx イメージが Debian をベースに構築されているためです。
調査が終わったら、コンテナを終了してメインのターミナルに戻ります。次のように入力してください。
exit
プロンプトが labex:~/project に戻ります。
調査を完了したことを確認するため、os_version.txt というファイルを作成し、確認した OS の名前（例：「Debian」）を書き込みます。
echo "Debian" > ~/project/os_version.txt
ポート転送
このステップでは、ポート転送を使って Nginx Pod にアクセスします。Pod はデフォルトでは分離されています。ゲート付きの住宅地にある家のようなもので、Pod 同士は通信できますが、ローカルターミナルにいる自分のような外部の利用者からは簡単にアクセスできません。
ローカルマシンから my-nginx で実行中の Web サーバーにアクセスするため、ポート転送を使って「秘密のトンネル」を作成します。
ポート転送はデバッグに便利な機能であり、本番環境でアプリケーションを公開する通常の方法ではありません。現在のワークステーションから 1 つの Pod への一時的なトンネルを作成します。完全な Service を作成したり、外部ネットワークポリシーを変更したりせずに、調査や簡単なテストを行える点が便利です。
次のコマンドを実行して、ローカルポート 8080 から Pod のポート 80 へ転送します。
kubectl port-forward my-nginx 8080:80 &
末尾の & に注意してください。 これは、Linux にこのプロセスをバックグラウンドで実行させるための記号です。これを付けないとコマンドがターミナルを占有し、プロセスを停止するまで他の入力ができません。
Forwarding from 127.0.0.1:8080 -> 80 というメッセージが表示されることを確認してください。
これで、curl を使ってこのトンネル経由で Nginx の Web ページにアクセスできます。
curl localhost:8080
Welcome to nginx! ページの HTML コードが表示されます。成功です。クラスター内にアクセスし、トンネル経由でデータを取得できました。
まとめ
この実験では、Kubernetes アプリケーションをデバッグするための 3 つの基本スキルを練習しました。
- ログ：
kubectl logsを使ってアプリケーションの出力を確認する。 - Exec：
kubectl execを使ってコンテナ環境に入り、ファイルの確認やコマンドの実行を行う。 - ポート転送：
kubectl port-forwardを使って内部サービスにローカルからアクセスする。
これらのツールは、聴診器や X 線装置のようなものです。Kubernetes で問題に遭遇したとき、原因を診断するためにまず使うツールがこれらです。
