Apache APISIX Ingress Controller में ट्रैफिक स्प्लिट

ट्रैफिक स्प्लिट एक ऐसी सुविधा है जो ट्रैफिक को कई बैकेंड सेवाओं में विभाजित और वितरित करती है। API गेटवे (जैसे Apache APISIX और Traefik), सर्विस मेश (जैसे Istio और Linkerd) जैसे समाधान ट्रैफिक स्प्लिटिंग करने में सक्षम हैं और Canary Release और Blue-Green Deployment जैसी कार्यक्षमताओं को लागू करते हैं।

ट्रैफिक स्प्लिट Ingress Controller में भी एक प्रमुख सुविधा है। Kubernetes क्लस्टर में इनग्रेस परत के रूप में, एप्लिकेशन के नए संस्करण को रिलीज करने के जोखिम को कम करने के लिए इनग्रेस कंट्रोलर में कुछ ट्रैफिक स्प्लिट नियम सेट करना वांछनीय है, ताकि केवल एक नियंत्रित मात्रा में ट्रैफिक नए रिलीज किए गए इंस्टेंस पर रूट किया जाए। इस लेख में, हम Ingress Nginx और Kong Ingress Controller में ट्रैफिक स्प्लिट (जिसे कैनरी रिलीज भी कहा जाता है) का परिचय देंगे, और अंत में हम Apache APISIX Ingress Controller में ट्रैफिक स्प्लिट की व्याख्या करेंगे।

(PS: अधिक संक्षिप्त विवरण के लिए, हम "कैनरी ऐप" शब्द का उपयोग उस बैकेंड सेवा का वर्णन करने के लिए करते हैं जो कैनरी नियमों के हिट होने के बाद रूट की जाती है, और "स्टेबल ऐप" शब्द का उपयोग उस बैकेंड सेवा का वर्णन करने के लिए करते हैं जो कैनरी नियमों के मिस होने के कारण रूट की जाती है, उदाहरण के लिए, निम्नलिखित डायग्राम में कैनरी और स्टेबल ऐप क्रमशः "foo-canary" और "foo" हैं।)

Ingress Nginx

Ingress Nginx कैनरी रिलीज का समर्थन करता है, यह "nginx.ingress.kubernetes.io/canary" एनोटेशन द्वारा नियंत्रित होता है, और यह इस सुविधा को कस्टमाइज़ करने के लिए कई एनोटेशन का समर्थन करता है।

nginx.ingress.kubernetes.io/canary-by-header

गंतव्य हेडर के मान (nginx.ingress.kubernetes.io/canary-by-header द्वारा इंगित) द्वारा तय किया जाता है, यदि मान "always" है तो कैनरी ऐप रूट किया जाएगा, अन्यथा स्टेबल ऐप रूट किया जाएगा (हेडर का मान "never" है)।

nginx.ingress.kubernetes.io/canary-by-header-value

यह एनोटेशन nginx.ingress.kubernetes.io/canary-by-header का विस्तार करता है, अब हेडर का मान "always" या "never" होने की आवश्यकता नहीं है।

nginx.ingress.kubernetes.io/canary-by-header-pattern

nginx.ingress.kubernetes.io/canary-by-header के समान, लेकिन मान एक PCRE संगत रेगुलर एक्सप्रेशन है।

nginx.ingress.kubernetes.io/canary-by-cookie

कुकी हेडर में डेटा फील्ड का उपयोग बैकेंड सेवा तय करने के लिए करें।

nginx.ingress.kubernetes.io/canary-weight

0 और 100 के बीच वेट वैल्यू असाइन करें, ट्रैफिक इस वेट के अनुसार वितरित किया जाएगा, 0 वेट का मतलब है कि सभी ट्रैफिक कैनरी ऐप पर रूट किया जाएगा और 100 वेट सभी ट्रैफिक को स्टेबल ऐप पर रूट करेगा।

निम्नलिखित YAML स्निपेट उन अनुरोधों को प्रॉक्सी करता है जिनका URI पथ "/get" से शुरू होता है और User-Agent ".Mozilla." पैटर्न से मेल खाता है, उन्हें कैनरी ऐप "foo-canary" पर रूट करता है।

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/canary: "true"
      nginx.ingress.kubernetes.io/canary-by-header: "User-Agent"
      nginx.ingress.kubernetes.io/canary-by-header-pattern:
".*Mozilla.*"
  name: ingress-v1beta1

Kong

Kong गेटवे में एक कैनरी रिलीज प्लगइन है और यह इस प्लगइन को KongPlugin रिसोर्स के माध्यम से अपने इनग्रेस कंट्रोलर को एक्सपोज़ करता है। एडमिनिस्ट्रेटर्स/उपयोगकर्ताओं को एक KongPlugin ऑब्जेक्ट बनाना होगा और कैनरी रिलीज नियम भरना होगा, लक्षित Kubernetes Service में "konghq.com/plugins" एनोटेशन इंजेक्ट करना होगा। या आप एक KongClusterPlugin ऑब्जेक्ट बना सकते हैं ताकि यह कैनरी नियम पूरे क्लस्टर में प्रभावी हो।

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: foo-canary
config:
  percentage: 30
  upstream_host: foo.com
  upstream_fallback: false
  upstream_port: 80
