OpenTelemetry に基づく Kubernetes フルリンク監視を 1 つの記事で理解する

こんにちは、皆さん。私はルガです。本日は、クラウド ネイティブ エコシステムのコア技術である「OpenTelemetry に基づく Kubernetes のフルリンク観測」である可観測性についてお話します。

1. OpenTelemetryに基づいて観測意識を完全に変える

組織がアプリケーションの導入と管理に Kubernetes を採用するケースが増えるにつれ、Kubernetes はコンテナ オーケストレーションの事実上の標準になりました。このような動的な Kubernetes 環境では、プラットフォーム上で実行されているアプリケーションの健全性を確保するために、観測可能なリソースが重要です。

ただし、動的な Kubernetes 環境は、観測可能性に大きな複雑さをもたらします。アプリケーションは継続的に拡張、展開、更新されています。エージェントやポーリングに依存する従来の監視テクノロジーは、環境の変化のスピードや分散アーキテクチャの複雑さに対応できないため、Kubernetes 環境のニーズを満たすことができません。

リアルタイムの観測機能をタイムリーに提供できないと、平均解決時間 (MTTR) が増加します。これは、アプリケーションの全体的な可用性とパフォーマンスに大きな影響を与え、ビジネス自体に悪影響を及ぼします。

従来の監視ソリューションのこれらの欠点を克服するために、技術チームは OpenTelemetry を使用して Kubernetes 環境を監視する革新的なアプローチを採用しました。 OpenTelemetry を採用することで、標準化されたアプローチを使用してテレメトリ データを収集、処理、エクスポートできるようになります。

OpenTelemetry は、Kubernetes 環境でのテレメトリ データの収集と処理をよりシンプルかつ一貫したものにする、統合された API とツールのセットを提供します。クロス言語およびクロスプラットフォームをサポートし、さまざまなコンポーネントやツールと統合できます。これにより、管理者はアプリケーションのパフォーマンス メトリック、ログ、トレース データをリアルタイムで監視し、分析とトラブルシューティングに視覚化ツールを使用できるようになります。

OpenTelemetry を使用すると、技術チームは Kubernetes 環境におけるアプリケーションの動作とパフォーマンスをより深く理解し、潜在的な問題を迅速に特定して解決できます。これにより、MTTR が短縮され、アプリケーションの可用性が向上し、ビジネス オペレーションを通常どおり継続できるようになります。

2. Kubernetesの監視における現在の課題

Kubernetes 環境の従来の可観測性には、組織がアプリケーションとインフラストラクチャを完全に可視化し、きめ細かな制御を行うことを制限する可能性があるいくつかの課題があります。

• 複雑さ: Kubernetes は、複数のコンポーネントとサービスで構成される非常に複雑なコンテナ オーケストレーション プラットフォームです。従来の観測方法ではこの複雑さに効果的に対処できない可能性があり、関連する監視データの収集と分析が困難になります。
• 動的性: Kubernetes 環境内のアプリケーションとリソース トポロジは通常、Pod の作成、削除、スケーリングなどの操作を含めて動的に変更されます。従来の観測方法では、これらの変化をタイムリーに追跡できない可能性があり、その結果、監視データの正確性と一貫性が影響を受けることになります。
• 高度に分散: Kubernetes 環境内のアプリケーションは通常分散されており、複数のコンテナとサービスで構成されます。従来の可観測性方法では、分散システムに対する包括的な可視性が提供されない可能性があり、アプリケーションのエンドツーエンドのパフォーマンスと依存関係を追跡および分析することが困難になります。
• 多様性: Kubernetes エコシステムには、Prometheus、Grafana、ELK スタックなど、さまざまな可観測性ニーズに対応するさまざまなコンポーネントとツールがあります。組織は、包括的な可観測性機能を獲得するために、これらのさまざまなツールを統合して管理する必要がある場合があります。
• 弾力性とスケーラビリティ: Kubernetes 環境の弾力性とスケーラビリティにより、アプリケーションのスケールと負荷パターンをいつでも変更できます。従来の観測方法ではこのような変化に効果的に対応できない可能性があり、その結果、監視データの正確性と適時性に影響が及ぶ可能性があります。

これらの課題に直面している組織は、Kubernetes 環境の複雑さとダイナミクスに対処し、より包括的で正確な監視機能を提供するために、OpenTelemetry などのより高度な監視方法とツールを採用する必要があります。これにより、組織はアプリケーションとインフラストラクチャをより適切に理解して管理し、パフォーマンスと可用性を向上させ、トラブルシューティングと問題解決を迅速化できます。

