Kubernetes Gateway API पर एक त्वरित नज़र

Nicolas Fränkel

Nicolas Fränkel

September 7, 2022

Ecosystem

मेरे हाल के एक ब्लॉग पोस्ट में, मैंने Kubernetes पॉड्स तक पहुंचने के कई तरीकों का वर्णन किया था। कोई भी पॉड तक उसके IP के माध्यम से पहुंच सकता है, लेकिन पॉड्स स्वाभाविक रूप से अस्थायी होते हैं। मानक तरीका एक Service को कॉन्फ़िगर करना है: इसका IP स्थिर होता है, और Kubernetes का काम Service और उसके अंतर्निहित पॉड्स के बीच मैपिंग को अप-टू-डेट रखना है। विभिन्न प्रकार की सेवाएं उपलब्ध हैं: केवल आंतरिक, NodePort जो अंततः क्लस्टर के बाहर से पहुंच की अनुमति देता है, और LoadBalancer जो एक तीसरे पक्ष के घटक पर निर्भर करता है - आमतौर पर, एक क्लाउड प्रदाता। अंत में, मैंने Ingress ऑब्जेक्ट का उल्लेख किया, जो रूटिंग की भी अनुमति देता है।

मैंने जानबूझकर नए बच्चे, Gateway API को छोड़ दिया। यह इस पोस्ट का विषय है।

Ingress से Gateway API तक

Kubernetes पॉड्स तक बाहरी पहुंच कई विकासवादी चरणों से गुजरी है, उदाहरण के लिए, Ingress LoadBalancer में रूटिंग की कमी की समस्या का उत्तर है। Ingress की सबसे बड़ी समस्या इसकी "प्रोप्राइटरी" ऑब्जेक्ट्स पर निर्भरता है। एक अनुस्मारक के रूप में, यहां Apache APISIX का उपयोग करके रूटिंग बनाने का स्निपेट है:

apiVersion: apisix.apache.org/v2beta3 #1
kind: ApisixRoute #1
metadata:
  name: apisix-route
spec:
  http:
    - name: left
      match:
        paths:
          - "/left"
      backends:
        - serviceName: left
          servicePort: 80
    - name: right
      match:
        paths:
          - "/right"
      backends:
        - serviceName: right
          servicePort: 80
  1. प्रोप्राइटरी ऑब्जेक्ट्स

प्रोप्राइटरी ऑब्जेक्ट्स माइग्रेशन के समय एक समस्या होती हैं। हालांकि एक प्रदाता से दूसरे प्रदाता में माइग्रेशन शायद असामान्य है, यह यथासंभव सहज होना चाहिए। प्रोप्राइटरी ऑब्जेक्ट्स का उपयोग करते समय, आपको पहले पुराने ऑब्जेक्ट से नए ऑब्जेक्ट्स में मैपिंग करने की आवश्यकता होती है। संभावना है कि यह एक-से-एक मैपिंग नहीं होगी। फिर, आपको स्पेसिफिकेशन को नए मॉडल में अनुवाद करने की आवश्यकता होती है: यह एक पूर्ण परियोजना होने की संभावना है।

Gateway API का विचार मानक ऑब्जेक्ट्स और प्रोप्राइटरी कार्यान्वयन के बीच एक साफ अलगाव रखना है।

Gateway API

Gateway API SIG-NETWORK समुदाय द्वारा प्रबंधित एक ओपन सोर्स प्रोजेक्ट है। यह Kubernetes में सर्विस नेटवर्किंग को मॉडल करने वाले संसाधनों का एक संग्रह है। ये संसाधन - GatewayClass, Gateway, HTTPRoute, TCPRoute, Service, आदि - Kubernetes सर्विस नेटवर्किंग को एक्सप्रेसिव, एक्स्टेंसिबल, और रोल-ओरिएंटेड इंटरफेस के माध्यम से विकसित करने का लक्ष्य रखते हैं जो कई विक्रेताओं द्वारा कार्यान्वित किए जाते हैं और व्यापक उद्योग समर्थन प्राप्त करते हैं।

-- https://gateway-api.sigs.k8s.io

उपरोक्त परिभाषा एक संगठनात्मक चिंता का भी उल्लेख करती है: विभिन्न भूमिकाओं को विभिन्न ऑब्जेक्ट्स के सेट को प्रबंधित करना चाहिए।

