Anthos Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

Istio on GKE から Anthos Service Mesh への移行

このガイドでは、Istio on Google Kubernetes Engine（Istio on GKE）バージョン 1.4 または 1.6（ベータ版）を使用している Google Kubernetes Engine（GKE）クラスタを、Google マネージドコントロールプレーンと Anthos Service Mesh 認証局（Mesh CA）を含むマネージド Anthos Service Mesh にアップグレードする方法について説明します。

前提条件

このガイドを完了するには、次の要件を満たす必要があります。

GKE クラスタで Istio on GKE を有効にする必要があります。複数の GKE クラスタがある場合は、すべてのクラスタで同じ操作を行います。
Istio on GKE をバージョン 1.4 または 1.6 にする必要があります。
GKE バージョン 1.17.17-gke.3100 以降、1.18.16-gke.1600 以降、1.19.8-gke.1600 以降を実行している必要があります。
GKE クラスタは、所定のロケーションのいずれかで実行されている必要があります。
このスクリプトを実行するユーザーまたはサービスアカウントには、プロジェクトの設定で説明されている IAM 権限が必要です。
このガイドは Cloud Shell でテストされているため、このガイドの手順を実行する場合は Cloud Shell を使用することをおすすめします。

目標

Regular チャンネルで Anthos Service Mesh の Google マネージドコントロールプレーンをデプロイします。このガイドは Regular チャンネルのみを対象としています。Stable チャンネルまたは Rapid チャンネルでは手順を若干変更する必要があります。リリースチャンネルの詳細については、こちらのリンクをご覧ください。
Istio 構成を Anthos Service Mesh に移行します。
メッシュ CA を構成します。
アプリケーションを Anthos Service Mesh に移行します。
istio-ingressgateway を Istio on GKE から Anthos Service Mesh にアップグレードします。
Anthos Service Mesh の移行を完了するか、Istio on GKE にロールバックします。

環境を設定する

環境の設定手順は次のとおりです。

Google Cloud Console で、[Cloud Shell をアクティブにする] をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開き、コマンドラインプロンプトが表示されます。Cloud Shell は Google Cloud CLI を使用したシェル環境で、Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
注: このスクリプトは macOS では機能しません。このスクリプトは Cloud Shell でのみテストされています。このスクリプトを使用するには、次のアプリケーションが必要です（すべて Cloud Shell にデフォルトで含まれています）。
- gcloud（バージョン 346.0.0 以降）
- kubectl（クライアントバージョン 1.21 以降）
- jq
- sed
- curl
- awk

このガイドで使用する環境変数を作成します。

# Enter your project ID
export PROJECT_ID=PROJECT_ID

# Copy and paste the following
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_1=GKE_CLUSTER_NAME
export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.

WORKDIR フォルダを作成します。このガイドに関連するすべてのファイルは WORKDIR になるため、終了時に WORKDIR を削除できます。
```
mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
```
このガイド用に KUBECONFIG ファイルを作成します。GKE クラスタのクラスタコンテキストを含む既存の KUBECONFIG ファイルを使用して、Anthos Service Mesh に移行することもできます。
```
touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
```

GKE クラスタの認証情報を取得し、コンテキストを変数に格納します。

ゾーンクラスタ

gcloud container clusters get-credentials ${CLUSTER_1} \
  --zone=${CLUSTER_1_LOCATION}

export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}

リージョンクラスタ

gcloud container clusters get-credentials ${CLUSTER_1} \
  --region=${CLUSTER_1_LOCATION}

export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}

クラスタは、フリートに登録されている必要があります。この操作は、インストールの前またはインストールの一部として個別に行うこともできます。その場合は、--enable-all または --enable-registration のいずれかのフラグと -fleet-id フラグを渡します。
プロジェクトでサービスメッシュ機能が有効になっている必要があります。インストールの一部として有効にするには、--enable-all フラグまたは --enable-registration フラグのいずれかを渡すか、インストール前に次のコマンドを実行します。
```
  gcloud container hub mesh enable --project=FLEET_PROJECT_ID
```
ここで、FLEET_PROJECT_ID はフリートホストプロジェクトのプロジェクト ID です。

省略可能な手順

