Fleet API を使用してマネージド Anthos Service Mesh を構成する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要

マネージド Anthos Service Mesh は、簡単に有効にできる Google のマネージド サービス メッシュです。信頼性、アップグレード、スケーリング、セキュリティについては Google が下位互換性のある方法で対応します。

このページでは、フリート機能 API を使用してマネージド Anthos Service Mesh を設定する方法について説明します。

Fleet API を使用してマネージド Anthos Service Mesh を有効にする場合:

  • Google が推奨されるコントロール プレーン構成を適用します。
  • Google が自動データプレーン管理を有効にします。
  • クラスタは Google Kubernetes Engine(GKE)クラスタのリリース チャンネルに基づいて Anthos Service Mesh リリース チャンネルに登録され、コントロール プレーンとデータプレーンは新しいリリースごとに最新の状態に保たれます。
  • Google は、デフォルト設定でサービス メッシュ全体のエンドポイント検出とクラスタ間負荷分散を有効にしますが、ファイアウォール ルールを作成する必要があります。

必要に応じてこのオンボーディング パスを使用します。

  • gcloud を使用して、Google Cloud APIs と IAM を使用するマネージド Anthos Service Mesh を構成する。
  • 他のフリート機能と同じ API を使用して Anthos Service Mesh を構成する。
  • 各クラスタの推奨の Anthos Service Mesh の構成を自動的に取得する。

前提条件

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

要件

  • サポートされているいずれかのリージョンで、サポート対象バージョンの GKE を使用している 1 つ以上のクラスタ。
  • マネージド Anthos Service Mesh をインストールするクライアント マシンと API サーバーとのネットワーク接続を確認します。
  • クラスタは、フリートに登録されている必要があります。この操作は手順にも含まれていますが、インストールの前に個別に行うこともできます。
  • パブリック エンドポイント アクセスが無効または承認済みネットワークに限定された限定公開クラスタを登録する場合は、gcloud 登録コマンドを実行するマシンがクラスタの外部エンドポイントにアクセスできることを確認するか、そのマシンの外部 IP をクラスタの承認済みネットワークに追加します。
  • プロジェクトでサービス メッシュのフリート機能が有効になっている必要があります。この操作は手順にも含まれていますが、個別に行うこともできます。
  • GKE Autopilot は GKE バージョン 1.21.3 以降でのみサポートされています。 CNI は Google によってインストール、管理されます。

  • マネージド Anthos Service Mesh では、単一プロジェクトの単一ネットワーク環境またはマルチプロジェクトの単一ネットワーク環境で複数の GKE クラスタを使用できます。

制限事項

マネージド Anthos Service Mesh でサポートされている機能と制限事項のリストを確認することをおすすめします。特に、次の点に注意してください。

  • IstioOperator API は、クラスタ内のコンポーネントを制御することが主な目的であるため、サポートされていません。

  • Fleet API でマネージド Anthos Service Mesh を有効にすると、Mesh CA が使用されます。サービス メッシュ デプロイで Certificate Authority Service(CA Service)が必要な場合は、asmcli を使用したマネージド Anthos Service Mesh の構成に沿ってください。

  • GKE Autopilot クラスタの場合、プロジェクト間の設定は GKE 1.23 以降でのみサポートされます。 GKE Autopilot リソースの上限に適応するために、デフォルトのプロキシ リソース リクエストと上限は 500m CPU と 512 Mb のメモリに設定されています。

  • マネージド データプレーンは、Regular と Rapid のリリース チャンネルで使用できます。

  • マネージド Anthos Service Mesh で利用できる実際の機能は、リリース チャンネルによって異なります。詳細については、マネージド Anthos Service Mesh でサポートされている機能と制限事項のリストをご覧ください。

  • マネージド コントロール プレーンのプロビジョニング プロセス中に、選択したチャンネルに対応する Istio CRD が指定のクラスタにインストールされます。クラスタに既存の Istio CRD が存在している場合、それらは上書きされます。

始める前に

  1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
  2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  3. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

  4. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  5. Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

  6. Fleet Host プロジェクトで必要な API を有効にします。

      gcloud services enable mesh.googleapis.com \
          --project=FLEET_PROJECT_ID
    