Gateway API Model

चित्र gateway-api.sigs.k8s.io से

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

Gateway API के माध्यम से पॉड एक्सेस कॉन्फ़िगर करना

आइए पहले कॉन्फ़िगर किए गए Ingress को Gateway API से बदलें। इसके लिए कई चरण आवश्यक हैं।

नए Gateway CRDs इंस्टॉल करें

k apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.5.0/standard-install.yaml

एक कार्यान्वयन इंस्टॉल करें

मैं Apache APISIX का उपयोग करूंगा। वैकल्पिक रूप से, SIG वेबसाइट कार्यान्वयनों की एक सूची बनाए रखती है।

helm install apisix apisix/apisix \
  --namespace ingress-apisix \
  --create-namespace \
  --devel \                                                                #1
  --set gateway.type=NodePort \                                            #2
  --set gateway.http.nodePort=30800 \                                      #2
  --set ingress-controller.enabled=true \                                  #2
  --set ingress-controller.config.kubernetes.enableApiGateway=true \       #3
  --set ingressPublishService="ingress-apisix/apisix-gateway"              #4
  1. --devel विकल्प के बिना, Helm latest रिलीज़ इंस्टॉल करता है, जो Gateway API के साथ काम नहीं करता है
  2. गेटवे को क्लस्टर के बाहर से पहुंच योग्य होना चाहिए
  3. यहां जादू होता है!
  4. मैं बाद में इस पर वापस आऊंगा

आइए जांचें कि सब कुछ काम कर रहा है:

k get all -n ingress-apisix

NAME                                             READY   STATUS    RESTARTS   AGE
pod/apisix-5fc9b45c69-cf42m                      1/1     Running   0          14m    #1
pod/apisix-etcd-0                                1/1     Running   0          14m    #2
pod/apisix-etcd-1                                1/1     Running   0          14m    #2
pod/apisix-etcd-2                                1/1     Running   0          14m    #2
pod/apisix-ingress-controller-6f8bd94d9d-wkzfn   1/1     Running   0          14m    #3

NAME                                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)
service/apisix-admin                ClusterIP   10.96.69.19     <none>        9180/TCP
service/apisix-etcd                 ClusterIP   10.96.226.79    <none>        2379/TCP,2380/TCP
service/apisix-etcd-headless        ClusterIP   None            <none>        2379/TCP,2380/TCP
service/apisix-gateway              NodePort    10.96.101.224   <none>        80:30800/TCP #4
service/apisix-ingress-controller   ClusterIP   10.96.141.230   <none>        80/TCP
  1. Apache APISIX स्वयं
  2. Apache APISIX अपनी कॉन्फ़िगरेशन etcd में संग्रहीत करता है। चार्ट डिफ़ॉल्ट रूप से तीन पॉड्स शेड्यूल करता है, वितरित सिस्टम में विफलताओं को संभालने के लिए एक अच्छा अभ्यास
  3. Apache APISIX कंट्रोलर: एक Kubernetes कंट्रोलर एक कंट्रोल लूप है जो मौजूदा स्थिति को वांछित स्थिति की ओर ले जाता है
  4. Apache APISIX गेटवे सेवा: यह NodePort Service है जिसे हमने Helm चार्ट के माध्यम से इंस्टॉल किया है। यह वह नाम भी है जिसे हमने Helm चार्ट इंस्टॉल के दौरान संदर्भित किया था - ingressPublishService

इस बिंदु पर, इंफ्रास्ट्रक्चर तैयार है।

गेटवे कार्यान्वयन घोषित करें

जैसा कि मैंने ऊपर उल्लेख किया है, API स्पेसिफिकेशन और कार्यान्वयन के बीच एक साफ अलगाव बनाता है। हालांकि, हमें इसे किसी तरह बांधने की आवश्यकता है। यह GatewayClass ऑब्जेक्ट की जिम्मेदारी है:

apiVersion: gateway.networking.k8s.io/v1alpha2 #1
kind: GatewayClass #2
metadata:
  name: apisix-gateway-class #3
