Saat merilis versi layanan baru atau melakukan migrasi sistem, validasi hanya dengan data sintetis tidak dapat mereproduksi kondisi dunia nyata seperti input kasus pinggiran (edge-case) dan token berbahaya. Pencerminan lalu lintas di Service Mesh (ASM) menyalin permintaan produksi langsung ke layanan atau kluster terpisah secara real time, sehingga Anda dapat menguji berdasarkan pola lalu lintas aktual tanpa berdampak pada produksi.
Cara kerja pencerminan lalu lintas
Pencerminan lalu lintas (juga disebut shadowing) menduplikasi permintaan masuk dan mengirimkannya ke tujuan yang dicerminkan. Tiga mekanisme menentukan perilakunya:
Out-of-band processing: Lalu lintas yang dicerminkan ditangani di luar jalur permintaan utama. Kegagalan di tujuan yang dicerminkan tidak memengaruhi respons produksi.
Fire and forget: Respons dari tujuan yang dicerminkan dibuang. Layanan utama mengembalikan responsnya tanpa menunggu cerminan.
Header distinction: Permintaan yang dicerminkan memiliki
-shadowditambahkan ke header Host/Authority-nya, sehingga log dapat membedakan lalu lintas yang dicerminkan dari lalu lintas produksi.
Kasus penggunaan
| Kasus penggunaan | Deskripsi |
|---|---|
| Validasi pra-rilis | Cerminkan lalu lintas produksi ke versi layanan baru sebelum rilis. Berbeda dengan simulasi manual berbasis data sampel, lalu lintas yang dicerminkan mereproduksi kondisi dunia nyata—termasuk kasus pinggiran seperti karakter khusus dan input berbahaya. |
| Migrasi sistem | Cerminkan lalu lintas produksi dari sistem lama ke sistem baru untuk uji coba sebelum mengganti atau mentransformasi sistem warisan. |
| Eksperimen arsitektur | Cerminkan lalu lintas ke lingkungan pengujian untuk mensimulasikan dampak perubahan arsitektur sebelum menerapkannya. |
| Isolasi database | Impor data uji ke database kosong dan cerminkan lalu lintas produksi ke dalamnya, sehingga data uji benar-benar terpisah dari data produksi. |
| Debugging langsung | Jalankan layanan sementara dan cerminkan lalu lintas dari layanan produksi yang sedang berjalan untuk mereproduksi dan mendebug masalah tanpa mengganggu produksi. |
| Pencatatan perilaku pengguna | Tangkap data perilaku pengguna nyata melalui lalu lintas yang dicerminkan untuk pelatihan sistem rekomendasi atau analisis profil pengguna. |
Konfigurasi VirtualService contoh
Aturan pencerminan lalu lintas didefinisikan dalam VirtualService. Contoh berikut mengarahkan seluruh lalu lintas ke subset v1 dan mencerminkannya ke subset v1-mirroring:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp-traffic-mirroring
spec:
hosts:
- myapp
http:
- route:
- destination:
host: myapp.default.svc.cluster.local
port:
number: 8000
subset: v1 # Primary destination
weight: 100
mirror:
host: myapp.default.svc.cluster.local
port:
number: 8000
subset: v1-mirroring # Mirror destinationSaat permintaan mencapai subset v1, salinan identik dikirim ke v1-mirroring. Periksa log aplikasi pada subset yang dicerminkan untuk memastikan permintaan telah tiba.
Cerminkan lalu lintas produksi dari Kluster A ke Kluster B
Pencerminan lalu lintas umumnya melibatkan beberapa kluster: kluster produksi mencerminkan lalu lintas ke kluster pengujian terpisah. Langkah-langkah berikut mengonfigurasi Kluster A (produksi) untuk mencerminkan lalu lintas ke Kluster B (pengujian).

