GKE への Anthos Service Mesh のインストール

このガイドでは、同じプロジェクトにある 1 つ以上の GKE クラスタを含むメッシュ用に Anthos Service Mesh バージョン 1.7.8 をインストールする方法、同バージョンへの移行やアップグレードを行う方法について説明します。Google が提供するスクリプトを使用して、プロジェクトとクラスタを構成し、Anthos Service Mesh をインストールします。

このガイドと、次のユースケース用のスクリプトを使用できます。

  • Anthos Service Mesh の新規インストール。

  • Anthos Service Mesh 1.6 または 1.7 パッチ バージョンからのアップグレード。これより前のバージョンからのアップグレードはサポートされていません。

  • オープンソースの Istio 1.6 または 1.7 から Anthos Service Mesh への移行。これより前のバージョンの Istio からの移行はサポートされていません。

  • Istio on GKE アドオンのバージョン 1.6 から Anthos Service Mesh への移行。Anthos Service Mesh に移行する前に、Operator で Istio 1.6 にアップグレードする必要があります。アドオンからの移行の完全な手順については、Istio on GKE のドキュメントの Anthos Service Mesh への移行をご覧ください。

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

始める前に

このガイドは、以下のものがあることを前提としています。

Istio から移行する場合は、Istio からの移行の準備を必ず確認してください。

Anthos と Anthos Service Mesh の違い

  • GKE Enterprise サブスクライバーである場合は、GKE Enterprise API を必ず有効にしてください。

    API の有効化

  • GKE Enterprise のサブスクライバーでない場合でも Anthos Service Mesh をインストールできますが、Google Cloud コンソールの一部の UI 要素と機能は GKE Enterprise のサブスクライバーのみが使用できます。サブスクライバーと非サブスクライバーが使用できる機能については、GKE Enterprise と Anthos Service Mesh の UI の違いをご覧ください。非サブスクライバーに関する Anthos Service Mesh の料金については、料金をご覧ください。

このスクリプトにより、他のすべての必要な Google API が有効になります。

要件

  • GKE クラスタは次の要件を満たす必要があります。

    • 4 つ以上の vCPU を備えたマシンタイプ（e2-standard-4 など）。クラスタのマシンタイプに 4 つ以上の vCPU がない場合は、異なるマシンタイプへのワークロードの移行の説明に従ってマシンタイプを変更します。

    • ノードの最小数は、マシンタイプによって異なります。Anthos Service Mesh には、8 つ以上の vCPU が必要です。4 つの vCPU を持つマシンタイプの場合、クラスタには少なくとも 2 つのノードが必要です。8 つの vCPU を持つマシンタイプの場合、クラスタに必要なノードは 1 つだけです。ノードを追加する必要がある場合は、クラスタのサイズ変更をご覧ください。

    • このスクリプトによって、クラスタで 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 の追加をご覧ください。

  • 移行の場合、istiod は istio-system 名前空間にインストールする必要があります。

制限事項

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 を使用すると、クラスタ間で単一のルート オブ トラストを使用できます。
Anthos Service Mesh の新規インストールでは、Mesh CA はデフォルトでスクリプトによって有効化されます。

ただし、次のような場合、Citadel の使用を検討できます。

  • カスタム CA を使用する場合。

  • Istio から移行する場合。

    Citadel を選択すると、移行中に mTLS トラフィックは中断されないため、ダウンタイムは発生しません。メッシュ CA を選択する場合は、信頼のルートが Citadel から Mesh CA に変更されるため、移行時のダウンタイムをスケジューリングする必要があります。Mesh CA ルートオブ トラストへの移行を完了するには、すべての名前空間内の Pod をすべて再起動する必要があります。このプロセスにおいて、古い Pod は新しい Pod で mTLS 接続を確立できません。

Mesh CA からの証明書には、アプリケーションのサービスに関する次のデータが含まれます。

  • Google Cloud プロジェクト ID。
  • GKE 名前空間
  • GKE サービス アカウント名

移行またはアップグレードの準備

Istio から移行する場合は、Istio からの移行の準備を必ず確認してください。

以前のインストールをカスタマイズしている場合は、Anthos Service Mesh に移行またはアップグレードする際に同じカスタマイズを行う必要があります。--set values フラグを追加してインストールをカスタマイズした場合は、それらの設定を IstioOperator 構成ファイルに追加することをおすすめします。構成ファイルを指定するには、スクリプトの実行時に構成ファイルで --custom_overlay を使用します。

