クラシック・クラスターでのゲートウェイ URL の作成

1. Istio ingress ホストを設定します。

   export INGRESS_IP=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. Istio ingress ポートを設定します。

   export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
   

3. Istio ingress のホストとポートを使用する GATEWAY_URL 環境変数を作成します。

   export GATEWAY_URL=$INGRESS_IP:$INGRESS_PORT
   

4. GATEWAY_URL 変数に対して curl を実行し、BookInfo アプリが稼働中であることを確認します。 応答 200 は、Istio で BookInfo アプリが適切に稼働していることを意味します。

   curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage
   

5. ページの最新表示を複数回試行します。 さまざまなバージョンのレビュー・セクションが、赤い星形、黒い星形、星形なしの間でラウンドロビンします。

VPC クラスターでのゲートウェイ URL の作成

1. Istio Ingress のホスト名を使用する GATEWAY_URL 環境変数を作成します。

   export GATEWAY_URL=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   

2. GATEWAY_URL 変数に対して curl を実行し、BookInfo アプリが稼働中であることを確認します。 応答 200 は、Istio で BookInfo アプリが適切に稼働していることを意味します。

   curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage
   

ブラウザーでの BookInfo Web ページの表示

ブラウザーで BookInfo アプリを表示するには、オペレーティング・システムに応じて以下のコマンドを実行します。

Mac OS または Linux

open http://$GATEWAY_URL/productpage

Windows

start http://$GATEWAY_URL/productpage

ページの最新表示を複数回試行します。 さまざまなバージョンのレビュー・セクションが、赤い星形、黒い星形、星形なしの間でラウンドロビンします。

IBM 提供のサブドメインを使用した BookInfo の公開 (TLS 不使用)

クラスター内で BookInfo アドオンを有効にすると、Istio ゲートウェイ bookinfo-gateway が自動的に作成されます。 このゲートウェイは、Istio の仮想サービス・ルールと宛先ルールを使用して、BookInfoアプリをパブリックに公開するロード・バランサー istio-ingressgateway を構成します。 以下の手順では、istio-ingressgateway ロード・バランサーの IP アドレス (クラシック・クラスターの場合) またはホスト名 (VPC クラスターの場合) のサブドメインを作成します。このサブドメインを通じて BookInfo にパブリック・アクセスできます。

1. DNS サブドメインを作成して、istio-ingressgateway ロード・バランサーの IP アドレス (クラシック・クラスターの場合) またはホスト名 (VPC クラスターの場合) を登録します。
   • クラシック:

     ibmcloud ks nlb-dns create classic --ip $INGRESS_IP --cluster <cluster_name_or_id>
     

   • VPC:

     ibmcloud ks nlb-dns create vpc-gen2 --lb-host $GATEWAY_URL --cluster <cluster_name_or_id>
     

2. サブドメインが作成されたことを確認し、サブドメインをコピーします。

   ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>
   

クラシック・クラスターの出力例

Hostname                                                                                IP(s)              Health Monitor   SSL Cert Status           SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["168.1.1.1"]      None             created                   <certificate>

VPC クラスターの出力例

Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>

Web ブラウザーで、BookInfo 製品ページを開きます。 TLS は構成されていないので、HTTP を使用してください。

http://<subdomain>/productpage

ページの最新表示を複数回試行します。 http://<subdomain>/productpage に対する要求は Istio ゲートウェイ・ロード・バランサーによって受信されます。 Istio ゲートウェイはマイクロサービス用の仮想サービス・ルールと宛先ルーティング・ルールを管理するため、依然として複数の異なるバージョンの reviews マイクロサービスがランダムに返されます。

IBM 提供のサブドメインを使用した BookInfo の公開 (TLS 使用)

クラスター内で BookInfo アドオンを有効にすると、Istio ゲートウェイ bookinfo-gateway が自動的に作成されます。 このゲートウェイは、Istio の仮想サービス・ルールと宛先ルールを使用して、BookInfoアプリをパブリックに公開するロード・バランサー istio-ingressgateway を構成します。 以下の手順では、istio-ingressgateway ロード・バランサーの IP アドレス (クラシック・クラスターの場合) またはホスト名 (VPC クラスターの場合) のサブドメインを作成します。このサブドメインを通じて BookInfo にパブリック・アクセスできます。 また、SSL 証明書を使用して、BookInfo アプリへの HTTPS 接続を可能にすることもできます。