ここで

  • FLEET_PROJECT_ID は、現在のプロジェクトの ID です。

mesh.googleapis.com を有効にして API を有効にする

API
meshconfig.googleapis.com
meshca.googleapis.com
container.googleapis.com
monitoring.googleapis.com
gkehub.googleapis.com
stackdriver.googleapis.com
opsconfigmonitoring.googleapis.com
connectgateway.googleapis.com

Anthos Service Mesh のフリート機能を有効にする

フリートで Anthos Service Mesh を有効にします。複数のクラスタを登録する場合、Anthos Service Mesh の有効化はフリートレベルで行われるため、このコマンドを実行する必要があるのは 1 回だけです。

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

各クラスタを構成する

メッシュ内の各クラスタに対してマネージド Anthos Service Mesh を構成するには、次の手順を行います。

gcloud を構成する

Cloud Shell を使用している場合でも、次の手順を実施します。

  1. Google Cloud CLI で認証します。

    gcloud auth login --project PROJECT_ID
    
  2. コンポーネントを更新します。

    gcloud components update
    
  3. クラスタを指すように kubectl を構成します。

    gcloud container clusters get-credentials CLUSTER_NAME \
         --zone CLUSTER_LOCATION \
         --project PROJECT_ID
    

クラスタをフリートに登録する

  1. フリートに Workload Identity を使用して、GKE クラスタを登録します。

    gcloud container fleet memberships register MEMBERSHIP_NAME \
      --gke-uri=GKE_URI \
      --enable-workload-identity \
      --project FLEET_PROJECT_ID
    

    ここで

    • MEMBERSHIP_NAME は、フリートに登録されているクラスタを一意に識別するために選択したメンバーシップ名です。

    • GKE_URI は GKE クラスタの URI です。 例: https://container.googleapis.com/v1/projects/my-gke-project/locations/us-central1-a/clusters/my-gke-cluster。URI を取得するには、gcloud container clusters list --uri を実行します。

  2. クラスタが登録されていることを確認します。

    gcloud container fleet memberships list --project FLEET_PROJECT_ID
    
  3. クラスタのプロジェクトがフリート ホスト プロジェクトと異なる場合は、フリート プロジェクトの Anthos Service Mesh サービス アカウントにクラスタ プロジェクトへのアクセスを許可する必要があります。この手順は、クラスタ プロジェクトごとに 1 回だけ行う必要があります。

    以前に asmcli を使用して、このクラスタとフリート プロジェクトの組み合わせに対してマネージド Anthos Service Mesh を構成していた場合、これらの変更はすでに適用されているため、次のコマンドを実行する必要はありません。

    フリート プロジェクトのサービス アカウントに、クラスタ プロジェクトにアクセスするための権限を付与します。

    gcloud projects add-iam-policy-binding "PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
    

mesh_id ラベルを適用する

ゾーンクラスタ

gcloud container clusters update  --project PROJECT_ID CLUSTER_NAME \
  --zone CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER

リージョン クラスタ

gcloud container clusters update  --project PROJECT_ID CLUSTER_NAME \
  --region CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER

ここで

  • PROJECT_ID はプロジェクトの一意の識別子です。
  • CLUSTER_NAME はクラスタの名前です。
  • CLUSTER_LOCATION は、クラスタのコンピューティング ゾーンまたはリージョンです。
  • FLEET_PROJECT_NUMBER は、フリート ホスト プロジェクトの一意の識別子です。

自動管理を有効にする

自動管理を有効にするには、次のコマンドを実行します。

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID

Ingress ゲートウェイはコントロール プレーンで自動的にはデプロイされないことに注意してください。Ingress ゲートウェイとコントロール プレーンのデプロイを分離すると、本番環境でゲートウェイを簡単に管理できます。クラスタに Ingress ゲートウェイまたは Egress ゲートウェイが必要な場合は、ゲートウェイをデプロイするをご覧ください。他のオプション機能を有効にするには、マネージド Anthos Service Mesh でオプション機能を有効にするをご覧ください。

