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

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

GKE でマネージド Cloud Service Mesh コントロールプレーンをプロビジョニングする

Cloud Service Mesh は、簡単に有効にできる Google のマネージドサービスメッシュです。Google がお客様に代わって、信頼性、アップグレード、スケーリング、セキュリティに対応します。

このページでは、Fleet API を使用して、Istio API を使用したマネージド Cloud Service Mesh を設定する方法について説明します。

前提条件

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

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

要件

サポートされているいずれかのリージョンで、サポート対象バージョンの GKE を使用している 1 つ以上のクラスタ。
マネージド Cloud Service Mesh は、GKE リリースチャンネルを使用して、安定性とアップグレードの速度のバランスを取ります。Cloud Service Mesh クラスタ内コンポーネント（CNI、MDPC、プロキシ、Istio CRD など）への新しい変更は、GKE Rapid チャンネルをサブスクライブするクラスタに最初にロールアウトされます。その後、クラスタは GKE Regular チャンネルに昇格し、十分な安定性が確認されると最終的に GKE Stable チャンネルに昇格します。
- フリートクラスタのサブセットを初期の GKE リリースチャンネルでプロビジョニングして、Cloud Service Mesh コンポーネントの更新を最初に受け取るようにすることをおすすめします。
- マネージド Cloud Service Mesh では、GKE リリースチャンネルを変更することはできません。
- GKE リリースチャンネルを変更しても、Cloud Service Mesh はオペレーションを妨げません。Cloud Service Mesh は、現在の GKE リリースチャンネルに合わせてクラスタ内コンポーネント（CNI、MDPC、デフォルトの挿入されたプロキシバージョン、Istio CRD）を自動的に更新します。
マネージド Cloud Service Mesh がクラスタに必須のコンポーネントをインストールするために十分な容量がクラスタに存在することを確認します。
- kube-system Namespace 内の mdp-controller Deployment は、CPU: 50m、メモリ: 128Mi をリクエストします。
- kube-system 名前空間内の istio-cni-node DaemonSet は、各ノードに対して CPU: 100m、メモリ: 100Mi をリクエストします。
組織のポリシー constraints/compute.disableInternetNetworkEndpointGroup が無効になっていることを確認します。このポリシーが有効になっている場合、ServiceEntry が機能しないことがあります。
マネージド Cloud Service Mesh をプロビジョニングするクライアントマシンと API サーバーとのネットワーク接続を確認します。
クラスタは、フリートに登録されている必要があります。プロビジョニング前に登録されていない場合は、手順の中で行うこともできます。
プロジェクトで Service Mesh のフリート機能が有効になっている必要があります。まだ有効にしていない場合は、手順の中で行うこともできます。
GKE Autopilot は、GKE バージョン 1.21.3 以降でのみサポートされています。
Cloud Service Mesh では、単一プロジェクトの単一ネットワーク環境または複数プロジェクトの単一ネットワーク環境で複数の GKE クラスタを使用できます。
- 異なるプロジェクトのクラスタを追加する場合は、同じフリートホストプロジェクトにクラスタを登録する必要があります。また、共有 VPC 構成でクラスタを同じネットワークに接続する必要があります。
- 単一プロジェクトマルチクラスタ環境では、フリートプロジェクトはクラスタプロジェクトと同じにできます。フリートの詳細については、フリートの概要をご覧ください。
- マルチプロジェクト環境では、クラスタプロジェクトとは別のプロジェクトでフリートをホストすることをおすすめします。組織のポリシーと既存の構成で許可されている場合は、共有 VPC プロジェクトをフリートホストプロジェクトとして使用することをおすすめします。詳細については、共有 VPC を使用したクラスタの設定をご覧ください。

Cloud Service Mesh のインストールに必要なロール

次の表に、マネージド Cloud Service Mesh のインストールに必要なロールを示します。

