Bermigrasi dari Istio di GKE ke Anthos 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 Anthos Service Mesh terkelola dengan bidang kontrol yang dikelola Google dan certificate authority Anthos Service Mesh (Mesh CA).
Prasyarat
Prasyarat berikut diperlukan untuk menyelesaikan panduan ini:
Cluster GKE dengan Istio di GKE diaktifkan. Jika Anda memiliki beberapa cluster GKE, ikuti langkah yang sama untuk semua cluster.
Istio di GKE harus 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 ini.
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 Anthos Service Mesh yang dikelola Google di saluran reguler. Panduan ini khusus untuk saluran reguler, saluran stabil atau cepat memerlukan petunjuk yang sedikit dimodifikasi. Untuk mempelajari saluran rilis lebih lanjut, buka link ini.
- Memigrasikan konfigurasi Istio ke Anthos Service Mesh.
- Konfigurasikan Mesh CA.
- Memigrasikan aplikasi ke Anthos Service Mesh.
- Mengupgrade
istio-ingressgatewaydari Istio di GKE ke Anthos Service Mesh. - Menyelesaikan migrasi Anthos Service Mesh atau melakukan roll back ke Istio di GKE.
Menyiapkan lingkungan Anda
Untuk menyiapkan lingkungan Anda, ikuti langkah-langkah berikut:
Di konsol Google Cloud, aktifkan Cloud Shell.
Di bagian bawah halaman Google Cloud Console, sesi Cloud Shell dimulai dan menampilkan prompt command line. Cloud Shell adalah lingkungan shell dengan Google Cloud CLI dan Google Cloud CLI yang sudah terinstal, serta dengan nilai yang sudah ditetapkan untuk project Anda saat ini. Perlu waktu beberapa detik untuk memulai sesi.
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.Buat folder
WORKDIR. Semua file yang terkait dengan panduan ini berakhir diWORKDIRsehingga Anda dapat menghapusWORKDIRsaat selesai.mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`Buat file
KUBECONFIGuntuk panduan ini. Anda juga dapat menggunakan fileKUBECONFIGyang sudah ada dan berisi konteks cluster untuk cluster GKE yang akan dimigrasikan ke Anthos Service Mesh.touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfigDapatkan kredensial untuk cluster GKE dan simpan konteksnya 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}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 tanda --enable-all atau --enable-registration.
Project Anda harus mengaktifkan Fitur Mesh Layanan. Anda dapat mengaktifkannya sebagai bagian dari penginstalan dengan meneruskan salah satu tanda --enable-all atau --enable-registration, atau dengan menjalankan perintah berikut sebelum penginstalan:
gcloud container hub mesh enable --project=FLEET_PROJECT_IDdengan FLEET_PROJECT_ID adalah project-id dari project host fleet.
Langkah opsional
Jika cluster adalah cluster pribadi (dengan master-authorized-networks diaktifkan),
tambahkan $SHELL_IP ke daftar yang diizinkan master-authorized-networks.
Jika sudah memiliki akses ke cluster Anda, 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 Anthos Service Mesh
Di bagian ini, Anda akan men-deploy Anthos Service Mesh dengan bidang kontrol saluran reguler yang dikelola Google di cluster GKE. Bidang kontrol ini awalnya di-deploy bersama sebagai bidang kontrol kedua (atau canary).
Download versi terbaru skrip yang menginstal Anthos Service Mesh ke direktori kerja saat ini, lalu jadikan skrip dapat dieksekusi:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcliUntuk mengonfigurasi cluster GKE, jalankan skrip penginstalan untuk menginstal Anthos Service Mesh dengan bidang kontrol saluran reguler yang dikelola Google:
./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 regularLangkah ini dapat memerlukan waktu beberapa menit hingga selesai.
Salin
istioctlke folderWORKDIR:cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
Di bagian berikutnya, Anda akan mendownload dan menjalankan skrip migrate_addon untuk membantu migrasi ke Anthos 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 Anthos Service Mesh
Di bagian ini, Anda akan memigrasikan konfigurasi Istio di GKE ke Anthos Service Mesh. Skrip yang dipandu mengidentifikasi konfigurasi yang dapat dan tidak dapat dimigrasikan.
Download alat migrasi dan setel agar dapat dieksekusi:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon chmod +x ${WORKDIR}/migrate_addonNonaktifkan webhook validasi Galley. Langkah ini diperlukan untuk memigrasikan beberapa konfigurasi 1.4 ke Anthos Service Mesh. Jawab
Yuntuk kedua pertanyaan:${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhookOutputnya 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" deletedVerifikasi 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-checkOutputnya 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 Anthos Service Mesh. Skrip sebelumnya mengidentifikasi konfigurasi kustom dan mencetak informasi tentang hal yang diperlukan. Penyesuaian ini adalah sebagai berikut:
Filter envoy kustom yang terdeteksi tidak didukung oleh Anthos Service Mesh. Hapus perilaku tersebut jika memungkinkan. Filter Envoy saat ini tidak didukung di bidang kontrol yang dikelola Google.
Sertifikat plugin kustom terdeteksi. Sertifikat plugin tidak akan dimigrasikan ke Anthos Service Mesh. Jika sertifikat plugin digunakan dengan Istio di GKE, sertifikat ini tidak akan digunakan setelah beban kerja dimigrasikan ke bidang kontrol yang dikelola Google. Semua beban kerja menggunakan sertifikat yang ditandatangani oleh CA Google Mesh. Sertifikat plugin tidak didukung oleh Mesh CA. Pesan ini bersifat informatif dan tidak ada tindakan yang perlu dilakukan.
Terdeteksi kebijakan keamanan yang tidak dapat dimigrasikan. <Error reason>. Hal ini biasanya gagal karena kebijakan AuthZ alfa yang perlu dimigrasikan secara manual. Untuk konteks dan informasi selengkapnya tentang cara memigrasikan kebijakan, lihat Memigrasikan kebijakan keamanan pra-Istio 1.4 Alpha ke API saat ini. Untuk informasi selengkapnya terkait pesan error, lihat security-policy-migration.
Terdeteksi konfigurasi VirtualService yang mungkin tidak kompatibel. <Specific Deprecated config>. Anda perlu memperbarui konfigurasi
VirtualServiceberikut:- Penggunaan
appendHeaderstidak didukung. Sebagai gantinya, gunakanspec.http.headers. - Penggunaan
websocketUpgradetidak diperlukan. Fitur ini diaktifkan secara default. - Ganti kolom
abort.percentdenganabort.percentage.
- Penggunaan
Mendeteksi penginstalan kustom resource mixer yang tidak dapat dimigrasikan. Memerlukan migrasi manual ke telemetriv2. Jika kebijakan mixer kustom dikonfigurasi selain Istio default pada penginstalan GKE, Anda harus memigrasikan kebijakan ini secara manual ke telemetri v2. Untuk mengetahui informasi selengkapnya tentang cara melakukannya, lihat Menyesuaikan Metrik Istio.
Deployment <deploymentName> dapat menjadi gateway kustom. Migrasikan ini secara manual. Anda perlu memigrasikan semua Deployment gateway secara manual selain
istio-ingressgateway(yang diinstal secara default). Untuk mengetahui 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:
Migrasikan semua konfigurasi kustom secara manual (kecuali untuk konfigurasi terakhir yang tercantum) sebelum melanjutkan ke langkah 2.
Gunakan alat migrasi untuk memigrasikan konfigurasi yang dapat dimigrasikan secara otomatis (atau diabaikan).
${WORKDIR}/migrate_addon -d tmpdir --command migrate-configsOutputnya 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
Terapkan kepercayaan root CA Mesh. Hal ini memungkinkan Anda bermigrasi dari Citadel CA saat ini ke Mesh CA tanpa menimbulkan periode nonaktif pada aplikasi Anda.
${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-caOutputnya 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 OKLangkah ini memerlukan waktu beberapa menit agar root certificate Anthos Service Mesh didistribusikan ke semua namespace. Tunggu hingga skrip selesai dengan pesan
OK.
Langkah sebelumnya akan melakukan hal berikut:
- Menginstal root kepercayaan CA Mesh untuk semua workload di cluster.
Mengubah konfigurasi bidang kontrol Deployment
istio-pilot,istiod, danistio-citadel. Perubahan tersebut meliputi:- Meningkatkan versi gambar ke versi terbaru.
- Menonaktifkan verifikasi
trust-domaindengan menetapkanPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true. - Menambahkan root kepercayaan CA Mesh ke
istio-citadeluntuk mendistribusikanConfigMapke semua namespace. - Menambahkan root kepercayaan CA Mesh ke
istio-ca-secretuntuk mendistribusikan root certificate.
Menyimpan manifes konfigurasi lama di
tmpdir.Memberikan langkah-langkah untuk fungsi rollback (didokumentasikan nanti).
Memigrasikan workload ke Anthos Service Mesh
Di bagian ini, Anda akan memigrasikan workload yang berjalan di Istio di GKE ke Anthos Service Mesh. Setelah migrasi, Anda memverifikasi bahwa proxy file bantuan yang benar (Anthos Service Mesh) dimasukkan ke setiap Pod dan bahwa aplikasi berfungsi sesuai yang diharapkan.
Jika Anda melakukan prosedur ini pada cluster yang sudah ada, pilih namespace yang akan dimigrasikan.
Tentukan namespace sebagai variabel; namespace ini dimigrasikan ke Anthos Service Mesh:
export NAMESPACE=NAMESPACE_NAME
Untuk memigrasikan workload ke Anthos Service Mesh, Anda harus memberi label ulang namespace untuk Anthos Service Mesh. Dengan pelabelan namespace, Anthos Service Mesh dapat memasukkan file bantuan secara otomatis ke semua workload. Untuk memberi label pada namespace, jalankan perintah berikut, dengan menyetel label ke
asm-managed:kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwriteLakukan mulai ulang berkelanjutan semua Deployment dalam 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 ...
Pastikan semua Pod dimulai ulang dan berjalan dengan dua container per Pod:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get podsOutputnya 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 tepat untuk memverifikasi langkah ini adalah dengan melihat
AGEPod. Pastikan nilainya singkat—misalnya, beberapa menit.Periksa versi proxy Envoy file bantuan dari salah satu Pod dari Deployment mana pun di namespace untuk memastikan bahwa Anda sekarang telah men-deploy proxy Anthos Service Mesh Envoy:
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'Outputnya mirip dengan hal berikut ini:
"gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3" "appContainerImage"
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}'(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 menghasilkan SUCCESS, bidang kontrol telah berhasil diupgrade ke Anthos Service Mesh. Untuk memperbarui bidang data secara manual, selesaikan langkah-langkah
dalam Memigrasikan beban kerja.
Jika migrationStatus menghasilkan status selain SUCCESS, Anda dapat memilih untuk:
- Tidak perlu melakukan tindakan lain jika error migrasi tidak memengaruhi Istio yang ada pada workload GKE. Atau, rollback jika diperlukan.
- Perbarui konfigurasi kustom
dalam cluster dan jalankan ulang migrasi secara manual jika
migrationStatusmenampilkanMIGRATION_CONFIG_ERROR.
Anda dapat melihat metrik bidang kontrol di Metrics Explorer setelah migrasi berhasil, lihat verify_control_plane_metrics
Mengakses dasbor Anthos Service Mesh
Di bagian ini, Anda akan membuka dasbor Anthos Service Mesh dan memastikan Anda menerima sinyal emas untuk semua Layanan. Anda juga akan dapat melihat topologi aplikasi.
Di konsol Google Cloud, buka halaman Anthos Service Mesh.
Anda akan dapat melihat metrik dan topologi untuk Layanan Anda.
Untuk mempelajari dasbor Anthos Service Mesh lebih lanjut, lihat Menjelajahi Anthos Service Mesh di Konsol Google Cloud.
Menyelesaikan migrasi yang berhasil
Di bagian ini, Anda akan menyelesaikan migrasi Istio di GKE ke Anthos Service Mesh. Sebelum melanjutkan ke bagian ini, pastikan Anda ingin melanjutkan dengan Anthos Service Mesh. Bagian ini juga membantu Anda membersihkan Istio di artefak GKE. Jika Anda ingin melakukan roll back ke Istio di GKE, lanjutkan ke bagian berikutnya.
Ganti
istio-ingressgateway(bagian dari Istio standar di GKE) dengan gateway berversi bidang kontrol yang dikelola Google:${WORKDIR}/migrate_addon -d tmpdir --command replace-gatewayOutputnya 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 OKKonfigurasi 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-webhookOutputnya 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' OKBeri label ulang semua namespace dengan label Anthos Service Mesh, dan jalankan mulai ulang berkelanjutan semua workload 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"di output. Artinya, namespace sebelumnya tidak memiliki labelistio-injection, yang akan Anda harapkan dalam penginstalan baru Anthos Service Mesh atau deployment baru. Karena injeksi otomatis gagal jika namespace memilikiistio-injectiondan label revisi, semua perintahkubectl labeldalam dokumentasi Istio pada GKE mencakup penghapusan labelistio-injection.Selesaikan migrasi dengan menjalankan perintah berikut:
${WORKDIR}/migrate_addon -d tmpdir --command write-markerOutputnya mirip dengan hal berikut ini:
Current migration state: SUCCESS Running: kubectl apply -f - configmap/asm-addon-migration-state created OK
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=DISABLEDCluster regional
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --region=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLEDBersihkan konfigurasi dengan menjalankan perintah berikut:
${WORKDIR}/migrate_addon -d tmpdir --command cleanupOutputnya 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" deletedPastikan Istio pada Deployment dan Layanan GKE telah berhasil dihapus dari cluster:
kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,servicesOutputnya 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 Anthos Service Mesh.
Selamat. Anda telah berhasil melakukan migrasi dari Istio di GKE ke Anthos Service Mesh dengan bidang kontrol yang dikelola Google dan Mesh CA tanpa periode nonaktif untuk aplikasi Anda.
Kembalikan perubahan
Di bagian ini, jika tidak ingin melanjutkan penggunaan Anthos Service Mesh, Anda dapat me-roll back perubahan Anthos Service Mesh. Setelah menyelesaikan bagian ini, beban kerja Anda akan dipindahkan kembali ke Istio di GKE.
Lakukan rollback perubahan webhook yang berubah:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhookBeri label ulang pada namespace untuk menggunakan Istio pada injeksi sidecar GKE, bukan Anthos Service Mesh, dengan menjalankan perintah berikut:
untuk namespace dengan workload versi 1.4:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwriteuntuk namespace dengan workload versi 1.6:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwriteLakukan mulai ulang berkelanjutan semua Deployment dalam namespace:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}Tunggu beberapa menit, lalu pastikan semua Pod berjalan:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get podsOutputnya mirip dengan hal berikut ini:
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
Verifikasi versi proxy Envoy file bantuan dari salah satu Pod untuk mengonfirmasi bahwa Anda memiliki proxy Istio di GKE v1.4 Envoy yang di-deploy:
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"
Verifikasi dan uji aplikasi Anda setelah memulai ulang.
Roll back perubahan Mesh CA:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-caAktifkan kembali webhook Istio Galley:
${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
Anda telah berhasil melakukan roll back perubahan pada Istio di GKE.
Terapkan Butik Online
Di bagian ini, Anda akan men-deploy contoh aplikasi berbasis microservice yang disebut Online Boutique ke cluster GKE. Butik Online diterapkan di namespace yang mendukung Istio. Anda memastikan bahwa aplikasi berfungsi dan bahwa Istio di GKE memasukkan proxy file bantuan ke setiap Pod.
Jika sudah memiliki cluster yang dilengkapi aplikasi, Anda dapat melewati proses pembuatan namespace baru dan men-deploy Butik Online. Anda dapat mengikuti proses yang sama untuk semua namespace di bagian Memigrasikan workload ke Anthos Service Mesh.
Men-deploy Butik Online 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-boutiqueTunggu 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 recommendationservicePastikan ada dua container per Pod—container aplikasi dan proxy file bantuan Istio yang otomatis dimasukkan Istio di GKE ke dalam Pod:
kubectl --context=${CLUSTER_1_CTX} -n online-boutique get podsOutputnya 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
Anda juga dapat memeriksa versi proxy Envoy file bantuan dari salah satu Pod untuk mengonfirmasi bahwa Anda memiliki Istio di proxy Envoy GKE v1.4 yang di-deploy:
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"
Akses aplikasi dengan membuka alamat IP alamat IP Layanan
istio-ingressgateway: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 memigrasikan dari Istio di GKE ke Anthos Service Mesh.
Mengapa saya dimigrasikan dari Istio di GKE ke Anthos 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 menyediakan fitur mesh layanan terbaru dan implementasi mesh layanan yang didukung, kami akan mengupgrade semua pengguna Istio di GKE ke Anthos Service Mesh.
Anthos Service Mesh adalah produk mesh layanan yang dikelola dan didukung Google yang didukung oleh Istio API. Anthos Service Mesh menggunakan Istio, sama seperti GKE bagi Kubernetes. Karena Anthos Service Mesh didasarkan pada Istio API, Anda dapat terus menggunakan konfigurasi Istio saat bermigrasi ke Anthos Service Mesh. Selain itu, tidak ada ikatan vendor eksklusif.
Anthos Service Mesh memberikan manfaat berikut:
- Mesh layanan yang dikelola Google dan didukung Google.
- Istio API tanpa ikatan vendor.
- Dasbor telemetri siap pakai dan pengelolaan SLO tanpa persyaratan untuk mengelola solusi pihak ketiga tambahan.
- Opsi certificate authority yang dihosting Google.
- Integrasi dengan networking Google Cloud dan Identity-Aware Proxy (IAP).
- Dukungan platform hybrid dan multi-cloud.
Untuk mempelajari fitur dan kemampuan Anthos Service Mesh lebih lanjut, lihat Fitur yang didukung bidang kontrol yang dikelola Google.
Apakah ada periode nonaktif yang terkait dengan migrasi ini?
Skrip migrasi dirancang untuk menghindari periode nonaktif. Skrip ini menginstal
Anthos Service Mesh sebagai
bidang kontrol canary
bersama bidang kontrol Istio yang sudah ada. istio-ingressgateway
diupgrade di tempatnya. Kemudian, Anda akan melabeli ulang namespace yang mengaktifkan Istio untuk mulai menggunakan Anthos Service Mesh dengan certificate authority Anthos Service Mesh (Mesh CA).
Pastikan PodDisruptionBudgets telah dikonfigurasi dengan benar untuk aplikasi Anda sehingga tidak terjadi periode nonaktif pada aplikasi. Meskipun dapat menghindari periode nonaktif, jika Anda melakukan migrasi ini sendiri, sebaiknya lakukan migrasi ini selama masa pemeliharaan terjadwal. Migrasi berbasis Google dilakukan selama masa pemeliharaan GKE. Pastikan cluster GKE Anda telah mengonfigurasi masa pemeliharaan.
Apakah ada biaya terkait penggunaan Anthos Service Mesh?
Ada dua cara untuk menggunakan Anthos Service Mesh di GKE:
Jika Anda adalah pelanggan GKE Enterprise, Anthos Service Mesh disertakan sebagai bagian dari langganan GKE Enterprise Anda.
Jika Anda bukan pelanggan GKE Enterprise, Anda dapat menggunakan Anthos Service Mesh sebagai produk mandiri di GKE (di Google Cloud). Untuk mengetahui informasi selengkapnya, lihat detail harga Anthos Service Mesh.
Apakah ada fitur atau konfigurasi yang tidak didukung di versi terbaru Anthos Service Mesh?
Skrip ini memeriksa semua konfigurasi Istio dan memigrasikannya ke versi Anthos Service Mesh terbaru. Ada konfigurasi tertentu yang mungkin memerlukan langkah tambahan untuk dimigrasikan dari Istio versi 1.4 ke Anthos Service Mesh versi 1.10. Skrip ini melakukan pemeriksaan konfigurasi dan memberi tahu Anda jika ada konfigurasi yang memerlukan langkah tambahan.
Apakah migrasi akan mengubah konfigurasi Istio saya saat ini?
Tidak, konfigurasi Istio Anda berfungsi di Anthos Service Mesh tanpa memerlukan perubahan apa pun.
Setelah bermigrasi ke Anthos Service Mesh, dapatkah saya melakukan migrasi kembali ke Istio?
Ya, tidak ada komitmen untuk menggunakan Anthos Service Mesh. Anda dapat meng-uninstal Anthos Service Mesh dan menginstal ulang Istio kapan saja.
Jika migrasi gagal, apakah saya dapat melakukan roll back?
Ya, skrip ini memungkinkan Anda melakukan roll back ke Istio sebelumnya di versi GKE.
Versi Istio mana yang dapat saya migrasikan dengan menggunakan skrip ini?
Skrip ini membantu Anda bermigrasi dari Istio di GKE versi 1.4 ke Anthos Service Mesh versi 1.10. Skrip ini memvalidasi versi Istio Anda selama tahap pra-migrasi, dan memberi tahu Anda apakah versi Istio Anda dapat dimigrasikan atau tidak.
Bagaimana cara mendapatkan bantuan tambahan terkait migrasi ini?
Tim Dukungan kami akan dengan senang hati membantu Anda. 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 Anthos Service Mesh?
Komponen Istio Anda akan terus berfungsi, tetapi Google tidak lagi mengelola penginstalan Istio Anda. Anda tidak lagi akan menerima update otomatis, dan penginstalan tidak dijamin akan berfungsi saat versi cluster Kubernetes diupdate.
Untuk mengetahui informasi selengkapnya, lihat Dukungan Istio.