コントロール プレーンがプロビジョニングされていることを確認する

  1. 数分後、コントロール プレーンのステータスが ACTIVE になっていることを確認します。

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    

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

    ...
    membershipSpecs:
      projects/746296320118/locations/global/memberships/demo-cluster-1:
        mesh:
          management: MANAGEMENT_AUTOMATIC
    membershipStates:
      projects/746296320118/locations/global/memberships/demo-cluster-1:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed'
            state: ACTIVE
          dataPlaneManagement:
            details:
            - code: OK
              details: Service is running.
            state: ACTIVE
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed.'
    ...
    

    details フィールドのリビジョン ラベルをメモします(出力の asm-managed など)。リビジョン ラベルを使用している場合は、アプリケーションのデプロイ前にこのラベルを設定する必要があります。デフォルトのインジェクション ラベルを使用している場合は、このラベルを設定する必要はありません。

マネージド データプレーン

Fleet API でマネージド Anthos Service Mesh を使用する場合、名前空間またはワークロード レベルでオプトアウトしない限り、Google はプロキシのアップグレードを完全に管理します。

有効にした場合、サイドカー プロキシと挿入されたゲートウェイは、ワークロードを再起動してプロキシの新しいバージョンを再挿入することで、マネージド コントロール プレーンと一緒に自動的に更新されます。無効になっている場合、プロキシ管理はクラスタ内の Pod の通常のライフサイクルに基づいて行われます。更新頻度を制御するには、ユーザーが手動でトリガーする必要があります。

マネージド データプレーンは、古いバージョンのプロキシを実行している Pod のエビクションを行うことで、プロキシをアップグレードします。エビクションは、Pod 停止予算を維持しながら変更率を制御することによって、段階的に行われます。

ここで注意することは、マネージド データプレーンには Istio Container Network Interface(CNI)プラグインが必要であり、これはマネージド コントロール プレーンをデプロイするときにデフォルトで有効であることです。

マネージド データプレーンでは、以下を管理しません。

  • 挿入されなかった Pod
  • 手動で挿入された Pod
  • Job
  • StatefulSet
  • DaemonSet

マネージド データプレーンは、自動的にプロビジョニングされるマネージド コントロール プレーンのリビジョンで有効になります。ただし、同じアノテーションを付けることで、特定の名前空間や Pod に対して選択的に無効にできます。個別のコンポーネントを選択的に制御する場合、優先順位はコントロール プレーンのリビジョン(有効)、名前空間、Pod の順になります。

名前空間のマネージド データプレーンを無効にするには:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

また、同じアノテーションを設定して、特定の Pod でマネージド データプレーンを無効にすることもできます。

メンテナンス通知を有効にする

メンテナンスが予定されている遅くとも 1 週間前に、メンテナンスの予定の通知を送信するようにリクエストできます。メンテナンス通知は、デフォルトでは送信されません。また、通知を受信するには、GKE メンテナンスの時間枠を構成する必要があります。

メンテナンス通知を受け取るには:

  1. [通信] ページに移動します。

    [通信] ページに移動

  2. [Anthos Service Mesh Upgrade] 行の [メール] 列で、メンテナンス通知をオンにするラジオボタンを選択します。

通知を受け取る必要があるユーザーごとに個別にオプトインできます。通知のメールフィルタを設定する場合、件名は次のようになります。

Upcoming upgrade for your ASM cluster "CLUSTER_LOCATION/CLUSTER_NAME"

エンドポイント ディスカバリを構成する(マルチクラスタ インストールのみ)

続行する前に、前の手順で説明したように各クラスタでマネージド Anthos Service Mesh を構成しておく必要があります。クラスタがプライマリ クラスタであることを示す必要はありません。これがデフォルトの動作です。

また、asmcli をダウンロードし(サンプル アプリケーションで構成を確認する場合にのみ)、プロジェクト変数とクラスタ変数を設定します。

一般公開クラスタ

一般公開クラスタ間のエンドポイント検出を構成する

Fleet API でマネージド Anthos Service Mesh を有効にすると、このクラスタのエンドポイント検出が有効になります。ただし、ファイアウォール ポートを開く必要があります。1 つ以上のクラスタのエンドポイント検出を無効にするには、宣言型 API を使用した一般公開クラスタ間のエンドポイント検出で、無効にする手順をご覧ください。