ロール名	ロール ID	付与する場所	説明
GKE Hub 管理者	roles/gkehub.admin	フリートプロジェクト	GKE Hub と関連リソースに対する完全アクセス権。
Service Usage 管理者	roles/serviceusage.serviceUsageAdmin	フリートプロジェクト	サービス状態の有効化、無効化、検査、オペレーションの検査、ユーザープロジェクトの割り当てと請求の利用が可能な権限。^{（注 1）}
CA サービス管理者^ベータ版	roles/privateca.admin	フリートプロジェクト	CA Service のすべてのリソースへの完全アクセス権。^{（注 2）}

Cloud Service Mesh の実行に必要なロール

次の表に、マネージド Cloud Service Mesh を実行するためにサービスアカウントで必要なロールを示します。ネットワークプロジェクトまたはクラスタプロジェクトがフリートホストプロジェクトと異なる場合は、フリートプロジェクトのサービスアカウントに、他のプロジェクトにおけるこれらのロールへのアクセス権を付与する必要があります。

ロール名	ロール ID	付与する場所	説明
Anthos Service Mesh サービスエージェント	roles/anthosservicemesh.serviceAgent	フリートプロジェクト
Mesh が管理するコントロールプレーンサービスエージェント（以前のロール）	roles/meshcontrolplane.serviceAgent	フリートプロジェクト	これは、Cloud Service Mesh の古いインストールの一部だった以前のロールです。インストールにこのサービスロールがある場合は、そのまま残しておいてかまいません。新規インストールではこのロールは必要ありません。

制限事項

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

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

注: IstioOperator API を使用しなくても、オプション機能を有効にできます。詳しくは、マネージド Cloud Service Mesh でオプション機能を有効にするをご覧ください。asmcli に含まれる移行ツールを使用して、他の IstioOperator オプション機能を自動的に変換し、マネージドコントロールプレーンとの互換性を持たせることもできます。詳細については、IstioOperator から移行するをご覧ください。
Certificate Authority Service（CA Service）を使用するには、クラスタごとに Cloud Service Mesh を構成する必要があります。GKE Enterprise でフリートのデフォルト構成を使用する場合はサポートされません。
GKE Autopilot クラスタの場合、プロジェクト間の設定は GKE 1.23 以降でのみサポートされます。
GKE Autopilot クラスタの場合、GKE Autopilot リソースの上限に適応するために、デフォルトのプロキシリソースのリクエストと上限は 500m CPU と 512 MB メモリに設定されています。カスタムインジェクションを使用して、デフォルト値をオーバーライドできます。
GKE Autopilot クラスタの場合、クラスタの NodePool がスケーリングされるまで、Cloud Service Mesh コンポーネントに関する警告（「DaemonSet has no nodes selected」）が表示されることがあります。
マネージドコントロールプレーンのプロビジョニングプロセス中に、Istio CRD が指定のクラスタにプロビジョニングされます。クラスタに既存の Istio CRD が存在している場合、それらは上書きされます。
Istio CNI と Traffic Director には、GKE Sandbox との互換性がありません。したがって、TRAFFIC_DIRECTOR 実装のマネージド Cloud Service Mesh は、GKE Sandbox が有効になっているクラスタをサポートしていません。

始める前に

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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`	Cloud Service Mesh は、Mesh Configuration API を使用して、メッシュから Google Cloudに構成データをリレーします。また、Mesh Configuration API を有効にすると、 Google Cloud コンソールの Cloud Service Mesh のページにアクセスして、Cloud Service Mesh 認証局を使用できます。	×
`meshca.googleapis.com`	マネージド Cloud Service Mesh で使用される Cloud 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`	マネージド Cloud Service Mesh コントロールプレーンがメッシュワークロードにアクセスできるようにするために必要です。	○*
`trafficdirector.googleapis.com`	高可用性を備えたスケーラブルなマネージドコントロールプレーンを実現します。	○*
`networkservices.googleapis.com`	高可用性を備えたスケーラブルなマネージドコントロールプレーンを実現します。	○*
`networksecurity.googleapis.com`	高可用性を備えたスケーラブルなマネージドコントロールプレーンを実現します。	○*

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

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

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

クラスタごとに構成する

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

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