OpenTelemetry は、分散トレースの簡単な実装など、アプリケーションや Kubernetes 環境からこれらの観測可能なデータを収集する方法を提供します。これにより、組織は問題を迅速に特定して診断できるようになり、トラブルシューティングがより効率的になります。

OpenTelemetry を使用すると、組織はアプリケーションのさまざまなコンポーネントの相互依存性とパフォーマンスをより包括的に把握できるようになります。監視データを収集および送信するための標準化された方法を提供し、組織がアプリケーションの健全性に関する詳細な情報を取得し、潜在的な問題に迅速に対応できるようにします。

したがって、OpenTelemetry を使用すると、組織は従来の可観測性方法の制限を克服し、より包括的できめ細かい可観測性機能を提供できるようになります。これにより、分散アプリケーションの理解とトラブルシューティング機能が向上します。

3. Kubernetesの監視におけるOpenTelemetryの重要な役割を明らかにする

Kubernetes を観察する方法は複数ありますが、OpenTelemetry を使用すると、従来の観察オプションに比べて多くの利点が得られます。ただし、ビジネス アプリケーションの監視を完全に無視すると、パフォーマンスと可用性に深刻かつ悲惨な結果をもたらす可能性があります。

可観測性を無視すると、組織はアプリケーションの健全性と状態を正確に把握できなくなります。タイムリーに観測可能なデータがなければ、組織はアプリケーションのパフォーマンスとリソースの使用率を評価するための重要なメトリックと指標を取得できません。これにより、組織は、潜在的なパフォーマンスのボトルネック、リソースの競合、またはアプリケーションのパフォーマンス低下や可用性の問題につながる可能性のあるその他の要因を特定することが困難になる可能性があります。

同時に、観察が不足すると、アプリケーションの問題の根本原因を効果的かつ効率的に特定するために必要な指標が得られないため、組織の平均解決時間 (MTTR) が長くなります。 Kubernetes クラスター内の主要コンポーネントを監視することで、MTTR を大幅に削減できます。

Kubernetes 環境の適切な可観測性がなければ、組織では Kubernetes Pod クラッシュ ループ、永続ボリュームの障害、ジョブの失敗などの問題が発生する可能性があります。これらの問題はすべて、Kubernetes 環境とそれらのリソース上で実行されているアプリケーションに重大なダウンタイムとパフォーマンスの問題を引き起こす可能性があります。

適切な可観測性を通じて改善する必要があるもう 1 つの重要な側面は、アプリケーションの分散コンポーネントとこれらのサービスを実行するインフラストラクチャ間の依存関係を識別するために必要なエンドツーエンドの可視性です。アプリケーションの全体像を把握しないと、組織は発生する可能性のある問題を分析して詳細に調べることができず、根本原因を絞り込む複雑さが増し、平均解決時間 (MTTR) が短縮されます。

可観測性は異常検出の基盤も築き、組織がアプリケーションの通常の動作と一致しない動作を識別できるようにします。これは、アプリケーションのパフォーマンスに影響を与える可能性のある異常を解決しようとするときに特に重要になります。

OpenTelemetry によって提供される追加の利点により、不適切な可観測性の実装によって生じる課題が最小限に抑えられ、チームは MTTR 時間の増加や可視性の制限などの問題に対処することでこれらの機能を最大限に活用できます。したがって、OpenTelemetry を使用して Kubernetes を監視することが重要です。

4. ベストプラクティス: 主要な観察目標を特定する

Kubernetes 環境からメトリックを収集して分析する場合、考慮すべき重要なメトリックがいくつかあります。次のコンテンツは、組織が収集する必要がある主要な指標の基礎として役立ちます。

1.ノードインジケーター

このメトリックは、CPU、メモリ、ネットワークの使用状況など、個々の Kubernetes クラスター ノードのパフォーマンスとリソースの使用状況に関する詳細情報を提供します。ノード インジケーターを監視することで、ノードの負荷状態を把握し、リソースのボトルネックを特定し、容量計画を実行できます。

2. ポッドメトリクス

このメトリックは、CPU、メモリ、ネットワークの使用状況など、ノード上で実行されているポッドのリソースの使用状況と操作に関する情報を提供します。 Pod メトリックを監視することで、各 Pod のリソース消費量を把握し、リソースを大量に消費する Pod を識別して最適化することができます。

3.コンテナメトリクス

