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

このガイドでは、Google Kubernetes Engine(GKE)クラスタを Istio on Google Kubernetes Engine(Istio on GKE)バージョン 1.4(ベータ版)で、Anthos Service Mesh Google が管理するコントロール プレーンと Anthos Service Mesh 認証局(Mesh CA)を使用して Anthos Service Mesh バージョン 1.10 にアップグレードする方法を説明します。

前提条件

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

  • Istio on GKE が有効になっている GKE クラスタ。複数の GKE クラスタがある場合は、すべてのクラスタで同じ手順に従います。GKE クラスタがない場合や、最初に新しい(テスト)クラスタでこのガイドをテストする場合は、付録 A の手順に従って Istio on GKE を有効にして新しい GKE クラスタを作成し、テスト アプリケーションをデプロイします。

  • Istio on GKE はバージョン 1.4 にする必要があります。ワークロードを Istio バージョン 1.6 にアップグレードした場合(Operator を使用して Istio 1.6 にアップグレードする場合)、そのドキュメントの手順に従って Anthos Service Mesh に移行してください。

  • GKE バージョン 1.17.17-gke.3100 以降、1.18.16-gke.1600 以降、1.19.8-gke.1600 以降を実行していることを確認します。

  • GKE クラスタは、この場所のいずれかで実行されている必要があります。

  • このスクリプトを実行するユーザーまたはサービス アカウントには、プロジェクトの設定で説明されている IAM 権限が必要です。

  • このガイドは Cloud Shell でテストされているため、このガイドの手順を実行する場合は Cloud Shell を使用することをおすすめします。

目標

  • Anthos Service Mesh Google マネージド コントロール プレーン バージョン 1.10 をデプロイします。
  • Istio 構成を Anthos Service Mesh に移行します。
  • メッシュ CA を構成します。
  • アプリケーションを Anthos Service Mesh に移行します。
  • istio-ingressgateway を Istio on GKE から Anthos Service Mesh にアップグレードします。
  • Anthos Service Mesh の移行を完了するか、Istio on GKE にロールバックします。

環境の設定

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

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

    Cloud Shell をアクティブにする

    Cloud Console ページの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell は、Cloud SDK と gcloud コマンドライン ツールがすでにインストールされたシェル環境で、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

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

    # 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.
    
  3. WORKDIR フォルダを作成します。このガイドに関連するすべてのファイルは WORKDIR になるため、終了時に WORKDIR を削除できます。

    mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
    
  4. このガイドの KUBECONFIG ファイルを作成します。GKE クラスタのクラスタ コンテキストを含む既存の KUBECONFIG ファイルを使用して、Anthos Service Mesh に移行することもできます。

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
    
  5. 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}
    

省略可能なステップ

クラスタが(master-authorized-networks が有効になっている)限定公開クラスタの場合は、$SHELL_IPmaster-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 をインストールする

このセクションでは、Google が管理するコントロール プレーンを使用して Anthos Service Mesh バージョン 1.10 を GKE クラスタにデプロイします。このコントロール プレーンは、Istio on GKE と 2 番目(またはカナリア)のコントロール プレーンとしてデプロイされます。

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asm_1_10
    chmod +x install_asm_1_10
    
  2. GKE クラスタを構成するには、インストール スクリプトを実行し、Google が管理するコントロール プレーンを使用して Anthos Service Mesh をインストールします。

    ./install_asm_1_10 --mode install --managed \
    -p ${PROJECT_ID} \
    -l ${CLUSTER_1_LOCATION} \
    -n ${CLUSTER_1} \
    --verbose \
    --output_dir ${CLUSTER_1} \
    --enable-all \
    --enable-registration \
    --option cni-managed
    

    処理が完了するまで数分かかることがあります。

  3. istioctl バージョン 1.10 を WORKDIR フォルダにコピーします。

    cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
    

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

Anthos Service Mesh への構成の移行

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

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

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
    chmod +x ${WORKDIR}/migrate_addon
    
  2. 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
    
    
  3. 構成を確認して手動で移行します。この手順により、ワークロードを 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.percentabort.percentage に置き換えます。
  • 移行できないミキサー リソースのカスタム インストールを検出しました。telemetryv2 に手動で移行する必要があります。 デフォルトの Istio on GKE インストールに加えてカスタム ミキサー ポリシーを構成している場合は、これらのポリシーをテレメトリー v2 に手動で移行する必要があります。詳しい方法については、Istio の指標をカスタマイズするをご覧ください。

  • デプロイ <deploymentName> はカスタム ゲートウェイである必要があります。これは手動で移行してください。 デフォルトでインストールされる istio-ingressgateway 以外のすべてのゲートウェイ Deployment を手動で移行する必要があります。Google が管理するコントロール プレーンのゲートウェイをアップグレードする方法については、Google が管理するコントロール プレーンの構成をご覧ください。

