# Traffic Management as Configuration — API Gateway and Service Mesh

Source: https://www.geekswithgeeks.com/en/api-gateway-service-mesh/m-traffic-policy

> Declare routing, splits, retries and timeouts as resources instead of code.

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

```yaml
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.

```yaml
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 }
```

**Quiz:** What is an advantage of declaring traffic policy as resources?

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

*Answer:* It is reviewable in Git and changes without redeploying applications. Policy-as-config is versioned, auditable and decoupled from application releases.