このメトリックは、CPU、メモリ、ネットワーク使用量など、Pod で実行されている個々のコンテナのパフォーマンスとリソース使用量に関する詳細情報を提供します。コンテナ メトリックを監視することで、各コンテナのリソース消費に関する詳細な情報を取得し、リソース リークや構成が不適切なコンテナを特定して調整を行うことができます。

4. API サーバーメトリクス

このメトリックには、リクエストのレイテンシ、応答時間、エラー率が含まれ、Kubernetes API サーバーの機能と可用性に関する詳細な情報が提供されます。 API サーバーのメトリクスを監視することで、API サーバーのパフォーマンスを理解し、潜在的なパフォーマンスのボトルネックや障害を特定できます。

5. Etcdインジケーター

このメトリックには、ディスク使用量、応答時間、エラー率が含まれ、Etcd クラスターの動作とステータスに関する詳細な情報が提供されます。 Etcd インジケーターを監視することで、Etcd クラスターの健全性状態、パフォーマンスのボトルネック、障害を把握できます。

これらの主要なメトリックを収集して分析することで、組織は Kubernetes 環境内のノード、ポッド、コンテナ、API サーバー、および Etcd クラスターに関する詳細な情報を取得できます。これにより、組織はクラスターのパフォーマンスをリアルタイムで監視および最適化し、アプリケーションの信頼性とパフォーマンスを向上させることができます。

5. OpenTelemetry に基づく Kubernetes ソリューション

トレース データの受信と処理を担当する OpenTelemetry コレクターを Kubernetes にデプロイします。デプロイが完了すると、OpenTelemetry (Go で記述されたアプリケーション) が提供する OTEL インストルメンテーション ライブラリを使用して、トレース データをコレクターに送信できるようになります。

トレース データがコレクターに到達すると、Jaeger コレクターに渡され、さらに処理および保存されます。最後に、Jaeger のユーザー インターフェイス (UI) を使用してこのトレース データを視覚化し、アプリケーションのパフォーマンスと動作をより深く理解することができます。

次の図は、アプリケーション、OpenTelemetry コレクター、Jaeger 間のやり取りとトレース データのフロー パスを含むこのフローを示しています。詳細については以下を参照してください。

このシナリオでは、OTEL の設定は次のようになります。

実際のビジネス シナリオでは、OpenTelemetry を Kubernetes と組み合わせて使用​​して、Kubernetes クラスター上で実行されているコンテナー化されたアプリケーションからテレメトリ データを収集できます。 OpenTelemetry は、Kubernetes 環境でテレメトリ データを簡単に収集および処理できるようにする、Kubernetes 固有のコンポーネントと統合をいくつか提供します。

これらには以下が含まれます:

1. Kubernetes固有のツール

Kubernetes API サーバー、Etcd、Kubelet など。これらのインストルメントを使用して、Pod の作成、削除、スケーリングなどの操作のテレメトリ データを生成できます。

2. Kubernetesメタデータインジェクション

Kubernetes 固有のメタデータ (Pod 名、Pod 名前空間、コンテナ ID など) をテレメトリ データに自動的に挿入します。これにより、テレメトリ データを Kubernetes 固有のメタデータと関連付け、コンテナ化されたアプリケーションに関連する問題を診断することが容易になります。

3. Kubernetes対応のサンプリング

Pod 名、名前空間、サービス名などの Kubernetes 固有のメタデータに基づくテレメトリ データのサンプル。これにより、バックエンドに送信されるテレメトリ データの量が削減され、パフォーマンスが向上します。

4. Kubernetesのデプロイメント

OpenTelemetry は Kubernetes デプロイメントまたはデーモンセットとしてデプロイできるため、Kubernetes 環境で OpenTelemetry コンポーネントを簡単に拡張および管理できます。

OpenTelemetry ベースの Kubernetes ソリューションにより、Kubernetes クラスター内のアプリケーションのエンドツーエンドの監視と可観測性を実現できます。これにより、アプリケーションのパフォーマンスをより深く理解し、問題をトラブルシューティングし、適切な最適化対策を講じてアプリケーションの信頼性とパフォーマンスを向上させることができます。

6. OpenTelemetryを実装するためのコアステップ

OpenTelemetry を実装して Kubernetes 環境を監視することで、チームはさまざまなメトリックを収集して分析し、アプリケーションのさまざまな部分から収集された他のメトリックと相関させて、アプリケーション全体のパフォーマンスをより深く理解できるようになります。

実際のビジネス シナリオでは、Kubernetes 環境を監視するために OpenTelemetry を正しく実装するための、わかりやすい 4 つのコア ステップを以下に示します。詳細については以下を参照してください。

