Kubernetes Gateway API v1.0: क्या आपको स्विच करना चाहिए?

Kubernetes Gateway API ने अपना v1.0 रिलीज़ किए हुए एक महीने से अधिक समय हो चुका है, जो इसके कुछ प्रमुख APIs के सामान्य रूप से उपलब्ध स्थिति में स्नातक होने का संकेत देता है।

मैंने Gateway API के बारे में तब लिखा था जब यह पिछले साल बीटा स्थिति में स्नातक हुआ था, लेकिन एक साल बाद भी, सवाल अभी भी बना हुआ है। क्या आपको Ingress API से Gateway API पर स्विच करना चाहिए?

मेरा पिछले साल का जवाब था कि आपको नहीं करना चाहिए। और मेरे पास इसके मजबूत कारण थे।

Gateway API और इसके कार्यान्वयन अभी भी अपने शुरुआती चरण में थे। दूसरी ओर, Ingress API स्थिर था और कुछ प्राथमिक उपयोग के मामलों को कवर करता था जो अधिकांश उपयोगकर्ताओं के लिए काम कर सकते थे।

अधिक क्षमताओं की आवश्यकता वाले उपयोगकर्ताओं के लिए, मैंने Ingress कंट्रोलर्स द्वारा प्रदान किए गए कस्टम रिसोर्सेस का उपयोग करने का सुझाव दिया था, जिसमें पोर्टेबिलिटी (विभिन्न Ingress कार्यान्वयनों के बीच स्विच करना) का त्याग करना पड़ता था।

v1.0 रिलीज़ के साथ, यह बदल सकता है। Gateway API अब कहीं अधिक सक्षम है, और इसके 20+ कार्यान्वयन तेजी से आगे बढ़ रहे हैं।

इसलिए, यदि आप नए सिरे से शुरू कर रहे हैं और Ingress और Gateway API के बीच चयन कर रहे हैं, तो मैं सुझाव दूंगा कि यदि API और आपके द्वारा चुना गया कार्यान्वयन आपके सभी आवश्यक फीचर्स को सपोर्ट करता है, तो आप Gateway API को चुनें।

Ingress API में क्या गलत है?

Ingress API बहुत अच्छी तरह से काम करता है, लेकिन केवल सामान्य उपयोग के मामलों के एक छोटे सेट के लिए। इसकी क्षमताओं को बढ़ाने के लिए, Ingress कार्यान्वयन ने कस्टम एनोटेशन्स का उपयोग करना शुरू कर दिया।

उदाहरण के लिए, यदि आपने Nginx Ingress चुना है, तो आप इसके दर्जनों एनोटेशन्स में से कुछ का उपयोग करेंगे, जो पोर्टेबल नहीं हैं यदि आप किसी अन्य Ingress कार्यान्वयन जैसे Apache APISIX पर स्विच करने का निर्णय लेते हैं।

ये कार्यान्वयन-विशिष्ट एनोटेशन्स प्रबंधित करने में भी कठिन होते हैं और Kubernetes-नेटिव तरीके से Ingress को प्रबंधित करने के उद्देश्य को हरा देते हैं।

अंततः, Ingress कंट्रोलर कार्यान्वयन ने Kubernetes उपयोगकर्ताओं को अधिक फीचर्स प्रदान करने के लिए अपने स्वयं के CRDs विकसित करना शुरू कर दिया। ये CRDs Ingress कंट्रोलर के लिए विशिष्ट होते हैं। लेकिन यदि आप पोर्टेबिलिटी का त्याग कर सकते हैं और एक Ingress कंट्रोलर पर टिके रह सकते हैं, तो CRDs के साथ काम करना आसान होता है और ये अधिक फीचर्स प्रदान करते हैं।

Gateway API का उद्देश्य इस समस्या को एक बार और सभी के लिए हल करना है, Ingress API के वेंडर एग्नोस्टिसिज्म और CRDs की लचीलापन प्रदान करके। यह इस लक्ष्य को प्राप्त करने के लिए बहुत अच्छी तरह से स्थित है।

लंबे समय में, Ingress API से किसी नए फीचर की उम्मीद नहीं की जाती है, और सभी प्रयास Gateway API के साथ मिलाने के लिए किए जाएंगे। इसलिए, Ingress API को अपनाने से समस्याएं हो सकती हैं जब आप अनजाने में इसकी क्षमताओं की सीमाओं से टकराते हैं।

स्पष्ट लाभ

