ポッドコンテナをリモートでデバッグする方法

みなさんこんにちは。私は次男です。

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

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

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

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

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

ログを見ることによるデバッグの効率についてはここでは触れません。これは VM 上では実現可能ですが、アプリケーションをコンテナ化して K8s で管理する場合はどうすればよいでしょうか?

systemctl や monit などのコマンドを実行して Pod 内のアプリケーションを再起動するのは便利ではないことは誰もが知っています。ログ方式を引き続き使用する場合は、残る方法は 1 つだけです。

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

えっと、かなり疲れているように見えますね。 CI/CD と K8s も問題を抱えています。

私の次男は強迫性障害を少し患っており、このような拷問のようなデバッグ方法には耐えられません。さらに、手動でログを表示する場合と比較して、デバッガーを使用したデバッグはより洗練され、高速であり、RD の想像力を刺激することもできます。最も重要なことは、デバッガーを使用してデバッグすると、コード呼び出しロジックや OS とのやり取りなど、さまざまな角度から問題について RD が考えるようになることです。たとえば、ブレークポイントを設定することは難しくありませんが、ブレークポイントをいつ設定するか、どこに最も適切にブレークポイントを設定するかが難しい部分です。

「道・法・術・道具・力」が老子の『道経』の真髄です。この記事は実際には「スキル」と「ツール」について語っていますが、私が言いたいのは「タオ」の方がより本質的でより重要であるということです。それは中核となる考え方、概念、そして基本的な法則です。好奇心旺盛な学生は、これらの「テクニック」の背後にある実装原則についてさらに考えることを強くお勧めします。

ローカルマシンから Pod 内のアプリケーションをリモートでデバッグする方法を例を使って説明します。アプリケーション自体は非常にシンプルで、Node.js で書かれた http サーバーです。他の言語で書かれたアプリケーションの場合は、回避策が必ず見つかります。

デバッグモードに入る

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

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

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

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

K8s ポート転送

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

実際には、いくつかの方法があります。たとえば、ロードバランサタイプのサービスを通じて。ただし、この方法は比較的高価です。私の知る限り、Tencent Cloud のロードバランサーはかなり高価です。

ここでは、無料で普遍的な方法を紹介したいと思います。 K8s に付属するポート転送機能を使用します。コマンドは次のとおりです。

 $ kubectl port-forward deploy / nodejs - n lancehbzhang 9229 : 9229

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

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

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

ここまでで、次の図の ③ と ④ の準備はできているはずです。

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

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

kubectl port-forward を実行しているマシンをローカルマシンに直接接続できない場合はどうなりますか?セキュリティ上の理由から、上図の③と④はネットワークに直接接続できますが、①と③はファイアウォールで分離されており、①がssh経由で③にログインするためのポートは22のみとなっています。この場合、ローカルマシンから④のデバッガーに接続するにはどうすればよいでしょうか?

このとき、手順②に示した SSH トンネルが機能します。このように、ローカルの VS コードは 127.0.0.1:9229 に接続するだけで、ブレークポイントの設定、シングルステップ実行、変数の表示などのデバッグコマンドがカプセル化され、SSH トンネルに接続されて ③ に送信され、ポート転送によって ④ のデバッグ対象に転送されます。

注: SSH トンネルの使用はこの記事の焦点では​​ありません。使用方法はGoogleで検索できます。

デモ

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

ローカル マシンで 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
 }
 ]
 }

17 行目にブレークポイントを設定し、F5 キーを押してデバッグを開始します。

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

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

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

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

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

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

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

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

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

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

他にやるべき仕事

これまでのところ、この記事では、重要ではないがデバッグエクスペリエンスに影響を与える可能性のあるいくつかの詳細を省略しました。いくつか挙げてみます。

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

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"]}}}]}}}}'

要約する

まず、コンテナ内のアプリケーションをデバッグ モードに切り替える必要があります。これをどのように行うかは、使用する言語によって大きく異なります。

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