Anthos Service Mesh 1.8 telah mencapai akhir siklus proses dan tidak lagi didukung. Lihat Mengupgrade dari versi sebelumnya.

Lihat dokumentasi terbaru atau pilih versi lain yang tersedia:

Versi yang tersedia

1.20 (terbaru)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.12

219}

Bermigrasi dari Istio

Halaman ini menjelaskan cara menjalankan skrip untuk bermigrasi dari Istio 1.7 or 1.8 ke Anthos Service Mesh 1.8.6 di cluster GKE untuk mesh yang berisi satu atau beberapa cluster yang berada dalam project Google Cloud yang sama.

Untuk mesh multi-cluster tempat cluster berada di project yang berbeda, lihat Penginstalan dan migrasi multi-cluster/multi-project untuk 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

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.
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 yang sudah ada untuk 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 bahwa skrip perlu dijalankan dengan tanda pengaktifan, Anda dapat menyertakan tanda tertentu dari pesan error atau tanda --enable_all saat menjalankan skrip tanpa --only_validate. Jika mau, Anda dapat mengupdate project dan membuat cluster sendiri sebelum menjalankan skrip seperti yang dijelaskan di bagian Menyiapkan project Anda dan Menyiapkan cluster dalam panduan penginstalan Multiproject.

Migrasi dari Istio dengan Citadel

Jika bermigrasi dari Istio dengan Citadel sebagai CA, Anda dapat terus menggunakan Citadel setelah bermigrasi ke Anthos Service Mesh. Perintah berikut menjalankan skrip untuk migrasi dan mengaktifkan Citadel sebagai CA. Migrasi ini hanya men-deploy bidang kontrol. Tindakan ini tidak mengubah root CA dan tidak mengganggu beban kerja 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.8-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-186-8 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.

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-186-8
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-186-8
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-178-10
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-178-10
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-186-8
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-186-8
```
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-186-8.
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-178-10.
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
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.

Mulai ulang Pod untuk memicu injeksi ulang.

kubectl rollout restart deployment -n NAMESPACE

Pastikan bahwa Pod Anda telah dikonfigurasi untuk mengarah ke versi baru istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```
Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar.
Jika Anda memiliki beban kerja di namespace lain, ulangi langkah-langkah untuk memberi label pada namespace dan memulai ulang Pod.
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.
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
```
Perhatian: Jangan menjalankan perintah apa pun yang menghapus Deployment istio-ingressgateway jika Anda hanya memiliki istio-ingressgateway versi baru. Tindakan ini akan mencegah traffic masuk ke mesh layanan Anda.
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.

Di konsol Google Cloud, buka Anthos Service Mesh.

Buka Anthos Service Mesh
Pilih project Google Cloud dari menu drop-down di panel menu.
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:

Di konsol Google Cloud, buka halaman Monitoring:

Buka Monitoring
Pilih Resource > Metrics Explorer.

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