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

asmcli を使用するマネージド Cloud Service Mesh をプロビジョニングする

概要

asmcli を使用するマネージド Cloud Service Mesh は、1 つのマネージドコントロールプレーンと 1 つのマネージドデータプレーンからなり、簡単に構成できます。これらのプレーンの信頼性、アップグレード、スケーリング、セキュリティは Google によって管理され、下位互換性が提供されます。このガイドでは、単一クラスタまたはマルチクラスタの構成で、asmcli を使用してマネージド Cloud Service Mesh にアプリケーションを設定または移行する方法について説明します。

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

前提条件

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

Cloud プロジェクト
Cloud 請求先アカウント
Cloud Service Mesh をプロビジョニングするために必要な権限を取得している
インストールツールである asmcli、kpt、必要なツールをインストールするで指定されているその他のツール

プロビジョニングにかかる時間を短縮するには、クラスタで Workload Identity を有効にする必要があります。Workload Identity が有効でない場合は、プロビジョニングにより自動的に有効になります。

要件

サポートされているいずれかのリージョンで、サポート対象バージョンの GKE を使用している 1 つ以上のクラスタ。
マネージド Cloud Service Mesh では、GKE リリースチャンネルによって安定性とアップグレード速度のバランスが確保されます。Cloud Service Mesh クラスタ内コンポーネント（CNI、MDPC、プロキシ、Istio CRD など）への新しい変更は、GKE Rapid チャンネルをサブスクライブするクラスタに最初にロールアウトされます。その後、クラスタは GKE Regular チャンネルに昇格し、十分な安定性が確認されると最終的に GKE Stable チャンネルに昇格します。
- マネージド Cloud Service Mesh では、安全な形で GKE リリースチャンネルを変更することができません。
- GKE リリースチャンネルを変更すると、変更先の GKE リリースチャンネルに合わせてクラスタ内コンポーネント（CNI、MDPC、デフォルトで挿入されたプロキシバージョン、Istio CRD）が自動的にアップグレードまたはダウングレードされます。
マネージド Cloud Service Mesh がクラスタにインストールする必須のコンポーネントに十分な容量がクラスタに存在することを確認します。
- kube-system Namespace 内の mdp-controller Deployment は、CPU: 50m、メモリ: 128Mi をリクエストします。
- kube-system Namespace 内の istio-cni-node DaemonSet は、各ノードに対して CPU: 100m、メモリ: 100Mi をリクエストします。
組織のポリシー constraints/compute.disableInternetNetworkEndpointGroup が無効になっていることを確認します。このポリシーが有効になっている場合、ServiceEntry が機能しないことがあります。
マネージド Cloud Service Mesh をプロビジョニングするクライアントマシンと API サーバーとのネットワーク接続を確認します。
クラスタは、フリートに登録されている必要があります。この手順は、プロビジョニング前に個別に行うことも、--enable-registration フラグと --fleet-id フラグを渡してプロビジョニングの一環として行うこともできます。
プロジェクトでサービスメッシュフリート機能が有効になっている必要があります。プロビジョニングの一環として有効にするには、--enable-gcp-components を渡すか、次のコマンドを実行します。
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
ここで、FLEET_PROJECT_ID はフリートホストプロジェクトのプロジェクト ID です。
GKE Autopilot は、GKE バージョン 1.21.3 以降でのみサポートされています。
Cloud Service Mesh では、単一プロジェクトの単一ネットワーク環境または複数プロジェクトの単一ネットワーク環境で複数の GKE クラスタを使用できます。
- 異なるプロジェクトのクラスタを追加する場合は、そのクラスタを同じフリートホストプロジェクトに登録する必要があります。また、そのクラスタを共有 VPC 構成で同じネットワークに接続する必要があります。
- 単一プロジェクトマルチクラスタ環境では、フリートプロジェクトはクラスタプロジェクトと同じにできます。フリートの詳細については、フリートの概要をご覧ください。
- マルチプロジェクト環境では、クラスタプロジェクトとは別のプロジェクトでフリートをホストすることをおすすめします。組織のポリシーと既存の構成で許可されている場合は、共有 VPC プロジェクトをフリートホストプロジェクトとして使用することをおすすめします。詳細については、共有 VPC を使用したクラスタの設定をご覧ください。
- 組織で VPC Service Controls を使用していて、リリースが 1.22.1-gke.10 以上の GKE クラスタで Cloud Service Mesh をプロビジョニングしている場合は、次の追加の構成手順が必要になる場合があります。
  - Cloud Service Mesh を Regular または Stable リリースチャンネルでプロビジョニングする場合、マネージドコントロールプレーンを適用する際に追加の --use-vpcsc フラグを使用し、VPC Service Controls（プレビュー版）ガイドに沿って操作する必要があります。そうしないと、プロビジョニングでセキュリティコントロールが失敗します。
  - Cloud Service Mesh を Rapid リリースチャンネルでプロビジョニングする場合、マネージドコントロールプレーンを適用する際に追加の --use-vpcsc フラグを使用する必要はありませんが、VPC Service Controls（一般提供）ガイドに沿って操作する必要があります。

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

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

