Service Mesh (ASM) memungkinkan Anda mendefinisikan aturan pengarahan permintaan kompleks secara fleksibel dengan membuat layanan virtual kustom. Aturan ini dapat digunakan bersama dengan jalur lalu lintas untuk mengimplementasikan manajemen lalu lintas yang komprehensif dan multidimensi, serta memaksimalkan observabilitas, operabilitas, dan pengalaman pengguna aplikasi. Topik ini menjelaskan cara membuat layanan virtual kustom untuk merutekan lalu lintas dalam mode permissif.
Dalam contoh ini, Anda dapat memodifikasi langkah-langkah di Skenario 1: Melewati ID jejak dalam jejak dan Skenario 2: Melewati header permintaan kustom dalam jejak untuk membuat layanan virtual kustom dan merutekan lalu lintas dalam mode permissif. Pastikan Anda telah membaca dan memahami topik Gunakan jalur lalu lintas dalam mode permissif untuk mengelola lalu lintas ujung ke ujung dan konten terkait.
Skenario
Konsol ASM menyediakan fitur pembuatan aturan pengarahan permintaan bawaan. Setelah Anda membuat layanan virtual pada gateway ingress ASM yang sesuai dengan jalur lalu lintas, aturan pengarahan permintaan dibuat untuk jalur tersebut. Dengan cara ini, gateway ingress ASM dapat meneruskan permintaan ke berbagai jalur lalu lintas.
Aturan pengarahan permintaan mencakup aturan pencocokan untuk header permintaan dan jalur permintaan. Anda dapat membuat layanan virtual kustom untuk menentukan aturan pencocokan yang lebih kompleks atau membuat rute permintaan kustom.
Saat menggunakan layanan virtual kustom untuk merutekan lalu lintas, kami sarankan agar Anda tidak menggunakan fitur pembuatan aturan pengarahan permintaan bawaan untuk jalur yang sama. Hal ini karena layanan virtual kustom mungkin bertentangan dengan aturan bawaan, yang dapat menyebabkan distribusi lalu lintas yang tidak normal atau tidak terduga.
Buat layanan virtual kustom pada gateway ingress ASM
Skenario 1: Melewati ID jejak dalam jejak adalah contohnya. Pada sublangkah 3 Buat aturan drainase untuk ketiga jalur dari Langkah 1, ubah langkah pembuatan aturan pengarahan lalu lintas menjadi langkah pembuatan layanan virtual menggunakan konten berikut. Untuk informasi lebih lanjut, lihat Kelola layanan virtual.
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 pencocokan ini cocok persis dengan header permintaan env: dev. - headers: env: exact: dev name: dev-route route: - destination: host: mocka.default.svc.cluster.local # Layanan tujuan untuk penerusan lalu lintas. subset: s2 # Nama jalur lalu lintas. weight: 50 headers: request: set: x-asm-prefer-tag: s2 # Konfigurasikan header pengarahan permintaan untuk jalur lalu lintas. - destination: host: mocka.default.svc.cluster.local # Layanan tujuan untuk penerusan lalu lintas. subset: s3 # Nama jalur lalu lintas. fallback: target: host: mocka.default.svc.cluster.local subset: s1 weight: 50 headers: request: set: x-asm-prefer-tag: s3 # Konfigurasikan header pengarahan permintaan untuk jalur lalu lintas. - name: base-route route: - destination: host: mocka.default.svc.cluster.local # Layanan tujuan untuk penerusan lalu lintas. subset: s1 # Nama jalur lalu lintas. headers: request: set: x-asm-prefer-tag: s1 # Konfigurasikan header pengarahan permintaan untuk jalur lalu lintas.CatatanSaat membuat layanan virtual kustom, nilai
headers.request.setdalam file YAML harus sesuai dengan header pengarahan permintaan. Sebagai contoh, dalam Skenario 2: Melewati header permintaan kustom dalam jejak, header pass-through ujung ke ujung sama dengan header pengarahan permintaan. Oleh karena itu, nilaiheaders.request.setdi bawah bidangrouteyang sesuai diubah menjadimy-trace-id: s1,my-trace-id: s2, danmy-trace-id: s3, masing-masing.Jalankan perintah dalam Langkah 3: Verifikasi bahwa fitur rilis canary ujung ke ujung berlaku. Output berikut dihasilkan saat Anda mengakses layanan di jalur s1, s2, dan s3:
-> 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 memeriksa hasil saat Anda mengakses layanan di jalur s1 dengan header permintaan
env: dev:for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' -H 'env: dev' -H'my-trace-id: x000'$i http://${ASM_GATEWAY_IP}/mock ; echo ''; sleep 1; done;Output yang diharapkan:
Output tersebut menunjukkan bahwa saat Anda mengakses layanan di jalur s1 dengan header permintaan
env: dev, dua jenis jejak v1->v3->v1 dan v2->v1->v2 terlibat, dengan rasio permintaan sekitar 50:50. Artinya, permintaan dengan header permintaanenv: devdirutekan ke jalur s2 dan s3 dengan rasio 50:50, dan permintaan sisanya dirutekan ke jalur s1.
Layanan virtual sebelumnya menentukan aturan pengarahan kustom pada gateway ASM untuk meneruskan lalu lintas ke jalur lalu lintas yang berbeda. Saat membuat layanan virtual kustom untuk merutekan permintaan dalam mode ketat, jika Anda ingin merutekan permintaan ke jalur tertentu, cukup setel bidang route.destination.subset ke nama jalur lalu lintas. Setelah permintaan dirutekan ke jalur tersebut, permintaan berikutnya dalam jejak selalu dirutekan ke jalur yang sama.
Buat layanan virtual kustom pada proxy sidecar
Selain membuat layanan virtual kustom pada gateway ingress ASM, Anda juga dapat menentukan aturan pengarahan permintaan untuk aplikasi dalam kluster untuk mengakses layanan di jalur lalu lintas dengan membuat layanan virtual pada semua proxy sidecar. Berbeda dengan layanan virtual kustom pada gateway ingress ASM, bidang gateway tidak diperlukan untuk layanan virtual pada proxy sidecar. Anda perlu menentukan domain kluster layanan mocka di bidang hosts. Contoh file YAML:
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 pencocokan ini cocok persis dengan header permintaan env: dev.
- headers:
env:
exact: dev
name: dev-route
route:
- destination:
host: mocka.default.svc.cluster.local # Layanan tujuan untuk penerusan lalu lintas.
subset: s2 # Nama jalur lalu lintas.
weight: 50
headers:
request:
set:
x-asm-prefer-tag: s2 # Konfigurasikan header pengarahan permintaan untuk jalur lalu lintas.
- destination:
host: mocka.default.svc.cluster.local # Layanan tujuan untuk penerusan lalu lintas.
subset: s3 # Nama jalur lalu lintas.
weight: 50
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s1
headers:
request:
set:
x-asm-prefer-tag: s3 # Konfigurasikan header pengarahan permintaan untuk jalur lalu lintas.
- name: base-route
route:
- destination:
host: mocka.default.svc.cluster.local # Layanan tujuan untuk penerusan lalu lintas.
subset: s1 # Nama jalur lalu lintas.
headers:
request:
set:
x-asm-prefer-tag: s1 # Konfigurasikan header pengarahan permintaan untuk jalur lalu lintas.Mirip dengan langkah Buat layanan virtual kustom pada gateway ingress ASM, nilai headers.request.set dalam file YAML harus sesuai dengan header pengarahan permintaan yang sesuai.
Jalankan tiga perintah berikut untuk mengakses layanan di jalur s1, s2, dan s3 tanpa header permintaan
env: devsetelah Anda membuat layanan virtual kustom pada proxy sidecar:kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "my-trace-id: s1" http://mocka:8000; echo ""; sleep 1; done;' kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "my-trace-id: s2" http://mocka:8000; echo ""; sleep 1; done;' kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "my-trace-id: s3" 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 tersebut menunjukkan bahwa semua permintaan tanpa header permintaan
env: devdikirim ke jalur s1.Jalankan tiga perintah berikut untuk mengakses layanan di jalur s1, s2, dan s3 dengan header permintaan
env: devsetelah Anda membuat layanan virtual kustom pada proxy sidecar:kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "my-trace-id: s1" -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;' kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "my-trace-id: s2" -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;' kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do curl -H "my-trace-id: s3" -H "env: dev" http://mocka:8000; echo ""; sleep 1; done;'Output yang diharapkan:
Outputnya sama dengan yang ada di Create a custom virtual service on an ASM ingress gateway. Artinya, ketika layanan dalam kluster memanggil layanan mocka dalam jalur lalu lintas, permintaan berikutnya dalam jejak selalu diarahkan ke jalur lalu lintas.