Migrasi berbasis Canary ke CA Mesh
Bermigrasi ke certificate authority (CA) Cloud Service Mesh (Mesh CA) dari Istio CA (juga dikenal sebagai Citadel) memerlukan migrasi root of trust. Sebelum Cloud Service Mesh 1.10, jika ingin bermigrasi dari Istio di Google Kubernetes Engine (GKE) ke Cloud Service Mesh dengan CA Mesh, Anda harus menjadwalkan downtime karena Cloud Service Mesh tidak dapat memuat beberapa root certificate. Oleh karena itu, selama migrasi, workload yang baru di-deploy memercayai root certificate baru, sementara yang lain memercayai root certificate lama. Workload yang menggunakan sertifikat yang ditandatangani oleh sertifikat root yang berbeda tidak dapat mengautentikasi satu sama lain. Artinya, traffic TLS bersama (mTLS) akan terganggu selama migrasi. Seluruh cluster hanya akan sepenuhnya pulih jika bidang kontrol dan semua workload di semua namespace di-deploy ulang dengan sertifikat CA Mesh. Jika mesh Anda memiliki beberapa cluster dengan workload yang mengirim permintaan ke workload di cluster lain, semua workload di cluster tersebut juga harus diupdate.
Gunakan langkah-langkah dalam panduan ini untuk kasus penggunaan berikut:
- Bermigrasi dari Istio di GKE ke bidang kontrol dalam cluster 1.18.7-asm.26 Cloud Service Mesh dengan CA Mesh.
- Upgrade dari Cloud Service Mesh 1.15 or a 1.16 patch release dengan CA Istio ke bidang kontrol dalam cluster Cloud Service Mesh 1.18.7-asm.26 dengan CA Mesh.
Batasan
- Semua cluster GKE harus berada dalam project Google Cloud yang sama.
Prasyarat
Ikuti langkah-langkah di bagian Menginstal alat dependen dan memvalidasi cluster untuk:- Menginstal alat yang diperlukan
- Download
asmcli
- Memberikan izin admin cluster
- Memvalidasi project dan cluster Anda
Alat yang diperlukan
Selama migrasi, Anda menjalankan alat yang disediakan Google, migrate_ca
, untuk
memvalidasi hal berikut untuk setiap Pod di cluster:
- Sertifikat root untuk CA Istio dan CA Mesh.
- Sertifikat mTLS workload yang diterbitkan oleh CA Istio dan oleh CA Mesh.
- Domain kepercayaan yang dikonfigurasi oleh CA Istio dan CA Mesh.
Alat ini memiliki dependensi berikut:
awk
grep
istioctl
Menjalankanasmcli install
akan mendownload versiistioctl
yang cocok dengan versi Cloud Service Mesh yang Anda instal.jq
kubectl
openssl
Ringkasan migrasi
Untuk bermigrasi ke CA Mesh, Anda harus mengikuti proses migrasi berbasis revisi (juga disebut sebagai "upgrade canary"). Dengan migrasi berbasis revisi, revisi control plane baru di-deploy bersama control plane yang ada. Kemudian, Anda akan memindahkan workload secara bertahap ke revisi baru, yang memungkinkan Anda memantau dampak migrasi melalui proses tersebut. Selama proses migrasi, autentikasi dan otorisasi berfungsi sepenuhnya antara workload yang menggunakan CA Mesh dan workload yang menggunakan CA Istio.
Berikut adalah ringkasan migrasi ke CA Mesh:
Mendistribusikan root of trust CA Mesh.
Instal revisi bidang kontrol baru yang menggunakan CA Istio dengan opsi yang akan mendistribusikan root of trust CA Mesh.
Migrasikan workload ke platform kontrol baru, namespace demi namespace, dan uji aplikasi Anda. Setelah semua workload berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.
Bermigrasi ke CA Mesh. Setelah semua proxy sidecar dikonfigurasi dengan root trust lama dan root trust CA Mesh, Anda dapat bermigrasi ke CA Mesh tanpa downtime. Sekali lagi, Anda mengikuti proses migrasi berbasis revisi:
Instal revisi bidang kontrol dengan Mesh CA diaktifkan.
Migrasikan workload ke revisi kontrol plane baru, namespace per namespace, dan uji aplikasi Anda. Jika semua workload berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.
Hapus secret CA di cluster yang terkait dengan CA lama dan mulai ulang platform kontrol baru.
Mendistribusikan root of trust CA Mesh
Sebelum Anda dapat bermigrasi ke Mesh CA, semua cluster GKE dalam mesh harus memiliki Cloud Service Mesh 1.10 atau yang lebih baru, dan semua cluster harus dikonfigurasi dengan opsi bidang kontrol yang memicu root of trust agar Mesh CA dapat didistribusikan ke proxy semua workload di cluster. Setelah proses selesai, setiap proxy dikonfigurasi dengan root kepercayaan lama dan baru. Dengan skema ini, saat Anda bermigrasi ke CA Mesh, workload yang menggunakan CA Mesh akan dapat melakukan autentikasi dengan workload yang menggunakan CA lama.
Menginstal revisi bidang kontrol baru
Instal revisi bidang kontrol dengan opsi yang mendistribusikan root of trust Mesh CA.
Ikuti langkah-langkah di Menginstal alat dependen dan memvalidasi cluster untuk bersiap menggunakan alat yang disediakan Google,
asmcli
, guna menginstal revisi panel kontrol baru.Pastikan Anda memiliki versi
asmcli
yang menginstal Cloud Service Mesh 1.11 atau yang lebih tinggi:./asmcli --version
Jalankan
asmcli install
. Dalam perintah berikut, ganti placeholder dengan nilai Anda../asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH
--fleet_id
Project ID dari project host fleet.--kubeconfig
Jalur ke filekubeconfig
Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan$PWD
tidak berfungsi di sini.--output_dir
Sertakan opsi ini untuk menentukan direktori tempatasmcli
mendownload paketanthos-service-mesh
dan mengekstrak file penginstalan, yang berisiistioctl
, sampel, dan manifes. Jika tidak,asmcli
akan mendownload file ke direktoritmp
. Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan$PWD
tidak berfungsi di sini.-
--enable_all
Memungkinkan alat untuk:- Berikan izin IAM yang diperlukan.
- Aktifkan Google API yang diperlukan.
- Tetapkan label pada cluster yang mengidentifikasi mesh.
- Daftarkan cluster ke fleet jika belum terdaftar.
-ca citadel
Untuk menghindari periode nonaktif, tentukan CA Istio (opsicitadel
sesuai dengan CA Istio). Jangan beralih ke CA Mesh pada tahap ini.--ca_cert
Sertifikat intermediate.--ca_key
Kunci untuk intermediate certificate--root_cert
Root certificate.--cert_chain
Rantai sertifikat.--option ca-migration-citadel
Saat Anda men-deploy ulang workload, opsi ini akan memicu root of trust baru untuk didistribusikan ke proxy sidecar workload.REVISION_1
: Direkomendasikan. Label revisi adalah pasangan nilai kunci yang ditetapkan di bidang kontrol. Kunci label revisi selaluistio.io/rev
. Secara default, alat ini menetapkan nilai untuk label revisi berdasarkan versi Cloud Service Mesh, misalnya:asm-1187-26
. Sebaiknya sertakan opsi ini dan gantiREVISION_1
dengan nama yang menjelaskan penginstalan, sepertiasm-1187-26-distribute-root
. Nama harus berupa label DNS-1035, dan harus terdiri dari karakter alfanumerik huruf kecil atau-
, diawali dengan karakter alfabet, dan diakhiri dengan karakter alfanumerik (sepertimy-name
atauabc-123
).
Memigrasikan workload ke bidang kontrol baru
Untuk menyelesaikan distribusi root of trust baru, Anda perlu memberi label pada
namespace dengan label revisi
istio.io/rev=<var>REVISION_1</var>-distribute-root
dan memulai ulang
workload. Saat menguji workload setelah memulai ulang, Anda menjalankan alat
untuk memvalidasi bahwa proxy sidecar dikonfigurasi dengan root trust lama dan baru
untuk CA Mesh.
Tetapkan konteks saat ini untuk
kubectl
. Pada perintah berikut, ubah--region
menjadi--zone
jika Anda memiliki cluster satu zona.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION
Download alat validasi:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
Tetapkan bit yang dapat dieksekusi pada alat:
chmod +x migrate_ca
Alat
migrate_ca
memanggilistioctl
, yang bergantung pada versi. Alatasmcli
menambahkan symlink keistioctl
di direktori yang Anda tentukan untuk--output_dir
. Pastikan direktori tersebut berada di awal jalur Anda. Dalam perintah berikut, gantiISTIOCTL_PATH
dengan direktori yang berisiistioctl
yang didownload alat.export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
Dapatkan label revisi yang ada di
istiod
danistio-ingressgateway
.kubectl get pod -n istio-system -L istio.io/rev
Outputnya mirip dengan hal berikut ini:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-5fd454f8ff-t7w9x 1/1 Running 0 36m default istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p 1/1 Running 0 18m asm-195-2-distribute-root istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs 1/1 Running 0 18m asm-195-2-distribute-root istiod-68bc495f77-shl2h 1/1 Running 0 36m default istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c 1/1 Running 0 18m asm-195-2-distribute-root istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s 1/1 Running 0 18m asm-195-2-distribute-root
Dalam output, di kolom
REV
, perhatikan nilai label revisi untuk revisi baru, yang cocok dengan label revisi yang Anda tentukan saat menjalankanasmcli install
. Dalam contoh ini, nilainya adalahasm-1187-26-distribute-root
.Anda harus menghapus revisi
istiod
lama setelah selesai memindahkan beban kerja ke revisi baru. Perhatikan nilai dalam label revisi untuk revisiistiod
lama. Contoh output menunjukkan migrasi dari Istio, yang menggunakan revisidefault
.
Tambahkan label revisi ke namespace dan hapus label
istio-injection
(jika ada). Pada perintah berikut, gantiNAMESPACE
dengan namespace yang akan diberi label.kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
Jika Anda melihat
"istio-injection not found"
dalam output, Anda dapat mengabaikannya. Artinya, namespace sebelumnya tidak memiliki labelistio-injection
. Karena perilaku injeksi otomatis tidak ditentukan saat namespace memiliki labelistio-injection
dan revisi, semua perintahkubectl label
dalam dokumentasi Cloud Service Mesh secara eksplisit memastikan bahwa hanya satu yang ditetapkan.Mulai ulang Pod untuk memicu injeksi ulang.
kubectl rollout restart deployment -n NAMESPACE
Uji aplikasi Anda untuk memverifikasi bahwa workload berfungsi dengan benar.
Jika Anda memiliki workload di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan mulai ulang Pod.
Validasi bahwa proxy sidecar untuk semua workload di cluster dikonfigurasi dengan sertifikat root lama dan baru:
./migrate_ca check-root-cert
Output yang diharapkan:
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
Jika Anda perlu memigrasikan gateway, ikuti langkah-langkah di Upgrade Canary (lanjutan) untuk menginstal deployment gateway baru. Ingat selalu hal-hal berikut:
- Gunakan
REVISION_1
sebagai label revisi. - Deploy resource gateway di namespace yang sama dengan gateway dari penginstalan lama untuk melakukan migrasi tanpa downtime. Pastikan bahwa resource layanan yang mengarah ke gateway lama juga harus menyertakan deployment yang lebih baru sekarang.
- Jangan hapus deployment gateway lama hingga Anda yakin bahwa aplikasi Anda berfungsi dengan benar (setelah langkah berikutnya).
- Gunakan
Jika Anda yakin bahwa aplikasi berfungsi seperti yang diharapkan, lanjutkan dengan langkah-langkah untuk bertransisi ke versi
istiod
baru. Jika ada masalah dengan aplikasi Anda, ikuti langkah-langkah untuk melakukan rollback.Menyelesaikan transisi
Jika Anda yakin bahwa aplikasi berfungsi seperti yang diharapkan, hapus platform kontrol lama untuk menyelesaikan transisi ke versi baru.
Ubah ke direktori tempat file dari repositori GitHub
anthos-service-mesh
berada.Konfigurasikan webhook validasi untuk menggunakan bidang kontrol baru.
kubectl apply -f asm/istio/istiod-service.yaml
Hapus Deployment
istio-ingressgateway
lama. Perintah yang Anda jalankan bergantung pada apakah Anda bermigrasi dari Istio atau mengupgrade dari Cloud Service Mesh versi sebelumnya:Migrasi
Jika Anda bermigrasi dari Istio,
istio-ingressgateway
lama tidak memiliki label revisi.kubectl delete deploy/istio-ingressgateway -n istio-system
Upgrade
Jika Anda mengupgrade dari versi Cloud Service Mesh sebelumnya, dalam perintah berikut, ganti
OLD_REVISION
dengan label revisi untuk versiistio-ingressgateway
sebelumnya.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Hapus revisi lama
istiod
. Perintah yang Anda gunakan bergantung pada apakah Anda bermigrasi dari Istio atau mengupgrade dari versi Cloud Service Mesh sebelumnya.Migrasi
Jika Anda bermigrasi dari Istio,
istio-ingressgateway
lama tidak memiliki label revisi.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Upgrade
Jika Anda mengupgrade dari versi Cloud Service Mesh sebelumnya, dalam perintah berikut, pastikan
OLD_REVISION
cocok dengan label revisi untukistiod
versi sebelumnya.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Hapus konfigurasi
IstioOperator
versi lama.kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
Output yang diharapkan mirip dengan berikut ini:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Rollback
Jika Anda mengalami masalah saat menguji aplikasi dengan versi
istiod
baru, ikuti langkah-langkah berikut untuk melakukan rollback ke versi sebelumnya:Hapus deployment gateway baru yang diinstal sebagai bagian dari langkah 11.
Beri label ulang namespace Anda untuk mengaktifkan injeksi otomatis dengan versi
istiod
sebelumnya. Perintah yang Anda gunakan bergantung pada apakah Anda menggunakan label revisi atauistio-injection=enabled
dengan versi sebelumnya.Jika Anda menggunakan label revisi untuk injeksi otomatis:
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
Jika Anda menggunakan
istio-injection=enabled
:kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Output yang diharapkan:
namespace/NAMESPACE labeled
Pastikan label revisi pada namespace cocok dengan label revisi pada versi
istiod
sebelumnya:kubectl get ns NAMESPACE --show-labels
Mulai ulang Pod untuk memicu injeksi ulang sehingga proxy memiliki versi sebelumnya:
kubectl rollout restart deployment -n NAMESPACE
Hapus Deployment
istio-ingressgateway
baru.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
Hapus revisi baru
istiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
Hapus konfigurasi
IstioOperator
baru.kubectl delete IstioOperator installed-state-asm-1187-26-distribute-root -n istio-system
Output yang diharapkan mirip dengan berikut ini:
istiooperator.install.istio.io "installed-state-asm-1187-26-distribute-root" deleted
Bermigrasi ke CA Mesh
Setelah proxy sidecar untuk semua workload dikonfigurasi dengan root trust lama dan root trust baru untuk CA Mesh, langkah-langkah untuk bermigrasi ke CA Mesh mirip dengan yang Anda lakukan untuk mendistribusikan root trust CA Mesh:
Menginstal bidang kontrol baru dengan CA Mesh yang diaktifkan
Anda menggunakan asmcli install
untuk menginstal revisi bidang kontrol baru yang mengaktifkan CA
Mesh.
Jika Anda menyesuaikan penginstalan sebelumnya, Anda harus menentukan file overlay yang sama saat menjalankan
asmcli install
.Jalankan
asmcli install
. Dalam perintah berikut, ganti placeholder dengan nilai Anda../asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --enable_all \ --ca mesh_ca \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
--fleet_id
Project ID dari project host fleet.--kubeconfig
Jalur ke filekubeconfig
Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan$PWD
tidak berfungsi di sini.--output_dir
Sertakan opsi ini untuk menentukan direktori tempatasmcli
mendownload paketanthos-service-mesh
dan mengekstrak file penginstalan, yang berisiistioctl
, sampel, dan manifes. Jika tidak,asmcli
akan mendownload file ke direktoritmp
. Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan$PWD
tidak berfungsi di sini.-
--enable_all
Memungkinkan alat untuk:- Berikan izin IAM yang diperlukan.
- Aktifkan Google API yang diperlukan.
- Tetapkan label pada cluster yang mengidentifikasi mesh.
- Daftarkan cluster ke fleet jika belum didaftarkan.
--ca mesh_ca
Anda kini dapat beralih ke CA Mesh karena root of trust CA Mesh telah didistribusikan.REVISION_2
Direkomendasikan. GantiREVISION_2
dengan nama yang mendeskripsikan penginstalan, sepertiasm-1187-26-meshca-ca-migration
. Nama harus berupa label DNS-1035, dan harus terdiri dari karakter alfanumerik huruf kecil atau-
, diawali dengan karakter alfabet, dan diakhiri dengan karakter alfanumerik (sepertimy-name
atauabc-123
).--option ca-migration-migration
Saat Anda men-deploy ulang beban kerja, opsi ini akan mengonfigurasi proxy untuk menggunakan root of trust CA Mesh.
Memigrasikan workload ke bidang kontrol baru
Untuk menyelesaikan penginstalan, Anda perlu memberi label pada namespace dengan label revisi baru dan memulai ulang workload.
Dapatkan label revisi yang ada di
istiod
danistio-ingressgateway
.kubectl get pod -n istio-system -L istio.io/rev
Outputnya mirip dengan hal berikut ini:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-asm-1187-26-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1187-26-distribute-root istio-ingressgateway-asm-1187-26-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1187-26-distribute-root istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1187-26-meshca-ca-migration istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1187-26-meshca-ca-migration istiod-asm-1187-26-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1187-26-distribute-root istiod-asm-1187-26-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1187-26-distribute-root istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1187-26-meshca-ca-migration istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1187-26-meshca-ca-migration
Dalam output, di kolom
REV
, catat nilai label revisi untuk versi baru. Dalam contoh ini, nilainya adalahasm-1187-26-meshca-ca-migration
.Perhatikan juga nilai di label revisi untuk versi
istiod
lama. Anda memerlukannya untuk menghapusistiod
versi lama setelah selesai memindah workload ke versi baru. Dalam contoh, nilai label revisi untuk revisi sebelumnya adalahasm-1187-26-distribute-root
.
Tambahkan label revisi baru ke namespace. Pada perintah berikut, ganti
NAMESPACE
dengan namespace yang akan diberi label.kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
Mulai ulang Pod untuk memicu injeksi ulang.
kubectl rollout restart deployment -n NAMESPACE
Uji aplikasi Anda untuk memverifikasi bahwa workload berfungsi dengan benar. Pastikan komunikasi mTLS berfungsi di antara workload di namespace lama dan workload di namespace yang lebih baru.
Jika Anda memiliki workload di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan mulai ulang Pod.
Ikuti langkah-langkah yang diuraikan dalam Upgrade langsung untuk mengupgrade deployment gateway lama yang diinstal pada langkah 11 di bagian sebelumnya ke revisi terbaru
REVISION_2
.Jika Anda yakin bahwa aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan langkah-langkah untuk bertransisi ke platform kontrol baru. Jika ada masalah dengan aplikasi Anda, ikuti langkah-langkah untuk melakukan rollback.
Menyelesaikan transisi
Jika Anda yakin bahwa aplikasi berfungsi seperti yang diharapkan, hapus platform kontrol lama untuk menyelesaikan transisi ke versi baru.
Ubah ke direktori tempat file dari repositori GitHub
anthos-service-mesh
berada.Konfigurasikan webhook validasi untuk menggunakan bidang kontrol baru.
kubectl apply -f asm/istio/istiod-service.yaml
Hapus Deployment
istio-ingressgateway
lama. Dalam perintah berikut, gantiOLD_REVISION
dengan label revisi untuk versiistio-ingressgateway
sebelumnya.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Hapus revisi
istiod
lama. Pada perintah berikut, gantiOLD_REVISION
dengan label revisi untuk versiistiod
sebelumnya.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Hapus konfigurasi
IstioOperator
lama.kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
Output yang diharapkan mirip dengan berikut ini:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Rollback
Jika Anda mengalami masalah saat menguji aplikasi dengan revisi
istiod
baru, ikuti langkah-langkah berikut untuk melakukan rollback ke revisi sebelumnya:Ikuti langkah-langkah di Upgrade langsung untuk mendowngrade deployment gateway yang sebelumnya diupgrade di langkah 6 bagian ini ke revisi lama
REVISION_1
.Beri label ulang namespace Anda untuk mengaktifkan injeksi otomatis dengan revisi
istiod
sebelumnya.kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
Output yang diharapkan:
namespace/NAMESPACE labeled
Pastikan label revisi pada namespace cocok dengan label revisi pada versi
istiod
sebelumnya:kubectl get ns NAMESPACE --show-labels
Mulai ulang Pod untuk memicu injeksi ulang sehingga proxy memiliki versi sebelumnya:
kubectl rollout restart deployment -n NAMESPACE
Hapus Deployment
istio-ingressgateway
baru.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
Hapus
istiod
versi baru. Pastikan label revisi dalam perintah berikut cocok dengan revisi Anda.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
Hapus versi baru konfigurasi
IstioOperator
.kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
Output yang diharapkan mirip dengan berikut ini:
istiooperator.install.istio.io "installed-state-REVISION_2" deleted
Menghapus secret CA dan memulai ulang bidang kontrol baru
Simpan secret untuk berjaga-jaga jika Anda memerlukannya:
kubectl get secret/cacerts -n istio-system -o yaml > save_file_1 kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
Hapus secret CA di cluster yang terkait dengan CA lama:
kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
Mulai ulang bidang kontrol yang baru diinstal. Tindakan ini memastikan root kepercayaan lama dihapus dari semua beban kerja yang berjalan di mesh.
kubectl rollout restart deployment -n istio-system