運用中の Istio と Kubernetes。 パート 2. トレース

過去に статье Service Mesh Istio の基本コンポーネントを確認し、システムについて理解し、Istio の使用を開始するときに通常生じる主な質問に答えました。 このパートでは、ネットワーク上でトレース情報の収集を整理する方法を見ていきます。

Service Mesh という言葉を聞いて多くの開発者やシステム管理者が最初に思い浮かぶのは、トレースです。 実際、すべての TCP トラフィックが通過する各ネットワーク ノードに特別なプロキシ サーバーを追加します。 ネットワーク上のすべてのネットワークインタラクションに関する情報を簡単に送信できるようになったそうです。 残念ながら、実際には考慮する必要のある微妙な点が数多くあります。 それらを見てみましょう。

誤解その XNUMX は、オンラインのハイキング データを無料で入手できるということです。

実際、比較的無料で、矢印で接続されたシステムのノードと、サービス間を通過するデータ レート (実際には、単位時間あたりのバイト数のみ) しか取得できません。 ただし、ほとんどの場合、サービスは HTTP、gRPC、Redis などの何らかのアプリケーション層プロトコルを介して通信します。 そしてもちろん、これらのプロトコルに特化したトレース情報を確認したいのですが、データ レートではなくリクエスト レートを確認したいのです。 私たちは、プロトコルを使用したリクエストのレイテンシーを理解したいと考えています。 最後に、システムにログインしてユーザーから応答を受け取るまでのリクエストの完全なパスを確認したいと思います。 この問題はもはやそれほど簡単に解決できません。

まず、Istio のアーキテクチャの観点から送信トレース スパンがどのように見えるかを見てみましょう。 最初の部分で覚えたように、Istio にはテレメトリを収集するための Mixer と呼ばれる別のコンポーネントがあります。 ただし、現在のバージョン 1.0.* では、送信はプロキシ サーバー、つまり envoy プロキシから直接行われます。 Envoy プロキシは、すぐに使える zipkin プロトコルを使用したトレース スパンの送信をサポートします。 他のプロトコルに接続することも可能ですが、プラグインを介してのみ接続できます。 Istio を使用すると、zipkin プロトコルのみをサポートする、組み立てられ構成された envoy プロキシをすぐに取得できます。 たとえば、Jaeger プロトコルを使用し、UDP 経由でトレース スパンを送信したい場合は、独自の istio-proxy イメージを構築する必要があります。 istio-proxy のカスタム プラグインのサポートはありますが、まだアルファ版です。 したがって、多数のカスタム設定を使用せずに済みたい場合は、トレース スパンの保存と受信に使用されるテクノロジの範囲が減ります。 実際、主要なシステムでは、Zipkin 自体または Yeter を使用できるようになりましたが、zipkin と互換性のあるプロトコル (効率は大幅に低下します) を使用してすべてをそこに送信します。 zipkin プロトコル自体には、HTTP プロトコル経由ですべてのトレース情報をコレクターに送信する必要があり、これには非常にコストがかかります。

すでに述べたように、アプリケーションレベルのプロトコルをトレースしたいと考えています。 これは、各サービスの隣にあるプロキシ サーバーが、現在どのような対話が行われているかを理解する必要があることを意味します。 デフォルトでは、Istio はすべてのポートをプレーン TCP として構成します。つまり、トレースは送信されません。 トレースを送信するには、まずメイン メッシュ構成でこのオプションを有効にし、非常に重要なこととして、サービスで使用されるプロトコルに従って Kubernetes サービス エンティティのすべてのポートに名前を付ける必要があります。 それは、例えば次のようになります。

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

http-magic のような複合名を使用することもできます (Istio は http を認識し、そのポートを http エンドポイントとして認識します)。 形式はプロトエクストラです。

プロトコルを決定するために膨大な数の構成にパッチを適用しないようにするには、汚い回避策を使用できます。つまり、Pilot コンポーネントがちょうど完成した時点でパッチを適用します。 プロトコル定義ロジックを実行します。 もちろん、最終的には、このロジックを標準に変更し、すべてのポートの命名規則に切り替える必要があります。

プロトコルが本当に正しく定義されているかどうかを理解するには、envoy プロキシを備えたいずれかのサイドカー コンテナに移動し、場所 /config_dump の envoy インターフェイスの管理ポートにリクエストを行う必要があります。 結果として得られる構成では、目的のサービスの操作フィールドを確認する必要があります。 Istio では、リクエストが行われた場所の識別子として使用されます。 Istio でこのパラメーターの値をカスタマイズするには (その後、トレース システムで確認します)、サイドカー コンテナーを起動する段階で serviceCluster フラグを指定する必要があります。 たとえば、下向きの kubernetes API から取得した変数から次のように計算できます。

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

envoy でのトレースの仕組みを理解するための良い例は次のとおりです。 ここで.

トレース スパンを送信するためのエンドポイント自体も、Envoy プロキシ起動フラグで指定する必要があります。次に例を示します。 --zipkinAddress tracing-collector.tracing:9411

誤解その XNUMX: すぐに使えるシステムを通じて、リクエストの完全なトレースを安価に取得できる

残念ながらそうではありません。 実装の複雑さは、サービスの相互作用をどのように実装したかによって異なります。 何故ですか？

実際のところ、istio-proxy がサービスへの受信リクエストと同じサービスから送信されるリクエストの対応を理解できるようにするには、すべてのトラフィックを単にインターセプトするだけでは十分ではありません。 何らかの通信識別子が必要です。 HTTP エンボイ プロキシは特殊なヘッダーを使用します。これにより、エンボイは、サービスへの特定のリクエストが他のサービスへの特定のリクエストを生成することを理解します。 そのようなヘッダーのリスト:

• x-リクエストID、
• x-b3-traceid、
• x-b3-スパニッド、
• x-b3-parentspanid、
• x-b3-サンプリングされた、
• x-b3-フラグ、
• x-ot-span-context。

このようなロジックを追加できる単一ポイント (たとえば、基本クライアント) がある場合は、すべて問題なく、このライブラリがすべてのクライアントに対して更新されるまで待つ必要があります。 しかし、非常に異種混合のシステムがあり、ネットワーク上でサービス間を移動する際に統一性がない場合、これは大きな問題となる可能性が高くなります。 このようなロジックを追加しないと、すべてのトレース情報は「単一レベル」のみになります。 つまり、サービス間のやり取りはすべて受信しますが、それらはネットワークを介した単一の経路に固定されることはありません。

まとめ

Istio は、ネットワーク経由でトレース情報を収集するための便利なツールを提供しますが、実装するにはシステムを適応させ、Istio 実装の機能を考慮する必要があることを理解する必要があります。 その結果、XNUMX つの主な点を解決する必要があります。XNUMX つはアプリケーション レベルのプロトコルの定義 (Envoy プロキシによってサポートされている必要がある)、もう XNUMX つはサービスからのリクエストからサービスへのリクエストの接続に関する情報の転送の設定 (ヘッダーを使用) です。 、HTTP プロトコルの場合)。 これらの問題が解決されると、多くの異なる言語やフレームワークで書かれた非常に異質なシステムであっても、ネットワークから透過的に情報を収集できる強力なツールが手に入ります。

Service Mesh に関する次の記事では、Istio の最大の問題の XNUMX つである各サイドカー プロキシ コンテナによる RAM の大量消費を取り上げ、それに対処する方法について説明します。

出所： habr.com