構成を移行するには、次の手順に従います。

  1. すべてのカスタム構成(リストの最後の構成を除く)を手動で移行してから、ステップ 2 に進みます。

  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
    
    
  3. 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
    
    

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

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

  • クラスタ内のすべての v1.4 ワークロードの Mesh CA ルート オブ トラストをインストールします。
  • v1.4 コントロール プレーンの Deployment istio-pilotistio-citadel の構成を変更します。変更内容は次のとおりです。

    • istio-pilot v1.4 イメージを最新のビルドにアップグレードします。
    • PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true を設定して trust-domain 検証を無効にします。
    • ConfigMap をすべての名前空間に分散させるために、メッシュ CA のルート オブ トラストを istio-citadel に追加します。
  • 古い構成マニフェストを tmpdir に保存します。

  • ロールバック機能(後述)の手順を提供します。

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

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

付録 A の手順に従ってテストクラスタを作成した場合は、例として online-boutique 名前空間を使用します。既存のクラスタでこの手順を実行する場合は、移行する名前空間を選択します。

  1. 名前空間を変数として定義します。この名前空間は Anthos Service Mesh に移行されます。

    export NAMESPACE=NAMESPACE_NAME # or online-boutique if using the test cluster in Appendix A
    
  2. ワークロードを Anthos Service Mesh に移行するには、Anthos Service Mesh の名前空間のラベルを変更する必要があります。名前空間にラベルを付けると、Anthos Service Mesh がすべてのワークロードにサイドカーを自動的に挿入できるようになります。名前空間にラベルを付けるには、ラベルを asm-managed-rapid に設定して次のコマンドを実行します。

    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed-rapid istio-injection- --overwrite
    
  3. Namespace 内のすべての Deployment のローリング再起動を実行します。

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

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

    deployment.apps/deploymentName1 restarted
    deployment.apps/deploymentName2 restarted
    ...
    
  4. すべてのポッドが再起動され、ポッドごとに 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 を確認することです。値が短いことを確認します(数分など)。

  5. 名前空間内の任意の Deployment の 1 つの Pod のサイドカー Envoy プロキシのバージョンを調べて、Anthos Service Mesh v1.10 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.10.2-asm.2"
    "appContainerImage"
    
  6. 再起動後にアプリケーションを確認してテストします。

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

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

  1. Cloud Console で、[Anthos Service Mesh] ページに移動します。

    Anthos Service Mesh に移動する

  2. Service の指標とトポロジの表示権限が必要です。

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

