Cloud Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

モダナイゼーションのための構成の更新

このドキュメントでは、ISTIOD コントロールプレーンから TRAFFIC_DIRECTOR コントロールプレーンにメッシュをモダナイズする前に、マネージド Cloud Service Mesh に行う必要のある構成の更新について説明します。

以下に、クラスタのモダナイゼーションの準備に必要な構成の更新の例を示します。更新手順については、各セクションをご覧ください。

マルチクラスタ
Workload Identity Federation for GKE を有効にする
マネージド CNI を有効にする
サイドカーでの標準以外のバイナリの使用
Istio Ingress ゲートウェイに移行する

モダナイゼーションワークフローの詳細については、マネージドコントロールプレーンのモダナイゼーションのページをご覧ください。

Istio シークレットから multicluster_mode に移行する

クラスタが TRAFFIC_DIRECTOR コントロールプレーンを使用している場合、マルチクラスタシークレットはサポートされません。このドキュメントでは、Istio マルチクラスタシークレットから multicluster_mode へのモダナイゼーションの方法について説明します。

Istio シークレットと宣言型 API の概要

オープンソースの Istio マルチクラスタエンドポイント検出は、istioctl などのツールを使用してクラスタに Kubernetes Secret を作成することによって機能します。このシークレットにより、クラスタはメッシュ内の別のクラスタにトラフィックをロードバランスできます。ISTIOD コントロールプレーンは、このシークレットを読み取り、その他のクラスタへのトラフィックのルーティングを開始します。

Cloud Service Mesh は、Istio シークレットを直接作成するのではなく、マルチクラスタトラフィックを制御する宣言型 API を使用します。この API は、Istio シークレットを実装の詳細として扱います。これにより Istio シークレットを手動で作成する場合よりも信頼性が高くなります。今後の Cloud Service Mesh の機能は宣言型 API に依存するため、これらの新機能を Istio シークレットに直接使用することはできません。今後サポート対象となる方法は、宣言型 API のみです。

Istio シークレットを使用している場合は、宣言型 API への移行をできるだけ早く行ってください。multicluster_mode 設定では、各クラスタがメッシュ内の他のすべてのクラスタにトラフィックを転送するように指示します。シークレットを使用すると、より柔軟な構成が可能になり、メッシュ内のどのクラスタにトラフィックを転送するかをクラスタごとに構成できます。宣言型 API と Istio シークレットでサポートされている機能の違いの一覧については、Istio API を使用しているサポート対象の機能をご覧ください。

Istio シークレットから宣言型 API に移行する

フリート機能の API で自動管理を使用して Cloud Service Mesh をプロビジョニングした場合は、次の手順を行う必要はありません。これらの手順は、asmcli --managed を使用してオンボーディングした場合にのみ適用されます。

このプロセスでは、クラスタを参照するシークレットが変更されます。このプロセス中に、エンドポイントが削除されてから再び追加されます。エンドポイントの削除と追加の間、トラフィックは他のクラスタへのロードバランシングではなく、ローカルルーティングに短時間戻ります。詳しくは、GitHub の問題をご覧ください。

Istio シークレットの使用から宣言型 API に移行する手順は次のとおりです。次の手順を同時に、または短時間で連続して実行します。

マルチクラスタエンドポイント検出を有効にするフリート内の各クラスタで、multicluster_mode=connected を設定して宣言型 API を有効にします。クラスタを検出できないようにするには、multicluster_mode=disconnected を明示的に設定する必要があります。

マルチクラスタエンドポイント検出に対してクラスタをオプトインするには、次のコマンドを使用します。
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
エンドポイント検出に対してクラスタをオプトアウトするには、次のコマンドを使用します。
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
古いシークレットを削除します。

クラスタに multicluster_mode=connected を設定すると、multicluster_mode=connected が設定されている他のすべてのクラスタに対して、各クラスタに新しいシークレットが生成されます。このシークレットは istio-system Namespace に配置され、次の形式になります。
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
各シークレットには、ラベル istio.io/owned-by: mesh.googleapis.com も適用されます。

