Anthos Service Mesh をインストールする

このページでは、次の作業の方法を説明します。

• asmcli を実行して Anthos Service Mesh 1.11.8-asm.4 を新規にインストールします。
• 必要に応じて、Ingress ゲートウェイをデプロイします。
• サイドカー プロキシを挿入するには、ワークロードをデプロイまたは再デプロイします。

注: サービス メッシュに Compute Engine 仮想マシンを追加する準備として、asmcli を使用してマネージド Anthos Service Mesh をデプロイし、Anthos Service Mesh を GKE にインストールしていても、asmcli install を実行するときに特定のコマンドライン オプションを使用する必要があります。また、追加の手順と注意が必要な制限事項があります。これらの機能のインストール手順については、以下をご覧ください。

• マネージド Anthos Service Mesh を構成する
• サービス メッシュに Compute Engine 仮想マシンを追加する

注: GKE Autopilot クラスタの場合、マネージド Anthos Service Mesh のみがサポートされます。現在、GKE Autopilot に対する Anthos Service Mesh サポートはプレビュー版で、GKE Rapid チャンネルとバージョン 1.21.3 以降でのみ利用できます。

始める前に

始める前に、次のことを行ってください。

• 前提条件を確認する。
• インストールの計画を確認する。
• 必要なツールをインストールする。
• asmcli をダウンロードする。
• クラスタ管理者の権限を付与する。
• プロジェクトとクラスタを検証する。

警告: Anthos Service Mesh が正常に機能するよう、istiod と canonical-service-controller-manager をクラスタにデプロイします。すべてのデプロイメントを変更する機能や、すべてのクラスタ シークレットを変更する機能などの、ロールベースのアクセス制御（RBAC）の権限が昇格されています。これらの権限は、サイドカーの挿入、サービスの検出、トラフィックの保護、Ingress ゲートウェイの管理、サービス ダッシュボードの表示などの、Anthos Service Mesh の機能に必要です。

Anthos Service Mesh をインストールする

Anthos Service Mesh のインストール方法の概要は次のとおりです。

1. asmcli install を実行して、単一のクラスタにクラスタ内コントロール プレーンをインストールします。コマンドラインの例については、以降のセクションをご覧ください。これらの例には、必須の引数とオプション引数の両方が含まれています。サンプルのゲートウェイやツール（istioctl など）を簡単に見つけられるように、必ず output_dir 引数を指定することをおすすめします。例の一覧については、右側のナビゲーション バーをご覧ください。

2. 限定公開の GKE クラスタでは、istiod へのトラフィックを許可するために追加のファイアウォール構成手順が必要です。

3. 必要に応じて、Ingress ゲートウェイをインストールします。デフォルトでは、asmcli は istio-ingressgateway をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。クラスタ内コントロール プレーンにデフォルトの istio-ingressgateway をインストールする必要がある場合は、--option legacy-default-ingressgateway 引数を指定します。

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

5. Anthos Service Mesh を複数のクラスタにインストールする場合は、各クラスタで asmcli install を実行します。asmcli install を実行する場合は、クラスタごとに同じ FLEET_PROJECT_ID を使用するようにしてください。Anthos Service Mesh をインストールしたら、マルチクラスタ メッシュの設定方法を確認してください。

6. クラスタがアイランド モードで異なるネットワーク上にある場合は、--network_id フラグを使用して、一意のネットワーク名を asmcli に渡す必要があります。

デフォルトの機能と Mesh CA をインストールする

このセクションでは、asmcli を実行して、プラットフォームのデフォルトのサポート機能を使用して Anthos Service Mesh をインストールし、認証局として Anthos Service Mesh 認証局（Mesh CA）を有効にする方法について説明します。

プラットフォームに関する注意:Mesh CA は、GKE on AWS や Amazon EKS ではサポートされていません。これらのプラットフォームで --ca mesh_ca を指定して asmcli install を実行すると、インストールに失敗します。

GKE

次のコマンドを実行して、デフォルトの機能と Mesh CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。

./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 はここでは機能しません。
  注: この --output_dir ディレクトリをメモしておきます。ゲートウェイをデプロイするときに、これを参照する必要があります。
• --enable_all: スクリプトが次の処理を行います。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • クラスタを登録する（まだ登録されていない場合）。
• --ca mesh_ca: 認証局として Mesh CA を使用します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。

オンプレミス

