Migrasi CA yang Langsung

Untuk bermigrasi dari Istio CA ke Mesh CA dengan pendekatan berbasis canary yang melibatkan periode nonaktif minimal atau tanpa periode nonaktif, lihat Migrasi berbasis Canary ke CA Mesh.

Jika mesh Anda memiliki beberapa cluster dengan workload yang mengirim permintaan ke beban kerja di cluster lain, ikuti semua langkah dalam panduan ini untuk semua cluster tersebut.

Gunakan langkah-langkah dalam panduan ini untuk kasus penggunaan berikut:

• Migrasikan bidang kontrol Cloud Service Mesh v1.13 atau yang lebih baru dalam cluster dengan Mesh CA ke Certificate Authority Service.
• Migrasikan bidang kontrol Cloud Service Mesh terkelola pada saluran rilis yang dipetakan ke v1.13 atau yang lebih baru dengan Mesh CA ke Certificate Authority Service.

Batasan

Migrasi dan upgrade CA yang diterapkan hanya didukung dari Cloud Service Mesh v1.13 atau yang lebih baru. Untuk migrasi bidang kontrol terkelola, pastikan saluran yang dipilih dipetakan ke v1.13 atau yang lebih baru.

Prasyarat

Sebelum mengikuti langkah-langkah dalam panduan ini, pastikan Anda telah:

• Memberikan izin admin cluster
• Mengonfigurasi gcloud

Selain itu, pastikan Anda saat ini menggunakan Cloud Service Mesh v1.13 atau yang lebih baru.

Alat yang diperlukan

Selama migrasi, Anda dapat menjalankan alat yang disediakan Google, migrate_ca. Alat ini memiliki dependensi berikut:

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

Sebelum mendownload alat migrate_ca, ikuti langkah-langkah di Menyiapkan migrasi Anda.

Ringkasan migrasi

Selama proses migrasi, autentikasi dan otorisasi berfungsi penuh antara workload yang menggunakan CA sebelumnya dan workload yang menggunakan CA baru.

Alat migrasi migrate_ca akan membuat peta konfigurasi Kubernetes untuk melacak status migrasi CA per revisi/saluran Cloud Service Mesh yang terinstal. Ini adalah resource dengan hak istimewa yang diinstal di namespace istio-system.

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

Alat migrasi akan mencadangkan peta konfigurasi Istio MeshConfig sebelum mengubahnya dan mencoba memigrasikan konfigurasi CA menggunakan CRD ProxyConfig jika memungkinkan.

Berikut adalah garis besar migrasi CA:

Catatan: Anda harus melakukan langkah-langkah migrasi pada setiap cluster di mesh Anda.

1. Persiapkan migrasi Anda.

2. Lakukan inisialisasi CA baru.

3. Menambahkan trustAnchors seluruh mesh untuk semua cluster dalam fleet.

4. Memigrasikan CA.

5. Melakukan rollback.

Mempersiapkan migrasi

1. Download alat bash migrate_ca:

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

2. Jadikan alat ini dapat dieksekusi:

   chmod +x migrate_ca
   

3. Siapkan direktori kerja:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Catatan: Jika Anda tidak menentukan direktori kerja, direktori kerja sementara akan dibuat. Anda harus menggunakannya sebagai direktori kerja untuk semua langkah berikutnya.

4. Ubah direktori kerja ke OUTPUT_DIR yang ditentukan di langkah sebelumnya

   cd OUTPUT_DIR
   

5. Jalankan perintah berikut untuk memastikan semua prasyarat terpenuhi:

   ./migrate_ca check-prerequisites
   

6. Catat revisi (ASM_REVISION) bidang kontrol yang terkait dengan CA sebelumnya yang sedang dimigrasikan. Langkah-langkah yang diperlukan bergantung pada jenis bidang kontrol, baik di dalam cluster maupun terkelola.

   Dalam cluster

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   Terkelola

   Lihat saluran yang sudah terinstal.

7. Karena migrasi CA yang diterapkan mengharuskan Anda memulai ulang workload, pastikan Anggaran Gangguan Pod dikonfigurasi dengan benar dan semua aplikasi dengan CA yang perlu dimigrasikan memiliki lebih dari satu Pod yang berjalan.