新しいシークレットが作成されたら、istioctl create-remote-secret で手動で作成したシークレットを削除できます。
```
kubectl delete secret SECRET_NAME -n istio-system
```

移行したら、リクエスト指標を確認して、想定どおりにルーティングされていることを確認します。

Workload Identity Federation for GKE を有効にする

Google Kubernetes Engine のワークロードを安全に運用するためには、Workload Identity 連携の使用が推奨されます。この連携を使って、Compute Engine、BigQuery、ML API などの Google Cloud サービスにアクセスできます。Workload Identity 連携は IAM ポリシーを使用するため、手動構成や、サービスアカウントキーファイルのような安全性の低い方法は必要ありません。Workload Identity 連携の詳細については、Workload Identity Federation for GKE の仕組みをご覧ください。

以降のセクションでは、Workload Identity 連携を有効にする方法について説明します。

クラスタで Workload Identity Federation を有効にする

クラスタで Workload Identity 連携が有効になっていることを確認します。それには、GKE クラスタに Workload Identity 連携プールを構成しておく必要があります。IAM 認証情報の検証に不可欠であるためです。

次のコマンドを使用して、クラスタに設定されている Workload Identity プールを確認します。
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
CLUSTER_NAME を GKE クラスタの名前に置き換えます。gcloud のデフォルトゾーンまたはデフォルトリージョンをまだ指定していない場合は、このコマンドの実行時に --region フラグまたは --zone フラグも指定する必要があります。
出力が空の場合は、既存のクラスタを更新するの手順に沿って、既存の GKE クラスタで Workload Identity を有効にします。

ノードプールで Workload Identity 連携を有効にする

クラスタで Workload Identity 連携を有効にしたら、GKE メタデータサーバーを使用するようにノードプールを構成する必要があります。

Standard クラスタのすべてのノードプールの一覧を取得します。gcloud container node-pools list コマンドを実行します。
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
CLUSTER_NAME を GKE クラスタの名前に置き換えます。gcloud のデフォルトゾーンまたはデフォルトリージョンをまだ指定していない場合は、このコマンドの実行時に --region フラグまたは --zone フラグも指定する必要があります。
各ノードプールが GKE メタデータサーバーを使用していることを確認します。
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
次のように置き換えます。
- NODEPOOL_NAME はノードプールの名前に置き換えます。
- CLUSTER_NAME は GKE クラスタの名前に置き換えます。
出力に GKE_METADATA が含まれていない場合は、既存のノードプールを更新するのガイドに沿ってノードプールを更新します。

マネージド Container Network Interface（CNI）を有効にする

このセクションでは、Google Kubernetes Engine で Cloud Service Mesh のマネージド CNI を有効にする方法について説明します。

マネージド CNI の概要

マネージド Container Network Interface（CNI）は、Istio CNI の Google 管理の実装です。CNI プラグインは、iptables ルールを構成することで Pod ネットワーキングを効率化します。これにより、アプリケーションと Envoy プロキシ間のトラフィックリダイレクトが有効になり、iptables の管理に必要な init-container の権限を付与する必要がなくなります。

istio-init コンテナは Istio CNI プラグインに置き換えられます。以前は、istio-init コンテナが、Istio サイドカーのトラフィックインターセプションを有効にするために Pod のネットワーク環境を設定していました。CNI プラグインは同じネットワークリダイレクト機能を実行しますが、昇格権限の必要性を減らし、セキュリティを強化するという利点があります。

したがって、セキュリティと信頼性を強化し、管理とトラブルシューティングを簡素化するために、すべてのマネージド Cloud Service Mesh デプロイでマネージド CNI が必要です。

初期コンテナへの影響

