サービスエントリ

ServiceEntry は、Istio の内部サービスレジストリに追加のエントリを追加して、メッシュ内の自動検出されたサービスがこれらの手動で指定されたサービスにアクセス/ルーティングできるようにするものです。サービスエントリは、サービスのプロパティ（DNS 名、VIP、ポート、プロトコル、エンドポイント）を記述します。これらのサービスは、メッシュの外部にある可能性があります（例：Web API）。または、プラットフォームのサービスレジストリに含まれていないメッシュ内部サービスである可能性があります（例：Kubernetes のサービスと通信する VM のセット）。さらに、サービスエントリのエンドポイントは、workloadSelector フィールドを使用して動的に選択することもできます。これらのエンドポイントは、WorkloadEntry オブジェクトまたは Kubernetes ポッドを使用して宣言された VM ワークロードになります。単一のサービスでポッドと VM の両方を選択できるため、サービスの既存の DNS 名を変更することなく、VM から Kubernetes へのサービスの移行が可能です。

次の例では、内部アプリケーションが HTTPS 経由でアクセスするいくつかの外部 API を宣言しています。サイドカーは ClientHello メッセージの SNI 値を検査して、適切な外部サービスにルーティングします。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-https
spec:
  hosts:
  - api.dropboxapi.com
  - www.googleapis.com
  - api.facebook.com
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: DNS

以下の設定は、Unmanaged VM上で動作するMongoDBインスタンスのセットをIstioのレジストリに追加し、これらのサービスをメッシュ内の他のサービスと同様に扱うことを可能にします。関連付けられたDestinationRuleは、データベースインスタンスへのmTLS接続を開始するために使用されます。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-mongocluster
spec:
  hosts:
  - mymongodb.somedomain # not used
  addresses:
  - 192.192.192.192/24 # VIPs
  ports:
  - number: 27018
    name: mongodb
    protocol: MONGO
  location: MESH_INTERNAL
  resolution: STATIC
  endpoints:
  - address: 2.2.2.2
  - address: 3.3.3.3

および関連付けられたDestinationRule

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: mtls-mongocluster
spec:
  host: mymongodb.somedomain
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

次の例では、サービスエントリと仮想サービス内のTLSルーティングを組み合わせて、SNI値に基づいてトラフィックを内部のEgressファイアウォールに誘導します。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-redirect
spec:
  hosts:
  - wikipedia.org
  - "*.wikipedia.org"
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: NONE

そして、SNI値に基づいてルーティングする関連付けられたVirtualService。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: tls-routing
spec:
  hosts:
  - wikipedia.org
  - "*.wikipedia.org"
  tls:
  - match:
    - sniHosts:
      - wikipedia.org
      - "*.wikipedia.org"
    route:
    - destination:
        host: internal-egress-firewall.ns1.svc.cluster.local

TLSマッチングを含む仮想サービスは、デフォルトのSNIマッチングを上書きします。仮想サービスがない場合、トラフィックはWikipediaドメインに転送されます。

次の例は、すべての外部サービストラフィックが転送される専用のEgressゲートウェイの使用を示しています。'exportTo'フィールドを使用すると、メッシュ内の他のネームスペースに対するサービス宣言の可視性を制御できます。デフォルトでは、サービスはすべてのネームスペースにエクスポートされます。次の例では、可視性を現在のネームスペース（「.」で表される）に制限するため、他のネームスペースで使用することはできません。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-httpbin
  namespace : egress
spec:
  hosts:
  - example.com
  exportTo:
  - "."
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS

すべてのEgressトラフィックを処理するゲートウェイを定義します。

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
 name: istio-egressgateway
 namespace: istio-system
spec:
 selector:
   istio: egressgateway
 servers:
 - port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   - "*"

そして、サイドカーからゲートウェイサービス（`istio-egressgateway.istio-system.svc.cluster.local`）へのルーティング、およびゲートウェイから外部サービスへのルーティングを行う関連付けられた`VirtualService`。仮想サービスはすべてのネームスペースにエクスポートされるため、それらのネームスペースはゲートウェイを介して外部サービスにトラフィックをルーティングできます。このように管理されたミドルプロキシを通過させることは一般的な方法です。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: gateway-routing
  namespace: egress
spec:
  hosts:
  - example.com
  exportTo:
  - "*"
  gateways:
  - mesh
  - istio-egressgateway
  http:
  - match:
    - port: 80
      gateways:
      - mesh
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
  - match:
    - port: 80
      gateways:
      - istio-egressgateway
    route:
    - destination:
        host: example.com

次の例は、外部サービスのホストでワイルドカードを使用する方法を示しています。接続をアプリケーションによって要求されたIPアドレスにルーティングする必要がある場合（つまり、アプリケーションがDNSを解決して特定のIPに接続しようとする場合）、解決モードを`NONE`に設定する必要があります。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-wildcard-example
spec:
  hosts:
  - "*.bar.com"
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: NONE

次の例は、クライアントのホスト上のUnixドメインソケットを介して利用可能なサービスを示しています。Unixアドレスエンドポイントを使用するには、解決をSTATICに設定する必要があります。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: unix-domain-socket-example
spec:
  hosts:
  - "example.unix.local"
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  endpoints:
  - address: unix:///var/run/example/socket

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を作成します。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc-dns
spec:
  hosts:
  - foo.bar.com
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  endpoints:
  - address: us.foo.bar.com
    ports:
      http: 8080
  - address: uk.foo.bar.com
    ports:
      http: 9080
  - address: in.foo.bar.com
    ports:
      http: 7080

`HTTP_PROXY=https://#/`を使用すると、アプリケーションから`http://foo.bar.com`への呼び出しは、上記で指定された3つのドメインにロードバランシングされます。言い換えれば、`http://foo.bar.com/baz`への呼び出しは`http://uk.foo.bar.com/baz`に変換されます。

次の例は、SPIFFE標準に準拠した形式のサブジェクト代替名を含む`ServiceEntry`の使用を示しています。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: httpbin
  namespace : httpbin-ns
spec:
  hosts:
  - example.com
  location: MESH_INTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  endpoints:
  - address: 2.2.2.2
  - address: 3.3.3.3
  subjectAltNames:
  - "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"

次の例は、`workloadSelector`を使用した`ServiceEntry`の使用を示し、サービス`details.bookinfo.com`のVMからKubernetesへの移行を処理します。このサービスには、サイドカー付きのVMベースのインスタンス2つと、標準的なデプロイメントオブジェクトによって管理されるKubernetesポッドのセットがあります。メッシュ内のこのサービスのコンシューマーは、VMとKubernetes間で自動的にロードバランシングされます。

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: details-vm-1
spec:
  serviceAccount: details
  address: 2.2.2.2
  labels:
    app: details
    instance-id: vm1
---
apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: details-vm-2
spec:
  serviceAccount: details
  address: 3.3.3.3
  labels:
    app: details
    instance-id: vm2

同じサービスアカウント`details`を使用するポッドラベル`app: details`を持つKubernetesデプロイメントがあると仮定すると、次のサービスエントリはVMとKubernetesの両方にまたがるサービスを宣言します。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: details-svc
spec:
  hosts:
  - details.bookinfo.com
  location: MESH_INTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  workloadSelector:
    labels:
      app: details

ServiceEntry

ServicePort

ServiceEntryStatus

ServiceEntryAddress

ServiceEntry.Location

ServiceEntry.Resolution