Gunakan traffic lane untuk canary release end-to-end-Alibaba Cloud Service Mesh-Alibaba Cloud

Jalur lalu lintas (traffic lanes) mengisolasi versi layanan tertentu ke dalam lingkungan runtime independen dan mengarahkan permintaan yang sesuai melalui seluruh rantai panggilan—tanpa perubahan kode aplikasi. Fitur ini memungkinkan peluncuran kanari ujung ke ujung secara simultan di beberapa layanan.

Mengapa menggunakan jalur lalu lintas

Penerapan kanari Kubernetes standar menggabungkan distribusi traffic dengan jumlah replika: mengirimkan 10% traffic ke kanari memerlukan 1 replika kanari bersama 9 replika stabil. Pendekatan ini tidak efektif dalam dua skenario berikut:

Rantai panggilan multi-layanan. Permintaan yang mengalir melalui layanan A, B, dan C membutuhkan routing versi yang konsisten di setiap hop. Kubernetes tidak menyediakan mekanisme bawaan untuk hal ini.
Scaling independen. Dengan jalur lalu lintas, distribusi traffic dan jumlah replika sepenuhnya dipisahkan. Satu replika kanari menerima persentase traffic yang Anda tentukan, terlepas dari jumlah replika stabil yang sedang berjalan.

Jalur lalu lintas ASM mengatasi kedua masalah tersebut dengan memberi tag permintaan di gerbang masuk (ingress gateway) dan menyebarkan tag tersebut di seluruh rantai panggilan.

Cara kerja

Konfigurasi jalur lalu lintas melalui Konsol akan menghasilkan tiga resource Istio secara otomatis:

Resource	Tujuan
TrafficLabel	Menetapkan label ke setiap permintaan berdasarkan label pod `ASM_TRAFFIC_TAG`
DestinationRule	Memetakan nama lane ke subset versi layanan
VirtualService	Mengarahkan permintaan ke subset yang tepat berdasarkan Header `x-asm-prefer-tag` dan URI

Alur routing:

Permintaan tiba di ingress gateway dengan header x-asm-prefer-tag: <lane-name>.
VirtualService mencocokkan header dan URI, lalu mengarahkan permintaan ke subset layanan pertama yang sesuai.
TrafficLabel menyebarkan tag jalur melalui panggilan layanan-ke-layanan berikutnya, sehingga permintaan tetap berada dalam jalur yang sama sepanjang rantai panggilan.

Ikhtisar skenario

Tutorial ini menerapkan tiga jalur (s1, s2, s3), masing-masing berisi tiga layanan (mocka, mockb, mockc) yang diikat ke versi berbeda:

Lane	Tag layanan	Layanan
s1	v1	mocka, mockb, mockc
s2	v2	mocka, mockb, mockc
s3	v3	mocka, mockb, mockc

Setelah pengaturan selesai, permintaan dengan x-asm-prefer-tag: s1 hanya mengalir melalui v1 dari ketiga layanan tersebut, permintaan dengan s2 mengalir melalui v2, dan permintaan dengan s3 mengalir melalui v3.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Instans ASM Edisi Perusahaan atau Edisi Ultimate, versi 1.17.2.22 atau lebih baru. Untuk informasi lebih lanjut, lihat Create an ASM instance atau Update an ASM instance
Kluster yang ditambahkan ke instans ASM. Untuk informasi lebih lanjut, lihat Add a cluster to an ASM instance
Gateway ASM bernama ingressgateway. Untuk informasi lebih lanjut, lihat Create an ingress gateway service
Gateway Istio bernama ingressgateway di namespace istio-system. Untuk informasi lebih lanjut, lihat Manage Istio gateways

Contoh YAML Gateway

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway        # Match the ASM ingress gateway
  servers:
    - port:
        number: 80               # Listen on port 80
        name: http
        protocol: HTTP
      hosts:
        - '*'                    # Accept traffic for all hosts

