Bermigrasi dari Istio

Halaman ini menjelaskan cara menjalankan skrip untuk bermigrasi dari Istio ke Anthos Service Mesh 1.10.6 di cluster GKE untuk mesh yang berisi satu atau beberapa cluster yang berada dalam project Google Cloud yang sama. Jika menggunakan Istio 1.6 atau yang lebih lama, Anda harus mengupgrade terlebih dahulu sebelum bermigrasi ke Anthos Service Mesh. Jika memiliki Istio 1.7 atau yang lebih baru, Anda mungkin dapat menggunakan Bermigrasi dari Istio 1.7 atau yang lebih baru ke Anthos Service Mesh dan Mesh CA. 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 ke 1.8.x) dalam satu langkah tidak diuji atau direkomendasikan secara resmi.

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 akan selalu menyertakan opsi berikut: project_id, cluster_name, cluster_location, mode, dan ca. Untuk ca, Anda memiliki opsi berikut:

    • --ca mesh_ca: Tentukan opsi ini saat Anda ingin bermigrasi ke certificate authority Anthos Service Mesh (Mesh CA).

    • --ca citadel: Tentukan opsi ini jika Anda ingin terus menggunakan CA Istio.

    Untuk mengetahui informasi selengkapnya, lihat Memilih certificate authority.

    Catatan: Anda dapat menggunakan --mode install untuk migrasi dari Istio. Saat Anda menggunakan --mode install, bukan --mode migrate, install_asm akan mengizinkan migrasi, apa pun versi bidang kontrol yang ada di cluster. Flag migrate hanya mengizinkan migrasi dari versi minor sebelumnya atau versi patch sebelumnya.

    Bagian berikut memberikan contoh umum untuk menjalankan skrip. 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 dari Istio dengan beberapa argumen tambahan yang mungkin berguna bagi Anda. Lihat menu navigasi di sebelah kanan untuk melihat daftar contohnya.

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

Bermigrasi ke Mesh CA dengan periode nonaktif

Migrasi ke certificate authority Anthos Service Mesh (Mesh CA) dari CA Istio memerlukan migrasi root of trust. Selama migrasi, beberapa beban kerja menggunakan root certificate lama, sementara yang lain menggunakan root certificate CA Mesh baru. Beban kerja yang menggunakan sertifikat yang ditandatangani oleh root certificate yang berbeda tidak dapat saling melakukan autentikasi. Seluruh cluster hanya akan sepenuhnya pulih saat bidang kontrol dan semua workload di semua namespace di-deploy ulang dengan sertifikat root CA baru.

Jika Anda dapat menjadwalkan periode nonaktif, ini adalah cara termudah untuk bermigrasi ke Anthos Service Mesh dengan Mesh CA. Contoh berikut menunjukkan opsi command line yang umum untuk bermigrasi ke Mesh CA.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir OUTPUT_DIRECTORY
  --enable_all

Bermigrasi ke Mesh CA dengan sedikit atau tanpa periode nonaktif

Jika Anda tidak dapat menjadwalkan periode nonaktif untuk migrasi ke Mesh CA, masih ada jalur migrasi ke Mesh CA, tetapi memerlukan langkah tambahan. Untuk mengetahui detailnya, lihat Bermigrasi ke Mesh CA.

Bermigrasi tetapi terus menggunakan Istio CA

Jika memerlukan CA kustom, Anda dapat terus menggunakan CA Istio setelah bermigrasi ke Anthos Service Mesh. Perintah berikut menjalankan skrip untuk migrasi dan mengaktifkan CA Istio. (Opsi --ca citadel disebut "citadel" karena itu adalah nama komponen CA sebelum semua komponen Istio dimasukkan dalam istiod.) Migrasi ini hanya men-deploy bidang kontrol dan gateway masuk. Hal ini tidak mengubah root CA dan tidak mengganggu beban kerja Anda yang ada.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --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 install \
  --ca citadel \
  --enable_all \
  --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 install \
  --ca citadel \
  --enable_all \
  --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.10-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-1106-2 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-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

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

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

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

    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.

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