コンテナの故障？慌てないでください。デバッグが機能しない場合は、superdebugがあります。

この記事はWeChatの公開アカウント「Cloud Native Treasure Box」から転載したものです。

この記事では主にKubernetesのデバッグ機能について説明し、kubectl debugとkubectl superdebugを紹介します。コンテナのマウントをサポートし、トラブルシューティングが必要な Pod をデバッグできます。この記事では、Kubernetes で kubectl exec コマンドを使用する際の制限を指摘し、実行中のコンテナをデバッグするための新しいコンテナを作成し、同じ Pod 内でシステムリソースを共有できる kubectl debug の役割を紹介しています。さらに、エフェメラルコンテナについても言及されています。デバッグ中に既存の Pod で一時的に実行して、トラブルシューティング操作をサポートできます。最後に、この記事では、Docker Engine や Linux 名前空間ベースのツールの使用など、Kubernetes 以外のローカルデバッグコンテナー方法についてもいくつか説明しています。

kubectl execを使用してコマンドを実行する

Kubernetes 上でソフトウェアを実行する場合、デプロイされたアプリケーションをデバッグしたい場合があります。 VM の使用に慣れている人にとって、デバッグの簡単な方法は、実行中の Pod に接続して共有することです。

 kubectl exec -it podname -c containername -- bash

これは通常機能し、非常に便利です。ただし、現実の世界では exec の有用性を制限する Kubernetes の「ベストプラクティス」が少なくとも 2 つあります。

• root として実行しないでください。コンテナは可能な限り最小限の権限で実行され、ランダムな UID で実行することもできます。

• 最小限のミラーリング。画像はできるだけ小さくする必要があります。極端な場合には、バイナリファイルを distroless イメージにインストールする必要があります。 [1]

これらのベストプラクティスを適用すると、kubectl exec を使用してコンテナーに接続することができなくなるか、デバッグに適さない不毛の荒野に陥ってしまいます。

コンテナのデバッグ

実行中のコンテナをデバッグするための Kubernetes ネイティブの答えは、kubectl debug を使用することです。

デバッグコマンドは、実行中のポッドに新しいコンテナを接続します。この新しいコンテナは、別のユーザーとして任意のイメージから実行できます。デバッグコンテナはターゲットコンテナと同じ Pod (つまり同じノード) で実行されるため、2 つのコンテナ間の分離は絶対的である必要はありません。デバッグコンテナは、同じ Pod で実行されている他のコンテナとシステムリソースを共有できます。

ポッドコンテナで実行されている PostgreSQL データベースの CPU 使用率を確認するとします。 Pod は root として実行されず、Postgres イメージには top や htop などのツールがインストールされていません。つまり、kubectl exec コマンドは役に立ちません。次のコマンドを実行できます。

 kubectl debug -it \ --container=debug-container \ --image=alpine \ --target=postcont \ postpod

root としてログインし (これは Alpine イメージのデフォルトです)、お気に入りの対話型プロセスビューアー htop ( apt add htop ) を簡単にインストールできます。コンテナ postcont と同じプロセス名前空間を共有し、そこで実行されているすべてのプロセスを表示し、強制終了することもできます。プロセスを終了すると、一時コンテナは存在しなくなります。

注: 一時コンテナ/bash セッションを終了せずに切断するには、CTRL+P または CTRL+D を押します。その後、 kubectl attach を使用して再接続できます。

注: kubectl debug は、変更された起動コマンドを使用して Pod を複製したり、ノードファイルシステムにアクセスできる "node" Pod を起動したりするなど、ここで概説した以上の機能を提供します。

一時コンテナ

上記のkubectl debugコマンドは、一時コンテナ[2]と呼ばれるものを作成することで機能します。これらのコンテナは、トラブルシューティングなどの操作をサポートするために、既存の Pod 内で一時的に実行する必要があります。

「通常の」コンテナと一時コンテナの違いは微妙です。一時的なコンテナが長期間実行されるのを妨げるものは実際にはありません。エフェメラルコンテナが存在する理由は、Kubernetes が最初に行ったインフラストラクチャの選択を見ればよく理解できると思います。

• ポッドは使い捨てで交換可能であり、これをサポートする必要がある。

• ポッドの仕様は不変です。

これは、Kubernetes が主にステートレスワークロードのデプロイに使用されていた場合 (Pod 自体が一時的なものと見なされる場合) には非常に理にかなっています。 Kubernetes があらゆることを実行できるこの新しい世界では、制限がある場合があります。 Pod の仕様は同じままですが、Kubernetes は一時的なコンテナを Pod のサブリソースとしてモデル化します。「通常の」コンテナとは異なり、一時コンテナはポッドの一部であるにもかかわらず、ポッド仕様の一部ではありません。この微妙な違いがみんなを幸せにします🥳!

仮設コンテナはまだ比較的新しいものです。

