Pod 内のコンテナをリモートでデバッグする方法 (補足記事)

みなさんこんにちは。私は次男です。この記事は以前にも投稿されていますが、ネットユーザーからの質問に答える過程で、SOPとして強調していなかった元の記事のいくつかの手順が、livenessProbeなどのリモートデバッグ環境を誰もが正常に構築できるかどうかに実際に非常に重要であることに気付きました。そのため、多くの学生のデバッグセッションが突然中断されました。記事を再編成し、元の記事のいくつかの問題を修正しました。

ボディセパレーター

面接のシナリオでは、デバッグの問題に関して、通常次のような会話が行われます。

セカンドブラザー：開発時にデバッグするためにどのような方法を使用していますか？

申請者: ログを見てください。

2 番目の兄弟: ログ レベルが正しく設定されていない場合、または重要な場所がログに記録されていない場合はどうなりますか?

応募者: 次に、コードを変更し、ログを追加し、サービスを再起動して、ログの読み取りを続けます。

ログを見ることによるデバッグの効率についてはここでは触れません。これは VM 上では実現可能ですが、アプリケーションをコンテナ化して K8s で管理する場合はどうすればよいでしょうか? systemctl や monit などのコマンドを実行して Pod 内のアプリケーションを再起動するのは便利ではないことは誰もが知っています。ログ表示方式を引き続き使用する場合は、残された方法は 1 つだけです。

• コードを変更し、ログを追加します。
• git にコミットします。
• CI/CD。
• ログが正しく追加されていない場合、または関数呼び出しの戻り値を確認する場合は、手順 1 からやり直してください。

えっと、かなり疲れているように見えますね。 CI/CD と K8s も大きな問題となっています。私の次男は強迫性障害を少し患っており、このような拷問のようなデバッグ方法には耐えられません。さらに、手動でログを表示する場合と比較して、デバッガーを使用したデバッグはより洗練され、高速であり、RD の想像力を刺激することもできます。最も重要なのは、デバッガーを使用してデバッグすると、コード呼び出しロジックや OS の相互作用など、複数の角度から問題について RD が考えるようになることです。たとえば、ブレークポイントを設定することは難しくありませんが、ブレークポイントをいつ設定するか、どこに最も適切にブレークポイントを設定するかを知ることが難しい部分です。 「道・法・術・道具・力」が老子の『道経』の真髄です。この記事は実際には「スキル」と「ツール」について語っていますが、私が言いたいのは「タオ」の方がより本質的でより重要であるということです。それは中核となる考え方、概念、そして基本的な法則です。好奇心旺盛な学生は、これらの「テクニック」の背後にある実装原則についてさらに考えることを強くお勧めします。ローカル マシンから Pod 内のアプリケーションをリモートでデバッグする方法を例を使って説明します。アプリケーション自体は非常にシンプルで、Node.js で書かれた http サーバーです。他の言語で書かれたアプリケーションの場合は、回避策が必ず見つかります。

1. 妨害の準備と排除

以下に挙げる準備は、デバッグ プロセス中に注意をそらす要素を多く排除し、問題そのものに集中できるようにすることを目的としています。次兄からの親切なリマインダー: 本番環境ではこれを行わないでください。

1. シーンをマークする

デバッグを容易にするために、Deployment/ReplicaSet/StatefulSet/DaemonSet などのワークロード リソースにいくつかの変更を加えます。修正後は元の状態に戻す必要があるため、修正前のシーンがどのような状態だったかを覚えておく必要があります。

 #最新のデプロイメントREVISION を4 として取得します。これは後で復元に使用されます。
 $ kubectl ロールアウト履歴デプロイメント/ nodejs -n lancehbzhang
 改訂変更- 原因
1 < なし>
 3 < なし>
 4 < なし>

2. Podインスタンスを1に設定する

Pod のレプリカを 1 に設定します。そうしないと、デバッガーによって送信されたデバッグ コマンドがどこに送信されたかを探すのに苦労することになります。

 $ kubectl patch deploy / nodejs -n lancehbzhang -p = '{"spec": {"replicas": 1 }} '

3. ライブネスプローブ

