Migrasi berbasis canary ke certificate authority Cloud Service Mesh

Catatan: Panduan ini menjelaskan cara melakukan migrasi dari Istio CA ke certificate authority Cloud Service Mesh dengan pendekatan berbasis canary yang melibatkan minimal atau tanpa periode nonaktif. Untuk memigrasikan CA dengan periode nonaktif minimal dan tanpa memigrasikan bidang kontrol, lihat Migrasi CA Langsung.

Bermigrasi ke certificate authority Cloud Service Mesh (certificate authority Cloud Service Mesh) dari Istio CA (juga dikenal sebagai Citadel) memerlukan migrasi akar kepercayaan. Sebelum Cloud Service Mesh 1.10, jika Anda ingin bermigrasi dari Istio di Google Kubernetes Engine (GKE) ke Cloud Service Mesh dengan certificate authority Cloud Service Mesh, Anda perlu menjadwalkan periode nonaktif karena Cloud Service Mesh tidak dapat memuat beberapa root certificate. Oleh karena itu, selama migrasi, workload yang baru di-deploy memercayai {i>root certificate<i}, sementara yang lain mempercayai {i>root certificate<i} lama. Workload yang menggunakan sertifikat yang ditandatangani oleh root certificate yang berbeda tidak dapat mengautentikasi masing-masing lainnya. Ini berarti bahwa mutual TLS (mTLS) lalu lintas terganggu selama migrasi. Seluruh cluster hanya sepenuhnya memulihkan saat bidang kontrol dan semua workload di semua namespace di-deploy ulang dengan sertifikat certificate authority Cloud Service Mesh. Jika {i>mesh<i} Anda memiliki beberapa klaster dengan 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:

• Bermigrasi dari Istio di GKE ke Cloud Service Mesh 1.19.8-asm.2 bidang kontrol dalam cluster dengan certificate authority Cloud Service Mesh.
• Upgrade dari Cloud Service Mesh 1.15 or a 1.16 patch release dengan Istio CA ke Cloud Service Mesh 1.19.8-asm.2 bidang kontrol dalam cluster dengan certificate authority Cloud Service Mesh.

Batasan

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

Prasyarat

Ikuti langkah-langkah di artikel Menginstal alat dependen dan memvalidasi cluster menjadi:

• Menginstal alat yang diperlukan
• Download asmcli
• Memberikan izin admin cluster
• Memvalidasi project dan cluster

Alat yang diperlukan

Selama migrasi, Anda menjalankan alat yang disediakan Google, migrate_ca, untuk lakukan validasi hal berikut untuk setiap Pod dalam cluster:

• Root certificate untuk Istio CA dan certificate authority Cloud Service Mesh.
• Sertifikat mTLS workload yang dikeluarkan oleh Istio CA dan oleh certificate authority Cloud Service Mesh.
• Domain kepercayaan yang dikonfigurasi oleh Istio CA dan certificate authority Cloud Service Mesh.

Alat ini memiliki dependensi berikut:

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

Ringkasan migrasi

Untuk bermigrasi ke certificate authority Cloud Service Mesh, Anda harus mengikuti proses migrasi berbasis revisi (juga disebut sebagai "upgrade canary"). Dengan migrasi berbasis revisi, bidang kontrol di-deploy bersamaan dengan bidang kontrol yang ada. Anda kemudian secara bertahap memindahkan beban kerja Anda ke revisi yang baru, yang memungkinkan Anda pengaruh migrasi melalui proses tersebut. Selama proses migrasi, autentikasi dan otorisasi berfungsi penuh di antara beban kerja menggunakan workload dan otoritas sertifikat Cloud Service Mesh menggunakan Istio CA.

Berikut adalah garis besar migrasi ke certificate authority Cloud Service Mesh:

1. Mendistribusikan root of trust otoritas sertifikat Cloud Service Mesh.

   1. Instal revisi bidang kontrol baru yang menggunakan Istio CA dengan yang akan mendistribusikan root of trust otoritas sertifikat Cloud Service Mesh.

   2. Migrasikan workload ke bidang kontrol baru, namespace berdasarkan namespace, dan menguji aplikasi Anda. Saat semua workload berhasil dimigrasikan ke bidang kontrol baru, memindahkan bidang kontrol yang lama.