初期コンテナは、設定タスク用にアプリケーションコンテナの前に実行される特殊なコンテナです。設定タスクには、構成ファイルのダウンロード、外部サービスとの通信、アプリケーション前の初期化の実行などのタスクが含まれます。ネットワークアクセスに依存する初期コンテナは、クラスタでマネージド CNI が有効になっている場合に問題が発生する可能性があります。

マネージド CNI を使用した Pod の設定プロセスは次のとおりです。

CNI プラグインは、Pod ネットワークインターフェースを設定し、Pod IP を割り当て、まだ起動していない Istio サイドカープロキシにトラフィックをリダイレクトします。
すべての初期コンテナが実行され、完了します。
Istio サイドカープロキシは、アプリケーションコンテナとともに起動します。

したがって、初期コンテナがアウトバウンドネットワーク接続を試行するか、メッシュ内のサービスに接続しようとすると、初期コンテナからのネットワークリクエストが破棄または誤ってルーティングされる可能性があります。これは、リクエストの送信時に、Pod のネットワークトラフィックを管理する Istio サイドカープロキシが実行されていないためです。詳細については、Istio CNI のドキュメントをご覧ください。

クラスタのマネージド CNI を有効にする

このセクションの手順に沿って、クラスタでマネージド CNI を有効にします。

初期コンテナからネットワーク依存関係を削除します。次の代替方法を検討してください。
- アプリケーションロジックまたはコンテナを変更する: サイドカープロキシの起動後に、ネットワークリクエストを必要とする初期コンテナや、アプリケーションコンテナ内でネットワークオペレーションを実行する初期コンテナへの依存関係を削除するようにサービスを変更できます。
- Kubernetes ConfigMap または Secret を使用する: ネットワークリクエストによって取得された構成データを Kubernetes ConfigMap または Secret に保存し、アプリケーションコンテナにマウントします。その他のソリューションについては、Istio のドキュメントをご覧ください。
クラスタでマネージド CNI を有効にします。
1. 次の構成変更を行います。
  1. 次のコマンドを実行して controlPlaneRevision を見つけます。
```
kubectl get controlplanerevision -n istio-system
```
  2. ControlPlaneRevision（CPR）カスタムリソース（CR）で、ラベル mesh.cloud.google.com/managed-cni-enabled を true に設定します。
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    CPR_NAME は、前の手順の出力の NAME 列の値に置き換えます。
  3. asm-options ConfigMap で、ASM_OPTS の値を CNI=on に設定します。
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. ControlPlaneRevision（CPR）カスタムリソース（CR）で、ラベル mesh.cloud.google.com/force-reprovision を true に設定します。このアクションにより、コントロールプレーンの再起動がトリガーされます。
    
    注: この方法はコントロールプレーンの再起動には推奨されません。Cloud Service Mesh のモダナイゼーションにのみ使用してください。
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. 機能の状態を確認します。次のコマンドを使用して、機能の状態を取得します。
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  FLEET_PROJECT_ID は、フリートホストプロジェクトの ID に置き換えます。通常、FLEET_PROJECT_ID はプロジェクトと同じ名前になります。
  - MANAGED_CNI_NOT_ENABLED 条件が servicemesh.conditions から削除されたことを確認します。
  - なお、ステータスが更新されるまでに 15～20 分ほどかかることがあります。数分待ってからコマンドを再実行してみてください。
3. クラスタの機能で controlPlaneManagement.state が Active になったら、Pod を再起動します。

サイドカーでの標準以外のバイナリの使用を廃止する

このセクションでは、デプロイメントを Distroless Envoy プロキシイメージと互換性のあるものにする方法について説明します。

Distroless Envoy プロキシのサイドカーイメージ

Cloud Service Mesh は、コントロールプレーンの構成に基づいて、さまざまなバイナリを含む Ubuntu ベースのイメージと Distroless イメージの 2 種類の Envoy プロキシサイドカーイメージを使用します。Distroless ベースイメージは、必要なコンポーネントのみを含めることで、セキュリティとリソースの最適化を優先する最小限のコンテナイメージです。攻撃対象領域が縮小され、脆弱性の防止に役立ちます。詳細については、Distroless プロキシイメージのドキュメントをご覧ください。

