マネージド Anthos Service Mesh をプロビジョニングする

有効にする必要がある Google のマネージドサービスメッシュは、マネージド Anthos Service Mesh のみです。信頼性、アップグレード、スケーリング、セキュリティについては Google が下位互換性のある方法で対応します。

このページでは、フリート機能の API を使用してマネージド Anthos Service Mesh を設定する方法について説明します。

Fleet API を使用してマネージド Anthos Service Mesh を有効にする場合:

Google が推奨のコントロールプレーン構成を適用します。
Google が自動データプレーン管理を有効にします。
クラスタは Google Kubernetes Engine（GKE）クラスタのリリースチャンネルに基づいて Anthos Service Mesh リリースチャンネルに登録され、コントロールプレーンとデータプレーンは新しいリリースごとに最新の状態に保たれます。
Google では、サービスメッシュ全体でエンドポイントの検出とクラスタ間のロードバランシングをデフォルトで有効にしていますが、ファイアウォールルールを作成する必要があります。

必要な場合は、次のオンボーディングパスを使用してください。

gcloud を使用して、Google Cloud APIs と IAM を使用するマネージド Anthos Service Mesh を構成する。
他のフリート機能と同じ API を使用して Anthos Service Mesh を構成する。
各クラスタの推奨の Anthos Service Mesh の構成を自動的に取得する。

前提条件

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

Cloud プロジェクト
Cloud 請求先アカウント
マネージド Anthos Service Mesh をプロビジョニングするために必要な権限を取得している。
クラスタで Workload Identity を有効にしている。

要件

サポートされているいずれかのリージョンで、サポート対象バージョンの GKE を使用している 1 つ以上のクラスタ。
マネージド Anthos Service Mesh がクラスタにインストールする必要なコンポーネントに十分な容量がクラスタに存在することを確認します。
- kube-system 名前空間内の mdp-controller デプロイは、CPU: 50m、メモリ: 128Mi をリクエストします。
- kube-system 名前空間内の istio-cni-node DaemonSet は、各ノードに対して CPU: 100m、メモリ: 100Mi をリクエストします。
マネージド Anthos Service Mesh をプロビジョニングするクライアントマシンと API サーバーとのネットワーク接続を確認します。
クラスタは、フリートに登録されている必要があります。この操作は、プロビジョニングの前に個別に行うこともできます。
プロジェクトでサービスメッシュフリート機能が有効になっている必要があります。この操作は個別に行うこともできます。
GKE Autopilot は、GKE バージョン 1.21.3 以降でのみサポートされています。
Istio CNI が必要であるため、マネージド Anthos Service Mesh をプロビジョニングする際、デフォルトでインストールされます。
マネージド Anthos Service Mesh では、単一プロジェクトの単一ネットワーク環境または複数プロジェクトの単一ネットワーク環境で複数の GKE クラスタを使用できます。
- 異なるプロジェクトのクラスタを追加する場合は、同じフリートホストプロジェクトにクラスタを登録する必要があります。また、共有 VPC 構成でクラスタを同じネットワークに接続する必要があります。
- 単一プロジェクトマルチクラスタ環境では、フリートプロジェクトはクラスタプロジェクトと同じにできます。フリートの詳細については、フリートの概要をご覧ください。
- マルチプロジェクト環境では、クラスタプロジェクトとは別のプロジェクトでフリートをホストすることをおすすめします。組織のポリシーと既存の構成で許可されている場合は、共有 VPC プロジェクトをフリートホストプロジェクトとして使用することをおすすめします。詳細については、共有 VPC を使用したクラスタの設定をご覧ください。
- 組織で VPC Service Controls を使用していて、さらにGKE クラスタでマネージド Anthos Service Mesh をプロビジョニングする場合は、次の手順に沿って操作します。Anthos Service Mesh の VPC Service Controls。

制限事項

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

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