必要なツールのインストール

スクリプトは、Cloud Shell 上、または Linux を実行するローカルマシン上で実行できます。

スクリプトをローカルで実行するには:

  1. 次のツールがインストールされていることを確認してください。

  2. gcloud CLI を使用して認証します。

    gcloud auth login

  3. コンポーネントを更新します。

    gcloud components update

  4. kpt から検出できるように、パスに git を設定します。

  5. 必要とするバージョンの kpt をダウンロードしてください。

スクリプトの実行

このセクションでは、スクリプトのダウンロード、必須パラメータとオプション パラメータの設定方法、スクリプトの実行方法について説明します。スクリプトの機能の詳細については、スクリプトについてをご覧ください。

  1. Anthos Service Mesh 1.7.8 をインストールするスクリプトのバージョンを、現在の作業ディレクトリにダウンロードします。

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm

    このスクリプトは安全な Cloud Source Repositories のロケーションからダウンロードしますが、GitHub の anthos-service-mesh-packages リポジトリにも公開されているので、ダウンロードの前にスクリプトの処理内容を確認できます。release-1.7-asm ブランチにある install_asm スクリプトのバージョンで Anthos Service Mesh 1.7.8 がインストールされます。

  2. 現在の作業ディレクトリにファイルの SHA-256 をダウンロードします。

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.sha256 > install_asm.sha256

  3. 両方のファイルを同じディレクトリに置いて、ダウンロードを検証します。

    sha256sum -c --ignore-missing install_asm.sha256

    検証が成功すると、コマンドは install_asm: OK を出力します。

    互換性を維持するため、install_asm.sha256 にはチェックサムを 2 回含めて、スクリプトのすべてのバージョンの名前を install_asm に変更できるようにします。--ignore-missing が存在しないというエラーが表示された場合は、--ignore-missing フラグを指定せずに上記のコマンドを再実行します。

  4. スクリプトを実行可能にします。

    chmod +x install_asm

  5. オプションを設定し、スクリプトの実行フラグを指定します。常に project_id、cluster_name、cluster_location、mode のオプションを含めます。mode によっては、ca オプションの指定が必要になる場合があります。

    • project_id、cluster_name、cluster_location の各オプションでは、Anthos Service Mesh をインストールするクラスタを識別します。
    • mode は、install、migrate、upgrade のいずれかです。
    • ca では、認証局を mesh_ca または citadel のいずれかに指定します。

    次のセクションでは、スクリプトを実行するための一般的な例について説明します。スクリプトの引数の詳細については、オプションとフラグをご覧ください。

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

例

このセクションでは、各 mode でスクリプトを実行する場合の例と便利な引数について説明します。例の一覧については、右側のナビゲーション バーをご覧ください。

検証のみ

次の例は、--only_validate オプションを使用してスクリプトを実行する方法を示しています。このオプションを使用すると、スクリプトはクラスタに対して何も変更を行いません。Anthos Service Mesh はインストールされません。このスクリプトは以下のことを検証します。

  • 環境に必要なツールがある。
  • 指定されたプロジェクトに対する必要な権限がある。
  • クラスタが最小要件を満たしている。
  • プロジェクトで必要な 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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

インストール

次のコマンドでは、新規インストール用のスクリプトを実行し、Mesh CA（新規インストール用のデフォルト CA。この場合、ca オプションは不要）を有効にします。スクリプトで必要な Google API を有効にできます。

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

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

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

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

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

最高レベルのセキュリティを確保するには、オフラインのルート CA を維持し、下位 CA を使用して各クラスタの CA を発行することを強くおすすめします。詳しくは、CA 証明書のプラグインをご覧ください。この構成では、サービス メッシュ内のすべてのワークロードは、同じルート CA を使用します。各 Anthos Service Mesh CA は、ルート CA によって署名された中間 CA 署名鍵と証明書を使用します。メッシュ内に複数の CA が存在する場合、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: ルート証明書

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

  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_apis \
  --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_apis \
  --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.7-asm asm

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

Istio から移行する

CA として Citadel を使用して Istio を移行すると、Anthos Service Mesh に移行した後も引き続き Citadel を使用できます。次のコマンドでは、移行用のスクリプトを実行し、Citadel を CA として有効にします。この移行では、コントロール プレーンのみがデプロイされます。ルート CA を変更することはなく、既存のワークロードに影響が及ぶことはありません。

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

オーバーレイ ファイルを使用した移行

オーバーレイ ファイルは 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 migrate \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

