Kubernetes Gateway और Ingress APIs की तुलना

कुछ महीने पहले, नया Kubernetes Gateway API बीटा में स्नातक हो गया।

जब आपके पास स्थिर Kubernetes Ingress API और कई कार्यान्वयन हैं, तो आपको बाहरी ट्रैफ़िक को संभालने के लिए एक और API की आवश्यकता क्यों है? Ingress API की कौन सी समस्याएं नया Gateway API हल करता है? क्या इसका मतलब Ingress API का अंत है?

मैं इन प्रश्नों के उत्तर देने का प्रयास करूंगा, इन APIs के साथ हाथों-हाथ काम करके और देखकर कि वे कैसे विकसित हुए हैं।

सेवाओं के लिए बाहरी पहुंच को मानकीकृत करना: Ingress API

Kubernetes Ingress API को Kubernetes में सेवाओं को बाहरी ट्रैफ़िक के लिए एक्सपोज़ करने को मानकीकृत करने के लिए बनाया गया था। Ingress API ने डिफ़ॉल्ट सेवा प्रकारों, NodePort और LoadBalancer, की सीमाओं को पार कर लिया, जैसे कि रूटिंग और SSL टर्मिनेशन जैसी सुविधाएं शुरू करके।

Ingress controllers के 20 से अधिक कार्यान्वयन उपलब्ध हैं। इस लेख में, मैं Apache APISIX और इसके Ingress controller का उपयोग उदाहरणों के लिए करूंगा।

आप APISIX या किसी अन्य Ingress कार्यान्वयन को कॉन्फ़िगर करने के लिए एक Ingress संसाधन बना सकते हैं।

नीचे दिया गया उदाहरण दिखाता है कि आप APISIX Ingress के साथ एक एप्लिकेशन के दो संस्करणों के बीच ट्रैफ़िक को कैसे रूट कर सकते हैं:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api-v1
                port:
                  number: 8080
            path: /v1
            pathType: Prefix
          - backend:
              service:
                name: bare-minimum-api-v2
                port:
                  number: 8081
            path: /v2
            pathType: Prefix

टिप: आप इस हाथों-हाथ ट्यूटोरियल को देख सकते हैं ताकि Kubernetes पर Ingress को Apache APISIX Ingress controller के साथ सेट अप करने के बारे में अधिक जान सकें।

चूंकि Ingress API किसी विशेष कंट्रोलर कार्यान्वयन से बंधा नहीं है, आप APISIX को किसी अन्य Ingress controller के साथ बदल सकते हैं, और यह समान रूप से काम करेगा।

यह सरल रूटिंग के लिए ठीक है। लेकिन API सीमित है, और यदि आप अपने Ingress controller द्वारा प्रदान की गई पूर्ण सुविधाओं का उपयोग करना चाहते हैं, तो आप एनोटेशन्स के साथ फंस जाते हैं।

उदाहरण के लिए, Kubernetes Ingress API रीराइट्स को कॉन्फ़िगर करने के लिए एक स्कीमा प्रदान नहीं करता है। रीराइट्स तब उपयोगी होते हैं जब आपका अपस्ट्रीम/बैकएंड URL आपके Ingress नियम में कॉन्फ़िगर किए गए पथ से भिन्न होता है।

APISIX इस सुविधा का समर्थन करता है, और आपको इसका लाभ उठाने के लिए कस्टम एनोटेशन्स का उपयोग करना होगा:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
  annotations:
    k8s.apisix.apache.org/rewrite-target-regex: "/app/(.*)"
    k8s.apisix.apache.org/rewrite-target-regex-template: "/$1"
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api
                port:
                  number: 8080
            path: /app
            pathType: Prefix

यह एक Ingress संसाधन बनाता है जो APISIX को कॉन्फ़िगर करता है कि /app प्रीफ़िक्स वाले किसी भी अनुरोध को बैकएंड पर प्रीफ़िक्स हटाकर भेजा जाए। उदाहरण के लिए, /app/version का अनुरोध /version पर भेजा जाएगा।

एनोटेशन्स आपके Ingress controller के चुनाव पर निर्भर करते हैं। ये "स्वामित्व" एक्सटेंशन्स Ingress API के साथ शुरू में इच्छित पोर्टेबिलिटी के दायरे को सीमित करते हैं।

कस्टम CRDs > Ingress API

एनोटेशन्स के साथ फंसने से Ingress controllers की उपयोगिता भी कम हो जाती है।

