バージョン 1.10

マネージド Anthos Service Mesh を構成する

概要

マネージド Anthos Service Mesh は、Google が管理するコントロール プレーンで、お客様は、オプションのデータプレーンの構成だけを行い、信頼性、アップグレード、スケーリング、セキュリティについては Google が下位互換性のある方法で対応します。このガイドでは、単一クラスタまたはマルチクラスタの構成で、マネージド Anthos Service Mesh にアプリケーションを設定または移行する方法について説明します。

マネージド Anthos Service Mesh でサポートされる機能と制限事項については、マネージド Anthos Service Mesh でサポートされる機能をご覧ください。

前提条件

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

要件

制限事項

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

  • マネージド Anthos Service Mesh は、単一の Google Cloud プロジェクト内でのみ複数の GKE クラスタを使用できます。

  • IstioOperator API はサポートされていません。

  • マネージド データプレーンの制限事項:

    • このマネージド データプレーンのプレビュー リリースは、マネージド コントロール プレーンの新しいデプロイでのみ使用できます。マネージド コントロール プレーンをすでにデプロイしており、マネージド データプレーンをデプロイする場合は、Google 管理のコントロール プレーンを適用するで説明するように、インストール スクリプトを再度実行する必要があります。

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

Workload Identity を有効にする

Workload Identity が有効になっていない場合は、クラスタで Workload Identity を有効にするで、必要な IAM 権限と、それを有効にする gcloud コマンドラインをご確認ください。

インストール スクリプトをダウンロードする

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
    
  2. スクリプトを実行可能にします。

    chmod +x install_asm
    

各クラスタを構成する

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

クラスタ認証情報を取得する

適切な認証情報を取得します。次のコマンドでは、kubectl コンテキストもターゲット クラスタを指すように設定されます。

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

Google 管理のコントロール プレーンを適用する

マネージド Anthos Service Mesh を使用するクラスタごとに install_asm インストール スクリプトを実行します。install_asm を実行するときには、次のオプションを含めることをおすすめします。

  • --option cni-managed: このオプションを使用すると、Istio Container Network Interface(CNI)プラグインが有効になります。CNI プラグインは、権限の高い init コンテナを使用する代わりに、CNCF CNI インターフェースを使用して、サイドカー プロキシ間のネットワーク トラフィックのリダイレクトを構成します。

  • --enable-registration: このフラグは、クラスタをフリートに登録します。

これらのオプションは、Google 管理のデータプレーンをデプロイする場合に必要です。

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

このスクリプトは、マネージド コントロール プレーンの構成に必要なすべてのファイルを --output_dir で指定された場所にダウンロードして、istioctl ツールやサンプル アプリケーションと一緒に Istio Gateway をインストールします。このガイドの手順では、インストール ディレクトリのルートで istioctl が実行され、istioctl がその /bin サブディレクトリにあることを前提としています。

同じクラスタで install_asm を再実行すると、既存のコントロール プレーンの構成が上書きされます。同じ構成が必要な場合は、同じオプションとフラグを指定してください。

Ingress ゲートウェイはコントロール プレーンで自動的にはデプロイされないことに注意してください。Ingress ゲートウェイとコントロール プレーンのデプロイを分離すると、本番環境でゲートウェイを簡単に管理できます。クラスタに Ingress ゲートウェイが必要な場合は、Istio ゲートウェイのインストールをご覧ください。

Google 管理のデータプレーンを適用する

Google 側でプロキシのアップグレードを管理するようにするには、Google 管理のデータプレーンを有効にします。有効にした場合、サイドカー プロキシと挿入されたゲートウェイがマネージド コントロール プレーンと一緒に自動的にアップグレードされます。

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

このマネージド データプレーンのプレビュー リリースでは、次のものは管理されません。

  • 挿入されなかった Pod。
  • istioctl kube-inject を使用して手動で挿入された Pod。
  • Job
  • StatefulSet
  • DaemonSet

マネージド データプレーンを使用しない場合や、一部の名前空間で有効にしない場合は、最新のプロキシ イメージを利用できるようにプロキシの再起動をトリガーする必要があります。コントロール プレーンは既存のプロキシで引き続き機能します。

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

Google 管理のデータプレーンを有効にするには:

  1. データプレーン管理を有効にします。

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

    また、同じアノテーションを設定して、特定の Pod で Google マネージド データプレーンを有効にすることもできます。特定の Pod にアノテーションを設定すると、その Pod は Google 管理のサイドカー プロキシを使用し、残りのワークロードは管理されていないサイドカー プロキシを使用します。

  2. マネージド データプレーンを作成する名前空間ごとに、前の手順を繰り返します。

  3. フリートで Anthos Service Mesh を有効にします。

    gcloud alpha container hub mesh enable --project=PROJECT_ID
    

データプレーン コントローラがクラスタ内のプロキシを管理する準備が整うまでに 10 分ほどかかります。次のコマンドを実行してステータスを確認します。

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

データプレーン コントローラの準備ができていると、コマンドの出力は Managed Data Plane is ready. となります。

10 分以上待ってもデータプレーン コントローラのステータスが準備完了にならない場合は、マネージド データプレーンのステータスでトラブルシューティングのヒントをご覧ください。

Google 管理のデータプレーンを無効にして、サイドカー プロキシの管理に戻す場合は、アノテーションを変更します。

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

Istio ゲートウェイをインストールする(省略可)

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

ゲートウェイに個別の名前空間を作成することをおすすめします。ゲートウェイを istio-system 名前空間にデプロイしないでください。

次の手順で 1 つ以上の Istio ゲートウェイをクラスタにインストールして、一般的な Ingress トラフィックを処理できます。

  1. この 2 つのオプションのいずれかを選択して、後の手順でゲートウェイをデプロイする名前空間を設定します。

    • インジェクションの Namespace を有効にします。
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
      

    または

    • ゲートウェイ Pod に対してのみインジェクションを有効にします。Namespace 内の一部の Pod は有効にできません。このコマンドですべてのインジェクション ラベルが削除されます。後で Pod 自体のインジェクションを有効にします。
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
      
  2. 次のシンプルな例を使用して、ゲートウェイの Deployment と Service を作成します。

    kubectl apply -f - << EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      type: LoadBalancer
      selector:
        istio: ingressgateway
      ports:
      - port: 80
        name: http
      - port: 443
        name: https
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      template:
        metadata:
          annotations:
            # This is required to tell Anthos Service Mesh to inject the gateway with the
            # required configuration.
            inject.istio.io/templates: gateway
          labels:
            istio: ingressgateway
            istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
        spec:
          containers:
          - name: istio-proxy
            image: auto # The image will automatically update each time the pod starts.
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: istio-ingressgateway-sds
    subjects:
    - kind: ServiceAccount
      name: default
    EOF
    
  3. Deployment を作成したら、新しいサービスが正常に動作していることを確認します。

    kubectl get pod,service -n GATEWAY_NAMESPACE
    

    次のような出力が表示されるのを確認します。

    NAME                                      READY   STATUS    RESTARTS   AGE
    pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
    
    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
    service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

サービスの場合と同様に、マネージド データプレーン コントローラにゲートウェイのプロキシを管理させることもできます。マネージド データプレーンをデプロイし、ゲートウェイ プロキシを管理対象にする場合は、Google 管理のデータプレーンを適用するの説明に従って、ゲートウェイ名前空間にラベルを付けてアノテーションを設定します。

ゲートウェイをユーザー側で管理する場合は、Anthos Service Mesh の新しいバージョンがリリースされたときに GATEWAY_NAMESPACE の Pod を再起動して、新しいコントロール プレーンの構成を取得する必要があります。Pod を再起動する前に、コントロール プレーンの指標を確認するで説明されている Metrics Explorer カスタムクエリを使用してコントロール プレーンのバージョンを確認して、新しいコントロール プレーンがクラスタにロールアウトされたことを確認する必要があります。

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

Anthos Service Mesh が管理するコントロール プレーンは、単一プロジェクト、単一ネットワーク、マルチプライマリ構成をサポートします。ただし、コントロール プレーンはクラスタにインストールされない点が異なります。マルチプライマリ構成とは、各クラスタが他のすべてのクラスタに対する Secret を使用して構成されていることを意味します。これにより、各クラスタが他のすべてのクラスタのエンドポイントを検出できるようになります。

続行する前に、前の手順で説明したインストール スクリプトが各クラスタで実行されている必要があります。あるクラスタがプライマリ クラスタであることを示す必要はなく、これがデフォルトの動作です。