注: IstioOperator API を使用せずにオプション機能を有効にすることもできます。詳しくは、マネージド Anthos Service Mesh でオプション機能を有効にするをご覧ください。asmcli に含まれる移行ツールを使用して、他の IstioOperator オプション機能を自動的に変換し、マネージドコントロールプレーンとの互換性を持たせることもできます。詳細については、IstioOperator から移行するをご覧ください。
Fleet API でマネージド Anthos Service Mesh を有効にすると、Mesh CA が使用されます。サービスメッシュデプロイに規制対象のワークロードが含まれている場合や、Certificate Authority Service（CA Service）が必要な場合は、asmcli を使用したマネージド Anthos Service Mesh のプロビジョニングをご覧ください。
asmcli を含むマネージド Anthos Service Mesh から Fleet API を含む Anthos Service Mesh への移行はサポートされていません。同様に、Fleet API を含むマネージド Anthos Service Mesh の --management manual から --management automatic への構成はサポートされていません。
GKE Autopilot クラスタの場合、プロジェクト間の設定は GKE 1.23 以降でのみサポートされます。
GKE Autopilot クラスタの場合、GKE Autopilot リソースの上限に適応するために、デフォルトのプロキシリソースのリクエストと上限は 500m CPU と 512 MB メモリに設定されています。カスタムインジェクションを使用して、デフォルト値をオーバーライドできます。
マネージド Anthos Service Mesh で利用できる実際の機能は、リリースチャンネルによって異なります。詳細については、マネージド Anthos Service Mesh でサポートされている機能と制限事項のリストをご覧ください。
マネージドコントロールプレーンのプロビジョニングプロセス中に、選択したチャネルに対応する Istio CRD が指定のクラスタにプロビジョニングされます。クラスタに既存の Istio CRD が存在している場合、それらは上書きされます。
Istio CNI は、GKE Sandbox と互換性がありません。Autopilot のマネージド Anthos Service Mesh は、マネージド Istio CNI を必要とするため、GKE Sandbox では使用できません。

準備

Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

gcloud を構成します（Cloud Shell を使用している場合も同様です）。

Google Cloud CLI で認証します。ここで、FLEET_PROJECT_ID はフリートホストプロジェクトの ID です。一般に、FLEET_PROJECT_ID はデフォルトで作成され、プロジェクトと同じ名前が設定されています。
```
       gcloud auth login --project FLEET_PROJECT_ID
```
コンポーネントを更新します。
```
       gcloud components update
```

フリートホストプロジェクトで必要な API を有効にします。

  gcloud services enable mesh.googleapis.com \
      --project=FLEET_PROJECT_ID

mesh.googleapis.com を有効にして API を有効にする

API	目的	無効化が可能か
`meshconfig.googleapis.com`	Anthos Service Mesh は、Mesh Configuration API を使用して、メッシュから Google Cloud に構成データをリレーします。また、Mesh Configuration API を有効にすると、Google Cloud コンソールの Anthos Service Mesh のページにアクセスして、Anthos Service Mesh 認証局（Mesh CA）を使用できます。	×
`meshca.googleapis.com`	マネージド Anthos Service Mesh で使用される Anthos Service Mesh 認証局に関連します。	×
`container.googleapis.com`	Google Kubernetes Engine（GKE）クラスタを作成するために必要です。	×
`gkehub.googleapis.com`	メッシュをフリートとして管理するために必要です。	×
`monitoring.googleapis.com`	メッシュワークロードのテレメトリーをキャプチャするために必要です。	×
`stackdriver.googleapis.com`	Service UI を使用するために必要です。	×
`opsconfigmonitoring.googleapis.com`	Google Cloud 外のクラスタで Service UI を使用するために必要です。	×
`connectgateway.googleapis.com`	マネージド Anthos Service Mesh コントロールプレーンがメッシュワークロードにアクセスできるようにするために必要です。	○*
`trafficdirector.googleapis.com`	高可用性でスケーラブルなマネージドコントロールプレーンを実現します。	○*
`networkservices.googleapis.com`	高可用性でスケーラブルなマネージドコントロールプレーンを実現します。	○*
`networksecurity.googleapis.com`	高可用性でスケーラブルなマネージドコントロールプレーンを実現します。	○*

警告: connectgateway.googleapis.com、trafficdirector.googleapis.com、networkservices.googleapis.com、networksecurity.googleapis.com を無効にすると、マネージド Anthos Service Mesh コントロールプレーンが機能しなくなります。フリートが任意のクラスタでマネージド Anthos Service Mesh を使用しない場合は、この API を無効にできます。

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

Fleet API を使用してマネージド Anthos Service Mesh をプロビジョニングするために必要な手順は、新しいフリートクラスタのデフォルトで有効にするか、クラスタごとに有効にするで異なります。

フリート用に構成する

Google Kubernetes Engine（GKE）Enterprise エディションを有効にしている場合は、フリートのデフォルト構成としてマネージド Anthos Service Mesh を有効にできます。つまり、クラスタの作成時に登録された Google Cloud クラスタ上の新しい GKE ではすべて、クラスタでマネージド Anthos Service Mesh が有効になります。フリートのデフォルト構成の詳細については、フリートレベルの機能を管理するをご覧ください。