Langkah 1: Terapkan layanan contoh

Aktifkan injeksi proxy sidecar otomatis

Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.
Di halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih ASM Instance > Global Namespace.
Di halaman Global Namespace, temukan namespace default dan klik Enable Automatic Sidecar Injection di kolom Automatic Sidecar Injection. Di pesan Submit, klik OK.

Untuk informasi lebih lanjut, lihat Enable automatic sidecar proxy injection.

Terapkan layanan

Terapkan v1, v2, dan v3 layanan contoh di kluster ACK:

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 grup jalur dan jalur

Buat grup jalur

Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.
Di halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Traffic Management Center > Traffic Lane.
Di halaman Traffic Lane, klik Create Swimlane Group. Di panel Create Swimlane Group, konfigurasikan parameter berikut dan klik OK.

Parameter	Nilai
Name of swim lane group	`test`
Entrance gateway	`ingressgateway`
Swimlane Services	Pilih kluster ACK dari daftar drop-down Kubernetes Clusters dan pilih default dari daftar drop-down Namespace. Pilih mocka, mockb, dan mockc di daftar layanan, lalu klik ikon untuk menambahkannya ke bagian selected

Setelah membuat grup jalur, ASM menghasilkan resource TrafficLabel:

YAML TrafficLabel yang Dihasilkan

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  labels:
    asm-system: 'true'
    provider: asm
  name: asm-trafficlabel-global
  namespace: istio-system
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - $getLabel(ASM_TRAFFIC_TAG)   # Reads the ASM_TRAFFIC_TAG label from each pod

Buat jalur

Buat tiga jalur (s1, s2, s3) dan ikat masing-masing ke versi layanan yang sesuai. Langkah-langkah berikut menunjukkan cara membuat jalur s1. Ulangi proses yang sama untuk s2 (tag layanan: v2) dan s3 (tag layanan: v3).

Di bagian Traffic Rule Definition halaman Traffic Lane, klik Create swimlanes.
Di kotak dialog Create swimlanes, konfigurasikan parameter berikut dan klik OK.

Parameter	Nilai
Swimlane Name	`s1`
Configure Service Tag	`v1`
Add Service	Pilih mocka(default), mockb(default), dan mockc(default)

Catatan

Permintaan dengan header x-asm-prefer-tag: s1 diarahkan ke subset v1 dari setiap layanan.

Setelah membuat ketiga jalur, bagian Traffic Rule Definition menampilkannya sebagai berikut:

Pembuatan setiap jalur menghasilkan DestinationRule. Contoh berikut menunjukkan DestinationRule untuk jalur s1:

YAML DestinationRule yang Dihasilkan (jalur s1)

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test                              # Belongs to the "test" lane group
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local               # Target service
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1                            # Lane s1 maps to version v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: v1
    - labels:
        ASM_TRAFFIC_TAG: v2                            # Lane s2 maps to version v2
      name: v2
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2
    - labels:
        ASM_TRAFFIC_TAG: v3                            # Lane s3 maps to version v3
      name: v3
    - labels:
        ASM_TRAFFIC_TAG: v3
      name: s3

Buat aturan traffic masuk

Buat aturan routing traffic untuk setiap jalur. Langkah-langkah berikut menunjukkan cara membuat aturan untuk jalur s1. Ulangi proses yang sama untuk s2 dan s3.

Contoh ini mengasumsikan semua layanan jalur berbagi path permintaan inbound /mock.

Di bagian Traffic Rule Definition halaman Traffic Lane, temukan jalur target dan klik Ingress traffic rules di kolom Actions.
Di kotak dialog Add drainage rule, konfigurasikan parameter berikut dan klik OK.

Parameter	Nilai
Ingress service	`mocka.default.svc.cluster.local`
Ingress traffic rules	Name: `r1`, realm name: `*`
Matching request URI	Method: Exact, Content: `/mock`

