EnvoyとIstiodのデバッグ
Istioは、トラフィック管理の設定問題を診断するのに非常に役立つ2つのコマンド、proxy-status
と proxy-config
コマンドを提供します。proxy-status
コマンドを使用すると、メッシュの概要を把握し、問題の原因となっているプロキシを特定できます。次に、proxy-config
を使用してEnvoyの設定を調べ、問題を診断できます。
以下で説明するコマンドを試したい場合は、次のいずれかを選択できます。
- インストール手順5とBookinfoのインストール手順に記載されているように、IstioとBookinfoがインストールされたKubernetesクラスタを用意する。
または
- Kubernetesクラスタで実行されている独自のアプリケーションに対して同様のコマンドを使用する。
メッシュの概要を把握する
proxy-status
コマンドを使用すると、メッシュの概要を把握できます。サイドカーのいずれかが設定を受信していない、または同期していない疑いがある場合は、proxy-status
でそれを知ることができます。
このリストにプロキシがない場合は、現在 Istiod インスタンスに接続されていないため、設定を受信していないことを意味します。
SYNCED
は、Envoyが最後に Istiod が送信した構成を認識したことを意味します。NOT SENT
は、Istiod が Envoy に何も送信していないことを意味します。これは通常、Istiod に送信するものがないためです。STALE
は、Istiod が Envoy に更新を送信したが、確認応答を受信していないことを意味します。これは通常、Envoy と Istiod 間のネットワークの問題、または Istio 自体のバグを示します。
EnvoyとIstiodの差分を取得する
proxy-status
コマンドは、プロキシ ID を指定することで、Envoy がロードした構成と Istiod が送信する構成の差分を取得するためにも使用できます。これにより、同期していないものが正確にどこにあるか、問題がどこにあるかを特定するのに役立ちます。
ここでは、リスナーとルートは一致していますが、クラスターは同期していないことがわかります。
Envoy構成の詳細な調査
proxy-config
コマンドは、特定の Envoy インスタンスがどのように構成されているかを確認するために使用できます。これは、Istio の構成とカスタムリソースだけでは検出できない問題を特定するために使用できます。特定の Pod のクラスター、リスナー、またはルートの基本的な概要を取得するには、次のコマンドを使用します(必要に応じて、リスナーまたはルートをクラスターに変更します)。
Envoy をデバッグするには、Envoy のクラスター/リスナー/ルート/エンドポイントと、それらがどのように相互作用するかを理解する必要があります。proxy-config
コマンドを -o json
およびフィルタリングフラグと一緒に使用して、productpage
Pod から reviews
Pod の reviews:9080
にリクエストを送信する際の Envoy の動きを追跡します。
Pod のリスナーの概要を照会すると、Istio が次のリスナーを生成していることがわかります。
- Pod へのすべてのインバウンドトラフィックを受信する
0.0.0.0:15006
のリスナーと、Pod へのすべてのアウトバウンドトラフィックを受信し、リクエストを仮想リスナーに引き渡す0.0.0.0:15001
のリスナーです。 - アウトバウンド TCP/HTTPS トラフィック用の、サービスIPごと、およびHTTP以外ごとの仮想リスナー。
- インバウンドトラフィック用に公開されたポートごとに、Pod IP上の仮想リスナー。
- アウトバウンドHTTPトラフィック用に、HTTPポートごとに
0.0.0.0
の仮想リスナー。
- Pod へのすべてのインバウンドトラフィックを受信する
上記の概要から、すべてのサイドカーが
0.0.0.0:15006
にバインドされたリスナー(IPテーブルがすべてのインバウンドPodトラフィックをルーティングする場所)と、0.0.0.0:15001
にバインドされたリスナー(IPテーブルがすべてのアウトバウンドPodトラフィックをルーティングする場所)を持っていることがわかります。0.0.0.0:15001
リスナーは、リクエストの元の宛先に最も一致する仮想リスナーにリクエストを引き渡します(一致するものが見つかった場合)。そうでない場合は、宛先に直接接続するPassthroughCluster
にリクエストを送信します。リクエストはポート
9080
へのアウトバウンドHTTPリクエストであるため、0.0.0.0:9080
仮想リスナーに引き渡されます。このリスナーは、構成されたRDSでルート構成を検索します。この場合、Istiod (ADS経由) によって構成されたRDSでルート9080
を検索します。9080
ルート構成には、各サービスの仮想ホストのみがあります。リクエストは reviews サービスに向かっているため、Envoyはリクエストがドメインに一致する仮想ホストを選択します。ドメインで一致すると、Envoyはリクエストに一致する最初のルートを探します。この場合、高度なルーティングはないため、すべてに一致するルートが1つだけです。このルートは、Envoyにoutbound|9080||reviews.default.svc.cluster.local
クラスタにリクエストを送信するように指示します。このクラスタは、Istiod (ADS経由) から関連するエンドポイントを取得するように構成されています。したがって、Envoyは
serviceName
フィールドをキーとして使用してエンドポイントのリストを検索し、それらのいずれかにリクエストをプロキシします。このクラスタで現在利用可能なエンドポイントを確認するには、
proxy-config
エンドポイントコマンドを使用します。
ブートストラップ構成の検査
これまで、主にIstiodから取得した構成を見てきましたが、Envoyには、Istiodの場所などの情報を含むいくつかのブートストラップ構成が必要です。これを確認するには、次のコマンドを使用します。
Istiodへの接続の検証
Istiodへの接続を確認することは、トラブルシューティングに役立つステップです。サービスメッシュ内のすべてのプロキシコンテナは、Istiodと通信できる必要があります。これは、いくつかの簡単なステップで実現できます。
curl
Podを作成します。curl
を使用して Istiod への接続をテストします。次の例では、デフォルトの Istiod 構成パラメーターと相互 TLS が有効になっている状態で、v1 登録 API を呼び出します。
Istiodのバージョンを一覧表示するレスポンスを受け取るはずです。
Istioが使用しているEnvoyのバージョンは?
デプロイメントで使用されているEnvoyのバージョンを確認するには、コンテナに exec
し、server_info
エンドポイントをクエリします。