Anthos Service Mesh のインストール

このページでは、同じ Google Cloud プロジェクトにある 1 つ以上のクラスタを含むメッシュの GKE クラスタに Anthos Service Mesh バージョン 1.8.6 をインストールするスクリプトの実行方法について説明します。

クラスタが異なるプロジェクトにあるマルチクラスタ メッシュについては、マルチクラスタ / マルチ プロジェクト インストールと GKE の移行をご覧ください。

このページでは Anthos Service Mesh のインストール（新規インストールまたは別の構成による同じバージョンのインストール）について説明します。

新規インストール用のスクリプトの実行は、同じバージョンの再インストール、アップグレード、Istio からの移行の場合でも同様ですが、これらのユースケースでは別の計画が必要になります。詳細については、次のページをご覧ください。

• Anthos Service Mesh のアップグレード
• Istio からの移行
• 同じバージョンの再インストール

始める前に

移行を開始する前に、次のことが完了していることを確認してださい。

• 要件の確認
• 認証局（CA）の選択
• クラスタの登録
• 必要なツールのインストール
• スクリプトのダウンロード

このスクリプトを使用するには、必要な権限が付与されているか、スクリプトが権限を有効にできるように --enable_all フラグまたは --enable_gcp_iam_roles フラグを追加する必要があります。同様に、スクリプトで必要な API を有効にしてクラスタを更新できるようにするには、--enable_all フラグを指定するか、よりきめ細かい有効化フラグを指定します。

Anthos Service Mesh のインストール

1. オプションを設定し、スクリプトの実行フラグを指定します。常に --project_id、--cluster_name、--cluster_location、--mode install のオプションを含めます。Citadel を CA として使用する場合、Citadel を CA として使用したインストールで説明されているように、--ca オプションとその他のオプションを指定する必要があります。スクリプトの引数の詳細については、オプションとフラグをご覧ください。

2. Anthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。

次のセクションでは、スクリプトを実行するための一般的な例について説明します。例の一覧については、右側のナビゲーション バーをご覧ください。

例

このセクションでは、インストールのためにスクリプトを実行する例を、よく使用される引数とともに説明します。例の一覧については、右側のナビゲーション バーをご覧ください。

検証のみ

次の例は、--only_validate オプションを使用してスクリプトを実行する方法を示しています。このオプションを使用すると、プロジェクトやクラスタは変更されず、Anthos Service Mesh はインストールされません。--only_validate を指定した場合、--enable_* フラグのいずれかがあると、スクリプトは失敗します。

このスクリプトは以下のことを検証します。

• 環境に必要なツールがある。
• 指定されたプロジェクトに対する必要な権限がある。
• クラスタが最小要件を満たしている。
• プロジェクトで必要な Google API がすべて有効になっている。

デフォルトでは、このスクリプトでインストール ファイルをダウンロードして抽出し、GitHub から asm 構成パッケージを一時ディレクトリにダウンロードします。終了する前に、このスクリプトで一時ディレクトリの名前を指定するメッセージが出力されます。--output_dir DIR_PATH オプションを使用して、ダウンロード用の既存のディレクトリを指定できます。--output_dir オプションを使用すると、必要に応じて istioctl コマンドライン ツールを使用できます。また、オプションの機能を有効にする構成ファイルが asm/istio/options ディレクトリにあります。

次のコマンドを実行して構成を検証し、インストール ファイルと asm パッケージを OUTPUT_DIR ディレクトリにダウンロードします。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH \
  --only_validate

成功すると、以下が出力されます。

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

いずれかのテストで検証が失敗した場合、エラー メッセージが出力されます。たとえば、プロジェクトで必要な Google API が有効になっていない場合は、次のエラーが表示されます。

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

有効化フラグを使用してスクリプトを実行する必要があるというエラー メッセージが表示された場合は、--only_validate を使用せずにスクリプトを実行するときに、エラー メッセージにある特定のフラグまたは --enable_all フラグを追加できます。必要に応じて、スクリプトを実行する前に、プロジェクトとクラスタを自分で更新することもできます。詳細については、マルチプロジェクト インストール ガイドのプロジェクトの設定とクラスタの設定セクションをご覧ください。

インストール

次のコマンドは、新規インストール用のスクリプトを実行します。これにより、インストール用のデフォルトの CA である Mesh CA が有効になるため、このケースでは --ca オプションは必要ありません。--enable_all フラグを使用すると、このスクリプトで、必要な Google API の有効化、Identity and Access Management の権限の設定、GKE Workload Identity の有効化など、クラスタに必要な更新を行うことができます。

Mesh CA を使用する場合は、GKE Workload Identity の代わりに、フリートの Workload Identity プールを使用できます。例については、フリートの Workload Identity プールでメッシュ CA を有効にするをご覧ください。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all

また、次のオプションを含めることもできます。