plugin: canary
---
apiVersion: v1
kind: Service
metadata:
  name: foo-canary
  labels:
    app: foo
  annotations:
    konghq.com/plugins: foo-canary
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: http
  selector:
    app: foo
    canary: true

उपरोक्त मामले में सेवा "foo-canary" को "canary" के रूप में चिह्नित किया गया है, और इस सेवा पर 30% ट्रैफिक को प्रॉक्सी करने के लिए एक कैनरी रिलीज नियम बनाया गया है।

Apache APISIX

Apache APISIX अपने traffic-split प्लगइन द्वारा कस्टम नियमों के साथ ट्रैफिक को विभाजित करता है, और Apache APISIX Ingress Controller इस प्लगइन और ApisixRoute में लचीले रूट मैच क्षमताओं का उपयोग करके ApisixRoute में ट्रैफिक स्प्लिट सुविधा को लागू करता है (प्रथम-श्रेणी समर्थन के रूप में, एनोटेशन पर निर्भर किए बिना)।

वेट-आधारित

कई Kubernetes सेवाओं को कॉन्फ़िगर करके, वेट-आधारित कैनरी नियम को इस प्रकार लागू किया जा सकता है:

apiVersion: apisix.apache.org/v2alpha1
kind: ApisixRoute
metadata:
  name: foo-route
spec:
  http:
    - name: rule1
      match:
        hosts:
          - foo.org
        paths:
          - /get*
      backends:
        - serviceName: foo-canary
          servicePort: 80
          weight: 10
        - serviceName: foo
          servicePort: 80
          weight: 5

उपरोक्त मामले में "foo.org" होस्ट और "/get" URI पथ प्रीफ़िक्स वाले अनुरोधों को "foo-canary" सेवा पर और अन्य को foo पर रूट किया जाता है।

कैनरी सेवा के लिए वेट छोटे पैमाने के सत्यापन के लिए छोटा हो सकता है, और ApisixRoute को संशोधित करके वेट को बढ़ाएं जब तक कि सभी ट्रैफिक कैनरी सेवा पर रूट न हो जाए, जिससे रिलीज पूरी तरह से समाप्त हो जाए।

नियम-आधारित

ApisixRoute में Exprs फील्ड उपयोगकर्ताओं को कस्टम रूट मैच नियम कॉन्फ़िगर करने की अनुमति देती है, दूसरी ओर, कई रूट नियमों को एक ही ApisixRoute ऑब्जेक्ट में समूहीकृत किया जा सकता है, इसलिए नियम-आधारित ट्रैफिक स्प्लिट को लागू करने का एक सहज तरीका है।

apiVersion: apisix.apache.org/v2alpha1
kind: ApisixRoute
metadata:
  name: foo-route
spec:
  http:
    - name: rule1
      priority: 1
      match:
        hosts:
          - foo.org
        paths:
          - /get*
      backends:
        - serviceName: foo
          servicePort: 80
    - name: rule2
      priority: 2
      match:
        hosts:
          - foo.org
        paths:
          - /get*
        exprs:
          - subject:
              scope: Query
              name: id
            op: In
            set:
              - "3"
              - "13"
              - "23"
              - "33"
      backends:
        - serviceName: foo-canary
          servicePort: 80

"foo.org" होस्ट और "/get" URI पथ प्रीफ़िक्स वाले अनुरोधों को दो भागों में विभाजित किया जाएगा:

id पैरामीटर जिसका मान 3, 13, 23 या 33 है, rule2 को हिट करेगा, और foo-canary पर फॉरवर्ड किया जाएगा;
अन्य rule1 को हिट करेंगे और foo पर रूट किए जाएंगे।

सारांश

Ingress Nginx में ट्रैफिक स्प्लिट (कैनरी रिलीज) वेट-आधारित योजना और हेडर नियम-आधारित योजना का समर्थन करता है, लेकिन यह एनोटेशन पर निर्भर करता है, जिसका अर्थ कमजोर है; Kong तरीका केवल वेट द्वारा कैनरी रिलीज कॉन्फ़िगर करने का समर्थन करता है, परिदृश्य कुछ हद तक संकीर्ण हैं, और कॉन्फ़िगरेशन जटिल है (आपको कई संसाधनों को कॉन्फ़िगर करने की आवश्यकता है); इसके विपरीत, Apache APISIX Ingress Controller में ट्रैफिक स्प्लिट लचीला और कॉन्फ़िगर करने में आसान है, यह वेट-आधारित और नियम-आधारित ट्रैफिक स्प्लिट योजना दोनों के लिए अच्छी तरह से काम करता है।