クラスタが（master-authorized-networks が有効になっている）限定公開クラスタの場合は、$SHELL_IP を master-authorized-networks 許可リストに追加します。すでにクラスタにアクセスできる場合は、この操作を行う必要はありません。

ゾーンクラスタ

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --zone=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

リージョンクラスタ

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --region=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

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

このセクションでは、Regular チャンネルの Google マネージドコントロールプレーンを使用して、Anthos Service Mesh を GKE クラスタにデプロイします。このコントロールプレーンは、最初は 2 つ目の（またはカナリア）コントロールプレーンとしてデプロイされます。

Anthos Service Mesh をインストールする最新バージョンのスクリプトを現在の作業ディレクトリにダウンロードして、スクリプトを実行可能にします。
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
chmod +x asmcli
```
GKE クラスタを構成するには、インストールスクリプトを実行して、Google が管理する Regular チャンネルのコントロールプレーンを使用して Anthos Service Mesh をインストールします。
```
./asmcli install \
-p ${PROJECT_ID} \
-l ${CLUSTER_1_LOCATION} \
-n ${CLUSTER_1} \
--fleet_id ${FLEET_PROJECT_ID} \
--managed \
--verbose \
--output_dir ${CLUSTER_1} \
--enable-all \
--channel regular
```
処理が完了するまで数分かかることがあります。
Google マネージドコントロールプレーンを確認する
istioctl を WORKDIR フォルダにコピーします。
```
cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
```

次のセクションでは、Anthos Service Mesh への移行を行うため、migrate_addon スクリプトをダウンロードして実行します。istioctl コマンドラインユーティリティは、migrate_addon スクリプトと同じフォルダに配置する必要があります。istioctl コマンドラインユーティリティと migrate_addon スクリプトの両方に WORKDIR フォルダを使用します。

Anthos Service Mesh に構成を移行する

このセクションでは、Istio on GKE 構成を Anthos Service Mesh に移行します。ガイド付きスクリプトで、移行可能な構成と移行できない構成を特定します。

移行ツールをダウンロードして実行可能にします。

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
chmod +x ${WORKDIR}/migrate_addon

Galley 検証 Webhook を無効にします。この操作は、1.4 の構成の一部を Anthos Service Mesh に移行するために必要となります。両方の質問に「Y」と答えます。

${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook

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

tmpdir directory not present. Create directory? Continue? [Y/n] Y

Disabling the Istio validation webhook... Continue? [Y/n] Y
Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml
Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}]
clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched
Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found
Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found
validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted

構成を確認して手動で移行します。この手順では、ワークロードを Google マネージドコントロールプレーンに移行する前に、手動で移行する必要のある構成を確認できます。
```
${WORKDIR}/migrate_addon -d tmpdir --command config-check
```
出力は次のようになります。
```
Installing the authentication CR migration tool...
OK