2. Bermigrasi ke certificate authority Cloud Service Mesh. Setelah semua proxy file bantuan dikonfigurasi dengan root of trust lama dan root of trust otoritas sertifikat Cloud Service Mesh, Anda dapat bermigrasi ke certificate authority Cloud Service Mesh tanpa periode nonaktif. Sekali lagi, Anda mengikuti proses migrasi berbasis revisi:

   1. Instal revisi bidang kontrol dengan certificate authority Cloud Service Mesh diaktifkan.

   2. Migrasikan workload ke revisi bidang kontrol baru, namespace dengan namespace, dan menguji aplikasi Anda. Saat semua workload berhasil bermigrasi ke bidang kontrol baru, menghapus bidang kontrol yang lama.

   3. Hapus rahasia CA di cluster yang terkait dengan CA lama dan memulai ulang bidang kontrol baru.

Mendistribusikan root of trust otoritas sertifikat Cloud Service Mesh

Sebelum Anda dapat bermigrasi ke certificate authority Cloud Service Mesh, 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 certificate authority Cloud Service Mesh agar yang didistribusikan ke proxy semua beban kerja di cluster. Jika selesai, setiap {i>proxy<i} dikonfigurasi dengan proxy lama dan akar kepercayaan yang baru. Dengan skema ini, saat Anda bermigrasi ke certificate authority Cloud Service Mesh, yang menggunakan certificate authority Cloud Service Mesh, akan dapat melakukan autentikasi dengan workload menggunakan CA lama.

Menginstal revisi bidang kontrol baru

Instal revisi bidang kontrol dengan opsi yang mendistribusikan certificate authority Cloud Service Mesh akar kepercayaan.

1. Ikuti langkah-langkah di artikel Menginstal alat dependen dan memvalidasi cluster untuk bersiap menggunakan alat yang disediakan Google, asmcli, untuk menginstal revisi bidang kontrol.

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

   ./asmcli --version
   

3. Jalankan asmcli install. Pada perintah berikut, ganti placeholder dengan nilai-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. Lingkungan variabel $PWD tidak berfungsi di sini.
• --output_dir Sertakan opsi ini untuk menentukan direktori tempat asmcli mendownload anthos-service-mesh mengemas dan mengekstrak file instalasi, yang berisi, istioctl, sampel, dan manifes. Sebaliknya asmcli akan mendownload file ke direktori tmp. Anda dapat menentukan jalur relatif atau jalur lengkap. Lingkungan variabel $PWD tidak berfungsi di sini.
• --enable_all Mengizinkan alat untuk:
  • Memberikan izin IAM yang diperlukan.
  • Aktifkan Google API yang diperlukan.
  • Berikan label pada cluster yang mengidentifikasi mesh.
  • Daftarkan cluster ke fleet jika belum terdaftar.
• -ca citadel Untuk menghindari periode nonaktif, tentukan Istio CA (`citadel` sesuai dengan Istio CA). Jangan beralih ke certificate authority Cloud Service Mesh untuk saat ini.
• --ca_cert Intermediate certificate.
• --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 akar kepercayaan baru untuk didistribusikan ke proxy file bantuan workload.
• REVISION_1: Direkomendasikan. J [label revisi](/service-mesh/docs/revisions-overview) adalah pasangan nilai kunci yang ditetapkan di 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-1198-2. Sebaiknya Anda menyertakan dan mengganti REVISION_1 dengan nama yang menjelaskan penginstalan, seperti asm-1198-2-distribute-root. Nama harus berupa label DNS-1035, dan harus terdiri dari huruf kecil karakter alfanumerik atau -, diawali dengan huruf alfabet dan diakhiri dengan karakter alfanumerik (seperti my-name atau abc-123).

Memigrasikan workload ke bidang kontrol baru

Untuk menyelesaikan pendistribusian root kepercayaan baru, Anda perlu memberi label namespace dengan label revisi istio.io/rev=<var>REVISION_1</var>-distribute-root dan mulai ulang sebagian besar workload standar dan berbasis cloud. Saat menguji beban kerja setelah memulai ulang, Anda menjalankan alat untuk memvalidasi bahwa proxy file bantuan dikonfigurasi dengan root lama dan baru untuk certificate authority Cloud Service Mesh.