K8s の livenessProbe と readinessProbe を覚えていますか?コンテナ内のアプリケーションがデバッグのためにこれら 2 つのプローブに長時間応答しない場合は、K8s によって Pod が強制終了される可能性があります。このとき、苦労して待ち望んだブレークポイントが一瞬で消えてしまうかもしれません。次兄がどうやってそれを知ったのか聞かないでください。涙が出ました。 kubectl patch deploy/nodejs を介してダミーの livenessProbe と readinessProbe をインストールするなど、インターネット上には多くの解決策があります。このダミー プローブは、コンテナーがアクティブかどうかを実際にプローブする必要はなく、常に true を返します。たとえば、次の方法では、kubectl patch コマンドを使用してデプロイメント仕様を変更します。

 #livenessProbe を削除
$ kubectl patch deploy / nodejs - n lancehbzhang --type json - p = '[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' を実行します。

 # ダミーのlivenessProbeをインストールする
$ kubectl patch deploy / nodejs - n lancehbzhang - p '{"spec": {"template": {"spec": {"containers": [{"name": "nodejs", "livenessProbe": {"initialDelaySeconds": 5, "periodSeconds": 5, "exec": {"command": ["true"]}}}]}}}}'

4. 現場の修復

このステップは先頭に配置されていますが、デバッグが完了したら、次のコマンドを実行するだけでシーンを復元できます。

 # デプロイメントへの復元REVISION 4
 $ kubectl rollout デプロイメントを元に戻すnodejs --to - リビジョン= 4 - n lancehbzhang

2. コンテナをデバッグモードに切り替える

まず、http サーバーをデバッグ モードに切り替える必要があります。ここでのデモ方法は Node.js でのみ機能することに注意してください。

 kubectl exec nodejs - 8448 d4cbc6 - nbjwd - n lancehbzhang -- / bin / bash - c "kill -USR1 1"

すべてがうまくいけば、Pod ログに次の情報が表示されます。これは、デバッガーがポート 9229 でリッスンしていることを意味します。

図1: コンテナをデバッグモードに切り替える

3. K8s ポート転送

次の質問は、ローカル デバッガーによって発行されたデバッグ コマンドをどのように接続できるかということです。

実際には、いくつかの方法があります。たとえば、ロードバランサタイプのサービスを通じて。ただし、この方法は比較的高価です。私の知る限り、Tencent Cloud のロードバランサーは非常に高価です。ここでは、無料で普遍的な方法を紹介したいと思います。 K8s のポート転送機能を使用します。コマンドは次のとおりです。

 $ kubectl ポート- フォワードデプロイ/ nodejs - n lancehbzhang 9229 : 9229

kubectl コマンドを実行できるマシンでこのコマンドを実行すると、すべてがうまくいけば次のインターフェースが表示されます。

図2: K8sポート転送の使用

おめでとう！つまり、今後、このマシンのポート 9229 に送信されたすべてのリクエストは、nodejs ポッドのポート 9229 に転送されます。ご想像のとおり、これはデバッガーがリッスンしているポートです。ここまでで、次の図の ③ と ④ の準備はできているはずです。

図 3: ローカル デバッガからリモート デバッグ対象までのパノラマ

4. SSHトンネル（オプション）

袖をまくってローカルマシンから接続する準備はできていますか?待ってください、まだ解決していないシナリオが 1 つあります。

kubectl port-forward を実行しているマシンをローカルマシンに直接接続できない場合はどうなりますか?セキュリティ上の理由から、上図の③と④はネットワークに直接接続できますが、①と③はファイアウォールで分離されており、①がssh経由で③にログインするためのポートは22のみとなっています。この場合、ローカルマシンから手順 ④ のデバッガーに接続するにはどうすればよいでしょうか?ここで、手順 ② で示した SSH トンネルが役立ちます。このように、ローカルの VS コードは 127.0.0.1:9229 に接続するだけで、ブレークポイントの設定、シングルステップ実行、変数の表示などのデバッグコマンドがカプセル化され、SSH トンネルに接続されて ③ に送信され、ポート転送によって ④ のデバッグ対象に転送されます。

注: SSH トンネルの使用はこの記事の焦点では​​ありません。使用方法はGoogleで検索できます。 SSH トンネルの詳細については、私の記事「手元にあるトンネルについてどれだけ知っていますか」を参照してください。