マネージド Anthos Service Mesh のフリートレベルのデフォルトを有効にするには、次の手順を行います。

コンソール

Google Cloud コンソールで、[機能マネージャー] ページに移動します。

機能マネージャーに移動
[サービスメッシュ] ペインで、[構成] をクリックします。
Google Cloud コンソールで作成し、フリートに登録するすべての新しいクラスタによって継承される設定を確認します。

注: これらの設定は、Anthos Service Mesh を使用するための前提条件である GKE の設定です。
これらの設定を適用するには、[構成] をクリックします。
確認のダイアログで [確認] をクリックします。
省略可: 既存のクラスタをデフォルト設定と同期します。
1. [フリート内のクラスタ] リストで、同期するクラスタを選択します。選択できるのは、Anthos Service Mesh がインストールされているクラスタのみです。
2. [フリートの設定に同期] をクリックし、表示される確認ダイアログで [確認] をクリックします。このオペレーションには数分かかることがあります。

gcloud

Google Cloud CLI を使用してフリートレベルのデフォルトを構成するには、次の設定を確立する必要があります。

フリートレベルの設定

1 行 management: automatic のみを含む mesh.yaml ファイルを作成します。
```
echo "management: automatic" > mesh.yaml
```

フリートで Anthos Service Mesh を有効にします。

gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
    --fleet-default-member-config mesh.yaml

次のエラーが表示された場合は、GKE Enterprise を有効にする必要があります。

ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
[anthos.googleapis.com] service is required for this operation and is not
enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
Console to enable it.: failed precondition

クラスタレベルの設定
- Anthos Service Mesh で使用するクラスタを作成する準備ができたら、デフォルトの構成を使用する Google Cloud CLI で、単一のステップで作成および登録します。次に例を示します。
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  フリートプロジェクトのプロジェクト番号を取得するには、次のコマンドを実行します。
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  --location フラグは、クラスタのコンピューティングゾーンまたはリージョン（us-central1-a、us-central1 など）です。
- クラスタのプロジェクトがフリートホストプロジェクトと異なる場合は、フリートプロジェクトの Anthos Service Mesh サービスアカウントにクラスタプロジェクトへのアクセスを許可し、クラスタプロジェクトで必要な API を有効にする必要があります。この手順は、クラスタプロジェクトごとに 1 回だけ行う必要があります。
  
  フリートプロジェクトのサービスアカウントに、クラスタプロジェクトにアクセスするための権限を付与します。
```
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
  クラスタのプロジェクトで Mesh API を有効にします。
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```
  CLUSTER_PROJECT_ID は、クラスタプロジェクトの一意の識別子に置き換えます。フリートと同じプロジェクトにクラスタを作成した場合、CLUSTER_PROJECT_ID は FLEET_PROJECT_ID と同じです。

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

クラスタごとに構成する

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

Anthos Service Mesh のフリート機能を有効にする

フリートで Anthos Service Mesh を有効にします。複数のクラスタを登録する場合、Anthos Service Mesh の有効化はフリートレベルで行われるため、このコマンドを実行する必要があるのは 1 回だけです。

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

クラスタのフリートへの登録

フリートの Workload Identity を使用して GKE クラスタを登録します。--location フラグは、クラスタのコンピューティングゾーンまたはリージョン（us-central1-a、us-central1 など）です。
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

クラスタが登録されていることを確認します。

gcloud container fleet memberships list --project FLEET_PROJECT_ID

出力例:

NAME                 EXTERNAL_ID                           LOCATION
cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1

自動管理を有効にするときに必要になるため、MEMBERSHIP_NAME をメモしておきます。

クラスタのプロジェクトがフリートホストプロジェクトと異なる場合は、フリートプロジェクトの Anthos Service Mesh サービスアカウントにクラスタプロジェクトへのアクセスを許可し、クラスタプロジェクトで必要な API を有効にする必要があります。この手順は、クラスタプロジェクトごとに 1 回だけ行う必要があります。

以前に asmcli を使用して、このクラスタとフリートプロジェクトの組み合わせに対してマネージド Anthos Service Mesh を構成していた場合、これらの変更はすでに適用されているため、次のコマンドを実行する必要はありません。

