Configuration के रूप में Traffic Management

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। यहाँ चलाया नहीं गया।

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 का पोर्टेबल रूप है। यहाँ चलाया नहीं गया।

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 }

त्वरित जाँच: Traffic नीति को resources के रूप में घोषित करने का लाभ क्या है?

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