Checking for configurations that will need to be explicitly migrated...
No resources found
```

カスタム構成を移行する

Anthos Service Mesh に移行する前に、カスタム構成を手動で移行することが必要になる場合があります。前述のスクリプトは、カスタム構成を識別し、必要な情報を出力します。カスタマイズは次のとおりです。

検出されたカスタム Envoy フィルタは、Anthos Service Mesh でサポートされません。可能であれば削除してください。Envoy フィルタは現在、Google マネージドコントロールプレーンでサポートされていません。
検出されたカスタムプラグイン証明書。プラグイン証明書は Anthos Service Mesh に移行されません。プラグイン証明書が Istio on GKE で使用されている場合、ワークロードが Google マネージドコントロールプレーンに移行した後、これらの証明書は使用されなくなります。すべてのワークロードは、Google Mesh CA によって署名された証明書を使用します。プラグイン証明書は Mesh CA ではサポートされていません。このメッセージは情報提供を目的としたものです。対処は必要ありません。
移行できなかったセキュリティポリシーを検出しました。<エラーの理由>。これは通常、手動での移行が必要なアルファ版の AuthZ ポリシーが原因で起きています。ポリシーの移行方法の詳細については、Istio 1.4 アルファ版のセキュリティポリシーを現在の API に移行するをご覧ください。エラーメッセージの詳細については、security-policy-migrate をご覧ください。
互換性のない可能性のある VirtualService 構成が検出されました。<特定の非推奨の構成>。以下の VirtualService 構成を更新する必要があります。
- appendHeaders の使用はサポートされていません。代わりに spec.http.headers を使用してください。
- websocketUpgrade を使用する必要はありません。これはデフォルトで有効になっています。
- フィールド abort.percent を abort.percentage に置き換えます。
移行できないミキサーリソースのカスタムインストールを検出しました。telemetryv2 に手動で移行する必要があります。デフォルトの Istio on GKE に加えてカスタムミキサーポリシーを構成している場合は、これらのポリシーをテレメトリー v2 に手動で移行する必要があります。詳しい方法については、Istio 指標のカスタマイズをご覧ください。
Deployment <deploymentName> はカスタムゲートウェイである必要があります。これは手動で移行してください。デフォルトでインストールされる istio-ingressgateway 以外のすべてのゲートウェイ Deployment を手動で移行する必要があります。Google マネージドコントロールプレーンのゲートウェイをアップグレードする方法については、Google マネージドコントロールプレーンの構成をご覧ください。

構成を移行するには、次の操作を行います。

すべてのカスタム構成（リストの最後の構成を除く）を手動で移行してから、手順 2 に進みます。

移行ツールを使用して、自動移行（または無視）できる構成を移行します。

${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs

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

Converting authentication CRs...
2021/06/25 20:44:58 found root namespace: istio-system
2021/06/25 20:44:59 SUCCESS converting policy /default
Running: kubectl apply --dry-run=client -f beta-policy.yaml
peerauthentication.security.istio.io/default created (dry run)

Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y
Running: kubectl apply -f beta-policy.yaml
peerauthentication.security.istio.io/default created
OK

Mesh CA ルート信頼を適用します。これにより、アプリケーションのダウンタイムなしで現在の Citadel CA から Mesh CA に移行できます。

${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca

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

Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y
Running: kubectl get cm -n istio-system istio-asm-managed -oyaml
Running: kubectl -n istio-system apply -f -
secret/meshca-root created
Running: kubectl get cm istio -n istio-system -o yaml
Running: kubectl get cm istio -n istio-system -o yaml
Running: kubectl replace -f -
configmap/istio replaced
Running: kubectl get deploy istio-pilot -n istio-system -o yaml
Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{
    "name":"discovery",
    "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12",
    "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}]
  }]}}}}
deployment.apps/istio-pilot patched
Running: kubectl get deploy istio-citadel -n istio-system -o yaml
Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{
    "containers":[{
      "name":"citadel",
      "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"],
      "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}]
    }],
    "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}]
  }}}}
deployment.apps/istio-citadel patched
OK

Waiting for root certificate to distribute to all pods. This will take a few minutes...
ASM root certificate not distributed to asm-system, trying again later
ASM root certificate not distributed to asm-system, trying again later
ASM root certificate distributed to namespace asm-system
ASM root certificate distributed to namespace default
ASM root certificate distributed to namespace istio-operator
ASM root certificate not distributed to istio-system, trying again later
ASM root certificate not distributed to istio-system, trying again later
ASM root certificate distributed to namespace istio-system
ASM root certificate distributed to namespace kube-node-lease
ASM root certificate distributed to namespace kube-public
ASM root certificate distributed to namespace kube-system
ASM root certificate distributed to namespace online-boutique
Waiting for proxies to pick up the new root certificate...
OK

Configuring Istio Addon 1.6 to trust Anthos Service Mesh...
Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found
Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml
Running: kubectl replace -f -
configmap/istio-istio-1611 replaced
Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge
istiooperator.install.istio.io/istio-1-6-11-gke-0 patched
Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem}
Running: kubectl -n istio-system patch secret istio-ca-secret
secret/istio-ca-secret patched
Running: kubectl patch deploy istiod-istio-1611 -n istio-system
deployment.apps/istiod-istio-1611 patched
Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system
Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination...
deployment "istiod-istio-1611" successfully rolled out
Running: kubectl apply -f - -n istio-system
envoyfilter.networking.istio.io/trigger-root-cert created
Waiting for proxies to pick up the new root certificate...
Running: kubectl delete envoyfilter trigger-root-cert -n istio-system
OK

この手順では、Anthos Service Mesh のルート証明書がすべての Namespace に分散されるまで数分かかります。スクリプトが、OK メッセージで終了するまで待ちます。

前の手順により、次の処理が実行されます。

クラスタ内のすべてのワークロードの Mesh CA ルートオブトラストをインストールします。
コントロールプレーンの Deployment istio-pilot、istiod、istio-citadel の構成を変更します。変更内容は次のとおりです。
- イメージを最新のビルドにアップグレードします。
- PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true を設定して trust-domain 検証を無効にします。
- ConfigMap をすべての Namespace に分散させるために、Mesh CA のルートオブトラストを istio-citadel に追加します。
- Mesh CA ルートオブトラストを istio-ca-secret に追加してルート証明書を配布します。
古い構成マニフェストを tmpdir に保存します。
後述のロールバック機能の手順を提供します。

ワークロードを Anthos Service Mesh に移行する

このセクションでは、Istio on GKE で実行されているワークロードを Anthos Service Mesh に移行します。移行後、正しいサイドカープロキシ（Anthos Service Mesh）がすべての Pod に挿入され、アプリケーションが想定どおり動作していることを確認します。

既存のクラスタでこの手順を実行する場合は、移行する Namespace を選択します。

Namespace を変数として定義します。この Namespace は Anthos Service Mesh に移行されます。
```
export NAMESPACE=NAMESPACE_NAME
```
ワークロードを Anthos Service Mesh に移行するには、Anthos Service Mesh の Namespace のラベルを変更する必要があります。Namespace にラベルを付けると、Anthos Service Mesh がすべてのワークロードにサイドカーを自動的に挿入できるようになります。Namespace にラベルを付けるには、ラベルを asm-managed に設定して次のコマンドを実行します。
```
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
```

Namespace 内のすべての Deployment のローリング再起動を実行します。

kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}

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

deployment.apps/deploymentName1 restarted
deployment.apps/deploymentName2 restarted
...

すべての Pod が再起動され、Pod ごとに 2 つのコンテナが実行されていることを確認します。
```
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
```
出力は次のようになります。
```
NAME                        READY   STATUS    RESTARTS   AGE
deploymentName1-PodName     2/2     Running   0          101s
deploymentName2-PodName     2/2     Running   2          100s
...
```
この手順を確認するには、Pod の AGE を確認します。値が短いこと（たとえば、数分）を確認します。
Namespace 内の任意の Deployment の 1 つの Pod のサイドカー Envoy プロキシのバージョンを調べて、Anthos Service Mesh Envoy プロキシがデプロイされていることを確認します。
```
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
```
出力は次のようになります。
```
"gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
"appContainerImage"
```

再起動後にアプリケーションを確認してテストします。

kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

（省略可）Google 側でプロキシのアップグレードを管理するようにするには、Google マネージドデータプレーンを有効にします。

移行ステータスを表示する

次のコマンドを実行して、移行のステータスを表示します。

kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}

出力では、移行が完了したか、保留中か、失敗したかが示されます。

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

migrationStatus が SUCCESS を出力していれば、コントロールプレーンは Anthos Service Mesh に正常にアップグレードされています。データプレーンを手動で更新するには、ワークロードの移行で手順を完了します。

migrationStatus の出力が SUCCESS 以外のステータスである場合、次のいずれかを選択できます。

移行エラーが既存の Istio on GKE ワークロードに影響を与えない場合は、特に何もする必要はありません。それ以外の場合は、必要に応じてロールバックします。
migrationStatus に MIGRATION_CONFIG_ERROR が表示される場合は、クラスタ内のカスタム構成を更新し、移行を手動で再実行します。

移行が正常に完了すると、Metrics Explorer にコントロールプレーンの指標が表示されます。verify_control_plane_metrics をご覧ください。

Anthos Service Mesh ダッシュボードにアクセスする

このセクションでは、Anthos Service Mesh ダッシュボードに移動し、すべての Service についてゴールデンシグナルを受信していることを確認します。アプリケーショントポロジの表示権限も必要です。

Google Cloud コンソールで、Anthos Service Mesh ページに移動します。

Anthos Service Mesh に移動する
Service の指標とトポロジの表示権限が必要です。

Anthos Service Mesh ダッシュボードの詳細については、Google Cloud コンソールでの Anthos Service Mesh の確認をご覧ください。

移行を正常に完了させる

このセクションでは、Istio on GKE から Anthos Service Mesh への移行を完了します。このセクションに進む前に、Anthos Service Mesh を続行していることを確認してください。このセクションは、Istio on GKE アーティファクトのクリーンアップにも役立ちます。Istio on GKE にロールバックする場合は、次のセクションに進みます。

istio-ingressgateway（GKE の標準 Istio の一部）を Google マネージドコントロールプレーンのバージョニングされたゲートウェイに置き換えます。

${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway

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

Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y
Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite
label "istio.io/rev" not found.
namespace/istio-system labeled
Running: kubectl apply -f -
serviceaccount/asm-ingressgateway created
deployment.apps/asm-ingressgateway created
role.rbac.authorization.k8s.io/asm-ingressgateway created
rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created
Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system
deployment.apps/asm-ingressgateway condition met

Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y
Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}}
horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change)
Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0
deployment.apps/istio-ingressgateway scaled
OK

Google マネージドコントロールプレーンを使用するように Webhook を再構成します。すべてのワークロードは、Google マネージドコントロールプレーンを使用して開始します。

${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook

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

Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y
Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}]
mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched
Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this
revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default'
OK

すべての名前空間に Anthos Service Mesh ラベルのラベルを付け直し、すべてのワークロードのローリング再起動を実行して、Google マネージドコントロールプレーンに取り込みます。
```
export NAMESPACE=NAMESPACE_NAME \
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
    istio.io/rev=asm-managed istio-injection- --overwrite`

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
${NAMESPACE}
```
出力内のメッセージ "istio-injection not found" は無視して構いません。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、これは想定される状態です。名前空間に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Istio on GKE ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

