Trafik yansıtma (trafik gölgeleme olarak da bilinir), canlı üretim trafiğini üretim ortamını etkilemeden gerçek zamanlı olarak bir test hizmetine kopyalar. Yansıtılan istekler "gönder ve unut" mantığıyla çalışır: Mesh bu istekleri kritik istek yolunun dışında bant dışı olarak gönderir ve tüm yanıtları yok sayar. Service Mesh (ASM) kümeler arası trafik yansıtma işlevini destekler; bu sayede yeni hizmet sürümlerini doğrulayabilir, sorunları ayıklayabilir veya gerçek üretim trafiğine karşı simülasyon testleri çalıştırabilirsiniz.
Aşağıdaki kurulumda Cluster A üretim ortamını, Cluster B ise test ortamını temsil eder. Cluster A'daki giriş ağ geçidi gelen trafiği Cluster B'ye yansıtır; burada bir test hizmeti yansıtılan istekleri işler.

Trafik yansıtmanın ne zaman kullanılacağı
| Kullanım durumu | Açıklama |
|---|---|
| Sürüm öncesi doğrulama | Dağıtımı yapmadan önce üretim trafiğini yeni bir hizmet sürümüne yansıtın ve sonuçları karşılaştırın. Örnek verilerle yapılan manuel testlerin aksine yansıtılan trafik hatalı girdiler ve kötü amaçlı yükler gibi gerçek dünya uç durumlarını kapsar. |
| Sistem geçişi | Eski sistemden yeni sisteme deneme amaçlı bir çalışma için trafiği yansıtın. Kesintiye geçmeden önce yeni sistemin tüm üretim senaryolarını yönettiğini doğrulayın. |
| Canlı hata ayıklama | Çalışan bir hizmetten geçici bir hata ayıklama örneğine trafiği yansıtın. Kullanıcıları etkilemeden gerçek trafiklerle sorunları yeniden oluşturun. |
| Test verisi izolasyonu | Üretim verilerine dokunmadan yansıtılan üretim trafiğini ayrı bir test veritabanına yönlendirin. |
| Kullanıcı davranışı günlüğü | Yansıtılan trafiği günlüklerde saklayarak öneri algoritmaları ve kullanıcı profili analizi için gerçek kullanıcı davranış verilerini yakalayın. |
Trafik yansıtmanın çalışma biçimi
Yansıtma işlemini yapılandırmadan önce anlaşılması gereken iki davranış şunlardır:
Host üstbilgisi değişikliği: Yansıtılan isteklerin Host/Authority üstbilgisine
-shadoweki eklenir. Örneğin orijinal Host değerihttpbinise yansıtılan isteğin Host değerihttpbin-shadowolur. VirtualService içindekimirrorbölümündekihostalanı yalnızca hedef adresi belirler; orijinal Host üstbilgisinin üzerine yazmaz.Yansıtma yüzdesi:
mirrorPercentage.valuealanı trafiğin ne kadarının yansıtılacağını kontrol eder. Bu alan belirtilmezse trafiğin %100'ü yansıtılır.
Örnek VirtualService yapılandırması
Aşağıdaki VirtualService tüm trafiği v1 alt kümesine yönlendirir ve bunu v1-mirroring alt kümesine yansıtır:
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
weight: 100
mirror:
host: myapp.default.svc.cluster.local
port:
number: 8000
subset: v1-mirroring
Bu yapılandırmayı uyguladıktan sonra myapp adresine yapılan her istek v1 alt kümesi tarafından karşılanır; aynı zamanda her isteğin bir kopyası v1-mirroring alt kümesine gönderilir.
Ön koşullar
Başlamadan önce aşağıdakilere sahip olduğunuzdan emin olun:
ASM yapılandırılmış iki Kubernetes kümesi (Cluster A ve Cluster B)
Her iki kümeye de erişecek şekilde yapılandırılmış kubectl
Hedef ad alanlarında etkinleştirilmiş otomatik sidecar enjeksiyonu
Adım 1: Cluster B'de httpbin hizmetini dağıtın
-
Aşağıdaki içeriğe sahip
httpbin.yamladlı bir dosya oluşturun: -
httpbin v1 uygulamasını dağıtın:
kubectl apply -f httpbin.yaml -
Pod'un çalıştığını doğrulayın:
kubectl get pods -l app=httpbinBeklenen çıktı aşağıdakine benzer:
NAME READY STATUS RESTARTS AGE httpbin-v1-xxxxxxxxx-xxxxx 2/2 Running 0 30sREADY sütunundaki
2/2değeri sidecar proxy'nin uygulama konteynerinin yanına enjekte edildiğini onaylar.
Adım 2: Cluster B'deki giriş ağ geçidi için bir yönlendirme kuralı yapılandırın
Bu adım Cluster A'dan yansıtılan trafiğin ulaşabilmesi için httpbin hizmetini Cluster B giriş ağ geçidi üzerinden açığa çıkarır.
-
Aşağıdaki içeriğe sahip
httpbin-gateway.yamladlı bir dosya oluşturun: -
Gateway ve VirtualService'i uygulayın:
kubectl apply -f httpbin-gateway.yaml -
Hizmetin giriş ağ geçidi üzerinden erişilebilir olduğunu doğrulamak için bir test isteği gönderin:
curl http://<cluster-b-ingress-gateway-ip>/headers<cluster-b-ingress-gateway-ip>değerini Cluster B'deki giriş ağ geçidinin harici IP'si ile değiştirin.Beklenen çıktı aşağıdakine benzer:
{ "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" } }
Adım 3: Cluster A'da trafik yansıtma yapılandırın
Henüz yapmadıysanız aynı httpbin uygulamasını Cluster A'ya dağıtın. 1. Adımdaki httpbin.yaml dosyasını kullanın:
kubectl apply -f httpbin.yaml
Ardından Cluster A'da dört kaynak oluşturun:
Cluster B giriş ağ geçidini harici bir hizmet olarak kaydeden bir ServiceEntry
Yerel httpbin hizmeti için
v1alt kümesini tanımlayan bir DestinationRuleTrafiği yerel httpbin hizmetine yönlendiren ve Cluster B'ye yansıtan bir Gateway ve VirtualService
ServiceEntry oluşturun
Yansıtılan trafik harici bir adresi (Cluster B giriş ağ geçidini) hedefler. Bir ServiceEntry mesh'in bu adresi nasıl çözeceğini belirtir.
-
Aşağıdaki içeriğe sahip
httpbin-cluster-b.yamladlı bir dosya oluşturun:apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: httpbin-cluster-b spec: hosts: - httpbin.mirror.cluster-b location: MESH_EXTERNAL ports: - number: 80 # Port of the ingress gateway in Cluster B name: http protocol: HTTP resolution: STATIC endpoints: - address: 47.95.XX.XX # External IP of the ingress gateway in Cluster B47.95.XX.XXdeğerini Cluster B'deki giriş ağ geçidinin gerçek harici IP'si ile değiştirin. -
ServiceEntry'i uygulayın:
kubectl apply -f httpbin-cluster-b.yaml
DestinationRule oluşturun
VirtualService trafiği httpbin'in v1 alt kümesine yönlendirir. Bir DestinationRule bu alt kümeyi tanımlar.
-
Aşağıdaki içeriğe sahip
httpbin-destinationrule.yamladlı bir dosya oluşturun:apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: httpbin spec: host: httpbin subsets: - name: v1 labels: version: v1 -
DestinationRule'ü uygulayın:
kubectl apply -f httpbin-destinationrule.yaml
Yansıtma içeren Gateway ve VirtualService oluşturun
VirtualService tüm trafiği yerel httpbin hizmetinin v1 alt kümesine yönlendirirken trafiğin belirli bir yüzdesini ServiceEntry aracılığıyla Cluster B'ye yansıtır.
-
Aşağıdaki içeriğe sahip
httpbin-gateway.yamladlı bir dosya oluşturun:Notmirror.hostalanı yalnızca hedef çözümlemesi için kullanılır. Yansıtılan isteklerin gerçek Host üstbilgisi orijinal Host değerinin sonuna-shadoweklenmiş halidir;httpbin.mirror.cluster-bdeğildir. -
Yapılandırmayı uygulayın:
kubectl apply -f httpbin-gateway.yaml
Adım 4: Trafik yansıtmanın çalıştığını doğrulayın
Envoy yapılandırmasını kontrol edin
Yansıtma ilkesinin uygulandığını onaylamak için Cluster A'daki giriş ağ geçidi Pod'unun Envoy yapılandırma dökümünü görüntüleyin:
"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
}
]
}
}
]
Doğrulanması gereken temel alanlar:
| Alan | Beklenen değer | Anlamı |
|---|---|---|
request_mirror_policies.cluster |
outbound|80||httpbin.mirror.cluster-b |
Yansıtılan trafik Cluster B giriş ağ geçidine gönderilir |
runtime_fraction.numerator |
500000 |
Trafiğin %50'si yansıtılır (500.000 / 1.000.000) |
Test trafiği gönderin ve günlükleri kontrol edin
Envoy yapılandırma dökümü yapılandırmayı onaylasa da yansıtılan trafiğin gerçekten Cluster B'ye ulaştığını da doğrulamanız gerekir. Test istekleri gönderin ve her iki kümedeki httpbin Pod günlüklerini kontrol edin.
-
Cluster A'daki giriş ağ geçidine bir istek gönderin:
curl http://<cluster-a-ingress-gateway-ip>/headers -
İsteğin karşılandığını onaylamak için Cluster A'daki httpbin Pod günlüklerini kontrol edin:
kubectl logs -l app=httpbin -c httpbinBeklenen çıktı Cluster A'nın isteği aldığını ve işlediğini gösterir:
127.0.0.6 - - [11/Mar/2026 06:00:00] "GET /headers HTTP/1.1" 200 - -
Yansıtılan isteğin geldiğini onaylamak için Cluster B'deki httpbin Pod günlüklerini kontrol edin:
kubectl logs -l app=httpbin -c httpbinYansıtma çalışıyorsa Cluster B günlüklerinde ilgili bir
GET /headersisteği girişi görünür:127.0.0.6 - - [11/Mar/2026 06:00:00] "GET /headers HTTP/1.1" 200 -Yansıtılan istek
-shadowsonekine sahip bir Host üstbilgisi taşır (örneğinhttpbin-shadow); ancak varsayılan httpbin erişim günlük biçimi Host üstbilgilerini göstermez.-shadowüstbilgisini incelemek için sidecar proxy'nin Envoy erişim günlüklerini kontrol edin veya ayrıntılı günlüğü etkinleştirin.NotCluster B yansıtılan isteği göstermiyorsa ServiceEntry IP adresinin Cluster B giriş ağ geçidinin gerçek harici IP'siyle eşleştiğinden ve giriş ağ geçidinin 80 numaralı bağlantı noktasındaki trafiği kabul ettiğinden emin olun.
Temizleme
Bu öğreticide oluşturulan kaynakları kaldırmak için:
Cluster B'de:
kubectl delete -f httpbin-gateway.yaml
kubectl delete -f httpbin.yaml
Cluster A'da:
kubectl delete -f httpbin-gateway.yaml
kubectl delete -f httpbin-destinationrule.yaml
kubectl delete -f httpbin-cluster-b.yaml
kubectl delete -f httpbin.yaml