これらは、Kubernetes v1.25 (2022 年 8 月) 以降は安定状態、v1.23 (2021 年 12 月) 以降はベータ状態、v1.22 (2021 年 8 月) 以降はアルファ状態です。

ボリュームのマウント

組み込みコマンド kubectl debug は非常に便利です。実行中の Pod に一時的なコンテナを追加し、オプションでそのプロセス名前空間を実行中のコンテナと共有することができます。ただし、 kubectl debug を使用して実行中のコンテナのファイルシステムの一部を検査または変更したい場合は、残念ながらできません。デバッグ Pod のファイルシステムは、接続しているコンテナのファイルシステムから切断されています。

幸いなことに、私たちはもっと良い方法を見つけられるはずです。アイデアはシンプルです:

• 実行中のターゲットコンテナの仕様を取得します。

• 一時的なコンテナをポッドにパッチ適用する。ターゲットコンテナーと同じプロセス名前空間を共有し、さらに同じボリュームマウントを含めるように構成します。

一時コンテナを作成するための kubectl コマンドはないので、作成するには K8s API に PATCH リクエストを送信する必要があります。 kubectl proxy コマンドを使用すると、K8s API にアクセスできます。

このプロセスはユーザーフレンドリーとは言えないので、プロセスをスクリプトまたは kubectl プラグインにラップするのが理にかなっています。このようなスクリプトの実装例は、次の場所にあります。

 https://github.com/JonMerlevede/kubectl-superdebug

kubectl デバッグ拡張機能は、ターゲットコンテナのボリューム仕様を一時的なデバッグポッドに接続します...

kubectl スーパーデバッグ

このメソッドとスクリプトは、ターゲットコンテナーから環境変数の仕様をコピーするように簡単に拡張できることに注意してください。

このスクリプトを kubectl-superdebug として保存し、パスで使用できるようにすると、次のようにどこからでも kubectl superdebug を使用して実行できます。

 kubectl superdebug \ --container=debug-container \ --image=alpine \ --target=postcont \ postpod

このスクリプトを拡張して、環境変数への参照など、ターゲットコンテナーの他の側面をデバッグコンテナーにコピーすることもできます。

これで、実行中のコンテナをデバッグするための Kubernetes ネイティブメソッドの概要は完了です。これでほとんどの人のニーズが満たされるはずです。

Kubernetes 以外のネイティブメソッド

Kubernetes では、実行中のコンテナに root として接続する方法 (マスタープロセスが root として実行されている場合を除く) や、別のコンテナからコンテナのルートファイルシステムにアクセスする方法は提供されていません。これは、これらのことが実行できないという意味ではありません。結局のところ、Kubernetes はコンテナ化エンジンの上に位置するコンテナオーケストレーターにすぎません。何らかの理由で本当に必要な場合は、通常、抽象化レイヤーを削除することで、必要なことはすべて実行できます。必ず確認してください...

Docker Engine を使用しており、ノードから直接、またはノード上で実行されている特権コンテナを通じてエンジンにアクセスできる場合は、docker exec --user を使用して、任意のユーザーとしてプロセスを実行できます。

kubectl ssh や kubectl exec-user などのプラグインはこのアプローチを実装します。残念ながら、containerd[3]やCRI-O[4]などの最新のエンジンでは、--userフラグ機能が提供されなくなりました。つまり、これらのプラグインは最新のKubernetesインストールでは動作しません。

ただし、これらの最新のエンジンでも、通常は Linux 名前空間とのみ対話します。適切な Linux 名前空間セットを入力することで、任意の「コンテナ」でコマンドを実行できます。 kpexec[5]ツールはこのアプローチを実装しています。ターゲットコンテナと同じノードで特権 Pod を起動し、ターゲットとする (Linux) 名前空間を決定し、それらの (Linux) 名前空間でコマンドを実行し、最後にその出力をターミナルにストリーミングします。追加の利点として、ターゲットコンテナのファイルシステムの上にデバッグに使用できるツールセットがオーバーレイされます。

kubectl exec とは異なり、kpexec はコンテナのメインプロセスとして、異なる uid/gid または異なる機能を持つコマンドを実行できます。 containerd および cri-o と互換性があります。 kpexec は、クラスターのセキュリティ構成と互換性がない可能性のある、やや重くて脆弱なアプローチを使用します。 kubectl (super)debug がニーズを満たさない場合は検討する価値があります。

kpexec は nsenter コマンドを使用して名前空間内で直接実行することに注意してください。これはユビキタスコンテナランタイムruncと互換性がありますが、Kata Containers[6]などのランタイムとは互換性がありません。

この記事では、実行中のコンテナをデバッグするための Kubernetes ネイティブの 2 つの方法、kubectl exec と kubectl debug について説明しました。私たちは kubectl debug がどのように動作するかを調査し、ターゲットコンテナと同じボリュームと同じプロセス名前空間を共有する一時コンテナを起動する kubectl superdebug のバリアントを提案しました。最後に、コンテナをデバッグするための Kubernetes ネイティブではないアプローチをいくつか確認しました。