1. 背景
コンテナとその周囲のエコシステムは、エンジニアがワークロードを展開、保守、トラブルシューティングする方法を変えます。ただし、必要なデバッグ ツールがコンテナ内に見つからない可能性があるため、Kubernetes クラスター上でアプリケーションをデバッグすることが困難になる場合があります。多くのエンジニアは、ディストリビューション ベース イメージを使用せずに、必要最低限のディストリビューション ベースのビルドを使用しています。ディストリビューション ベース イメージには、パッケージ マネージャーやシェルさえありません。また、一部のチームでは、ベース イメージとしてスクラッチを使用し、アプリケーションに必要なファイルのみを追加します。走る。 この一般的な慣行の理由としては、次のようなものがあります。
ビルドを高速化し、CD/CI サイクルを短縮します。
これらの必要なものを取り除いた基本イメージには、Kubernetes の一時コンテナー機能の最大の用途である、アプリケーションまたはその依存関係のトラブルシューティングを行うためのツールは含まれていません。一時コンテナーを使用すると、必要なすべてのデバッグ ツールを含むコンテナー イメージを作成できます。デバッグが必要になったら、ステージング コンテナを選択した実行中のポッドにデプロイできます。 デプロイされたコンテナにコンテナを追加することはできないため、仕様を更新し、リソースを再作成する必要があります。ただし、オンラインの問題のトラブルシューティングを容易にするために、一時コンテナを既存のポッドに追加できます。
2. 一時コンテナの構成
一時コンテナは、通常のコンテナと同じ仕様を共有します。ただし、一部のフィールドは無効になり、一部の動作は変更されます。 重大な変更の一部を以下に示します。完全なリストについては、暫定コンテナ仕様を確認してください。
スタートアップ、アクティビティ、準備プローブは許可されません。
3. 一時コンテナを起動します
まず、一時コンテナ機能が有効になっているかどうかを確認します。
kubectl debug - it < POD_NAME > - - image= busybox
この機能が有効になっていない場合は、次のようなメッセージが表示されます。
Defaulting debug container name to debugger- wg54p.
error: ephemeral containers are disabled for this cluster ( error from server: "the server could not find the requested resource" ) .
kubelet、kube-apiserver、kube-controller-manager、kube-proxy、kube-scheduler パラメーターの –feature-gates= に EphemeralContainers=true を追加します。次に例を示します。
...
- - feature- gates= RemoveSelfLink = false , EphemeralContainers = true
...
4. 一時的なコンテナを使用する
現在、クラスターは一時コンテナー機能をサポートしています。一時コンテナーを作成するには、kubectl コマンド ライン ツールの debug サブコマンドを使用します。まず、デプロイメントを作成します。
kubectl create deployment nginx- deployment - - image= nginx
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx- deployment- 66b6c48dd5- frsv9 1 / 1 Running 6 62d
次のコマンドは、busybox によってミラーリングされるポッド nginx-deployment-66b6c48dd5-frsv9 に新しい一時コンテナーを作成します。-i パラメーターと -t パラメーターを使用すると、新しく作成されたコンテナーにアタッチできます。
$ kubectl debug - it pods/ nginx- deployment- 66b6c48dd5- frsv9 - - image= busybox
/ # ping 8.8 . 8.8
PING 8.8 . 8.8 ( 8.8 . 8.8 ) : 56 data bytes
64 bytes from 8.8 . 8.8 : seq= 0 ttl= 112 time= 9.797 ms
64 bytes from 8.8 . 8.8 : seq= 1 ttl= 112 time= 9.809 ms
^ C
/ # nc - - help
BusyBox v1.34 . 1 ( 2021 - 11 - 11 01 : 55 : 05 UTC ) multi- call binary.
Usage : nc [ OPTIONS ] HOST PORT - connect
nc [ OPTIONS ] - l - p PORT [ HOST ] [ PORT ] - listen
...
kubectl description pod <POD_NAME> コマンドを使用すると、新しいフィールド「一時コンテナー」が表示されます。このセクションには一時コンテナーとそのプロパティが含まれます。
$ kubectl describe pods < POD_NAME >
...
...
Ephemeral Containers :
debugger- thwrn:
Container ID : containerd: / / eec23aa9ee63d96b82970bb947b29cbacc30685bbc3418ba840dee109f871bf0
Image : busybox
Image ID : docker. io/ library/ busybox@ sha256: e7157b6d7ebbe2cce5eaa8cfe8aa4fa82d173999b9f90a9ec42e57323546c353
Port : < none>
Host Port : < none>
5. プロセス名前空間を一時コンテナと共有する
プロセス名前空間の共有は常に優れたトラブルシューティング オプションであり、この機能は一時的なコンテナーで利用できます。プロセス名前空間の共有は既存のコンテナには適用できないため、ターゲット コンテナのコピーを作成する必要があります。 –share-processesflag は、--copy-to と一緒に使用すると、プロセス名前空間の共有を有効にします。これらのフラグは、既存の Pod 仕様定義を新しい定義にコピーし、仕様内でのプロセス名前空間の共有を有効にします。
$ kubectl debug - it < POD_NAME > - - image= busybox - - share- processes - - copy- to= debug- pod
ps コマンドを実行して実行中のプロセスを確認すると、予想通り、busybox コンテナからは /pause が、nginx-deployment コンテナからは nginx プロセスが表示されます。
# ps aux
PID USER TIME COMMAND
1 root 0 : 00 / pause
6 root 0 : 00 nginx: master process nginx - g daemon off;
11 101 0 : 00 nginx: worker process
12 root 0 : 00 sh
17 root 0 : 00 ps aux
プロセス名前空間を使用すると、デバッグに役立つ共有コンテナ ファイル システムにもアクセスでき、コンテナには /proc//root リンクを使用してアクセスできます。上記の出力から、nginx の PID が 6 であることがわかります。
# ls / proc/ 6 / root/ etc/ nginx
conf. d koi- utf mime. types nginx. conf uwsgi_params fastcgi_params koi- win modules scgi_params win- utf
ここでは、ターゲット コンテナ上の Nginx ディレクトリ構造と構成ファイルを確認できます。
6. 結論
一時コンテナ機能は間違いなく問題のデバッグとトラブルシューティングに大きな利便性をもたらしますが、プロセス名前空間の共有により高度なデバッグ機能が可能になります。 Kubernetes クラスターで実行されているアプリケーションも使用している場合は、時間をかけてこれらの機能を試してみる価値があります。 Readiness Probe が失敗したときに他のコンテナを自動的に修復するなど、ワークフローを自動化するためにこれらのツールを使用しているチームもあることは想像に難くありません。