Migrasi berbasis Canary ke Mesh CA

<0x0 Untuk memigrasikan CA Anda dengan waktu non-operasional minimal dan tanpa memigrasikan control plane, lihat Migrasi CA di Tempat.

Bermigrasi ke certificate authority (CA) Cloud Service Mesh dari Istio CA (juga dikenal sebagai Citadel) memerlukan migrasi root of trust. Sebelum Cloud Service Mesh 1.10, jika Anda ingin bermigrasi dari Istio di Google Kubernetes Engine (GKE) ke Cloud Service Mesh dengan Mesh CA, Anda perlu menjadwalkan periode nonaktif karena Cloud Service Mesh tidak dapat memuat beberapa sertifikat root. Oleh karena itu, selama migrasi, workload yang baru di-deploy mempercayai root certificate baru, sementara workload lainnya mempercayai root certificate lama. Workload yang menggunakan sertifikat yang ditandatangani oleh sertifikat root yang berbeda tidak dapat saling mengautentikasi. Artinya, traffic mutual TLS (mTLS) terganggu selama migrasi. Seluruh cluster hanya dapat dipulihkan sepenuhnya 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 perlu diperbarui.

Gunakan langkah-langkah dalam panduan ini untuk kasus penggunaan berikut:

• Lakukan migrasi dari Istio di GKE ke bidang kontrol dalam cluster Cloud Service Mesh dengan Mesh CA. 1.29.4-asm.0
• Lakukan upgrade dari Cloud Service Mesh 1.15 atau rilis patch 1.16 dengan Istio CA ke bidang kontrol dalam cluster Cloud Service Mesh 1.29.4-asm.0 dengan Mesh CA.

Batasan

• Semua cluster GKE harus berada dalam project yang sama Google Cloud .

Prasyarat

Ikuti langkah-langkah di 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 Istio CA dan Mesh CA.
• Sertifikat mTLS beban kerja yang dikeluarkan oleh Istio CA dan Mesh CA.
• Domain tepercaya yang dikonfigurasi oleh Istio CA dan Mesh CA.

Alat ini memiliki dependensi berikut:

• awk
• grep
• istioctl Menjalankan asmcli install akan mendownload versi istioctl yang cocok dengan versi Cloud Service Mesh yang Anda instal.
• jq
• kubectl
• openssl

Ringkasan migrasi

Untuk bermigrasi ke Mesh CA, Anda mengikuti proses migrasi berbasis revisi (juga disebut sebagai "upgrade canary"). Dengan migrasi berbasis revisi, revisi bidang kontrol baru di-deploy bersama dengan bidang kontrol yang ada. Kemudian, Anda memindahkan workload secara bertahap ke revisi baru, yang memungkinkan Anda memantau efek migrasi selama proses berlangsung. Selama proses migrasi, autentikasi dan otorisasi berfungsi penuh antara beban kerja yang menggunakan Mesh CA dan beban kerja yang menggunakan Istio CA.

Berikut adalah ringkasan migrasi ke Mesh CA:

1. Mendistribusikan root of trust CA Mesh.

   1. Instal revisi bidang kontrol baru yang menggunakan Istio CA dengan opsi yang akan mendistribusikan root of trust CA Mesh.

   2. Migrasikan workload ke control plane baru, namespace demi namespace, dan uji aplikasi Anda. Setelah semua workload berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.

2. Bermigrasi ke CA Mesh. Setelah semua proxy sidecar dikonfigurasi dengan root of trust lama dan root of trust CA Mesh, Anda dapat bermigrasi ke CA Mesh tanpa waktu non-operasional. Sekali lagi, Anda mengikuti proses migrasi berbasis revisi:

   1. Instal revisi bidang kontrol dengan CA Mesh diaktifkan.

   2. Migrasikan workload ke revisi bidang kontrol baru, namespace demi namespace, dan uji aplikasi Anda. Setelah semua workload berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.

   3. Hapus secret CA di cluster yang terkait dengan CA lama dan mulai ulang control plane baru.

Mendistribusikan root of trust CA Mesh

Sebelum Anda dapat bermigrasi ke Mesh CA, semua cluster GKE di 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 untuk Mesh CA agar didistribusikan ke proxy semua workload di cluster. Setelah proses selesai, setiap proxy dikonfigurasi dengan root of trust 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 kepercayaan CA Mesh.