1. DNS サブドメインを作成して、istio-ingressgateway ロード・バランサーの IP アドレス (クラシック・クラスターの場合) またはホスト名 (VPC クラスターの場合) を登録します。

   • クラシック:

     ibmcloud ks nlb-dns create classic --ip $INGRESS_IP --secret-namespace istio-system --cluster <cluster_name_or_id>
     

   • VPC:

     ibmcloud ks nlb-dns create vpc-gen2 --lb-host $GATEWAY_URL --secret-namespace istio-system --cluster <cluster_name_or_id>
     

2. サブドメインが作成されていることを確認し、SSL Cert Secret Name フィールドの SSL シークレットの名前をメモします。

   ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>
   

   クラシック・クラスターの出力例。

   Hostname                                                                                IP(s)              Health Monitor   SSL Cert Status           SSL Cert Secret Name
   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["168.1.1.1"]      None             created                   <certificate>
   

   VPC クラスターの出力例

   Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
   

TLS 終端処理を使用するための bookinfo-gateway の構成

以下の手順を実行して、bookinfo-gateway の TLS 終端処理をセットアップします。

1. TLS 接続を処理するように構成されていない既存の bookinfo-gateway を削除します。

   kubectl delete gateway bookinfo-gateway
   

2. TLS 終端処理を使用する新しい bookinfo-gateway 構成ファイルを作成します。 以下の YAML ファイルを bookinfo-gateway.yaml として保存します。 <secret_name> を、事前に検出した SSL シークレットの名前で置き換えます。

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: bookinfo-gateway
   spec:
     selector:
       istio: ingressgateway
     servers:
     - port:
         number: 443
         name: https
         protocol: HTTPS
       tls:
         mode: SIMPLE
         credentialName: <secret_name>
       hosts:
       - "*"
   

3. クラスターに新しい bookinfo-gateway を作成します。

   kubectl apply -f bookinfo-gateway.yaml
   

4. Web ブラウザーで、BookInfo 製品ページを開きます。 手順 2 で確認したサブドメインに HTTPS を使用していることを確認します。

   https://<subdomain>/productpage
   

5. ページの最新表示を複数回試行します。 https://<subdomain>/productpage に対する要求は Istio ゲートウェイ・ロード・バランサーによって受信されます。 Istio ゲートウェイはマイクロサービス用の仮想サービス・ルールと宛先ルーティング・ルールを管理するため、依然として複数の異なるバージョンの reviews マイクロサービスがランダムに返されます。

何が起きたかを理解する

BookInfo サンプルは、Istio のトラフィック管理コンポーネントの 3 つがどのように連携して受信トラフィックをアプリにルーティングするかを示すデモ用サンプルです。

Gateway

bookinfo-gateway ゲートウェイは、 istio-system ネームスペース内の istio-ingressgateway サービスであるロードバランサーについて説明しています。このロードバランサーは、 BookInfo への受信 HTTP /TCP トラフィックのエントリーポイントとして機能します。 Istio は、ゲートウェイ構成ファイル内に定義されたポート上で Istio マネージド・アプリに対する着信要求を listen するようにロード・バランサーを構成します。 BookInfo ゲートウェイの構成ファイルを調べるには、次のコマンドを実行します。

kubectl get gateway bookinfo-gateway -o yaml

VirtualService

bookinfo は、 VirtualService マイクロサービスを destinations として定義することで、サービスメッシュ内でリクエストがどのようにルーティングされるかを制御するルールを定義します。 bookinfo 仮想サービスでは、要求の /productpage URI はポート productpage 上の 9080 ホストにルーティングされます。 このように、BookInfo アプリに対する要求はすべて、まず productpage マイクロサービスにルーティングされ、そこで BookInfo の他のマイクロサービスが呼び出されます。 仮想サービス・ルールを表示するには、以下のコマンドを実行します。

kubectl get virtualservice bookinfo -o yaml

DestinationRule

