メッシュを観測する:Prometheus、Grafana、トレーシング、Kiali
すべてのサイドカーはすでにメトリクスとトレースを出力しています。それを実際に見られるものに変えるアドオンをインストールします。
メッシュ内のすべての Envoy サイドカーは、トラフィックを処理する副産物として、すでに詳細なメトリクスとトレースデータを生成しています。そのデータが存在するために、アプリケーションに何かを追加する必要はありません。追加のコンポーネントがなければ欠けているのは、それを送り、保存し、見るための場所です。このガイドでは、それを行い、メッシュのトラフィックを実際に見えるようにする部品をインストールします。
各アドオンの役割
- Prometheus は、すべてのサイドカーが公開するメトリクス(サービスごと、ルートごとのリクエスト率、エラー率、レイテンシー)を収集して保存します。このライブラリの専用 Prometheus ガイドが、ツール自体を詳しく説明しています。ここでは、Istio 自身のダッシュボードがクエリするバックエンドとしての役割に特化しています。
- Grafana は、事前構築された Istio ダッシュボードを通じて、その Prometheus のデータを可視化します。メッシュ全体のトラフィック概要、サービスごとの詳細、コントロールプレーンの健全性などです。
- 分散トレーシングのバックエンド(Jaeger は Istio のサンプルアドオンで最も長く使われている選択肢で、環境によっては Zipkin や OpenTelemetry ベースのバックエンドを使います)は、1 つのリクエストが触れたすべてのサービスにわたる完全な経路を示すトレースを収集します。これにより、複数のホップを持つリクエストの中で、どこで実際に遅延が発生したかを、どこかで発生したことを知るだけでなく、確認できます。
- Kiali は、Istio 専用に作られたサービスメッシュコンソールです。サービス同士が実際にどう通信しているかを示すライブのトポロジーグラフで、同じメトリクスとトレースデータに支えられています。さらに、その UI から、メッシュの設定を直接検査し、場合によっては編集することもできます。
サンプルアドオンをインストールする
Istio のリリースバンドルには、そのすべてについて、samples/addons の下にすぐに適用できるマニフェストが含まれています。
cd istio-* # istioctl のインストールで使ったディレクトリ
kubectl apply -f samples/addons
kubectl get pods -n istio-system
istio-system ですでに動作している istiod やゲートウェイと並んで、prometheus、grafana、kiali、トレーシングバックエンドの Pod が起動するのが見えるはずです。これらのサンプルマニフェストは評価と学習のためのもので、各ツールの本番対応のデプロイとして意図されたものではありません。デフォルトのリソース制限、ストレージ、保持期間はどれも控えめで、実際のデプロイでは通常、同梱のサンプルではなく、独自に専用で適切なサイズに構成した Prometheus と Grafana を実行します。
Kiali にアクセスする
これらのアドオンはいずれも、デフォルトではクラスターの外に公開されていません。Kiali の UI に到達するには port-forward を使います。
kubectl port-forward svc/kiali -n istio-system 20001:20001
http://localhost:20001 を開きます。メッシュ化されたサービスにトラフィックが流れていれば、Kiali のグラフビューがライブでレンダリングされます。どのサービスがどれと通信しているか、健全性で色分けされ、接続ごとのリクエスト量とエラー率が表示されます。
グラフがおかしく見える、または空に見える理由
Kiali のトポロジービューが空、まばら、または明らかに通信しているはずなのに切断されたノードが表示される場合、最も一般的な原因は、前のガイドで説明したものと同じです。下にある Deployment と Service に app ラベルがないことです。Kiali はそのラベルからグラフを構築します。ラベルのないワークロードはメッシュに存在し、問題なくトラフィックを運びますが、Kiali にはそれらを可視化で確実に識別して結びつける方法がありません。メッシュ自体が誤って構成されていると決めつける前に、ラベルを確認してください。
2 番目に一般的な原因は、単にまだトラフィックがないことです。Kiali のグラフは、選択された時間枠で観測されたトラフィックを反映するため、まだリクエストが送られていない新しくメッシュ化されたサービスは、表示するものがありません。いくつかのリクエストを流して、更新してください。
Grafana の事前構築ダッシュボード
同じ方法で Grafana に port-forward します。
kubectl port-forward svc/grafana -n istio-system 3000:3000
サンプルのインストールには、Istio 専用のダッシュボード(メッシュのトラフィック、サービスごとの詳細、コントロールプレーンのパフォーマンス)がすでにプロビジョニングされており、ゼロから構築する必要がありません。Istio がどのようなメトリクスを公開し、それがどのように構造化されているかを理解するための、本当に良い出発点です。このライブラリの他の場所にある Grafana のガイドが、デフォルトを探索した後で、このようなダッシュボードをカスタマイズして拡張する方法を説明しています。
サンプルのインストールは、目的地ではなく出発点として扱う
メッシュが観測可能であることを確認し、各ツールが何を表示するかを理解したら、ローカルでの評価を超えるものにとっての自然な次のステップは、同梱のサンプルを、適切に構成され、独立して管理されるインストールに置き換えることです。おそらく、samples/addons に無期限に頼るのではなく、このライブラリの Prometheus と Grafana の専用ガイドを使うことになるでしょう。サンプルのマニフェストは、「メッシュが見える」状態に素早く到達するためのもので、本番クラスターの長期的な可観測性スタックになるためのものではありません。
人気のガイド
-
Istio のアーキテクチャ:サイドカー、データプレーン、コントロールプレーン istiod が実際に何をするのか、Envoy サイドカーがどう組み込まれるのか、そしてアプリもそのマニフェストも Istio の存在を知る必要がない理由。 -
istioctl で Istio をインストールし、サイドカー注入を有効にする ローカルクラスターでメッシュを動かし、正常であることを確認し、最初のワークロードにサイドカーを注入します。 -
Helm で Istio をインストールしてカスタマイズする 本番環境で Istio を動かすために公式に推奨される方法と、削除された Istio Operator に代わるもの。 -
istioctl で Istio のインストールを検証してデバッグする 設定ミスを事前に見つけます。analyze、validate、proxy-status、そしてメッシュが黙って依存している 1 つのラベル。