GKE でのインストールと移行

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

このガイドは、次のユースケースに使用できます。

  • Anthos Service Mesh の新規インストール。以前のバージョンの Anthos Service Mesh がインストールされている場合は、GKE での Anthos Service Mesh のアップグレードをご覧ください。1.6 スクリプトではアップグレードが処理されません。

  • オープンソースの Istio 1.6 から Anthos Service Mesh への移行。これより前のバージョンの Istio からの移行はサポートされていません。スクリプトのバージョン 1.7 は、Istio 1.6 または 1.7 から Anthos Service Mesh 1.7 への移行をサポートしています。Anthos Service Mesh 1.7 に移行することもできます。

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

以下のユースケースでは、GKE での高度なインストールと移行を使用する必要があります。

  • asm-gcp プロファイルで設定をオーバーライドするためにインストールをカスタマイズする必要があり、複数のオーバーレイ IstioOperator YAML ファイルがある場合。スクリプトで指定できる YAML ファイルは 1 つのみです。

  • クラスタが複数のプロジェクトにあるマルチクラスタ メッシュの場合。

始める前に

このガイドでは、次のものが用意されていることを前提としています。

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 の料金については、料金をご覧ください。

要件

  • 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.6.14 でサポートされていない 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 または Istio on GKE アドオンから移行する場合。

    Citadel を選択すると、移行中に mTLS トラフィックは中断されないため、ダウンタイムは発生しません。Mesh CA を選択すると、すべての名前空間ですべての Pod を再起動するまで mTLS トラフィックがエラーとなるため、移行時のダウンタイムをスケジューリングする必要があります。

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

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

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

このスクリプトは、Cloud Shell で実行できます。また、Linux あるいは macOS が実行されているローカルマシンで実行できます。Cloud Shell で必要なすべてのツールがプリインストールされます。

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

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

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

    gcloud auth login

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

    gcloud components update

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

スクリプトの実行

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

  1. 現在の作業ディレクトリにスクリプトをダウンロードします。

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

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6.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 のいずれかです。
    • 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 コマンドライン ツールを使用できます。

  1. asm-packages という名前のディレクトリを作成します。

    mkdir asm-packages

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

    ./install_asm \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install \
--output_dir ./asm-packages \
--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

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

次の例では、新規インストールを行い、オプション機能を有効にする YAML ファイルを含めます。

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

Istio から移行する

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

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

オプションとフラグ

オプション

-p|--project_id CLUSTER_PROJECT_ID
クラスタが作成されたプロジェクト ID。
-n|--cluster_name CLUSTER_NAME
クラスタの名前。
-l|--cluster_location CLUSTER_LOCATION
クラスタが作成されたゾーン（シングルゾーン クラスタの場合）またはリージョン（リージョン クラスタの場合）のいずれか。
-m|--mode {install|migrate}
Anthos Service Mesh を新規にインストールする場合は、「install」と入力します。Istio または Istio on GKE アドオンから Anthos Service Mesh に移行する場合は、「migrate」と入力します。
-c|--ca {mesh_ca|citadel}
新規にインストールする場合、このパラメータはデフォルトで Mesh CA に設定されるため、含める必要はありません。Istio から移行する場合は、citadel または mesh_ca を指定する必要があります。移行のダウンタイムをスケジューリングできる場合は、mesh_ca を使用することをおすすめします。移行のダウンタイムをスケジューリングできない場合は、citadel を使用します。
-o|--operator_overlay YAML_FILE
asm-gcp プロファイルで有効になっていない機能を有効にするための YAML ファイルの名前。スクリプトで検出できる場所に YAML ファイルを配置する必要があります。そのため、ファイルは、スクリプトと同じディレクトリに存在するか、../manifests/asm-features.yaml のように相対パスで指定する必要があります。
-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.6.14-asm.2 サブディレクトリが含まれます。asm ディレクトリには、インストールの構成が含まれます。istio-1.6.14-asm.2 ディレクトリには、istioctl、サンプル、マニフェストが含まれるインストール ファイルの抽出コンテンツが含まれます。

フラグ

-e|--enable_apis
スクリプトで、Anthos Service Mesh で必要な Google API を有効にできるようにします。このフラグがない場合、必要な API がまだ有効になっていないと、スクリプトが終了します。スクリプトにより有効化される API の一覧については、set_up_project をご覧ください。
-v|--verbose
実行前および実行後にコマンドを出力します。
--dry_run
コマンドを出力しますが、実行しません。
--only_validate
検証を実行しますが、Anthos Service Mesh はインストールしません。
--disable_canonical_service
デフォルトでは、このスクリプトは Canonical Service コントローラをクラスタにデプロイします。スクリプトでコントローラをデプロイしない場合は、--disable_canonical_service を指定します。詳細については、Canonical Service コントローラの有効化と無効化をご覧ください。
-h|--help
オプション、フラグ、終了を説明するヘルプ メッセージを表示します。

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

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

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

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

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

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

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

