マネージド Anthos Service Mesh を構成する

概要

マネージド Anthos Service Mesh は、Google が管理するコントロール プレーンで、お客様は、オプションのデータプレーンの構成だけを行い、信頼性、アップグレード、スケーリング、セキュリティについては Google が下位互換性のある方法で対応します。このガイドでは、単一クラスタまたはマルチクラスタの構成で、asmcli を使用してマネージド Anthos Service Mesh にアプリケーションを設定または移行する方法について説明します。

マネージド Anthos Service Mesh でサポートされる機能と制限事項については、マネージド Anthos Service Mesh でサポートされる機能をご覧ください。

前提条件

このガイドは、次のものが用意されていることを前提としています。

要件

  • サポートされているいずれかのリージョンで、サポート対象バージョンの GKE を使用している 1 つ以上のクラスタ。
  • マネージド Anthos Service Mesh をインストールするクライアント マシンと API サーバーとのネットワーク接続を確認します。
  • クラスタは、フリートに登録されている必要があります。この手順は、インストール前に個別に行うことも、--enable-registration フラグと --fleet-id フラグを渡してインストールの一環として行うこともできます。
  • プロジェクトでサービス メッシュ機能が有効になっている必要があります。インストールの一部として有効にするには、--enable-gcp-components を渡すか、次のコマンドを実行します。

    gcloud container hub mesh enable --project=FLEET_PROJECT_ID
    

    ここで、FLEET_PROJECT_ID はフリート ホスト プロジェクトのプロジェクト ID です。

  • マネージド Anthos Service Mesh では、単一プロジェクトの単一ネットワーク環境またはマルチプロジェクトの単一ネットワーク環境で複数の GKE クラスタを使用できます。

    • 異なるプロジェクトのクラスタを追加する場合は、同じフリート ホスト プロジェクトに登録する必要があります。また、共有 VPC 構成でクラスタを同じネットワークに接続する必要があります。
    • また、1 つのプロジェクトに共有 VPC をホストし、別々のサービス プロジェクトでクラスタを作成することをおすすめします。詳細については、共有 VPC を使用したクラスタの設定をご覧ください。
    • 組織で VPC Service Controls を使用している場合は、Google 管理のコントロール プレーンの適用時に追加の --use-vpcsc フラグを使用する必要があります。そうしないと、セキュリティ コントロールが失敗します。VPC Service Controls 機能は、Regular チャンネルと Rapid チャンネルで利用できます。

制限事項

マネージド Anthos Service Mesh でサポートされている機能と制限事項のリストを確認することをおすすめします。特に、次の点に注意してください。

  • IstioOperator API は、クラスタ内のコンポーネントを制御することが主な目的であるため、サポートされていません。

  • このマネージド データプレーンのプレビュー リリースは、マネージド コントロール プレーンの新しいデプロイでのみ使用できます。マネージド コントロール プレーンをすでにデプロイしており、マネージド データプレーンをデプロイする場合は、Google 管理のコントロール プレーンを適用するで説明するように、インストール ツールを再度実行する必要があります。

  • マネージド データプレーンは、Regular と Rapid のリリース チャンネルで使用できます。

  • マネージド Anthos Service Mesh で利用できる実際の機能は、リリース チャンネルによって異なります。詳細については、Anthos Service Mesh でサポートされている機能と制限事項のリストをご覧ください。

  • Google が管理するコントロール プレーンのプロビジョニング プロセス中に、選択したチャネルに対応する Istio CRD が指定のクラスタにインストールされます。クラスタに既存の Istio CRD が存在している場合、それらは上書きされます。

gcloud を構成する

Cloud Shell を使用している場合でも、次の手順を実施します。

  1. Google Cloud CLI で認証します。

    gcloud auth login --project PROJECT_ID
    
  2. コンポーネントを更新します。

    gcloud components update
    
  3. Anthos Service Mesh を GKE クラスタにインストールする場合は、クラスタを参照するように kubectl を構成します。

    gcloud container clusters get-credentials CLUSTER_NAME \
         --zone CLUSTER_LOCATION \
         --project PROJECT_ID
    

