Gunakan aturan trafik untuk mengonfigurasi jalur lalu lintas dan pengalihan lalu lintas - Alibaba Cloud Service Mesh

Anda dapat mengonfigurasi aturan manajemen trafik, seperti layanan virtual dan aturan tujuan, untuk mengisolasi versi aplikasi atau aplikasi dengan karakteristik tertentu ke dalam lingkungan runtime independen yang dikenal sebagai jalur. Permintaan trafik yang memenuhi aturan akan diarahkan ke versi tujuan atau aplikasi dengan karakteristik tertentu. Selain itu, Anda dapat mengonfigurasi pengalihan trafik untuk mengarahkan trafik ke versi dengan prioritas lebih rendah ketika versi tujuan tidak tersedia. Topik ini menjelaskan cara menggunakan aturan trafik untuk mengonfigurasi jalur lalu lintas dan pengalihan lalu lintas di Service Mesh (ASM).

Prasyarat

Sebuah instance ASM Edisi Enterprise atau Edisi Ultimate telah dibuat, dan instans tersebut adalah versi 1.17 atau lebih baru. Untuk informasi lebih lanjut, lihat Buat instance ASM atau Perbarui instance ASM.
Sebuah kluster Kubernetes telah ditambahkan ke instance ASM. Untuk informasi lebih lanjut, lihat Tambahkan kluster ke instance ASM.
Sebuah gateway ASM bernama ingressgateway telah dibuat. Untuk informasi lebih lanjut, lihat Buat gateway masuk.

Langkah 1: Sebarkan layanan contoh

Aktifkan injeksi proxy sidecar otomatis untuk namespace default. Untuk informasi lebih lanjut, lihat bagian "Aktifkan injeksi sidecar otomatis" dari topik Kelola namespace global.
Untuk informasi lebih lanjut, lihat Aktifkan injeksi proxy sidecar otomatis.

Jalankan perintah berikut untuk menerapkan layanan contoh menggunakan file kubeconfig kluster pada bidang data.

Dalam contoh ini, layanan mocka, mockb, dan mockc diterapkan, dan masing-masing dari tiga layanan memiliki tiga versi: v1, v2, dan v3.

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: Buat aturan trafik untuk menentukan jalur lalu lintas

Buat aturan tujuan.

Buat file bernama dr-mock.yaml dan salin konten berikut ke file tersebut.

Dalam contoh ini, masing-masing layanan mocka, mockb, dan mockc memiliki tiga subset: v1, v2, dan v3.

Tampilkan isi 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

Jalankan perintah berikut untuk menerapkan aturan tujuan menggunakan file kubeconfig instance ASM:
```
kubectl apply -f dr-mock.yaml
```

Buat layanan virtual.

Buat file bernama vs-mock.yaml dan salin konten berikut ke file tersebut.

Kode berikut membuat tiga jalur untuk tiga rantai panggilan layanan: mocka versi v1 ke mockb versi v1 lalu ke mockc versi v1, mocka versi v2 ke mockb versi v2 lalu ke mockc versi v2, dan mocka versi v3 ke mockb versi v3 lalu ke mockc versi v3. Dengan cara ini, permintaan dari layanan versi tertentu hanya dapat dikirim ke layanan dengan versi yang sama.

Tampilkan isi 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

Jalankan perintah berikut untuk menerapkan layanan virtual menggunakan file kubeconfig instance ASM:
```
kubectl apply -f vs-mock.yaml
```

Buat aturan pengalihan trafik di gateway.

Buat file bernama gw-mock.yaml dan salin konten berikut ke file tersebut.

Kode berikut membuat aturan pengalihan trafik untuk tiga rantai panggilan layanan. Gateway mengarahkan permintaan yang dikirim ke gateway ke versi v1, v2, atau v3 layanan mocka berdasarkan nilai header x-asm-prefer-tag dalam permintaan.

Tampilkan isi 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

Jalankan perintah berikut untuk menerapkan aturan pengalihan trafik menggunakan file kubeconfig instance ASM:
```
kubectl apply -f gw-mock.yaml
```

Langkah 3: Periksa apakah jalur lalu lintas berfungsi

Peroleh alamat IP publik gateway ASM. Untuk informasi lebih lanjut, lihat Langkah 2: Kueri alamat IP gateway masuk instance ASM dari topik Integrasikan layanan inferensi cloud-native KServe dengan ASM.
Jalankan perintah berikut untuk mengonfigurasi variabel lingkungan.
xxx.xxx.xxx.xxx adalah alamat IP yang diperoleh di sublangkah 1.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
Periksa apakah fitur rilis canary ujung-ke-ujung berfungsi.
1. Jalankan perintah berikut untuk memeriksa apakah jalur untuk layanan versi v1 berfungsi:
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Output yang diharapkan:
```
-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)
```
  Dalam output, trafik yang membawa header HTTP x-asm-prefer-tag: v1 mengalir ke layanan versi v1. Ini sesuai dengan harapan.
2. Jalankan perintah berikut untuk memeriksa apakah jalur untuk layanan versi v2 berfungsi:
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Output yang diharapkan:
```
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)
```
  Dalam output, trafik yang membawa header HTTP x-asm-prefer-tag: v2 mengalir ke layanan versi v2. Ini sesuai dengan harapan.
3. Jalankan perintah berikut untuk memeriksa apakah jalur untuk layanan versi v3 berfungsi:
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Output yang diharapkan:
```
-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)
```
  Dalam output, trafik yang membawa header HTTP x-asm-prefer-tag: v3 mengalir ke layanan versi v3. Ini sesuai dengan harapan.

Langkah 4: Konfigurasikan pengalihan lalu lintas di jalur lalu lintas

Salin konten berikut ke vs-mock.yaml untuk memodifikasi file tersebut.

Kode berikut membuat tiga jalur untuk tiga rantai panggilan layanan: mocka versi v1 ke mockb versi v1 lalu ke mockc versi v1, mocka versi v2 ke mockb versi v2 lalu ke mockc versi v2, dan mocka versi v3 ke mockb versi v3 lalu ke mockc versi v3. Selain itu, jika versi v2 atau v3 layanan mockb atau mockc tidak tersedia, permintaan dikirim ke versi v1 dari layanan yang sesuai.

Tampilkan isi 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
      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

Jalankan perintah berikut untuk memodifikasi layanan virtual asli dan menerapkan konfigurasi pengalihan lalu lintas menggunakan file kubeconfig instance ASM:
```
kubectl apply -f vs-mock.yaml
```

Langkah 5: Periksa apakah pengalihan lalu lintas berfungsi

Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.
Di halaman Clusters, temukan kluster yang diinginkan dan klik namanya. Di panel sisi kiri, pilih Workloads > Deployments.
Di halaman Deployments, temukan workload mockb-v2 dan klik Scale di kolom Actions. Di kotak dialog Scale, atur Desired Number of Pods menjadi 1 dan klik OK. Di pesan OK, klik Confirm. Operasi ini mensimulasikan kegagalan versi v2 layanan mockb.
Jalankan perintah berikut untuk memeriksa apakah jalur untuk layanan versi v2 berfungsi:
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
Output yang diharapkan:
```
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.126)-> mockc(version: v1, ip: 172.17.0.128)
```
Dalam output, trafik yang membawa header HTTP x-asm-prefer-tag: v2 pertama-tama mengalir ke layanan versi v2. Kemudian, trafik yang seharusnya mengalir ke layanan mockb versi v2 dialihkan ke rantai panggilan dengan layanan mockb versi v1 karena layanan mockb versi v2 gagal. Pengalihan lalu lintas berfungsi.