Sebelum memulai, pastikan Anda telah:
Memiliki instans ASM dengan dua kluster Kubernetes (Kluster A dan Kluster B) yang ditambahkan ke mesh
kubectldikonfigurasi untuk mengakses kedua klusterGerbang masuk (ingress gateway) diterapkan di kedua kluster
Langkah 1: Terapkan aplikasi contoh di Kluster B
Terapkan layanan httpbin di Kluster B untuk menerima lalu lintas yang dicerminkan.
Buat file bernama httpbin.yaml dengan konten berikut:
Terapkan konfigurasi:
kubectl apply -f httpbin.yamlVerifikasi bahwa Pod sedang berjalan:
kubectl get pods -l app=httpbinOutput harus menunjukkan Pod
httpbin-v1dalam statusRunning.
Langkah 2: Konfigurasikan aturan routing untuk gerbang masuk di Kluster B
Siapkan Gateway dan VirtualService agar gerbang masuk Kluster B mengarahkan permintaan masuk ke layanan httpbin.
Buat file bernama httpbin-gateway.yaml dengan konten berikut:
Terapkan konfigurasi:
kubectl apply -f httpbin-gateway.yamlVerifikasi bahwa layanan dapat dijangkau melalui gerbang masuk:
curl http://<cluster-b-ingress-gateway-ip>/headersOutput yang diharapkan:
{ "headers": { "Accept": "*/*", "Host": "47.99.XX.XX", "User-Agent": "curl/7.79.1", "X-Envoy-Attempt-Count": "1", "X-Envoy-External-Address": "120.244.XXX.XXX", "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=158e4ef69876550c34d10e3bfbd8d43f5ab481b16ba0e90b4e38a2d53ac****;Subject=\"\";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" } }Jika respons menyertakan objek
headers, layanan berfungsi dengan benar.
Langkah 3: Konfigurasikan pencerminan lalu lintas dari Kluster A ke Kluster B
Langkah ini membuat Kluster A mencerminkan lalu lintas ke Kluster B. Anda memerlukan dua sumber daya: ServiceEntry yang mendaftarkan Kluster B sebagai tujuan eksternal, dan VirtualService yang mendefinisikan aturan pencerminan.
Buat ServiceEntry untuk Kluster B
Gerbang masuk Kluster B berada di luar mesh Kluster A. Buat ServiceEntry agar dapat dijangkau melalui hostname.
Buat file bernama httpbin-cluster-b.yaml dengan konten berikut:
Ganti
<cluster-b-ingress-ip>dengan alamat IP aktual gerbang masuk Kluster B.apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: httpbin-cluster-b spec: hosts: - httpbin.mirror.cluster-b # Logical hostname for the mirror target location: MESH_EXTERNAL ports: - number: 80 # Port of Cluster B's ingress gateway name: http protocol: HTTP resolution: STATIC endpoints: - address: <cluster-b-ingress-ip> # Replace with Cluster B's ingress gateway IPTerapkan konfigurasi:
kubectl apply -f httpbin-cluster-b.yaml
Buat aturan pencerminan di Kluster A
Konfigurasikan Gateway dan VirtualService yang mengarahkan lalu lintas produksi ke subset v1 dari httpbin di Kluster A dan mencerminkan persentase lalu lintas tersebut ke Kluster B.
Buat file bernama httpbin-gateway.yaml dengan konten berikut:
PentingBidang
hostdalam bagianmirrormenentukan tujuan lalu lintas yang dicerminkan tetapi tidak mengubah header Host asli. Permintaan yang dicerminkan mempertahankan header Host/Authority asli dengan tambahan-shadow. Sebagai contoh, header Host dari lalu lintas yang dicerminkan bukanhttpbin.mirror.cluster-bmelainkan header permintaan asli dengan tambahan-shadow.Terapkan konfigurasi:
kubectl apply -f httpbin-gateway.yaml
Verifikasi konfigurasi Envoy
Periksa dump konfigurasi Envoy dari Pod gerbang masuk di Kluster A untuk memastikan kebijakan pencerminan aktif.
Dalam konfigurasi rute, temukan bagian request_mirror_policies:
"routes": [
{
"match": {
"prefix": "/headers",
"case_sensitive": true
},
"route": {
"cluster": "outbound|8000|v1|httpbin.default.svc.cluster.local",
"timeout": "0s",
"retry_policy": {
"retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
"num_retries": 2,
"retry_host_predicate": [
{
"name": "envoy.retry_host_predicates.previous_hosts",
"typed_config": {
"@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
}
}
],
"host_selection_retry_max_attempts": "5",
"retriable_status_codes": [
503
]
},
"request_mirror_policies": [
{
"cluster": "outbound|80||httpbin.mirror.cluster-b",
"runtime_fraction": {
"default_value": {
"numerator": 500000,
"denominator": "MILLION"
}
},
"trace_sampled": false
}
]
}
}
]Bidang kunci dalam output:
| Bidang | Deskripsi |
|---|---|
request_mirror_policies.cluster | Kluster tujuan untuk lalu lintas yang dicerminkan (outbound|80||httpbin.mirror.cluster-b) |
runtime_fraction.numerator / denominator | Rasio pencerminan. 500000 / MILLION = 50% lalu lintas dicerminkan |
route.cluster | Tujuan utama untuk lalu lintas produksi (outbound|8000|v1|httpbin.default.svc.cluster.local) |
Jika bagian request_mirror_policies muncul dengan nilai kluster dan fraksi yang benar, pencerminan lalu lintas telah dikonfigurasi dengan tepat.