バイナリの互換性

コンテナランタイムの内容は、必要なパッケージのみに制限することをおすすめします。この方法により、セキュリティと共通脆弱性識別子（CVE）スキャナの信号対雑音比が改善されます。Distroless サイドカーイメージには最小限の依存関係があり、必須ではない実行可能ファイル、ライブラリ、デバッグツールはすべて削除されています。したがって、コンテナ内でシェルコマンドを実行したり、curl、ping、kubectl exec などのデバッグユーティリティを使用したりすることはできません。

クラスタを Distroless イメージと互換性のあるものにする

サポートされていないバイナリ（bash や curl など）への参照を構成から削除します。特に、Readiness、Startup、Liveness プローブ内、および istio-proxy、istio-init、istio-validation コンテナ内の Lifecycle PostStart と PreStop フック内。
特定のユースケースでは、holdApplicationUntilProxyStarts などの代替手段を検討してください。
デバッグには、エフェメラルコンテナを使用して実行中のワークロード Pod に接続できます。その後、インスペクトしてカスタムコマンドを実行できます。例については、Cloud Service Mesh ログを収集するをご覧ください。

特定のユースケースに適した解決策が見つからない場合は、サポートの利用を参照のうえ Google Cloudサポートまでお問い合わせください。

Istio Ingress ゲートウェイに移行する

このセクションでは、Istio Ingress ゲートウェイに移行する方法について説明します。Istio Ingress ゲートウェイへの移行には、次の 2 つの方法があります。

トラフィック分割による段階的な移行

この方法では、停止を最小限に抑えることを優先します。トラフィックを新しい Istio ゲートウェイに段階的に送信し、リクエストのごく一部でパフォーマンスをモニタリングして必要に応じてすばやく元に戻すことができます。レイヤ 7 トラフィック分割の構成は一部のアプリケーションでは難しい場合があるため、移行中は両方のゲートウェイシステムを同時に管理する必要があります。手順については、トラフィック分割を使用した段階的な移行をご覧ください。
直接移行

この方法では、テストを徹底的に実施した後、すべてのトラフィックを新しい Istio ゲートウェイに同時に再ルーティングします。このアプローチの利点は、古いゲートウェイのインフラストラクチャから完全に分離されるため、既存の設定の制約を受けずに新しいゲートウェイの構成を柔軟に行えることです。ただし、移行中に新しいゲートウェイで予期しない問題が発生した場合、ダウンタイムのリスクが高まります。手順については、直接移行をご覧ください。

次の移行例では、アプリケーションの Namespace（default）で HTTP サービス（httpbin）が実行され、Kubernetes Gateway API を使用して外部に公開されていることを前提としています。関連する構成は次のとおりです。

ゲートウェイ: k8-api-gateway（istio-ingress Namespace 内） - .example.com で終わるホスト名のポート 80 で HTTP トラフィックをリッスンするように構成されています。
HTTPRoute: httpbin-route（default Namespace 内） - ホスト名が httpbin.example.com で、パスが /get で始まる HTTP リクエストを default Namespace 内の httpbin サービスに転送します。
httpbin アプリケーションには、外部 IP 34.57.246.68 を使用してアクセスできます。

基本的なゲートウェイの図

トラフィック分割による段階的な移行

新しい Istio Ingress ゲートウェイをプロビジョニングする

サンプルゲートウェイをデプロイするの手順に沿って新しい Ingress ゲートウェイをデプロイし、要件に合わせてサンプル構成をカスタマイズします。anthos-service-mesh リポジトリのサンプルは、istio-ingressgateway loadBalancer サービスと対応する ingress-gateway Pod をデプロイするためのものです。

ゲートウェイリソースの例（istio-ingressgateway.yaml）

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