インストール ツールをダウンロードする

  1. 最新バージョンのツールを現在の作業ディレクトリにダウンロードします。

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
    
  2. ツールを実行可能にします。

    chmod +x asmcli
    

各クラスタを構成する

メッシュ内の各クラスタに対してマネージド Anthos Service Mesh を構成するには、次の手順を行います。

Google 管理のコントロール プレーンを適用する

Google 管理のコントロール プレーンを適用する前に、リリース チャンネルを選択する必要があります。

マネージド Anthos Service Mesh を使用するクラスタごとにインストール ツールを実行します。次の両方のオプションを含めることをおすすめします。

  • --enable-registration --fleet_id FLEET_PROJECT_ID この 2 つのフラグでクラスタをフリートに登録します。ここで、FLEET_ID はフリート ホスト プロジェクトのプロジェクト ID です。単一プロジェクトを使用する場合、FLEET_PROJECT_IDPROJECT_ID と同じであり、フリート ホスト プロジェクトとクラスタ プロジェクトは同じです。マルチプロジェクトのようなより複雑な構成では、個別のフリート ホスト プロジェクトを使用することをおすすめします。

  • --enable-all。このフラグにより、必要なコンポーネントと登録の両方が有効になります。

組織でプロジェクトに VPC Service Controls が適用されている場合は、追加のフラグ --use-vpcsc を構成する必要があります。そうしないと、セキュリティ コントロールが失敗します。VPC Service Controls 機能は、Regular チャンネルと Rapid チャンネルで利用できます。

クラスタが GKE Autopilot クラスタである場合は、GKE Autopilot セクションで、「asmcli」コマンドで使用する追加要件とフラグを確認します。

asmcli ツールは、CLI ツール内のツールとロジックを使用して、マネージド コントロール プレーンを直接構成します。推奨 CA に応じて、以下の一連の手順を使用します。

認証局

メッシュに使用する認証局を選択します。

Mesh CA

次のコマンドを実行して、デフォルトの機能と Mesh CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。RELEASE_CHANNEL は、適切なチャネル(regularstablerapid)に置き換えます。

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL

CA Service

  1. Certificate Authority Service を構成するの手順を行います。
  2. 次のコマンドを実行して、デフォルト機能と Certificate Authority Service を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。RELEASE_CHANNEL は、適切なチャネル(regularstablerapid)に置き換えます。
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL \
      --ca gcp_cas \
      --ca_pool pool_name

このツールは、指定された --output_dir にマネージド コントロール プレーンを構成するためのすべてのファイルをダウンロードし、istioctl ツールとサンプル アプリケーションをインストールします。このガイドの手順では、asmcli install の実行時に指定した --output_dir の場所から istioctl が実行され、istioctl<Istio release dir>/bin サブディレクトリにあることを前提としています。

同じクラスタで asmcli を再実行すると、既存のコントロール プレーンの構成が上書きされます。同じ構成が必要な場合は、同じオプションとフラグを指定してください。

GKE Autopilot

GKE Autopilot は、Regular チャネルと Rapid チャネルの Anthos Service Mesh でのみサポートされています。クラスタにはバージョン 1.21.3 以降の GKE が必要です。GKE Autopilot リソースの上限に適応するために、デフォルトのプロキシ リソース リクエストと上限は 500m CPU と 512 Mb のメモリに設定される必要があります。Autopilot クラスタにはマネージド CNI が必要なため、--use_managed_cni フラグを含める必要があります。RELEASE_CHANNEL は、適切なチャネル(regularstablerapid)に置き換えます。

./asmcli install \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --managed \
    --verbose \
    --output_dir CLUSTER_NAME \
    --use_managed_cni \
    --channel RELEASE_CHANNEL \
    --enable-all

コントロール プレーンがプロビジョニングされていることを確認する

asmcli ツールは、クラスタに ControlPlaneRevision カスタム リソースを作成します。このリソースのステータスは、マネージド コントロール プレーンがプロビジョニングされるか、プロビジョニングに失敗すると更新されます。

リソースのステータスを調べます。NAME は、各チャネルに対応する値(asm-managedasm-managed-stable、または asm-managed-rapid)に置き換えます。

kubectl describe controlplanerevision NAME -n istio-system

出力は次のようになります。

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

調整条件により、マネージド コントロール プレーンが正常に動作しているかどうかを判断します。true の場合、コントロール プレーンは正常に実行されています。Stalled の場合は、マネージド コントロール プレーンのプロビジョニング プロセスでエラーが検出されたかどうか確認します。Stalled の場合、Message フィールドに特定のエラーに関する詳細情報が含まれています。発生する可能性があるエラーについて詳しくは、Stalled コードをご覧ください。

ゼロタッチのアップグレード

Google が管理するコントロール プレーンは、インストール後、新しいリリースやパッチが利用可能になると自動的にアップグレードされます。

コントロール プレーンがアップグレードされるたびに、データプレーンをアップグレードする必要はありません。コントロール プレーンはサポート ウィンドウ内ですべてのプロキシを引き続き使用しますが、最新のデータプレーン機能や修正、パフォーマンスの向上を利用する場合は、この方法をおすすめします。チャネル内の最新の公開プロキシ イメージにアップグレードするには、ローリング再起動を実行するか、必要に応じて自動的に再起動を促す Google 管理のデータプレーンを適用します。

マネージド データプレーンを適用する(省略可)

プロキシのアップグレードをすべて Google 側で管理するには、マネージド データプレーンを有効にします。有効にした場合、サイドカー プロキシと挿入されたゲートウェイは、ワークロードを再起動してプロキシの新しいバージョンを再挿入することで、マネージド コントロール プレーンと一緒に自動的に更新されます。無効になっている場合、プロキシ管理はクラスタ内の Pod の通常のライフサイクルに基づいて行われます。更新頻度を制御するには、ユーザーが手動でトリガーする必要があります。

マネージド データプレーンは、古いバージョンのプロキシを実行している Pod のエビクションを行うことで、プロキシをアップグレードします。エビクションは、Pod 停止予算を維持しながら変更率を制御することによって、段階的に行われます。

ここで注意することは、マネージド データプレーンには Istio Container Network Interface(CNI)プラグインが必要であり、これはマネージド コントロール プレーンをデプロイするときにデフォルトで有効であることです。

このマネージド データプレーンのプレビュー リリースでは、次のものは管理されません。

  • 挿入されなかった Pod
  • 手動で挿入された Pod
  • Job
  • StatefulSet
  • DaemonSet

マネージド データプレーンは、Rapid と Regular の両方のリリース チャネルで使用できます。