• --output_dir DIR_PATH。検証のみのサンプルを実行しなかった場合は、このオプションを使用して、既存のディレクトリを指定します。スクリプトは、このディレクトリに asm パッケージと Anthos Service Mesh インストール ファイルをダウンロードします。このファイルには istioctl、サンプル、マニフェストが含まれています。指定しない場合、スクリプトは、asm パッケージとインストール ファイルを一時ディレクトリにダウンロードします。

• --enable-registration。このフラグを使用すると、スクリプトによって、クラスタが属するプロジェクトにクラスタを登録できます。このフラグを指定しない場合は、クラスタの登録の手順に沿ってクラスタを手動で登録してください。

Citadel を CA として使用したインストール

このセクションでは、次の方法を説明します。

• Anthos Service Mesh がワークロードの署名に使用する証明書と鍵を生成する。
• インストール用のスクリプトを実行し、Citadel を CA として有効にする。

カスタム CA が必要な場合にのみ、Citadel を CA として使用することをおすすめします。

最高レベルのセキュリティを確保するには、オフラインのルート CA を維持し、下位 CA を使用して各クラスタの CA を発行することを強くおすすめします。詳しくは、CA 証明書のプラグインをご覧ください。この構成では、サービス メッシュ内のすべてのワークロードは、同じルート CA を使用します。各 Anthos Service Mesh CA は、ルート CA によって署名された中間 CA 署名鍵と証明書を使用します。メッシュ内に複数の CA が存在する場合、CA 間の信頼の階層を確立します。この手順を繰り返して、任意の数の認証局の証明書と鍵をプロビジョニングできます。

重要: この手順では、説明用の例として make コマンドで証明書と鍵を作成します。最高レベルのセキュリティを確保するには、オフラインの安全なコンピュータと本番環境用ツールを使用します。たとえば、HashiCorp Vault を使用して、CA 署名鍵を安全に生成して保護します。

1. 証明書と鍵のディレクトリを作成します。

   mkdir -p certs && \
   pushd certs

2. ルート証明書と鍵を生成します。

   make -f ../tools/certs/Makefile.selfsigned.mk root-ca
   

   これにより、次のファイルが生成されます。

   • root-cert.pem: ルート証明書
   • root-key.pem: ルート鍵
   • root-ca.conf: ルート証明書を生成するための openssl の構成
   • root-cert.csr: ルート証明書の CSR

3. 中間証明書と鍵を生成します。

   make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

   これにより、cluster1 という名前のディレクトリにファイルが生成されます。

   • ca-cert.pem: 中間証明書
   • ca-key.pem: 中間鍵
   • cert-chain.pem: istiod が使用する証明書チェーン
   • root-cert.pem: ルート証明書
   注: cluster1 は別の名前に置き換えることができます。たとえば、make mycluster-certs は mycluster という名前のディレクトリを作成します。

   これらの手順をオフライン コンピュータで行う場合は、生成されたディレクトリを、スクリプトを実行しているコンピュータにコピーします。

4. スクリプトを実行して、証明書と鍵用に以前に生成したファイルを含めます。

   ./install_asm \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --mode install \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH \
     --enable_all

オーバーレイ ファイルを使用したインストール

オーバーレイ ファイルは IstioOperator カスタム リソース（CR）を含む YAML ファイルです。install_asm に渡してコントロール プレーンを構成します。YAML ファイルを install_asm に渡すことで、デフォルトのコントロール プレーン構成をオーバーライドし、オプション機能を有効にできます。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。

YAML ファイルで複数の CR を指定した場合、install_asm は、ファイルを CR ごとに一時的な YAML ファイルに分割します。istioctl install は、複数の CR を含む YAML ファイルの最初の CR のみを適用するため、このスクリプトは CR を別個のファイルに分割します。

次の例では、インストールを行い、オーバーレイ ファイルを含むコントロール プレーン構成をカスタマイズします。次のコマンドでは、OVERLAY_FILE を YAML ファイルの名前に変更します。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --custom_overlay OVERLAY_FILE

オプションを使用したインストール

次の例では、アップグレードを行い、asm パッケージの egressgateways.yaml ファイルを組み込み、Egress ゲートウェイを有効にします。.yaml 拡張子は含めないように注意してください。スクリプトによってファイルが取得されるため、最初に asm パッケージをダウンロードする必要はありません。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --option egressgateways

--option を使用すると、オプション機能を有効にできます。asm パッケージの asm/istio/options ディレクトリにあるファイルのいずれかを変更する必要がある場合は、asm パッケージをダウンロードして変更し、--custom_overlay を使用してファイルを含めます。

asm パッケージを現在の作業ディレクトリにダウンロードしてファイルを変更するには:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm

--output_dir オプションを指定した検証のみの例を実行した場合、構成ファイルは asm/istio/options の下の指定した出力ディレクトリにあります。

フリートで Mesh CA を有効にする

プレビュー — Mesh CA with fleet

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

フリートを使用した Mesh CA のプレビュー版は、GKE に Anthos Service Mesh を新規にインストールする場合に限られています。プレビュー版のアップグレードと移行はサポートされていません。