ゲートウェイ構成を適用してトラフィックを管理します。
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
ゲートウェイリソースの spec.selector が ingress-gateway Pod のラベルと一致していることを確認します。たとえば、ingress-gateway Pod に istio=ingressgateway というラベルが付いている場合、ゲートウェイ構成でもこの istio=ingressgateway ラベルを選択する必要があります。

新しいゲートウェイの初期ルーティングを構成する

Istio VirtualService を使用して、アプリケーションの初期ルーティングルールを定義します。

VirtualService の例（my-app-vs-new.yaml）:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

VirtualService を適用します。

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

新しくデプロイされた Istio Ingress ゲートウェイを介してバックエンド（httpbin）サービスにアクセスする

Ingress Host 環境変数を、最近デプロイした istio-ingressgateway ロードバランサに関連付けられた外部 IP アドレスに設定します。
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
新しいゲートウェイを使用してアプリケーション（httpbin）にアクセスできることを確認します。
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
出力は次のようになります。
```
HTTP/1.1 200 OK
```

新しい Istio Ingress ゲートウェイを使用したリクエストフロー

トラフィック分割用に既存の Ingress を変更する

新しいゲートウェイ（istio-api-gateway など）の設定が正常に完了したことを確認したら、トラフィックの一部をそのゲートウェイ経由でルーティングできます。これを行うには、現在の HTTPRoute を更新して、トラフィックのごく一部を新しいゲートウェイに転送し、大部分は既存のゲートウェイ（k8-api-gateway）を引き続き使用するようにします。

HTTPRoute を編集用に開きます。

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

新しい Ingress ゲートウェイのロードバランササービスを指す新しいバックエンド参照を初期重み 10% で追加し、古いゲートウェイのバックエンドの重みを更新します。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

参照権限付与を使用して、Namespace 間の参照の権限を付与します。

アプリケーションの Namespace（default）にある HTTPRoute がゲートウェイの Namespace（istio-ingress）の loadbalancer サービスにアクセスできるようにするには、参照権限付与を作成する必要があります。このリソースはセキュリティ制御として機能し、許可される Namespace 間の参照を明示的に定義します。

次の istio-ingress-grant.yaml は、参照権限付与の例を示しています。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

参照権限付与を適用します。

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

既存の外部 IP アドレス（例: 34.57.246.68）へのリクエストが失敗していないことを確認します。次の check-traffic-flow.sh は、リクエストの失敗をチェックするスクリプトを示しています。

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

スクリプトを実行して、トラフィックルートに関係なくリクエストが失敗しないことを確認します。
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

既存のゲートウェイと新しい Istio Ingress ゲートウェイの間でトラフィックが分割されたリクエストフロー

トラフィックの割合を徐々に増やす

既存の外部 IP アドレス（34.57.246.68 など）でリクエストエラーが発生していない場合は、HTTPRoute でバックエンドの重みを調整して、新しい Istio Ingress ゲートウェイにトラフィックを徐々に移行します。istio-ingressgateway の重みを増やし、古いゲートウェイの重みを 10%、20% などの小さな増分で減らします。

次のコマンドを使用して、既存の HTTPRoute を更新します。

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

トラフィックの完全な移行と古いゲートウェイの削除

新しい Istio Ingress ゲートウェイが安定したパフォーマンスとリクエスト処理を実証したら、すべてのトラフィックを新しい Istio Ingress ゲートウェイに移行します。HTTPRoute を更新して、古いゲートウェイのバックエンドの重みを 0 に、新しいゲートウェイの重みを 100 に設定します。
トラフィックが新しいゲートウェイに完全にルーティングされたら、アプリケーションのホスト名（httpbin.example.com など）の外部 DNS レコードを更新して、新しい Istio Ingress ゲートウェイをプロビジョニングするで作成したロードバランササービスの外部 IP アドレスを指すようにします。

最後に、古いゲートウェイとその関連リソースを削除します。

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

