サードパーティロードバランサー

 3分の読み物  

Istioは、イングレスとサービスメッシュの両方の実装を提供しており、これらを一緒に使用することも、別々に使用することもできます。これらはシームレスに連携するように設計されていますが、サードパーティのイングレスとの統合が必要な場合もあります。これは、移行目的、機能要件、または個人的な好みの可能性があります。

統合モード

「スタンドアロン」モードでは、サードパーティのイングレスがバックエンドに直接送信します。この場合、バックエンドにはIstioサイドカーが注入されていると想定されます。

graph LR cc((クライアント)) tpi(サードパーティイングレス) a(バックエンド) cc-->tpi-->a

このモードでは、ほとんどの場合、問題なく動作します。サービスメッシュ内のクライアントは、接続先のバックエンドにサイドカーがあることを意識する必要はありません。ただし、イングレスはmTLSを使用しないため、望ましくない動作につながる可能性があります。結果として、この設定の構成のほとんどはmTLSの有効化に関するものです。

「チェーン」モードでは、サードパーティのイングレスとIstio独自のゲートウェイを順番に使用します。これは、両方のレイヤーの機能が必要な場合に役立ちます。特に、グローバルアドレスやマネージド証明書などの機能を持つマネージドクラウドロードバランサーで役立ちます。

graph LR cc((クライアント)) tpi(サードパーティイングレス) ii(Istioゲートウェイ) a(バックエンド) cc-->tpi tpi-->ii ii-->a

クラウドロードバランサー

一般的に、クラウドロードバランサーは、mTLSなしのスタンドアロンモードでは追加設定なしで動作します。チェーンモードまたはmTLS付きスタンドアロンモードをサポートするには、ベンダー固有の構成が必要です。

Google HTTP(S)ロードバランサー

Google HTTP(S)ロードバランサーとの統合は、mTLSがサポートされていないため、mTLSが不要な場合にのみスタンドアロンモードで追加設定なしで動作します。

チェーンモードも可能です。設定手順については、Googleドキュメントを参照してください。

クラスター内ロードバランサー

一般的に、クラスタ内ロードバランサーは、mTLSなしのスタンドアロンモードでは追加設定なしで動作します。

mTLSを使用したスタンドアロンモードは、クラスタ内ロードバランサーのPodにサイドカーを挿入することで実現できます。これには、標準的なサイドカーの注入に加えて、通常2つのステップが必要です。

  1. インバウンドトラフィックのリダイレクトを無効化します。必須ではありませんが、通常、サイドカーはアウトバウンドトラフィックのみに使用します。クライアントからのインバウンド接続は、すでにロードバランサー自体によって処理されているためです。これにより、サイドカーによって失われる元のクライアントIPアドレスを保持することもできます。このモードは、ロードバランサーのPodにtraffic.sidecar.istio.io/includeInboundPorts: ""アノテーションを挿入することで有効にできます。

  2. サービスルーティングを有効化します。Istioサイドカーは、リクエストが特定のPod IPではなくサービスに送信された場合にのみ適切に機能します。ほとんどのロードバランサーはデフォルトで特定のPod IPに送信するため、mTLSが機能しなくなります。これを行うための手順はベンダー固有です。いくつかの例を以下に示しますが、特定のベンダーのドキュメントを参照することを推奨します。

    あるいは、Hostヘッダーをサービス名に設定することでも機能する場合があります。ただし、これにより予期しない動作が発生する可能性があります。ロードバランサーは特定のPodを選択しますが、Istioはそれを無視します。これが機能する理由の詳細については、こちらを参照してください。

ingress-nginx

ingress-nginxは、Ingressリソースにアノテーションを挿入することでサービスルーティングを行うように構成できます。

nginx.ingress.kubernetes.io/service-upstream: "true"

Emissary-Ingress

Emissary-ingressはデフォルトでサービスルーティングを使用するため、追加の手順は必要ありません。

この情報は役に立ちましたか？
改善のための提案はありますか？

フィードバックありがとうございます！