Anthos Service Mesh 1.11 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 ke Mesh CA

Migrasi ke certificate authority Anthos Service Mesh (Mesh CA) dari Istio CA (juga dikenal sebagai Citadel) memerlukan migrasi root kepercayaan. Sebelum Anthos Service Mesh 1.10, jika ingin bermigrasi dari Istio di Google Kubernetes Engine (GKE) ke Anthos Service Mesh dengan Mesh CA, Anda harus menjadwalkan periode nonaktif karena Anthos 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. Beban kerja yang menggunakan sertifikat yang ditandatangani oleh root certificate yang berbeda tidak dapat saling melakukan autentikasi. Artinya, traffic multi-TLS (mTLS) terganggu selama migrasi. Seluruh cluster hanya sepenuhnya pulih saat bidang kontrol dan semua workload di semua namespace di-deploy ulang dengan sertifikat Mesh CA. Jika mesh Anda memiliki beberapa cluster dengan beban kerja yang mengirimkan permintaan ke workload di cluster lain, semua workload di cluster tersebut juga perlu diperbarui.

Halaman ini menjelaskan cara melakukan migrasi dari Istio CA ke Mesh CA dengan periode nonaktif minimal atau tanpa periode nonaktif. Gunakan langkah-langkah dalam panduan ini untuk kasus penggunaan berikut:

Bermigrasi dari Istio di GKE ke bidang kontrol dalam cluster 1.11.8-asm.4 Anthos Service Mesh dengan Mesh CA.
Mengupgrade dari 1.9 or a 1.10 patch release Anthos Service Mesh dengan Istio CA ke bidang kontrol dalam cluster 1.11.8-asm.4 Anthos Service Mesh dengan Mesh CA.

Batasan

Mesh CA hanya didukung di GKE.
Semua cluster GKE harus berada dalam project Google Cloud yang sama.

Prasyarat

Ikuti langkah-langkah di bagian Memulai untuk:

Alat yang diperlukan

Selama migrasi, Anda menjalankan alat yang disediakan Google, migrate_ca, untuk memvalidasi hal berikut bagi setiap Pod dalam cluster:

Root certificate untuk Istio CA dan Mesh CA.
Sertifikat mTLS workload yang dikeluarkan oleh Istio CA dan oleh Mesh CA.
Domain kepercayaan yang dikonfigurasi oleh Istio CA dan Mesh CA.

Alat ini memiliki dependensi berikut:

awk
grep
istioctl Saat Anda menjalankan alat install_asm, alat ini akan mendownload versi istioctl yang cocok dengan versi Anthos Service Mesh yang diinstal.
jq
kubectl
openssl

Ringkasan migrasi

Untuk bermigrasi ke Mesh CA, ikuti proses migrasi berbasis revisi (juga disebut sebagai "upgrade canary"). Dengan migrasi berbasis revisi, revisi bidang kontrol baru di-deploy bersama bidang kontrol yang ada. Kemudian, Anda secara bertahap memindahkan workload ke revisi baru, yang memungkinkan Anda memantau efek migrasi selama prosesnya. Selama proses migrasi, autentikasi dan otorisasi berfungsi sepenuhnya antara workload yang menggunakan CA Mesh dan workload yang menggunakan Istio CA.

Berikut adalah garis besar migrasi ke Mesh CA:

Mendistribusikan root kepercayaan CA Mesh.
1. Instal revisi bidang kontrol baru yang menggunakan Istio CA dengan opsi yang akan mendistribusikan root of trust Mesh CA.
2. Migrasikan workload ke bidang kontrol baru, namespace berdasarkan namespace, dan uji aplikasi Anda. Setelah semua beban kerja berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.
Bermigrasi ke Mesh CA. Setelah semua proxy file bantuan dikonfigurasi dengan root kepercayaan lama dan root kepercayaan CA Mesh, Anda dapat bermigrasi ke Mesh CA tanpa periode nonaktif. Sekali lagi, Anda mengikuti proses migrasi berbasis revisi:
1. Instal revisi bidang kontrol dengan Mesh CA diaktifkan.
2. Migrasikan workload ke revisi bidang kontrol baru, namespace menurut namespace, lalu uji aplikasi Anda. Setelah semua workload berhasil dimigrasikan ke bidang kontrol baru, hapus bidang kontrol lama.
3. Hapus rahasia CA di cluster yang terkait dengan CA lama dan mulai ulang bidang kontrol baru.

