サービスエントリ
ServiceEntry
は、Istio の内部サービスレジストリに追加のエントリを追加して、メッシュ内の自動検出されたサービスがこれらの手動で指定されたサービスにアクセス/ルーティングできるようにするものです。サービスエントリは、サービスのプロパティ(DNS 名、VIP、ポート、プロトコル、エンドポイント)を記述します。これらのサービスは、メッシュの外部にある可能性があります(例:Web API)。または、プラットフォームのサービスレジストリに含まれていないメッシュ内部サービスである可能性があります(例:Kubernetes のサービスと通信する VM のセット)。さらに、サービスエントリのエンドポイントは、workloadSelector
フィールドを使用して動的に選択することもできます。これらのエンドポイントは、WorkloadEntry
オブジェクトまたは Kubernetes ポッドを使用して宣言された VM ワークロードになります。単一のサービスでポッドと VM の両方を選択できるため、サービスの既存の DNS 名を変更することなく、VM から Kubernetes へのサービスの移行が可能です。
次の例では、内部アプリケーションが HTTPS 経由でアクセスするいくつかの外部 API を宣言しています。サイドカーは ClientHello メッセージの SNI 値を検査して、適切な外部サービスにルーティングします。
以下の設定は、Unmanaged VM上で動作するMongoDBインスタンスのセットをIstioのレジストリに追加し、これらのサービスをメッシュ内の他のサービスと同様に扱うことを可能にします。関連付けられたDestinationRuleは、データベースインスタンスへのmTLS接続を開始するために使用されます。
および関連付けられたDestinationRule
次の例では、サービスエントリと仮想サービス内のTLSルーティングを組み合わせて、SNI値に基づいてトラフィックを内部のEgressファイアウォールに誘導します。
そして、SNI値に基づいてルーティングする関連付けられたVirtualService。
TLSマッチングを含む仮想サービスは、デフォルトのSNIマッチングを上書きします。仮想サービスがない場合、トラフィックはWikipediaドメインに転送されます。
次の例は、すべての外部サービストラフィックが転送される専用のEgressゲートウェイの使用を示しています。'exportTo'フィールドを使用すると、メッシュ内の他のネームスペースに対するサービス宣言の可視性を制御できます。デフォルトでは、サービスはすべてのネームスペースにエクスポートされます。次の例では、可視性を現在のネームスペース(「.」で表される)に制限するため、他のネームスペースで使用することはできません。
すべてのEgressトラフィックを処理するゲートウェイを定義します。
そして、サイドカーからゲートウェイサービス(`istio-egressgateway.istio-system.svc.cluster.local`)へのルーティング、およびゲートウェイから外部サービスへのルーティングを行う関連付けられた`VirtualService`。仮想サービスはすべてのネームスペースにエクスポートされるため、それらのネームスペースはゲートウェイを介して外部サービスにトラフィックをルーティングできます。このように管理されたミドルプロキシを通過させることは一般的な方法です。
次の例は、外部サービスのホストでワイルドカードを使用する方法を示しています。接続をアプリケーションによって要求されたIPアドレスにルーティングする必要がある場合(つまり、アプリケーションがDNSを解決して特定のIPに接続しようとする場合)、解決モードを`NONE`に設定する必要があります。
次の例は、クライアントのホスト上のUnixドメインソケットを介して利用可能なサービスを示しています。Unixアドレスエンドポイントを使用するには、解決をSTATICに設定する必要があります。
HTTPベースのサービスの場合、複数のDNSアドレス指定可能なエンドポイントによってバックアップされた`VirtualService`を作成できます。このようなシナリオでは、アプリケーションは`HTTP_PROXY`環境変数を使用して、`VirtualService`のAPI呼び出しを選択したバックエンドに透過的にリダイレクトできます。たとえば、次の設定は、us.foo.bar.com:8080、uk.foo.bar.com:9080、およびin.foo.bar.com:7080の3つのドメインによってバックアップされた、存在しない外部サービスfoo.bar.comを作成します。
`HTTP_PROXY=https:///`を使用すると、アプリケーションから`http://foo.bar.com`への呼び出しは、上記で指定された3つのドメインにロードバランシングされます。言い換えれば、`http://foo.bar.com/baz`への呼び出しは`http://uk.foo.bar.com/baz`に変換されます。
次の例は、SPIFFE標準5に準拠した形式のサブジェクト代替名を含む`ServiceEntry`の使用を示しています。
次の例は、`workloadSelector`を使用した`ServiceEntry`の使用を示し、サービス`details.bookinfo.com`のVMからKubernetesへの移行を処理します。このサービスには、サイドカー付きのVMベースのインスタンス2つと、標準的なデプロイメントオブジェクトによって管理されるKubernetesポッドのセットがあります。メッシュ内のこのサービスのコンシューマーは、VMとKubernetes間で自動的にロードバランシングされます。
同じサービスアカウント`details`を使用するポッドラベル`app: details`を持つKubernetesデプロイメントがあると仮定すると、次のサービスエントリはVMとKubernetesの両方にまたがるサービスを宣言します。
ServiceEntry
ServiceEntryを使用すると、Istioの内部サービスレジストリに追加のエントリを追加できます。
ServicePort
ServicePortは、サービスの特定のポートのプロパティを記述します。
ServiceEntryStatus
ServiceEntryAddress
ホスト名を追加するために必要なマイナーな抽象化
ServiceEntry.Location
Locationは、サービスがIstioメッシュの一部であるか、メッシュの外部であるかを指定します。Locationは、サービス間のmTLS認証、ポリシー適用など、いくつかの機能の動作を決定します。メッシュ外のサービスと通信する場合、IstioのmTLS認証は無効になり、ポリシー適用はサーバー側ではなくクライアント側で実行されます。
名前 | 説明 |
---|---|
MESH_EXTERNAL | サービスがメッシュの外部にあることを示します。通常、APIを介して消費される外部サービスを示すために使用されます。 |
MESH_INTERNAL | サービスがメッシュの一部であることを示します。通常、Unmanagedインフラストラクチャ(たとえば、Kubernetesベースのサービスメッシュに追加されたVM)を含めるためにサービスメッシュを拡張する一部として明示的に追加されたサービスを示すために使用されます。 |
ServiceEntry.Resolution
Resolutionは、プロキシがサービスに関連付けられたネットワークエンドポイントのIPアドレスをどのように解決するかを決定し、それらのいずれかにルーティングできるようにします。ここで指定された解決モードは、アプリケーションがサービスに関連付けられたIPアドレスを解決する方法には影響しません。アプリケーションは、アウトバウンドトラフィックをプロキシでキャプチャできるように、サービスをIPに解決するためにDNSを使用する必要がある場合があります。または、HTTPサービスの場合、アプリケーションはプロキシと直接通信して(たとえば、HTTP_PROXYを設定して)これらのサービスと通信できます。
名前 | 説明 |
---|---|
NONE | 着信接続が既に解決されている(特定の宛先IPアドレスに)と想定します。このような接続は、通常、IPテーブルREDIRECT/eBPFなどのメカニズムを使用してプロキシを介してルーティングされます。ルーティング関連の変換を実行した後、プロキシは接続がバインドされていたIPアドレスに接続を転送します。 |
STATIC | エンドポイント(下記参照)に指定された静的IPアドレスを、サービスに関連付けられたバッキングインスタンスとして使用します。 |
DNS | 周囲のDNSを非同期でクエリして、IPアドレスを解決しようとします。エンドポイントが指定されていない場合、ワイルドカードが使用されていない場合は、hostsフィールドに指定されたDNSアドレスが解決されます。エンドポイントが指定されている場合、エンドポイントに指定されたDNSアドレスが解決されて、宛先IPアドレスが決定されます。DNS解決は、Unixドメインソケットエンドポイントでは使用できません。 |
DNS_ROUND_ROBIN | 周囲のDNSを非同期でクエリして、IPアドレスを解決しようとします。`DNS`とは異なり、`DNS_ROUND_ROBIN`は、DNS解決の完全な結果に依存せずに、新しい接続を開始する必要がある場合に返された最初のIPアドレスのみを使用し、DNSレコードが頻繁に変更されても、接続プールと接続サイクルの枯渇を排除して、ホストへの接続は維持されます。これは、DNSを介してアクセスする必要がある大規模なウェブスケールサービスに最適です。プロキシは、ワイルドカードが使用されていない場合、hostsフィールドに指定されたDNSアドレスを解決します。DNS解決は、Unixドメインソケットエンドポイントでは使用できません。 |