Bermigrasi dari Istio

Halaman ini menjelaskan cara menjalankan skrip untuk bermigrasi dari Istio 1.8 or 1.9 ke Anthos Service Mesh 1.9.8 di cluster GKE untuk mesh yang berisi satu atau beberapa cluster yang berada dalam project Google Cloud yang sama. Jika memiliki Istio versi sebelumnya, Anda harus mengupgrade terlebih dahulu sebelum bermigrasi ke Anthos Service Mesh. Jika Anda perlu melakukan upgrade, buka halaman Upgrade Istio di versi Istio yang berlaku. Perlu diperhatikan bahwa Mengupgrade Istio di lebih dari satu versi minor (misalnya, 1,6.x hingga 1,8.x) dalam satu langkah tidak diuji atau direkomendasikan secara resmi.

Untuk bermigrasi dari Istio tempat cluster berada di project yang berbeda, lihat panduan multi-project GKE.

Halaman ini ditujukan untuk migrasi dari Istio ke Anthos Service Mesh. Untuk informasi tentang menjalankan skrip untuk penginstalan dan upgrade baru, lihat artikel berikut:

Sebelum memulai

Sebelum memulai migrasi, pastikan Anda memiliki:

Skrip ini mengharuskan Anda memiliki izin yang diperlukan, atau menyertakan tanda --enable_all atau --enable_gcp_iam_roles agar skrip dapat mengaktifkan izin untuk Anda. Demikian pula, untuk mengizinkan skrip mengaktifkan API yang diperlukan dan memperbarui cluster Anda, tentukan flag --enable_all atau tanda pengaktifan yang lebih terperinci.

Menyiapkan migrasi

Pastikan untuk meninjau Mempersiapkan migrasi dari Istio.

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.

Bermigrasi ke Anthos Service Mesh

  1. Tetapkan opsi dan tentukan tanda untuk menjalankan skrip. Anda selalu menyertakan opsi berikut: project_id, cluster_name, cluster_location, dan mode.

    Bagian berikut memberikan contoh umum untuk menjalankan skrip. Lihat menu navigasi di sebelah kanan untuk melihat daftar contoh. Untuk deskripsi lengkap argumen skrip, lihat Opsi dan flag.

  2. Untuk menyelesaikan penyiapan Anthos Service Mesh, Anda perlu mengaktifkan injeksi bantuan otomatis dan men-deploy atau men-deploy ulang workload.

Contoh

Bagian ini menunjukkan contoh cara menjalankan skrip untuk migrasi dengan beberapa argumen tambahan yang mungkin berguna bagi Anda. Lihat menu navigasi di sebelah kanan untuk daftar contoh.

Hanya validasi

Contoh berikut menunjukkan cara menjalankan skrip dengan opsi --only_validate. Dengan opsi ini, skrip tidak membuat perubahan apa pun pada project atau cluster Anda, dan tidak menginstal Anthos Service Mesh. Saat Anda menentukan --only_validate,skrip akan gagal jika Anda menyertakan salah satu tanda --enable_*.

Skrip ini memvalidasi bahwa:

  • Lingkungan Anda memiliki alat yang diperlukan.
  • Anda memiliki izin yang diperlukan pada project yang ditentukan.
  • Cluster memenuhi persyaratan minimum.
  • Project ini telah mengaktifkan semua Google API yang diperlukan.

Secara default, skrip akan mendownload dan mengekstrak file penginstalan serta mendownload paket konfigurasi asm dari GitHub ke direktori sementara. Sebelum keluar, skrip akan menghasilkan pesan yang memberikan nama direktori sementara. Anda dapat menentukan direktori untuk hasil download dengan opsi --output_dir DIR_PATH. Opsi --output_dir memudahkan Anda menggunakan alat command line istioctl jika Anda membutuhkannya. Selain itu, file konfigurasi untuk mengaktifkan fitur opsional disertakan dalam direktori asm/istio/options.

Jalankan perintah berikut untuk memvalidasi konfigurasi Anda dan mendownload file penginstalan serta paket asm ke direktori OUTPUT_DIR:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --output_dir DIR_PATH \
  --only_validate

Jika berhasil, skrip menghasilkan output berikut:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Jika salah satu pengujian gagal dalam validasi, skrip akan menampilkan pesan error. Misalnya, jika project Anda tidak mengaktifkan semua Google API yang diperlukan, Anda akan melihat error berikut:

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Jika Anda mendapatkan pesan error yang menyatakan perlunya menjalankan skrip dengan tanda pengaktifan, Anda memiliki opsi berikut:

  • Sertakan tanda tertentu dari pesan error atau tanda --enable_all saat menjalankan skrip untuk melakukan penginstalan yang sebenarnya (yaitu, tanpa --only_validate).

  • Jika ingin, Anda dapat mengupdate project dan membuat cluster sendiri sebelum menjalankan skrip seperti yang dijelaskan dalam Penyiapan untuk menginstal Anthos Service Mesh di GKE.

Perhatikan bahwa install_asm tidak mengizinkan flag pengaktifan dengan --only_validate.

Migrasi dengan Istio CA

Jika bermigrasi dari Istio, Anda dapat terus menggunakan Istio CA sebagai certificate authority setelah bermigrasi ke Anthos Service Mesh. Perintah berikut menjalankan skrip untuk migrasi dan mengaktifkan Istio CA. Migrasi ini hanya men-deploy bidang kontrol. Tindakan ini tidak mengubah root certificate dan tidak mengganggu beban kerja Anda yang ada.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --option revisioned-istio-ingressgateway \
  --enable_all

Bermigrasi dengan file overlay

File overlay adalah file YAML yang berisi resource kustom (CR) IstioOperator yang Anda teruskan ke install_asm untuk mengonfigurasi bidang kontrol. Anda dapat mengganti konfigurasi bidang kontrol default dan mengaktifkan fitur opsional dengan meneruskan file YAML ke install_asm. Anda dapat menambahkan lapisan pada lebih banyak overlay, dan setiap file overlay akan menggantikan konfigurasi pada lapisan sebelumnya.

Jika Anda menentukan lebih dari satu CR dalam file YAML, install_asm akan membagi file tersebut menjadi beberapa file YAML sementara, satu untuk setiap CR. Skrip ini membagi CR menjadi beberapa file terpisah karena istioctl install hanya menerapkan CR pertama dalam file YAML yang berisi lebih dari satu CR.

Contoh berikut melakukan migrasi dan menyertakan file overlay untuk menyesuaikan konfigurasi bidang kontrol. Dengan perintah berikut, ubah OVERLAY_FILE menjadi nama file YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --custom_overlay OVERLAY_FILE

Bermigrasi dengan opsi

Contoh berikut melakukan migrasi dan menyertakan file egressgateways.yaml dari paket asm, yang memungkinkan gateway keluar. Perhatikan bahwa Anda tidak menyertakan ekstensi .yaml. Skrip ini mengambil file untuk Anda sehingga Anda tidak perlu mendownload paket asm terlebih dahulu.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --option revisioned-istio-ingressgateway \
  --option egressgateways

Anda dapat menggunakan --option untuk mengaktifkan fitur opsional. Jika Anda perlu memodifikasi salah satu file dalam direktori asm/istio/options dalam paket asm, download paket asm, buat perubahan, dan sertakan file tersebut menggunakan --custom_overlay.

Untuk mendownload paket asm ke direktori kerja saat ini agar Anda dapat melakukan modifikasi pada file:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm

Jika Anda menjalankan contoh Only validasi tempat Anda menentukan opsi --output_dir, file konfigurasi akan berada di direktori output yang ditentukan di asm/istio/options.

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

Skrip ini menetapkan label revisi dalam format istio.io/rev=asm-198-6 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.

Skrip ini juga membuat Deployment istio-ingressgateway yang direvisi. Tindakan ini memungkinkan Anda mengontrol kapan beralih ke versi baru.

  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-198-6
    istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-198-6
    istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-186-8
    istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-186-8
    istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-198-6
    istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-198-6
    1. Perhatikan apakah Anda memiliki istio-ingressgateway versi lama dan baru.

      • Jika Anda menyertakan opsi revisioned-istio-ingressgateway saat mengupgrade, upgrade canary istio-ingressgateway telah selesai. Dalam hal ini, output Anda akan menampilkan istio-ingressgateway versi lama dan baru.

      • Jika Anda tidak menyertakan revisioned-istio-ingressgateway saat mengupgrade, upgrade istio-ingressgateway yang sudah ada telah dilakukan. Dalam hal ini, output hanya menampilkan versi baru.

    2. Pada output, di kolom REV, catat nilai label revisi untuk versi baru. Dalam contoh ini, nilainya adalah asm-198-6.

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

  2. Jika Anda memiliki istio-ingressgateway versi lama dan baru, alihkan istio-ingressgateway ke revisi baru. Dalam perintah berikut, ubah REVISION 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"}]'

    Output yang diharapkan: service/istio-ingressgateway patched

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

  4. Mulai ulang Pod untuk memicu injeksi ulang.

    kubectl rollout restart deployment -n NAMESPACE
  5. Pastikan bahwa Pod Anda telah dikonfigurasi untuk mengarah ke versi baru istiod.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
  6. Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar.

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

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

  9. Jalankan kembali perintah berikut untuk mengonfirmasi apakah Anda memiliki istio-ingressgateway versi lama dan baru atau hanya versi baru. Tindakan ini menentukan cara Anda menangani transisi ke versi baru istio-ingressgateway atau melakukan roll back ke versi lama.

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

    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. Jika Anda memiliki istio-ingressgateway versi lama dan baru, hapus Deployment istio-ingressgateway 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, istiod 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 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. Perintah yang digunakan bergantung pada apakah Anda memiliki istio-ingressgateway versi lama dan baru atau hanya versi baru.

      • Jika Anda memiliki istio-ingressgateway versi lama dan baru, jalankan perintah kubectl patch service dan 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"}]'
        
      • Jika Anda hanya memiliki istio-ingressgateway versi baru, jalankan perintah kubectl rollout undo.

        kubectl -n istio-system rollout undo deploy istio-ingressgateway
        
    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. Jika Anda memiliki istio-ingressgateway versi lama dan baru, 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.

Melihat dasbor Anthos Service Mesh

Setelah workload di-deploy di cluster dengan proxy file bantuan dimasukkan, Anda dapat menjelajahi halaman Anthos Service Mesh di Konsol Google Cloud untuk melihat semua fitur kemampuan observasi yang ditawarkan Anthos Service Mesh. Perlu diperhatikan bahwa perlu waktu sekitar satu atau dua menit agar data telemetri ditampilkan di konsol Google Cloud setelah Anda men-deploy workload.

Akses ke Anthos Service Mesh di Konsol Google Cloud dikontrol oleh Identity and Access Management (IAM). Untuk mengakses halaman Anthos Service Mesh, Pemilik Project harus memberi pengguna peran Project Editor atau Viewer, atau peran yang lebih ketat yang dijelaskan dalam Mengontrol akses ke Anthos Service Mesh di Konsol Google Cloud.

  1. Di konsol Google Cloud, buka Anthos Service Mesh.

    Buka Anthos Service Mesh

  2. Pilih project Google Cloud dari menu drop-down di panel menu.

  3. Jika Anda memiliki lebih dari satu mesh layanan, pilih mesh dari menu drop-down Service Mesh.

Untuk mempelajari lebih lanjut, lihat Menjelajahi Anthos Service Mesh di Konsol Google Cloud.

Selain halaman Anthos Service Mesh, metrik yang terkait dengan layanan Anda (seperti jumlah permintaan yang diterima oleh layanan tertentu) dikirim ke Cloud Monitoring, yang akan muncul di Metrics Explorer.

Untuk melihat metrik:

  1. Di konsol Google Cloud, buka halaman Monitoring:

    Buka Monitoring

  2. Pilih Resource > Metrics Explorer.

Untuk mengetahui daftar lengkap metrik, lihat Metrik Istio dalam dokumentasi Cloud Monitoring.

Langkah selanjutnya