व्यक्तिपरक, विस्तार योग्य, और भूमिका-उन्मुख Gateway API के विकास को आकार देने वाले प्रमुख विचार हैं।

Ingress API के विपरीत, Gateway API कई APIs (HTTPRoute, Gateway, GatewayClass, आदि) का एक संग्रह है, जिनमें से प्रत्येक विभिन्न संगठनात्मक भूमिकाओं को पूरा करता है।

उदाहरण के लिए, एप्लिकेशन डेवलपर्स को केवल HTTPRoute रिसोर्स की परवाह करनी होती है, जहां वे ट्रैफ़िक को रूट करने के लिए नियम परिभाषित कर सकते हैं। वे क्लस्टर-स्तरीय विवरण को एक ऑपरेटर को सौंप सकते हैं जो क्लस्टर को प्रबंधित करता है और यह सुनिश्चित करता है कि यह डेवलपर्स की आवश्यकताओं को पूरा करता है, Gateway रिसोर्स का उपयोग करके।

API का यह भूमिका-उन्मुख डिज़ाइन अलग-अलग लोगों को क्लस्टर का उपयोग करने की अनुमति देता है, जबकि नियंत्रण बनाए रखता है।

Gateway API, Ingress API की तुलना में कहीं अधिक सक्षम है। Ingress API में एनोटेशन्स की आवश्यकता वाले फीचर्स, Gateway API में बॉक्स से बाहर सपोर्ट किए जाते हैं।

एक आधिकारिक एक्सटेंशन

हालांकि Gateway API एक आधिकारिक Kubernetes API है, यह CRDs के एक सेट के रूप में कार्यान्वित किया गया है।

यह डिफ़ॉल्ट Kubernetes रिसोर्सेस का उपयोग करने से अलग नहीं है। लेकिन आपको इन CRDs को एक आधिकारिक एक्सटेंशन की तरह इंस्टॉल करना होगा।

यह Kubernetes की तुलना में तेजी से पुनरावृत्ति की अनुमति देता है, जो धीरे-धीरे दीर्घकालिक स्थिरता की ओर बढ़ रहा है।

क्या यह फैल जाएगा?

जैसा कि यह प्रसिद्ध XKCD कॉमिक हमें अक्सर याद दिलाता है, मानक फैलने की प्रवृत्ति रखते हैं।

इसका एक संस्करण Ingress और Gateway APIs में देखा गया था। यह आमतौर पर इस तरह से होता है:

1. विभिन्न प्रोजेक्ट्स/उनके मानकों को एकीकृत करने के लिए एक मानक उभरता है (Kubernetes Ingress API)।
2. एकीकृत मानक की सीमाएं होती हैं जिन्हें कार्यान्वयनकर्ता दूर करना चाहते हैं (Ingress API सीमित था)।
3. इन सीमाओं के कारण कार्यान्वयन मानक से अलग हो जाते हैं (कस्टम CRDs, एनोटेशन्स)।
4. प्रत्येक कार्यान्वयन का अब अपना मानक होता है (गैर-पोर्टेबल CRDs, एनोटेशन्स)।
5. इन विभिन्न मानकों को एकीकृत करने के लिए एक नया मानक उभरता है (Kubernetes Gateway API)।

यह सोचना उचित है कि Gateway API यहां अंतिम समाधान नहीं हो सकता है। लेकिन मेरा मानना है कि इसमें Kubernetes में रूटिंग के लिए मानक बनने की हर संभावना है।

फिर से, मेरे पास इसके मजबूत कारण हैं।

मानक फैलाव को रोकने के लिए व्यापक अपनाना महत्वपूर्ण है क्योंकि कार्यान्वयनों के लिए एक अलग मानक पर काम करने के लिए कम प्रोत्साहन होते हैं। Gateway API के पास पहले से ही 25 से अधिक कार्यान्वयन हैं।

एक कार्यान्वयन Gateway API के साथ विभिन्न स्तरों पर अनुरूप हो सकता है:

1. कोर: सभी कार्यान्वयनों से इनका अनुरूप होने की उम्मीद की जाती है।
2. विस्तारित: ये केवल कुछ कार्यान्वयनों में उपलब्ध हो सकते हैं लेकिन मानक APIs हैं।
3. कार्यान्वयन-विशिष्ट: कार्यान्वयनों के लिए विशिष्ट लेकिन मानक एक्सटेंशन पॉइंट्स के माध्यम से जोड़े गए।

