Untuk melakukan rilis canary di seluruh rantai panggilan atau menerapkan isolasi versi, gunakan traffic lanes dalam strict mode guna mengisolasi versi terkait (atau atribut lainnya) dari suatu aplikasi dalam lingkungan runtime independen. Pendekatan ini memastikan hanya traffic yang memenuhi kondisi tertentu yang dialihkan ke versi layanan baru, sehingga meningkatkan stabilitas dan kontrol proses rilis Anda.
Prasyarat
-
Anda telah membuat instans ASM Edisi Perusahaan atau Edisi Ultimate versi 1.18.2.111 atau lebih baru. Untuk informasi lebih lanjut, lihat Create an ASM instance atau Upgrade an ASM instance.
CatatanJika versi instans Anda adalah 1.17.2.22 atau lebih baru tetapi sebelum 1.18.2.111, lihat Use the traffic management feature in lane mode.
-
Anda telah membuat gerbang masuk ASM bernama ingressgateway. Untuk informasi lebih lanjut, lihat Create an ingress gateway service.
-
Anda telah membuat gateway bernama ingressgateway di namespace istio-system. Untuk informasi lebih lanjut, lihat Manage gateways.
Contoh
Contoh ini menggunakan tiga layanan (mocka, mockb, dan mockc) untuk membuat tiga jalur (s1, s2, dan s3) yang merepresentasikan tiga versi rantai panggilan layanan.
Langkah 1: Deploy layanan sampel
-
Aktifkan injeksi otomatis proxy sidecar untuk namespace default. Untuk detailnya, lihat Enable automatic sidecar proxy injection.
Untuk informasi lebih lanjut tentang injeksi otomatis, lihat Configure sidecar injection policies.
-
Jalankan perintah berikut di kluster Container Service for Kubernetes (ACK) Anda untuk mendeploy layanan sampel:
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-tracing-v1.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-tracing-v2.yaml kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-tracing-v3.yaml
Langkah 2: Buat grup swimlane dan swimlane
-
Buat grup swimlane.
-
Masuk ke Konsol ASM. Di panel navigasi kiri, pilih .
-
Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi kiri, pilih .
-
Pada halaman Traffic Lane, klik Create Swimlane Group. Pada panel Create Swimlane Group, konfigurasikan parameter dan klik OK.
Parameter
Deskripsi
Name of swim lane group
Untuk contoh ini, masukkan test.
Entrance gateway
Pilih ingressgateway.
Lane Mode
Pilih Strict Mode.
Swimlane service
Pilih kluster Kubernetes target dan namespace default. Di daftar di bawah, pilih layanan mocka, mockb, dan mockc, lalu klik ikon
untuk menambahkannya ke bagian selected.
-
-
Buat swimlane s1, s2, dan s3 serta bind-kan ke versi v1, v2, dan v3, masing-masing.
-
Di bagian Traffic Lane pada halaman Traffic Rule Definition, klik Create swimlanes.
-
Pada kotak dialog Create swimlanes, konfigurasikan parameter dan klik OK.
Parameter
Deskripsi
Swimlane Name
Tetapkan nama swimlane menjadi s1, s2, dan s3.
Configure Service Tag
Label Key: Pilih ASM_TRAFFIC_TAG.
Label Value: Pilih v1, v2, dan v3 untuk swimlane s1, s2, dan s3, masing-masing.
Setelah ketiga swimlane dibuat, setiap swimlane berisi layanan swimlane
mocka,mockb, danmockc.Setelah Anda membuat swimlane, ASM secara otomatis membuat DestinationRule dan VirtualService yang sesuai untuk setiap layanan dalam grup swimlane. Untuk melihat sumber daya ini, navigasikan ke atau VirtualService di panel navigasi kiri.
-
-
Buat aturan traffic ingress untuk setiap swimlane.
-
Di bagian Traffic Lane pada halaman Traffic Rule Definition, temukan swimlane target dan klik Ingress traffic rules di kolom Actions.
-
Pada kotak dialog Add drainage rule, konfigurasikan parameter dan klik OK.
Dalam contoh ini, URI ingress untuk layanan swimlane adalah
/mock. Oleh karena itu, Anda mengonfigurasi aturan traffic ingress yang sama untuk setiap swimlane.Parameter
Deskripsi
Ingress service
Pilih mocka.default.svc.cluster.local.
Ingress traffic rules
Tetapkan Name menjadi r1 dan Domain Name menjadi *.
Matching request URI
Tetapkan Method menjadi Exact dan Content menjadi /mock.
Add Header Matching Rule
Klik Add Header Matching Rule. Tetapkan Name menjadi x-asm-prefer-tag dan Method menjadi Exact. Untuk ketiga swimlane, tetapkan Content menjadi s1, s2, dan s3, masing-masing.
Setelah Anda membuat aturan traffic ingress, halaman Traffic Rule Definition diperbarui. Swimlane sekarang diberi label s1, s2, dan s3, dan layanan swimlane (mocka, mockb, dan mockc) diaktifkan untuk semua swimlane.
Setelah Anda membuat aturan tersebut, VirtualService yang menerapkan aturan traffic ingress secara otomatis dibuat untuk setiap swimlane.
-
Langkah 3: Verifikasi peluncuran kanari ujung ke ujung
-
Dapatkan Alamat IP publik gerbang masuk ASM. Untuk informasi lebih lanjut, lihat Get the ASM ingress gateway address.
-
Jalankan perintah berikut untuk menetapkan variabel lingkungan.
Ganti
xxx.xxx.xxx.xxxdengan alamat IP dari langkah sebelumnya.export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx -
Verifikasi bahwa peluncuran kanari ujung ke ujung berfungsi sesuai harapan.
-
Jalankan perintah berikut untuk menguji routing ke jalur s1.
Nilai
s1untukx-asm-prefer-tagmenentukan jalur s1 yang Anda konfigurasi di Langkah 2.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)Output menunjukkan bahwa permintaan dengan Header HTTP
x-asm-prefer-tag: s1dialihkan ke layanan di jalur s1. -
Jalankan perintah berikut untuk menguji routing ke jalur s2.
Nilai
s2untukx-asm-prefer-tagmenentukan jalur s2 yang Anda konfigurasi di Langkah 2.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)Output menunjukkan bahwa permintaan dengan Header HTTP
x-asm-prefer-tag: s2dialihkan ke layanan di jalur s2. -
Jalankan perintah berikut untuk menguji routing ke jalur s3.
Nilai
s3untukx-asm-prefer-tagmenentukan jalur s3 yang Anda konfigurasi di Langkah 2.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)Output menunjukkan bahwa permintaan dengan Header HTTP
x-asm-prefer-tag: s3dialihkan ke layanan di jalur s3.
-
Routing traffic dengan virtual service kustom
Fitur traffic lane mencakup kemampuan bawaan untuk mengonfigurasi aturan routing permintaan. Saat Anda membuat aturan ini, ASM secara otomatis menghasilkan virtual service yang sesuai pada gerbang masuk. Hal ini memungkinkan gerbang masuk untuk mengarahkan permintaan ke jalur traffic yang berbeda.
Aturan routing permintaan untuk jalur traffic mencocokkan permintaan berdasarkan header permintaan dan path permintaan. Untuk menerapkan kondisi pencocokan yang lebih kompleks atau perilaku routing kustom, Anda dapat membuat virtual service kustom.
Saat Anda menggunakan virtual service kustom untuk mengarahkan traffic ke jalur traffic, hindari membuat aturan routing permintaan bawaan untuk jalur traffic yang sama. Virtual service kustom dapat bertentangan dengan aturan bawaan dan menyebabkan distribusi traffic yang tidak terduga atau salah.
Buat virtual service untuk gateway ASM
-
Untuk melanjutkan skenario contoh, alih-alih menyelesaikan Langkah 2.3, Create request routing rules for the three traffic lanes, buat virtual service dengan konfigurasi berikut. Untuk informasi lebih lanjut, lihat Manage virtual services.
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: swimlane-ingress-vs-custom namespace: istio-system spec: gateways: - istio-system/ingressgateway hosts: - '*' http: - match: # Aturan ini mencocokkan permintaan dengan header tepat 'env: dev'. - headers: env: exact: dev name: dev-route route: - destination: host: mocka.default.svc.cluster.local # Layanan tujuan untuk traffic. subset: s2 # Tetapkan 'subset' ke nama jalur traffic. weight: 50 - destination: host: mocka.default.svc.cluster.local # Layanan tujuan untuk traffic. subset: s3 # Tetapkan 'subset' ke nama jalur traffic. weight: 50 - name: base-route route: - destination: host: mocka.default.svc.cluster.local # Layanan tujuan untuk traffic. subset: s1 # Tetapkan 'subset' ke nama jalur traffic. -
Jalankan perintah dari Langkah 3: Verify the end-to-end canary release. Output yang diharapkan saat mengakses jalur traffic s1, s2, dan s3 adalah sebagai berikut:
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)Jalankan perintah berikut untuk memverifikasi perilaku saat mengakses jalur traffic s1 dengan header permintaan
env: dev.for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H 'env: dev' http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Output yang diharapkan:
Output menunjukkan bahwa untuk permintaan yang menyertakan header
env: dev, traffic dibagi kira-kira 50/50 antara jalur traffic s2 dan s3. Semua permintaan lainnya dialihkan ke jalur traffic s1.
Virtual service di atas mendefinisikan aturan routing kustom pada gateway ASM untuk meneruskan traffic ke jalur traffic yang berbeda. Saat Anda menggunakan virtual service kustom untuk mengarahkan traffic ke jalur traffic dalam strict mode, Anda hanya perlu menentukan nama jalur traffic target di bidang subset tujuan routing. Setelah permintaan memasuki jalur traffic, semua panggilan berikutnya dalam rantai permintaan tetap berada dalam jalur traffic tersebut.
Buat virtual service untuk sidecar
Selain mendefinisikan aturan pada gerbang masuk, Anda juga dapat membuat virtual service yang berlaku untuk semua sidecar. Hal ini memungkinkan Anda mendefinisikan aturan routing permintaan yang mengontrol cara layanan dalam kluster mengakses layanan lain di jalur traffic. Berbeda dengan virtual service untuk gateway, virtual service berbasis sidecar menghilangkan bidang gateway, dan bidang hosts menentukan FQDN layanan mocka dalam kluster. Berikut adalah contoh YAML-nya:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: swimlane-ingress-vs-custom
namespace: istio-system
spec:
hosts:
- mocka.default.svc.cluster.local
http:
- match: # Aturan ini mencocokkan permintaan dengan header tepat 'env: dev'.
- headers:
env:
exact: dev
name: dev-route
route:
- destination:
host: mocka.default.svc.cluster.local # Layanan tujuan untuk traffic.
subset: s2 # Tetapkan 'subset' ke nama jalur traffic.
weight: 50
- destination:
host: mocka.default.svc.cluster.local # Layanan tujuan untuk traffic.
subset: s3 # Tetapkan 'subset' ke nama jalur traffic.
weight: 50
- name: base-route
route:
- destination:
host: mocka.default.svc.cluster.local # Layanan tujuan untuk traffic.
subset: s1 # Tetapkan 'subset' ke nama jalur traffic.
-
Jalankan perintah berikut untuk memverifikasi perilaku saat mengakses layanan mocka dari sidecar tanpa header permintaan
env: dev.kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl http://mocka:8000; echo ""; sleep 1; done;'Output yang diharapkan:
-> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)Output menunjukkan bahwa tanpa header permintaan
env: dev, semua permintaan mengikuti rantai panggilan v1, yang mengonfirmasi bahwa traffic dialihkan ke jalur traffic s1. -
Jalankan perintah berikut untuk memverifikasi perilaku saat permintaan menyertakan header permintaan
env: dev.kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;'Output yang diharapkan:
Output ini konsisten dengan hasil dari virtual service berbasis gateway. Saat Anda mengakses layanan mocka dengan header permintaan
env: dev, traffic dibagi kira-kira 50/50 antara jalur traffic s2 dan s3.
Ini bekerja dengan prinsip yang sama seperti virtual service berbasis gateway. Saat layanan lain dalam kluster memanggil layanan mocka, seluruh rantai permintaan berikutnya tetap berada dalam jalur traffic yang dipilih.
Dokumentasi terkait
-
Jalur traffic memiliki dua mode: strict dan permissive. Untuk perbandingan kedua mode tersebut, lihat Traffic lane overview.
-
Mode permissive memberikan fleksibilitas lebih besar untuk jalur traffic, terutama saat aplikasi Anda menggunakan header permintaan pass-through dalam jejak. Misalnya, Anda dapat membuat Lingkungan pengujian yang mencakup versi baru hanya beberapa layanan dalam jejak. Untuk detailnya, lihat Use permissive mode traffic lanes for end-to-end traffic management.
-
Anda dapat menerapkan jalur traffic menggunakan aturan traffic seperti VirtualService dan DestinationRule. Anda juga dapat mengonfigurasi traffic shifting untuk mengarahkan traffic ke aplikasi fallback yang ditentukan saat aplikasi versi tertentu (atau dengan karakteristik lainnya) tidak tersedia. Untuk informasi lebih lanjut, lihat Configure traffic lanes and traffic shifting using traffic rules.