Anthos Service Mesh 1.11 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

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

概要

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

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

前提条件

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

Cloud プロジェクト。
Cloud 請求先アカウント。
インストールスクリプト、kpt、必要なツールのインストールで指定されているその他のツール。

要件

サポートされているいずれかのリージョンで、サポート対象バージョンの GKE を使用している 1 つ以上のクラスタ。
クラスタで Workload Identity が有効になっている必要があります。gcloud コマンドについては、Workload Identity を有効にするをご覧ください。
Google 管理のデータプレーンでは、Google 管理のコントロールプレーンをデプロイするときに、Istio Container Network Interface（CNI）プラグインを有効にする必要があります（詳細はこのページの後半で説明します）。

移行

クラスタ内コントロールプレーンから Google 管理のコントロールプレーンへの直接移行 / アップグレードは、Mesh CA と一緒にインストールされているバージョン 1.9 以降でのみサポートされます。
Istio CA を使用してインストールする場合は、先に 1.9 以降の Mesh CA に移行する必要があります。
間接移行 / アップグレードがサポートされています。つまり、クラスタ内コントロールプレーンで Anthos Service Mesh 1.11 に到達するまでは、各バージョンで標準の Anthos Service Mesh のアップグレードパスを使用できます。その後、Google が管理するコントロールプレーンに移行できます。

制限事項

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

マネージド Anthos Service Mesh は、単一の Google Cloud プロジェクト内でのみ複数の GKE クラスタを使用できます。
IstioOperator API はサポートされていません。
マネージドデータプレーンの制限事項:
- このマネージドデータプレーンのプレビューリリースは、マネージドコントロールプレーンの新しいデプロイでのみ使用できます。マネージドコントロールプレーンをすでにデプロイしており、マネージドデータプレーンをデプロイする場合は、Google 管理のコントロールプレーンを適用するで説明するように、インストールスクリプトを再度実行する必要があります。
- マネージドデータプレーンは、Regular と Rapid のリリースチャンネルで使用できます。

Workload Identity を有効にする

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

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

Anthos Service Mesh 1.11.8 をインストールするスクリプトの最新バージョンを、現在の作業ディレクトリにダウンロードします。
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
```
スクリプトを実行可能にします。
```
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 を実行するときには、次の 2 つのオプションを含めることをおすすめします。

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

これらのオプションは、Google 管理のデータプレーンをデプロイする場合に必要です。オプションの完全なリストについては、asmcli リファレンスページをご覧ください。

  ./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 管理のデータプレーンを有効にするには:

データプレーン管理を有効にします。
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
また、同じアノテーションを設定して、特定の Pod で Google マネージドデータプレーンを有効にすることもできます。特定の Pod にアノテーションを設定すると、その Pod は Google 管理のサイドカープロキシを使用し、残りのワークロードは管理されていないサイドカープロキシを使用します。
マネージドデータプレーンを作成する名前空間ごとに、前の手順を繰り返します。

フリートで 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 トラフィックを処理できます。

この 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-
```

次のシンプルな例を使用して、ゲートウェイの 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

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 が管理するコントロールプレーンは、単一プロジェクト、単一ネットワーク、マルチプライマリ構成をサポートします。ただし、コントロールプレーンはクラスタにインストールされない点が異なります。

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

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

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

メッシュ内の他のすべてのクラスタ（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}

次のコマンドを実行して、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

現在のクラスタが既存のマルチクラスタメッシュに追加された場合、他のすべてのクラスタが現在のクラスタに対応する Secret を作成することで、現在のクラスタのエンドポイントを検出できるようにします。
```
./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}
```

また、他のクラスタの 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 で確認できます。

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

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

Metrics Explorer に移動
ワークスペースを選択し、次のパラメータを使用してカスタムクエリを追加します。
- 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 を削除します。
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 に移行するには、次の手順を行います。

Google 管理のコントロールプレーンを適用するの手順に沿ってスクリプトを実行します。
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
```

現在の名前空間のラベルを istio.io/rev:asm-managed-rapid ラベルに置き換えます。

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

名前空間で Deployment のローリングアップグレードを実行します。
```
kubectl rollout restart deployment -n NAMESPACE
```
アプリケーションをテストして、ワークロードが正しく機能することを確認します。
他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。
マルチクラスタ設定にアプリケーションをデプロイした場合は、すべてのクラスタに Kubernetes と Istio の構成を複製します。ただし、その構成をクラスタの一部に制限する場合を除きます。特定のクラスタに適用される構成は、そのクラスタに対する信頼できる情報源です。
コントロールプレーンの指標の確認の手順に沿って、指標が想定どおりに動作することを確認します。

クラスタには、さまざまなリビジョンを混在させることができ、たとえば、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 を使用した場合や、追加のゲートウェイをインストールした場合は、コントロールプレーンの指標をチェックし、接続されているエンドポイントの数がゼロであることを確認します。

ロールバック

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

コントロールプレーンの以前のバージョンで挿入されるワークロードを更新します。次のコマンドのリビジョン値 asm-191-1 はサンプルとして使用されています。このサンプル値は、前のコントロールプレーンのリビジョンラベルに置き換えてください。
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
プロキシが 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 管理のコントロールプレーンに移行する

ドキュメントを使用して、ゲートウェイの新しいバージョンに Kubernetes Deployment を作成します。サービス構成の selector フィールドを使用して、古いバージョンと新しいバージョンの両方を選択するように既存の Kubernetes Gateway サービスを構成する必要があります。
これらの kubectl scale を使用して、新しい Deployment を徐々にスケールアップします。また、古い Deployment をスケールダウンし、サービスの中断やダウンタイムの兆候を確認します。移行が成功すると、サービスが中断されることなく、古いインスタンスがゼロになるはずです。

アンインストール

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

トラブルシューティング

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

次のステップ

リリースチャンネルについて確認する。