Kubernetesのサービスメッシュ ” Istio ” を監視する方法

By 清水 孝郎 - OCTOBER 13, 2022
Topics: モニタリング

SHARE:

本文の内容は、2022年10月13日にVictor Hernandoが投稿したブログ(https://sysdig.com/blog/monitor-istio/)を元に日本語に翻訳・再構成した内容となっております。

Istioサービスメッシュは、コードや設定を変更することなく、可観測性、セキュリティ、トラフィック管理などの重要な機能をアプリケーションに追加することができます。Istio監視がどのようにあなたのIstioサービスが良い状態であることを保証するのに役立つかを発見してください。

How to monitor Istio featured image
この記事では、Istioの基本的な概念について説明します。あなたは、Istioの監視のための最も興味深いメトリクスがどれであるかを知ることができます。さらに、Istioを管理し、フードの下にあるものを検査するために必要なツールのセットを通して説明します。

これらは、この記事でカバーされているトピックです：

  • Istioとは何ですか？
  • Istioの概要
  • Prometheus を使用して Istio を監視する方法
  • IstioのためのGrafanaダッシュボード
  • Kialiとは？
  • Jaegerとは？

Istioとは？

Istioサービスメッシュは、アプリケーションに透過的に追加できる専用のインフラストラクチャーレイヤーです。この新しいレイヤーはインフラストラクチャーに追加の機能を追加し、マイクロサービス間のトラフィックを管理することを可能にします。好みに応じてトラフィックのバランスをとるための独自のルールを作成したり、コードにカオスエンジニアリングを適用するためのフォールトインジェクションルールを実装したり、その他にもさまざまなことが可能です。

Istioサービスメッシュは多くの異なるコンポーネントで構成されており、2つのレイヤーに分かれています。

  • コントロールプレーン
  • データプレーン

Istioとそのエコシステム全体が複雑であるため、Istioの監視は困難な作業になる可能性があります。Istioサービスメッシュのユーザーは、自分のサービスで何が起こっているかを見失うことはできません。そうでなければ、アプリケーションのパフォーマンスや可用性に問題が発生することになりかねません。

Istioサービスメッシュのコントロールプレーンコンポーネントのいくつかが故障し始めたらどうでしょうか？

Envoyのサイドカーの1つがうまく機能しないとしたらどうでしょう？

KubernetesでIstioサービスメッシュを使用して、これらの問題や他の種類の問題を時間内に検出することがどれほど重要なのでしょうか？

Istioの監視が、Istioのコントロールプレーン、サービス、およびワークロードの問題をどのように防げるかについて、説明していきます。

Istioの概要

Istioのコントロールプレーンが提供する機能の一部です。

  • HTTP、gRPC、WebSocket、およびTCPトラフィックのロードバランシング。
  • 豊富なルーティングルール、フォールトインジェクション、フェイルオーバーなどの実装による、トラフィック動作のコントロールフローメカニズム。独自のサーキットブレーカールールを設定し、耐障害性の高いアプリケーションを構築。
  • Istioサービスメッシュのログ、トレース、メトリクス。
  • TLS暗号化、認証、認可によるサービス間の安全な通信。

このセクションでは、Istioのコントロールプレーンとデータプレーン、Istioに含まれるサービスとコンポーネント、およびその責任について詳しく学びます。

Istio architecture

Istioのコントロールプレーン

Istiodは、Istioのサービスメッシュのコントロールプレーンの名称です。以下のコンポーネントで構成されています。

  • Pilot: ランタイムでプロキシを設定するコンポーネント。Envoyプロキシーを通じて、Istioオブジェクトに新しい設定を伝搬します。
  • Citadel: 証明書を発行し、そのローテーションを保証します。内部CA（認証局）として動作し、証明書署名要求（CSR）に署名し、サービス間のトラフィックが安全になるようにTLS証明書を発行します。
  • Galley: Istioサービスメッシュの構成を検証し、配布する。検証後、構成は配布のためにPilotに送信されます。


Istioデータプレーン

Envoyは、Istioサービスメッシュアーキテクチャーのデータプレーンコンポーネントです。コントロールプレーンの一部ではありませんが、その役割はIstioサービスメッシュを機能させる上で重要です。Envoyは、Podに（サイドカーコンテナとして）オリジナルコンテナと一緒にコロケーションされるプロキシとなっています。このサイドカープロキシーは、クラスタ内のサービス間や、内部から外部へのサービス間のトラフィックを処理する役割を担っています。

Envoyがなければ、変更を伝搬させたり、サービスメッシュ内のあるサービスから他のサービスへの通信を確立したりすることはできません。要するに、何も機能しないのです。

Istioの可観測性

Istioのコントロールプレーンとデータプレーンについて話してきましたが、ここまではよかったです。しかし…

このインフラストラクチャーを監視するのはどうでしょうか？

複雑な環境のようで、いろいろな可能性があり、Istioのサービス・メッシュを監視するためにどのツールを使うべきでしょうか？

これらの質問に光を当ててみましょう。

次のセクションでは、Istioのためのアウトオブボックス観測スタックについて詳しく説明します。

ペンと紙を持って、さっそく始めましょう！ 📝

Istioのサービスメッシュの観測可能スタックは、基本的に4つのコンポーネントで構成されています。

  • Prometheus：Prometheus: メトリクスを時系列データとして収集・保存するオープンソースの監視ツールで、コミュニティによって広く採用・サポートされています。
  • Grafana：Prometheusと同じく、オープンソースコミュニティで広く採用され、世界中で支持されています。Grafanaはデータソースに接続し、時系列データをグラフで表現します。コンシューム、設定が容易で、ダッシュボードのエクスポート/インポートを行うことができます。
  • Kiali：Istioのサービスメッシュコンソールです。トラフィックフローの監視と確認、リッチルール、サーキットブレーカー、ロードバランサーなどの設定を行う事ができます。
  • Jaeger：分散型トレーシングプラットフォーム。他のツールが提供するものに加えて、Jaegerはネットワークパフォーマンスの分析やレイテンシーの最適化を可能にします。

PrometheusでIstioを監視する方法

Istioはアドオンのバンドルを持ってきます。これらのコンポーネントは、Istioインフラストラクチャーを実行するために必要ではありませんが、とても推奨されています。このバンドルをデプロイすることで、observabilityモジュールを取得することができます。

observability スタックはどのようにデプロイするのでしょうか？

とても簡単で、次のステップに従うだけです。

まず、あなたが選んだIstioのリリースに付属しているobservabilityバンドルをデプロイします。数分待つと、すべてのPodが立ち上がり、実行されます。

以下の手順と構成は、Kubernetes 1.25 環境で Istio 1.15 を使用してテストされています。Istioのデプロイ方法の詳細については、Istioの公式ドキュメントページを参照してください。

$ kubectl apply -f istio-1.15.0/samples/addons
$ kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
grafana-56bdf8bf85-fsdl5               1/1     Running   0          4m
istio-egressgateway-564bdb69c7-vpxnd   1/1     Running   0          4h
istio-ingressgateway-984565b57-b5f6m   1/1     Running   0          4m
istiod-6b5cbd4c58-z79qt                1/1     Running   0          4m
jaeger-c4fdf6674-8pv8m                 1/1     Running   0          4m
kiali-5ff49b9f69-l898z                 1/1     Running   0          4m
prometheus-85949fddb-grnnp             2/2     Running   0          4m

PodがRunningの状態になったら、Prometheusのダッシュボードにアクセスします。istioctl コマンドでポートを転送し、localhostでアクセスできるようにします。

$ istioctl dashboard prometheus
http://localhost:9090

Prometheusコンソールでは、独自のクエリーを実行し、必要なIstioデータのメトリクスを取得することができます。

Prometheus Istio metric

Cool!ですねぇ。でも…

確認・監視すべき重要なメトリクスは何でしょうか？

次のセクションでメトリクスについて見てみましょう。🔍

Prometheus Istioの主要メトリクス

Istioは膨大な数のメトリクスをエクスポートします。これらすべてのメトリクスについて話すには、多くの時間と紙とインクが必要になるので、どれが最も重要で、なぜ重要なのかを強調してみましょう。

Envoyメトリクス

前のセクションで説明したように、Envoyプロキシーは、サービス間のトラフィック、内部から外部へのサービスやクライアントのトラフィックを管理するコンポーネントです。envoyメトリクスを監視することで、アプリケーションのパフォーマンスをより理解することができ、最も重要なことは、Istioサービスメッシュのどこかに潜在的な問題がある場合に気付くことです。

  • istio_requests_total: HTTP、HTTP/2、またはgRPCリクエストがIstioプロキシーによって処理されるたびに増分されるカウンターです。このメトリクスは、インフラストラクチャーが処理しているトラフィックの量を示します。カウンターが大きく減少した場合は、トラフィックの損失や回線の一部に問題があることを示す可能性があるため、このメトリクスの変化に注意してください。数値が増加した場合は、トラフィックが増加したことを示す可能性があります。クラスターに十分なキャパシティがあるかどうか注意してください。
  • istio_request_duration_miliseconds: HTTP、HTTP/2、またはgRPCリクエストがEnvoyプロキシーを通して処理される必要がある時間を測定するための3つのカウンターメトリクス（_bucket、_count、_sum）を提供します。このメトリクスは、アプリケーションのワークフローにおけるパフォーマンスの問題を示す良い指標となります。予想以上に高い値やリクエスト時間の急激な上昇は、ネットワークの遅延、新しいアプリケーションのバージョンによる一部のアプリケーションの動作の違いやパフォーマンスの低下など、多くの異なる根本的な問題を示している可能性があります。
  • istio_request_bytes: HTTP、HTTP/2、またはgRPCリクエストのボディサイズを測定する3つのカウンターメトリクス(_bucket, _count, _sum)。
  • istio_response_bytes: 3つのカウンターメトリクス (_bucket, _count, _sum) で、HTTP、HTTP/2、またはgRPCのレスポンスボディサイズを測定します。

Pilot メトリクス

Pilot メトリクスは、Istioコンポーネントへの設定変更の伝搬に必要な変更回数と時間を反映します。これらのメトリクスの値の急激な変化または上昇傾向は、新しい構成またはIstioオブジェクトへの変更の伝播中に問題があることを示す可能性があります。

  • pilot_xds: これは、xDS（Discovery Serviceを構成するAPI群）を使用してpilot に接続されたエンドポイントの数を示すゲージメトリクスです。
  • pilot_xds_pushes: Listener Discovery Service（LDS）、Route Discovery Service（RDS）、Endpoint Discovery Service（EDS）、およびCluster Discovery Service（CDS）に送信されたメッセージとエラーの数を示すカウンターメトリクスです。
  • pilot_xds_push_time: pilot がLDS、RDS、EDS、およびCDSにメッセージをプッシュするのにかかる合計時間（秒）。

Galleyメトリクス

これらのメトリクスは、Istioオブジェクトに適用されている変更の数に関する推定値を提供します。Istio オブジェクトを変更するために新しいマニフェストが適用され、Validation Webhook がそれを正しく検証した場合、それは合格としてカウントされます。Validation Webhook が何らかの理由でマニフェストを受け入れない場合、それは検証の失敗としてカウントされます。

  • galley_validation_failed: リソースバリデーションが失敗した回数を計測するカウンターです。
  • galley_validation_passed:通過したリソース検証の数を計測するカウンタです。

Citadel メトリクス

Citadelメトリクスは、Citadelに送信されたCSRが適切に受け入れられ、署名され、証明書の形で発行されているかについての概要を提供します。

  • citadel_server_csr_count: Istio Citadelコンポーネントが受信したCSRの数です。
  • citadel_server_root_cert_expiry_timestamp: Citadel ルート証明書の有効期限が切れる UNIX タイムスタンプ（秒）。
  • citadel_server_success_cert_issuance_count:  Citadel ルート証明書が発行された回数。Citadel が正常にサービスを提供した発行済み証明書の数です。

Grafana ダッシュボード

そろそろGrafanaの話をしていきましょう。

Grafanaは、Istio observability bundleに含まれるコンポーネントの1つです。observability stackに含まれる定義済みのダッシュボードのおかげで、Istioの監視データを表示するために使用することができます。

Prometheusコンソールと同じ方法でGrafana UIにアクセスすることができます。

$ istioctl dashboard grafana
http://localhost:3000

Grafana Istio control plane dashboard

Kiali

KialiはIstioのサービスメッシュのためのコンソールです。そのUIは非常に汎用的で、サービスを管理・観察するための多くの可能性を提供しています。

  • Istioサービスメッシュのアプリケーションのトポロジーを確認する。
  • サービストポロジーの下にある各サービスの健全性を観察する。
  • ネットワークの応答時間、ロードバランシングエンジンのパフォーマンス、アプリケーションの応答コードなどの詳細を得ることができます。
  • アプリケーションのバージョニングと各バージョンのパフォーマンス。
  • Gateway、Service、SidecarなどのIstioオブジェクトを作成、削除、変更することができます。

Kialiコンソールへの通信を開始しましょう：

$ istioctl dashboard kiali
http://localhost:20001/kiali

このように、Kialiはアプリケーションのトポロジーをグラフで表現しています。どのオブジェクトをクリックするかによって、異なるデータセットが表示されます。例えば、レビューアプリケーションとそのバージョンのパフォーマンスに関するデータを見たい場合、その項目をクリックすれば、関連する全てのデータが表示されます。

Kiali console
先に述べたように、Kialiは観測可能なシステムであると同時に、Istioのサービスメッシュのコンソールでもあります。そのため、Istioのオブジェクト（Gateway、Service、Sidecarなど）を修正したり、あるいは作成する必要がある場合は、コンソールの “Istio Config” セクションから行うことができます。

Kiali Istio config

Jaeger

Jaegerは、分散トレースに使われるオープンソースのソフトウェアです。分散システム間のトランザクションをトレースすることをミッションとしています。Jaegerは、あるトランザクションの経路をたどるログトレースを支援します。トランザクションがどのように進んだかを視覚的に表現するメカニズムや、エラー、応答時間、HTTP応答コードなどの貴重な情報を提供します。

Jaegerが何であるか、そしてそのコンソールをどのように操作するかを確認しましょう。

$ istioctl dashboard jaeger
http://localhost:16686

検索メニューから調べたいサービスを選択し、「Find Traces」をクリックします。調べたい時間帯をカスタマイズしたり、タグを使ってより詳細な検索をすることもできます。

Istio Jaeger dashboard
検査したいトレースを選択し、ツリーに表示されるコールをナビゲートします。データは時系列グラフで表現され、ワークフロー全体を構成するすべてのコールと、すべての操作の処理に必要な時間を簡単に特定できます。このようにして、アプリケーションやサービスにおける潜在的な問題を簡単に発見することができます。例えば、コードを変更した後、トランザクション全体を完了するのに2倍の時間がかかるのは、どのコンポーネントが原因なのかを検出することができます。

Istio Jaeger trace

まとめ

Istioは、スタック全体を監視するための優れたツールセットを提供しています。これらのツールはデフォルトではインストールされず、Istioを正しく動作させるために必須ではありませんが、強く推奨されています。

もし、Istioですべてが良い状態にあることを確認したいのであれば、observabilityスタックを使うことを検討してみてください。これは、Istioサービスメッシュ内のオブジェクトの監視や管理に役立ちます。

この記事で読んだことに加えて、Istioサービスメッシュのトラブルシューティングを支援するツールを持ちたいと思いませんか？

Sysdig Monitor は、この困難な任務を支援します。アウトオブボックスのダッシュボードと専用ツールは、Sysdigが管理するスケーラブルなプラットフォームで、単一の統合ポータルからIstioサービスメッシュの監視とトラブルシューティングを支援します。

Sysdig MonitorがIstioサービスメッシュの監視にもたらすもの、そしてSysdig Monitorでリアルタイムに問題をトラブルシュートする方法をご覧ください!

Sysdig MonitorがKubernetesクラスターの監視とトラブルシューティングにどのように役立つかについてもっと知りたい方は、Sysdig Monitorのトライアルページにアクセスして、30日間の無料アカウントをリクエストしてください。数分で使い始めることができます！