アップグレード

次のコマンドでは、スクリプトを実行してアップグレードします。このスクリプトを使用すると別の CA への変更はできないため、ca オプションを含める必要はありません。

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

オーバーレイ ファイルを使用したアップグレード

オーバーレイ ファイルは 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 upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

オプションとフラグ

このセクションでは、スクリプトで使用可能な引数について説明します。

オプション

-p|--project_id CLUSTER_PROJECT_ID
クラスタが作成されたプロジェクト ID。
-n|--cluster_name CLUSTER_NAME
クラスタの名前。
-l|--cluster_location CLUSTER_LOCATION
クラスタが作成されたゾーン（シングルゾーン クラスタの場合）またはリージョン（リージョン クラスタの場合）のいずれか。
-m|--mode {install|migrate|upgrade}
Anthos Service Mesh のインストールを行う場合は「install」と入力します。Istio から移行する場合は「migrate」と入力します。既存の Anthos Service Mesh インストールを新しいバージョンにアップグレードするには「upgrade」と入力します。
-c|--ca {mesh_ca|citadel}
インストールで Mesh CA を使用する場合、スクリプトはデフォルトで Mesh CA となっているため、このオプションを指定する必要はありません。アップグレードの場合、スクリプトにより CA の変更が許されないため、このオプションを含める必要はありません。移行の場合は、citadel か mesh_ca を指定します。移行のダウンタイムをスケジューリングできる場合は、mesh_ca を使用することをおすすめします。使用する CA についての詳細は、認証局の選択をご覧ください。Citadel の使用時に指定する必要がある他のオプションについては、Citadel カスタム証明書のオプションをご覧ください。
--co|--custom_overlay YAML_FILE
IstioOperator カスタム リソース（CR）YAML ファイルの名前。デフォルトで有効になっていない機能を有効にします。スクリプトが YAML ファイルの場所を特定できる必要があるため、スクリプトと同じディレクトリにファイルを置くか、相対パスを指定します。複数のファイルを追加するには、--co|--custom_overlay とファイル名を指定します。例: --co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE
オプション機能を有効にする IstioOperator CR を含む anthos-service-mesh パッケージの YAML ファイル名。こうしたファイルのいずれかを含める場合は、最初に anthos-service-mesh パッケージをダウンロードする必要はありません。また、.yaml 拡張子は指定しないでください。いずれかのファイルを変更する必要がある場合は、anthos-service-mesh パッケージをダウンロードして変更を加え、--custom_overlay オプションを使用します。複数のファイルを追加するには、-o|--option とファイル名を指定します。例: -o option_file1 -o option_file2 -o option_file3
-s|--service_account ACCOUNT
Anthos Service Mesh のインストールに使用されるサービス アカウントの名前。指定しない場合は、現在の gcloud 構成にある有効なユーザー アカウントが使用されます。有効なユーザー アカウントを変更する必要がある場合は、gcloud auth login を実行します。
-k|--key_file FILE_PATH
サービス アカウントの鍵ファイル。サービス アカウントを使用していない場合は、このオプションを省略します。
-D|--output_dir DIR_PATH
指定されていない場合、このスクリプトは、Anthos Service Mesh のインストールに必要なファイルや構成をダウンロードする一時ディレクトリを作成します。代わりに、--output-dir フラグを指定して、既存のディレクトリの指定に使用します。完了すると、指定したディレクトリには asm サブディレクトリと istio-1.7.8-asm.10 サブディレクトリが含まれます。asm ディレクトリには、インストールの構成が含まれます。istio-1.7.8-asm.10 ディレクトリには、istioctl、サンプル、マニフェストが含まれるインストール ファイルの抽出コンテンツが含まれます。

フラグ

-e|--enable_apis
スクリプトで、Anthos Service Mesh で必要な Google API を有効にできるようにします。このフラグがない場合、必要な API がまだ有効になっていないと、スクリプトが終了します。スクリプトにより有効化される API の一覧については、set_up_project をご覧ください。
-v|--verbose
実行前および実行後にコマンドを出力します。
--dry_run
コマンドを出力しますが、実行しません。
--only_validate
検証を実行しますが、Anthos Service Mesh はインストールしません。
--print_config
Anthos Service Mesh をインストールする代わりに、コンパイル済みのすべての YAML を標準出力（stdout）に出力します。通常は stdout に出力される場合でも、他のすべての出力が標準エラー（stderr）に書き込まれます。このフラグを指定すると、すべての検証と設定がスキップされます。
--disable_canonical_service
デフォルトでは、このスクリプトは Canonical Service コントローラをクラスタにデプロイします。スクリプトでコントローラをデプロイしない場合は、--disable_canonical_service を指定します。詳細については、Canonical Service コントローラの有効化と無効化をご覧ください。
-h|--help
オプション、フラグ、終了を説明するヘルプ メッセージを表示します。
--version
install_asm のバージョンを出力して終了します。このコマンドでバージョンが出力されない場合は、install_asm_1.7 の最新バージョンをダウンロードします。