ロール名	ロール ID	付与する場所	説明
GKE Hub 管理者	roles/gkehub.admin	フリートプロジェクト	GKE Hub と関連リソースに対する完全アクセス権。
Service Usage 管理者	roles/serviceusage.serviceUsageAdmin	フリートプロジェクト	サービス状態の有効化、無効化、検査、オペレーションの検査、ユーザープロジェクトの割り当てと請求の利用が可能な権限。^{（注 1）}
CA Service 管理者^ベータ版	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 でサポートされている機能と制限事項のリストを確認することをおすすめします。特に、次の点に注意してください。

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

注: IstioOperator API を使用しなくても、オプション機能を有効にできます。詳しくは、マネージド Cloud Service Mesh でオプション機能を有効にするをご覧ください。asmcli に含まれる移行ツールを使用すると、IstioOperator の他のオプション機能を、マネージドコントロールプレーンで利用できるように自動的に変換できます。詳細については、IstioOperator から移行するをご覧ください。
GKE Autopilot クラスタの場合、プロジェクト間の設定は GKE 1.23 以降でのみサポートされます。
GKE Autopilot クラスタの場合、GKE Autopilot リソースの上限に適応するために、デフォルトのプロキシリソースのリクエストと上限は 500m CPU と 512 MB メモリに設定されています。カスタムインジェクションを使用すると、デフォルト値をオーバーライドできます。
マネージドコントロールプレーンのプロビジョニングプロセス中に、Istio CRD が指定のクラスタにプロビジョニングされます。クラスタに既存の Istio CRD が存在している場合は上書きされます。
Istio CNI と Cloud Service Mesh は GKE Sandbox に対応していません。したがって、TRAFFIC_DIRECTOR が実装されているマネージド Cloud Service Mesh では、GKE Sandbox が有効になっているクラスタはサポートされません。
asmcli ツールから Google Kubernetes Engine（GKE）エンドポイントにアクセスできる必要があります。アクセスを構成するには、Virtual Private Cloud（VPC）内の Compute Engine VM などの「ジャンプ」サーバーを使用して特定のアクセス権を付与します。

始める前に

gcloud を構成する

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

Google Cloud CLI に対して認証を行います。
```
gcloud auth login --project PROJECT_ID
```
PROJECT_ID は、クラスタプロジェクトの一意の識別子です。PROJECT_ID を取得するには次のコマンドを実行します。
```
   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```
```
コンポーネントを更新します。
```
gcloud components update
```
クラスタを参照するように kubectl を構成します。

注: クラスタがリージョンクラスタの場合は、--zone ではなく --region を使用します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID
```

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

