以前の v1.18 サービスメッシュのドキュメントを表示しています。

利用可能なバージョン

Cloud Service Mesh
1.20 アーカイブ
 1.19 アーカイブ
 1.18 アーカイブ

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

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

前提条件

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

Istio on GKE が有効になっている 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 チャンネルで Cloud Service Mesh の Google マネージドコントロールプレーンをデプロイします。このガイドは Regular チャンネルのみを対象としています。Stable チャンネルまたは Rapid チャンネルでは手順を若干変更する必要があります。リリースチャンネルの詳細については、こちらのリンクをご覧ください。
Istio 構成を Cloud Service Mesh に移行します。
Cloud Service Mesh 認証局を構成します。
アプリケーションを Cloud Service Mesh に移行します。
istio-ingressgateway を Istio on GKE から Cloud Service Mesh にアップグレードします。
Cloud 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 ファイルを使用して、Cloud 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}

クラスタは、フリートに登録されている必要があります。インストールの前に個別にインストールするか、--fleet-id と --enable-all フラグまたは --enable-registration フラグのいずれかを渡して、インストールの一部として行うこともできます。
プロジェクトでサービスメッシュ機能が有効になっている必要があります。インストールの一部として有効にするには、--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

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

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

Cloud Service Mesh をインストールする最新バージョンのスクリプトを現在の作業ディレクトリにダウンロードして、スクリプトを実行可能にします。
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
chmod +x asmcli
```
GKE クラスタを構成するには、インストールスクリプトを実行して、Google が管理する Regular チャンネルのコントロールプレーンを使用して Cloud 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}/.
```

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

構成を Cloud Service Mesh に移行する

このセクションでは、Istio on GKE 構成を Cloud 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 の構成の一部を Cloud 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
```

カスタム構成を移行する

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

検出されたカスタム Envoy フィルタは、Cloud Service Mesh でサポートされません。可能であれば削除してください。 Envoy フィルタは現在、Google が管理するコントロールプレーンではサポートされていません。
検出されたカスタムプラグイン証明書。プラグイン証明書は Cloud Service Mesh に移行されません。プラグイン証明書が Istio on GKE で使用されている場合、ワークロードが Google マネージドコントロールプレーンに移行した後、これらの証明書は使用されなくなります。すべてのワークロードは、Google Cloud Service Mesh 認証局によって署名された証明書を使用します。プラグイン証明書は、Cloud Service Mesh 認証局ではサポートされていません。このメッセージは情報提供を目的としたものであり、操作は不要です。
移行できなかったセキュリティポリシーを検出しました。<エラーの理由>。これは通常、手動で移行する必要があるアルファ 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 の指標をカスタマイズするをご覧ください。
デプロイ <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

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

${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

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

前のステップでは、次のことが行われます。

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

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

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

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

Namespace を変数として定義します。この Namespace は Cloud Service Mesh に移行されます。
```
export NAMESPACE=NAMESPACE_NAME
```
ワークロードを Cloud Service Mesh に移行するには、Cloud Service Mesh の Namespace のラベルを変更する必要があります。Namespace にラベルを付けると、Cloud Service Mesh がすべてのワークロードにサイドカーを自動的に挿入できるようになります。名前空間にラベルを付けるには、ラベルを 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
...

すべてのポッドが再起動され、ポッドごとに 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 プロキシのバージョンを調べて、Cloud 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 を出力していれば、コントロールプレーンは Cloud Service Mesh に正常にアップグレードされています。データプレーンを手動で更新するには、ワークロードの移行で手順を完了します。

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

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

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

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

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

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

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

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

移行を正常に完了させる

このセクションでは、Istio on GKE から Cloud Service Mesh への移行を完了します。このセクションに進む前に、Cloud 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

すべての名前空間に Cloud 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 ラベルが付加されていなかったことを示しており、Cloud 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

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

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

変更をロールバックする

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

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

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

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

バージョン 1.4 のワークロードを持つ名前空間の場合:
```
export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
```
バージョン 1.6 のワークロードを持つ名前空間の場合:
```
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"

再起動後にアプリケーションを確認してテストします。
Cloud Service Mesh 認証局の変更をロールバックします。
```
${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 のデプロイをスッキプすることもできます。ワークロードを Cloud 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 ごとに、2 つのコンテナ（Istio on GKE によって Pod に自動的に挿入されるアプリケーションコンテナと Istio サイドカープロキシ）があることを確認します。

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 から Cloud Service Mesh への移行に関するよくある質問と関連する回答について説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前提条件

目標

環境の設定

ゾーンクラスタ

リージョン クラスタ

ゾーンクラスタ

リージョン クラスタ

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

構成を Cloud Service Mesh に移行する

カスタム構成を移行する

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

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

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

移行を正常に完了させる

ゾーンクラスタ

リージョン クラスタ

変更をロールバックする

Online Boutique をデプロイする

よくある質問

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

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

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

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

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

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

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

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

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

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

リージョンクラスタ

リージョンクラスタ

リージョンクラスタ