1. Tetapkan konteks saat ini untuk kubectl. Pada perintah berikut, ubah --region hingga --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. Tetapkan bit yang dapat dieksekusi pada alat:

   chmod +x migrate_ca
   

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

   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. Di output, di bawah kolom REV, perhatikan nilai revisi label untuk revisi baru, yang sesuai dengan label revisi yang Anda yang ditentukan saat Anda menjalankan asmcli install. Dalam contoh ini, nilainya adalah asm-1198-2-distribute-root.

   2. Anda perlu menghapus revisi lama istiod saat selesai memindahkan workload ke revisi yang baru. Perhatikan nilai dalam label revisi untuk revisi istiod lama. Contoh {i>output<i} menunjukkan migrasi dari Istio, yang menggunakan revisi default.

6. Tambahkan label revisi ke namespace dan hapus istio-injection label (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 melihat "istio-injection not found" di output, Anda dapat mengabaikannya. Itu berarti bahwa namespace sebelumnya tidak memiliki Label istio-injection. Karena perilaku injeksi otomatis tidak ditentukan jika namespace memiliki istio-injection dan label revisi, semua perintah kubectl label di Mesh Layanan Cloud dokumentasi secara eksplisit memastikan bahwa hanya satu yang ditetapkan.

7. Mulai ulang Pod untuk memicu injeksi ulang.

   kubectl rollout restart deployment -n NAMESPACE
   

8. Uji aplikasi Anda untuk memastikan beban kerja berfungsi dengan benar.

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

10. Validasi bahwa proxy file bantuan untuk semua workload di cluster 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]

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 metode tersebut penginstalan lama untuk melakukan migrasi tanpa periode nonaktif. Pastikan bahwa resource layanan yang mengarah ke gateway lama harus menyertakan deployment sekarang juga.
    • Jangan hapus deployment gateway lama sampai Anda yakin aplikasi berfungsi dengan baik (setelah langkah berikutnya).

12. Jika sudah puas karena aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan dengan langkah-langkah untuk bertransisi ke versi baru istiod. Jika ada terkait aplikasi Anda, ikuti langkah-langkah untuk melakukan rollback.

    Selesaikan transisi

    Jika Anda puas aplikasi Anda bekerja seperti yang diharapkan, hapus bidang kontrol lama untuk menyelesaikan transisi ke versi baru.

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

    2. Konfigurasi webhook yang memvalidasi untuk menggunakan bidang kontrol baru.

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

    3. Hapus istio-ingressgatewayDeployment lama. Perintah yang Anda berjalan 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 melakukan upgrade dari versi Cloud Service Mesh sebelumnya, dalam perintah berikut, ganti OLD_REVISION dengan label revisi untuk versi sebelumnya istio-ingressgateway.

       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 digunakan bergantung pada mengenai apakah Anda bermigrasi dari Istio atau mengupgrade dari dari Cloud Service Mesh.

       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 melakukan upgrade dari versi Cloud Service Mesh sebelumnya, dalam perintah berikut, pastikan bahwa OLD_REVISION cocok dengan label revisi untuk istiod versi sebelumnya.

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

    5. Hapus konfigurasi IstioOperator versi sebelumnya.

       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, ikuti langkah-langkah ini untuk melakukan rollback ke versi sebelumnya versi:

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

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

       • 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

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

       kubectl get ns NAMESPACE --show-labels
       

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

       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 dari 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-1198-2-distribute-root -n istio-system
       

       Output yang diharapkan mirip dengan berikut ini:

       istiooperator.install.istio.io "installed-state-asm-1198-2-distribute-root" deleted

Bermigrasi ke certificate authority Cloud Service Mesh

Karena proxy file bantuan untuk semua beban kerja sekarang dikonfigurasi dengan root of trust dan root of trust baru untuk certificate authority Cloud Service Mesh, langkah-langkah untuk yang dimigrasikan ke certificate authority Cloud Service Mesh mirip dengan yang Anda lakukan untuk mendistribusikan root of trust otoritas sertifikat Cloud Service Mesh:

Instal bidang kontrol baru dengan certificate authority Cloud Service Mesh diaktifkan

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

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