限定公開クラスタ

限定公開クラスタ間のエンドポイント検出の構成

Fleet API でマネージド Anthos Service Mesh を有効にすると、このクラスタのエンドポイント検出が有効になります。ただし、ファイアウォール ポートを開く必要があります。1 つ以上のクラスタのエンドポイント検出を無効にするには、宣言型 API を使用した限定公開クラスタ間のエンドポイント検出で無効にする手順をご覧ください。

2 つのクラスタがあるサンプル アプリケーションについては、HelloWorld サービスの例をご覧ください。

アプリケーションのデプロイ

アプリケーションをデプロイするには、インストール時に構成したチャネルに対応するラベルを使用するか、istio-injection=enabled を使用します(デフォルトのインジェクション ラベルを使用している場合)。

デフォルトのインジェクション ラベル

kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite

リビジョン ラベル

アプリケーションをデプロイする前に、名前空間から以前の istio-injection ラベルを削除し、代わりに istio.io/rev=REVISION_LABEL ラベルを設定します。

これは、コントロール プレーンを確認したときに特定したリビジョン ラベルです。特定のリビジョン ラベルに変更するには、REVISION_LABEL をクリックし、該当するラベル(Rapid の場合は asm-managed-rapid、Regular の場合は asm-managed、Stable の場合は asm-managed-stable)に置き換えます。

リビジョン ラベルはリリース チャンネルに対応しています。

リビジョン ラベル チャネル
asm-managed 標準
asm-managed-rapid 迅速
asm-managed-stable Stable
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite

この時点では、Anthos Service Mesh のマネージド コントロール プレーンが正常に構成されています。ラベル付きの名前空間に既存のワークロードがある場合は、それらを再起動して、プロキシが挿入されるようにします。

これで、アプリケーションをデプロイする準備が整い、Bookinfo サンプル アプリケーションをデプロイできます。

マルチクラスタ設定にアプリケーションをデプロイする場合、その特定の構成ファイルをクラスタの一部に制限する予定がなければ、すべてのクラスタに Kubernetes とコントロール プレーンの構成を複製します。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。

コントロール プレーンの指標の確認

コントロール プレーンとデータプレーンのバージョンは、Metrics Explorer で確認できます。

構成が正しく機能することを確認するには:

  1. Google Cloud コンソールで、コントロール プレーンの指標を確認します。

    Metrics Explorer に移動

  2. ワークスペースを選択し、次のパラメータを使用してカスタムクエリを追加します。

    • Resource type: Kubernetes Container
    • Metric: Proxy Clients
    • Filter: container_name="cr-REVISION_LABEL"
    • Group By: revision ラベルと proxy_version ラベル
    • Aggregator sum
    • Period: 1 minute

    Google マネージドのコントロール プレーンとクラスタ内コントロール プレーンの両方で Anthos Service Mesh を実行する場合は、そのコンテナ名を使用してそれぞれの指標を区別できます。たとえば、マネージド指標には container_name="cr-asm-managed" が含まれ、非マネージド指標には container_name="discovery" が含まれます。両方の指標を表示するには、container_name="cr-asm-managed" の Filter を削除します。

  3. Metrics Explorer で次のフィールドを調べて、コントロール プレーンとプロキシのバージョンを確認します。

    • [revision] は、コントロール プレーンのバージョンを示します。
    • [proxy_version] は proxy_version を示します。
    • [value] は、接続されたプロキシの数を示します。

    現在のチャンネルと Anthos Service Mesh バージョンのマッピングについては、チャンネルごとの Anthos Service Mesh のバージョンをご覧ください。

アプリケーションをマネージド Anthos Service Mesh に移行する

