Kubernetes デバッグの 5 大課題への取り組み

Kubernetes などのクラウドネイティブ テクノロジーにより、企業はソフトウェアを迅速に構築し、簡単に拡張できるようになります。ただし、サービス指向アーキテクチャ (マイクロサービス) の構築と基盤となる Kubernetes インフラストラクチャの実行が複雑になるため、これらの Kubernetes ベースのアプリケーションのデバッグは非常に困難になる可能性があります。

エラーは避けられず、通常はソフトウェア開発プロセス中の間違いや見落としによって発生します。したがって、企業がアプリケーションの配信ペースに遅れずについていき、エンドユーザーの満足度を維持するために、開発者は効率的かつ効果的なデバッグ方法を必要としています。これには、これらのエラーを見つけて、分析し、修正することが含まれます。

この記事では、Kubernetes デバッグの 5 つの課題とその解決方法について説明します。

1. コンテナの構築と再デプロイによる開発サイクルの遅延

開発チームが Kubernetes などのクラウドネイティブ テクノロジーを採用すると、内部開発ループで追加の手順を実行する必要があるため、開発者エクスペリエンスは大幅に変わります。以前のモノリシック環境のようにコードを記述してコード変更の結果をすぐに確認するのではなく、外部依存関係を管理し、コンテナを構築し、オーケストレーション構成 (Kubernetes YAML など) を実装してから、影響を受けるコード変更を確認する必要があります。

この Kubernetes デバッグの課題を解決するには、いくつかの方法があります。

• 最初の方法では、サービスをローカルで開発し、エンドツーエンドのテストではなく単体テストに集中できますが、サービス/Web アプリケーションに認証要件があり、データベースに依存している場合は、これが困難になる可能性があります。
• この問題を解決するもう 1 つの方法は、DevSpace と呼ばれるツールを使用することです。このツールは、ビルドとデプロイメントの手順を自動化し、大幅に高速化します。
• 最後に、Telepresence と呼ばれる CNCF ツールを活用して、ローカル開発環境をリモート Kubernetes クラスターに接続することもできます。これにより、リモート Kubernetes クラスター内のこれらの外部依存関係にアクセスし、ローカルで開発しているサービスに対して即時のテスト フィードバック ループを実行できるようになります。

2. 分散アプリケーションのエンドツーエンドのプロセスに対する可視性の欠如

Kubernetes を使用する場合のもう 1 つのデバッグの課題は、通常はサービスが多すぎるため、アプリケーションのエンドツーエンドのフローを包括的に理解することです。完全な可視性がなければ、エラーを特定して修正することは困難です。

理想的には、サービス全体の可視性を得て、何が何を呼び出しているのか、何がタイムアウトしているのかなどを把握できる必要があります。これに対処するには、観測性とトレースをよりシームレスにするツールを活用する必要があります。たとえば、OpenTelemetry、Jaeger、Grafana Tempo などのツールを使用すると、エラーを再現するために必要な情報を取得できます。ここでの目標は、できるだけ多くの情報を取得することです。そうすることで、バグをリアルタイムで修正し、最終的にアプリケーションの全体的なパフォーマンスを向上させることができます。

3. コードにデバッガをアタッチできない

開発者にとって最も重要なことの 1 つは、コードにデバッガーをアタッチできることですが、Kubernetes を使用してもこれは容易ではありません。はい、print/log ステートメントなどは機能しますが、特にユーザーが慣れていない新しいコード ベースの場合は、デバッガーを配置してコードをステップ実行できるほど優れたものではありません。

この Kubernetes デバッグの問題を解決するには、次の 2 つの方法があります。

• ローカルで開発し、依存関係のローカルインスタンスをモックまたはスピンアップする方法を見つけます。
• コードがユニットテスト可能であることを確認し、そのコードに重点を置きます。テストの作成やデバッグが容易になります。

4. ローカル変更による統合テストを実行するための複雑なセットアップ

クラウドネイティブ アプリケーションは通常、さまざまなマイクロサービスで構成されます。通常、これらのマイクロサービスは相互に依存して動作し、相互に通信して、より大きなビジネス リクエストを処理します。

たとえば、ソーシャル メディア アプリケーションのタイムライン サービスでは、ユーザーのフォロワーを判断するためにユーザー プロファイル サービスと通信する必要がある場合があり、ユーザーの認証ステータスを判断するために認証サービスと通信する必要がある場合があります。マイクロサービス間では多方向のサービス間通信が発生するため、ユニット テストだけではターゲット環境でのアプリケーションの動作を常に保証できるとは限らないため、変更を展開する前にマイクロサービスで統合テストを実行することが重要です。

このコンテキストで統合テストを実行するには、当然、複数のサービスを実行し、(場合によってはリモートの) ミドルウェアおよびデータ ストアに接続する必要があります。これには、さまざまな課題を伴う技術とツールが必要です。これらの課題には、リソースの制限や、本番環境と非本番環境間のデータの不整合などが含まれます。さまざまな環境に合わせてさまざまな構成を管理する。サービスのバージョン管理、リリース、展開サイクルの管理に関連する困難。

5. 本番環境/ステージング環境でのみ発生する問題を再現する

場合によっては、ローカルの本番環境またはステージング環境で発生したバグを再現することが非常に複雑になることがあります。この時点では、シミュレーションまたは既存の値は不十分です。

実際にこの問題を再現するにはどうしたらよいのか、と疑問に思うかもしれません。どうすれば問題の根本に早くたどり着けるでしょうか?そうですね、K8s のデバッグの課題に関しては、Telepresence というオープンソース ツールをいつも使っています。このツールを使用すると、リモート依存関係にローカルで実行されているかのようにアクセスし、リモート サービスからローカル サービスにトラフィックを再ルーティングできます。

つまり、リアルタイムでデバッグし、問題を再現して、優先バージョン管理および CI/CD パイプラインに修正をより速くプッシュできるということです。

結論は

ほとんどの組織では、重要なソフトウェア配信は複数回の反復を通じてテストする必要があると主張していますが、エラーは避けられないことを覚えておくことが重要です。アプリケーションを効果的にデバッグできることは、バグを特定、理解、修正するための最良の手法の 1 つです。 Kubernetes などのコンテナ テクノロジーはソフトウェア開発者に多くのメリットをもたらしますが、アプリケーションのデバッグの課題ももたらします。幸いなことに、これらの課題に簡単に対処する方法があります。