実際には、長時間データがない場合、SSH トンネルは閉じられます。キープアライブメカニズムを有効にすることができます。さらに、SSH トンネル ログの詳細レベルを適切なレベルに設定すると、トンネルが現在動作しているかどうかを把握するのにも役立ちます。

図4: SSHトンネルの詳細設定を維持する

5. デモンストレーション

はい、準備は完了です。さあ、次男のパフォーマンスが始まります。

ローカル マシンで VS Code を開き、launch.json に次の構成を入力します。パラメータ port はローカルデバッガが接続する必要があるポートを示し、localRoot はローカルコードパスを示し、remoteRoot は ④ のアプリケーションが配置されているパスを示します。 Docker イメージをビルドするときに、弟がアプリケーションの WORKDIR を /myapp に設定したので、ここでも /myapp を入力する必要があります。その他のパラメータについては、ご自身で Google で検索してください。

 {
 // IntelliSense を使用して、可能な属性について学習します。
 // マウスをホバーすると、既存の属性の説明が表示されます。
 // 詳細については、https://go.microsoft.com/fwlink/?linkid=830387 をご覧ください。
 「バージョン」 : 「0.2.0」 、
 「構成」 : [
 {
 「名前」 : 「Attach-2-nodejs」 、
 「ポート」 : 9229 、
 「リクエスト」 ： 「添付」 、
 "skipFiles" : [ "<node_internals>/**" ],
 「タイプ」 : 「pwa-node」 、
 "localRoot" : "${workspaceFolder}" 、
 「リモートルート」 : 「/myapp」 、
 "ソースマップ" : true
 }
 ]
 }

ここで localRoot パラメータを正しく設定する必要があることに注意してください。そうしないと、ブレークポイント設定が有効になりません。 ${workspaceFolder} は、D:\\nodejs など、vs code によって現在開かれているプロジェクト ディレクトリを表します。その下に、2 つのマイクロサービスのサブプロジェクトである sub-A と sub-B という 2 つのディレクトリを追加します。 sub-A によって生成されたコンテナーをデバッグする場合は、localRoot を ${workspaceFolder}/sub-A に設定する必要があります。

remoteRoot パラメータは、Dockerfile の WORKDIR 設定に関連しています。 17 行目にブレークポイントを設定し、F5 キーを押してデバッグを開始します。

図5: ローカルデバッガー

先ほど開いた SSH トンネル インターフェースを覚えていますか?このとき、「接続 127.0.0.1:9229 -> 127.0.0.1:9229 が正常に確立されました」などの情報が出力されます。もちろん、具体的な情報の内容は使用するツールによって異なります。

図6: SSHトンネルが動作しています

問題がなければ、ネットワークパケットは図3の③の位置に到着するはずです。この時点でK8s port-forwardが何を出力するか見てみましょう。

図7: K8sポート転送が機能している

とてもよかったです。リクエストを受け止めて一生懸命頑張っているようです。最後に、図3の④に印刷されている「デバッガが接続されています」という興味深い情報を見てみましょう。

図8: デバッグ対象はデバッガが接続されていることを示している

最後のステップを除いて、すべて準備が整いました。ブレークポイントにヒットできるかどうかを確認するためのリクエストを送信します。

図9: リクエストを送信してブレークポイントに到達する

図 5 をもう一度見てみましょう。変数を表示したり、トレースバックをスタックしたり、その他多くの便利な操作を実行できる、魅力的なインターフェイスです。はい、今こそ想像力を働かせる時です。

VI.結論

記事の最後に、まとめをしておきましょう。

• まず、コンテナ内のアプリケーションをデバッグ モードに切り替える必要があります。これをどのように行うかは、使用する言語によって大きく異なります。
• K8s ポート転送を使用すると、デバッガーによって発行されたデバッグ コマンドをデバッグ対象のアプリケーション (デバッグ対象) に転送できます。
• ローカル マシンで実行されているデバッガーが K8s ポート転送を実行しているマシンと直接通信できない場合は、デバッガーのデバッグ コマンドを SSH トンネルに投入し、もう一方の端に送信する必要があります。
• すべての準備が整ったら、ローカル デバッガーをデバッグ対象に接続できます。

上記がこの記事の全内容です。