ゲートウェイが仮想サービスルールに従ってリクエストをルーティングした後、 details、 productpage、 ratings、 reviews は DestinationRules マイクロサービスにリクエストが到達した際に適用されるポリシーを定義します。 例えば、BookInfo 製品ページを最新表示すると表示が変わるのは、異なるバージョン (productpage、v1、v2) の v3 マイクロサービスをランダムに呼び出す reviews マイクロサービスの結果です。 これらのバージョンはランダムに選択されます。これは、reviews 宛先ルールでマイクロサービスの subsets (名前付きバージョン) に均等な重みが与えられているためです。 これらのサブセットは、特定のバージョンのサービスにトラフィックがルーティングされるときに仮想サービス・ルールによって使用されます。 BookInfo に適用される宛先ルールを調べるには、次のコマンドを実行します。

kubectl describe destinationrules

自動サイドカー注入の有効化

自動サイドカー注入を有効にすると、名前空間によって新規デプロイメントの有無が listen されて、ポッド・テンプレート仕様が自動的に変更されて、Envoy プロキシー・サイドカー・コンテナーを使用してアプリ・ポッドが作成されるようになります。 Istio と統合する複数のアプリをある名前空間にデプロイする場合は、その名前空間に対して自動サイドカー注入を有効にします。 Istio マネージド・アドオンでは、どの名前空間に対しても自動サイドカー注入はデフォルトで有効にはなりません。

kube-system、ibm-system,、または ibm-operators 名前空間のサイドカー注入を有効にしないでください。

名前空間に対して自動サイドカー注入を有効にするには、以下のようにします。

1. Istio マネージド・アプリをデプロイする名前空間の名前を取得します。

   kubectl get namespaces
   

2. 名前空間に istio-injection=enabled というラベルを設定します。

   kubectl label namespace <namespace> istio-injection=enabled
   

3. ラベル付き名前空間にアプリをデプロイするか、その名前空間に既に存在するアプリを再デプロイします。

   kubectl apply <myapp>.yaml --namespace <namespace>
   

4. オプション その名前空間にアプリを再デプロイするには、アプリ・ポッドを削除して、注入されるサイドカーとともに再デプロイされるようにします。

   kubectl delete pod -l app=<myapp>
   

5. アプリを公開するためのサービスを作成していない場合は、Kubernetes サービスを作成します。 Istio サービス・メッシュ内にマイクロサービスとして含める Kubernetes サービスによってアプリが公開されなければなりません。 ポッドとサービスの Istio 要件に従っていることを確認してください。

6. アプリ用のサービスを定義します。

   apiVersion: v1
   kind: Service
   metadata:
     name: myappservice
   spec:
     selector:
       <selector_key>: <selector_value> # Enter the label key `selector_key` and value `selector_value` pair that you want to use to target the pods where your app runs.
     ports:
     - protocol: TCP
       port: 8080 # The port that the service listens on
   

7. クラスター内にサービスを作成します。 アプリと同じ名前空間にサービスがデプロイされるようにします。

   kubectl apply -f myappservice.yaml -n <namespace>
   

これで、Istio サービス・メッシュにアプリ・ポッドが組み込まれました。アプリ・ポッドではアプリ・コンテナーとともに Istio サイドカー・コンテナーが実行されるからです。

サイドカーの手動注入

名前空間でのサイドカーの自動注入を有効にしない場合は、デプロイメント YAML にサイドカーを手動で注入できます。 サイドカーを自動的に注入させたくない他のデプロイメントとともに名前空間でアプリが実行されている場合は、サイドカーを手動で注入します。

kube-system、ibm-system,、または ibm-operators 名前空間のサイドカー注入を有効にしないでください。

1. istioctl クライアントをダウンロードします。

   curl -L https://istio.io/downloadIstio | sh -
   

2. Istio パッケージ・ディレクトリーにナビゲートします。

   cd istio-1.23.5
   

手動でデプロイメントにサイドカーを注入するには、以下のようにします。

1. アプリ・デプロイメント YAML に Envoy サイドカーを注入します。

   istioctl kube-inject -f <myapp>.yaml | kubectl apply -f -
   

2. アプリをデプロイします。

   kubectl apply <myapp>.yaml
   

3. アプリを公開するためのサービスを作成していない場合は、Kubernetes サービスを作成します。 Istio サービス・メッシュ内にマイクロサービスとして含める Kubernetes サービスによってアプリが公開されなければなりません。 ポッドとサービスの Istio 要件に従っていることを確認してください。