1. Ikuti langkah-langkah di Menginstal alat dependen dan memvalidasi cluster untuk bersiap menggunakan alat yang disediakan Google, asmcli, guna menginstal revisi control plane baru.

2. Pastikan Anda memiliki versi asmcli yang menginstal Cloud Service Mesh 1.11 atau yang lebih tinggi:

   ./asmcli --version
   

3. 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 project host fleet.
• --kubeconfig Jalur ke file kubeconfig Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan $PWD tidak berfungsi di sini.
• --output_dir Sertakan opsi ini untuk menentukan direktori tempat asmcli mendownload paket anthos-service-mesh dan mengekstrak file penginstalan, yang berisi istioctl, sampel, dan manifes. Jika tidak, asmcli akan mendownload file ke direktori tmp. Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan $PWD tidak berfungsi di sini.
• --enable_all Mengizinkan 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 (opsi citadel sesuai dengan CA Istio). Jangan beralih ke CA Mesh pada tahap ini.
• --ca_cert Sertifikat perantara.
• --ca_key Kunci untuk sertifikat perantara
• --root_cert Root certificate.
• --cert_chain Rantai sertifikat.
• --option ca-migration-citadel Saat Anda men-deploy ulang workload, opsi ini akan memicu distribusi root of trust baru ke proxy sidecar workload.
• REVISION_1: Direkomendasikan. Label revisi adalah pasangan nilai kunci yang ditetapkan pada bidang kontrol. Kunci label revisi selalu istio.io/rev. Secara default, alat ini menetapkan nilai untuk label revisi berdasarkan versi Cloud Service Mesh, misalnya: asm-1294-0. Sebaiknya sertakan opsi ini dan ganti REVISION_1 dengan nama yang mendeskripsikan penginstalan, seperti asm-1294-0-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 (seperti my-name atau abc-123).

Memigrasikan workload ke bidang kontrol baru

Untuk menyelesaikan pendistribusian root of trust baru, Anda harus memberi label pada namespace dengan label revisi istio.io/rev=<var>REVISION_1</var>-distribute-root dan memulai ulang beban kerja. Saat menguji workload setelah memulai ulang, Anda menjalankan alat untuk memvalidasi bahwa proxy sidecar dikonfigurasi dengan root tepercaya lama dan baru untuk Mesh CA.

1. Menetapkan 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
   

2. Download alat validasi:

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
   

3. Setel bit yang dapat dieksekusi pada alat:

   chmod +x migrate_ca
   

4. Alat migrate_ca memanggil istioctl, yang bergantung pada versi. Alat asmcli menambahkan symlink ke istioctl di direktori yang Anda tentukan untuk --output_dir. Pastikan direktori tersebut berada di awal jalur Anda. Dalam perintah berikut, ganti ISTIOCTL_PATH dengan direktori yang berisi istioctl yang didownload alat.

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. Dapatkan label revisi yang ada di istiod dan istio-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

   1. Dalam output, di kolom REV, perhatikan nilai label revisi untuk revisi baru, yang cocok dengan label revisi yang Anda tentukan saat menjalankan asmcli install. Dalam contoh ini, nilainya adalah asm-1294-0-distribute-root.

   2. Anda harus menghapus revisi lama istiod setelah selesai memindahkan beban kerja ke revisi baru. Perhatikan nilai dalam label revisi untuk revisi istiod lama. Output contoh menunjukkan migrasi dari Istio, yang menggunakan revisi default.

6. Tambahkan label revisi ke namespace dan hapus label istio-injection (jika ada). Pada perintah berikut, ganti NAMESPACE 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" di output, Anda dapat mengabaikannya. Artinya, namespace sebelumnya tidak memiliki label istio-injection. Karena perilaku injeksi otomatis tidak ditentukan saat namespace memiliki label istio-injection dan revisi, semua perintah kubectl label dalam dokumentasi Cloud Service Mesh secara eksplisit memastikan bahwa hanya satu yang ditetapkan.

7. Mulai ulang Pod untuk memicu penyuntikan ulang.

   kubectl rollout restart deployment -n NAMESPACE
   

8. Uji aplikasi Anda untuk memverifikasi bahwa workload berfungsi dengan benar.

9. Jika Anda memiliki workload di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan memulai ulang Pod.

10. 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]