GKE on VMware または Google Distributed Cloud Virtual for Bare Metal で次のコマンドを実行して、デフォルト機能と Mesh CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./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 はここでは機能しません。また、kubeconfig ファイルの相対的な場所（「~」を使用した相対名）も機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
   • --platform multicloud: プラットフォームがオンプレミスやマルチクラウドなど、Google Cloud 以外であることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • --ca mesh_ca: 認証局として Mesh CA を使用します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。

デフォルトの機能と Certificate Authority（CA）Service をインストールする

このセクションでは、asmcli を実行して、プラットフォームのデフォルトでサポートされている機能を使用して Anthos Service Mesh をインストールし、認証局として CA Service を有効にする方法について説明します。

プラットフォームに関する注: CA Service は、Google Cloud 上の GKE クラスタでのみサポートされています。他のプラットフォームで --ca gcp_cas を指定して asmcli install を実行すると、インストールに失敗します。

Mesh CA に加えて、Certificate Authority Service を使用するように Anthos Service Mesh を構成できます。このガイドでは、CA Service とのインテグレーションについて説明します。このインテグレーションは、次のようなユースケースでおすすめします。

• 異なるクラスタ上のワークロード証明書への署名に別の認証局が必要な場合。
• istiod カスタム CA プラグイン証明書を使用する場合。
• Google が管理する HSM に署名鍵を元に戻す必要がある場合。
• 規制の厳しい業界で、コンプライアンスの対象となっている場合。
• Anthos Service Mesh CA をカスタム エンタープライズ ルート証明書のチェーンに追加して、ワークロード証明書に署名する場合。

メッシュ CA の費用は Anthos Service Mesh の料金に含まれています。CA Service は Anthos Service Mesh の基本料金に含まれず、別途課金されます。また、CA Service には明示的な SLA が提供されますが、Mesh CA には提供されません。

このインテグレーションでは、Anthos Service Mesh のワークロードすべてに 2 つの IAM ロールが付与されます。

• privateca.workloadCertificateRequester
• privateca.auditor

CA Service を構成する

1. CA プールを作成し、GKE クラスタと同じプロジェクトの CA プールに 1 つ以上の有効な認証局を設定します。下位 CA を使用して Anthos Service Mesh のワークロード証明書に署名します。下位 CA に対応する CA プールをメモします。
2. CA プールが階層 DevOps 内にあり、CA のプールがクラスタと同じリージョンにあることを確認します。これにより、過大なレイテンシの問題や、リージョン間にわたるサービス停止の可能性を回避できます。詳細については、ワークロードに最適化された階層をご覧ください。

3. Anthos Service Mesh ワークロードのサービス証明書のみを目的とする場合は、CA プールに次の発行ポリシーを設定します。マルチクラスタ メッシュの場合は、一意のクラスタ リージョンごとに 1 つの下位 CA プールを設定することをおすすめします。下位 CA プールはすべて、同じルート CA プールのチェーンに追加する必要があります。

   policy.yaml

   baselineValues:
     keyUsage:
       baseKeyUsage:
         digitalSignature: true
         keyEncipherment: true
       extendedKeyUsage:
         serverAuth: true
         clientAuth: true
     caOptions:
       isCa: false
   identityConstraints:
     allowSubjectPassthrough: false
     allowSubjectAltNamesPassthrough: true
     celExpression:
       expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
   

4. CA プールの発行ポリシーを更新するには、次のコマンドを使用します。

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

プールにポリシーを設定する方法については、証明書発行ポリシーの使用をご覧ください。

CA Service を使用するように Anthos Service Mesh を構成する

1. CA として認証局サービスを使用する Anthos Service Mesh コントロール プレーンをインストールします。

   ./asmcli install \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --enable_all \
     --ca gcp_cas \
     --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

2. HTTP/TCP の受信接続や発信接続を受信するように Ingress ゲートウェイをインストールします。詳細については、ゲートウェイのインストールをご覧ください。

3. Anthos Service Mesh のインストールを完了して、ワークロードの自動サイドカー プロキシ インジェクションを有効にします。詳細については、ワークロードのデプロイと再デプロイをご覧ください。

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 間の信頼の階層を確立します。この手順を繰り返して、任意の数の認証局の証明書と鍵をプロビジョニングできます。

重要: この手順では、説明用の例として make コマンドで証明書と鍵を作成します。最高レベルのセキュリティを確保するには、オフラインの安全なコンピュータと本番環境用ツールを使用します。たとえば、HashiCorp Vault を使用して、CA 署名鍵を安全に生成して保護します。