Mendistribusikan root kepercayaan CA Mesh

Sebelum Anda dapat bermigrasi ke Mesh CA, semua cluster GKE di mesh harus memiliki Anthos Service Mesh 1.10 atau yang lebih baru, dan semua cluster harus dikonfigurasi dengan opsi bidang kontrol yang memicu root kepercayaan untuk Mesh CA agar didistribusikan ke proxy semua workload di cluster. Setelah proses selesai, setiap proxy akan dikonfigurasi dengan root kepercayaan lama dan baru. Dengan skema ini, saat Anda bermigrasi ke Mesh CA, beban kerja yang menggunakan Mesh CA akan dapat melakukan autentikasi dengan beban kerja menggunakan CA lama.

Menginstal revisi bidang kontrol baru

Instal revisi bidang kontrol dengan opsi yang mendistribusikan root of trust Mesh CA.

Ikuti langkah-langkah di bagian Memulai untuk bersiap menggunakan alat yang disediakan Google, asmcli, untuk menginstal revisi bidang kontrol baru.
Pastikan Anda memiliki versi asmcli yang menginstal Anthos Service Mesh 1.11 atau yang lebih tinggi:
```
./asmcli --version
```

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 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:
- Memberikan izin IAM yang diperlukan.
- Mengaktifkan 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 Istio CA (opsi citadel sesuai dengan Istio CA). Jangan beralih ke Mesh CA pada tahap ini.
--ca_cert Intermediate certificate.
--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 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 akan menetapkan nilai untuk label revisi berdasarkan versi Anthos Service Mesh, misalnya: asm-1118-4. Sebaiknya sertakan opsi ini dan ganti REVISION_1 dengan nama yang menjelaskan penginstalan, seperti asm-1118-4-distribute-root. Nama harus berupa label DNS-1035, dan harus terdiri dari karakter alfanumerik huruf kecil atau -, dimulai dengan karakter alfabet, dan diakhiri dengan karakter alfanumerik (seperti my-name atau abc-123).

Memigrasikan beban kerja ke bidang kontrol baru

Untuk menyelesaikan distribusi root kepercayaan baru, Anda perlu memberi label namespace dengan label revisi istio.io/rev=<var>REVISION_1</var>-distribute-root, lalu memulai ulang workload Anda. Saat menguji beban kerja setelah memulai ulang beban, Anda menjalankan alat untuk memvalidasi bahwa proxy file bantuan dikonfigurasi dengan root of trust lama dan baru untuk Mesh CA.

Setel konteks saat ini untuk kubectl. Dalam perintah berikut, ubah --region menjadi --zone jika Anda memiliki cluster zona tunggal.
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION
```

Download alat validasi:

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca

Tetapkan bit yang dapat dieksekusi pada alat ini:
```
chmod +x migrate_ca
```
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 tersebut.
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

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

Pada output, di kolom REV, catat nilai label revisi untuk revisi baru, yang cocok dengan label revisi yang Anda tentukan saat menjalankan asmcli install. Dalam contoh ini, nilainya adalah asm-1118-4-distribute-root.
Anda harus menghapus revisi lama istiod saat selesai memindahkan beban kerja ke revisi baru. Catat nilai dalam label revisi untuk revisi istiod lama. Contoh output menunjukkan migrasi dari Istio, yang menggunakan revisi default.

Tambahkan label revisi ke namespace dan hapus label istio-injection (jika ada). Dalam perintah berikut, ganti NAMESPACE dengan namespace yang akan diberi label.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 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

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.

Validasi bahwa proxy file bantuan untuk semua beban kerja di cluster dikonfigurasi dengan root certificate 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]

Jika Anda perlu memigrasikan gateway, ikuti langkah-langkah dalam bagian Canary Upgrade (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 periode nonaktif. Pastikan bahwa resource layanan yang menunjuk ke gateway lama juga harus menyertakan deployment yang lebih baru.
- Jangan hapus deployment gateway lama sampai Anda yakin aplikasi berfungsi dengan baik (setelah langkah berikutnya).
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 revisi lama istiod. 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. 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 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.
```
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-1118-4-distribute-root -n istio-system
```
  Output yang diharapkan mirip dengan berikut ini:
```
istiooperator.install.istio.io "installed-state-asm-1118-4-distribute-root" deleted
```