11. 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 yang lebih lama untuk melakukan migrasi tanpa waktu henti. Pastikan resource layanan yang mengarah ke gateway lama juga menyertakan deployment yang lebih baru.
    • Jangan hapus deployment gateway yang lebih lama hingga Anda yakin bahwa aplikasi Anda berfungsi dengan benar (setelah langkah berikutnya).

12. Jika Anda yakin bahwa aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan dengan langkah-langkah untuk bertransisi ke versi baru istiod. Jika ada masalah dengan aplikasi Anda, ikuti langkah-langkah untuk melakukan rollback.

    Menyelesaikan transisi

    Jika Anda yakin bahwa aplikasi Anda berfungsi seperti yang diharapkan, hapus control plane lama untuk menyelesaikan transisi ke versi baru.

    1. Ubah ke direktori tempat file dari repositori GitHub anthos-service-mesh berada.

    2. Konfigurasi webhook validasi untuk menggunakan bidang kontrol baru.

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. Hapus istio-ingressgatewayDeployment lama. Perintah yang Anda jalankan bergantung pada apakah Anda melakukan migrasi 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 deploy/istio-ingressgateway -n istio-system
       

       Upgrade

       Jika Anda melakukan upgrade dari versi Cloud Service Mesh sebelumnya, pada perintah berikut, ganti OLD_REVISION dengan label revisi untuk versi istio-ingressgateway sebelumnya.

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
       

    4. Hapus revisi lama istiod. Perintah yang Anda gunakan bergantung pada apakah Anda melakukan migrasi 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, pada perintah berikut, pastikan OLD_REVISION cocok dengan label revisi untuk versi istiod sebelumnya.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
       

    5. 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:

    1. Hapus deployment gateway baru yang diinstal sebagai bagian dari langkah 11.

    2. Beri label ulang namespace Anda untuk mengaktifkan injeksi otomatis dengan istiod versi sebelumnya. Perintah yang Anda gunakan bergantung pada apakah Anda menggunakan label revisi atau istio-injection=enabled dengan versi sebelumnya.

       • Jika Anda menggunakan label revisi untuk penyisipan 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

    3. Pastikan label revisi pada namespace cocok dengan label revisi pada versi istiod sebelumnya:

       kubectl get ns NAMESPACE --show-labels
       

    4. Mulai ulang Pod untuk memicu penyuntikan ulang sehingga proxy memiliki versi sebelumnya:

       kubectl rollout restart deployment -n NAMESPACE
       

    5. Hapus Deployment istio-ingressgateway baru.

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
       

    6. Hapus revisi baru istiod.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
       

    7. Hapus konfigurasi IstioOperator baru.

       kubectl delete IstioOperator installed-state-asm-1294-0-distribute-root -n istio-system
       

       Output yang diharapkan mirip dengan berikut ini:

       istiooperator.install.istio.io "installed-state-asm-1294-0-distribute-root" deleted

Bermigrasi ke CA Mesh

Setelah proxy sidecar untuk semua workload dikonfigurasi dengan root of trust lama dan root of trust baru untuk Mesh CA, langkah-langkah untuk bermigrasi ke Mesh CA serupa dengan langkah-langkah yang Anda lakukan untuk mendistribusikan root of trust Mesh CA:

Menginstal bidang kontrol baru dengan CA Mesh yang diaktifkan

Anda menggunakan asmcli install untuk menginstal revisi bidang kontrol baru yang mengaktifkan Mesh CA.

1. Jika Anda menyesuaikan penginstalan sebelumnya, Anda harus menentukan file overlay yang sama saat menjalankan asmcli install.

2. 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 project host fleet.
   • --kubeconfig Jalur ke file kubeconfig Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan $PWD tidak berfungsi di sini.
   • --output_dir Sertakan opsi ini untuk menentukan direktori tempat asmcli mendownload paket anthos-service-mesh dan mengekstrak file penginstalan, yang berisi istioctl, sampel, dan manifes. Jika tidak, asmcli akan mendownload file ke direktori tmp. Anda dapat menentukan jalur relatif atau jalur lengkap. Variabel lingkungan $PWD tidak berfungsi di sini.
   • --enable_all Mengizinkan 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 mesh_ca Anda kini dapat beralih ke CA Mesh karena root tepercaya CA Mesh telah didistribusikan.
   • REVISION_2 Direkomendasikan. Ganti REVISION_2 dengan nama yang menjelaskan penginstalan, seperti asm-1294-0-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 (seperti my-name atau abc-123).
   • --option ca-migration-migration Saat Anda men-deploy ulang beban kerja, opsi ini mengonfigurasi proxy untuk menggunakan root of trust CA Mesh.