次のコマンドを実行して、移行を完了します。

${WORKDIR}/migrate_addon -d tmpdir --command write-marker

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

Current migration state: SUCCESS
Running: kubectl apply -f -
configmap/asm-addon-migration-state created
OK

次のコマンドを実行して、Istio on GKE を無効にします。

ゾーンクラスタ

gcloud beta container clusters update ${CLUSTER_1} \
    --project=$PROJECT_ID \
    --zone=${CLUSTER_1_LOCATION} \
    --update-addons=Istio=DISABLED

リージョンクラスタ

gcloud beta container clusters update ${CLUSTER_1} \
    --project=$PROJECT_ID \
    --region=${CLUSTER_1_LOCATION} \
    --update-addons=Istio=DISABLED

次のコマンドを実行して、構成をクリーンアップします。

${WORKDIR}/migrate_addon -d tmpdir --command cleanup

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

Cleaning up old resources...
Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus}
Will delete IstioOperator/istio-1-6-11-gke-0.istio-system
Will delete ServiceAccount/istio-citadel-service-account.istio-system
...
Will delete DestinationRule/istio-policy.istio-system
Will delete DestinationRule/istio-telemetry.istio-system
Will delete Secret/istio-ca-secret.istio-system

Deleting resources previously listed... Continue? [Y/n] Y
Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found
istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted
Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found
serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found
...
Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found
secret "istio-ca-secret" deleted
Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security
job.batch "istio-security-post-install-1.4.10-gke.8" deleted