Citadel のカスタム証明書オプション

citadel を指定してカスタム CA を使用する場合は、次のオプションを指定します。

  • --ca_cert FILE_PATH: 中間証明書
  • --ca_key FILE_PATH: 中間証明書の鍵
  • --root_cert FILE_PATH: ルート証明書
  • --cert_chain FILE_PATH: 証明書チェーン

詳細については、既存の CA 証明書への接続をご覧ください。

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

自動サイドカー プロキシ インジェクション（自動挿入）を有効にするまで、インストールは完了しません。

  • 新規インストールの場合、Anthos Service Mesh をインストールする前に、クラスタで動作していたワークロードに対して自動挿入を有効にして Pod を再起動する必要があります。

  • 移行とアップグレードは、デュアル コントロール プレーンのアップグレード（Istio ドキュメントでは「カナリア アップグレード」）のプロセスに従います。デュアル コントロール プレーンのアップグレードでは、既存の istiod を残しながら、istiod の新しいバージョンがスクリプトでインストールされます。その後、一部のワークロードを新しいバージョンに移行します。このプロセスでは、すべてのトラフィックを新しいバージョンに移行する前に、ワークロードのごく一部で新しいバージョンの影響をモニタリングできます。

  • 新しいワークロードをデプロイする前に、Anthos Service Mesh がトラフィックをモニタリングおよび保護できるように、自動挿入を有効にします。

自動挿入を有効にするには、istiod に適用されたリビジョン ラベルをスクリプトで取得し、名前空間にリビジョン ラベルを付けます。以下で詳細について説明します。

リビジョン ラベルを取得する

このスクリプトは、リビジョン ラベルを istio.io/rev=asm-178-10 形式で istiod に追加します。自動挿入を有効にするには、一致するリビジョン ラベルを名前空間に追加します。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入できるように、名前空間内の既存の Pod を再起動する必要があります。

  1. kubectl の現在のコンテキストを設定します。

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. istiod のラベルを表示して、スクリプトによって設定されたリビジョン ラベルを取得します。

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

    このコマンドからの出力は、次のようになります。新規インストール、移行、アップグレードでは、出力が若干異なるので注意してください。次の出力例は、移行によるものです。

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7

    出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョン ラベルの値をメモします。この例では、値が asm-178-10 ですが、値が異なる場合があります。

    アップグレードと移行の場合は、古い istiod バージョンのリビジョン ラベルの値もメモしてください。これは、移行またはアップグレード完了時に、古いバージョンの istiod を削除するときに必要になります。この出力例では、古いバージョンの istiod のリビジョン ラベルの値は default ですが、異なる値の場合もあります。

自動挿入の有効化

新規インストール、移行、アップグレードで自動挿入を有効にする手順は次のとおりです。

  1. istiod のリビジョン ラベルの値を取得します。

  2. リビジョン ラベルを名前空間に追加し、istio-injection ラベルを削除します。次のコマンドで、REVISION を istiod のリビジョンと一致する値に変更します。

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

  3. Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE

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

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

  5. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

  6. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。

移行とアップグレードの場合:

  • アプリケーションが期待どおりに機能していることを確認したら、次のセクションに進み、新しいバージョンの istiod への移行を完了します。

  • アプリケーションに問題がある場合は、以前のバージョンにロールバックするの手順を行ってください。

移行を完了させる

移行とアップグレードの場合、古いバージョンの istiod を削除する必要があります。アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除して新しいバージョンへの移行を完了します。

  1. 古いバージョンの istiod のリビジョン ラベルの値を取得します。

  2. 古いバージョンの istiod を削除します。次のコマンドで、OLD_REVISION を前の手順のリビジョンに置き換えます。

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true

以前のバージョンへのロールバック