1. OpenTelemetry Collectorをインストールする

まず、OpenTelemetry Collector を正しくインストールする必要があります。コレクターは、テレメトリ データを受信、処理、エクスポートするコンポーネントです。公式ドキュメントで提供されているガイドラインに従って、Kubernetes クラスターに Collector をインストールして構成できます。

Kubernetes クラスターでは、OpenTelemetry エージェントを DaemonSet として構成して、エージェントがクラスター内のすべてのノードで実行されるようにすることができます。エージェントは次のコマンドでインストールできます。

 [leonli@LugaLab ~ ] % kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

もちろん、ここではインストールに Helm Charts を使用することもできます: https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-operator

2. OpenTelemetry Collectorを構成する

コレクターをインストールしたら、必要なメトリックとデータを収集するように構成する必要があります。構成ファイルでは、収集するメトリックの種類、エクスポーター (データをバックエンドに送信するために使用される)、およびその他の特定のコレクター設定を指定できます。 Collector を慎重に構成することで、組織のニーズに合わせてデータの収集とエクスポートをカスタマイズできます。

OTel は、Prometheus、Jaeger、Zipkin を含む複数のバックエンドをサポートしています。具体的な構成については、次の例を参照してください。

 receivers: otlp: protocols: grpc: exporters: prometheus: endpoint: "localhost:4444" jaeger: endpoint: "http://jaeger:14268/api/traces" service: pipelines: traces: receivers: [otlp] processors: [] exporters: [jaeger, prometheus]

3. KubernetesアプリケーションでOpenTelemetryインストルメンテーションを有効にする

Kubernetes アプリケーションで OpenTelemetry インストルメンテーションを有効にするには、通常、アプリケーション コードに OpenTelemetry SDK を追加する必要があります。 SDK には、アプリケーションにコードを挿入してメトリックを収集し、リクエストをトレースし、ログを記録するための API が用意されています。アプリケーションで OpenTelemetry SDK を使用することで、重要なパフォーマンス データとコンテキスト情報を取得できます。

4. 希望するバックエンドにデータを送信する

最後のステップとして、収集したデータを優先バックエンドに送信するように OpenTelemetry Collector を構成する必要があります。バックエンドには、Prometheus、Grafana、Jaeger などのさまざまなデータ ストレージおよび分析プラットフォームを使用できます。要件と環境に基づいて、適切なバックエンドを選択し、そのバックエンドにデータをエクスポートするようにコレクターを構成します。

ここでは、Jaeger バックエンドを例に挙げます。さまざまな可視化オプションが提供されており、Kubernetes クラスター内のリクエストフローを簡単に把握でき、OTeL などのさまざまなトレース形式をサポートしています。詳細については、以下を参照してください。

 apiVersion: jaegertracing.io/v1 kind: Jaeger metadata: name: simple-prod spec: strategy: allInOne allInOne: image: jaegertracing/all-in-one:latest options: log-level: debug

Kubernetes の可観測性は、Kubernetes ベースのアプリケーションのパフォーマンス、信頼性、可用性を確保する上で非常に重要です。 OpenTelemetry は、分散トレース、メトリック、ログなどの機能を活用して、Kubernetes 環境を監視するための強力なフレームワークを提供します。

ベスト プラクティスに従い、OpenTelemetry などの適切なツールを活用することで、Kubernetes クラスターの状態をリアルタイムで把握し、アプリケーションのパフォーマンスを向上させることができます。

Kubernetes がより広く使用されるようになるにつれて、強力な可観測性戦略がこれまで以上に重要になります。 OpenTelemetry やその他の監視ツールを実装することで、潜在的な問題を回避し、Kubernetes 環境がスムーズに実行されるようにすることができます。

これらの監視ツールは、主要なメトリックの収集と分析、リクエストのパスの追跡、主要なイベントとログの記録に役立ちます。 Kubernetes クラスターをリアルタイムで監視することで、潜在的な問題を迅速に特定し、パフォーマンスのボトルネックを追跡し、アプリケーションを最適化および調整するための適切な対策を講じることができます。

要約すると、OpenTelemetry やその他の同様の可観測性ツールを実装することで、Kubernetes ベースのアプリケーションのパフォーマンスと信頼性を確保するための強力な可観測性戦略を確立できます。これにより、問題をタイムリーに発見して解決し、アプリケーションの可用性を向上させ、ユーザーに優れたエクスペリエンスを提供できるようになります。