Migrasi ke certificate authority Anthos Service Mesh (Mesh CA) dari Istio CA (juga dikenal sebagai Citadel) memerlukan migrasi root kepercayaan. Sebelum Anthos Service Mesh 1.10, jika ingin bermigrasi dari Istio di Google Kubernetes Engine (GKE) ke Anthos Service Mesh dengan Mesh CA, Anda harus menjadwalkan periode nonaktif karena Anthos 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. Beban kerja yang menggunakan sertifikat yang ditandatangani oleh root certificate yang berbeda tidak dapat saling melakukan autentikasi. Artinya, traffic multi-TLS (mTLS) terganggu selama migrasi. Seluruh cluster hanya sepenuhnya pulih saat bidang kontrol dan semua workload di semua namespace di-deploy ulang dengan sertifikat Mesh CA. Jika mesh Anda memiliki beberapa cluster dengan beban kerja yang mengirimkan permintaan ke workload di cluster lain, semua workload di cluster tersebut juga perlu diperbarui.
Halaman ini menjelaskan cara melakukan migrasi dari Istio CA ke Mesh CA dengan periode nonaktif minimal atau tanpa periode nonaktif. Gunakan langkah-langkah dalam panduan ini untuk kasus penggunaan berikut:
- Bermigrasi dari Istio di GKE ke bidang kontrol dalam cluster 1.10.6-asm.2 Anthos Service Mesh dengan Mesh CA.
- Mengupgrade dari 1.9 or a 1.10 patch release Anthos Service Mesh dengan Istio CA ke bidang kontrol dalam cluster 1.10.6-asm.2 Anthos Service Mesh dengan Mesh CA.
Batasan
- Mesh CA hanya didukung di GKE.
- Semua cluster GKE harus berada dalam project Google Cloud yang sama.
Prasyarat
Panduan ini mengasumsikan bahwa Anda memiliki hal berikut:
- Project Google Cloud
- Akun Penagihan Cloud
- Alat yang diperlukan untuk menjalankan skrip
install_asm
- Untuk mesh multi-cluster yang menggunakan Istio CA, root certificate yang sama harus ditetapkan pada setiap cluster
Alat yang diperlukan
Selama migrasi, Anda menjalankan skrip yang disediakan Google, migrate_ca
, untuk memvalidasi hal berikut bagi setiap Pod di cluster:
- Root certificate untuk Istio CA dan Mesh CA.
- Sertifikat mTLS workload yang dikeluarkan oleh Istio CA dan oleh Mesh CA.
- Domain kepercayaan yang dikonfigurasi oleh Istio CA dan Mesh CA.
Skrip ini memiliki dependensi berikut:
awk
grep
istioctl
Saat Anda menjalankan skripinstall_asm
, skrip akan mendownload versiistioctl
yang cocok dengan versi Anthos Service Mesh yang Anda instal.jq
kubectl
openssl
Ringkasan migrasi
Untuk bermigrasi ke Mesh CA, ikuti proses migrasi berbasis revisi (juga disebut sebagai "upgrade canary"). Dengan migrasi berbasis revisi, revisi bidang kontrol baru di-deploy bersama bidang kontrol yang ada. Kemudian, Anda secara bertahap memindahkan workload ke revisi baru, yang memungkinkan Anda memantau efek migrasi selama prosesnya. Selama proses migrasi, autentikasi dan otorisasi berfungsi sepenuhnya antara workload yang menggunakan CA Mesh dan workload yang menggunakan Istio CA.
Berikut adalah ringkasan migrasi ke Mesh CA:
Mendistribusikan root kepercayaan CA Mesh.
Instal revisi bidang kontrol baru dengan opsi yang akan mendistribusikan root of trust Mesh CA.
Migrasikan workload ke bidang kontrol baru, namespace berdasarkan namespace, dan uji aplikasi Anda. Setelah semua beban kerja berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.
Bermigrasi ke Mesh CA. Setelah semua proxy file bantuan dikonfigurasi dengan root kepercayaan lama dan root kepercayaan CA Mesh, Anda dapat bermigrasi ke Mesh CA tanpa periode nonaktif. Sekali lagi, Anda mengikuti proses migrasi berbasis revisi:
Instal revisi bidang kontrol dengan Mesh CA diaktifkan.
Migrasikan workload ke revisi bidang kontrol baru, namespace menurut namespace, lalu uji aplikasi Anda. Setelah semua workload berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.
Hapus rahasia CA di cluster yang terkait dengan CA lama dan mulai ulang bidang kontrol baru.
Mendistribusikan root kepercayaan CA Mesh
Sebelum Anda dapat bermigrasi ke Mesh CA, semua cluster GKE di mesh harus memiliki Anthos Service Mesh 1.10 atau yang lebih baru, dan semua cluster harus dikonfigurasi dengan opsi bidang kontrol yang memicu root kepercayaan untuk Mesh CA agar didistribusikan ke proxy semua workload di cluster. Setelah proses selesai, setiap proxy akan dikonfigurasi dengan root kepercayaan lama dan baru. Dengan skema ini, saat Anda bermigrasi ke Mesh CA, beban kerja yang menggunakan Mesh CA akan dapat melakukan autentikasi dengan beban kerja 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 bagian Menginstal Anthos Service Mesh di GKE untuk bersiap menggunakan skrip yang disediakan Google,
install_asm
, untuk menginstal revisi bidang kontrol baru.Pastikan Anda memiliki versi
install_asm
yang menginstal Anthos Service Mesh 1.10 atau yang lebih tinggi:./install_asm --version
Jalankan
install_asm
. Dalam perintah berikut, ganti placeholder dengan nilai Anda.PROJECT_ID
: Wajib diisi. Project ID project tempat cluster dibuat.CLUSTER_NAME
: Wajib diisi. Nama cluster.CLUSTER_LOCATION
: Wajib diisi. Zona atau region tempat cluster berada.REVISION_1
: Direkomendasikan. Label revisi adalah pasangan nilai kunci yang ditetapkan di bidang kontrol. Kunci label revisi selaluistio.io/rev
. Secara default, skrip akan menetapkan nilai untuk label revisi berdasarkan versi Anthos Service Mesh, misalnya:asm-1106-2
. Sebaiknya sertakan opsi ini dan gantiREVISION_1
dengan nama yang menjelaskan penginstalan, sepertiasm-1106-2-distribute-root
. Nama harus berupa label DNS-1035, dan harus terdiri dari karakter alfanumerik huruf kecil atau-
, dimulai dengan karakter alfabet, dan diakhiri dengan karakter alfanumerik (sepertimy-name'
, atauabc-123
). Ekspresi reguler yang digunakan untuk validasi adalah:'[a-z]([-a-z0-9]*[a-z0-9])?')
DIR_PATH
: Wajib diisi. Jalur relatif ke direktori tempat skrip mendownload paketanthos-service-mesh
dan file penginstalan Anthos Service Mesh, yang berisiistioctl
, contoh, dan manifes.OVERLAYS
: Opsional. Jika Anda ingin mengaktifkan fitur opsional, sertakan--custom_overlay
dengan nama file overlay untuk setiap fitur. Jika Anda tidak mengaktifkan fitur opsional, hapus baris ini dan garis miring terbalik di baris sebelumnya../install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca citadel \ --enable_all \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH \ OVERLAYS
Argumen command line berikut diperlukan:
--ca citadel
: Untuk menghindari periode nonaktif, tentukan Istio CA (opsicitadel
sesuai dengan Istio CA). Jangan beralih ke Mesh CA pada tahap ini.--option ca-migration-citadel
: Saat Anda men-deploy ulang beban kerja, opsi ini memicu root kepercayaan baru untuk didistribusikan ke proxy bantuan beban kerja.
Memigrasikan beban kerja ke bidang kontrol baru
Untuk menyelesaikan distribusi root kepercayaan baru, Anda perlu memberi label
namespace dengan label revisi istio.io/rev=asm-1106-2-distribute-root
, lalu memulai ulang
workload Anda. Saat menguji beban kerja setelah memulai ulang beban, Anda menjalankan skrip untuk memvalidasi bahwa proxy sidecar dikonfigurasi dengan root kepercayaan lama dan baru untuk Mesh CA.
Setel konteks saat ini untuk
kubectl
. Dalam perintah berikut, ubah--region
menjadi--zone
jika Anda memiliki cluster zona tunggal.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION
Download skrip validasi:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.10-asm/scripts/ca-migration/migrate_ca > migrate_ca
Tetapkan bit yang dapat dieksekusi pada skrip:
chmod +x migrate_ca
Skrip
migrate_ca
memanggilistioctl
, yang bergantung pada versi. Skripinstall_asm
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 telah didownload skrip.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
Pada output, di kolom
REV
, catat nilai label revisi untuk revisi baru, yang cocok dengan label revisi yang Anda tentukan saat menjalankaninstall_asm
. Dalam contoh ini, nilainya adalahasm-1106-2-distribute-root
.Anda harus menghapus revisi lama
istiod
saat selesai memindahkan beban kerja ke revisi baru. Catat nilai dalam label revisi untuk revisiistiod
lama. Contoh output menunjukkan migrasi dari Istio, yang menggunakan revisidefault
.
Alihkan
istio-ingressgateway
ke revisi baru. Dalam perintah berikut, pastikanREVISION_1
cocok dengan nilai label revisi dari revisi baru.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'
Output yang diharapkan:
service/istio-ingressgateway patched
Tambahkan label revisi ke namespace dan hapus label
istio-injection
(jika ada). Dalam perintah berikut, gantiNAMESPACE
dengan namespace yang akan diberi label.kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
Jika melihat
"istio-injection not found"
pada output, Anda dapat mengabaikannya. Artinya, namespace sebelumnya tidak memiliki labelistio-injection
. Karena injeksi otomatis gagal jika namespace memilikiistio-injection
dan label revisi, semua perintahkubectl label
dalam dokumentasi Anthos Service Mesh mencakup penghapusan labelistio-injection
.Mulai ulang Pod untuk memicu injeksi ulang.
kubectl rollout restart deployment -n NAMESPACE
Pastikan bahwa Pod Anda telah dikonfigurasi untuk mengarah ke versi baru
istiod
.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_1
Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar.
Jika Anda memiliki beban kerja di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan memulai ulang Pod.
Validasi bahwa proxy file bantuan untuk semua beban kerja di cluster dikonfigurasi dengan root certificate 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 puas karena aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan dengan langkah-langkah untuk bertransisi ke versi baru
istiod
. Jika aplikasi Anda mengalami masalah, ikuti langkah-langkah untuk melakukan rollback.Selesaikan transisi
Jika Anda puas karena aplikasi Anda berfungsi seperti yang diharapkan, hapus bidang kontrol lama untuk menyelesaikan transisi ke versi baru.
Ubah ke direktori tempat file dari repositori GitHub
anthos-service-mesh
berada.Konfigurasikan webhook yang memvalidasi untuk menggunakan bidang kontrol baru.
kubectl apply -f asm/istio/istiod-service.yaml
Hapus
istio-ingressgateway
Deployment lama. Perintah yang Anda jalankan bergantung pada apakah Anda bermigrasi dari Istio atau mengupgrade dari Anthos Service Mesh versi sebelumnya:Migrasi
Jika Anda bermigrasi dari Istio,
istio-ingressgateway
lama tidak akan memiliki label revisi.kubectl delete deploy/istio-ingressgateway -n istio-system
Upgrade
Jika Anda melakukan upgrade dari versi Anthos Service Mesh sebelumnya, dalam perintah berikut, ganti
OLD_REVISION
dengan label revisi untukistio-ingressgateway
versi 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 Anthos Service Mesh versi sebelumnya.Migrasi
Jika Anda bermigrasi dari Istio,
istio-ingressgateway
lama tidak akan memiliki label revisi.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Upgrade
Jika Anda melakukan upgrade dari versi Anthos 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 versi lama konfigurasi
IstioOperator
.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 baru
istiod
, ikuti langkah-langkah berikut untuk melakukan rollback ke versi sebelumnya:Beralih kembali ke
istio-ingressgatewqy
versi lama. Dalam perintah berikut, gantiOLD_REVISION
dengan revisi lama.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
Beri label ulang namespace Anda untuk mengaktifkan injeksi otomatis dengan versi
istiod
sebelumnya. Perintah yang digunakan 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
istiod
versi 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-1106-2-distribute-root -n istio-system
Output yang diharapkan mirip dengan berikut ini:
istiooperator.install.istio.io "installed-state-asm-1106-2-distribute-root" deleted
Bermigrasi ke Mesh CA
Setelah proxy file bantuan untuk semua beban kerja dikonfigurasi dengan root kepercayaan lama dan root kepercayaan baru untuk Mesh CA, langkah-langkah untuk bermigrasi ke Mesh CA mirip dengan langkah-langkah yang Anda lakukan untuk mendistribusikan root of trust Mesh CA:
Menginstal bidang kontrol baru dengan Mesh CA diaktifkan
Anda menggunakan install_asm
untuk menginstal revisi bidang kontrol baru yang mengaktifkan Mesh CA.
Jika menyesuaikan penginstalan sebelumnya, Anda perlu menentukan file overlay yang sama saat menjalankan
install_asm
.Jalankan
install_asm
. Dalam perintah berikut, ganti placeholder dengan nilai Anda.PROJECT_ID
: Wajib diisi. Project ID project tempat cluster dibuat.CLUSTER_NAME
: Wajib diisi. Nama cluster.CLUSTER_LOCATION
: Wajib diisi. Zona atau region tempat cluster berada.REVISION_2
: Direkomendasikan. GantiREVISION_2
dengan nama yang menjelaskan penginstalan, sepertiasm-1106-2-meshca-ca-migration
. Nama harus berupa label DNS-1035, dan harus terdiri dari karakter alfanumerik huruf kecil atau-
, dimulai dengan karakter alfabet, dan diakhiri dengan karakter alfanumerik (sepertimy-name'
, atauabc-123
). Ekspresi reguler yang digunakan untuk validasi adalah:'[a-z]([-a-z0-9]*[a-z0-9])?')
DIR_PATH
: Wajib diisi. Jalur relatif ke direktori tempat skrip mendownload paketanthos-service-mesh
dan file penginstalan Anthos Service Mesh, yang berisiistioctl
, contoh, dan manifes.OVERLAYS
: Opsional. Jika Anda ingin mengaktifkan fitur opsional, sertakan--custom_overlay
dengan nama file overlay untuk setiap fitur. Jika Anda tidak mengaktifkan fitur opsional, hapus baris ini dan garis miring terbalik di baris sebelumnya.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca mesh_ca \ --enable_all \ --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
Argumen command line berikut diperlukan:
--ca mesh_ca
: Sekarang Anda dapat beralih ke Mesh CA karena root of trust Mesh CA telah didistribusikan.--option ca-migration-migration
: Saat Anda men-deploy ulang beban kerja, opsi ini akan mengonfigurasi proxy untuk menggunakan root of trust Mesh CA.
Memigrasikan beban kerja ke bidang kontrol baru
Untuk menyelesaikan penginstalan, Anda perlu memberi label 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-1106-2-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1106-2-distribute-root istio-ingressgateway-asm-1106-2-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1106-2-distribute-root istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1106-2-meshca-ca-migration istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1106-2-meshca-ca-migration istiod-asm-1106-2-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1106-2-distribute-root istiod-asm-1106-2-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1106-2-distribute-root istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1106-2-meshca-ca-migration istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1106-2-meshca-ca-migration
Pada output, di kolom
REV
, catat nilai label revisi untuk versi baru. Dalam contoh ini, nilainya adalahasm-1106-2-meshca-ca-migration
.Perhatikan juga nilai dalam label revisi untuk versi
istiod
lama. Anda memerlukan tindakan ini untuk menghapus versi lamaistiod
saat selesai memindahkan beban kerja ke versi baru. Dalam contoh, nilai label revisi untuk revisi sebelumnya adalah `asm-1106-2-distribute-root
.
Alihkan
istio-ingressgateway
ke revisi baru. Dalam perintah berikut, ubahREVISION_2
ke nilai yang cocok dengan label revisi versi baru.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_2"}]'
Output yang diharapkan:
service/istio-ingressgateway patched
Tambahkan label revisi baru ke namespace. Dalam perintah berikut, ganti
NAMESPACE
dengan namespace untuk label.kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
Mulai ulang Pod untuk memicu injeksi ulang.
kubectl rollout restart deployment -n NAMESPACE
Pastikan bahwa Pod Anda telah dikonfigurasi untuk mengarah ke versi baru
istiod
.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_2
Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar. Pastikan komunikasi mTLS berfungsi antara workload di namespace lama dan workload di namespace yang lebih baru.
Jika Anda memiliki beban kerja di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan memulai ulang Pod.
Jika Anda puas karena aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan dengan langkah-langkah untuk bertransisi ke bidang kontrol baru. Jika aplikasi Anda mengalami masalah, ikuti langkah-langkah untuk melakukan rollback.
Selesaikan transisi
Jika Anda puas karena aplikasi Anda berfungsi seperti yang diharapkan, hapus bidang kontrol lama untuk menyelesaikan transisi ke versi baru.
Ubah ke direktori tempat file dari repositori GitHub
anthos-service-mesh
berada.Konfigurasikan webhook yang memvalidasi untuk menggunakan bidang kontrol baru.
kubectl apply -f asm/istio/istiod-service.yaml
Hapus
istio-ingressgateway
Deployment lama. Dalam perintah berikut, gantiOLD_REVISION
dengan label revisi untukistio-ingressgateway
versi sebelumnya.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Hapus revisi
istiod
lama. Dalam perintah berikut, gantiOLD_REVISION
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
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:Beralih kembali ke
istio-ingressgatewqy
sebelumnya. Dalam perintah berikut, gantiOLD_REVISION
dengan revisi lama.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
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
istiod
versi 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 versi baru
istiod
. 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
Hapus rahasia CA dan mulai ulang bidang kontrol yang baru
Simpan secret untuk berjaga-jaga jika diperlukan:
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 rahasia 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. Hal ini akan memastikan root of trust lama dibersihkan dari semua workload yang berjalan di mesh.
kubectl rollout restart deployment -n istio-system