Memigrasikan Istio ServiceEntry ke GCPBackend untuk Cloud Run

Halaman ini menunjukkan cara bermigrasi dari ServiceEntry ke GCPBackend, yang menunjukkan bagaimana kemampuan pengelolaan traffic Istio dapat memastikan transisi yang lancar dan aman.

Bermigrasi ke GCPBackend memberikan manfaat berikut:

  1. Kode aplikasi yang disederhanakan: Anda dapat menghilangkan kebutuhan untuk injeksi JWT IAM manual di aplikasi, sehingga mengurangi kompleksitas dan potensi error.
  2. Peningkatan keamanan: manfaatkan injeksi JWT IAM otomatis untuk komunikasi yang lebih aman antara GKE dan Cloud Run.
  3. Migrasi yang lancar: Manfaatkan pemisahan dan pencerminan traffic untuk memigrasikan traffic dengan aman tanpa mengganggu aplikasi.
  4. Pengelolaan yang ditingkatkan: Dapatkan manfaat dari konfigurasi dan pengelolaan yang disederhanakan.

Sebelum memulai

Bagian berikut mengasumsikan bahwa Anda telah:

  1. Cluster GKE dengan Cloud Service Mesh diaktifkan.
  2. Layanan Cloud Run sebagai Entri Layanan Istio.
  3. Mengonfigurasi resource GCPBackend.

Buat atau ubah VirtualService yang ada untuk menyertakan ServiceEntry dan GCPBackend sebagai tujuan

Anda dapat menggunakan pemisahan traffic untuk secara bertahap mengalihkan traffic dari ServiceEntry ke GCPBackend. Anda harus memulai dengan persentase kecil traffic yang diarahkan ke GCPBackend dan meningkatkannya secara bertahap sambil memantau masalah apa pun.

Contoh berikut menjelaskan migrasi 10% permintaan ke GCPBackend.

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

Dengan keterangan:

  • NAMESPACE adalah nama namespace.

Dalam contoh ini:

  • VIRTUAL_SERVICEE adalah cr-gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME adalah cr-service-entry.com.
  • GCP_BACKEND_HOSTNAME adalah =cr-gcpbackend.com.

(Opsional) Mengonfigurasi VirtualService untuk Pencerminan Traffic

Untuk lebih memastikan transisi yang lancar, Anda dapat mengonfigurasi duplikasi traffic untuk mengirim salinan traffic ke GCPBackend sambil tetap mengarahkan traffic ke ServiceEntry. Hal ini memungkinkan pengujian dan validasi konfigurasi GCPBackend tanpa memengaruhi alur traffic utama. Untuk informasi selengkapnya, lihat Istio Virtual Service API.

Memvalidasi fungsi

Lihat log aplikasi atau metrik Cloud Service Mesh untuk memeriksa rasio error permintaan ke $SERVICE_ENTRY_HOSTNAME. Tidak akan ada error.

Untuk menguji di luar aplikasi, Anda dapat men-deploy klien curl. Jika permintaan dirutekan ke CloudRun menggunakan GCPBackend API, permintaan tersebut tidak memerlukan token IAM yang secara eksplisit dilampirkan ke permintaan karena Cloud Service Mesh akan melampirkan token tersebut secara otomatis.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"

Output harus berupa respons HTTP 200 yang valid.