フリートプロジェクトのサービスアカウントに、クラスタプロジェクトにアクセスするための権限を付与します。
```
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
  --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
  --role roles/anthosservicemesh.serviceAgent
```
クラスタのプロジェクトで Mesh API を有効にします。
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```

自動管理を有効にする

自動管理を有効にするには、次のコマンドを実行します。

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

ここで

MEMBERSHIP_NAME は、クラスタがフリートに登録されたことを確認したときに表示されるメンバーシップ名です。
MEMBERSHIP_LOCATION は、メンバーシップのロケーションです（リージョンまたは global）。

このガイドのコマンドを使用してメンバーシップを最近作成した場合は、クラスタのリージョンにする必要があります。ゾーンクラスタがある場合は、クラスタのゾーンに対応するリージョンを使用します。たとえば、us-central1-c にゾーンクラスタがある場合は、値 us-central1 を使用します。

2023 年 5 月より前に登録した場合や、メンバーシップの登録時に global を指定した場合、この値は global になります。メンバーシップのロケーションは gcloud container fleet memberships list --project FLEET_PROJECT_ID で確認できます。

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

数分後、コントロールプレーンのステータスが ACTIVE になっていることを確認します。

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

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

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

details フィールドのリビジョンラベルをメモします（出力の asm-managed など）。リビジョンラベルを使用している場合は、アプリケーションをデプロイする前に、このラベルを設定する必要があります。デフォルトのインジェクションラベルを使用している場合、このラベルを設定する必要はありません。

クラスタを参照するように `kubectl` を構成します。

以下の各セクションでは、各クラスタに対して kubectl コマンドを実行します。以下の各セクションに進む前に、各クラスタに対して次のコマンドを実行して、クラスタを参照するように kubectl を構成します。

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

Ingress ゲートウェイはコントロールプレーンで自動的にはデプロイされないことに注意してください。Ingress ゲートウェイとコントロールプレーンのデプロイを分離すると、本番環境でゲートウェイを簡単に管理できます。クラスタに Ingress ゲートウェイまたは Egress ゲートウェイが必要な場合は、ゲートウェイをデプロイするをご覧ください。他のオプション機能を有効にするには、マネージド Anthos Service Mesh でオプション機能を有効にするをご覧ください。

マネージドデータプレーン

マネージド Anthos Service Mesh を使用している場合、名前空間、ワークロード、リビジョンレベルでプロキシを無効にしない限り、Google がプロキシのアップグレードを完全に管理します。

マネージドデータプレーンが有効な場合、サイドカープロキシと挿入されたゲートウェイは、ワークロードを再起動してプロキシの新しいバージョンを再挿入することで、マネージドコントロールプレーンとともに自動的に更新されます。これは通常、マネージドコントロールプレーンがアップグレードされてから 1～2 週間後に完了します。

無効になっている場合、プロキシ管理はクラスタ内の Pod の通常のライフサイクルに基づいて行われます。更新頻度を制御するには、ユーザーが手動でトリガーする必要があります。

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

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

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

マネージドデータプレーンを無効にする（省略可）

新しいクラスタにマネージド Anthos Service Mesh をプロビジョニングする場合は、マネージドデータプレーンを完全に無効にすることも、個々の名前空間や Pod に対して無効にすることもできます。既存のクラスタがデフォルトで無効になっている場合、または手動で無効にした場合、マネージドデータプレーンは引き続き無効になります。

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

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Namespace 名のマネージドデータプレーンを無効にするには:

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

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

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

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

マネージドデータプレーンのメンテナンスが予定されている遅くとも 1 週間前に、メンテナンスの予定の通知を送信するようにリクエストできます。メンテナンス通知は、デフォルトでは送信されません。また、通知を受信するには、GKE メンテナンスの時間枠を構成する必要があります。有効にすると、アップグレードオペレーションの少なくとも 2 日前に通知が送信されます。

マネージドデータプレーンのメンテナンス通知を有効にするには:

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

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

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

Upcoming upgrade for your Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"。

次の例に、一般的なマネージドデータプレーンのメンテナンス通知を示します。

件名: ASM クラスタ「<location/cluster-name>」のアップグレードの予定

Anthos Service Mesh をご利用のお客様

クラスタ ${instance_id}（https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}）の Anthos Service Mesh コンポーネントのアップグレードが、${scheduled_date_human_readable} の ${scheduled_time_human_readable} に予定されています。

新しい更新内容については、リリースノート（https://cloud.google.com/service-mesh/docs/release-notes）をご覧ください。

このメンテナンスがキャンセルされた場合は、別途メールが届きます。

何卒よろしくお願い申し上げます。

Anthos Service Mesh チーム

(c) 2022 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 このサービスに関するお知らせは、Google Cloud Platform やアカウントの重要な変更についてお知らせするものです。メンテナンスの時間枠の通知をオプトアウトするには、ユーザー設定（https://console.cloud.google.com/user-preferences/communication?project=${project_id}）を編集してください。

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

続行する前に、前の手順で説明したように各クラスタでマネージド Anthos Service Mesh を構成しておく必要があります。クラスタがプライマリクラスタであることを示す必要はありません。これがデフォルトの動作です。

また、asmcli をダウンロードし（サンプルアプリケーションで構成を確認する場合のみ）、プロジェクト変数とクラスタ変数を設定します。

一般公開クラスタ

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

Fleet API でマネージド Anthos Service Mesh を有効にすると、このクラスタのエンドポイント検出が有効になります。ただし、ファイアウォールのポートを開く必要があります。1 つ以上のクラスタのエンドポイント検出を無効にするには、宣言型 API を使用した一般公開クラスタ間のエンドポイント検出で、無効にする手順をご覧ください。

限定公開クラスタ

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

Fleet API でマネージド Anthos Service Mesh を有効にすると、このクラスタのエンドポイント検出が有効になります。ただし、ファイアウォールのポートを開く必要があります。1 つ以上のクラスタのエンドポイント検出を無効にするには、宣言型 API を使用した限定公開クラスタ間のエンドポイント検出で無効にする手順をご覧ください。

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

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

マネージド Anthos Service Mesh を使用するフリートに複数のクラスタがある場合は、アプリケーションの処理とデプロイの前に、エンドポイントディスカバリまたはファイアウォールポートが意図したとおりに構成されていることを確認してください。

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

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

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

リビジョンラベル

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

これは、コントロールプレーンを確認したときに特定したリビジョンラベルです。特定のリビジョンラベルに変更するには、REVISION_LABEL をクリックし、該当するラベル（Rapid の場合は asm-managed-rapid、Regular の場合は asm-managed、Stable の場合は asm-managed-stable）に置き換えます。

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

リビジョンラベル	チャネル
`asm-managed`	標準
`asm-managed-rapid`	迅速
`asm-managed-stable`	Stable

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

この時点では、マネージド Anthos Service Mesh が正常に構成されています。ラベル付きの名前空間に既存のワークロードがある場合は、それらを再起動してプロキシが挿入されるようにします。

これで、アプリケーションをデプロイする準備が整い、Bookinfo サンプルアプリケーションをデプロイできます。

マルチクラスタ設定にアプリケーションをデプロイする場合、その特定の構成ファイルをクラスタの一部に制限する予定がなければ、すべてのクラスタに Kubernetes とコントロールプレーンの構成を複製します。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。

インジェクションをカスタマイズする（省略可）

Pod ごとの構成を使用して、個々の Pod でこれらのオプションをオーバーライドできます。これを行うには、istio-proxy コンテナを Pod に追加します。サイドカーインジェクションでは、ここで定義された構成はデフォルトのインジェクションテンプレートのオーバーライドとして扱われます。

たとえば、次の構成では、CPU リクエストの削減、ボリュームマウントの追加、preStop フックの追加など、さまざまな設定をカスタマイズできます。

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limites:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

一般に、Pod 内の任意のフィールドを設定できます。ただし、特定のフィールドには注意が必要です。

Kubernetes では、インジェクションの実行前に image フィールドを設定する必要があります。特定のイメージを設定してデフォルトをオーバーライドできますが、image を auto に設定することをおすすめします。これにより、サイドカーインジェクタで使用するイメージが自動的に選択されます。
containers の一部のフィールドは、関連する設定に依存しています。たとえば、CPU リクエストは CPU の上限よりも小さくする必要があります。両方のフィールドが正しく構成されていないと、Pod の起動に失敗することがあります。
Kubernetes では、PodSpec のリソースに requests と limits の両方を設定できます。GKE Autopilot では requests のみが考慮されます。詳細については、Autopilot でのリソース制限の設定をご覧ください。

また、特定のフィールドは Pod のアノテーションで構成できますが、上記の方法で設定をカスタマイズすることをおすすめします。特定のアノテーションについてはさらに注意が必要です。

GKE Standard で sidecar.istio.io/proxyCPU が設定されている場合は、sidecar.istio.io/proxyCPULimit を明示的に設定してください。そうでないと、サイドカーの CPU 上限が無制限に設定されます。
GKE Standard で sidecar.istio.io/proxyMemory が設定されている場合は、sidecar.istio.io/proxyMemoryLimit を明示的に設定してください。そうしないと、サイドカーのメモリ上限が無制限に設定されます。
GKE Autopilot でアノテーションを使用してリソース requests と limits を構成すると、リソースがオーバープロビジョニングされる可能性があります。これを避けるには、イメージテンプレート方式を使用します。Autopilot のリソース変更の例をご覧ください。

たとえば、次のリソースのアノテーション構成をご覧ください。

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

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

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

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

Google Cloud コンソールで、コントロールプレーンの指標を確認します。

Metrics Explorer に移動
ワークスペースを選択し、次のパラメータを使用してカスタムクエリを追加します。
- 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 を削除します。
Metrics Explorer で次のフィールドを調べて、コントロールプレーンとプロキシのバージョンを確認します。
- [revision] は、コントロールプレーンのバージョンを示します。
- [proxy_version] は proxy_version を示します。
- [value] は、接続されたプロキシの数を示します。
現在のチャンネルと Anthos Service Mesh バージョンのマッピングについては、チャンネルごとの Anthos Service Mesh のバージョンをご覧ください。

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

クラスタ内 Anthos Service Mesh からマネージド Anthos Service Mesh にアプリケーションを移行するには、次の手順を行います。

現在の名前空間のラベルを置き換えます。必要な手順は、デフォルトのインジェクションラベル（istio-injection enabled など）またはリビジョンラベルをご覧ください。
デフォルトのインジェクションラベル
1. 次のコマンドを実行して、デフォルトタグをマネージドリビジョンに移動します。
```
istioctl tag set default --revision REVISION_LABEL
```
2. まだ実行していない場合は、次のコマンドを実行し、istio-injection=enabled を使用して名前空間にラベルを付けます。
```
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \
--overwrite
```
リビジョンラベル
istio.io/rev=REVISION_LABEL ラベルを使用した場合は、次のコマンドを実行します。
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
    --overwrite
```
名前空間で Deployment のローリングアップグレードを実行します。
```
kubectl rollout restart deployment -n NAMESPACE
```
アプリケーションをテストして、ワークロードが正しく機能することを確認します。
他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。
マルチクラスタ設定にアプリケーションをデプロイした場合は、すべてのクラスタに Kubernetes と Istio の構成を複製します。ただし、その構成をクラスタの一部に制限する場合を除きます。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。
コントロールプレーンの指標の確認の手順に沿って、指標が想定どおりに表示されることを確認します。