このスクリプトは、リビジョン ラベルを istio.io/rev=asm-1614-2 形式で 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-1614-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1614-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7

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

    移行の場合は、古い 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 で挿入されるワークロードを更新します。

    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 コントローラの有効化と無効化の手順を行い、無効にします。

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

このセクションの内容は、asm-gcp 構成プロファイルを使用して Anthos Service Mesh がインストールされている場合にのみ適用されます。asm-gcp-multiproject プロファイルを使用して Anthos Service Mesh をインストールした場合、テレメトリー データは Google Cloud コンソールの 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 のインストールで、手動で行うすべての操作を自動化します。

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

  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_expected_control_plane
  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  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
EOF
}

set_up_cluster

set_up_cluster(){
  add_cluster_labels
  enable_workload_identity

  # this is project scope but requires workload identity
  if [[ "${CA}" = "mesh_ca" ]]; then
    init_meshca
  fi

  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-1614-2 のようなラベルを設定し、スクリプトによってクラスタが変更されていることを示します。

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

install_asm

install_asm(){

  local CA_OPT
  CA_OPT=""
  if [[ "${CA}" = "citadel" ]]; then
    CA_OPT="-citadel"
  fi

  info "Configuring kpt package..."
  run kpt cfg set asm gcloud.container.cluster "${CLUSTER_NAME}"
  run kpt cfg set asm gcloud.core.project "${PROJECT_ID}"
  run kpt cfg set asm gcloud.project.environProjectNumber "${PROJECT_NUMBER}"
  run kpt cfg set asm gcloud.compute.location "${CLUSTER_LOCATION}"
  run kpt cfg set asm anthos.servicemesh.rev "${REVISION_LABEL}"
  if [[ -n "${_CI_ASM_IMAGE_LOCATION}" ]]; then
    run kpt cfg set asm anthos.servicemesh.hub "${_CI_ASM_IMAGE_LOCATION}"
    run kpt cfg set asm anthos.servicemesh.tag "${RELEASE}"
  fi

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST}"
  if [[  -f "$CUSTOM_OVERLAY" ]]; then
    PARAMS="${PARAMS} -f ${CUSTOM_OVERLAY}"
  fi
  PARAMS="${PARAMS} --set revision=${REVISION_LABEL}"
  PARAMS="${PARAMS} -c ${KUBECONFIG}"

  info "Installing ASM control plane..."
  # shellcheck disable=SC2086
  retry 5 run ./"${ISTIOCTL_REL_PATH}" install $PARAMS

  # Prevent the stderr buffer from ^ messing up the terminal output below
  sleep 1
  info "...done!"

  if ! does_istiod_exist; then
    info "Installing validation webhook fix..."
    retry 3 run kubectl apply -f "${VALIDATION_FIX_SERVICE}"
  fi

  if [[ "$DISABLE_CANONICAL_SERVICE" -ne 1 ]]; then
    info "Installing ASM CanonicalService controller in asm-system namespace..."
    retry 3 run kubectl apply -f asm/canonical-service/controller.yaml
    info "Waiting for deployment..."
    retry 3 run kubectl wait --for=condition=available --timeout=600s \
        deployment/canonical-service-controller-manager -n asm-system
    info "...done!"
  fi

  outro
}

install_asm 関数:

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

1.7 スクリプトとの違い

1.7 スクリプト 1.6 スクリプト
アップグレードをサポートします。 アップグレードは行われません。
Istio 1.6 と Istio 1.7 からの移行をサポートします。 Istio 1.6 からの移行をサポートします。
--print_config
install_asm スクリプトを使用してインストールしたときに使用した構成を出力します。このフラグにより、以前にインストールしたときと同じ構成で同じ Anthos Service Meshversion（スクリプトでは許可されていない）を簡単に再インストールできます。		 利用できません。
--custom_overlay
複数のオーバーレイ ファイルを許可します。		 --custom_overlay
使用できるオーバーレイ ファイルは 1 つだけです。
--option
GitHub の asm パッケージからオーバーレイ ファイルを pull します。		 利用できません。
次のオプションを使用してカスタム CA をサポートします。

--ca_cert
--ca_key
--root_cert
--cert_chain

利用できません。