Migrasi CA di Tempat

Catatan: Panduan ini menjelaskan cara memigrasikan certificate authority (CA) tanpa memigrasikan beban kerja ke bidang kontrol baru (di tempat) dengan periode nonaktif minimal menggunakan alat berbasis bash. 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 Mesh CA.

Jika mesh Anda memiliki beberapa cluster dengan workload yang mengirimkan permintaan ke beban kerja pada 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 Anthos Service Mesh v1.13 atau yang lebih baru dalam cluster dengan Mesh CA ke Certificate Authority Service.
• Migrasikan bidang kontrol Anthos Service Mesh terkelola di saluran rilis yang dipetakan ke v1.13 atau yang lebih baru dengan Mesh CA ke Certificate Authority Service.

Batasan

Migrasi dan upgrade CA di tempat hanya didukung dari Anthos 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:

• Izin admin cluster yang diberikan
• gcloud yang dikonfigurasi

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

Alat yang diperlukan

Selama migrasi, Anda 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.

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 Anthos Service Mesh yang diinstal. 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 ringkasan migrasi CA:

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

1. Siapkan migrasi Anda.

2. Lakukan inisialisasi CA baru.

3. Tambahkan trustAnchors tingkat mesh untuk semua cluster dalam fleet.

4. Migrasikan CA.

5. Jalankan rollback.

Mempersiapkan migrasi Anda

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 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 bahwa semua prasyarat terpenuhi:

   ./migrate_ca check-prerequisites
   

6. Catat revisi (ASM_REVISION) bidang kontrol yang terkait dengan CA sebelumnya yang sedang dimigrasikan. Langkah yang diperlukan bergantung pada jenis bidang kontrol, baik dalam cluster maupun yang 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 diinstal.

7. Karena migrasi CA bawaan mengharuskan Anda untuk memulai ulang workload, pastikan Pod Disruption Budget dikonfigurasi dengan benar dan semua aplikasi yang CAnya perlu dimigrasikan memiliki lebih dari satu Pod yang berjalan.

8. Pastikan cluster sudah terdaftar ke fleet dan workload-identity diaktifkan di cluster. Kemudian, catat project ID armada sebagai (FLEET_ID) untuk langkah-langkah selanjutnya.

9. Alat ini menerima kubeConfig dan kubeContext untuk memilih cluster tempat operasi dijalankan. 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
     

Menginisialisasi CA baru

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

   Mesh CA

   Panggil sub-perintah initialize alat utilitas.

   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 menginisialisasi Certificate Authority Service. Catat CA_POOL.

   b. Panggil sub-perintah initialize alat utilitas:

   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 tingkat mesh untuk semua cluster dalam fleet

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

2. Download trustAnchors CA:

   Mesh 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 trustAnchors CA:

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

4. Pastikan bahwa trustAnchors telah diterima oleh semua workload di fleet. Dalam argumen namespace, teruskan semua namespace tempat beban kerja 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.

   Mesh 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 otomatis melakukan langkah ini selama upgrade terkelola.

   Untuk meminimalkan risiko periode nonaktif traffic TLS, langkah ini harus memengaruhi sejumlah kecil workload terlebih dahulu. Hanya mulai ulang beban kerja yang terkait dengan revisi bidang kontrol ASM_REVISION. Misalnya, jika semua workload di namespace kubernetes NAMESPACE dikaitkan dengan bidang kontrol Anthos Service Mesh yang sama.

   kubectl rollout restart deployment -n NAMESPACE
   

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

4. Pastikan konfigurasi CA baru sedang digunakan oleh semua beban kerja:

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

Menjalankan rollback

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

   ./migrate-ca rollback
   

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

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opsional) Pastikan konfigurasi CA lama sedang 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 di tempat.