このガイドでは、異なる Google Cloud プロジェクトにある複数の GKE クラスタが存在するメッシュに、Anthos Service Mesh をインストールする方法と、オープンソース Istio から移行する方法について説明します。同じ Google Cloud プロジェクト内で 1 つ以上の GKE クラスタをインストール、移行、アップグレードする方法については、GKE のインストール、移行、アップグレードをご覧ください。
このガイドは、次のユースケースに使用できます。
Anthos Service Mesh 1.7.8 の新規インストール。
オープンソースの Istio 1.6 または 1.7 から Anthos Service Mesh 1.7.8 への移行。以前のバージョンの Istio を使用している場合は、Anthos Service Mesh に移行する前に、先にアップグレードする必要があります。
異なる複数の Google Cloud プロジェクトでクラスタを構成するには、asm-gcp-multiproject（ベータ版）プロファイルが必要です。このプロファイルでは、次のとおりです。
Google Cloud コンソールの Anthos Service Mesh ダッシュボードは現在利用できません。ただし、プロジェクトごとに Cloud Logging でログを表示し、Cloud Monitoring で指標を表示できます。
asm-gcp-multiproject構成プロファイルの [サポートされている機能] ページにある、他のサポートされるデフォルト機能が有効になります。
始める前に
このガイドでは、次のものが用意されていることを前提としています。
Istio から移行する場合は、Istio からの移行の準備を必ず確認してください。
Anthos と Anthos Service Mesh の違い
GKE Enterprise サブスクライバーの場合は、GKE Enterprise API を必ず有効にしてください。
GKE Enterprise のサブスクライバーでない場合でも Anthos Service Mesh をインストールできますが、Google Cloud コンソールの一部の UI 要素と機能は GKE Enterprise のサブスクライバーのみが使用できます。サブスクライバーと非サブスクライバーが使用できる機能については、GKE Enterprise と Anthos Service Mesh の UI の違いをご覧ください。非サブスクライバーに関する Anthos Service Mesh の料金については、料金をご覧ください。
要件
クラスタが複数のプロジェクトにあるため、Shared Virtual Private Cloud（VPC）内に存在している必要があります。クラスタの構成については、共有 VPC を使用したクラスタの設定をご覧ください。
GKE クラスタは次の要件を満たす必要があります。
4 つ以上の vCPU を備えたマシンタイプ（
e2-standard-4など）。クラスタのマシンタイプに 4 つ以上の vCPU がない場合は、異なるマシンタイプへのワークロードの移行の説明に従ってマシンタイプを変更します。ノードの最小数は、マシンタイプによって異なります。Anthos Service Mesh には、8 つ以上の vCPU が必要です。4 つの vCPU を持つマシンタイプの場合、クラスタには少なくとも 2 つのノードが必要です。8 つの vCPU を持つマシンタイプの場合、クラスタに必要なノードは 1 つだけです。ノードを追加する必要がある場合は、クラスタのサイズ変更をご覧ください。
Anthos Service Mesh をインストールする前にクラスタを作成するには、Workload Identity を有効にします。Workload Identity は、Google API を呼び出すためのおすすめの方法です。Workload Identity を有効にすると、Workload Identity の制限事項で説明されているように、ワークロードから Google API への呼び出し方法が変わります。
クラスタをリリース チャンネルに登録します。この操作は省略できますが、行うことをおすすめします。Regular リリース チャンネルに登録することをおすすめします。他のチャネルは Anthos Service Mesh 1.7.8 でサポートされていない GKE バージョンをベースにしていることがあります。詳細については、サポートされている環境をご覧ください。静的 GKE バージョンがある場合は、既存のクラスタをリリース チャンネルに登録するの手順を行ってください。
サービス メッシュに含めるには、サービスポートに名前を付ける必要があります。名前には、
name: protocol[-suffix]の構文でポートのプロトコルを含める必要があります。角かっこは、ダッシュで始まるオプションの接尾辞です。詳細については、サービスポートの命名をご覧ください。限定公開クラスタに Anthos Service Mesh をインストールする場合は、ファイアウォールでポート 15017 を開き、自動サイドカー インジェクションで使用される Webhook が適切に機能する必要があります。詳細については、限定公開クラスタのポートを開くをご覧ください。
組織にサービス境界を作成した場合は、Mesh CA サービスを境界に追加する必要があります。詳細については、サービス境界へのメッシュ CA の追加をご覧ください。
制限事項
1 つの Google Cloud プロジェクトに関連付けることができるメッシュは 1 つのみです。
認証局の選択
新規にインストールする場合でも移行する場合でも、相互 TLS（mTLS）証明書を発行する認証局（CA）として、Anthos Service Mesh 認証局（Mesh CA）または Citadel（現在は istiod に組み込まれています）を使用できます。
次の理由から、Mesh CA を使用することをおすすめします。
- Mesh CA は、信頼性の高いスケーラブルなサービスで、Google Cloud 上で動的にスケーリングされるワークロード用に最適化されています。
- Mesh CA を使用する場合、Google は CA バックエンドのセキュリティと可用性を管理します。
- Mesh CA を使用すると、クラスタ間で単一のルート オブ トラストを使用できます。
ただし、次のような場合、Citadel の使用を検討できます。
- カスタム CA を使用する場合。
Istio から移行する場合。
Citadel を選択すると、移行中に mTLS トラフィックは中断されないため、ダウンタイムは発生しません。メッシュ CA を選択する場合は、信頼のルートが Citadel から Mesh CA に変更されるため、移行時のダウンタイムをスケジューリングする必要があります。Mesh CA ルートオブ トラストへの移行を完了するには、すべての名前空間内の Pod をすべて再起動する必要があります。このプロセスにおいて、古い Pod は新しい Pod で mTLS 接続を確立できません。
Mesh CA からの証明書には、アプリケーションのサービスに関する次のデータが含まれます。
- Google Cloud プロジェクト ID。
- GKE 名前空間
- GKE サービス アカウント名
マルチクラスタのサポート
現時点では必須ではありませんが、プロジェクトのフリート（以前の environ）にクラスタを登録することをおすすめします。フリートを使用してクラスタを整理すると、複数のクラスタを簡単に管理できます。フリートにクラスタを登録することで、必要に応じてサービスやその他のインフラストラクチャをグループ化し、一貫したポリシーを適用できます。複数のプロジェクトにクラスタがある場合は、クラスタが属しているプロジェクトではなく、フリートのホスト プロジェクトにクラスタを登録する必要があります。詳しくは、フリートにクラスタを登録するをご覧ください。
フリートのホスト プロジェクトのコンセプトは、クラスタを設定して Anthos Service Mesh で必要なオプションを有効にする場合に重要です。クラスタのサービス メッシュは、プロジェクト番号に基づく値で識別されます。別のプロジェクトのクラスタを設定する場合は、フリートのホスト プロジェクトのプロジェクト番号を使用する必要があります。