4. アプリ用のサービスを定義します。

   apiVersion: v1
   kind: Service
   metadata:
     name: myappservice
   spec:
     selector:
       <selector_key>: <selector_value> # Enter the label key `selector_key` and value `selector_value` pair that you want to use to target the pods where your app runs.
     ports:
     - protocol: TCP
       port: 8080 # The port that the service listens on.
   

5. クラスター内にサービスを作成します。 アプリと同じ名前空間にサービスがデプロイされるようにします。

   kubectl apply -f myappservice.yaml -n <namespace>
   

これで、Istio サービス・メッシュにアプリ・ポッドが組み込まれました。アプリ・ポッドではアプリ・コンテナーとともに Istio サイドカー・コンテナーが実行されるからです。

DNS を使用した Istio Ingress ゲートウェイの公開 (TLS 終端処理なし)

1. クラスターに istio マネージド・アドオンをインストールします。
2. istioctl CLI をインストールします。
3. アプリ・マイクロサービス用にサイドカー注入をセットアップし、そのアプリ・マイクロサービスを名前空間にデプロイし、そのアプリ・マイクロサービスに Kubernetes サービスを作成して、Istio サービス・メッシュ内に配置します。

アプリをパブリックに公開するには、以下のようにします。

1. パブリック istio-ingressgateway ロード・バランサー・サービスを使用して HTTP 用のポート 80 を公開するゲートウェイを作成します。 <namespace> を、Istio 管理対象マイクロサービスがデプロイされている名前空間で置き換えます。 ゲートウェイYAMLコンポーネントの詳細については 、Istioのリファレンスドキュメントを参照してください。

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: my-gateway
   spec:
     selector:
       app: ingressgateway
     servers:
     - port:
         number: 80
         name: http
         protocol: HTTP
       hosts:
       - "*"
   

2. Istio マネージド・マイクロサービスがデプロイされている名前空間にゲートウェイを適用します。

   kubectl apply -f my-gateway.yaml -n <namespace>
   

3. my-gateway ゲートウェイを使用するとともにアプリ・マイクロサービスのためのルーティング・ルールを定義する仮想サービスを作成します。 80 とは異なるポートでマイクロサービスが listen する場合は、そのポートを追加してください。 仮想サービスYAMLコンポーネントの詳細については 、Istioのリファレンスドキュメントを参照してください。

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: my-virtual-service
     namespace: <namespace> # The namespace where your Istio-managed microservices are deployed.
   spec:
     gateways:
     - my-gateway # `my-gateway` is specified so that the gateway can apply these virtual service routing rules to the `istio-ingressgateway` load balancer.
     hosts:
     - '*'
     http:
     - match:
       - uri:
           exact: /<service_path> # Replace `service_path` with the path that your entrypoint microservice listens on. For example, in the BookInfo app, the path is defined as `/productpage`.
       route:
       - destination:
           host: <service_name> # Replace `service_name` with the name of your entrypoint microservice. For example, in the BookInfo app, `productpage` served as the entrypoint microservice that called the other app microservices.
           port:
             number: 80 # If your microservice listens on a different port, replace `80` with the port.
   

4. Istio マネージド・マイクロサービスがデプロイされている名前空間に仮想サービス・ルールを適用します。

   kubectl apply -f my-virtual-service.yaml -n <namespace>
   

5. ** パブリック・ロード・バランサーの **EXTERNAL-IPistio-ingressgateway アドレス (クラシック・クラスター) またはホスト名 (VPC クラスター) を取得します。 クラスターの各ゾーンで Istio ロード・バランサーを有効にした場合は、各ゾーン内のロード・バランサー・サービスの IP アドレスまたはホスト名を取得します。

   kubectl get svc -n istio-system
   

   # Example output for classic clusters
   istio-ingressgateway     LoadBalancer   172.21.XXX.XXX   169.1.1.1       80:31380/TCP,443:31390/TCP,31400:31400/TCP,5011:31323/TCP,8060:32483/TCP,853:32628/TCP,15030:31601/TCP,15031:31915/TCP  22m
   

   # Example output for VPC clusters:
   istio-ingressgateway     LoadBalancer   172.21.XXX.XXX   1234abcd-us-south.lb.appdomain.cloud       80:31380/TCP,443:31390/TCP,31400:31400/TCP,5011:31323/TCP,8060:32483/TCP,853:32628/TCP,15030:31601/TCP,15031:31915/TCP  22m
   

