このガイドでは、異なる Google Cloud プロジェクトにある複数の GKE クラスタが存在するメッシュに、Anthos Service Mesh をインストールする方法と、オープンソース Istio から移行する方法について説明します。
このガイドは、以下のオンボーディング ユースケースに使用できます。
Anthos Service Mesh 1.8.6 の新規インストール。
オープンソースの Istio 1.7 or 1.8 から Anthos Service Mesh 1.8.6 への移行。以前のバージョンの Istio を使用している場合は、Anthos Service Mesh に移行する前に、先にアップグレードする必要があります。
異なるプロジェクト内のクラスタによるサービス メッシュでは、すべての機能を使用できるわけではありません。特に、Google Cloud コンソールの Anthos Service Mesh ダッシュボードは現在使用できません。ただし、プロジェクトごとに Cloud Logging でログを表示し、Cloud Monitoring で指標を表示できます。
始める前に
このガイドでは、次のものが用意されていることを前提としています。
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.8.6 でサポートされていない GKE バージョンをベースにしていることがあります。詳細については、サポートされている環境をご覧ください。静的 GKE バージョンがある場合は、既存のクラスタをリリース チャンネルに登録するの手順を行ってください。
サービス メッシュに含めるには、サービスポートに名前を付ける必要があります。名前には、
name: protocol[-suffix]の構文でポートのプロトコルを含める必要があります。角かっこは、ダッシュで始まるオプションの接尾辞です。詳細については、サービスポートの命名をご覧ください。限定公開クラスタに Anthos Service Mesh をインストールする場合は、ファイアウォールでポート 15017 を開き、自動サイドカー インジェクションで使用される Webhook が適切に機能する必要があります。詳細については、限定公開クラスタのポートを開くをご覧ください。
組織にサービス境界を作成した場合は、Mesh CA サービスを境界に追加する必要があります。詳細については、サービス境界への Mesh 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 で必要なオプションを有効にする場合に重要です。クラスタのサービス メッシュは、プロジェクト番号に基づく値で識別されます。別のプロジェクトのクラスタを設定する場合は、フリートのホスト プロジェクトのプロジェクト番号を使用する必要があります。