Kubernetesコンテナの問題を「Kubectl Debug」で調査する方法

Kubernetesワークロードの問題を診断するのは難しいことがあります。アプリケーションのログに原因を見つけることができれば、運がいいかもしれません。

kubectl logs

コマンド。一部の場合では、ポッドと対話しながら問題を明らかにするライブデバッグセッションを避けることはできません。

kubectl debug コマンドは、Pod内に新しい一時的なコンテナを提供することで、これらのデバッグ作業を簡素化します。これを使用して、Podの環境を検査し、既存のコンテナに現れている問題のトラブルシューティングを開始できます。

Kubectlデバッグの使用準備

kubectl debugはKubernetesとKubectlのv1.18で導入されました。それは、クラスター内で一時コンテナが利用可能であることに依存しています。一時コンテナはKubernetes v1.23でベータ機能となり、現在はデフォルトで有効になっています。クラスターが古いKubernetesバージョンを実行している場合は、手動で機能ゲートを有効にする必要があります。

エフェメラルコンテナは、一時的に既存のPodに追加のコンテナを接続する必要がある一時的なタスクのために設計されています。これは、ライブコンテナインスタンスに影響を与えずにPodを正確に検査したいデバッグ操作に最適です。

ほとんどのコンテナイメージにはデバッグツールが不足しており、実行中のコンテナ内にそれらをインストールすると、その環境が変更され、副作用を引き起こす可能性があります。ポッドにエフェメラルコンテナを接続することは、安全なデバッグ方法で、クリーンな作業環境を提供してくれます。必要なすべてのツールを含む重めのイメージを使用することができます。

エフェメラルコンテナはホストPodの一部となりますが、注意すべきいくつかの違いがあります。エフェメラルコンテナは、その性質上一時的であるため、ポートバインディング、プローブ、リソース予約をサポートしていません。自動で再起動されることはなく、一度作成されると変更することもできません。サポートされている機能の完全なリストはドキュメントにあります。

Kubectlデバッグの使用

続ける前に、テスト目的のために基本的なデプロイメントを作成してください。

kubectl create deployment nginx --image=nginx:latest


deployment.apps/nginx created

次に、get podsコマンドを使用して、デプロイメントのPodの名前を見つけます:

kubectl get pods


NAME READY STATUS RESTARTS AGE

nginx-55649fd747-qsnr2 1/1 Running 0 5s

私たちのデプロイメントのPodはnginx-55649fd747-qsnr2と呼ばれています。

今、kubectl debug コマンドを使って、Pod内でデバッグセッションを開始できます:

kubectl debug -it --image=ubuntu:20.04 nginx-55649fd747-qsnr2

このコマンドの構文は、kubectl create と kubectl debug のハイブリッドに似ています。コマンドに渡された名前のない引数は、接続する既存の Pod を特定します。--image 引数は、新しいコンテナに使用するイメージを指定します。ここでは、Ubuntu Linux ディストリビューションに含まれるお馴染みのコマンドにアクセスするために ubuntu:20.04 を使用しています。

-itフラグは--stdin --ttyに相当します。これらの引数を含めると、コンテナにTTYが割り当てられ、接続され、ターミナルのstdinストリームが接続されます。これにより、新しいコンテナ内でインタラクティブなシェルが利用可能になります。

これで、一時的なコンテナ内でデバッグ作業を実行できるようになりました。

ポッドのコピー

kubectl debug を使用する別の方法は、--copy-to 引数を使用することです。これにより、ターゲットの Pod のコピーが作成され、そのコピーに一時的なコンテナが追加されます。元の Pod はそのまま残ります。

kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug nginx-555649fd747-qsnr2

この機能は、デバッグ中に行った変更が本番アプリケーションに直接影響を与えないというさらなる保証を提供します。

ポッドをコピーすると、プロセス名前空間共有を有効にすることもできます。これにより、ポッド内の既存のプロセスがエフェメラルコンテナに表示されるようになります。既存のコンテナとは使用できません。なぜなら、彼らの spec.shareProcessNamespace フィールドは通常 false に設定されるからです。 kubectl debug を --copy-to および --share-processes フラグで実行すると、コピーしたポッドでプロセス共有が有効になり、この手順がより直感的になります:

kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --share-processes nginx-555649fd747-qsnr2

あなたの一時的なUbuntuコンテナで表示されるプロセスリストには、今、NGINXプロセスが含まれます：

ps ax


PID USER TIME COMMAND

 1 root 0:00 /pause

 9 root 0:00 nginx: master process nginx -g daemon off;

このプロセスは、あなたのポッド内の別のNGINXコンテナでまだ実行中です。名前空間の共有により、/procを介してターゲットコンテナのファイルシステムにアクセスすることもできます。

ls /proc/9/root/etc/nginx


conf.d fastcgi_params mime.types modules nginx.conf ...

このようにPodをコピーすることは強力なデバッグツールです。お馴染みのツールで準備された別のコンテナを使用して、Podのファイルやプロセスを簡単に調査できます。

オプション引数

--copy-to フラグは、デフォルトで元の Pod をそのまま維持します。--replace を使用することで、操作を置き換えとして動作させることができます。これにより、最初の Pod が停止します。

kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --replace nginx-555649fd747-qsnr2

Kubernetesは、コピーされたPodを利用可能な任意のNodeにスケジュールします。これは、安定したテスト環境を確保したい場合には問題となる可能性があります。--same-nodeを追加すると、コピーは既存のPodのNodeにスケジュールされ、クラスター内のマシン間の違いが排除されます。

kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --same-node nginx-555649fd747-qsnr2

もう一つ便利なオプションは、エフェメラルコンテナ内に追加の環境変数を設定するための--envです。デバッグツールを設定したり、ターゲットPodから継承された値を上書きするためにこれを使用する必要があるかもしれません。

kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --env EDITOR=/usr/bin/nano nginx-555649fd747-qsnr2

最後に、kubectl debug で作成されたコンテナは対話的である必要はないことを覚えておいてください。kubectl exec のような構文を使用して、Pod に対して簡単に一時的なコマンドを実行できます。--attach 引数は、-i （--stdin）を使用していない場合にシェルがコンテナに接続されるかどうかを制御するためにサポートされています。

kubectl debug --image=ubuntu:20.04 --copy-to nginx-debug --share-processes --attach true nginx-555649fd747-qsnr2 -- ls /proc/9/root/etc/nginx


conf.d fastcgi_params mime.types modules nginx.conf ...

結論

一時的なコンテナとkubectl debugコマンドは、Kubernetesワークロードの簡素化されたデバッグ体験を提供します。通常のコンテナとは異なるイメージを使用してPod内でコマンドを実行できます。これにより、アプリケーションのイメージに含まれていないデバッグツールにアクセスできます。

kubectl debug は、Pod のコピーを作成し、元の Pod とそのプロセスを共有することもできます。このメカニズムにより、あなたが完全に制御できる別の一時的なコンテナから、ターゲット Pod のコンテナ内のプロセスを検査できます。実行中のプロセスを調査する必要があるときに、より高度なデバッグオプションを提供します。