Setelah membuat aturan routing traffic untuk ketiga jalur, bagian Traffic Rule Definition menampilkannya sebagai berikut:

ASM menghasilkan VirtualService yang mengarahkan permintaan berdasarkan header x-asm-prefer-tag:

YAML VirtualService yang Dihasilkan

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    istioGateway: ingressgateway
    provider: asm
  name: ingressgateway
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway                      # Bind to the ingress gateway
  hosts:
    - '*'                                              # Match all hosts
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s1                                # Match requests tagged for lane s1
          uri:
            exact: /mock                               # Match the /mock path
      name: swimelane-ingress-route-test-s1-rule1
      route:
        - destination:
            host: mocka.default.svc.cluster.local      # Route to mocka
            subset: s1                                 # Use the s1 subset (version v1)
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2                                # Match requests tagged for lane s2
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s2-rule2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2                                 # Use the s2 subset (version v2)
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s3                                # Match requests tagged for lane s3
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s3-rule3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3                                 # Use the s3 subset (version v3)

Langkah 3: Verifikasi peluncuran kanari ujung ke ujung

Dapatkan alamat IP gateway

Dapatkan alamat IP publik dari ingress gateway ASM. Untuk detailnya, lihat Langkah 2 di Integrate the cloud-native inference service KServe with ASM.

Tetapkan alamat IP sebagai variabel lingkungan. Ganti <gateway-ip-address> dengan alamat IP publik yang sebenarnya.

export ASM_GATEWAY_IP=<gateway-ip-address>

Uji setiap jalur

Kirimkan 100 permintaan ke setiap jalur dan verifikasi bahwa traffic tetap berada dalam versi layanan yang diharapkan.

Jalur s1 (diharapkan: semua v1):

for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' 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)

Ketiga layanan mengembalikan v1, yang mengonfirmasi bahwa permintaan dengan tag x-asm-prefer-tag: s1 hanya diarahkan melalui jalur s1.

Jalur s2 (diharapkan: semua v2):

for i in {1..100}; do curl -H 'x-asm-prefer-tag: s2' 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)

Jalur s3 (diharapkan: semua v3):

for i in {1..100}; do curl -H 'x-asm-prefer-tag: s3' 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)

Pemecahan masalah routing

Jika ada permintaan yang mengembalikan versi yang tidak sesuai, periksa hal berikut:

Gejala	Kemungkinan penyebab	Resolusi
Respons menunjukkan versi salah	`ASM_TRAFFIC_TAG` tidak sesuai dengan tag layanan yang dikonfigurasi untuk jalur tersebut	Verifikasi label pod dengan `kubectl get pods --show-labels` dan pastikan sesuai dengan konfigurasi jalur
Tidak ada respons atau 404	Rute VirtualService tidak cocok dengan nilai header `x-asm-prefer-tag` atau URI	Periksa YAML VirtualService untuk mengonfirmasi aturan pencocokan header dan path URI
Traffic bocor antar-jalur	Subset DestinationRule tidak memetakan nama jalur ke label versi dengan benar	Periksa YAML DestinationRule dan verifikasi setiap subset memetakan nilai `ASM_TRAFFIC_TAG` yang benar
Kegagalan routing intermiten	Proxy sidecar tidak diinjeksikan pada beberapa pod	Jalankan `kubectl get pods -o jsonpath='{.items[].spec.containers[].name}'` untuk mengonfirmasi kontainer `istio-proxy` ada di semua pod

(Opsional) Langkah 4: Periksa topologi mesh

Jika Mesh Topology diaktifkan di Konsol ASM, periksa graf topologi untuk memvisualisasikan jalur permintaan di berbagai jalur. Untuk informasi lebih lanjut, lihat Enable Mesh Topology to observe an ASM instance in the ASM console.

Langkah selanjutnya

Label traffic — Pelajari lebih lanjut tentang konsep pelabelan traffic dan konfigurasi lanjutan