このページでは、同じ Google Cloud プロジェクトにある 1 つ以上のクラスタを含むメッシュの GKE クラスタに Anthos Service Mesh バージョン 1.8.6 をインストールするスクリプトの実行方法について説明します。
クラスタが異なるプロジェクトにあるマルチクラスタ メッシュについては、マルチクラスタ / マルチ プロジェクト インストールと GKE の移行をご覧ください。
このページでは Anthos Service Mesh のインストール(新規インストールまたは別の構成による同じバージョンのインストール)について説明します。
新規インストール用のスクリプトの実行は、同じバージョンの再インストール、アップグレード、Istio からの移行の場合でも同様ですが、これらのユースケースでは別の計画が必要になります。詳細については、次のページをご覧ください。
始める前に
移行を開始する前に、次のことが完了していることを確認してださい。
このスクリプトを使用するには、必要な権限が付与されているか、スクリプトが権限を有効にできるように --enable_all
フラグまたは --enable_gcp_iam_roles
フラグを追加する必要があります。同様に、スクリプトで必要な API を有効にしてクラスタを更新できるようにするには、--enable_all
フラグを指定するか、よりきめ細かい有効化フラグを指定します。
Anthos Service Mesh のインストール
オプションを設定し、スクリプトの実行フラグを指定します。常に
--project_id
、--cluster_name
、--cluster_location
、--mode install
のオプションを含めます。Citadel を CA として使用する場合、Citadel を CA として使用したインストールで説明されているように、--ca
オプションとその他のオプションを指定する必要があります。スクリプトの引数の詳細については、オプションとフラグをご覧ください。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 間の信頼の階層を確立します。この手順を繰り返して、任意の数の認証局の証明書と鍵をプロビジョニングできます。
証明書と鍵のディレクトリを作成します。
mkdir -p certs && \ pushd certs
ルート証明書と鍵を生成します。
make -f ../tools/certs/Makefile.selfsigned.mk root-ca
これにより、次のファイルが生成されます。
- root-cert.pem: ルート証明書
- root-key.pem: ルート鍵
- root-ca.conf: ルート証明書を生成するための openssl の構成
- root-cert.csr: ルート証明書の CSR
中間証明書と鍵を生成します。
make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts
これにより、
cluster1
という名前のディレクトリにファイルが生成されます。- ca-cert.pem: 中間証明書
- ca-key.pem: 中間鍵
- cert-chain.pem: istiod が使用する証明書チェーン
- root-cert.pem: ルート証明書
これらの手順をオフライン コンピュータで行う場合は、生成されたディレクトリを、スクリプトを実行しているコンピュータにコピーします。
スクリプトを実行して、証明書と鍵用に以前に生成したファイルを含めます。
./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 のプレビュー版は、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 がトラフィックのモニタリングと保護を行えるように自動挿入を構成してください。
自動インジェクションを有効にするには:
次のコマンドを使用して、
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
です。リビジョン ラベルを適用し、存在する場合は
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
ラベルの削除が含まれています。Anthos Service Mesh をインストールする前にクラスタでワークロードが実行されていた場合は、Pod を再起動して再インジェクションをトリガーします。
Pod を再起動する方法は、アプリケーションとクラスタが属する環境によって異なります。たとえば、ステージング環境では、すべての Pod を削除するのみの場合がありますが、それによって Pod が再起動されます。ただし、本番環境では、Blue/Green デプロイを実装するプロセスにより、トラフィックが中断しないように Pod を安全に再起動できます。
kubectl
を使用すると、ローリングの再起動を実行できます。kubectl rollout restart deployment -n NAMESPACE
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 に対するアクセス制御を参照)を付与する必要があります。
Google Cloud コンソールで、[Anthos Service Mesh] に移動します。
メニューバーのプルダウン リストから Google Cloud プロジェクトを選択します。
複数のサービス メッシュがある場合は、[サービス メッシュ] プルダウン リストからメッシュを選択します。
詳細については、Google Cloud コンソールでの Anthos Service Mesh の確認をご覧ください。
Anthos Service Mesh ページに加えて、サービスに関連する指標(特定のサービスで受信したリクエストの数など)が Cloud Monitoring に送信され、Metrics Explorer に表示されます。
指標を表示するには:
Google Cloud コンソールで、[Monitoring] ページに移動します。
[リソース] > [Metrics Explorer] を選択します。
指標の完全なリストについては、Cloud Monitoring のドキュメントの Istio 指標をご覧ください。