マネージド データプレーンを有効にするには:

  1. データプレーン管理を有効にします。

    kubectl annotate --overwrite namespace NAMESPACE \
    mesh.cloud.google.com/proxy='{"managed":"true"}'
    

    また、同じアノテーションを設定して、特定の Pod でマネージド データプレーンを有効にすることもできます。

  2. マネージド データプレーンを作成する名前空間ごとに、前の手順を繰り返します。

    サービスがクラスタ内のプロキシを管理する準備ができるまでに、10 分ほどかかることがあります。次のコマンドを実行してステータスを確認します。

    gcloud alpha container fleet mesh describe --project PROJECT_ID
    

    予想される出力

     membershipStates:
       projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
         servicemesh:
           dataPlaneManagement:
             details:
             - code: OK
               details: Service is running.
             state: ACTIVE
         state:
           code: OK
           description: 'Revision(s) ready for use: asm-managed-rapid.'
     ```
    

サービスの準備が 10 分以内に完了しない場合は、マネージド データプレーンのステータスで次の手順を確認してください。

マネージド データプレーンを無効にして、サイドカー プロキシの管理に戻す場合は、アノテーションを変更します。

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

メンテナンス通知を有効にする

メンテナンスが予定されている遅くとも 1 週間前に、メンテナンスの予定の通知を送信するようにリクエストできます。メンテナンス通知は、デフォルトでは送信されません。また、通知を受信するには、GKE メンテナンスの時間枠を構成する必要があります。

メンテナンス通知を受け取るには:

  1. [通信] ページに移動します。

    [通信] ページに移動

  2. [Anthos Service Mesh Upgrade] 行の [メール] 列で、メンテナンス通知をオンにするラジオボタンを選択します。

通知を受け取る必要があるユーザーごとに個別にオプトインできます。通知のメールフィルタを設定する場合、件名は次のようになります。

Upcoming upgrade for your ASM cluster "CLUSTER_LOCATION/CLUSTER_NAME"

エンドポイント ディスカバリを構成する(マルチクラスタ インストールのみ)

続行する前に、前の手順で説明したように各クラスタでマネージド Anthos Service Mesh を構成しておく必要があります。クラスタがプライマリ クラスタであることを示す必要はありません。これがデフォルトの動作です。エンドポイント ディスカバリを構成する前に、プロジェクトとクラスタ変数の設定ファイアウォール ルールの作成を完了する必要があります。

一般公開クラスタ

一般公開クラスタ間のエンドポイント ディスカバリを構成する

一般公開クラスタ(限定公開以外のクラスタ)で操作している場合は、一般公開クラスタ間のエンドポイント ディスカバリを構成することも、よりシンプルに一般公開クラスタ間のエンドポイント ディスカバリを有効にすることもできます。

限定公開クラスタ

限定公開クラスタ間のエンドポイント検出の構成

GKE の限定公開クラスタを使用する場合は、クラスタ コントロール プレーン エンドポイントを限定公開エンドポイントではなく、一般公開エンドポイントとして構成する必要があります。限定公開クラスタ間のエンドポイント検出の構成をご覧ください。

2 つのクラスタがあるサンプル アプリケーションについては、HelloWorld サービスの例をご覧ください。

アプリケーションのデプロイ

アプリケーションをデプロイするには、インストール時に構成したチャネルに対応するラベルを使用するか、istio-injection=enabled を使用します(デフォルトのインジェクション ラベルを使用している場合)。

デフォルトのインジェクション ラベル

kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite

リビジョン ラベル

アプリケーションをデプロイする前に、名前空間から以前の istio-injection ラベルを削除し、代わりに istio.io/rev=asm-managed-rapid ラベルを設定します。

別のリビジョン ラベルを使用している場合は、asm-managed-rapid をクリックし、該当するラベルに置き換えます(Regular の場合は asm-managed、Stable の場合は asm-managed-stable)。

リビジョン ラベルはリリース チャンネルに対応しています。

リビジョン ラベル チャネル
asm-managed Regular
asm-managed-rapid Rapid
asm-managed-stable Stable
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite

この時点では、Anthos Service Mesh のマネージド コントロール プレーンが正常に構成されています。マネージド データプレーンも適用している場合は、ワークロードを再起動します。それ以外の場合は、ローリング アップデートを実行します。これで、アプリケーションをデプロイする準備が整い、Bookinfo サンプル アプリケーションをデプロイできます。

マルチクラスタ設定にアプリケーションをデプロイする場合、その特定の構成ファイルをクラスタの一部に制限する予定がなければ、すべてのクラスタに Kubernetes とコントロール プレーンの構成を複製します。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。また、Mesh CA が他の名前空間にある状態で、このクラスタが Anthos Service Mesh または Certificate Authority Service を実行している場合、アプリケーションが、クラスタ内コントロール プレーンによって制御される他のアプリケーションと通信できることを確認します。

コントロール プレーンの指標の確認

コントロール プレーンとデータプレーンのバージョンは、Metrics Explorer で確認できます。

構成が正しく機能することを確認するには:

  1. コンソールでコントロール プレーンの指標を表示します。

    Metrics Explorer に移動

  2. ワークスペースを選択し、次のパラメータを使用してカスタムクエリを追加します。

    • Resource type: Kubernetes Container
    • Metric: Proxy Clients
    • Filter: container_name="cr-REVISION_LABEL"
    • Group By: revision ラベルと proxy_version ラベル
    • Aggregator sum
    • Period: 1 minute

    Google マネージドのコントロール プレーンとクラスタ内コントロール プレーンの両方で Anthos Service Mesh を実行する場合は、そのコンテナ名を使用してそれぞれの指標を区別できます。たとえば、マネージド指標には container_name="cr-asm-managed" が含まれ、非マネージド指標には container_name="discovery" が含まれます。両方の指標を表示するには、container_name="cr-asm-managed" の Filter を削除します。

  3. Metrics Explorer で次のフィールドを調べて、コントロール プレーンとプロキシのバージョンを確認します。

    • [revision] は、コントロール プレーンのバージョンを示します。
    • [proxy_version] は proxy_version を示します。
    • [value] は、接続されたプロキシの数を示します。

    現在のチャンネルと Anthos Service Mesh バージョンのマッピングについては、チャンネルごとの Anthos Service Mesh のバージョンをご覧ください。

アプリケーションをマネージド Anthos Service Mesh に移行する

マネージド Anthos Service Mesh に移行するには、次の手順を行います。

  1. Google 管理のコントロール プレーンを適用するの手順に沿ってツールを実行します。

  2. (省略可)Google が管理するデータプレーンを使用する場合は、データプレーンの管理を有効にします。

    kubectl annotate --overwrite namespace NAMESPACE \
    mesh.cloud.google.com/proxy='{"managed":"true"}'
    
  3. (省略可)Google が管理するデータプレーンを使用する場合は、フリートで Anthos Service Mesh を有効にします。

    gcloud alpha container hub mesh enable --project=PROJECT_ID
    
  4. 現在の名前空間のラベルを置き換えます。必要な手順は、デフォルトのインジェクション ラベルistio-injection enabled など)またはリビジョン ラベルをご覧ください。

    デフォルトのインジェクション ラベル

    1. 次のコマンドを実行して、デフォルトタグをマネージド リビジョンに移動します。

      istioctl tag set default --revision MCP_RELEASE_CHANNEL
      
    2. まだ実行していない場合は、次のコマンドを実行し、istio-injection=enabled を使用して名前空間にラベルを付けます。

      kubectl label namespace NAMESPACE istio-injection=enabled \
      --overwrite
      

    リビジョン ラベル

    istio.io/rev=asm-managed-rapid ラベルを使用した場合は、次のコマンドを実行します。

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
        --overwrite
    
  5. 名前空間で Deployment のローリング アップグレードを実行します。

    kubectl rollout restart deployment -n NAMESPACE
    
  6. アプリケーションをテストして、ワークロードが正しく機能することを確認します。

  7. 他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。

  8. マルチクラスタ設定にアプリケーションをデプロイした場合は、すべてのクラスタに Kubernetes と Istio の構成を複製します。ただし、その構成をクラスタの一部に制限する場合を除きます。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。

  9. コントロール プレーンの指標の確認の手順に沿って、指標が想定どおりに表示されることを確認します。

アプリケーションが想定どおりに動作していることを確認したら、すべての名前空間をクラスタ内コントロール プレーンに切り替えた後でクラスタ内 istiod を削除するか、バックアップとして保持できます。istiod は、自動的にスケールダウンして使用するリソースを減らします。削除するには、古いコントロール プレーンの削除に進みます。

問題が発生した場合は、マネージド コントロール プレーンの問題を解決するを参照して問題を特定し、解決します。また、必要であれば以前のバージョンにロールバックできます。

古いコントロール プレーンを削除する

すべての名前空間で Google 管理のコントロール プレーンが使用されていることを確認したら、古いコントロール プレーンを削除できます。

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

自動インジェクションではなく istioctl kube-inject を使用した場合や、追加のゲートウェイをインストールした場合は、コントロール プレーンの指標をチェックし、接続されているエンドポイントの数がゼロであることを確認します。

ロールバック

前のコントロール プレーン バージョンにロールバックする必要がある場合は、次の手順を行います。

  1. コントロール プレーンの以前のバージョンで挿入されるワークロードを更新します。次のコマンドのリビジョン値 asm-191-1 はサンプルとして使用されています。このサンプル値は、前のコントロール プレーンのリビジョン ラベルに置き換えてください。

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE
    

未使用時は、マネージド コントロール プレーンは自動的にゼロへスケーリングされ、リソースを使用しません。Webhook の変更とプロビジョニングはそのまま残り、クラスタの動作には影響しません。

これでゲートウェイが asm-managed リビジョンに設定されました。ロールバックするには、Anthos Service Mesh のインストール コマンドを再実行します。これにより、クラスタ内コントロール プレーンを参照するゲートウェイが再デプロイされます。

kubectl -n istio-system rollout undo deploy istio-ingressgateway

正常に実行されると、次の出力が表示されます。

deployment.apps/istio-ingressgateway rolled back

アンインストール

名前空間が使用されていない場合、Google 管理のコントロール プレーンは自動的にゼロにスケールされます。詳細な手順については、Anthos Service Mesh をアンインストールするをご覧ください。

トラブルシューティング

マネージド コントロール プレーンを使用する際の問題を特定して解決するには、マネージド コントロール プレーンの問題を解決するをご覧ください。

ControlPlaneRevision の Stalled コード

ControlPlaneRevisions ステータスで Stalled 条件が true になる理由はいくつか考えられます。

理由 メッセージ 説明
PreconditionFailed GKE メンバーシップのみがサポートされていますが、${CLUSTER_NAME} は GKE クラスタではありません。 現在のクラスタは GKE クラスタではないようです。マネージド コントロール プレーンは GKE クラスタ上でのみ機能します。
サポートされていない ControlPlaneRevision 名: ${NAME} ControlPlaneRevision の名前は、次のいずれかにする必要があります。
  • asm-managed
  • asm-managed-rapid
  • asm-managed-stable
サポートされていない ControlPlaneRevision Namespace: ${NAMESPACE} ControlPlaneRevision の Namespace は istio-system である必要があります。
${NAME} の ControlPlaneRevision に対してサポートされていないチャネル: ${CHANNEL}想定される ${OTHER_CHANNEL} ControlPlaneRevision の名前は、以下の ControlPlaneRevision のチャンネルと一致する必要があります。
  • asm-managed -> regular
  • asm-managed-rapid -> rapid
  • asm-managed-stable -> stable
チャンネルは省略できません。空白にすることもできません Channel は、ControlPlaneRevision の必須フィールドです。カスタム リソースがないか、空白になっています。
サポートされていないコントロール プレーン リビジョン タイプ: ${TYPE} managed_service は、ControlPlaneRevisionType フィールドの唯一の許可フィールドです。
サポートされていない Kubernetes バージョン: ${VERSION} Kubernetes バージョン 1.15 以降がサポートされています。
Workload Identity が有効になっていません クラスタで Workload Identity を有効にしてください。
サポートされていないワークロード プール: ${POOL} ワークロード プールは ${PROJECT_ID}.svc.id.goog の形式にする必要があります。
クラスタ プロジェクトと環境プロジェクトが一致しません クラスタは、フリートに登録されているプロジェクトの一部にする必要があります。
ProvisioningFailed クラスタ リソースの更新中にエラーが発生しました Google は CRD や Webhook などのクラスタ内リソースを更新できませんでした。
MutatingWebhookConfiguration「istiod-asm-managed」には、${EXISTING_URL} という URL の Webhook が含まれていますが、${EXPECTED_URL} が想定されています インストールが中断されないように、Google は既存の Webhook を上書きしません。この動作が必要な場合は、手動で更新してください。
ValidatingWebhookConfiguration ${NAME} には URL が ${EXISTING_URL} の Webhook が含まれていますが、${EXPECTED_URL} が想定されています インストールが中断されないように、Google は既存の Webhook を上書きしません。この動作が必要な場合は、手動で更新してください。

次のステップ