クラスタ内の Anthos Service Mesh からマネージド Anthos Service Mesh にアプリケーションを移行するには、次の手順を実行します。

  1. 現在の名前空間のラベルを置き換えます。必要な手順は、デフォルトのインジェクション ラベルistio-injection enabled など)またはリビジョン ラベルをご覧ください。

    デフォルトのインジェクション ラベル

    1. 次のコマンドを実行して、デフォルトタグをマネージド リビジョンに移動します。

      istioctl tag set default --revision REVISION_LABEL
      
    2. まだ実行していない場合は、次のコマンドを実行し、istio-injection=enabled を使用して名前空間にラベルを付けます。

      kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \
      --overwrite
      

    リビジョン ラベル

    istio.io/rev=REVISION_LABEL ラベルを使用した場合は、次のコマンドを実行します。

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
        --overwrite
    
  2. 名前空間で Deployment のローリング アップグレードを実行します。

    kubectl rollout restart deployment -n NAMESPACE
    
  3. アプリケーションをテストして、ワークロードが正しく機能することを確認します。

  4. 他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。

  5. マルチクラスタ設定にアプリケーションをデプロイした場合は、すべてのクラスタに Kubernetes と Istio の構成を複製します。ただし、その構成をクラスタの一部に制限する場合を除きます。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。

  6. コントロール プレーンの指標の確認の手順に沿って、指標が想定どおりに表示されることを確認します。

アプリケーションが期待どおりに動作していることを確認したら、すべての名前空間をマネージド コントロール プレーンに切り替えた後にクラスタ内の istiod を削除できます。また、これらをバックアップとして残すこともできます。この場合、istiod が自動的にスケールダウンし、リソースの使用量が少なくなります。削除するには、古いコントロール プレーンを削除するに進みます。

問題が発生した場合は、マネージド コントロール プレーンの問題を解決するを参照して問題を特定し、解決します。また、必要であれば以前のバージョンにロールバックできます。

古いコントロール プレーンを削除する

すべての名前空間で Google 管理のコントロール プレーンが使用されていることを確認したら、古いコントロール プレーンを削除できます。

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

自動インジェクションではなく istioctl kube-inject を使用した場合や、追加のゲートウェイをインストールした場合は、コントロール プレーンの指標をチェックし、接続されているエンドポイントの数がゼロであることを確認します。

ロールバック

前のコントロール プレーン バージョンにロールバックする必要がある場合は、次の手順を行います。

  1. コントロール プレーンの以前のバージョンで挿入されるワークロードを更新します。次のコマンドのリビジョン値 asm-191-1 はサンプルとして使用されています。このサンプル値は、前のコントロール プレーンのリビジョン ラベルに置き換えてください。

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE
    

未使用時は、マネージド コントロール プレーンは自動的にゼロへスケーリングされ、リソースを使用しません。Webhook の変更とプロビジョニングはそのまま残り、クラスタの動作には影響しません。

これでゲートウェイが asm-managed リビジョンに設定されました。ロールバックするには、Anthos Service Mesh のインストール コマンドを再実行します。これにより、クラスタ内コントロール プレーンを参照するゲートウェイが再デプロイされます。

kubectl -n istio-system rollout undo deploy istio-ingressgateway

正常に実行されると、次の出力が表示されます。

deployment.apps/istio-ingressgateway rolled back

自動管理を無効にする

自動管理を無効にしても、リソースはプロビジョニング解除されません。手動で管理や削除を行えるように、すべてのリソースがクラスタに残っています。

  1. 自動管理を無効にするには、次のコマンドを実行します。

    gcloud container fleet mesh update \
       --management manual \
       --memberships MEMBERSHIP_NAME \
       --project FLEET_PROJECT_ID
    
  2. 数分後、コントロール プレーンの管理のステータスが DISABLED になっていることを確認します。

    gcloud container fleet mesh describe --project PROJECT_ID
    

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

    ...
    membershipSpecs:
      projects/projectid/locations/global/memberships/cluster-name:
        mesh:
          controlPlane: management
    membershipStates:
      projects/projectid/locations/global/memberships/cluster-name:
        servicemesh:
          controlPlaneManagement:
            state: DISABLED
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed.'
    ...
    

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

Anthos Service Mesh を完全にアンインストールする場合は、Anthos Service Mesh のアンインストールをご覧ください。

トラブルシューティング

マネージド コントロール プレーンを使用する際の問題を特定して解決するには、マネージド コントロール プレーンの問題を解決するをご覧ください。

次のステップ