xDS コントロール プレーン API
Cloud Service Mesh とそのクライアント(Envoy プロキシまたはプロキシレス gRPC ライブラリ)は、オープンソースの xDS API を使用して情報を交換します。Cloud Service Mesh を構成すると(たとえば、転送ルールやバックエンド サービスなどのリソースを使用すると)、Cloud Service Mesh がこれらのリソースを xDS 構成に変換してクライアントと共有します。
xDS バージョンのサポート
Cloud Service Mesh は xDS v3 のみをサポートしています。
Envoy と gRPC のどのバージョンが xDS v3 をサポートするかを確認するには、Envoy と gRPC のドキュメントをご覧ください。
まだ xDS v2 を使用している場合は、次の手順に沿って xDS v3 に移行してください。
xDS v2 から xDS v3 に移行する
移行プロセスには次の 2 つのステップがあります。
- Cloud Service Mesh への接続時にクライアント(Envoy プロキシまたはプロキシレス gRPC ライブラリ)が使用するサービス アカウントに付与されている Identity and Access Management(IAM)権限を更新します。
- アプリケーションを更新して再デプロイします。具体的な手順はデプロイによって異なります。以降のセクションで説明します。
サービス アカウントの IAM 権限を更新する
Cloud Service Mesh クライアント(Envoy、プロキシレス gRPC)で使用するサービス アカウントに trafficdirector.networks.reportMetrics
権限と trafficdirector.networks.getConfigs
権限があることを確認します。これらの権限は、IAM Cloud Service Mesh クライアント ロール(roles/trafficdirector.client
)に含まれています。
IAM カスタムロールを使用している場合は、それらの権限をカスタムロールに追加できます。権限を追加したら、サービス アカウントから Compute ネットワーク閲覧者のロール(roles/compute.networkViewer
)、Compute ネットワーク管理者のロール(roles/compute.networkAdmin
)、またはその両方を削除できます。
Compute ネットワーク閲覧者のロール(roles/compute.networkViewer
)または Compute ネットワーク管理者のロール(roles/compute.networkAdmin
)ではなく、Cloud Service Mesh クライアントのロールを使用することをおすすめします。Cloud Service Mesh クライアントのロールを使用すると、サービス アカウントに付与される権限が制限され、必要以上に幅広い権限が付与されることがなくなります。
アプリケーションを更新する
サービス アカウントの IAM 権限を更新したら、アプリケーションを更新します。
Compute Engine での Envoy
Compute Engine で Envoy のアプリケーションを更新するには、マネージド インスタンス グループのローリング再起動またはローリング置換を行います。xDS v3 をサポートする Envoy のバージョンが、仮想マシン(VM)インスタンスに自動的に追加されます。
GKE での Envoy
Google Kubernetes Engine(GKE)で自動 Envoy インジェクションを使用する場合は、Cloud Service Mesh で使用している GKE クラスタにサイドカー インジェクタを再インストールします。新しい Pod を作成すると、xDS v3 をサポートする Envoy サイドカー プロキシがワークロード Pod とともに自動的に挿入されます。
GKE で手動サイドカー インジェクションを使用する場合は、各 GKE クラスタにサイドカー プロキシを再デプロイします。
プロキシレス gRPC
移行プロセスには次の 2 つのステップがあります。
使用する gRPC のバージョンで xDS v3 がサポートされていることを確認します。詳細については、gRPC の xDS の機能をご覧ください。
次の手順でブートストラップ構成を更新します。
- ブートストラップ ファイルの例に示すように、
"xds_servers"
フィールドに"server_features": ["xds_v3"]
を追加します。 ノード ID を前の例に示されているような次の形式にする必要があります。
"projects/PROJECT_NUMBER/networks/NETWORK_NAME/nodes/ID"
- ブートストラップ ファイルの例に示すように、
アプリケーションに前述の変更を行ってから、アプリケーションをビルドして再デプロイします。
ブートストラップ構成に対する前述の変更は、xDS v3 をサポートしていない gRPC バージョンには影響しません。また、ブートストラップ構成に前述の変更がない場合、xDS v3 をサポートする gRPC バージョンは xDS v2 を使用します。
便宜上、Cloud Service Mesh gRPC ブートストラップ ジェネレータ バージョン 0.16.0 以降を使用して、xDS v3 と互換性のあるブートストラップ構成を生成できます。
Cloud Service Mesh クライアントが xDS v3 を使用していることを確認する
Cloud Service Mesh がクライアント用に生成した構成を検査するには、クライアント ステータス ツールを使用します。このツールは、構成が xDS v2 か xDS v3 かを示します。
次のステップ
- Cloud Service Mesh の一般的なトラブルシューティングについては、Envoy デプロイに関するトラブルシューティングをご覧ください。
- プロキシレス gRPC サービスをデプロイするときに構成の問題を解決するには、プロキシレス gRPC デプロイのトラブルシューティングをご覧ください。