Memigrasikan workload ke bidang kontrol baru

Untuk menyelesaikan penginstalan, Anda harus memberi label pada namespace dengan label revisi baru dan memulai ulang workload.

1. Dapatkan label revisi yang ada di istiod dan istio-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-1294-0-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1294-0-distribute-root
   istio-ingressgateway-asm-1294-0-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1294-0-distribute-root
   istio-ingressgateway-asm-1294-0-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1294-0-meshca-ca-migration
   istio-ingressgateway-asm-1294-0-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1294-0-meshca-ca-migration
   istiod-asm-1294-0-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1294-0-distribute-root
   istiod-asm-1294-0-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1294-0-distribute-root
   istiod-asm-1294-0-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1294-0-meshca-ca-migration
   istiod-asm-1294-0-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1294-0-meshca-ca-migration

   1. Dalam output, di kolom REV, catat nilai label revisi untuk versi baru. Dalam contoh ini, nilainya adalah asm-1294-0-meshca-ca-migration.

   2. Perhatikan juga nilai dalam label revisi untuk versi istiod lama. Anda memerlukan hal ini untuk menghapus istiod versi lama saat Anda selesai memindahkan workload ke versi baru. Dalam contoh, nilai label revisi untuk revisi sebelumnya adalah asm-1294-0-distribute-root.

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

3. Mulai ulang Pod untuk memicu penyuntikan ulang.

   kubectl rollout restart deployment -n NAMESPACE
   

4. Uji aplikasi Anda untuk memverifikasi bahwa workload berfungsi dengan benar. Pastikan komunikasi mTLS berfungsi antara workload di namespace yang lebih lama dan workload di namespace yang lebih baru.

5. Jika Anda memiliki workload di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan memulai ulang Pod.

6. Ikuti langkah-langkah yang diuraikan dalam Upgrade di tempat untuk mengupgrade deployment gateway lama yang diinstal pada langkah 11 di bagian sebelumnya ke revisi terbaru REVISION_2.

7. Jika Anda yakin bahwa aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan langkah-langkah untuk bertransisi ke bidang kontrol baru. Jika ada masalah dengan aplikasi Anda, ikuti langkah-langkah untuk melakukan rollback.

   Menyelesaikan transisi

   Jika Anda yakin bahwa aplikasi Anda berfungsi seperti yang diharapkan, hapus control plane lama untuk menyelesaikan transisi ke versi baru.

   1. Ubah ke direktori tempat file dari repositori GitHub anthos-service-mesh berada.

   2. Konfigurasi webhook validasi untuk menggunakan bidang kontrol baru.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Hapus istio-ingressgatewayDeployment lama. Dalam perintah berikut, ganti OLD_REVISION dengan label revisi untuk versi istio-ingressgateway sebelumnya.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. Hapus revisi istiod lama. Pada perintah berikut, ganti OLD_REVISION dengan label revisi untuk versi istiod sebelumnya.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. 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:

   1. Ikuti langkah-langkah di Upgrade di tempat untuk melakukan downgrade pada deployment gateway yang sebelumnya diupgrade di langkah 6 bagian ini ke revisi lama REVISION_1.

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

   3. Pastikan label revisi pada namespace cocok dengan label revisi pada versi istiod sebelumnya:

      kubectl get ns NAMESPACE --show-labels
      

   4. Mulai ulang Pod untuk memicu penyuntikan ulang sehingga proxy memiliki versi sebelumnya:

      kubectl rollout restart deployment -n NAMESPACE
      

   5. Hapus Deployment istio-ingressgateway baru.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
      

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

   7. Hapus konfigurasi IstioOperator versi baru.

      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 secret CA dan mulai ulang bidang kontrol baru

1. Simpan rahasia untuk berjaga-jaga jika Anda membutuhkannya:

   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
   

2. Hapus rahasia CA di cluster yang terkait dengan CA lama:

   kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
   

3. Mulai ulang bidang kontrol yang baru diinstal. Hal ini memastikan bahwa root kepercayaan lama dihapus dari semua beban kerja yang berjalan di mesh.

   kubectl rollout restart deployment -n istio-system