直接移行

新しい Istio Ingress ゲートウェイをプロビジョニングする

ゲートウェイリソースの例（istio-ingressgateway.yaml）

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

ゲートウェイ構成を適用してトラフィックを管理します。
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
ゲートウェイリソースの spec.selector が ingress-gateway Pod のラベルと一致していることを確認します。たとえば、ingress-gateway Pod に istio=ingressgateway というラベルが付いている場合、ゲートウェイ構成でもこの istio=ingressgateway ラベルを選択する必要があります。

新しいゲートウェイの初期ルーティングを構成する

Istio VirtualService を使用して、アプリケーションの初期ルーティングルールを定義します。

VirtualService の例（my-app-vs-new.yaml）:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

VirtualService を適用します。

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

新しくデプロイされた Istio Ingress ゲートウェイを介してバックエンド（httpbin）サービスにアクセスする

Ingress Host 環境変数を、最近デプロイした istio-ingressgateway ロードバランサに関連付けられた外部 IP アドレスに設定します。
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
新しいゲートウェイを使用してアプリケーション（httpbin）にアクセスできることを確認します。
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
出力は次のようになります。
```
HTTP/1.1 200 OK
```

新しい Istio Ingress ゲートウェイを使用したリクエストフロー

新しいゲートウェイをテストしてモニタリングする

すべてのルーティングルールをテストし、TLS 構成、セキュリティポリシー、その他の機能を検証します。負荷テストを実行して、新しいゲートウェイが想定されるトラフィックを処理できることを確認します。
新しいゲートウェイのテストが完了したら、アプリケーションのホスト名（httpbin.example.com など）の外部 DNS レコードを更新し、新しい Istio Ingress ゲートウェイをプロビジョニングするで作成したロードバランササービスの外部 IP アドレスを指すようにします。
リクエスト成功率、レイテンシ、エラー率、アプリケーション Pod のリソース使用率などの主要な指標をモニタリングして、新しい Istio Ingress ゲートウェイの安定性を確認します。安定したら、古いゲートウェイとそれに関連付けられたリソースを削除できます。
```
kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
```

重要な考慮事項: アプリケーションで HTTPS が必要な場合は、新しい Istio Ingress ゲートウェイで TLS 証明書と構成が正しく設定されていることを確認してください。詳細については、Ingress ゲートウェイで TLS 終端を設定するをご覧ください。

モダナイゼーションのための構成の更新

Istio シークレットから multicluster_mode に移行する

Istio シークレットと宣言型 API の概要

Istio シークレットから宣言型 API に移行する

Workload Identity Federation for GKE を有効にする

クラスタで Workload Identity Federation を有効にする

ノードプールで Workload Identity 連携を有効にする

マネージド Container Network Interface（CNI）を有効にする

マネージド CNI の概要

初期コンテナへの影響

クラスタのマネージド CNI を有効にする

サイドカーでの標準以外のバイナリの使用を廃止する

Distroless Envoy プロキシのサイドカー イメージ

バイナリの互換性

クラスタを Distroless イメージと互換性のあるものにする

Istio Ingress ゲートウェイに移行する

トラフィック分割による段階的な移行

新しい Istio Ingress ゲートウェイをプロビジョニングする

新しいゲートウェイの初期ルーティングを構成する

新しくデプロイされた Istio Ingress ゲートウェイを介してバックエンド（httpbin）サービスにアクセスする

トラフィック分割用に既存の Ingress を変更する

トラフィックの割合を徐々に増やす

トラフィックの完全な移行と古いゲートウェイの削除

直接移行

新しい Istio Ingress ゲートウェイをプロビジョニングする

新しいゲートウェイの初期ルーティングを構成する

新しくデプロイされた Istio Ingress ゲートウェイを介してバックエンド（httpbin）サービスにアクセスする

新しいゲートウェイをテストしてモニタリングする

Distroless Envoy プロキシのサイドカーイメージ