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:

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

  1. Mendistribusikan root of trust CA Mesh.

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

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

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

    1. Instal revisi bidang kontrol dengan Mesh CA diaktifkan.

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

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

  1. Ikuti langkah-langkah di Menginstal alat dependen dan memvalidasi cluster untuk bersiap menggunakan alat yang disediakan Google, asmcli, guna menginstal revisi panel kontrol 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 dari 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 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 (opsi citadel 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 selalu istio.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 ganti REVISION_1 dengan nama yang menjelaskan penginstalan, seperti asm-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 (seperti my-name atau abc-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.

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

  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. 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-1187-26-distribute-root.

    2. Anda harus menghapus revisi istiod lama setelah selesai memindahkan beban kerja ke revisi baru. Perhatikan nilai dalam label revisi untuk revisi istiod lama. Contoh output 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" dalam 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 injeksi 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 mulai 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 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).

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

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

    2. Konfigurasikan webhook validasi untuk menggunakan bidang kontrol baru.

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

    3. 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 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 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 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 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 versi istiod 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 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 label revisi pada versi istiod sebelumnya:

      kubectl get ns NAMESPACE --show-labels

    4. Mulai ulang Pod untuk memicu injeksi 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-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.

  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 dari 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 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. Ganti REVISION_2 dengan nama yang mendeskripsikan penginstalan, seperti asm-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 (seperti my-name atau abc-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.

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

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

    2. Perhatikan juga nilai di label revisi untuk versi istiod lama. Anda memerlukannya untuk menghapus istiod versi lama setelah selesai memindah workload ke versi baru. Dalam contoh, nilai label revisi untuk revisi sebelumnya adalah asm-1187-26-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 injeksi ulang.

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

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

    2. Konfigurasikan webhook validasi untuk menggunakan bidang kontrol baru.

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

    3. Hapus Deployment istio-ingressgateway 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 langsung untuk mendowngrade 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 injeksi 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 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

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

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

  2. Hapus secret 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. Tindakan ini memastikan root kepercayaan lama dihapus dari semua beban kerja yang berjalan di mesh.

    kubectl rollout restart deployment -n istio-system