Traffic Routing Integrations

Splitting traffic through NGINX Ingress, Istio, Linkerd, Gateway API, and AWS ALB.

7 min readCI/CD & GitOpsPlatform

Traffic Routing Overview

Traffic routing is how you split user requests between the stable and canary versions of your application. The routing mechanism depends on your infrastructure — ingress controllers, service meshes, or cloud load balancers. Each has different capabilities for traffic splitting, header routing, and weight-based splitting.

NGINX Ingress

NGINX canary annotations


# Stable Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-stable
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-stable
                port:
                  number: 80

---
# Canary Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp-canary
                port:
                  number: 80

NGINX canary annotations split traffic by weight, header, or cookie. canary-weight: 10 sends 10% to canary. canary-by-header allows explicit canary routing via the X-Canary header. This is useful for internal testing before public rollout.

Istio Service Mesh

Istio VirtualService and DestinationRule


apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
    - myapp
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: myapp
            subset: canary
    - route:
        - destination:
            host: myapp
            subset: stable
          weight: 90
        - destination:
            host: myapp
            subset: canary
          weight: 10

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
    - name: stable
      labels:
        app: myapp
        version: v1
    - name: canary
      labels:
        app: myapp
        version: v2
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        maxRequestsPerConnection: 10

Istio VirtualService provides fine-grained traffic control. The header-based route allows explicit canary routing. The weight-based route splits normal traffic. DestinationRule defines subsets and traffic policies.

Linkerd

Linkerd TrafficSplit


apiVersion: split.smi-spec.io/v1alpha4
kind: TrafficSplit
metadata:
  name: myapp
  namespace: production
spec:
  service: myapp
  backends:
    - service: myapp-stable
      weight: 90
    - service: myapp-canary
      weight: 10

---
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: myapp.production.svc.cluster.local
  namespace: production
spec:
  routes:
    - name: GET /api/health
      condition:
        method: GET
        pathRegex: /api/health
      responseClasses:
        - condition:
            status:
              min: 200
              max: 299
          result: success

Linkerd uses the SMI TrafficSplit CRD for traffic splitting. The TrafficSplit resource divides traffic between stable and canary services. ServiceProfile defines route-level metrics for more granular analysis.

Gateway API

Gateway API HTTPRoute


apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: myapp
spec:
  parentRefs:
    - name: myapp-gateway
  hostnames:
    - myapp.example.com
  rules:
    - matches:
        - headers:
            - name: x-canary
              value: "true"
      backendRefs:
        - name: myapp-canary
          port: 80
          weight: 100
    - backendRefs:
        - name: myapp-stable
          port: 80
          weight: 90
        - name: myapp-canary
          port: 80
          weight: 10

Gateway API is the Kubernetes-native replacement for Ingress. HTTPRoute supports header matching and weighted backend references. This is the future of Kubernetes traffic routing.

AWS ALB

AWS ALB target group weights


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/actions.myapp: |
      {
        "Type": "forward",
        "ForwardConfig": {
          "TargetGroups": [
            {
              "TargetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/myapp-stable/abc123",
              "Weight": 90
            },
            {
              "TargetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/myapp-canary/def456",
              "Weight": 10
            }
          ]
        }
      }
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              serviceName: myapp
              servicePort: use-annotation

AWS ALB supports weighted target groups for traffic splitting. The annotation-based configuration defines the forward action with weighted target groups. This works without a service mesh.

Choose based on your infrastructure

NGINX is simplest for basic canary routing. Istio provides the most control but adds complexity. Gateway API is the Kubernetes standard but requires controller support. AWS ALB works if you are already on AWS without a service mesh.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 5 · Platform

Progressive Delivery Controllers