# Configuration के रूप में Traffic Management — API Gateway और Service Mesh

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

> Routing, बँटवारे, retries और timeouts को कोड की जगह resources के रूप में घोषित करें।

## YAML के रूप में नीति

Kubernetes में mesh और gateway का व्यवहार custom resources में घोषित होता है और control plane द्वारा लागू किया जाता है। **Istio** में `VirtualService` routes, weights, retries और timeouts परिभाषित करता है और `DestinationRule` subsets (versions), connection pools और outlier detection। Kubernetes **Gateway API** मानक, पोर्टेबल विकल्प देता है: `Gateway` (listener), `HTTPRoute` (weighted `backendRefs` वाले नियम) और ऐसे attachment नियम जो platform स्वामित्व को application routing से अलग करते हैं। इस तरह नीति घोषित करने से वह Git में review योग्य, auditable और भाषाओं भर में एकरूप बनती है, और application को redeploy किए बिना बदलती है।

## Retries वाला canary route (Istio, उदाहरण)

भावना में पहले के nginx weights और retry settings के समतुल्य, पर resource के रूप में घोषित: 90% v1 को, 10% v2 को, 2-सेकंड का timeout और 5xx या connection विफलता पर अधिकतम 2 retries। यहाँ चलाया नहीं गया।

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

## Gateway API से वही बँटवारा (उदाहरण)

`HTTPRoute` weighted routing का पोर्टेबल रूप है। यहाँ चलाया नहीं गया।

```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:** Traffic नीति को resources के रूप में घोषित करने का लाभ क्या है?

- [ ] यह services की ज़रूरत हटाता है
- [ ] यह सारे outages रोकता है
- [x] यह Git में review योग्य है और applications को redeploy किए बिना बदलती है
- [ ] यह YAML को वैकल्पिक बनाता है

*Answer:* यह Git में review योग्य है और applications को redeploy किए बिना बदलती है. Policy-as-config versioned, auditable और application releases से अलग है।