このページでは、次の作業の方法を説明します。
asmcli
を実行して Anthos Service Mesh 1.10.6-asm.2 を新規にインストールします。- サイドカー プロキシを挿入するには、ワークロードをデプロイまたは再デプロイします。
始める前に
始める前に、次のことを行ってください。
Anthos Service Mesh をインストールする
Anthos Service Mesh のインストール方法の概要は次のとおりです。
asmcli install
を実行して、単一のクラスタにクラスタ内コントロール プレーンをインストールします。コマンドラインの例については、以降のセクションをご覧ください。これらの例には、必須の引数とオプション引数の両方が含まれています。サンプルのゲートウェイやツール(istioctl
など)を簡単に見つけられるように、必ずoutput_dir
引数を指定することをおすすめします。例の一覧については、右側のナビゲーション バーをご覧ください。必要に応じて、Ingress ゲートウェイをインストールします。
Anthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。
Anthos Service Mesh を複数のクラスタにインストールする場合は、各クラスタで
asmcli install
を実行します。Anthos Service Mesh をすべてのクラスタにインストールしたら、オンプレミスでのマルチクラスタ メッシュの設定をご覧ください。クラスタがアイランド モードで異なるネットワーク上にある場合は、
--network_id
フラグを使用して、一意のネットワーク名をasmcli
に渡す必要があります。
デフォルトの機能と Mesh CA をインストールする
このセクションでは、asmcli
を実行して、プラットフォームのデフォルトのサポート機能を使用して Anthos Service Mesh をインストールし、認証局として Anthos Service Mesh 認証局(Mesh CA)を有効にする方法について説明します。
GKE
次のコマンドを実行して、デフォルト機能を備えた新しいコントロール プレーンをインストールします。プレースホルダに値を入力します。
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--fleet_id FLEET_PROJECT_ID \
--output_dir DIR_PATH \
--enable_all \
--ca mesh_ca
--project_id
、--cluster_name
、--cluster_location
: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。--fleet_id
: フリート ホスト プロジェクトのプロジェクト ID。このオプションを指定しない場合、asmcli
は、クラスタ登録時にクラスタが作成されたプロジェクトを使用します。--output_dir
:asmcli
がanthos-service-mesh
パッケージをダウンロードして、istioctl
、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli
はファイルをtmp
ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--enable_all
: スクリプトが次の処理を行います。- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する(まだ登録されていない場合)。
--ca mesh_ca
: 認証局として Mesh CA を使用します。asmcli
は、フリート Workload Identity を使用するように Mesh CA を構成します。
オンプレミス
現在のコンテキストをユーザー クラスタに設定します。
kubectl config use-context CLUSTER_NAME
次のコマンドを実行して、デフォルト機能を備えた新しいコントロール プレーンをインストールします。プレースホルダに値を入力します。
./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca mesh_ca
--fleet_id
: フリート ホスト プロジェクトのプロジェクト ID。--kubeconfig
:kubeconfig
ファイルのパス。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--output_dir
:asmcli
がanthos-service-mesh
パッケージをダウンロードして、istioctl
、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli
はファイルをtmp
ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--platform multicloud
: オンプレミスがプラットフォームであることを指定します。--enable_all
: スクリプトが次の処理を行います。- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する(まだ登録されていない場合)。
--ca mesh_ca
: 認証局として Mesh CA を使用します。asmcli
は、フリート Workload Identity を使用するように Mesh CA を構成します。
Istio CA とデフォルト機能をインストールする
このセクションでは、次の方法を説明します。
- Anthos Service Mesh がワークロードの署名に使用する Istio CA の証明書と鍵を生成します。
asmcli
を実行して、デフォルト機能を使用して Anthos Service Mesh をインストールし、Istio 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: ルート証明書
オフラインのコンピュータを使用してこれらの手順を行う場合は、生成されたディレクトリを、クラスタにアクセスできるコンピュータにコピーします。
前のディレクトリに戻ります。
popd
asmcli
を実行し、Istio CA を使用してメッシュをインストールします。GKE
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --fleet_id FLEET_PROJECT_ID \ --output_dir DIR_PATH \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH
--project_id
、--cluster_name
、--cluster_location
: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。--fleet_id
: フリート ホスト プロジェクトのプロジェクト ID。このオプションを指定しない場合、asmcli
は、クラスタ登録時にクラスタが作成されたプロジェクトを使用します。--output_dir
:asmcli
がanthos-service-mesh
パッケージをダウンロードして、istioctl
、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli
はファイルをtmp
ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--enable_all
: スクリプトが次の処理を行います。- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する(まだ登録されていない場合)。
-ca citadel
: 認証局として Istio CA を使用します。--ca_cert
: 中間証明書--ca_key
: 中間証明書の鍵--root_cert
: ルート証明書--cert_chain
: 証明書チェーン
オンプレミス
現在のコンテキストをユーザー クラスタに設定します。
kubectl config use-context CLUSTER_NAME
次のコマンドを実行して、デフォルトの機能と Istio CA を使用する Anthos Service Mesh をインストールします。
./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH
--fleet_id
: フリート ホスト プロジェクトのプロジェクト ID。--kubeconfig
:kubeconfig
ファイルのパス。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--output_dir
:asmcli
がanthos-service-mesh
パッケージをダウンロードして、istioctl
、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli
はファイルをtmp
ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--platform multicloud
: オンプレミスがプラットフォームであることを指定します。--enable_all
: スクリプトが次の処理を行います。- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する(まだ登録されていない場合)。
-ca citadel
: 認証局として Istio CA を使用します。--ca_cert
: 中間証明書--ca_key
: 中間証明書の鍵--root_cert
: ルート証明書--cert_chain
: 証明書チェーン
オプション機能を使用してインストールする
オーバーレイ ファイルは IstioOperator
カスタム リソース(CR)を含む YAML ファイルです。asmcli
に渡してコントロール プレーンを構成します。YAML ファイルを asmcli
に渡すことで、デフォルトのコントロール プレーン構成をオーバーライドし、オプション機能を有効にできます。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。
GKE
次のコマンドを実行して、デフォルト機能を備えた新しいコントロール プレーンをインストールします。プレースホルダに値を入力します。
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--fleet_id FLEET_PROJECT_ID \
--output_dir DIR_PATH \
--enable_all \
--ca mesh_ca \
--custom_overlay OVERLAY_FILE
--project_id
、--cluster_name
、--cluster_location
: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。--fleet_id
: フリート ホスト プロジェクトのプロジェクト ID。このオプションを指定しない場合、asmcli
は、クラスタ登録時にクラスタが作成されたプロジェクトを使用します。--output_dir
:asmcli
がanthos-service-mesh
パッケージをダウンロードして、istioctl
、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli
はファイルをtmp
ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--enable_all
: スクリプトが次の処理を行います。- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する(まだ登録されていない場合)。
--ca mesh_ca
: 認証局として Mesh CA を使用します。asmcli
は、フリート Workload Identity を使用するように Mesh CA を構成します。--custom_overlay
: オーバーレイ ファイルの名前を指定します。
オンプレミス
現在のコンテキストをユーザー クラスタに設定します。
kubectl config use-context CLUSTER_NAME
次のコマンドを実行して、デフォルト機能を備えた新しいコントロール プレーンをインストールします。プレースホルダに値を入力します。
./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca mesh_ca \ --custom_overlay OVERLAY_FILE
--fleet_id
: フリート ホスト プロジェクトのプロジェクト ID。--kubeconfig
:kubeconfig
ファイルのパス。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--output_dir
:asmcli
がanthos-service-mesh
パッケージをダウンロードして、istioctl
、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli
はファイルをtmp
ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数$PWD
はここでは機能しません。--platform multicloud
: オンプレミスがプラットフォームであることを指定します。--enable_all
: スクリプトが次の処理を行います。- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する(まだ登録されていない場合)。
--ca mesh_ca
: 認証局として Mesh CA を使用します。asmcli
は、フリート Workload Identity を使用するように Mesh CA を構成します。--custom_overlay
: オーバーレイ ファイルの名前を指定します。
ゲートウェイをインストールする
Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。
Ingress ゲートウェイの名前空間をまだ作成していない場合は作成します。ゲートウェイはユーザー ワークロードであり、コントロール プレーンの名前空間にデプロイすることはおすすめしません。
GATEWAY_NAMESPACE
は、名前空間の名前に置き換えます。kubectl create namespace GATEWAY_NAMESPACE
ゲートウェイの名前空間にリビジョン ラベルを適用することで、ゲートウェイで自動インジェクションを有効にします。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロール プレーン リビジョンに関連付けます。使用するリビジョン ラベルは、マネージド Anthos Service Mesh をデプロイしたか、クラスタ内コントロール プレーンをデプロイしたかによって異なります。
次のコマンドを使用して、
istiod
のリビジョン ラベルを探します。kubectl -n istio-system get pods -l app=istiod --show-labels
出力は次のようになります。
NAME READY STATUS RESTARTS AGE LABELS istiod-asm-1106-2-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1106-2-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
出力の
LABELS
列で、接頭辞istio.io/rev=
に続くistiod
リビジョン ラベルの値をメモします。この例での値はasm-1106-2
です。リビジョン ラベルを名前空間に適用します。次のコマンドで、
REVISION
は前の手順でメモしたistiod
リビジョン ラベルの値です。kubectl label namespace GATEWAY_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
ラベルの削除が含まれています。--output_dir
で指定したディレクトリに移動します。samples/gateways/istio-ingressgateway/
ディレクトリにある Ingress ゲートウェイ構成のサンプルをそのままデプロイするか、必要に応じて変更します。kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
ゲートウェイのベスト プラクティスの詳細を確認してください。
ワークロードのデプロイと再デプロイ
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-1106-2-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1106-2-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
出力の
LABELS
列で、接頭辞istio.io/rev=
に続くistiod
リビジョン ラベルの値をメモします。この例での値はasm-1106-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
ラベルの削除が含まれています。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
次のステップ
GKE: マルチメッシュを設定する
オンプレミス: