Bermigrasi dari Istio di GKE ke Cloud Service Mesh

Panduan ini menunjukkan cara mengupgrade cluster Google Kubernetes Engine (GKE) dengan Istio di Google Kubernetes Engine (Istio di GKE) versi 1.4 atau 1.6 (Beta) ke Cloud Service Mesh terkelola dengan bidang kontrol yang dikelola Google dan otoritas sertifikat Cloud Service Mesh.

Prasyarat

Prasyarat berikut diperlukan untuk menyelesaikan panduan ini:

  • Cluster GKE dengan Istio di GKE diaktifkan. Jika Anda memiliki beberapa cluster GKE, ikuti langkah-langkah yang sama untuk semua cluster.

  • Istio di GKE harus berupa versi 1.4 atau 1.6.

  • Pastikan Anda menjalankan GKE versi 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+, atau yang lebih baru.

  • Cluster GKE harus berjalan di salah satu lokasi berikut.

  • Pengguna atau Akun Layanan yang menjalankan skrip ini memerlukan izin IAM yang didokumentasikan dalam Menyiapkan project Anda.

  • Panduan ini diuji di Cloud Shell, jadi sebaiknya gunakan Cloud Shell untuk melakukan langkah-langkah dalam panduan ini.

Tujuan

  • Deploy bidang kontrol yang dikelola Google Cloud Service Mesh di saluran reguler. Panduan ini khusus untuk channel reguler, sedangkan channel stabil atau cepat memerlukan petunjuk yang sedikit berbeda. Untuk mempelajari lebih lanjut saluran rilis, buka link ini.
  • Migrasikan konfigurasi Istio ke Cloud Service Mesh.
  • Konfigurasi otoritas sertifikat Cloud Service Mesh.
  • Migrasikan aplikasi ke Cloud Service Mesh.
  • Lakukan upgrade istio-ingressgateway dari Istio di GKE ke Cloud Service Mesh.
  • Selesaikan migrasi Cloud Service Mesh atau kembalikan ke Istio di GKE.

Menyiapkan lingkungan Anda