証明書を生成する Makefile は、asmcli validate コマンドで指定した --output_dir ディレクトリの istio-1.11.8-asm.4 サブディレクトリにあります。asmcli validate を実行していない場合、またはディレクトリをローカルにダウンロードしていない場合は、Anthos Service Mesh インストール ファイルをダウンロードして内容を抽出し、Makefile を取得します。

1. istio-1.11.8-asm.4 ディレクトリに移動します。

2. 証明書と鍵のディレクトリを作成します。

   mkdir -p certs && \
   pushd certs

3. ルート証明書と鍵を生成します。

   make -f ../tools/certs/Makefile.selfsigned.mk root-ca
   

   これにより、次のファイルが生成されます。

   • root-cert.pem: ルート証明書
   • root-key.pem: ルート鍵
   • root-ca.conf: ルート証明書を生成するための openssl の構成
   • root-cert.csr: ルート証明書の CSR

4. 中間証明書と鍵を生成します。

   make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

   これにより、cluster1 という名前のディレクトリにファイルが生成されます。

   • ca-cert.pem: 中間証明書
   • ca-key.pem: 中間鍵
   • cert-chain.pem: istiod が使用する証明書チェーン
   • root-cert.pem: ルート証明書
   注: cluster1 は別の名前に置き換えることができます。たとえば、make mycluster-cacerts は mycluster という名前のディレクトリを作成します。

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

5. 前のディレクトリに戻ります。

   popd

6. asmcli を実行し、Istio CA を使用してメッシュをインストールします。

   GKE

   次のコマンドを実行して、デフォルトの機能と Istio CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。

    ./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 はここでは機能しません。
     注: この --output_dir ディレクトリをメモしておきます。ゲートウェイをデプロイするときに、これを参照する必要があります。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。

   • -ca citadel: 認証局として Istio CA を使用します。
   • --ca_cert: 中間証明書
   • --ca_key: 中間証明書の鍵
   • --root_cert: ルート証明書
   • --cert_chain: 証明書チェーン

   オンプレミス

   GKE on VMware または Google Distributed Cloud Virtual for Bare Metal で次のコマンドを実行して、デフォルト機能と Istio CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。

   1. 現在のコンテキストをユーザー クラスタに設定します。

      kubectl config use-context CLUSTER_NAME
      

   2. asmcli install を実行します。

      ./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 はここでは機能しません。また、kubeconfig ファイルの相対的な場所（「~」を使用した相対名）も機能しません。
      • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
      • --platform multicloud: プラットフォームがオンプレミスやマルチクラウドなど、Google Cloud 以外であることを指定します。
      • --enable_all: スクリプトが次の処理を行います。
        • 必要な IAM 権限を付与する。
        • 必要な Google API を有効にする。
        • メッシュを識別するラベルをクラスタに設定する。
        • クラスタを登録する（まだ登録されていない場合）。
      • -ca citadel: 認証局として Istio CA を使用します。
      • --ca_cert: 中間証明書
      • --ca_key: 中間証明書の鍵
      • --root_cert: ルート証明書
      • --cert_chain: 証明書チェーン

   AWS

   GKE on AWS で次のコマンドを実行して、デフォルトの機能と Istio CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。公開サブネットまたは非公開サブネットで Ingress を有効にすることもできます。

   公開

   1. 現在のコンテキストをユーザー クラスタに設定します。

      kubectl config use-context CLUSTER_NAME
      

   2. asmcli install を実行します。

      ./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 はここでは機能しません。また、kubeconfig ファイルの相対的な場所（「~」を使用した相対名）も機能しません。
      • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
      • --platform multicloud: プラットフォームがオンプレミスやマルチクラウドなど、Google Cloud 以外であることを指定します。
      • --enable_all: スクリプトが次の処理を行います。
        • 必要な IAM 権限を付与する。
        • 必要な Google API を有効にする。
        • メッシュを識別するラベルをクラスタに設定する。
        • クラスタを登録する（まだ登録されていない場合）。
      • -ca citadel: 認証局として Istio CA を使用します。
      • --ca_cert: 中間証明書
      • --ca_key: 中間証明書の鍵
      • --root_cert: ルート証明書
      • --cert_chain: 証明書チェーン

   非公開

   1. 現在のコンテキストをユーザー クラスタに設定します。

      kubectl config use-context CLUSTER_NAME
      

   2. 次の YAML を istio-operator-internal-lb.yaml というファイルに保存します。

      apiVersion: install.istio.io/v1alpha1
      kind: IstioOperator
      spec:
        components:
          ingressGateways:
          - enabled: true
            k8s:
              serviceAnnotations:
                service.beta.kubernetes.io/aws-load-balancer-internal: "true"
            name: istio-ingressgateway
      

   3. asmcli install を実行します。

      ./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 \
        --custom_overlay istio-operator-internal-lb.yaml
      

      • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
      • --kubeconfig: kubeconfig ファイルのフルパス。環境変数 $PWD はここでは機能しません。また、kubeconfig ファイルの相対的な場所（「~」を使用した相対名）も機能しません。
      • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
      • --platform multicloud: プラットフォームがオンプレミスやマルチクラウドなど、Google Cloud 以外であることを指定します。
      • --enable_all: スクリプトが次の処理を行います。
        • 必要な IAM 権限を付与する。
        • 必要な Google API を有効にする。
        • メッシュを識別するラベルをクラスタに設定する。
        • クラスタを登録する（まだ登録されていない場合）。
      • -ca citadel: 認証局として Istio CA を使用します。
      • --ca_cert: 中間証明書
      • --ca_key: 中間証明書の鍵
      • --root_cert: ルート証明書
      • --cert_chain: 証明書チェーン

   Amazon EKS

   Amazon EKS で次のコマンドを実行して、デフォルトの機能と Istio CA を備えたコントロール プレーンをインストールします。プレースホルダに値を入力します。

   1. 現在のコンテキストをユーザー クラスタに設定します。

      kubectl config use-context CLUSTER_NAME
      

   2. asmcli install を実行します。

      ./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 はここでは機能しません。また、kubeconfig ファイルの相対的な場所（「~」を使用した相対名）も機能しません。
      • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
      • --platform multicloud: プラットフォームがオンプレミスやマルチクラウドなど、Google Cloud 以外であることを指定します。
      • --enable_all: スクリプトが次の処理を行います。
        • 必要な IAM 権限を付与する。
        • 必要な Google API を有効にする。
        • メッシュを識別するラベルをクラスタに設定する。
        • クラスタを登録する（まだ登録されていない場合）。
      • -ca citadel: 認証局として Istio CA を使用します。
      • --ca_cert: 中間証明書
      • --ca_key: 中間証明書の鍵
      • --root_cert: ルート証明書
      • --cert_chain: 証明書チェーン

