モダナイゼーションのための構成の更新
このドキュメントでは、ISTIOD コントロール プレーンから TRAFFIC_DIRECTOR コントロール プレーンにメッシュをモダナイズする前に、マネージド Cloud Service Mesh に行う必要のある構成の更新について説明します。
以下に、クラスタのモダナイゼーションの準備に必要な構成の更新の例を示します。更新手順については、各セクションをご覧ください。
- マルチクラスタ
- Workload Identity Federation for GKE を有効にする
- マネージド CNI を有効にする
- サイドカーでの標準以外のバイナリの使用
- Istio Ingress ゲートウェイに移行する
- EnvoyFilter コンプレッサ構成を最新化する
- インターネット ネットワーク エンドポイント グループを有効にする
- 共有 VPC の権限
- コントロール プレーンの構成がない
モダナイゼーション ワークフローの詳細については、マネージド コントロール プレーンのモダナイゼーションのページをご覧ください。
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_NAMECLUSTER_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 を有効にします。
次の構成変更を行います。
次のコマンドを実行して
controlPlaneRevisionを見つけます。kubectl get controlplanerevision -n istio-systemControlPlaneRevision（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 \ --overwriteCPR_NAMEは、前の手順の出力の NAME 列の値に置き換えます。asm-options ConfigMap で、
ASM_OPTSの値をCNI=onに設定します。kubectl patch configmap asm-options -n istio-system \ -p '{"data":{"ASM_OPTS":"CNI=on"}}'ControlPlaneRevision（CPR）カスタム リソース（CR）で、アノテーションmesh.cloud.google.com/force-reprovisionをtrueに設定します。このアクションにより、コントロール プレーンの再起動がトリガーされます。kubectl annotate controlplanerevision CPR_NAME \ -n istio-system mesh.cloud.google.com/force-reprovision=true \ --overwrite
機能の状態を確認します。以下のコマンドを使用して、機能の状態を取得します。
gcloud container fleet mesh describe --project FLEET_PROJECT_IDFLEET_PROJECT_IDは、フリートホスト プロジェクトの ID に置き換えます。通常、FLEET_PROJECT_IDはプロジェクトと同じ名前になります。MANAGED_CNI_NOT_ENABLED条件がservicemesh.conditionsから削除されたことを確認します。- なお、ステータスが更新されるまでに 15～20 分ほどかかることがあります。数分待ってからコマンドを再実行してみてください。
クラスタの機能で
controlPlaneManagement.stateがActiveになったら、Pod を再起動します。
サイドカーでの標準以外のバイナリの使用を廃止する
このセクションでは、デプロイを distroless Envoy プロキシ イメージと互換性のあるものにする方法について説明します。
Distroless Envoy プロキシのサイドカー イメージ
Cloud Service Mesh は、コントロール プレーンの構成に基づいて、default プロキシ イメージ（さまざまなデバッグ バイナリを含む）と distroless プロキシ イメージの 2 種類の Envoy プロキシ サイドカー イメージを使用します。
マネージド TRAFFIC_DIRECTOR コントロール プレーンを使用するクラスタの場合:
- 直接オンボーディングされたクラスタ: デフォルトで
distrolessイメージを使用します。 - CSM-ISTIOD から移行されたクラスタ: デフォルトで
defaultイメージを使用します。セキュリティ ポスチャーを改善するために、distrolessイメージを明示的にオプトインできます。
CSM-ISTIOD から移行したクラスタで distroless イメージを有効にするには、MeshConfig の defaultConfig.image.imageType: distroless を使用してグローバルに構成するか、sidecar.istio.io/proxyImageType: distroless Pod アノテーションを使用してワークロードごとに構成します。
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 に接続できます。その後、インスペクトしてカスタム コマンドを実行できます。例については、{service_mesh_name} のログを収集しています を参照してください。
特定のユースケースに適した解決策が見つからない場合は、サポートの利用を参照のうえ Google Cloudサポートまでお問い合わせください。
Istio Ingress ゲートウェイに移行する
このセクションでは、Istio Ingress ゲートウェイに移行する方法について説明します。Istio Ingress ゲートウェイへの移行には、次の 2 つの方法があります。
トラフィック分割による段階的な移行
この方法では、停止を最小限に抑えることを優先します。トラフィックを新しい Istio ゲートウェイに段階的に送信し、リクエストのごく一部でパフォーマンスをモニタリングして必要に応じてすばやく元に戻すことができます。レイヤ 7 トラフィック分割の構成は一部のアプリケーションでは難しい場合があるため、移行中は両方のゲートウェイ システムを同時に管理する必要があります。手順については、トラフィック分割を使用した段階的な移行をご覧ください。
直接移行
この方法では、テストを徹底的に実施した後、すべてのトラフィックを新しい Istio ゲートウェイに同時に再ルーティングします。このアプローチの利点は、古いゲートウェイのインフラストラクチャから完全に分離されるため、既存の設定の制約を受けずに新しいゲートウェイの構成を柔軟に行えることです。ただし、移行中に新しいゲートウェイで予期しない問題が発生した場合、ダウンタイムのリスクが高まります。手順については、直接移行をご覧ください。
以下の移行例では、アプリケーション名前空間 (デフォルト) で HTTP サービス (httpbin) が実行されており、Kubernetes Gateway API を使用して外部に公開されていることを前提としています。関連する構成は次のとおりです。
- ゲートウェイ:
k8-api-gateway（istio-ingressNamespace 内） -.example.comで終わるホスト名のポート 80 で HTTP トラフィックをリッスンするように構成されています。 - HTTPRoute:
httpbin-route（defaultNamespace 内） - ホスト名がhttpbin.example.comで、パスが/getで始まる HTTP リクエストをdefaultNamespace 内のhttpbinサービスに転送します。 - httpbin アプリケーションには、外部 IP アドレス 34.57.246.68 を使用してアクセスできます。
トラフィック分割による段階的な移行
新しい Istio Ingress ゲートウェイをプロビジョニングする
サンプル ゲートウェイをデプロイするの手順に沿って新しい Ingress ゲートウェイをデプロイし、要件に合わせてサンプル構成をカスタマイズします。anthos-service-mesh リポジトリのサンプルは、
istio-ingressgatewayloadBalancer サービスと対応するingress-gatewayPod をデプロイするためのものです。ゲートウェイ リソースの例（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-gatewayPod のラベルと一致していることを確認します。たとえば、ingress-gatewayPod に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: 8000VirtualService を適用します。
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
トラフィック分割用に既存の 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
トラフィックの割合を徐々に増やす
既存の外部 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 ゲートウェイをプロビジョニングする
サンプル ゲートウェイをデプロイするの手順に沿って新しい Ingress ゲートウェイをデプロイし、要件に合わせてサンプル構成をカスタマイズします。anthos-service-mesh リポジトリのサンプルは、
istio-ingressgatewayloadBalancer サービスと対応するingress-gatewayPod をデプロイするためのものです。ゲートウェイ リソースの例（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-gatewayPod のラベルと一致していることを確認します。たとえば、ingress-gatewayPod に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: 8000VirtualService を適用します。
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
新しいゲートウェイをテストしてモニタリングする
すべてのルーティング ルールをテストし、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 終端を設定するをご覧ください。
複数のコントロール プレーンを修正する
Cloud Service Mesh では以前、複数のコントロール プレーンのプロビジョニングをブロックしない asmcli（非推奨）を使用したオンボーディングがサポートされていました。現在の Cloud Service Mesh では、クラスタ チャンネルに一致するクラスタごとに 1 つのチャンネルのみをデプロイするというベスト プラクティスが適用されるようになり、同じクラスタで複数のチャンネルをデプロイして使用することはできません。
Stable または Regular で利用可能になる前に、Rapid の新しいバージョンのメッシュでカナリア デプロイを行う場合は、それぞれに別のチャンネルがある 2 つの異なるクラスタを使用する必要があります。チャンネルは GKE クラスタ チャンネルによって管理され、Mesh 自体に関連付けられた個別のチャンネルはありません。
複数のチャンネルがあるかどうかは、メンバーシップの UNSUPPORTED_MULTIPLE_CONTROL_PLANES ステータス条件で確認できます。この警告が表示されない場合は、影響がないため、このセクションを読み飛ばしてかまいません。
次のコマンドを実行して、クラスタに複数のコントロール プレーン チャンネルがあるかどうかを確認します。
gcloud container fleet mesh describe出力は次のようになります。
... projects/.../locations/global/memberships/my-membership: servicemesh: conditions: - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.' documentationLink: https://cloud.google.com/service-mesh/v1.29/docs/migrate/modernization-configuration-updates#multiple_control_planes severity: WARNING controlPlaneManagement: details: - code: REVISION_READY details: 'Ready: asm-managed-stable' implementation: ISTIOD state: ACTIVE ...UNSUPPORTED_MULTIPLE_CONTROL_PLANES条件が表示された場合は、クラスタに存在するチャンネルを特定します。kubectl get controlplanerevisions -n istio-system出力は次のようになります。
NAME RECONCILED STALLED AGE asm-managed-stable True False 97d asm-managed True False 97d asm-managed-rapid True False 97dこの例では、3 つのチャンネルすべてがプロビジョニングされています。
- asm-managed-stable -> STABLE
- asm-managed -> REGULAR
- asm-managed-rapid -> RAPID
結果が 1 つだけ表示された場合は、クラスタにプロビジョニングされているチャンネルは 1 つだけです。残りの手順はスキップできます。
2 つ以上の結果が表示された場合は、残りの手順に沿って余分なチャンネルを削除します。
ワークロードを 1 つのチャンネルに統合する
余分なチャンネルを削除する前に、ワークロードで単一のチャンネルのみが使用されていることを確認する必要があります。
クラスタで使用しているすべてのラベルを見つけます。
kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL前のコマンドの出力に応じて、RELEASE_CHANNEL を
asm-managed-stable、asm-managed、またはasm-managed-rapidに置き換えます。プロビジョニングされたチャンネルごとにこの手順を繰り返します。出力は次のようになります。
NAME STATUS AGE default Active 110dこの例では、Regular チャンネルで default Namespace が挿入されています。
すべてのワークロードですでに同じチャンネルを使用している場合は、余分なチャンネルを削除するの手順に進んでください。それ以外の場合は、このセクションの手順を続けます。
1 つのチャンネルのみが使用されるようにラベルを変更します。
- 場合によっては、
sidecar.istio.io/injectラベルを使用して Pod を直接挿入することもできます。使用状況についても確認してください。 - この手順では、
istio-injection=enabledラベルは無視してかまいません。このラベルが付いている Namespace は、クラスタに残っているチャンネルに合わせて自動的に変更されます。 - 保持するチャンネルを選択する際は、GKE クラスタ チャンネルと同じチャンネルを選択してください。このチャンネルが存在しない場合は、アクティブなチャンネルのいずれかを選択します。
- 実際に選択するチャンネルは重要ではありません。メッシュのバージョンは、メッシュのチャンネルではなく、GKE クラスタのチャンネルによって決まります。
- 使用中のアクティブなチャンネル間で meshconfig 構成を確認し、差異がないことを確認します。各チャンネルは構成に個別の configmap を使用するため、2 つのチャンネルを 1 つに統合すると、2 つのチャンネル間で一貫した動作が保証されます。
kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwriteNAMESPACE を Namespace の名前に置き換えます。
istio-injection=enabledを使用することをおすすめします。このラベルを使用しない場合は、istio.io/rev=RELEASE_CHANNELを使用することもできます。Namespace / Pod のラベルを変更したら、正しいコントロール プレーンによって挿入されるように、すべてのワークロードを再起動する必要があります。
- 場合によっては、
余分なチャンネルを削除する
すべてのワークロードが単一のチャンネルで実行されていることを確認したら、未使用の余分なチャンネルを削除できます。3 つのリリース チャンネルがすべてプロビジョニングされた場合は、チャンネルごとに次のコマンドを実行してください。
余分な
ControlPlaneRevisionリソースを削除します。kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-systemRELEASE_CHANNEL を
asm-managed-stable、asm-managed、またはasm-managed-rapidに置き換えます。MutatingWebhookConfigurationを削除します。kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNELmeshconfigconfigmap を削除します。kubectl delete configmap istio-RELEASE_CHANNEL
自動管理を有効にする
自動管理を有効にするには、次のコマンドを実行します。
gcloud container fleet mesh update \ --management automatic \ --memberships MEMBERSHIP_NAME \ --project PROJECT_ID \ --location MEMBERSHIP_LOCATION次のように置き換えます。
- MEMBERSHIP_NAME は、クラスタがフリートに登録されていることを確認した際に表示されるメンバーシップ名です。
- PROJECT_ID はプロジェクトのプロジェクト ID です。
- MEMBERSHIP_LOCATION は、メンバーシップのロケーションです（リージョンまたは
global）。メンバーシップのロケーションはgcloud container fleet memberships list --project PROJECT_IDで確認できます。
自動管理が有効になっていることを確認します。
gcloud container fleet mesh describe出力は次のようになります。
... membershipSpecs: projects/.../locations/us-central1/memberships/my-member: mesh: management: MANAGEMENT_AUTOMATIC membershipStates: projects/.../locations/us-central1/memberships/my-member: servicemesh: conditions: - code: VPCSC_GA_SUPPORTED details: This control plane supports VPC-SC GA. documentationLink: http://cloud.google.com/service-mesh/v1.29/docs/managed/vpc-sc severity: INFO controlPlaneManagement: details: - code: REVISION_READY details: 'Ready: asm-managed' implementation: TRAFFIC_DIRECTOR state: ACTIVE dataPlaneManagement: details: - code: OK details: Service is running. state: ACTIVE state: code: OK description: |- Revision ready for use: asm-managed. All Canonical Services have been reconciled successfully. ...
EnvoyFilter コンプレッサ構成を最新化する
envoy.extensions.filters.http.compressor.v3.Compressor フィルタを使用している場合、Envoy でいくつかのトップレベル フィールドが非推奨となり、response_direction_config.common_config と request_direction_config.common_config に移動しました。
EnvoyFilter リソースを最新のサポートされている形式に更新する方法については、EnvoyFilter コンプレッサ構成を最新化するをご覧ください。
必須の組織のポリシーを有効にする
Cloud Service Mesh を正常に動作させるには、特定のポリシーを有効にする必要があります。
必要なポリシー
compute.disableInternetNetworkEndpointGroup
Cloud Service Mesh にはインターネットネットワークエンドポイントグループ（NEG）を作成する機能が必要です。これらの NEG は、 Google Cloud外のサービスにトラフィックをルーティングするための重要なコンポーネントです。
constraints/compute.disableInternetNetworkEndpointGroup制約により、これらの必要なインターネット NEG の作成が妨げられる可能性があります。
この組織のポリシーがプロジェクト、フォルダ、組織に適用されている場合、Cloud Service Mesh が Traffic Director コントロール プレーンで正しく機能しなくなります。これにより、この Cloud Service Mesh 構成への移行や、この構成の正常な動作が妨げられます。
Enforced が true に設定されている場合、インターネット NEG の作成は無効になります。
影響を受けるかどうかを確認するにはどうすればよいですか？
プロジェクトの有効なポリシーは、 Google Cloud コンソールまたは Google Cloud CLI を使用して確認できます。組織のポリシーを表示する手順については、公式ドキュメントの組織のポリシーを表示するをご覧ください。
たとえば、次の Google Cloud CLI コマンドを使用できます。
gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project YOUR_PROJECT_ID --effective
ポリシーに enforced: true 値が表示されている場合は、影響を受けます。
constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy:
enforced: true
ポリシーに別の値が表示されている場合や、ポリシーが空の場合は、影響を受けません。
constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}
問題を解決する
ポリシーが適用されている場合は、組織、フォルダ、プロジェクトのレベルでこの制約を無効にする（false に設定する）必要があります。
このようなブール型制約を含む組織のポリシーを変更する手順については、組織のポリシーの作成と管理ガイドをご覧ください。通常、これらの変更を行うには roles/orgpolicy.policyAdmin ロールが必要です。
共有 VPC の権限
クラスタがサービス プロジェクトにあり、VPC ネットワークがホスト プロジェクトにある共有 VPC でマネージド Cloud Service Mesh を使用する場合は、フリート プロジェクトの Cloud Service Mesh サービス エージェントに追加の権限が必要です。
TRAFFIC_DIRECTOR コントロール プレーンへの移行の一環として、Cloud Service Mesh では、適切なヘルスチェックとネットワーク機能を確保するために、ホスト プロジェクトのファイアウォール ルールを管理する権限が必要です。これは、以前の ISTIOD コントロール プレーンでは必要ありませんでした。
影響を受けるかどうかを確認するにはどうすればよいですか？
以下のような場合に影響を受けます。
- GKE クラスタがサービス プロジェクトにある。
- これらのクラスタは、別のプロジェクト（VPC ホスト プロジェクト）でホストされている共有 VPC ネットワークを使用します。
- Fleet プロジェクトの Cloud Service Mesh サービスエージェントには、VPC ホストプロジェクトのファイアウォールルールを管理する権限がありません。
フリート機能の状態にコード SHARED_VPC_MISSING_PERMISSIONS の警告メッセージが表示されることがあります。この問題の理解と解決方法（システム管理オプションとユーザー管理オプションの両方を含む）の詳細については、ヘルスチェックを理解するを参照してください。
コントロール プレーンの構成がない
Cloud Service Mesh のサービス メッシュを管理するためのベスト プラクティスでは、Google Kubernetes Engine Fleet API を使用して Management フィールドを AUTOMATIC に設定します。これにより、Webhook やコントロール プレーンなど、多くのメッシュ機能を完全に自動で管理できます。さらに、新しいアップデートや機能がリリースされると、クラスターが自動的にそれらを受信するよう設定されます。一部の以前のインストール方法では、Cloud Service Mesh がこの方法で構成されていません。そのため、手動でパッチを適用する必要があります。
影響を受けるかどうかを確認するにはどうすればよいですか？
クラスタに ControlPlaneRevision があるかどうかを確認します。
kubectl get controlplanerevisions -n istio-system
クラスタに ControlPlaneRevision がすでに存在する場合は、このガイドは適用されません。ControlPlaneRevision がない場合は、このガイドを使用してクラスターを最新化してください。
MISSING_CONTROL_PLANE_CONFIG 警告が表示され、Cloud Service Mesh を使用したくない場合は、Cloud Service Mesh を無効にします。
モダナイゼーションの手順
以下の手順に従って、お使いの構成を現在の標準規格に適合させるために必要な作業を確認してください。
gcloud container fleet mesh describe --project PROJECT_ID
出力に応じて、次の手順を行います。
| 出力 | 実行する手順 |
|---|---|
API [gkehub.googleapis.com] not enabled on project [my-project]. Would you like to enable and retry (this will take a few minutes)? (y/N)? |
y と応答して再試行します。 |
ERROR: (gcloud.container.fleet.mesh.describe) Service Mesh Feature for project [my-project] is not enabled |
1. メッシュ機能を有効にします。 |
... resourceState: state: ACTIVE ... |
2. クラスタをフリートに登録します。 |
1. メッシュ機能を有効にする
メッシュ機能を有効にするには、以下のコマンドを使用します。これにより、Cloud Service Mesh をプロジェクト上で実行できるようになります。詳細および潜在的な副作用については、サービスメッシュのプロビジョニングを参照してください。
gcloud container fleet mesh enable --project PROJECT_ID
メッシュ機能を有効にした後、2 に進んでください。クラスタをフリートに登録します。
2. クラスタをフリートに登録する
お使いのクラスターが既にフリートに登録されているかどうかを確認してください。
gcloud container fleet memberships list --project PROJECT_ID
クラスターがリストにない場合は、次の手順に従って登録してください: フリートへのクラスターの登録。
クラスターをフリートに登録すると、そのクラスターは Cloud Service Mesh などの機能をフリートを通じて管理できるようになります。
3. メッシュチャンネルを決定します
Cloud Service Mesh は、独立したメッシュ チャンネルではなく、クラスタの Google Kubernetes Engine チャンネルに依存します。以前は、Cloud Service Mesh で 1 つ以上のメッシュ チャンネル（Google Kubernetes Engine クラスタ チャンネルとは異なる）を選択できました。メッシュ構成に、これらのチャネルへの参照が残っている可能性があります。
まず、使用しているチャネルを特定します。複数のチャネルを使用している場合は、複数のコントロール プレーンを修正するの手順に沿って、使用量を 1 つのチャネルに減らします。
使用しているメッシュチャネルを確認するには、ネームスペースのラベルを確認してください。ワークロードに注入ラベルを明示的に追加している場合は、ワークロードも確認する必要があることに注意してください。次のコマンドは、クラスタ内のすべてのワークロードをチェックし、出力をフィルタして、これらのワークロードに使用されるコントロール プレーンと挿入タグを表示します。
kubectl get namespaces,pods,deployments,statefulsets,daemonsets --all-namespaces --show-labels | grep -E "istio.io/rev|istio-injection"
カスタムタグやウェブフックを手動で作成した場合は、それらも確認する必要があります。
出力は次のようになります。
namespace/default Active 153d istio-injection=enabled,istio.io/rev=asm-managed,kubernetes.io/metadata.name=default
namespace/payments Active 42d istio.io/rev=asm-managed-stable,kubernetes.io/metadata.name=payments
default pod/frontend-847f569874-v9kjz 2/2 Running 0 2m app=frontend,istio.io/rev=asm-managed,pod-template-hash=847f569874
payments pod/checkout-0 2/2 Running 0 5d app=checkout,istio.io/rev=asm-managed-stable,controller-revision-hash=5c68b9487
default deployment.apps/frontend 1/1 1 1 153d app=frontend,istio.io/rev=asm-managed
payments statefulset.apps/checkout 1/1 1 1 42d app=checkout,istio.io/rev=asm-managed-stable
istio.io/rev={channel} に存在する値をメモします。名前は次のようにチャンネルと一致します。複数のチャネルが使用されている場合は、複数のコントロール プレーンを修正するの手順に沿って、チャネルを 1 つに減らします。
| 値 | チャネル |
|---|---|
asm-managed-stable |
Stable |
asm-managed |
標準 |
asm-managed-rapid |
Rapid |
メッシュ チャンネルが Google Kubernetes Engine クラスタ チャンネルと一致する場合は、ステップ 5 に進みます。
4. メッシュ チャネルの ControlPlaneRevision リソースを作成する
メッシュ チャンネルが Google Kubernetes Engine クラスタ チャンネルと一致する場合は、この手順をスキップできます。コントロール プレーンの自動管理を有効にすると、チャンネルがクラスタ チャンネルと一致する場合、この ControlPlaneRevision リソースが自動的に作成されます。
使用しているメッシュ チャネルの ControlPlaneRevision リソースを作成します。
Stable
kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
name: asm-managed-stable
namespace: istio-system
spec:
type: managed_service
channel: stable
EOF
標準
kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
name: asm-managed
namespace: istio-system
spec:
type: managed_service
channel: regular
EOF
Rapid
kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
name: asm-managed-rapid
namespace: istio-system
spec:
type: managed_service
channel: rapid
EOF
5. 自動管理を有効にする
マルチクラスタ エンドポイント ディスカバリを無効にするには、コントロール プレーンの自動管理を有効にする前に、エンドポイント ディスカバリの宣言型 API の「無効にする」の手順に沿って操作します。
マネージド データプレーンを無効にするには、マネージド データプレーンを無効にするの手順に沿って操作します。
自動管理を有効にするには、次のコマンドを実行します。これにより、フリート管理の Cloud Service Mesh がクラスタのコントロール プレーン構成を管理できるようになります。
gcloud container fleet mesh update --management automatic --memberships MY_CLUSTER_MEMBERSHIP --project PROJECT_ID
MY_CLUSTER_MEMBERSHIP は、クラスタのメンバーシップ名に置き換えます。
6. インストールを検証する
次のコマンドを実行します。
gcloud container fleet mesh describe --project PROJECT_ID
出力は次のようになります。
createTime: '2025-02-24T22:10:10.826263363Z'
etag: XjjRZB3-ZsueoaKihEBUupYhMDUjvoSyUHTVD2YgR6k
membershipSpecs:
projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
mesh:
management: MANAGEMENT_AUTOMATIC # See item 1 below
membershipStates:
projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
servicemesh:
conditions: [] # See item 2 below
controlPlaneManagement: # See item 3 below
details:
- code: REVISION_READY
details: 'Ready: asm-managed'
implementation: TRAFFIC_DIRECTOR
state: ACTIVE
dataPlaneManagement: # See item 4 below
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: |-
Revision ready for use: asm-managed.
All Canonical Services have been reconciled successfully.
updateTime: '2025-06-17T23:39:05.267540058Z'
name: projects/my-project/locations/global/features/servicemesh
resourceState:
state: ACTIVE
spec: {}
updateTime: '2025-02-25T04:12:16.280672401Z'
membershipSpecs内では、フリート内の各メンバーシップに個別の仕様があります。各メンバーの管理が正しくMANAGEMENT_AUTOMATICに設定されていることを確認してください。- 各メンバーシップには、関連付けられたステータス条件のリストがあります。エラーや警告がないことを確認し、提供されているドキュメント リンクに沿って問題を解決します。
controlPlaneManagementには、コントロールプレーンの状態が含まれます。コントロール プレーンがACTIVE状態であることを確認します。dataPlaneManagementには、データプレーンのステータスが含まれます。この設定は有効にしておくことをおすすめします。