Mengupgrade Anthos Service Mesh di GKE dalam mesh multi-project

Panduan ini menjelaskan cara melakukan upgrade dari 1.9 or a 1.10 patch release ke Anthos Service Mesh 1.11.8 di cluster Google Kubernetes Engine (GKE) untuk mesh yang berisi beberapa cluster yang berada di project Google Cloud yang berbeda.

Sebelum memulai

Sebelum menginstal Anthos Service Mesh, pastikan Anda memiliki:

• Siapkan lingkungan Anda untuk menginstal alat yang Anda perlukan.

Mempersiapkan upgrade

Jika penginstalan sebelumnya disesuaikan, Anda memerlukan penyesuaian yang sama saat mengupgrade ke versi Anthos Service Mesh baru atau bermigrasi dari Istio. Jika menyesuaikan penginstalan dengan menambahkan flag --set values ke istioctl install, Anda harus menambahkan setelan tersebut ke file YAML IstioOperator, yang disebut sebagai file overlay. Tentukan file overlay menggunakan opsi --custom_overlay dengan nama file saat menjalankan skrip. Skrip meneruskan file overlay ke istioctl install.

Skrip ini mengikuti proses upgrade revisi (disebut sebagai upgrade "canary" dalam dokumentasi Istio). Dengan upgrade berbasis revisi, skrip menginstal revisi baru bidang kontrol bersama bidang kontrol yang ada. Saat menginstal versi baru, skrip menyertakan label revision yang mengidentifikasi bidang kontrol baru.

Kemudian, migrasi ke versi baru dengan menetapkan label revision yang sama pada beban kerja dan melakukan mulai ulang berkelanjutan untuk memasukkan ulang proxy agar menggunakan versi dan konfigurasi Anthos Service Mesh yang baru. Dengan pendekatan ini, Anda dapat memantau efek upgrade pada sebagian kecil beban kerja Anda. Setelah menguji aplikasi, Anda dapat memigrasikan semua traffic ke versi baru. Pendekatan ini jauh lebih aman daripada melakukan upgrade langsung di mana komponen bidang kontrol baru menggantikan versi sebelumnya.

Menyiapkan variabel lingkungan

1. Dapatkan project ID untuk project tempat cluster dibuat dan nomor project untuk project host environ.

   gcloud

   Jalankan perintah berikut:

   gcloud projects list
   

   Konsol

   1. Buka halaman Dashboard di Konsol Google Cloud.

      Buka halaman Dasbor

   2. Klik menu drop-down Select from di bagian atas halaman. Di jendela Select from yang muncul, pilih project Anda.

      Project ID ditampilkan di kartu Project info Dasbor project.

2. Buat variabel lingkungan untuk project ID project tempat cluster dibuat:

   export PROJECT_ID=YOUR_PROJECT_ID

3. Buat variabel lingkungan untuk nomor project project host lingkungan.

   export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER

4. Buat variabel lingkungan berikut:

   • Tetapkan nama cluster:

     export CLUSTER_NAME=YOUR_CLUSTER_NAME

   • Tetapkan CLUSTER_LOCATION ke zona cluster atau region cluster Anda:

     export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

5. Tetapkan zona atau region default untuk Google Cloud CLI. Jika Anda tidak menetapkan opsi default di sini, pastikan untuk menentukan opsi --zone atau --region dalam perintah gcloud container clusters pada halaman ini.

   • Jika Anda memiliki cluster zona tunggal, tetapkan zona default:

     gcloud config set compute/zone ${CLUSTER_LOCATION}

   • Jika Anda memiliki cluster regional, tetapkan region default:

     gcloud config set compute/region ${CLUSTER_LOCATION}

   Tips: Agar penyiapan lingkungan shell Anda di masa mendatang lebih mudah, Anda dapat menyalin dan menempelkan pernyataan export untuk setiap variabel lingkungan ke skrip shell sederhana yang Anda source saat memulai shell baru. Anda juga dapat menambahkan perintah gcloud yang menetapkan nilai default ke skrip. Atau, Anda dapat menggunakan gcloud init untuk membuat dan mengaktifkan konfigurasi gcloud yang telah diberi nama.

Menetapkan kredensial dan izin

1. Dapatkan kredensial autentikasi untuk berinteraksi dengan cluster. Perintah ini juga menetapkan konteks saat ini untuk kubectl ke cluster.

   gcloud container clusters get-credentials ${CLUSTER_NAME} \
       --project=${PROJECT_ID}
   

2. Berikan izin admin cluster kepada pengguna saat ini. Anda memerlukan izin ini guna membuat aturan role-based access control (RBAC) yang diperlukan untuk Anthos Service Mesh.

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