एक निच फीचर कार्यान्वयन-विशिष्ट से विस्तारित और फिर कोर में जा सकता है क्योंकि अधिक कार्यान्वयन इन फीचर्स को सपोर्ट करते हैं। यानी, API कस्टम एक्सटेंशन के लिए जगह प्रदान करता है, जबकि यह सुनिश्चित करता है कि यह मानक का पालन करता है।

सर्विस मेश इंटरफ़ेस (SMI) प्रोजेक्ट Kubernetes में सर्विस मेश को कॉन्फ़िगर करने के लिए मानकीकृत करने का एक समान प्रयास था। हालांकि, प्रोजेक्ट को सर्विस मेश प्रोजेक्ट्स की प्रारंभिक भागीदारी के बाद कम ट्रैक्शन मिला और धीरे-धीरे समाप्त हो गया।

SMI ने कई सामान्य फीचर्स का समर्थन नहीं किया जो उपयोगकर्ताओं को एक सर्विस मेश में उम्मीद थे। यह इन फीचर्स को सपोर्ट करने के लिए पर्याप्त तेजी से आगे भी नहीं बढ़ा। अंततः, सर्विस मेश कार्यान्वयन SMI के अनुरूप होने में पिछड़ गए (मैं CNCF TAG Network के तहत SMI के साथ एक प्रोजेक्ट पर काम करता था जो SMI अनुरूपता की रिपोर्ट करता था)।

ये सार्वभौमिक कारण हैं, लेकिन प्रोजेक्ट को अब Gateway API के माध्यम से पुनर्जीवित किया जा रहा है। सर्विस मेश प्रबंधन और प्रशासन के लिए Gateway API (GAMMA) पहल का उद्देश्य Gateway API को सर्विस मेश के साथ काम करने के लिए विस्तारित करना है।

SMI प्रोजेक्ट हाल ही में GAMMA पहल के साथ मर्ज हो गया, जो Gateway API के लिए बहुत अच्छा है। Istio, निस्संदेह सबसे लोकप्रिय सर्विस मेश, ने भी घोषणा की कि भविष्य में Istio को प्रबंधित करने के लिए Gateway API डिफ़ॉल्ट API होगा। ऐसे अपनाने फैलाव को रोकते हैं।

माइग्रेशन गाइड

Gateway API डॉक्यूमेंटेशन में आपके Ingress रिसोर्सेस को Gateway रिसोर्सेस में माइग्रेट करने के लिए एक व्यापक गाइड है। इसे दोहराने के बजाय, आइए ingress2gateway टूल का उपयोग करके हमारे Ingress रिसोर्सेस को संबंधित Gateway API रिसोर्सेस में कन्वर्ट करने का प्रयास करें।

आप रिलीज़ पेज से सीधे अपने ऑपरेटिंग सिस्टम के लिए बाइनरी डाउनलोड और इंस्टॉल कर सकते हैं।

आइए एक सरल Ingress रिसोर्स लें:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

यह प्रदान किए गए होस्ट एड्रेस के साथ सभी ट्रैफ़िक को httpbin सर्विस पर रूट करेगा।

इसे Gateway API रिसोर्स में कन्वर्ट करने के लिए, हम चला सकते हैं:

ingress2gateway print --input_file=ingress.yaml

यह Gateway API रिसोर्स नीचे दिखाए गए अनुसार होगा:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

व्यवहार्य विकल्प

Kubernetes में गेटवे कॉन्फ़िगर करने के लिए अन्य व्यवहार्य विकल्प भी हैं।

Apache APISIX में, आप इसे स्टैंडअलोन मोड में डिप्लॉय कर सकते हैं और एक yaml फ़ाइल में रूट कॉन्फ़िगरेशन परिभाषित कर सकते हैं। आप इस yaml फ़ाइल को पारंपरिक वर्कफ़्लोज़ के माध्यम से अपडेट कर सकते हैं, और यह उन परिदृश्यों में काफी मददगार हो सकता है जहां Kubernetes API के माध्यम से गेटवे कॉन्फ़िगरेशन को प्रबंधित करने की आवश्यकता नहीं होती है।

कार्यान्वयन-विशिष्ट कस्टम CRDs भी व्यवहार्य विकल्प हैं यदि आप किसी अलग समाधान पर स्विच करने की योजना नहीं बना रहे हैं या यदि आपका कॉन्फ़िगरेशन इतना छोटा है कि इसे आसानी से माइग्रेट किया जा सकता है।

किसी भी स्थिति में, Gateway API यहां रहने के लिए है।