Istio on GKE の Deployment と Service がクラスタから正常に削除されたことを確認します。

kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services

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

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/asm-ingressgateway   1/1     1            1           10m

NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      AGE   PORT(S)
service/istio-ingressgateway   LoadBalancer   10.64.5.208   34.139.100.237   95m   15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP

Anthos Service Mesh Ingress ゲートウェイサービスと Deployment のみが表示されます。

これで操作は完了です。Google マネージドコントロールプレーンと Mesh CA を使用して、Istio on GKE から Anthos Service Mesh にアプリケーションのダウンタイムなしで正常に移行しました。

変更をロールバックする

Anthos Service Mesh を続行しない場合、Anthos Service Mesh の変更をロールバックできます。このセクションでは、その概要を説明します。このセクションを完了すると、ワークロードは Istio on GKE に戻ります。

変更用 Webhook の変更をロールバックします。

${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook

次のコマンドを実行して、Anthos Service Mesh ではなく Istio on GKE サイドカーインジェクションを使用するように Namespace のラベルを変更します。

バージョン 1.4 のワークロードを持つ Namespace の場合:
```
export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
```
バージョン 1.6 のワークロードを持つ Namespace の場合:
```
export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
```
Namespace 内のすべての Deployment のローリング再起動を実行します。
```
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
```

数分待ってから、すべての Pod が実行されていることを確認します。

kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods

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

NAME                       READY   STATUS    RESTARTS   AGE
deploymentName1-PodName    2/2     Running   0          101s
deploymentName2-PodName    2/2     Running   2          100s
...

いずれかの Pod のサイドカー Envoy プロキシのバージョンを確認して、Istio on GKE v1.4 Envoy プロキシがデプロイされていることを確認します。

export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'

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

"gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"appContainerImage"

または

"gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
"appContainerImage"

再起動後にアプリケーションを確認してテストします。

Mesh CA の変更をロールバックします。

${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca

Istio Galley Webhook を再度有効にします。

${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook

これで、Istio on GKE への変更が正常にロールバックされました。

Online Boutique をデプロイする

このセクションでは、Online Boutique という、マイクロサービスベースのサンプルアプリケーションを GKE クラスタにデプロイします。Online Boutique は Istio 対応の Namespace にデプロイされます。アプリケーションが機能していることと、Istio on GKE によってすべての Pod にサイドカープロキシが挿入されていることを確認します。

アプリケーションにすでにクラスタ存在する場合は、新しい Namespace を作成して Online Boutique のデプロイをスッキプすることもできます。ワークロードを Anthos Service Mesh に移行するセクションで、すべての Namespace に対して同じプロセスを実行できます。

Online Boutique を GKE クラスタにデプロイします。

kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique

すべての Deployment の準備が整うまで待機します。

kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

Pod ごとに、Istio on GKE によって Pod に自動的に挿入されるアプリケーションコンテナと Istio サイドカープロキシという 2 つのコンテナがあることを確認します。

kubectl --context=${CLUSTER_1_CTX} -n online-boutique get pods

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

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

いずれかの Pod からサイドカー Envoy プロキシのバージョンを確認して、GKE v1.4 の Envoy プロキシがデプロイされていることを確認することもできます。

export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

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

"gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

istio-ingressgateway Service IP アドレスの IP アドレスに移動して、アプリケーションにアクセスします。

kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

よくある質問

このセクションでは、Istio on GKE から Anthos Service Mesh への移行に関するよくある質問と関連する回答について説明します。

Istio on GKE から Anthos Service Mesh に移行するのはなぜですか？

Istio on Google Kubernetes Engine は、Google が管理する Istio を Google Kubernetes Engine（GKE）クラスタにデプロイする機能のベータ版です。Istio on GKE は、サポートされていないバージョン（Istio バージョン 1.4）をデプロイします。最新のサービスメッシュ機能とサポートされているサービスメッシュの実装を提供するため、すべての Istio on GKE ユーザーを Anthos Service Mesh にアップグレードします。

Anthos Service Mesh は、Istio API を利用するサービスメッシュプロダクトで、Google が管理とサポートを行います。Anthos Service Mesh と Istio は、GKE と Kubernetes の関係と同じです。Anthos Service Mesh は Istio API をベースにしているため、Anthos Service Mesh に移行しても引き続き Istio の構成を使用できます。また、独自仕様のベンダーロックインもありません。

Anthos Service Mesh には次のようなメリットがあります。

Google が管理し、サポートを提供するサービスメッシュ。
ベンダーロックインのない Istio API。
すぐに使用できるテレメトリーダッシュボードと SLO 管理。追加のサードパーティ製ソリューションを管理する必要はありません。
Google がホストする認証局のオプション。
Google Cloud ネットワーキングと Identity-Aware Proxy（IAP）との統合。
ハイブリッドとマルチクラウドのプラットフォームのサポート。

Anthos Service Mesh の特長と機能の詳細については、Google マネージドコントロールプレーンでサポートされる機能をご覧ください。

この移行に関連するダウンタイムはありますか？

移行スクリプトは、ダウンタイムを回避するように設計されています。このスクリプトは、既存の Istio コントロールプレーンと並行して、Anthos Service Mesh をカナリアコントロールプレーンとしてインストールします。istio-ingressgateway はインプレースでアップグレードされます。さらに、Istio が有効になっている Namespace のラベルを変更し、Anthos Service Mesh 認証局（Mesh CA）で Anthos Service Mesh の使用を開始します。

アプリケーションのダウンタイムが発生しないように、アプリケーションの PodDisruptionBudgets が正しく構成されていることを確認します。ダウンタイムは回避できますが、この移行を自身で行う場合は、定期メンテナンスの時間枠内に移行を完了することをおすすめします。Google 主導の移行は GKE のメンテナンスの時間枠で実行されます。GKE クラスタにメンテナンスの時間枠が構成されていることを確認します。

Anthos Service Mesh の使用に伴う費用はありますか？

GKE で Anthos Service Mesh を使用するには、次の 2 つの方法があります。

GKE Enterprise のサブスクライバーの場合、Anthos Service Mesh は GKE Enterprise サブスクリプションの一部として含まれています。
GKE Enterprise サブスクライバーでない場合は、GKE（Google Cloud 上）でスタンドアロンサービスとして Anthos Service Mesh を使用できます。詳細については、Anthos Service Mesh の料金の詳細をご覧ください。

Anthos Service Mesh の最新バージョンでサポートされていない機能や構成はありますか？

このスクリプトは、すべての Istio 構成をチェックし、最新の Anthos Service Mesh バージョンに移行します。一部の構成では、Istio バージョン 1.4 から Anthos Service Mesh バージョン 1.10 への移行で追加の手順が必要になる場合があります。このスクリプトは構成チェックを実行し、構成に追加の手順が必要かどうかを通知します。

移行することで現在の Istio 構成は変更されますか？

いいえ、Istio の構成は Anthos Service Mesh で機能します。変更の必要はありません。

Anthos Service Mesh に移行した後、Istio に再移行できますか？

はい、Anthos Service Mesh の使用に対するコミットメントはありません。いつでも Anthos Service Mesh をアンインストールして、Istio を再インストールできます。

移行が失敗した場合、ロールバックできますか？

はい。スクリプトを使用して以前の Istio on GKE バージョンにロールバックできます。

このスクリプトを使用して移行できる Istio はどのバージョンですか？

このスクリプトは、Istio on GKE バージョン 1.4 から Anthos Service Mesh バージョン 1.10 への移行をサポートします。このスクリプトは、移行前の段階で Istio のバージョンを検証し、Istio のバージョンが移行可能かどうかを通知します。

この移行に関するその他のサポートを受けるにはどうすればいいですか？

サポートチームにお気軽にお問い合わせください。Google Cloud コンソールからサポートケースを開くことができます。詳細については、サポートケースの管理をご覧ください。

Anthos Service Mesh に移行しないとどうなりますか？

Istio コンポーネントは引き続き機能しますが、Google による Istio のインストールの管理は行われなくなります。自動更新は受信されなくなるため、Kubernetes クラスタバージョンの更新で機能しなくなる可能性があります。

詳細については、Istio のサポートをご覧ください。

Istio on GKE から Anthos Service Mesh への移行

前提条件

目標

環境を設定する

ゾーンクラスタ

リージョン クラスタ

ゾーンクラスタ

リージョン クラスタ

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

Anthos Service Mesh に構成を移行する

カスタム構成を移行する

ワークロードを Anthos Service Mesh に移行する

移行ステータスを表示する

Anthos Service Mesh ダッシュボードにアクセスする

移行を正常に完了させる

ゾーンクラスタ

リージョン クラスタ

変更をロールバックする

Online Boutique をデプロイする

よくある質問

Istio on GKE から Anthos Service Mesh に移行するのはなぜですか？

この移行に関連するダウンタイムはありますか？

Anthos Service Mesh の使用に伴う費用はありますか？

Anthos Service Mesh の最新バージョンでサポートされていない機能や構成はありますか？

移行することで現在の Istio 構成は変更されますか？

Anthos Service Mesh に移行した後、Istio に再移行できますか？

移行が失敗した場合、ロールバックできますか？

このスクリプトを使用して移行できる Istio はどのバージョンですか？

この移行に関するその他のサポートを受けるにはどうすればいいですか？

Anthos Service Mesh に移行しないとどうなりますか？

リージョンクラスタ

リージョンクラスタ

リージョンクラスタ