オプション機能を使用してインストールする

オーバーレイ ファイルは IstioOperator カスタム リソース（CR）を含む YAML ファイルです。asmcli に渡してコントロール プレーンを構成します。YAML ファイルを asmcli に渡すことで、デフォルトのコントロール プレーン構成をオーバーライドし、オプション機能を有効にできます。複数のオーバーレイを重ねることができます。各オーバーレイ ファイルは、以前のレイヤの構成をオーバーライドします。オーバーレイ ファイルは、バージョン管理システムに保存することをおすすめします。

GKE

次のコマンドを実行して、オプション機能を備えたコントロール プレーンをインストールします。複数のファイルを追加するには、--custom_overlay とファイル名を指定します（例: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml）。指定されたプレースホルダに値を入力します。

./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 はここでは機能しません。
  注: この --output_dir ディレクトリをメモしておきます。ゲートウェイをデプロイするときに、これを参照する必要があります。
• --enable_all: スクリプトが次の処理を行います。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • クラスタを登録する（まだ登録されていない場合）。
• --ca mesh_ca: 認証局として Mesh CA を使用します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。
• --custom_overlay: オーバーレイ ファイルの名前を指定します。

Google Cloud 以外

GKE on VMware、Google Distributed Cloud Virtual for Bare Metal、GKE on AWS、Amazon EKS で次のコマンドを実行します。プレースホルダに値を入力します。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行して、オプション機能を備えたコントロール プレーンをインストールします。複数のファイルを追加するには、--custom_overlay とファイル名を指定します（例: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml）。

   ./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 はここでは機能しません。また、kubeconfig ファイルの相対的な場所（「~」を使用した相対名）も機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
   • --platform multicloud: プラットフォームがオンプレミスやマルチクラウドなど、Google Cloud 以外であることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • --ca mesh_ca: 認証局として Mesh CA を使用します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。
   • --custom_overlay: オーバーレイ ファイルの名前を指定します。