Untuk menyiapkan lingkungan Anda, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud , aktifkan Cloud Shell.

    Aktifkan Cloud Shell

    Di bagian bawah halaman konsol Google Cloud , sesi Cloud Shell akan dimulai dan menampilkan perintah command line. Cloud Shell adalah lingkungan shell dengan Google Cloud CLI dan Google Cloud CLI yang sudah terinstal, dan dengan nilai yang sudah ditetapkan untuk project Anda saat ini. Perlu waktu beberapa detik hingga sesi dimulai.

  2. Buat variabel lingkungan yang digunakan dalam panduan ini:

    # 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. Buat folder WORKDIR. Semua file yang terkait dengan panduan ini akan berada di WORKDIR sehingga Anda dapat menghapus WORKDIR setelah selesai.

    mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`

  4. Buat file KUBECONFIG untuk panduan ini. Anda juga dapat menggunakan file KUBECONFIG yang sudah ada yang berisi konteks cluster untuk cluster GKE yang akan dimigrasikan ke Cloud Service Mesh.

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. Dapatkan kredensial untuk cluster GKE dan simpan konteks dalam variabel:

    Cluster zona

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

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

    Cluster regional

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

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

  6. Cluster Anda harus terdaftar ke fleet. Langkah ini dapat dilakukan secara terpisah sebelum penginstalan atau sebagai bagian dari penginstalan dengan meneruskan --fleet-id dan salah satu flag --enable-all atau --enable-registration.

  7. Project Anda harus mengaktifkan Fitur Service Mesh. Anda dapat mengaktifkannya sebagai bagian dari penginstalan dengan meneruskan salah satu flag --enable-all atau --enable-registration, atau dengan menjalankan perintah berikut sebelum penginstalan:

      gcloud container hub mesh enable --project=FLEET_PROJECT_ID

    dengan FLEET_PROJECT_ID adalah project-id project host fleet.

Langkah opsional

Jika cluster adalah cluster pribadi (dengan master-authorized-networks diaktifkan), tambahkan $SHELL_IP Anda ke daftar yang diizinkan master-authorized-networks. Jika Anda sudah memiliki akses ke cluster, langkah ini mungkin tidak diperlukan.

Cluster zona

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

Cluster regional

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

Menginstal Cloud Service Mesh

Di bagian ini, Anda akan men-deploy Cloud Service Mesh dengan bidang kontrol yang dikelola Google dari saluran reguler di cluster GKE. Bidang kontrol ini awalnya di-deploy bersama sebagai bidang kontrol kedua (atau canary).

  1. Download versi terbaru skrip yang menginstal Cloud Service Mesh ke direktori kerja saat ini, dan buat skrip dapat dieksekusi:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
chmod +x asmcli

  2. Untuk mengonfigurasi cluster GKE, jalankan skrip penginstalan untuk menginstal Cloud Service Mesh dengan panel kontrol yang dikelola Google dari saluran reguler:

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

    Langkah ini dapat memerlukan waktu beberapa menit hingga selesai.

  3. Memverifikasi bidang kontrol yang dikelola Google

  4. Salin istioctl ke folder WORKDIR:

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

Di bagian berikutnya, Anda akan mendownload dan menjalankan skrip migrate_addon untuk membantu migrasi ke Cloud Service Mesh. Utilitas command line istioctl harus berada di folder yang sama dengan skrip migrate_addon. Anda menggunakan folder WORKDIR untuk utilitas command line istioctl dan skrip migrate_addon.

Memigrasikan konfigurasi ke Cloud Service Mesh

Di bagian ini, Anda akan memigrasikan konfigurasi Istio di GKE ke Cloud Service Mesh. Skrip terpandu mengidentifikasi konfigurasi mana yang dapat dan tidak dapat dimigrasikan.

  1. Download alat migrasi dan setel agar dapat dijalankan:

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

  2. Nonaktifkan webhook validasi Galeri. Langkah ini diperlukan untuk memigrasikan beberapa konfigurasi 1.4 ke Cloud Service Mesh. Jawab Y kedua pertanyaan:

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

    Outputnya mirip dengan hal berikut ini:

    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. Verifikasi dan migrasikan konfigurasi secara manual. Langkah ini membantu mengidentifikasi beberapa konfigurasi yang perlu dimigrasikan secara manual sebelum memigrasikan workload ke bidang kontrol yang dikelola Google.

    ${WORKDIR}/migrate_addon -d tmpdir --command config-check

    Outputnya mirip dengan hal berikut ini:

    Installing the authentication CR migration tool...
OK

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

Memigrasikan konfigurasi kustom

Anda mungkin perlu memigrasikan konfigurasi kustom secara manual sebelum bermigrasi ke Cloud Service Mesh. Skrip sebelumnya mengidentifikasi konfigurasi kustom dan mencetak informasi tentang apa yang diperlukan. Penyesuaian ini adalah sebagai berikut:

  • Filter Envoy kustom yang terdeteksi tidak didukung oleh Cloud Service Mesh. Hapus jika memungkinkan. Filter Envoy saat ini tidak didukung di bidang kontrol yang dikelola Google.

  • Mendeteksi sertifikat plugin kustom. Sertifikat plugin tidak akan dimigrasikan ke Cloud Service Mesh. Jika sertifikat plugin digunakan dengan Istio di GKE, sertifikat ini tidak digunakan setelah workload dimigrasikan ke bidang kontrol yang dikelola Google. Semua beban kerja menggunakan sertifikat yang ditandatangani oleh otoritas sertifikat Google Cloud Service Mesh. Sertifikat plugin tidak didukung oleh Certificate Authority Cloud Service Mesh. Pesan ini hanya berupa informasi dan tidak memerlukan tindakan apa pun.

  • Mendeteksi kebijakan keamanan yang tidak dapat dimigrasikan. <Error reason>. Biasanya gagal karena kebijakan AuthZ alfa yang perlu dimigrasikan secara manual. Untuk mengetahui konteks dan informasi selengkapnya tentang cara memigrasikan kebijakan, lihat artikel Memigrasikan kebijakan keamanan Alpha pra-Istio 1.4 ke API saat ini. Untuk mengetahui informasi selengkapnya terkait pesan error, lihat security-policy-migrate.

  • Mendeteksi konfigurasi VirtualService yang mungkin tidak kompatibel. <Specific deprecated config>. Anda perlu memperbarui konfigurasi VirtualService berikut:

    • Penggunaan appendHeaders tidak didukung. Sebagai gantinya, gunakan spec.http.headers.
    • Penggunaan websocketUpgrade tidak diperlukan. Fitur ini diaktifkan secara default.
    • Ganti kolom abort.percent dengan abort.percentage.

  • Mendeteksi penginstalan kustom resource mixer yang tidak dapat dimigrasikan. Memerlukan migrasi manual ke telemetryv2. Jika kebijakan mixer kustom dikonfigurasi selain penginstalan Istio di GKE default, Anda harus memigrasikan kebijakan ini secara manual ke Telemetry V2. Untuk mengetahui informasi selengkapnya tentang cara melakukannya, lihat Menyesuaikan Metrik Istio.

  • Deployment <deploymentName> dapat berupa gateway kustom. Migrasikan ini secara manual. Anda harus memigrasikan semua Deployment gateway secara manual selain istio-ingressgateway (yang diinstal secara default). Untuk informasi tentang cara mengupgrade gateway untuk bidang kontrol yang dikelola Google, lihat Mengonfigurasi bidang kontrol yang dikelola Google.

Untuk memigrasikan konfigurasi, ikuti langkah-langkah berikut:

  1. Migrasikan semua konfigurasi kustom secara manual (kecuali konfigurasi terakhir yang tercantum) sebelum melanjutkan ke langkah 2.

  2. Gunakan alat migrasi untuk memigrasikan konfigurasi yang dapat dimigrasikan (atau diabaikan) secara otomatis.

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

    Outputnya mirip dengan hal berikut ini:

    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. Terapkan kepercayaan root otoritas sertifikat Cloud Service Mesh. Hal ini memungkinkan Anda bermigrasi dari CA Citadel saat ini ke certificate authority Cloud Service Mesh tanpa menyebabkan aplikasi Anda mengalami periode nonaktif.

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

    Outputnya mirip dengan hal berikut ini:

    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

    Langkah ini memerlukan waktu beberapa menit agar sertifikat root Cloud Service Mesh didistribusikan ke semua namespace. Tunggu hingga skrip selesai dengan pesan OK.

Langkah sebelumnya melakukan hal berikut:

  • Menginstal root of trust certificate authority Cloud Service Mesh untuk semua workload di cluster.

  • Mengubah konfigurasi Deployment bidang kontrol istio-pilot, istiod, dan istio-citadel. Perubahan ini mencakup:

    • Mengupgrade gambar ke build terbaru.
    • Menonaktifkan verifikasi trust-domain dengan menyetel PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
    • Menambahkan root of trust certificate authority Cloud Service Mesh ke istio-citadel untuk mendistribusikan ConfigMap ke semua namespace.
    • Menambahkan root of trust otoritas sertifikat Cloud Service Mesh ke istio-ca-secret untuk mendistribusikan root certificate.

  • Menyimpan manifes konfigurasi lama di tmpdir.

  • Menyediakan langkah-langkah untuk fungsi rollback (didokumentasikan nanti).

Memigrasikan workload ke Cloud Service Mesh

Di bagian ini, Anda akan memigrasikan workload yang berjalan di Istio di GKE ke Cloud Service Mesh. Setelah migrasi, Anda memverifikasi bahwa proxy sidecar yang benar (Cloud Service Mesh) disuntikkan di setiap Pod dan aplikasi berfungsi seperti yang diharapkan.

Jika Anda melakukan prosedur ini di cluster yang sudah ada, pilih namespace yang akan dimigrasikan.

  1. Tentukan namespace sebagai variabel; namespace ini dimigrasikan ke Cloud Service Mesh:

    export NAMESPACE=NAMESPACE_NAME

  2. Untuk memigrasikan workload ke Cloud Service Mesh, Anda harus memberi label ulang namespace untuk Cloud Service Mesh. Pelabelan namespace memungkinkan Cloud Service Mesh untuk otomatis memasukkan sidecar ke semua beban kerja. Untuk memberi label pada namespace, jalankan perintah berikut, dengan menetapkan label ke asm-managed:

    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite

  3. Lakukan mulai ulang berkelanjutan pada semua Deployment di namespace:

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

    Outputnya mirip dengan hal berikut ini:

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

  4. Pastikan semua Pod dimulai ulang dan berjalan dengan dua container per Pod:

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

    Outputnya mirip dengan hal berikut ini:

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

    Cara yang baik untuk memverifikasi langkah ini adalah dengan melihat AGE Pod. Pastikan nilai yang dimasukkan singkat—misalnya, beberapa menit.

  5. Periksa versi proxy Envoy sidecar dari salah satu Pod dari Deployment mana pun di namespace untuk mengonfirmasi bahwa Anda kini telah men-deploy proxy Envoy Cloud Service Mesh:

    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'

    Outputnya mirip dengan hal berikut ini:

    "gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
"appContainerImage"

  6. Verifikasi dan uji aplikasi Anda setelah memulai ulang.

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

  7. (Opsional) Jika Anda ingin Google mengelola upgrade proxy, aktifkan bidang data yang dikelola Google

Melihat status migrasi

Jalankan perintah berikut untuk melihat status migrasi:

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

Output menunjukkan apakah migrasi selesai, tertunda, atau gagal:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Jika migrationStatus menampilkan SUCCESS, bidang kontrol telah berhasil diupgrade ke Cloud Service Mesh. Untuk memperbarui data plane secara manual, selesaikan langkah-langkah dalam Memigrasikan workload.

Jika migrationStatus menampilkan status selain SUCCESS, Anda dapat memilih untuk:

  • Tidak perlu melakukan tindakan tambahan jika error migrasi tidak memengaruhi workload Istio di GKE yang sudah ada. Jika tidak, lakukan rollback jika diperlukan.
  • Perbarui konfigurasi kustom di cluster dan jalankan ulang migrasi secara manual jika migrationStatus menampilkan MIGRATION_CONFIG_ERROR.

Anda dapat melihat metrik bidang kontrol di Metrics Explorer setelah migrasi berhasil, lihat verify_control_plane_metrics

Mengakses dasbor Cloud Service Mesh

Di bagian ini, Anda akan membuka dasbor Cloud Service Mesh dan memastikan bahwa Anda menerima sinyal keemasan untuk semua Layanan. Anda juga akan dapat melihat topologi aplikasi.

  1. Di konsol Google Cloud , buka halaman Cloud Service Mesh.

    Buka Cloud Service Mesh

  2. Anda akan dapat melihat metrik dan topologi untuk Layanan Anda.

Untuk mempelajari lebih lanjut dasbor Cloud Service Mesh, lihat Menjelajahi Cloud Service Mesh di konsol Google Cloud .

Menyelesaikan migrasi yang berhasil

Di bagian ini, Anda akan menyelesaikan migrasi Istio on GKE ke Cloud Service Mesh. Sebelum melanjutkan bagian ini, pastikan Anda ingin melanjutkan dengan Cloud Service Mesh. Bagian ini juga membantu Anda membersihkan artefak Istio di GKE. Jika Anda ingin melakukan roll back ke Istio di GKE, lanjutkan ke bagian berikutnya.

  1. Ganti istio-ingressgateway (bagian dari Istio standar di GKE) dengan gateway berversi bidang kontrol yang dikelola Google:

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

    Outputnya mirip dengan hal berikut ini:

    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. Mengonfigurasi ulang webhook untuk menggunakan bidang kontrol yang dikelola Google; semua beban kerja dimulai dengan menggunakan bidang kontrol yang dikelola Google:

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

    Outputnya mirip dengan hal berikut ini:

    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. Beri label ulang semua namespace dengan label Cloud Service Mesh, dan lakukan mulai ulang bertahap semua beban kerja untuk menempatkannya di bidang kontrol yang dikelola 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}

    Anda dapat mengabaikan pesan "istio-injection not found" dalam output. Artinya, namespace sebelumnya tidak memiliki label istio-injection, yang akan Anda lihat di penginstalan baru Cloud Service Mesh atau deployment baru. Karena injeksi otomatis gagal jika namespace memiliki label revisi dan istio-injection, semua perintah kubectl label dalam dokumentasi Istio di GKE menyertakan penghapusan label istio-injection.

  4. Selesaikan migrasi dengan menjalankan perintah berikut:

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

    Outputnya mirip dengan hal berikut ini:

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

  5. Nonaktifkan Istio di GKE dengan menjalankan perintah berikut:

    Cluster zona

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

    Cluster regional

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

  6. Bersihkan konfigurasi dengan menjalankan perintah berikut:

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

    Outputnya mirip dengan hal berikut ini:

    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. Pastikan Deployment dan Layanan Istio di GKE telah berhasil dihapus dari cluster:

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

    Outputnya mirip dengan hal berikut ini:

    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

    Anda hanya akan melihat Layanan dan Deployment gateway masuk Cloud Service Mesh.

Selamat. Anda telah berhasil bermigrasi dari Istio di GKE ke Cloud Service Mesh dengan bidang kontrol yang dikelola Google dan certificate authority Cloud Service Mesh tanpa periode nonaktif pada aplikasi Anda.

Mengembalikan perubahan

Di bagian ini, jika tidak ingin melanjutkan Cloud Service Mesh, Anda dapat mengembalikan perubahan Cloud Service Mesh. Setelah menyelesaikan bagian ini, workload Anda akan kembali ke Istio di GKE.

  1. Kembalikan perubahan webhook mutating: 

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

  2. Beri label ulang namespace untuk menggunakan injeksi sidecar Istio di GKE, bukan Cloud Service Mesh, dengan menjalankan perintah berikut:

    untuk namespace dengan beban kerja versi 1.4: 

    export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite

    untuk namespace dengan workload versi 1.6: 

    export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite

  3. Lakukan mulai ulang berkelanjutan pada semua Deployment di namespace:

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

  4. Tunggu beberapa menit dan pastikan semua Pod berjalan:

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

    Outputnya mirip dengan hal berikut ini:

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

  5. Verifikasi versi proxy Envoy file bantuan dari salah satu Pod untuk mengonfirmasi bahwa Anda telah men-deploy proxy Envoy Istio di GKE v1.4:

    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'

    Outputnya mirip dengan hal berikut ini:

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

    atau

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

  6. Verifikasi dan uji aplikasi Anda setelah memulai ulang.

  7. Membatalkan perubahan certificate authority Cloud Service Mesh:

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

  8. Aktifkan kembali webhook Istio Galley:

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

Anda telah berhasil mengembalikan perubahan ke Istio di GKE.

Men-deploy Online Boutique

Di bagian ini, Anda akan men-deploy aplikasi berbasis microservice contoh bernama Online Boutique ke cluster GKE. Online Boutique di-deploy di namespace yang mendukung Istio. Anda memverifikasi bahwa aplikasi berfungsi dan bahwa Istio di GKE menyuntikkan proxy sidecar ke setiap Pod.

Jika sudah memiliki cluster dengan aplikasi, Anda dapat melewati pembuatan namespace baru dan men-deploy Online Boutique. Anda dapat mengikuti proses yang sama untuk semua namespace di bagian Memigrasikan workload ke Cloud Service Mesh.

  1. Deploy Online Boutique ke cluster 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. Tunggu hingga semua Deployment siap:

    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. Pastikan ada dua container per Pod—container aplikasi dan proxy sidecar Istio yang otomatis disuntikkan Istio di GKE ke dalam Pod:

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

    Outputnya mirip dengan hal berikut ini:

    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. Anda juga dapat memeriksa versi proxy Envoy sidecar dari salah satu Pod untuk mengonfirmasi bahwa Anda telah men-deploy proxy Envoy Istio di GKE v1.4:

    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'

    Outputnya mirip dengan hal berikut ini:

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

  5. Akses aplikasi dengan membuka alamat IP istio-ingressgateway Service IP address:

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

Pertanyaan umum (FAQ)

Bagian ini menjelaskan pertanyaan umum (FAQ) dan jawaban terkait tentang migrasi dari Istio di GKE ke Cloud Service Mesh.

Mengapa saya dimigrasikan dari Istio di GKE ke Cloud Service Mesh?

Istio di Google Kubernetes Engine adalah fitur beta yang men-deploy Istio yang dikelola Google di cluster Google Kubernetes Engine (GKE). Istio di GKE men-deploy versi yang tidak didukung (Istio versi 1.4). Untuk memberi Anda fitur service mesh terbaru dan penerapan service mesh yang didukung, kami mengupgrade semua pengguna Istio di GKE ke Cloud Service Mesh.

Cloud Service Mesh adalah produk mesh layanan terkelola dan yang didukung Google yang didukung oleh API Istio. Cloud Service Mesh adalah Istio seperti GKE adalah Kubernetes. Karena Cloud Service Mesh didasarkan pada Istio API, Anda dapat terus menggunakan konfigurasi Istio saat bermigrasi ke Cloud Service Mesh. Selain itu, tidak ada ketergantungan pada vendor eksklusif.

Cloud Service Mesh memberikan manfaat berikut:

  • Mesh layanan yang dikelola dan didukung Google.
  • API Istio tanpa ketergantungan pada vendor.
  • Dasbor telemetri siap pakai dan pengelolaan SLO tanpa persyaratan untuk mengelola solusi pihak ketiga tambahan.
  • Opsi certificate authority yang dihosting Google.
  • Integrasi dengan Google Cloud jaringan dan Identity-Aware Proxy (IAP).
  • Dukungan platform hybrid dan multi-cloud.

Untuk mempelajari lebih lanjut fitur dan kemampuan Cloud Service Mesh, lihat Fitur yang didukung bidang kontrol yang dikelola Google.

Apakah ada periode nonaktif yang terkait dengan migrasi ini?

Skrip migrasi dirancang untuk menghindari waktu henti. Skrip ini menginstal Cloud Service Mesh sebagai bidang kontrol kanaris bersama bidang kontrol Istio yang ada. istio-ingressgateway diupgrade di tempat. Kemudian, Anda memberi label ulang namespace yang mendukung Istio untuk mulai menggunakan Cloud Service Mesh dengan otoritas sertifikat Cloud Service Mesh.

Pastikan Anda telah mengonfigurasi PodDisruptionBudgets dengan benar untuk aplikasi Anda sehingga Anda tidak mengalami periode nonaktif aplikasi. Meskipun Anda dapat menghindari periode nonaktif, jika Anda melakukan migrasi ini sendiri, sebaiknya lakukan migrasi ini selama masa pemeliharaan terjadwal. Migrasi yang dilakukan Google akan dilakukan selama masa pemeliharaan GKE. Pastikan cluster GKE Anda telah dikonfigurasi untuk masa pemeliharaan.

Apakah ada biaya yang terkait dengan penggunaan Cloud Service Mesh?

Ada dua cara untuk menggunakan Cloud Service Mesh di GKE:

  • Jika Anda adalah pelanggan GKE Enterprise, Cloud Service Mesh disertakan sebagai bagian dari langganan GKE Enterprise Anda.

  • Jika Anda bukan pelanggan GKE Enterprise, Anda dapat menggunakan Cloud Service Mesh sebagai produk mandiri di GKE (di Google Cloud). Untuk mengetahui informasi selengkapnya, lihat Detail harga Cloud Service Mesh.

Apakah ada fitur atau konfigurasi yang tidak didukung di Cloud Service Mesh versi terbaru?

Skrip ini memeriksa semua konfigurasi Istio dan memigrasikannya ke versi Cloud Service Mesh terbaru. Ada konfigurasi tertentu yang mungkin memerlukan langkah-langkah tambahan untuk dimigrasikan dari Istio versi 1.4 ke Cloud Service Mesh versi 1.10. Skrip akan melakukan pemeriksaan konfigurasi dan memberi tahu Anda jika ada konfigurasi yang memerlukan langkah tambahan.

Apakah migrasi mengubah konfigurasi Istio saya saat ini?

Tidak, konfigurasi Istio Anda berfungsi di Cloud Service Mesh tanpa memerlukan perubahan apa pun.

Setelah bermigrasi ke Cloud Service Mesh, dapatkah saya bermigrasi kembali ke Istio?

Ya, tidak ada komitmen untuk menggunakan Cloud Service Mesh. Anda dapat meng-uninstal Cloud Service Mesh dan menginstal ulang Istio kapan saja.

Jika migrasi gagal, apakah dapat di-roll back?

Ya, skrip ini memungkinkan Anda melakukan roll back ke versi Istio on GKE sebelumnya.

Versi Istio mana yang dapat saya migrasikan menggunakan skrip ini?

Skrip ini membantu Anda melakukan migrasi dari Istio di GKE versi 1.4 ke Cloud Service Mesh versi 1.10. Skrip memvalidasi versi Istio Anda selama tahap pra-migrasi, dan memberi tahu Anda apakah versi Istio Anda dapat dimigrasikan.

Bagaimana cara mendapatkan bantuan tambahan terkait migrasi ini?

Tim Dukungan kami siap membantu. Anda dapat membuka kasus dukungan dari konsol Google Cloud . Untuk mempelajari lebih lanjut, lihat Mengelola kasus dukungan.

Apa yang terjadi jika saya tidak bermigrasi ke Cloud Service Mesh?

Komponen Istio Anda akan terus berfungsi, tetapi Google tidak lagi mengelola penginstalan Istio Anda. Anda tidak lagi menerima update otomatis, dan penginstalan tidak dijamin berfungsi saat versi cluster Kubernetes diupdate.

Untuk mengetahui informasi selengkapnya, lihat Dukungan Istio.