この例では、フリートの Workload Identity プールを使用するために、Mesh CA を有効にする方法を示しています。フリートで Mesh CA を使用すると、別の Google Cloud プロジェクトのクラスタを、そのフリートに対応する単一の信頼ドメインに結合できます。

フリートで Mesh CA を有効にするには:

まだクラスタを登録していない場合は、次の例のように --enable-registration フラグを指定するようにしてください。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --enable-registration \
  --option hub-meshca

このコマンドは、新規インストール用のスクリプトを実行して、Anthos Service Mesh で必要なオプションを使用してプロジェクトとクラスタを構成し、クラスタが所属するプロジェクトにクラスタを登録して、フリートの Workload Identity プールを使用するように Mesh CA を構成します。

ワークロードのデプロイと再デプロイ

Anthos Service Mesh は、サイドカー プロキシを使用してネットワークのセキュリティ、信頼性、オブザーバビリティを強化します。Anthos Service Mesh では、これらの機能がアプリケーションのプライマリ コンテナから抽出され、同じ Pod 内の個別のコンテナとして提供される共通のプロセス外プロキシに実装されます。

インストールは、自動サイドカー プロキシ挿入（自動挿入）を有効化して、Anthos Service Mesh をインストールする前にクラスタで実行していたワークロードの Pod を再起動するまで完了しません。

自動挿入を有効にするには、Anthos Service Mesh をインストールしたときに istiod に設定したリビジョン ラベルで名前空間にラベルを付けます。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入できるように、名前空間内の既存の Pod を再起動する必要があります。

新しいワークロードを新しい名前空間にデプロイする前に、Anthos Service Mesh がトラフィックのモニタリングと保護を行えるように自動挿入を構成してください。

自動インジェクションを有効にするには:

1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

   kubectl -n istio-system get pods -l app=istiod --show-labels
   

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

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-186-8-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-186-8-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586

   出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョン ラベルの値をメモします。この例での値は asm-186-8 です。

2. リビジョン ラベルを適用し、存在する場合は istio-injection ラベルを削除します。次のコマンドで、NAMESPACE は自動インジェクションを有効にする名前空間の名前で、REVISION は前の手順でメモしたリビジョン ラベルです。

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

   出力中のメッセージ "istio-injection not found" は無視して構いません。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、こうなって当然です。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

3. Anthos Service Mesh をインストールする前にクラスタでワークロードが実行されていた場合は、Pod を再起動して再インジェクションをトリガーします。

   Pod を再起動する方法は、アプリケーションとクラスタが属する環境によって異なります。たとえば、ステージング環境では、すべての Pod を削除するのみの場合がありますが、それによって Pod が再起動されます。ただし、本番環境では、Blue/Green デプロイを実装するプロセスにより、トラフィックが中断しないように Pod を安全に再起動できます。

   kubectl を使用すると、ローリングの再起動を実行できます。

   kubectl rollout restart deployment -n NAMESPACE
   

4. Pod が新しいバージョンの istiod を指すように構成されていることを確認します。

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
   

Anthos Service Mesh ダッシュボードの表示

サイドカー プロキシが挿入されたクラスタにワークロードをデプロイすると、Google Cloud コンソールの Anthos の [サービス メッシュ] ページで、Anthos Service Mesh が提供するすべてのオブザーバビリティ機能を確認できます。ワークロードをデプロイした後、Google Cloud コンソールにテレメトリー データが表示されるまでに 1～2 分ほどかかることがあります。

Google Cloud コンソールでの Anthos Service Mesh へのアクセスは、Identity and Access Management（IAM）によって制御されます。Anthos Service Mesh ページにアクセスするには、プロジェクト オーナーがユーザーに対して、プロジェクト編集者または閲覧者のロール、または、より限定的なロール（Google Cloud コンソールでの Anthos Service Mesh に対するアクセス制御を参照）を付与する必要があります。

1. Google Cloud コンソールで、[Anthos Service Mesh] に移動します。

   Anthos の [サービス メッシュ] に移動する

2. メニューバーのプルダウン リストから Google Cloud プロジェクトを選択します。

3. 複数のサービス メッシュがある場合は、[サービス メッシュ] プルダウン リストからメッシュを選択します。

詳細については、Google Cloud コンソールでの Anthos Service Mesh の確認をご覧ください。

Anthos Service Mesh ページに加えて、サービスに関連する指標（特定のサービスで受信したリクエストの数など）が Cloud Monitoring に送信され、Metrics Explorer に表示されます。

指標を表示するには:

1. Google Cloud コンソールで、[Monitoring] ページに移動します。

   [Monitoring] に移動

2. [リソース] > [Metrics Explorer] を選択します。

指標の完全なリストについては、Cloud Monitoring のドキュメントの Istio 指標をご覧ください。

次のステップ

• Online Boutique サンプル アプリケーションをデプロイする
• Anthos Service Mesh にクラスタを追加する