移行を正常に完了させる

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

  1. 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
    
  2. 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
    
  3. すべての Namespace に Anthos Service Mesh ラベルのラベルを付け直し、すべてのワークロードのローリング再起動を実行して、Google が管理するコントロール プレーンに取り込みます。

    export NAMESPACE=NAMESPACE_NAME \
        kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
        istio.io/rev=asm-managed-rapid istio-injection- --overwrite`
    
        kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
    ${NAMESPACE}
    
  4. 次のコマンドを実行して、移行を完了します。

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

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

    Current migration state: COMPLETE
    Running: kubectl apply -f -
    configmap/asm-addon-migration-state created
    OK
    
    
  5. 次のコマンドを実行して、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
    
  6. 次のコマンドを実行して、構成をクリーンアップします。

    ${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
    
  7. 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 v1.4 から Anthos Service Mesh v1.10 にアプリケーションのダウンタイムなしで正常に移行しました。

変更をロールバックする

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

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

    export NAMESPACE=NAMESPACE_NAME
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
    
  2. Namespace 内のすべての Deployment のローリング再起動を実行します。

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
    
  3. 数分待ってから、すべての 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
    ...
    
    
  4. いずれかの 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"
    
  5. 再起動後にアプリケーションを確認してテストします。

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

    ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
    
  7. Istio Galley Webhook を再度有効にします。

    ${WORKDIR}/migrate_addon -d tmpdir enable-galley-webook
    

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

付録 A

Istio on GKE で GKE クラスタを作成する

このセクションでは、Istio on GKE を有効にした GKE クラスタをデプロイします。限定公開または一般公開 GKE クラスタを使用できます。限定公開 GKE クラスタには一般公開の GKE エンドポイントが必要です。また、Istio on GKE のインストールも確認します。

GKE クラスタがすでに存在する場合は、作成手順をスキップし、KUBECONFIG ファイルを使用するクラスタにアクセス可能であることを確認します。このガイドで使用するコンテキストは、変数 ${CLUSTER_1_CTX} で定義されます。この変数にクラスタのコンテキストを設定できます。

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

    # 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.
    
  2. Istio on GKE を有効にした GKE クラスタを作成します(これは限定公開クラスタです)。これらの手順は、一般公開の GKE クラスタにも実行できます。

    ゾーンクラスタ

    gcloud beta container clusters create ${CLUSTER_1} \
      --project ${PROJECT_ID} \
      --zone=${CLUSTER_1_LOCATION} \
      --machine-type "e2-standard-4" \
      --num-nodes "4" --min-nodes "2" --max-nodes "5" \
      --addons=Istio --istio-config=auth=MTLS_STRICT \
      --enable-master-authorized-networks \
      --master-authorized-networks ${SHELL_IP}/32 \
      --enable-private-nodes \
      --master-ipv4-cidr 172.16.0.32/28 \
      --enable-ip-alias \
      --enable-autoscaling
    

    リージョン クラスタ

    gcloud beta container clusters create ${CLUSTER_1} \
      --project ${PROJECT_ID} \
      --region=${CLUSTER_1_LOCATION} \
      --machine-type "e2-standard-4" \
      --num-nodes "4" --min-nodes "2" --max-nodes "5" \
      --addons=Istio --istio-config=auth=MTLS_STRICT \
      --enable-master-authorized-networks \
      --master-authorized-networks ${SHELL_IP}/32 \
      --enable-private-nodes \
      --master-ipv4-cidr 172.16.0.32/28 \
      --enable-ip-alias \
      --enable-autoscaling
    
  3. クラスタが RUNNING であることを確認します。

    gcloud container clusters list
    

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

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING
    
  4. クラスタに接続します。

    ゾーンクラスタ

    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}
    

    省略可能なステップ

    これらの手順で Cloud Shell を使用している場合は、SHELL_IP が変わる可能性があります。その場合は、次のコマンドを実行して master-authorized-networks の値を新しい Cloud Shell IP アドレスに更新できます。

    クラスタの master-authorized-networks 値を更新するには、次のコマンドを実行します。Cloud Shell の IP アドレスが変更された場合にのみ、次のコマンドを実行する必要があります。

    ゾーンクラスタ

    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
    
  5. Istio がクラスタにデプロイされていることを確認します。すべての Service がデプロイされていることを確認します。

    kubectl --context=${CLUSTER_1_CTX} get service -n istio-system
    

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

    NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                                                                                      AGE
    istio-citadel            ClusterIP      10.64.7.167    <none>        8060/TCP,15014/TCP                                                                                                                           90s
    istio-galley             ClusterIP      10.64.15.216   <none>        443/TCP,15014/TCP,9901/TCP                                                                                                                   90s
    istio-ingressgateway     LoadBalancer   10.64.9.36     <pending>     15020:31962/TCP,80:31663/TCP,443:31658/TCP,31400:32022/TCP,15029:31829/TCP,15030:30063/TCP,15031:32466/TCP,15032:30649/TCP,15443:30807/TCP   90s
    istio-pilot              ClusterIP      10.64.10.175   <none>        15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                                       90s
    istio-policy             ClusterIP      10.64.1.82     <none>        9091/TCP,15004/TCP,15014/TCP                                                                                                                 90s
    istio-sidecar-injector   ClusterIP      10.64.13.43    <none>        443/TCP,15014/TCP                                                                                                                            90s
    istio-telemetry          ClusterIP      10.64.7.76     <none>        9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                                       90s
    promsd                   ClusterIP      10.64.5.236    <none>        9090/TCP
    
  6. すべての Pod が実行され、ジョブが完了していることを確認します。

    kubectl --context=${CLUSTER_1_CTX} get pods -n istio-system
    

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

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-f5586dffb-8c9sm                    1/1     Running     0          10m
    istio-galley-7975f77bbf-zxccq                    1/1     Running     0          10m
    istio-ingressgateway-b9477dcdb-gr7wb             1/1     Running     0          10m
    istio-pilot-59d4884d67-v6zh6                     2/2     Running     0          10m
    istio-policy-6885cb4644-h5pnv                    2/2     Running     1          10m
    istio-security-post-install-1.4.10-gke.8-q9w5s   0/1     Completed   0          10m
    istio-sidecar-injector-649d664b99-555dx          1/1     Running     0          10m
    istio-telemetry-59b6bf55c7-r2q57                 2/2     Running     1          10m
    istiod-istio-1611-6895859f65-zvlzq               1/1     Running     0          9m21s
    prometheus-6655946b9f-hdsrd                      2/2     Running     0          9m21s
    promsd-574ccb9745-w65pl                          2/2     Running     1          10m
    

Online Boutique をデプロイする

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

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

  1. 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
    
  2. すべての 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
    
  3. 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
    
  4. いずれかの 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.2.3"
    
  5. istio-ingressgateway Service IP アドレスの IP アドレスに移動して、アプリケーションにアクセスします。

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

次のステップ