フリートプロジェクトで mesh 機能を有効にします。複数のクラスタを登録する場合でも、Cloud 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 をメモしておいてください。自動管理を有効にするときに必要になります。

クラスタのネットワークのプロジェクトがフリートホストプロジェクトと異なる場合（共有 VPC を使用している場合など）、フリートプロジェクトの Cloud Service Mesh サービスアカウントにネットワークプロジェクトへのアクセスを許可する必要があります。これが必要なのはネットワークプロジェクトに対して 1 回だけです。

フリートプロジェクトのサービスアカウントに、ネットワークプロジェクトにアクセスするための権限を付与します。
```
 gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
```
クラスタのプロジェクトがフリートホストプロジェクトと異なる場合は、フリートプロジェクトの Cloud Service Mesh サービスアカウントにクラスタプロジェクトへのアクセスを許可し、クラスタプロジェクトで必要な API を有効にする必要があります。

この手順は、クラスタプロジェクトごとに 1 回だけ行う必要があります。以前に、このクラスタとフリートプロジェクトの組み合わせに対してマネージド Cloud 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
```

Certificate Authority Service を構成する（省略可）

サービスメッシュのデプロイで Certificate Authority Service（CA Service）が必要な場合は、マネージド Cloud Service Mesh の Certificate Authority Service を構成するの手順に沿って、フリートに対して有効にします。次のセクションに進む前に、すべての手順を完了してください。

自動管理を有効にする

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

  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 で確認できます。

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

フリート用に構成する

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

フリートレベルのデフォルトは、フリートのデフォルトを有効にした後に作成された新しいクラスタにのみ自動的に適用されます。既存のクラスタに新しいデフォルト設定を適用するには、クラスタを同期する必要があります。

フリートのデフォルト構成としてマネージド Cloud Service Mesh を有効にし、クラスタの作成時にクラスタをフリートに登録すると、Mesh CA のみがサポートされます。Certificate Authority Service を使用する場合は、クラスタごとに有効にすることをおすすめします。

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

コンソール

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

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

注: これらの設定は、Cloud Service Mesh を使用するうえで前提条件となる GKE 設定です。
これらの設定を適用するには、[構成] をクリックします。
確認のダイアログで [確認] をクリックします。
既存のクラスタでマネージド Cloud Service Mesh を有効にするには、既存のクラスタをデフォルト設定に同期する必要があります。
1. [フリート内のクラスタ] リストで、同期するクラスタを選択します。
2. [フリートの設定に同期] をクリックし、表示された確認ダイアログで [確認] をクリックします。このオペレーションには数分かかることがあります。

gcloud

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

フリートレベルの設定

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

フリートで Cloud 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

ネットワークレベルの設定
- ネットワークのプロジェクトがフリートホストプロジェクトと異なる場合（共有 VPC を使用している場合など）、フリートプロジェクトの Cloud Service Mesh サービスアカウントにネットワークプロジェクトへのアクセスを許可する必要があります。これが必要なのはネットワークプロジェクトに対して 1 回だけです。
  
  フリートプロジェクトのサービスアカウントに、ネットワークプロジェクトにアクセスするための権限を付与します。
```
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
クラスタレベルの設定
- Cloud Service Mesh で使用するクラスタを作成する準備ができたら、デフォルト構成を使用するよう Google Cloud CLI で 1 ステップでクラスタを作成して登録します。次に例を示します。
```
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 など）です。
- クラスタのプロジェクトがフリートホストプロジェクトと異なる場合は、フリートプロジェクトの Cloud 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 と同じです。

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

Terraform のサポート

Cloud Service Mesh は、GKEHub 機能メンバーシップモジュールを介して Terraform によるプロビジョニングをサポートしています。

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

数分後、コントロールプレーンのステータスが 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
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

implementation フィールドに表示されるコントロールプレーン（ISTIOD または TRAFFIC_DIRECTOR）をメモします。コントロールプレーンの違いとサポートされている構成、コントロールプレーンの実装の選択については、Cloud Service Mesh でサポートされている機能をご覧ください。

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

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

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

Ingress ゲートウェイはコントロールプレーンで自動的にはデプロイされないことに注意してください。Ingress ゲートウェイとコントロールプレーンのデプロイを分離すると、本番環境でゲートウェイを管理できます。Istio Ingress ゲートウェイまたは Egress ゲートウェイを使用する場合は、ゲートウェイをデプロイするをご覧ください。Kubernetes Gateway API を使用する場合は、Mesh 用にゲートウェイを準備するをご覧ください。他のオプション機能を有効にするには、Cloud Service Mesh でオプション機能を有効にするをご覧ください。

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

マネージド Cloud Service Mesh を使用している場合、Google がプロキシのアップグレードを完全に管理します。

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

マネージドデータプレーンは GKE リリースチャンネルに依存します。マネージドデータプレーンが有効になっているときに GKE リリースチャンネルを変更すると、マネージド Cloud Service Mesh は、マネージドデータプレーンのロールアウトと同様に、既存のすべてのワークロードのプロキシを更新します。

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

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

Cloud Service Mesh データプレーンの新しいバージョンがデプロイされる場合

マネージドデータプレーン	新しい Cloud Service Mesh データプレーンのデプロイをトリガーするイベント
マネージドデータプレーン	Cloud Service Mesh のアクティブな更新新しいバージョンが利用可能になった場合にアクティブに更新される¹	新しい Pod の作成ユーザーまたは水平 Pod 自動スケーリングが新しいワークロードをデプロイする場合	GKE メンテナンスの時間枠 GKE メンテナンスの時間枠内でノードが置き換えられる場合
有効
無効

¹Cloud Service Mesh のアクティブな更新により、StatefulSets、Jobs、DaemonSets、手動で挿入された Pods を除く、ワークロード内の Pods が自動的に置き換えられます。Cloud Service Mesh のアクティブな更新は、Pod Disruption Budget を考慮します。

優先度の低いアクティブな更新は、GKE メンテナンスの時間枠内で行われます。
優先度の高いアクティブな更新は、GKE メンテナンスの時間枠に関係なく、Cloud Service Mesh によってクラスタで利用可能になった時点で実行できます。優先度の高いアクティブな更新には、通常、少なくとも 1 つの関連する CVE があります。

Cloud Service Mesh データプレーンのライフサイクルを自分で管理したくない場合、かつワークロードで Pod の随時置き換えが許容される場合は、マネージドデータプレーンを有効にします。

すべての Cloud Service Mesh データプレーンの更新の時間を完全に制御する場合は、マネージドデータプレーンを無効にします。

制限事項

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

挿入されなかった Pod
手動で挿入された Pod
ジョブ
StatefulSet
DaemonSet

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

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

マネージドデータプレーンをクラスタレベルで無効にし、サイドカープロキシを再び自分で管理するには、すべての controlplanerevision を見つけて、各アノテーションを変更します。

すべてのコントロールプレーンのリビジョンを確認します。
```
kubectl get controlplanerevisions -n istio-system
```
アノテーションを変更します。
```
kubectl annotate --overwrite controlplanerevision CONTROL_PLANE_REVISION_NAME -n istio-system mesh.cloud.google.com/proxy='{"managed":"false"}'
```
コントロールプレーンリビジョンごとにこの手順を繰り返します。

CONTROL_PLANE_REVISION_NAME は、前のコマンドの出力に置き換えます。

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"}'

マネージドデータプレーンのメンテナンスの時間枠を有効にする

GKE メンテナンスの時間枠を構成している場合、アクティブなアップグレードは次に利用可能なメンテナンスの時間枠の開始時に開始され、すべてのマネージド Pod が更新されるまで一時停止せずに続行します（通常 12 時間）。CVE 関連のロールアウトではメンテナンスの時間枠は適用されません。

Cloud Service Mesh は、GKE に合わせて GKE メンテナンスの時間枠を使用します。

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

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

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

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

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

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

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

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

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

Cloud Service Mesh をご利用のお客様へ、

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

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

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

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

Cloud Service Mesh チーム

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 このお知らせは、Google Cloud Platform またはお客様のアカウントの重要な変更に関する最新情報をお届けするためにお送りしています。メンテナンスの時間枠の通知をオプトアウトするには、ユーザー設定（ https://console.cloud.google.com/user-preferences/communication?project=${project_id}）を編集してください。

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

メッシュにクラスタが 1 つしかない場合は、このマルチクラスタの手順をスキップして、アプリケーションのデプロイまたはアプリケーションの移行に進んでください。

続行する前に、各クラスタで Cloud Service Mesh が構成されていることを確認します。

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

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

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

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

インジェクションの名前空間を有効にします。手順は、コントロールプレーンの実装によって異なります。

マネージド（TD）

デフォルトのインジェクションラベルを名前空間に適用します。

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

マネージド（Istiod）

推奨: 次のコマンドを実行して、デフォルトのインジェクションラベルを Namespace に適用します。

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

マネージド Istiod コントロールプレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションも利用できます。次の手順を行います。

次のコマンドを実行して、利用可能なリリースチャンネルを探します。
```
kubectl -n istio-system get controlplanerevision
```
出力は次のようになります。
```
NAME                AGE
asm-managed-rapid   6d7h
```
注: 上記のリストに 2 つのコントロールプレーンのリビジョンが表示されている場合は、1 つを削除します。クラスタに複数のコントロールプレーンチャネルを配置することはできません。

出力で、NAME 列の値は、Cloud Service Mesh バージョンで使用可能なリリースチャンネルに対応するリビジョンラベルです。

リビジョンラベルを名前空間に適用します。

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

次のコマンドを使用して、名前空間のラベルが正しく適用されていることを確認します。

  kubectl get namespace -L istio-injection

出力例:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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

マルチクラスタ設定にアプリケーションをデプロイする場合、その特定の構成ファイルをクラスタの一部に制限する予定がなければ、すべてのクラスタに 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"
      limits:
        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 では、Pod の spec でリソースの 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"

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

クラスタ内 Cloud Service Mesh からマネージド Cloud Service Mesh にアプリケーションを移行するには、次の手順に沿って操作します。

現在の名前空間のラベルを置き換えます。手順はコントロールプレーンの実装によって異なります。

マネージド（TD）

デフォルトのインジェクションラベルを名前空間に適用します。

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

マネージド（Istiod）

推奨: 次のコマンドを実行して、デフォルトのインジェクションラベルを Namespace に適用します。

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

次のコマンドを実行して、利用可能なリリースチャンネルを探します。
```
kubectl -n istio-system get controlplanerevision
```
出力は次のようになります。
```
NAME                AGE
asm-managed-rapid   6d7h
```
注: 上記のリストに 2 つのコントロールプレーンのリビジョンが表示されている場合は、1 つを削除します。クラスタに複数のコントロールプレーンチャネルを配置することはできません。

出力で、NAME 列の値は、Cloud Service Mesh バージョンで使用可能なリリースチャンネルに対応するリビジョンラベルです。

リビジョンラベルを名前空間に適用します。

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

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

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

deployment.apps/istio-ingressgateway rolled back

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

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

GKE でマネージド Cloud Service Mesh コントロール プレーンをプロビジョニングする

前提条件

要件

Cloud Service Mesh のインストールに必要なロール

Cloud Service Mesh の実行に必要なロール

制限事項

始める前に

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

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

クラスタごとに構成する

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

クラスタをフリートに登録する

Certificate Authority Service を構成する（省略可）

自動管理を有効にする

フリート用に構成する

コンソール

gcloud

Terraform のサポート

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

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

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

Cloud Service Mesh データプレーンの新しいバージョンがデプロイされる場合

制限事項

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

マネージド データプレーンのメンテナンスの時間枠を有効にする

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

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

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

マネージド（TD）

マネージド（Istiod）

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

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

マネージド（TD）

マネージド（Istiod）

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

ロールバック

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

GKE でマネージド Cloud Service Mesh コントロールプレーンをプロビジョニングする

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

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

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

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

マネージドデータプレーンのメンテナンスの時間枠を有効にする

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

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

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