6. DNS サブドメインを作成して、ロード・バランサー IP またはホスト名を登録します。 IBM Cloud Kubernetes Service での DNS サブドメインの登録の詳細については、Classic：NLBサブドメインの登録、または VPC ALB または VPC NLB のDNSサブドメインでVPCロードバランサーのホスト名を登録する情報を参照してください。

   ibmcloud ks nlb-dns create classic --cluster <cluster_name_or_id> --ip <LB_IP> [--ip <LB_zone2_IP> ...]
   

   VPCクラスタの例となるコマンド。

   ibmcloud ks nlb-dns create vpc-gen2 -c <cluster_name_or_ID> --lb-host <LB_hostname>
   

7. サブドメインが作成されたことを確認します。 出力で、**「SSL Cert Secret Name」**フィールドにある SSL 秘密鍵の名前をコピーします。

   ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>
   

   クラシック・クラスターの出力例。

   Hostname                                                                                IP(s)              Health Monitor   SSL Cert Status           SSL Cert Secret Name
   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["168.1.1.1"]      None             created                   <certificate>
   

   VPCクラスタの出力例。

   Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
   

8. アプリ・マイクロサービスの URL を入力して、Istio マネージド・マイクロサービスにトラフィックがルーティングされていることを確認します。

   http://<host_name>/<service_path>
   

よりきめ細かくルーティングを制御することもできます。 ロードバランサーがトラフィックを各マイクロサービスにルーティングした後に適用されるルールを作成するには、例えば、トラフィックを1つのマイクロサービスの異なるバージョンに送信するルールなどを作成し、適用することができます DestinationRules作成して適用することができます。

Ingress セットアップまたは Egress セットアップをデバッグする必要がありますか? istio-global-proxy-accessLogFile 構成マップmanaged-istio-customの オプションが "/dev/stdout" に設定されていることを確認します。 Envoy プロキシーは、アクセス情報を標準出力に出力します。これは、Envoy コンテナーに対して kubectl logs コマンドを実行することで表示できます。 ゲートウェイの ibm-cloud-provider-ip ポッドが pending のままになっている場合は、このトラブルシューティングのトピックを参照してください。

DNS を使用した Istio Ingress ゲートウェイの公開 (TLS 終端処理あり)

1. クラスターに istio マネージド・アドオンをインストールします。
2. istioctl CLI をインストールします。
3. アプリ・マイクロサービス用にサイドカー注入をセットアップし、そのアプリ・マイクロサービスを名前空間にデプロイし、そのアプリ・マイクロサービスに Kubernetes サービスを作成して、Istio サービス・メッシュ内に配置します。

アプリをパブリックに公開するには、以下のようにします。

1. DNS サブドメインを作成して、ロード・バランサー IP またはホスト名を登録します。 IBM Cloud Kubernetes Service で DNS サブドメインを登録する方法について詳しくは、クラシック: NLB サブドメインの登録または DNS サブドメインへの VPC ロード・バランサーのホスト名の登録を参照してください。

   • クラシック・クラスター:

     ibmcloud ks nlb-dns create classic --cluster <cluster_name_or_id> --ip <LB_IP> [--ip <LB_zone2_IP> ...]
     

   • VPC クラスター:

     ibmcloud ks nlb-dns create vpc-gen2 -c <cluster_name_or_ID> --lb-host <LB_hostname>
     

2. サブドメインが作成されたことを確認します。 出力で、**「SSL Cert Secret Name」**フィールドにある SSL 秘密鍵の名前をコピーします。

   ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>
   

   # Example output for classic clusters:
   Hostname                                                                                IP(s)              Health Monitor   SSL Cert Status           SSL Cert Secret Name
   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["168.1.1.1"]      None             created                   <certificate>
   

   # Example output for VPC clusters:
   Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
   