8. Pastikan cluster sudah terdaftar ke fleet dan workload-identitas diaktifkan di cluster. Kemudian, catat ID project perangkat tersebut sebagai (FLEET_ID) untuk langkah-langkah mendatang.

9. Alat ini menerima kubeConfig dan kubeContext untuk memilih cluster tempat operasi dilakukan. Jika argumen ini tidak diteruskan, konteks/konfigurasi default akan digunakan.

   • Untuk menambahkan kredensial cluster GKE ke kubeConfig, gunakan perintah berikut:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Untuk mengubah konteks kubectl saat ini atau meneruskan konteks ke alat, gunakan perintah berikut:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Melakukan inisialisasi CA baru

1. Langkah-langkah yang diperlukan untuk melakukan inisialisasi CA baru bergantung pada CA baru tujuan migrasi. Lakukan langkah-langkah ini di setiap cluster fleet tempat Anda ingin memigrasikan CA.

   Jaring CA

   Panggil sub-perintah alat utilitas initialize.

   Jika Anda menentukan konfigurasi Kubernetes kustom:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   Atau:

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   CA Service

   a. Ikuti langkah-langkah yang diperlukan untuk melakukan inisialisasi Certificate Authority Service. Catat CA_POOL.

   b. Panggil sub-perintah alat utilitas initialize:

   Jika Anda menentukan konfigurasi Kubernetes kustom:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   Atau:

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

Menambahkan trustAnchors seluruh mesh untuk semua cluster dalam fleet

1. Ulangi langkah-langkah di bawah ini untuk CA baru dan CA lama untuk semua cluster yang merupakan bagian dari fleet.

2. Download trustAnchor CA:

   Jaring CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   CA Service

   Simpan sertifikat CA dalam file:

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. Tambahkan trustAnchor CA:

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Pastikan trustAnchor telah diterima oleh semua workload di fleet. Pada argumen namespace, teruskan semua namespace tempat workload di-deploy:

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Output yang diharapkan:

   Check the CA cert in namespace nsa-1-24232                                                                                                                               
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

Memigrasikan CA

1. Memigrasikan konfigurasi CA. Perintah yang diperlukan bergantung pada CA baru tempat Anda bermigrasi.

   Jaring CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   CA Service

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Mulai ulang semua workload.

   Catatan: Langkah ini bersifat opsional jika Anda telah menginstal bidang data terkelola. Hal ini karena Google mengelola masa aktif proxy dan secara otomatis melakukan langkah ini selama upgrade terkelola.

   Untuk meminimalkan risiko periode nonaktif traffic TLS, langkah ini harus memengaruhi jumlah workload terkecil terlebih dahulu. Hanya memulai ulang workload yang terkait dengan revisi bidang kontrol ASM_REVISION. Misalnya, jika semua workload di namespace kubernetes NAMESPACE dikaitkan dengan bidang kontrol Cloud Service Mesh yang sama.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Pastikan koneksi mTLS berfungsi antara workload di namespace yang dimulai ulang dan workload lain sebelum mengulangi langkah 1 dan 2 untuk semua namespace serta untuk semua cluster yang merupakan bagian dari fleet. Jika beban kerja yang lebih baru akan muncul dan traffic mesh tidak terganggu, ulangi langkah 1 dan 2 untuk semua namespace dan cluster yang merupakan bagian dari fleet. Jika tidak, lanjutkan untuk melakukan rollback untuk melakukan rollback konfigurasi CA yang lebih baru.

4. Pastikan konfigurasi CA yang baru digunakan oleh semua workload:

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Output yang diharapkan:

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

Melakukan rollback

1. Roll back konfigurasi CA dan hapus trustAnchors yang baru dikonfigurasi:

   ./migrate-ca rollback
   

2. Mulai ulang semua workload. Pastikan Anda hanya memulai ulang workload yang terkait dengan revisi bidang kontrol ASM_REVISION. Misalnya, jika semua workload di namespace kubernetes NAMESPACES dikaitkan dengan bidang kontrol Cloud Service Mesh yang sama.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opsional) Pastikan bahwa konfigurasi CA lama digunakan oleh semua beban kerja.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Ulangi langkah 1–3 untuk semua cluster dalam fleet tempat workload menggunakan bidang kontrol ASM_REVISION.

Selamat! Anda telah berhasil melakukan migrasi CA langsung.