spec:
  controllerName: apisix.apache.org/gateway-controller #4
  1. हम जानबूझकर नवीनतम संस्करण का उपयोग नहीं कर रहे हैं, क्योंकि Apache APISIX इस संस्करण का उपयोग करता है। ध्यान दें कि यह (निकट) भविष्य में विकसित होगा
  2. GatewayClass ऑब्जेक्ट
  3. इसे जैसे चाहें नाम दें; हालांकि, हम बाद में गेटवे क्लास को संदर्भित करने के लिए इसका उपयोग करेंगे
  4. कंट्रोलर का नाम कार्यान्वयन पर निर्भर करता है। यहां, हम Apache APISIX का उपयोग कर रहे हैं।

ध्यान दें कि GatewayClass का क्लस्टर-वाइड स्कोप होता है। यह मॉडल हमें विभिन्न Gateway API कार्यान्वयन घोषित करने और उन्हें एक ही क्लस्टर के अंदर समानांतर में उपयोग करने की अनुमति देता है।

गेटवे बनाएं

Apache APISIX के साथ, यह काफी सीधा है:

apiVersion: gateway.networking.k8s.io/v1alpha2 #1
kind: Gateway #2
metadata:
  name: apisix-gateway
spec:
  gatewayClassName: apisix-gateway-class #3
  listeners: #4
    - name: http
      protocol: HTTP
      port: 80
  1. ऊपर के समान नेमस्पेस
  2. Gateway ऑब्जेक्ट
  3. पहले घोषित गेटवे क्लास को संदर्भित करें
  4. इस स्तर पर कुछ प्रतिबंधों की अनुमति दें ताकि क्लस्टर ऑपरेटर अवांछित उपयोग से बच सके

चेतावनी: Gateway API ऑपरेटर पक्ष पर पोर्ट को डायनामिकली बदलने का विकल्प निर्दिष्ट करता है। इस लेखन के समय, Apache APISIX का पोर्ट आवंटन स्टैटिक है। योजना है कि इसे भविष्य में डायनामिक बनाया जाए। कृपया इस GitHub issue को सब्सक्राइब करें ताकि प्रगति का पालन कर सकें।

रूट्स, रूट्स, हर जगह रूट्स

अब तक, सब कुछ इंफ्रास्ट्रक्चर था; हम अंततः रूटिंग कॉन्फ़िगर कर सकते हैं।

मैं पिछले पोस्ट में जैसी रूटिंग चाहता हूं; एक /left शाखा और एक right शाखा। संक्षिप्तता के लिए, मैं बाद वाले को छोड़ दूंगा।

apiVersion: gateway.networking.k8s.io/v1alpha2 #1
kind: HTTPRoute #2
metadata:
  name: left
spec:
  parentRefs:
    - name: apisix-gateway #3
  rules:
    - matches: #4
        - path: #4
            type: PathPrefix #4
            value: /left
      backendRefs: #5
        - name: left #5
          port: 80 #5
  1. ऊपर के समान नेमस्पेस
  2. HTTPRoute ऑब्जेक्ट
  3. ऊपर बनाए गए Gateway को संदर्भित करें
  4. नियम मिलान। हमारे मामले में, हम एक पथ उपसर्ग के संबंध में मिलान करते हैं, लेकिन बहुत सारे नियम उपलब्ध हैं। आप क्वेरी पैरामीटर, हेडर, आदि के आधार पर मिलान कर सकते हैं।
  5. "अपस्ट्रीम" को आगे भेजने के लिए। हमने पिछले ब्लॉग पोस्ट में left Service को परिभाषित किया था।

जांचें कि यह काम करता है

अब जब हमने अपने रूट्स को कॉन्फ़िगर कर लिया है, तो हम जांच सकते हैं कि यह काम करता है।

curl localhost:30800/left

जब हमने Helm चार्ट इंस्टॉल किया, तो हमने Apache APISIX को पोर्ट 30800 पर एक NodePort सेवा बनाने के लिए कहा। इसलिए, हम क्लस्टर के बाहर से सेवा तक पहुंचने के लिए पोर्ट का उपयोग कर सकते हैं।

left

निष्कर्ष

क्लस्टर के बाहर से पॉड तक पहुंचने के लिए कई विकल्प उपलब्ध हैं। CNCF ने उनमें से अधिकांश को पिछले वाले में सुधार करने के लिए जोड़ा है।

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

इस पोस्ट के लिए पूरा स्रोत कोड GitHub पर पाया जा सकता है।

आगे जाने के लिए:

Tags:
Kubernetes
Gateway API