Tüm Ürünler
Search
Belge Merkezi

Alibaba Cloud Service Mesh:Use traffic mirroring across clusters at the service mesh layer

Son Güncelleme:Oct 07, 2026

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.

Cross-cluster traffic mirroring architecture

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 -shadow eki eklenir. Örneğin orijinal Host değeri httpbin ise yansıtılan isteğin Host değeri httpbin-shadow olur. VirtualService içindeki mirror bölümündeki host alanı yalnızca hedef adresi belirler; orijinal Host üstbilgisinin üzerine yazmaz.

  • Yansıtma yüzdesi: mirrorPercentage.value alanı 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

  1. Aşağıdaki içeriğe sahip httpbin.yaml adlı bir dosya oluşturun:

    Expand to view httpbin.yaml

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: httpbin
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: httpbin
      labels:
        app: httpbin
        service: httpbin
    spec:
      ports:
      - name: http
        port: 8000
        targetPort: 80
      selector:
        app: httpbin
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: httpbin-v1
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: httpbin
          version: v1
      template:
        metadata:
          labels:
            app: httpbin
            version: v1
        spec:
          serviceAccountName: httpbin
          containers:
          - image: docker.io/kennethreitz/httpbin
            imagePullPolicy: IfNotPresent
            name: httpbin
            ports:
            - containerPort: 80
  2. httpbin v1 uygulamasını dağıtın:

    kubectl apply -f httpbin.yaml
  3. Pod'un çalıştığını doğrulayın:

    kubectl get pods -l app=httpbin

    Beklenen çıktı aşağıdakine benzer:

    NAME                         READY   STATUS    RESTARTS   AGE
    httpbin-v1-xxxxxxxxx-xxxxx   2/2     Running   0          30s

    READY sütunundaki 2/2 değ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.

  1. Aşağıdaki içeriğe sahip httpbin-gateway.yaml adlı bir dosya oluşturun:

    Expand to view httpbin-gateway.yaml

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: httpbin-gateway
    spec:
      selector:
        istio: ingressgateway
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - "*"
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: httpbin
    spec:
      hosts:
      - "*"
      gateways:
      - httpbin-gateway
      http:
      - match:
        - uri:
            prefix: /headers
        route:
        - destination:
            host: httpbin
            port:
              number: 8000
  2. Gateway ve VirtualService'i uygulayın:

    kubectl apply -f httpbin-gateway.yaml
  3. 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 v1 alt kümesini tanımlayan bir DestinationRule

  • Trafiğ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.

  1. Aşağıdaki içeriğe sahip httpbin-cluster-b.yaml adlı 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 B

    47.95.XX.XX değerini Cluster B'deki giriş ağ geçidinin gerçek harici IP'si ile değiştirin.

  2. 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.

  1. Aşağıdaki içeriğe sahip httpbin-destinationrule.yaml adlı bir dosya oluşturun:

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: httpbin
    spec:
      host: httpbin
      subsets:
      - name: v1
        labels:
          version: v1
  2. 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.

  1. Aşağıdaki içeriğe sahip httpbin-gateway.yaml adlı bir dosya oluşturun:

    Expand to view httpbin-gateway.yaml

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: httpbin-gateway
    spec:
      selector:
        istio: ingressgateway
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - "*"
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: httpbin
    spec:
      gateways:
        - httpbin-gateway
      hosts:
        - '*'
      http:
        - match:
            - uri:
                prefix: /headers
          mirror:
            host: httpbin.mirror.cluster-b    # Resolves to the Cluster B ingress gateway via the ServiceEntry
            port:
              number: 80
          mirrorPercentage:
            value: 50                         # Mirror 50% of traffic; omit this field to mirror 100%
          route:
            - destination:
                host: httpbin
                port:
                  number: 8000
                subset: v1
    Not

    mirror.host alanı yalnızca hedef çözümlemesi için kullanılır. Yansıtılan isteklerin gerçek Host üstbilgisi orijinal Host değerinin sonuna -shadow eklenmiş halidir; httpbin.mirror.cluster-b değildir.

  2. 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.

  1. Cluster A'daki giriş ağ geçidine bir istek gönderin:

    curl http://<cluster-a-ingress-gateway-ip>/headers
  2. İsteğin karşılandığını onaylamak için Cluster A'daki httpbin Pod günlüklerini kontrol edin:

    kubectl logs -l app=httpbin -c httpbin

    Beklenen çı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 -
  3. 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 httpbin

    Yansıtma çalışıyorsa Cluster B günlüklerinde ilgili bir GET /headers isteğ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 -shadow sonekine sahip bir Host üstbilgisi taşır (örneğin httpbin-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.

    Not

    Cluster 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