Anthos Service Mesh 1.7 のドキュメントを表示しています。最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

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

このガイドでは、同じプロジェクトにある 1 つ以上の GKE クラスタを含むメッシュ用に Anthos Service Mesh バージョン 1.7.3 をインストール、移行、アップグレードする方法について説明します。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 の違い

  • Anthos サブスクライバーの場合は、Anthos API を必ず有効にしてください。

    API の有効化

  • Anthos のサブスクライバーでない場合も Anthos Service Mesh をインストールできますが、Google Cloud Console の一部の UI 要素と機能は Anthos のサブスクライバーのみが使用できます。サブスクライバーと非サブスクライバーが使用できる機能については、Anthos と 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.3 でサポートされていない GKE バージョンをベースにしていることがあります。詳細については、サポートされている環境をご覧ください。静的 GKE バージョンがある場合は、既存のクラスタをリリース チャンネルに登録するの手順に従ってください。

  • サービス メッシュに含めるには、サービスポートに名前を付ける必要があります。名前には、name: protocol[-suffix] の構文でポートのプロトコルを含める必要があります。角かっこは、ダッシュで始まるオプションの接尾辞です。詳細については、サービスポートの命名をご覧ください。

  • 限定公開クラスタに Anthos Service Mesh をインストールする場合は、ファイアウォールでポート 15017 を開き、自動サイドカー インジェクションで使用される Webhook が適切に機能する必要があります。詳細については、限定公開クラスタのポートを開くをご覧ください。

  • 組織にサービス境界を作成した場合は、Mesh CA サービスを境界に追加する必要があります。詳細については、サービス境界へのメッシュ CA の追加をご覧ください。

  • 移行の場合、istiodistio-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 を実行するローカルマシン上で実行できます。Cloud Shell で必要なすべてのツールがプリインストールされます。 macOS には bash の古いバージョンが付属しているため、サポートされませんので注意してください。

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

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

    • Cloud SDKgcloud コマンドライン ツール)
    • 標準のコマンドライン ツール: awkcurlgrepsedsha256sumtr
    • git
    • kpt
    • kubectl
    • jq
  2. Cloud SDK で認証します。

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

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

スクリプトの実行

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

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

    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.3 がインストールされます。

  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 になります。互換性を維持するために、上記のコマンドで --ignore-missing フラグを使用して、スクリプトの任意のバージョンを install_asm に変更できます。

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

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

    • project_idcluster_namecluster_location の各オプションでは、Anthos Service Mesh をインストールするクラスタを識別します。
    • mode は、installmigrateupgrade のいずれかです。
    • 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

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

次の例では、新規インストールを行い、インストールをカスタマイズするために作成した IstioOperator YAML ファイルを含めています。次のコマンドでは、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 ファイルを指定して、外向きゲートウェイを有効にします。.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

アップグレード

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

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

オプションとフラグ

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

オプション

-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」と入力します。「upgrade」を入力して、既存の Anthos Service Mesh インストールを新しいバージョンにアップグレードします。
-c|--ca {mesh_ca|citadel}
新規インストールの場合、このスクリプトではデフォルトが Mesh CA であるため、Mesh CA を使用する場合は、このオプションを指定する必要はありません。アップグレードの場合、このスクリプトでは CA を変更できないため、このオプションを指定する必要はありません。移行の場合、citadel または mesh_ca を指定します。移行のダウンタイムをスケジューリングできる場合は、mesh_ca を使用することをおすすめします。使用する CA について詳しくは、認証局の選択をご覧ください。Citadel の使用時に指定する必要のある追加オプションについては、Citadel のカスタム証明書のオプションをご覧ください。
--co|--custom_overlay YAML_FILE
asm-gcp プロファイルで有効になっていない機能を有効にするための YAML ファイルの名前。スクリプトで検出できる場所に YAML ファイルを配置する必要があります。そのため、ファイルはスクリプトと同じディレクトリに存在する必要がありますが、そのかわりに相対パスを指定することもできます。複数のファイルを追加するには、--co|--custom_overlay とファイル名を指定します。例: -co overlay_file1.yaml -co overlay_file2.yaml -co overlay_file3.yaml

-o|--option OPTION_FILE asm 内の YAML ファイルの名前。適用する .yaml 拡張子はありません。これらのファイルのいずれかを含める際は、asm パッケージを最初にダウンロードする必要はありません。いずれかのファイルを変更する必要がある場合は、asm パッケージをダウンロードし、変更を加え、--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.3-asm.6 サブディレクトリが格納されます。asm ディレクトリには、インストールの構成が格納されます。istio-1.7.3-asm.6 ディレクトリには、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
オプション、フラグ、終了を説明するヘルプ メッセージを表示します。

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-173-6 形式のリビジョン ラベルを 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-173-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-173-6,istio=istiod,pod-template-hash=85d86774f7
    istiod-asm-173-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-173-6,istio=istiod,pod-template-hash=85d86774f7

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

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

自動挿入の有効化

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

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

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

    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. プロキシが以前のバージョンになるように、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 スクリプトを使用して、同じバージョンの Anthos Service Mesh を再インストールすることはできません。同じバージョンを再インストールする必要がある場合は、istioctl コマンドライン ツールを使用します。たとえば、オプション機能を有効化するオーバーレイ ファイルを追加、削除、変更する必要がある場合に、再インストールが必要になる場合があります。

同じバージョンを再インストールする手順は、次のとおりです。

  1. istioctl が含まれるインストール ファイルをダウンロードして抽出する出力ディレクトリを作成します。

  2. --print_config オプションを指定して次のコマンドを実行し、コントロール プレーンの現在の構成を取得し、istio-config.yaml に出力します。

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME \
      --cluster_location CLUSTER_LOCATION \
      --mode install \
      --output_dir DIR_PATH \
      --print_config > istio-config.yaml
  3. istioctl がパスに含まれるディレクトリを追加します。

    export PATH=DIR_PATH/bin:$PATH
  4. スクリプトが istiod に追加されたリビジョン ラベルの値を取得します。

  5. istioctl install を実行し、istio-config.yaml ファイルを含めます。必要に応じて、-f オプションを指定して他のオーバーレイ ファイルを含めます。次のコマンドで、REVISION を前の手順のリビジョンに置き換えます。

    istioctl install \
     -f istio-config.yaml \
     -f OVERLAY_FILE \
     --set revision=REVISION

    ファイルの順序は重要ですので注意してください。基本構成を istio-config.yaml に組み込み、次にオーバーレイ ファイルを組み込みます。

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

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

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

  1. Google Cloud Console で、[Anthos Service Mesh] に移動します。

    Anthos Service Mesh に移動する

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

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

詳細については、Cloud Console での Anthos Service Mesh の確認をご覧ください。

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

指標を表示するには:

  1. Google Cloud Console で、[Monitoring] ページに移動します。

    [モニタリング] に移動

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

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

クラスタの登録

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

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

スクリプトについて

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

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

validate_argsvalidate_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 ラベルを設定します。これは、Cloud Console の Anthos Service Mesh ページに指標を表示するために必要です。

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

  • スクリプトを実行している 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 をインストールします。

次のステップ