cara mengimplementasikan jalur lalu lintas dan degradasi traffic berdasarkan konfigurasi aturan traffic - Alibaba Cloud Service Mesh

Saat beberapa layanan mikro dirilis secara bersamaan, setiap versi layanan harus diuji sebagai rantai panggilan lengkap tanpa memengaruhi traffic produksi. Jalur lalu lintas mengisolasi rantai panggilan layanan yang diberi versi ke dalam lingkungan runtime independen sehingga permintaan yang masuk ke suatu jalur tetap berada dalam versi tersebut dari ujung ke ujung. Jika suatu versi dalam jalur menjadi tidak tersedia, pengalihan traffic mengarahkan permintaan ke versi fallback yang ditentukan untuk mencegah gangguan.

Langkah-langkah berikut mencakup penyiapan lengkap di Service Mesh (ASM): mendefinisikan subset versi dengan DestinationRules, merutekan traffic antar-layanan berdasarkan versi dengan VirtualServices, mengarahkan traffic ingress ke jalur tertentu melalui Header HTTP, dan mengonfigurasi fallback saat target jalur tidak tersedia.

Cara kerja jalur lalu lintas

Jalur lalu lintas dibangun dari tiga primitif manajemen traffic Istio:

Primitif	Peran dalam jalur lalu lintas
DestinationRule	Mendeklarasikan subset versi (v1, v2, v3) untuk setiap layanan berdasarkan label pod. Mendefinisikan versi mana saja yang ada.
VirtualService	Merutekan traffic antar-layanan berdasarkan `sourceLabels`, menjaga permintaan tetap berada dalam jalur versi yang sama. Mendefinisikan kemana traffic dialihkan.
Gateway + VirtualService	Merutekan traffic ingress ke jalur yang tepat berdasarkan Header HTTP (`x-asm-prefer-tag`). Berfungsi sebagai titik masuk ke dalam suatu jalur.

Diagram berikut menunjukkan tiga jalur, masing-masing berisi rantai panggilan lengkap v1, v2, atau v3:

                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v1: mocka v1 → mockb v1 → mockc v1  │
  v1                └─────────────────────────────────────┘
                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v2: mocka v2 → mockb v2 → mockc v2  │
  v2                └─────────────────────────────────────┘
                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v3: mocka v3 → mockb v3 → mockc v3  │
  v3                └─────────────────────────────────────┘

Traffic shifting menambahkan mekanisme fallback: jika versi layanan dalam suatu jalur tidak tersedia, ASM mengalihkan traffic ke versi fallback yang ditentukan (biasanya v1).

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Instans ASM Edisi Perusahaan atau Edisi Ultimate versi 1.17 atau lebih baru. Lihat Buat instans ASM atau Perbarui instans ASM.
Kluster Kubernetes yang ditambahkan ke instans ASM. Lihat Tambahkan kluster ke instans ASM.
Gerbang ASM bernama ingressgateway. Lihat Buat gerbang ingress.

Langkah 1: Deploy layanan contoh

Tutorial ini menggunakan tiga layanan contoh — mocka, mockb, dan mockc — masing-masing di-deploy dalam tiga versi (v1, v2, v3). Rantai panggilan mengalir dari mocka ke mockb lalu ke mockc.

Aktifkan injeksi proxy sidecar otomatis untuk namespace default. Untuk detailnya, lihat bagian "Aktifkan injeksi sidecar otomatis" pada topik Kelola namespace global, atau lihat Aktifkan injeksi proxy sidecar otomatis.

Deploy layanan contoh menggunakan file kubeconfig kluster pada bidang data:

   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml

Langkah 2: Definisikan subset versi dengan DestinationRules

DestinationRules mendeklarasikan subset versi yang tersedia untuk setiap layanan. Setiap subset dipetakan ke pod dengan label version yang sesuai.

Buat file bernama dr-mock.yaml dengan konten berikut: Bidang utama:

Bidang	Deskripsi
`namespace: istio-system`	Diterapkan di namespace lapisan kontrol ASM, bukan namespace aplikasi.
`host`	Nama layanan lengkap, seperti `mocka.default.svc.cluster.local`.
`subsets[].labels.version`	Sesuai dengan label `version` pada pod yang di-deploy di Langkah 1.

Tampilkan dr-mock.yaml

   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mocka
     namespace: istio-system
   spec:
     host: mocka.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     host: mockb.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     host: mockc.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3

Terapkan DestinationRule menggunakan file kubeconfig instans ASM:
```
   kubectl apply -f dr-mock.yaml
```

Langkah 3: Rutekan traffic dalam jalur menggunakan VirtualServices

VirtualServices merutekan traffic antar-layanan berdasarkan sourceLabels, menjaga permintaan tetap berada dalam jalur versi yang sama. Saat mocka v2 memanggil mockb, VirtualService mencocokkan label sumber version: v2 dan merutekan permintaan ke mockb v2.

Buat file bernama vs-mock.yaml dengan konten berikut: Bidang utama: Aturan routing dievaluasi dari atas ke bawah. Kecocokan pertama yang ditemukan akan digunakan.

Bidang	Deskripsi
`sourceLabels`	Mencocokkan label `version` pada pod pemanggil. Pemanggil v2 hanya dapat mencapai tujuan v2, sehingga traffic tetap berada dalam jalur tersebut.
`subset`	Mereferensikan nama subset yang didefinisikan dalam DestinationRule (Langkah 2).

Tampilkan vs-mock.yaml

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     hosts:
       - mockb.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v2
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v3
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     hosts:
       - mockc.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v2
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v3

