Traffic Management as Configuration

Policy as YAML

In Kubernetes, mesh and gateway behaviour is declared in custom resources and applied by the control plane. In Istio, a VirtualService defines routes, weights, retries and timeouts and a DestinationRule defines subsets (versions), connection pools and outlier detection. The Kubernetes Gateway API offers a standard, portable alternative: Gateway (the listener), HTTPRoute (rules with weighted backendRefs) and attachment rules that separate platform ownership from application routing. Declaring policy this way makes it reviewable in Git, auditable and consistent across languages, and it changes without redeploying the application.

A canary route with retries (Istio, illustrative)

Equivalent in spirit to the nginx weights and retry settings earlier, but declared as a resource: 90% to v1, 10% to v2, a 2-second timeout and up to 2 retries on 5xx or connection failure. Not run here.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: orders }
spec:
  hosts: [orders]
  http:
    - route:
        - destination: { host: orders, subset: v1 }
          weight: 90
        - destination: { host: orders, subset: v2 }
          weight: 10
      timeout: 2s
      retries: { attempts: 2, perTryTimeout: 1s, retryOn: "5xx,connect-failure" }

The same split with Gateway API (illustrative)

HTTPRoute is the portable form of weighted routing. Not run here.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: orders }
spec:
  parentRefs: [{ name: public-gateway }]
  hostnames: ["api.example.com"]
  rules:
    - matches: [{ path: { type: PathPrefix, value: /orders } }]
      backendRefs:
        - { name: orders-v1, port: 8080, weight: 90 }
        - { name: orders-v2, port: 8080, weight: 10 }

Quick check: What is an advantage of declaring traffic policy as resources?

• It removes the need for services
• It prevents all outages
• It is reviewable in Git and changes without redeploying applications
• It makes YAML optional