各クラスタで、メッシュ内の他のすべてのクラスタ i=1..N に対して次のコマンドを 1 回実行することで、エンドポイント ディスカバリを有効にします。

  1. クラスタごとに、kubectl 構成ファイル コンテキストが現在のクラスタを指すようにします。

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
    
  2. メッシュ内の他のすべてのクラスタ(i = 1..N)で次のコマンドを実行して、エンドポイント ディスカバリを有効にします。

    export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i
    
    ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
      kubectl apply -f - --context=${CTX}
    
  3. 次のコマンドを実行して、Secret が作成されていることを確認します。

    kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
    

    次のような出力が表示されることを確認します。

    NAME                                   TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s
    
  4. 現在のクラスタが既存のマルチクラスタ メッシュに追加された場合、他のすべてのクラスタが現在のクラスタに対応する Secret を作成することで、現在のクラスタのエンドポイントを検出できるようにします。

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
      kubectl apply -f - --context=${CTX_i}
    
  5. また、他のクラスタの Secret を確認することもできます。

    kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}
    

    次のような出力が表示されることを確認します。

    NAME                            TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME   Opaque   1      44s
    

詳細と 2 つのクラスタを含む例については、エンドポイント ディスカバリを有効にするをご覧ください。

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

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

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

この時点では、Anthos Service Mesh のマネージド コントロール プレーンが正常に構成されています。これで、アプリケーションをデプロイする準備が整い、Bookinfo サンプル アプリケーションをデプロイできます。

マルチクラスタ設定にアプリケーションをデプロイする場合、その特定の構成ファイルをクラスタの一部に制限する予定がなければ、すべてのクラスタに Kubernetes とコントロール プレーンの構成を複製します。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。また、Mesh CA が他の名前空間にある状態で、このクラスタが Anthos Service Mesh 1.7、1.8、またはそれ以降を実行している場合、アプリケーションが、クラスタ内コントロール プレーンによって制御される他のアプリケーションと通信できることを確認します。

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

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

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

  1. Cloud Console でコントロール プレーンの指標を表示します。

    Metrics Explorer に移動

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

    • Resource type: Kubernetes Container
    • Metric: Proxy Clients
    • Filter: container_name="cr-asm-managed-rapid"
    • 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 は、Mesh CA を使用する Anthos Service Mesh 1.9 からの移行のみをサポートします。

マネージド Anthos Service Mesh に移行するには、次の手順を行います。

  1. Google 管理のコントロール プレーンを適用するの手順に沿ってスクリプトを実行します。

  2. Google 管理のコントロール プレーンとデータプレーンの両方をデプロイした場合:

    1. データプレーン管理を有効にします。

      kubectl annotate --overwrite namespace NAMESPACE \
      mesh.cloud.google.com/proxy='{"managed":"true"}'
      
    2. フリートで Anthos Service Mesh を有効にします。

      gcloud alpha container hub mesh enable --project=PROJECT_ID
      
  3. 現在の名前空間のラベルを istio.io/rev:asm-managed-rapid ラベルに置き換えます。

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

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

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

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

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

クラスタには、さまざまなリビジョンを混在させることができ、たとえば、Anthos Service Mesh 1.7 および 1.8 と、クラスタ内コントロール プレーンを一緒に使用できます。異なる Anthos Service Mesh コントロール プレーンのリビジョンを使用して、複数の名前空間を制限なく混在できます。

アプリケーションが想定どおりに動作していることを確認したら、すべての名前空間をクラスタ内コントロール プレーンに切り替えた後でクラスタ内 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

ゲートウェイを Google 管理のコントロール プレーンに移行する

  1. ドキュメントを使用して、ゲートウェイの新しいバージョンに Kubernetes Deployment を作成します。サービス構成の selector フィールドを使用して、古いバージョンと新しいバージョンの両方を選択するように既存の Kubernetes Gateway サービスを構成する必要があります。

  2. これらの kubectl scale を使用して、新しい Deployment を徐々にスケールアップします。また、古い Deployment をスケールダウンし、サービスの中断やダウンタイムの兆候を確認します。移行が成功すると、サービスが中断されることなく、古いインスタンスがゼロになるはずです。

アンインストール

名前空間が使用されていない場合、Google が管理するコントロール プレーンは自動的にゼロにスケールされるため、アンインストールは不要です。

トラブルシューティング

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

次のステップ