Terapkan VirtualService menggunakan file kubeconfig instans ASM:
```
   kubectl apply -f vs-mock.yaml
```

Langkah 4: Rutekan traffic ingress ke jalur melalui Header HTTP

Gateway dan VirtualService tingkat gateway mengarahkan permintaan masuk ke jalur yang tepat berdasarkan header HTTP x-asm-prefer-tag. Selama pengujian canary, insinyur QA atau pipeline CI/CD menambahkan x-asm-prefer-tag: v2 ke permintaan pengujian, sehingga permintaan tersebut diarahkan ke jalur v2 sementara traffic produksi tetap mengalir ke v1.

Buat file bernama gw-mock.yaml dengan konten berikut: Bidang utama:

Bidang	Deskripsi
`selector: istio: ingressgateway`	Mengikat Gateway ke pod gerbang ingress ASM.
`x-asm-prefer-tag`	Menentukan jalur mana yang menerima permintaan. Nilainya harus persis sesuai dengan versi (v1, v2, atau v3).
`uri: exact: /mock`	Header dan URI harus cocok agar rute diterapkan.

Tampilkan gw-mock.yaml

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 80
           name: http
           protocol: HTTP
         hosts:
           - '*'
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     gateways:
       - istio-system/ingressgateway
     hosts:
       - '*'
     http:
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v1
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v1
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v2
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v2
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v3
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v3

Terapkan Gateway dan aturan routing menggunakan file kubeconfig instans ASM:
```
   kubectl apply -f gw-mock.yaml
```

Langkah 5: Verifikasi jalur lalu lintas

Dapatkan Alamat IP publik gerbang ASM. Untuk detailnya, lihat Langkah 2 di Integrasikan KServe dengan ASM.
Tetapkan IP gateway sebagai variabel lingkungan. Ganti xxx.xxx.xxx.xxx dengan alamat IP aktual:
```
   export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```

Kirim permintaan pengujian ke setiap jalur dan verifikasi bahwa traffic tetap berada dalam versi yang benar. Uji jalur v1: Output yang diharapkan: Ketiga layanan merespons dengan versi v1, mengonfirmasi bahwa traffic tetap berada dalam jalur v1. Uji jalur v2: Output yang diharapkan: Uji jalur v3: Output yang diharapkan: Setiap jalur merutekan traffic secara eksklusif ke layanan dengan versi yang sesuai, mengonfirmasi bahwa isolasi jalur berfungsi dengan benar.

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)

Langkah 6: Tambahkan pengalihan traffic dengan fallback

Pengalihan traffic menambahkan ketahanan pada jalur lalu lintas. Dengan konfigurasi fallback, ASM mengalihkan traffic ke versi stabil (v1) saat versi target tidak tersedia, mencegah gangguan layanan selama rilis canary.

Ganti konten vs-mock.yaml dengan konfigurasi berikut. Ini menambahkan blok fallback ke rute v2 dan v3, mengarahkan traffic ke subset v1 saat versi target tidak dapat dijangkau: Bidang utama:

Bidang	Deskripsi
`fallback.target.host` dan `fallback.target.subset`	Tujuan fallback. Di sini, baik `mockb` maupun `mockc` fallback ke v1.
rute v1 (tanpa fallback)	v1 berfungsi sebagai garis dasar stabil, sehingga tidak memerlukan target fallback.
Fallback per-rute	Target fallback setiap versi dikonfigurasi secara independen.

Tampilkan vs-mock.yaml yang diperbarui

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     hosts:
       - mockb.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v2
         fallback:
           target:
             host: mockb.default.svc.cluster.local
             subset: v1
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v3
         fallback:
           target:
             host: mockb.default.svc.cluster.local
             subset: v1
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     hosts:
       - mockc.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v2
         fallback:
           target:
             host: mockc.default.svc.cluster.local
             subset: v1
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v3
         fallback:
           target:
             host: mockc.default.svc.cluster.local
             subset: v1

Terapkan VirtualService yang diperbarui menggunakan file kubeconfig instans ASM:
```
   kubectl apply -f vs-mock.yaml
```

Langkah 7: Verifikasi pengalihan traffic

Simulasikan kegagalan layanan untuk mengonfirmasi bahwa routing fallback berfungsi.

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, klik nama kluster target, lalu pilih Workloads > Deployments di panel navigasi kiri.
Di halaman Deployments, temukan workload mockb-v2 dan klik Scale di kolom Actions. Di kotak dialog Scale, atur Desired Number of Pods menjadi 1, lalu klik OK. Klik Confirm untuk menerapkan. Ini mensimulasikan kegagalan layanan mockb v2.
Kirim permintaan pengujian ke jalur v2: Output yang diharapkan: Permintaan masuk melalui mocka v2 (sesuai dengan header x-asm-prefer-tag: v2). Karena mockb v2 tidak tersedia, traffic dialihkan ke mockb v1, yang kemudian merutekan ke mockc v1 melalui jalur v1. Pengalihan traffic berfungsi sebagaimana diharapkan.
```
   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
```
   -> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.126)-> mockc(version: v1, ip: 172.17.0.128)
```

Bersihkan sumber daya

Untuk menghapus semua sumber daya yang dibuat dalam tutorial ini:

# Hapus aturan traffic (menggunakan kubeconfig ASM)
kubectl delete -f gw-mock.yaml
kubectl delete -f vs-mock.yaml
kubectl delete -f dr-mock.yaml

# Hapus layanan contoh (menggunakan kubeconfig kluster)
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml