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 がクラスタにインストールする必要なコンポーネントに十分な容量がクラスタに存在することを確認します。
kube-system名前空間内のmdp-controllerデプロイは、CPU: 50m、メモリ: 128Mi をリクエストします。kube-system名前空間内のistio-cni-nodeDaemonSet は、各ノードに対して CPU: 100m、メモリ: 100Mi をリクエストします。
- 組織のポリシー
constraints/compute.disableInternetNetworkEndpointGroupが無効になっていることを確認します。 このポリシーを有効にすると、ServiceEntry が機能しないことがあります。 - マネージド Cloud Service Mesh をプロビジョニングするクライアント マシンと API サーバーとのネットワーク接続を確認します。
- クラスタは、フリートに登録されている必要があります。この操作は、プロビジョニングの前に個別に行うこともできます。
- プロジェクトでサービス メッシュ フリート機能が有効になっている必要があります。この操作は個別に行うこともできます。
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 サービスのリソースへの完全アクセス権。 （注 2） |
制限事項
Cloud Service Mesh でサポートされている機能と制限事項のリストを確認することをおすすめします。 特に、次の点に注意してください。
IstioOperatorAPI は、クラスタ内のコンポーネントを制御することが主な目的であるため、サポートされていません。Certificate Authority Service（CA Service）を使用するには、クラスタごとに Cloud Service Mesh を構成する必要があります。GKE Enterprise でフリートのデフォルト構成を使用する場合はサポートされません。
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 が有効になっているクラスタをサポートしていません。
始める前に
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure 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.
-
Make sure 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 Google Cloud コンソールで、[機能マネージャー] ページに移動します。
[サービス メッシュ] ペインで、[構成] をクリックします。
Google Cloud コンソールで作成してフリートに登録するすべての新しいクラスタに継承される設定を確認します。
これらの設定を適用するには、[構成] をクリックします。
確認のダイアログで [確認] をクリックします。
省略可: 既存のクラスタをデフォルト設定と同期します。
- [フリート内のクラスタ] リストで、同期するクラスタを選択します。Cloud Service Mesh がインストールされているクラスタのみを選択できます。
- [フリートの設定に同期] をクリックし、表示された確認ダイアログで [確認] をクリックします。このオペレーションが完了するまでには数分かかる場合があります。
フリートレベルの設定
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_IDCLUSTER_PROJECT_ID は、クラスタ プロジェクトの固有識別子に置き換えます。クラスタをフリートと同じプロジェクトに作成した場合、CLUSTER_PROJECT_ID は 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-central1MEMBERSHIP_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- MEMBERSHIP_NAME は、クラスタがフリートに登録されていることを確認した際に表示されたメンバーシップ名です。
MEMBERSHIP_LOCATION は、メンバーシップのロケーションです（リージョンまたは
global）。このガイドのコマンドを使用してメンバーシップを最近作成した場合は、クラスタのリージョンにする必要があります。ゾーンクラスタがある場合は、クラスタのゾーンに対応するリージョンを使用します。たとえば、
us-central1-cにゾーンクラスタがある場合は、値us-central1を使用します。2023 年 5 月より前に登録した場合や、メンバーシップの登録時に
globalを指定した場合、この値はglobalになります。メンバーシップのロケーションはgcloud container fleet memberships list --project FLEET_PROJECT_IDで確認できます。- 挿入されなかった Pod
- 手動で挿入された Pod
- ジョブ
- StatefulSets
- DaemonSets
[通信] ページに移動します。
[Cloud Service Mesh Upgrade] 行の [メール] 列で、メンテナンス通知をオンにするラジオボタンを選択します。
- デフォルトのインジェクション ラベルを名前空間に適用します。
利用可能なリリース チャンネルを探すには、次のコマンドを実行します。
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- Kubernetes では、インジェクションの実行前に
imageフィールドを設定する必要があります。特定のイメージを設定してデフォルトをオーバーライドできますが、imageをautoに設定することをおすすめします。これにより、サイドカー インジェクタで使用するイメージが自動的に選択されます。 containersの一部のフィールドは、関連する設定に依存しています。たとえば、CPU の上限以下にする必要があります。両方のフィールドが正しく構成されていないと、Pod の起動に失敗することがあります。- Kubernetes では、Pod
spec内のリソースにrequestsとlimitsの両方を設定できます。GKE Autopilot ではrequestsのみが考慮されます。詳細については、Autopilot でのリソース制限の設定をご覧ください。 - 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 のリソース変更の例をご覧ください。 - 現在の名前空間のラベルを置き換えます。手順は、コントロール プレーンの実装によって異なります。
- デフォルトのインジェクション ラベルを名前空間に適用します。
利用可能なリリース チャンネルを探すには、次のコマンドを実行します。
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 の構成を複製します。ただし、その構成をクラスタの一部に制限する場合を除きます。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。
コントロール プレーンの以前のバージョンで挿入されるワークロードを更新します。次のコマンドのリビジョン値
asm-191-1はサンプルとして使用されています。このサンプル値は、前のコントロール プレーンのリビジョン ラベルに置き換えてください。kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwriteプロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。
kubectl rollout restart deployment -n NAMESPACE
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 |
高可用性でスケーラブルなマネージド コントロール プレーンを実現します。 | ○* |
マネージド Cloud Service Mesh を構成する
Fleet API を使用してマネージド Cloud Service Mesh をプロビジョニングするために必要な手順は、新しいフリート クラスタのデフォルトで有効にするか、クラスタごとに有効にするで異なります。
フリート用に構成する
Google Kubernetes Engine（GKE）Enterprise エディションを有効にしている場合は、マネージド Cloud Service Mesh をフリートのデフォルト構成として有効にできます。つまり、クラスタの作成中に登録された Google Cloud 上の新しい GKE クラスタはすべて、クラスタでマネージド Cloud Service Mesh が有効になります。フリートのデフォルト構成の詳細については、フリートレベルの機能を管理するをご覧ください。
フリートのデフォルト構成としてマネージド Cloud Service Mesh を有効にし、クラスタの作成時にクラスタをフリートに登録する場合、Mesh CA のみがサポートされます。Certificate Authority Service を使用する場合は、クラスタごとに有効にすることをおすすめします。
マネージド Cloud Service Mesh のフリートレベルのデフォルトを有効にするには、次の手順を行います。
Console
gcloud
Google Cloud CLI を使用してフリートレベルのデフォルトを構成するには、次の設定を確立する必要があります。
コントロール プレーンがプロビジョニングされていることを確認するに進みます。
クラスタごとに構成する
メッシュ内の各クラスタに対して個別にマネージド Cloud Service Mesh を構成するには、次の手順を行います。
Cloud Service Mesh のフリート機能を有効にする
フリートで Cloud Service Mesh を有効にします。複数のクラスタを登録する場合、Cloud Service Mesh の有効化はフリートレベルで行われるため、このコマンドを実行する必要があるのは 1 回だけです。
gcloud container fleet mesh enable --project FLEET_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
ここで、
コントロール プレーンがプロビジョニングされていることを確認する
数分後、コントロール プレーンのステータスが 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 を使用する場合は、メッシュ用に Gateway を準備するをご覧ください。他のオプション機能を有効にするには、Cloud Service Mesh でオプション機能を有効にするをご覧ください。
マネージド データプレーン
マネージド Cloud Service Mesh を使用している場合、これを無効にしない限り、Google がプロキシのアップグレードを完全に管理します。
マネージド データプレーンが有効な場合、サイドカー プロキシと挿入されたゲートウェイは、ワークロードを再起動してプロキシの新しいバージョンを再挿入することで、マネージド コントロール プレーンとともに自動的に更新されます。これは通常、マネージド コントロール プレーンがアップグレードされてから 1～2 週間後に完了します。
無効になっている場合、プロキシ管理はクラスタ内の Pod の通常のライフサイクルに基づいて行われます。更新頻度を制御するには、ユーザーが手動でトリガーする必要があります。
マネージド データプレーンは、以前のバージョンのプロキシを実行している Pod のエビクションを行うことで、プロキシをアップグレードします。エビクションは、Pod Disruption Budget を維持しながら変更率を制御することによって、段階的に行われます。
マネージド データプレーンでは、次のものは管理されません。
マネージド データプレーンを無効にする（省略可）
新しいクラスタにマネージド Cloud Service Mesh をプロビジョニングする場合は、マネージド データプレーンを完全に無効にすることも、個々の名前空間や 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"}'
メンテナンス通知を有効にする
マネージド データプレーンのメンテナンスが予定されている遅くとも 1 週間前に、メンテナンスの予定の通知を送信するようにリクエストできます。メンテナンス通知は、デフォルトでは送信されません。また、通知を受信するには、GKE メンテナンスの時間枠を構成する必要があります。有効にすると、アップグレード オペレーションの少なくとも 2 日前に通知が送信されます。
マネージド データプレーンのメンテナンス通知を有効にするには:
通知を受け取る必要があるユーザーごとに個別にオプトインできます。通知のメールフィルタを設定する場合、件名は次のようになります。
Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"。
次の例に、一般的なマネージド データプレーンのメンテナンス通知を示します。
件名: Cloud Service Mesh クラスタ「
<location/cluster-name>」のアップグレードの予定Cloud Service Mesh をご利用のお客様
クラスタ内の Cloud Service Mesh コンポーネント、${instance_id}（https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}）が、${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）
推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを名前空間に適用します。
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
マネージド Istiod コントロール プレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。
この時点で、マネージド 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 内の任意のフィールドを設定できます。ただし、特定のフィールドには注意が必要です。
また、特定のフィールドは Pod のアノテーションで構成できますが、上記の方法で設定をカスタマイズすることをおすすめします。次のアノテーションには特に注意してください。
たとえば、次のリソースのアノテーション構成をご覧ください。
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）
推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを名前空間に適用します。
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
マネージド Istiod コントロール プレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。
アプリケーションが期待どおりに動作していることを確認したら、すべての名前空間をマネージド コントロール プレーンに切り替えた後にクラスタ内の istiod を削除できます。また、これらをバックアップとして残すこともできます。この場合、istiod が自動的にスケールダウンし、リソースの使用量が少なくなります。削除するには、古いコントロール プレーンを削除するに進みます。
問題が発生した場合は、マネージド コントロール プレーンの問題を解決するを参照して問題を特定し、解決します。また、必要であれば以前のバージョンにロールバックできます。
古いコントロール プレーンを削除する
すべての名前空間で Google 管理のコントロール プレーンが使用されていることを確認したら、古いコントロール プレーンを削除できます。
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
自動インジェクションではなく istioctl kube-inject を使用した場合や、追加のゲートウェイをインストールした場合は、コントロール プレーンの指標をチェックし、接続されているエンドポイントの数がゼロであることを確認します。
ロールバック
前のコントロール プレーン バージョンにロールバックする必要がある場合は、次の手順を行います。
未使用時は、マネージド コントロール プレーンは自動的にゼロへスケーリングされ、リソースを使用しません。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 をアンインストールするをご覧ください。