ゲートウェイをインストールする

Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。

1. Ingress ゲートウェイの名前空間をまだ作成していない場合は作成します。ゲートウェイはユーザー ワークロードであり、コントロール プレーンの名前空間にデプロイすることはおすすめしません。GATEWAY_NAMESPACE は、名前空間の名前に置き換えます。

   kubectl create namespace GATEWAY_NAMESPACE
   

   予想される出力:

   namespace/GATEWAY_NAMESPACE created
   

2. ゲートウェイの名前空間にリビジョン ラベルを適用することで、ゲートウェイで自動インジェクションを有効にします。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロール プレーン リビジョンに関連付けます。

   1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

      kubectl get deploy -n istio-system -l app=istiod -o \
        "jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
      

      このコマンドは、Anthos Service Mesh バージョンに対応するリビジョン ラベル（例: asm-1118-4）を出力します。

   2. リビジョン ラベルを名前空間に適用します。次のコマンドで、REVISION は前の手順でメモした istiod リビジョン ラベルの値です。

      kubectl label namespace GATEWAY_NAMESPACE \
        istio.io/rev=REVISION --overwrite
      

      予想される出力:

      namespace/GATEWAY_NAMESPACE labeled
      

3. samples/gateways/istio-ingressgateway/ ディレクトリにある Ingress ゲートウェイ構成のサンプルをそのままデプロイするか、必要に応じて変更します。

   kubectl apply -n GATEWAY_NAMESPACE \
     -f DIR_PATH/samples/gateways/istio-ingressgateway
   

   予想される出力:

   deployment.apps/istio-ingressgateway created
   poddisruptionbudget.policy/istio-ingressgateway created
   horizontalpodautoscaler.autoscaling/istio-ingressgateway created
   role.rbac.authorization.k8s.io/istio-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
   service/istio-ingressgateway created
   serviceaccount/istio-ingressgateway created
   

ゲートウェイのベスト プラクティスの詳細を確認してください。

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

Anthos Service Mesh は、サイドカー プロキシを使用してネットワークのセキュリティ、信頼性、オブザーバビリティを強化します。Anthos Service Mesh では、これらの機能がアプリケーションのプライマリ コンテナから抽出され、同じ Pod 内の個別のコンテナとして提供される共通のプロセス外プロキシに実装されます。

インストールは、自動サイドカー プロキシ挿入（自動挿入）を有効化して、Anthos Service Mesh をインストールする前にクラスタで実行していたワークロードの Pod を再起動するまで完了しません。

自動挿入を有効にするには、Anthos Service Mesh をインストールしたときに istiod に設定したリビジョン ラベルで名前空間にラベルを付けます。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入できるように、名前空間内の既存の Pod を再起動する必要があります。

新しいワークロードを新しい名前空間にデプロイする前に、Anthos Service Mesh がトラフィックのモニタリングと保護を行えるように自動挿入を構成してください。

自動インジェクションを有効にするには:

1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

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

   出力は次のようになります。

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-1118-4-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-1118-4-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586

   出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョン ラベルの値をメモします。この例での値は asm-1118-4 です。

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 ラベルの削除が含まれています。

3. Anthos Service Mesh をインストールする前にクラスタでワークロードが実行されていた場合は、Pod を再起動して再インジェクションをトリガーします。

   Pod を再起動する方法は、アプリケーションとクラスタが属する環境によって異なります。たとえば、ステージング環境では、すべての Pod を削除するのみの場合がありますが、それによって Pod が再起動されます。ただし、本番環境では、Blue/Green デプロイを実装するプロセスにより、トラフィックが中断しないように Pod を安全に再起動できます。

   kubectl を使用すると、ローリングの再起動を実行できます。

   kubectl rollout restart deployment -n NAMESPACE
   

次のステップ

• マルチクラスタ メッシュの設定の詳細を確認する。

  • メッシュが GKE クラスタだけで構成されている場合は、GKE でマルチクラスタ メッシュを設定するをご覧ください。

  • メッシュが Google Cloud 外のクラスタで構成されている場合は、Google Cloud 外のマルチクラスタ メッシュを設定するをご覧ください。

• オンプレミスで外部 IP アドレスを構成する。

• Online Boutique サンプル アプリケーションをデプロイする。