最新バージョンのツールを現在の作業ディレクトリにダウンロードします。
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
```
ツールを実行可能にします。
```
chmod +x asmcli
```

各クラスタを構成する

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

マネージドコントロールプレーンを適用する

マネージドコントロールプレーンを適用する前に、リリースチャンネルを選択する必要があります。使用する Cloud Service Mesh チャンネルは、マネージド Cloud Service Mesh をプロビジョニングする時点での GKE クラスタチャンネルによって決まります。同じクラスタで複数のチャネルを同時に使用することはできません。

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

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

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

認証局

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

Mesh CA

次のコマンドを実行して、デフォルトの機能と Mesh CA を備えたコントロールプレーンをインストールします。プレースホルダに値を入力します。

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

CA Service

Certificate Authority Service を構成するの手順に沿って操作します。
次のコマンドを実行して、デフォルト機能と Certificate Authority Service を備えたコントロールプレーンをインストールします。プレースホルダに値を入力します。

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

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

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

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

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

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

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

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

数分が経過した後もステータスが ACTIVE にならない場合は、マネージドコントロールプレーンのステータスを確認するを参照して、考えられるエラーの詳細を確認してください。

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

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

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

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

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

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

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

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

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

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

マネージド Cloud Service Mesh を古いクラスタでプロビジョニングした場合は、そのクラスタ全体でデータプレーン管理を有効にできます。

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

または、特定のコントロールプレーンリビジョン、Namespace、または Pod で同じアノテーションを設定して、マネージドデータプレーンを選択的に有効にできます。個別のコンポーネントを選択的に制御する場合、優先順位は、コントロールプレーンのリビジョン、Namespace、Pod の順です。

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

gcloud container fleet mesh describe --project FLEET_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 分以内に完了しない場合は、マネージドデータプレーンのステータスで次の手順を確認してください。

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

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

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

kubectl annotate --overwrite controlplanerevision -n istio-system \
  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"}'

メンテナンスの時間枠を有効にする

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 が各クラスタで構成済みであることを確認します。

一般公開クラスタ

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

オペレーションの対象が一般公開クラスタ（限定公開以外のクラスタ）である場合は、一般公開クラスタ間のエンドポイントディスカバリを構成することも、よりシンプルに一般公開クラスタ間のエンドポイントディスカバリを有効にすることもできます。

限定公開クラスタ

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

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

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

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

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

マネージド（TD）

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

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 つのコントロールプレーンリビジョンが表示された場合は、一方を削除します。クラスタに複数のコントロールプレーンチャネルを配置することはできません。

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

リビジョンラベルを Namespace に適用します。

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

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

  kubectl get namespace -L istio-injection

出力例:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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

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

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

コントロールプレーンとデータプレーンのバージョンは、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 が管理するコントロールプレーンとクラスタ内のコントロールプレーンの両方で Cloud Service Mesh を実行する場合は、コンテナ名によってそれぞれの指標を区別できます。たとえば、マネージドコントロールプレーンの指標には container_name="cr-asm-managed" が含まれ、非マネージドのコントロールプレーンの指標には container_name="discovery" が含まれます。両方の指標を表示するには、container_name="cr-asm-managed" の Filter を削除します。
Metrics Explorer で次のフィールドを調べて、コントロールプレーンとプロキシのバージョンを確認します。
- [revision] は、コントロールプレーンのバージョンを示します。
- [proxy_version] は proxy_version を示します。
- [value] は、接続されたプロキシの数を示します。
各チャンネルに現在対応する Cloud Service Mesh のバージョンについては、チャンネルごとの Cloud Service Mesh のバージョンをご覧ください。

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

移行の準備を行う

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

Google が管理するコントロールプレーンを適用するの手順に沿ってツールを実行します。
（省略可）Google が管理するデータプレーンを使用する場合は、データプレーンの管理を有効にします。
```
  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'
```

アプリケーションを移行する

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

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

マネージド（TD）

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

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 つのコントロールプレーンリビジョンが表示された場合は、一方を削除します。クラスタに複数のコントロールプレーンチャネルを配置することはできません。

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

リビジョンラベルを Namespace に適用します。

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

Namespace で Deployment のローリングアップグレードを実行します。
```
kubectl rollout restart deployment -n NAMESPACE
```
アプリケーションをテストして、ワークロードが正しく機能することを確認します。
他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。
マルチクラスタ設定にアプリケーションをデプロイした場合は、すべてのクラスタに Kubernetes と Istio の構成を複製します。ただし、その構成をクラスタの一部に制限する場合を除きます。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。

アプリケーションが期待どおりに動作していることを確認したら、すべての Namespace をマネージドコントロールプレーンに切り替えた後にクラスタ内の 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

アンインストール

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

トラブルシューティング

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

次のステップ

リリースチャンネルについて確認する。
IstioOperator から移行する。
ゲートウェイをマネージドコントロールプレーンに移行する。
次のようなマネージド Cloud Service Mesh のオプション機能を有効にする方法を確認する。

asmcli を使用するマネージド Cloud Service Mesh をプロビジョニングする

概要

前提条件

要件

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

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

制限事項

始める前に

gcloud を構成する

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

各クラスタを構成する

マネージド コントロール プレーンを適用する

認証局

Mesh CA

CA Service

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

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

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

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

メンテナンスの時間枠を有効にする

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

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

一般公開クラスタ

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

限定公開クラスタ

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

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

マネージド（TD）

マネージド（Istiod）

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

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

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

移行の準備を行う

アプリケーションを移行する

マネージド（TD）

マネージド（Istiod）

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

ロールバック

アンインストール

トラブルシューティング

次のステップ

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

マネージドコントロールプレーンを適用する

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

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

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

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

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

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

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

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