アプリケーションが期待どおりに動作していることを確認したら、すべての名前空間をマネージドコントロールプレーンに切り替えた後にクラスタ内の istiod を削除できます。また、これらをバックアップとして残すこともできます。この場合、istiod が自動的にスケールダウンし、リソースの使用量が少なくなります。削除するには、古いコントロールプレーンの削除に進みます。

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

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

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

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

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

ロールバック

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

コントロールプレーンの以前のバージョンで挿入されるワークロードを更新します。次のコマンドのリビジョン値 asm-191-1 はサンプルとして使用されています。このサンプル値は、前のコントロールプレーンのリビジョンラベルに置き換えてください。
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
プロキシが 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

Anthos Service Mesh をアンインストールする

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

トラブルシューティング

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

次のステップ

次のようなオプションのマネージド Anthos Service Mesh 機能を有効にする方法を確認する。
トランスポートセキュリティを構成してメッシュを保護する。

マネージド Anthos Service Mesh をプロビジョニングする

前提条件

要件

制限事項

準備

mesh.googleapis.com を有効にして API を有効にする

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

フリート用に構成する

コンソール

gcloud

クラスタごとに構成する

Anthos Service Mesh のフリート機能を有効にする

クラスタのフリートへの登録

自動管理を有効にする

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

クラスタを参照するように kubectl を構成します。

マネージド データプレーン

マネージド データプレーンを無効にする（省略可）

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

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

一般公開クラスタ

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

限定公開クラスタ

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

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

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

リビジョン ラベル

インジェクションをカスタマイズする（省略可）

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

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

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

リビジョン ラベル

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

ロールバック

Anthos Service Mesh をアンインストールする

トラブルシューティング

次のステップ

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

クラスタを参照するように `kubectl` を構成します。

マネージドデータプレーン

マネージドデータプレーンを無効にする（省略可）

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

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

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

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

リビジョンラベル

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

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

リビジョンラベル

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