移行とアップグレードで、新しいバージョンの istiod を使用してアプリケーションをテストしたときに問題が発生した場合は、以下の手順で以前のバージョンにロールバックできます。

  1. 以前のバージョンの istiod で自動挿入を有効にする場合は、名前空間に再びラベルを付けます。使用するコマンドは、リビジョン ラベルと以前のバージョンの istio-injection=enabled のどちらを使用するかによって異なります。

    • 自動挿入にリビジョン ラベルを使用した場合:

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

    • istio-injection=enabled を使用した場合:

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

  2. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE

  3. 以前のバージョンの istio-ingressgateway を再デプロイします。

    kubectl -n istio-system rollout undo deploy istio-ingressgateway

  4. 新しい istiod を削除します。

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

  5. --disable_canonical_service フラグを含めなかった場合、スクリプトで Canonical Service コントローラが有効になります。Canonical Service コントローラの有効化と無効化の手順を行い、無効にします。

同じバージョンの再インストール

install_asm スクリプトは、istioctl install を呼び出して、インストール、アップグレード、Istio の移行用に Anthos Service Mesh コントロール プレーン コンポーネント（istiod と istio-ingressgateway）をデプロイします。このスクリプトは istioctl install を使用します。オプション機能を有効にするために Anthos Service Mesh をカスタマイズする場合は、新しい構成でコントロール プレーンを再インストールする必要があります。

同じバージョンの Anthos Service Mesh を再インストールできるように、install_asm スクリプトが変更されました。同じバージョンを再インストールしてオプション機能を有効にすると、既存のコントロール プレーン構成が上書きされます。そのため、既存のインストールをカスタマイズした場合は、以前のインストールと同じ --option オプションや --custom_overlay オプションと、有効にする新しい機能の --option オプションや --custom_overlay オプションを含める必要があります。

Cloud Trace を有効にする場合やトレース設定を変更する場合は、更新されたコントロール プレーン構成でサイドカー プロキシが再挿入されるように、ワークロードを再デプロイする必要があります。

同じバージョンを再インストールするときは、通常のインストールの場合と同様に --mode install を指定します。スクリプトを使用したインストールについては、Anthos Service Mesh のインストールをご覧ください。

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

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 指標をご覧ください。

クラスタの登録

Google Cloud コンソールで統合ユーザー インターフェースにアクセスするには、クラスタをプロジェクトのフリートに登録する必要があります。フリートは、Google Cloud 外のクラスタを含むクラスタとそのワークロードを表示して管理するために統合された方法を提供します。

クラスタの登録については、フリートへのクラスタの登録をご覧ください。

スクリプトについて

このスクリプトは、安全な Cloud Source Repositories のロケーションからダウンロードしますが、GitHub もから入手できるので、ダウンロードの前にスクリプトの処理内容を確認できます。このスクリプトは、クラスタが要件を満たすことを検証し、GKE への Anthos Service Mesh のインストールで、手動で行うすべての操作を自動化します。

Anthos Service Mesh 1.7.8 では、release-1.7-asm ブランチで install_asm スクリプトのバージョンを使用します。バージョニングとリリースのプロセスについては、バージョニング / リリースをご覧ください。

validate_args と validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
 
validate_dependencies() {
  validate_cli_dependencies
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  fi

  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

validate_args 関数と validate_dependencies 関数:

  • 必要なツールがすべてインストールされていることを確認します。
  • パラメータ値として入力したプロジェクト ID、クラスタ名、クラスタのロケーションが有効であることを確認します。
  • クラスタがマシンタイプとノード数の最小要件を満たしていることを確認します。

set_up_project

--enable_apis フラグを使用すると、set_up_project 関数により必要な API が有効になります。

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
stackdriver.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

set_up_cluster 関数は、クラスタに対して次の更新を行います。

  • Workload Identity を有効にします。これは、GKE アプリケーションから Google Cloud サービスに安全にアクセスする方法として推奨される方法です。

  • GKE で Cloud Monitoring と Cloud Logging を有効にします。

  • クラスタに mesh_id ラベルを設定します。これは、Google Cloud コンソールの [Anthos Service Mesh] ページに指標を表示するために必要です。

  • asmv=asm-178-10 のようなラベルを設定し、スクリプトによってクラスタが変更されていることを示します。

  • スクリプトを実行している GCP ユーザーまたはサービス アカウントを、クラスタの cluster-admin ロールにバインドします。

install_asm

install_asm() {

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

install_asm 関数:

  • 一時ディレクトリに kpt パッケージをダウンロードします。
  • kpt セッターを実行して istio-operator.yaml ファイルを構成します。
  • Anthos Service Mesh をインストールします。

次のステップ