2. Jalankan asmcli install. Pada perintah berikut, ganti placeholder dengan nilai-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. Lingkungan variabel $PWD tidak berfungsi di sini.
   • --output_dir Sertakan opsi ini untuk menentukan direktori tempat asmcli mendownload anthos-service-mesh mengemas dan mengekstrak file instalasi, yang berisi istioctl, sampel, dan manifes. Sebaliknya asmcli akan mendownload file ke direktori tmp. Anda dapat menentukan jalur relatif atau jalur lengkap. Lingkungan variabel $PWD tidak berfungsi di sini.
   • --enable_all Mengizinkan alat untuk:
     • Memberikan izin IAM yang diperlukan.
     • Aktifkan Google API yang diperlukan.
     • Berikan label pada cluster yang mengidentifikasi mesh.
     • Daftarkan cluster ke fleet jika belum terdaftar.
   • --ca mesh_ca Anda kini dapat beralih ke certificate authority Cloud Service Mesh sebagai certificate authority Cloud Service Mesh {i>root of trust <i}telah didistribusikan.
   • REVISION_2 Direkomendasikan. Ganti REVISION_2 dengan nama yang mendeskripsikan penginstalan, seperti asm-1198-2-meshca-ca-migration. Nama harus berupa label DNS-1035, dan harus terdiri dari huruf kecil karakter alfanumerik atau -, diawali dengan huruf alfabet dan diakhiri dengan karakter alfanumerik (seperti my-name atau abc-123).
   • --option ca-migration-migration Saat Anda [men-deploy ulang workload](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), opsi ini mengonfigurasi proxy agar menggunakan root of trust otoritas sertifikat Cloud Service Mesh.

Memigrasikan workload ke bidang kontrol baru

Untuk menyelesaikan instalasi, Anda perlu memberi label namespace dengan label revisi dan memulai ulang beban kerja Anda.

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

   1. Di output, di bawah kolom REV, perhatikan nilai revisi label untuk versi baru. Dalam contoh ini, nilainya adalah asm-1198-2-meshca-ca-migration.

   2. Perhatikan juga nilai dalam label revisi untuk versi istiod sebelumnya. Anda memerlukan tindakan ini untuk menghapus versi istiod sebelumnya saat Anda selesai memindahkan beban kerja ke versi baru. Dalam contoh, nilai label revisi untuk revisi sebelumnya adalah asm-1198-2-distribute-root.

2. Tambahkan label revisi baru ke namespace Dalam perintah berikut, ganti NAMESPACE dengan namespace untuk diberi label.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
   

3. Mulai ulang Pod untuk memicu injeksi ulang.

   kubectl rollout restart deployment -n NAMESPACE
   

4. Uji aplikasi Anda untuk memastikan beban kerja berfungsi dengan benar. Memastikan komunikasi mTLS berfungsi antar-beban kerja di grup yang lebih lama dan workload di namespace yang lebih baru.

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

6. Ikuti langkah-langkah yang dijelaskan di Upgrade di tempat untuk mengupgrade deployment gateway lama yang diinstal di langkah 11 bagian sebelumnya ke revisi terakhir REVISION_2.

7. Jika sudah puas karena aplikasi Anda berfungsi seperti yang diharapkan, lanjutkan langkah-langkah untuk beralih ke bidang kontrol baru. Jika ada terkait aplikasi Anda, ikuti langkah-langkah untuk melakukan rollback.

   Selesaikan transisi

   Jika Anda puas aplikasi Anda bekerja seperti yang diharapkan, hapus bidang kontrol lama untuk menyelesaikan transisi ke versi baru.

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

   2. Konfigurasi webhook yang memvalidasi untuk menggunakan bidang kontrol baru.

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

   3. Hapus istio-ingressgatewayDeployment lama. Dalam , ganti OLD_REVISION dengan revisi label untuk istio-ingressgateway versi 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 istiod versi 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, ikuti langkah-langkah ini untuk melakukan rollback ke versi sebelumnya revisi:

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

   2. Beri label ulang namespace untuk mengaktifkan injeksi otomatis dengan Revisi istiod.

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
      

      Output yang diharapkan:

      namespace/NAMESPACE labeled

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

      kubectl get ns NAMESPACE --show-labels
      

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

      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 bahwa label revisi dalam perintah berikut ini cocok dengan revisi Anda.

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

   7. 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 rahasia CA dan memulai ulang bidang kontrol baru

1. Simpan secret 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. Ini memastikan bahwa akar lama dari akan dibersihkan dari semua beban kerja yang berjalan di mesh.

   kubectl rollout restart deployment -n istio-system