Jika melihat error "cluster-admin-binding" already exists, Anda dapat mengabaikannya dengan aman dan melanjutkan dengan cluster-admin-binding yang ada.

Mendownload file penginstalan

Mempersiapkan file konfigurasi resource

Saat menjalankan perintah istioctl install, Anda menentukan -f istio-operator.yaml pada command line. File ini berisi informasi tentang project dan cluster yang diperlukan Anthos Service Mesh. Anda harus mendownload paket yang berisi istio-operator.yaml dan file konfigurasi resource lainnya agar dapat menetapkan informasi project dan cluster.

Untuk menyiapkan file konfigurasi resource:

Mengupgrade Anthos Service Mesh

Men-deploy dan men-deploy ulang workload

Penginstalan belum selesai sampai Anda mengaktifkan injeksi proxy sidecar otomatis (injeksi otomatis). Migrasi dari Istio dan upgrade OSS mengikuti proses upgrade berbasis revisi (disebut sebagai "upgrade canary" dalam dokumentasi Istio). Dengan upgrade berbasis revisi, versi baru bidang kontrol diinstal bersama bidang kontrol yang ada. Kemudian, Anda memindahkan beberapa beban kerja ke versi baru agar Anda dapat memantau efek upgrade dengan sebagian kecil beban kerja, sebelum memigrasikan semua traffic ke versi baru.

Saat menjalankan istioctl install, Anda menetapkan label revisi dalam format istio.io/rev=asm-1118-4 pada istiod. Untuk mengaktifkan injeksi otomatis, tambahkan label revisi yang cocok ke namespace Anda. Label revisi digunakan oleh webhook injektor file bantuan untuk mengaitkan file bantuan yang dimasukkan dengan revisi istiod tertentu. Setelah menambahkan label, mulai ulang Pod di namespace untuk file bantuan yang akan dimasukkan.

1. Dapatkan label revisi yang ada di istiod dan istio-ingressgateway.

   kubectl get pod -n istio-system -L istio.io/rev
   

   Output dari perintah serupa dengan berikut ini.

   NAME                                             READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1118-4
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1118-4
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-1107-1
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-1107-1
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1118-4
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1118-4

   1. Pada output, di kolom REV, catat nilai label revisi untuk versi baru. Dalam contoh ini, nilainya adalah asm-1118-4.

   2. Perhatikan juga nilai dalam label revisi untuk versi istiod lama. Anda memerlukan tindakan ini untuk menghapus versi lama istiod saat selesai memindahkan beban kerja ke versi baru. Dalam contoh output, nilai label revisi untuk versi lama adalah asm-1107-1.

2. Tambahkan label revisi ke namespace dan hapus label istio-injection (jika ada). Dalam perintah berikut, ubah REVISION ke nilai yang cocok dengan revisi baru istiod.

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

   Jika melihat "istio-injection not found" pada output, Anda dapat mengabaikannya. Artinya, namespace sebelumnya tidak memiliki label istio-injection. Karena injeksi otomatis gagal jika namespace memiliki istio-injection dan label revisi, semua perintah kubectl label dalam dokumentasi Anthos Service Mesh mencakup penghapusan label istio-injection.

3. Mulai ulang Pod untuk memicu injeksi ulang.

   kubectl rollout restart deployment -n NAMESPACE

4. Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar.

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

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

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

   2. Konfigurasikan webhook yang memvalidasi 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 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 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 istiod versi lama. 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 untuk istiod versi sebelumnya.

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

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

   1. Beralih kembali ke istio-ingressgateway versi lama. Dalam perintah berikut, ganti OLD_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"}]'
      

   2. Beri label ulang namespace Anda untuk mengaktifkan injeksi otomatis dengan versi istiod sebelumnya. Perintah yang digunakan 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 istiod versi 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. Pastikan nilai REVISION dalam perintah berikut sudah benar.

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

   6. Hapus versi baru istiod. Pastikan nilai REVISION dalam perintah berikut sudah benar.

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

   7. Hapus versi baru konfigurasi IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      Output yang diharapkan mirip dengan berikut ini:

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   8. Jika Anda tidak menyertakan flag --disable_canonical_service, skrip akan mengaktifkan pengontrol Layanan Kanonis. Sebaiknya Anda membiarkannya tetap aktif, tetapi jika Anda perlu menonaktifkannya, lihat Mengaktifkan dan menonaktifkan pengontrol Layanan Kanonis.

Langkah selanjutnya

• Men-deploy aplikasi contoh Online Boutique
• Menyiapkan mesh multi-cluster