3. パブリック istio-ingressgateway ロード・バランサー・サービスを使用して HTTP 用のポート 80 を公開するゲートウェイを作成します。 <namespace> を、Istio 管理対象マイクロサービスがデプロイされている名前空間で置き換えます。 ゲートウェイYAMLコンポーネントの詳細については 、Istioのリファレンスドキュメントを参照してください。

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: my-gateway
     namespace: <namespace>
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           name: https
           protocol: HTTPS
           number: 443
       tls:
         mode: SIMPLE
         serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
         privateKey: /etc/istio/ingressgateway-certs/tls.key
       hosts:
       - "*"
   

4. Istio マネージド・マイクロサービスがデプロイされている名前空間にゲートウェイを適用します。

   kubectl apply -f my-gateway.yaml -n <namespace>
   

5. my-gateway ゲートウェイを使用するとともにアプリ・マイクロサービスのためのルーティング・ルールを定義する仮想サービスを作成します。 仮想サービスYAMLコンポーネントの詳細については 、Istioのリファレンスドキュメントを参照してください。

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: my-virtual-service
     namespace: <namespace> # The namespace where your Istio-managed microservices are deployed.
   spec:
     gateways:
     - my-gateway # `my-gateway` is specified so that the gateway can apply these virtual service routing rules to the `istio-ingressgateway` load balancer.
     hosts:
     - '*'
     http:
     - match:
       - uri:
           exact: /<service_path> # Replace `service_path` with the path that your entrypoint microservice listens on. For example, in the BookInfo app, the path is defined as `/productpage`.
       route:
       - destination:
           host: <service_name> # The name of your entrypoint microservice. For example, in the BookInfo app, `productpage` served as the entrypoint microservice that called the other app microservices.
           port:
             number: 443 # If your microservice listens on a different port, replace 443 with the port.
   

6. Istio マネージド・マイクロサービスがデプロイされている名前空間に仮想サービス・ルールを適用します。

   kubectl apply -f my-virtual-service.yaml -n <namespace>
   

7. ** パブリック・ロード・バランサーの **EXTERNAL-IPistio-ingressgateway アドレス (クラシック・クラスター) またはホスト名 (VPC クラスター) を取得します。 クラスターの各ゾーンで Istio ロード・バランサーを有効にした場合は、各ゾーン内のロード・バランサー・サービスの IP アドレスまたはホスト名を取得します。

   kubectl get svc -n istio-system
   

   # Example output for classic clusters:
   istio-ingressgateway     LoadBalancer   172.21.XXX.XXX   169.1.1.1       80:31380/TCP,443:31390/TCP,31400:31400/TCP,5011:31323/TCP,8060:32483/TCP,853:32628/TCP,15030:31601/TCP,15031:31915/TCP  22m
   

   # Example output for VPC clusters:
   istio-ingressgateway     LoadBalancer   172.21.XXX.XXX   1234abcd-us-south.lb.appdomain.cloud       80:31380/TCP,443:31390/TCP,31400:31400/TCP,5011:31323/TCP,8060:32483/TCP,853:32628/TCP,15030:31601/TCP,15031:31915/TCP  22m
   

8. アプリ・マイクロサービスの URL を入力して、Istio マネージド・マイクロサービスにトラフィックがルーティングされていることを確認します。

   https://<host_name>/<service_path>
   

NLB の DNS ホストのシークレットの証明書は、90 日ごとに有効期限が切れます。 デフォルトの名前空間のシークレットは、有効期限が切れる 37 日前に IBM Cloud Kubernetes Service によって自動的に更新されますが、シークレットが更新されるたびに、シークレットを istio-system 名前空間に手動でコピーする必要があります。 スクリプトを使用してこの処理を自動化することができます。

よりきめ細かくルーティングを制御することもできます。 ロードバランサーがトラフィックを各マイクロサービスにルーティングした後に適用されるルールを作成するには、例えば、トラフィックを1つのマイクロサービスの異なるバージョンに送信するルールなどを作成し、適用することができます DestinationRules作成して適用することができます。

Ingress セットアップまたは Egress セットアップをデバッグする必要がありますか? istio-global-proxy-accessLogFile 構成マップmanaged-istio-customの オプションが "/dev/stdout" に設定されていることを確認します。 Envoy プロキシーは、アクセス情報を標準出力に出力します。これは、Envoy コンテナーに対して kubectl logs コマンドを実行することで表示できます。 ゲートウェイの ibm-cloud-provider-ip ポッドが pending のままになっている場合は、このトラブルシューティングのトピックを参照してください。