इसलिए, कंट्रोलर्स ने Ingress API की सीमाओं को पार करने के लिए अपने स्वयं के कस्टम संसाधन बनाए। नीचे दिया गया उदाहरण दिखाता है कि APISIX के कस्टम संसाधन का उपयोग करके Ingress को कैसे कॉन्फ़िगर किया जाए ताकि एक एप्लिकेशन के दो संस्करणों के बीच ट्रैफ़िक को रूट किया जा सके:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-routes
spec:
  http:
    - name: route-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v1
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
    - name: route-2
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v2
      backends:
        - serviceName: bare-minimum-api-v2
          servicePort: 8081

इन CRDs ने Ingress को कॉन्फ़िगर करना बहुत आसान बना दिया, लेकिन आप विशिष्ट Ingress कंट्रोलर कार्यान्वयन से बंधे होते हैं। Ingress API के विकसित न होने के कारण, आपको उपयोगिता या पोर्टेबिलिटी के बीच चयन करना पड़ता था।

Ingress का विस्तार और Gateway API में विकास

Ingress API टूटा नहीं था; यह सीमित था। Gateway API को इन सीमाओं को पार करने के लिए डिज़ाइन किया गया था।

(Gateway API) का उद्देश्य Kubernetes सेवा नेटवर्किंग को व्यक्तिपरक, विस्तार योग्य, और भूमिका-उन्मुख इंटरफेस के माध्यम से विकसित करना है ...

यह पहले उल्लेखित विभिन्न Ingress controllers के कस्टम CRDs से प्रेरणा लेता है।

Gateway API, Ingress API की क्षमताओं के "शीर्ष पर" कई सुविधाएं जोड़ता है। इसमें HTTP हेडर-आधारित मिलान, भारित ट्रैफ़िक विभाजन, और अन्य सुविधाएं शामिल हैं जो Ingress API के साथ कस्टम स्वामित्व एनोटेशन्स की आवश्यकता होती हैं।

APISIX Ingress संसाधन के साथ ट्रैफ़िक विभाजन (देखें ApisixRoute/v2 संदर्भ):

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: traffic-split
spec:
  http:
    - name: rule-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /get*
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
          weight: 90
        - serviceName: bare-minimum-api-v2
          servicePort: 8081
          weight: 10

Gateway API के साथ ट्रैफ़िक विभाजन (देखें Canary ट्रैफ़िक रोलआउट):

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: traffic-split
spec:
  hostnames:
  - local.navendu.me
  rules:
  - backendRefs:
    - name: bare-minimum-api-v1
      port: 8080
      weight: 90
    - name: bare-minimum-api-v2
      port: 8081
      weight: 10

Ingress API से एक और सुधार यह है कि Gateway API चिंताओं को अलग करता है। Ingress के साथ, एप्लिकेशन डेवलपर और क्लस्टर ऑपरेटर एक ही Ingress ऑब्जेक्ट पर काम करते हैं, दूसरे की जिम्मेदारियों से अनजान होते हैं और गलत कॉन्फ़िगरेशन के लिए दरवाजा खोलते हैं।

Gateway API कॉन्फ़िगरेशन को Route और Gateway ऑब्जेक्ट्स में अलग करता है, जिससे एप्लिकेशन डेवलपर और क्लस्टर ऑपरेटर को स्वायत्तता प्रदान करता है। नीचे दिया गया चित्र इसे स्पष्ट रूप से समझाता है:

क्या यह Ingress API का अंत है?

Gateway API अपेक्षाकृत नया है, और इसके कार्यान्वयन लगातार टूट रहे हैं। इसके विपरीत, Ingress API स्थिर रिलीज़ में है और समय की कसौटी पर खरा उतरा है।

यदि आपका उपयोग केस केवल सरल रूटिंग से संबंधित है और यदि आप अतिरिक्त सुविधाओं को प्राप्त करने के लिए कस्टम एनोटेशन्स का उपयोग करने के लिए तैयार हैं, तो Ingress API अभी भी एक ठोस विकल्प है।

Gateway API के Ingress API का सुपरसेट होने के कारण, दोनों को समेकित करना समझदारी हो सकती है। SIG Network समुदाय के लिए धन्यवाद, Gateway API अभी भी बढ़ रहा है और जल्द ही उत्पादन के लिए तैयार हो जाएगा।

अधिकांश Ingress controllers और सेवा मेश ने पहले ही Gateway API को Ingress API के साथ लागू कर दिया है, और जैसे-जैसे परियोजना विकसित होती है, और अधिक कार्यान्वयन सामने आएंगे।

व्यक्तिगत रूप से, कम से कम अभी के लिए, मैं Ingress या Gateway API के बजाय Apache APISIX जैसे Ingress controllers द्वारा प्रदान किए गए कस्टम CRDs के साथ रहूंगा।