API Gateways, Kubernetes Gateways, और Service Meshes की एक व्यापक तुलना
June 9, 2023
API गेटवे, Kubernetes गेटवे, और सर्विस मेश के बारे में अभी भी बहुत भ्रम है। इसका मुख्य कारण यह है:
- लोग अक्सर इन तकनीकों को एक ही कीवर्ड्स के साथ उल्लेख करते हैं, जैसे कि canary deployments, rate limiting, और service discovery।
- ये सभी तकनीकें रिवर्स प्रॉक्सी का उपयोग करती हैं।
- कुछ API गेटवे के अपने Kubernetes गेटवे और सर्विस मेश होते हैं और इसके विपरीत भी।
- बहुत सारे लेख/वीडियो हैं जो इन तीनों तकनीकों की तुलना करते हैं और यह निष्कर्ष निकालते हैं कि एक दूसरे से बेहतर क्यों है।
इस लेख में, मैं इन तकनीकों को समझाने की कोशिश करूंगा और यह साझा करूंगा कि वे मूल रूप से कैसे भिन्न हैं और विभिन्न उपयोग के मामलों को कैसे पूरा करते हैं।
API गेटवे
एक API गेटवे आपके क्लाइंट एप्लिकेशन और आपके API के बीच में बैठता है। यह सभी क्लाइंट अनुरोधों को स्वीकार करता है, उन्हें आवश्यक API तक फॉरवर्ड करता है, और क्लाइंट को प्रतिक्रिया एक संयुक्त पैकेज में वापस करता है।
यह मूल रूप से एक रिवर्स प्रॉक्सी है जिसमें बहुत सारी क्षमताएं होती हैं।
इसके अलावा, एक API गेटवे में प्रमाणीकरण, सुरक्षा, सूक्ष्म ट्रैफिक नियंत्रण, और मॉनिटरिंग जैसी सुविधाएं भी हो सकती हैं, जिससे API डेवलपर्स को केवल व्यावसायिक आवश्यकताओं पर ध्यान केंद्रित करने की आवश्यकता होती है।
कई API गेटवे समाधान उपलब्ध हैं। कुछ लोकप्रिय मुफ्त और ओपन सोर्स समाधान हैं:
- Apache APISIX: Nginx के ऊपर बना एक उच्च-प्रदर्शन, विस्तार योग्य, क्लाउड नेटिव API गेटवे।
- Gloo Edge: Envoy प्रॉक्सी के ऊपर बना एक API गेटवे।
- Kong: Nginx पर बना एक प्लगइन योग्य API गेटवे।
- Tyk: Go में लिखा गया एक API गेटवे जो REST, GraphQL, TCP, और gRPC प्रोटोकॉल का समर्थन करता है।
क्लाउड प्लेटफॉर्म जैसे GCP, AWS, और Azure के अपने स्वामित्व वाले API गेटवे भी हैं।
API गेटवे, Kubernetes गेटवे, और सर्विस मेश canary deployments का समर्थन करते हैं—धीरे-धीरे एक नया सॉफ्टवेयर संस्करण उपयोगकर्ताओं के एक छोटे समूह के लिए रोल आउट करना इससे पहले कि इसे सामान्य रूप से उपलब्ध कराया जाए।
नीचे दिया गया उदाहरण दिखाता है कि Apache APISIX में canary deployment को कैसे कॉन्फ़िगर किया जाए।
आप निम्नलिखित कॉन्फ़िगरेशन के साथ APISIX Admin API को एक अनुरोध भेज सकते हैं:
curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri":"/*", "plugins":{ "traffic-split":{ "rules":[ { "weighted_upstreams":[ { "upstream":{ "name":"api-v1", "type":"roundrobin", "nodes":{ "api-v1:8080":1 } }, "weight":95 }, { "weight":5 } ] } ] } }, "upstream":{ "type":"roundrobin", "nodes":{ "api-v2:8080":1 } } }'
APISIX अब 95% ट्रैफिक को api-v1 सेवा और 5% ट्रैफिक को api-v2 सेवा पर रूट करेगा।
Kubernetes गेटवे
Kubernetes गेटवे केवल Kubernetes-नेटिव API गेटवे हैं। यानी, आप इन API गेटवे को Kubernetes API के साथ प्रबंधित कर सकते हैं, जैसे कि Kubernetes पॉड, सेवा, या डिप्लॉयमेंट।
Kubernetes में, आपके API क्लस्टर में डिप्लॉय किए गए पॉड और सेवाएं हैं। फिर आप एक Kubernetes गेटवे का उपयोग करके बाहरी ट्रैफिक को अपने क्लस्टर पर डायरेक्ट करते हैं।
Kubernetes इसे प्राप्त करने के लिए दो API प्रदान करता है, Ingress API और Gateway API.
Kubernetes Ingress API
Ingress API को डिफ़ॉल्ट सेवा प्रकारों, NodePort और LoadBalancer, की सीमाओं को दूर करने के लिए बनाया गया था, जिसमें रूटिंग और SSL टर्मिनेशन जैसी सुविधाएं शामिल हैं। इसने यह भी मानकीकृत किया कि आप Kubernetes सेवाओं को बाहरी ट्रैफिक के लिए कैसे एक्सपोज़ करते हैं।
इसके दो घटक हैं, Ingress और Ingress controller.
Ingress Kubernetes नेटिव ऑब्जेक्ट एक सेट ऑफ रूल्स को परिभाषित करता है कि बाहरी ट्रैफिक आपकी सेवाओं तक कैसे पहुंच सकता है।
यह उदाहरण कॉन्फ़िगरेशन दिखाता है कि Kubernetes Ingress ऑब्जेक्ट के साथ URI पथ के आधार पर ट्रैफिक को कैसे रूट किया जाए:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-routes spec: ingressClassName: apisix rules: - http: paths: - backend: service: name: api-v1 port: number: 8080 path: /v1 pathType: Exact - backend: service: name: api-v2 port: number: 8080 path: /v2 pathType: Exact
एक Ingress controller इन नियमों को लागू करता है और एक रिवर्स प्रॉक्सी का उपयोग करके ट्रैफिक को आपके क्लस्टर पर रूट करता है।
20 से अधिक Ingress controller इम्प्लीमेंटेशन हैं। APISIX में एक Ingress controller है जो APISIX API गेटवे को Kubernetes Ingress के रूप में काम करने के लिए रैप करता है।
APISIX Ingress controller Kubernetes Ingress ऑब्जेक्ट को APISIX कॉन्फ़िगरेशन में परिवर्तित करता है।
APISIX फिर इस कॉन्फ़िगरेशन को लागू करता है।
आप APISIX को किसी अन्य Ingress controller के साथ स्वैप कर सकते हैं, क्योंकि Ingress API किसी विशिष्ट इम्प्लीमेंटेशन से बंधा नहीं है।
यह वेंडर न्यूट्रैलिटी सरल कॉन्फ़िगरेशन के लिए अच्छी तरह से काम करती है। लेकिन अगर आप canary deployment जैसी जटिल रूटिंग करना चाहते हैं, तो आपको वेंडर-विशिष्ट एनोटेशन पर निर्भर रहना होगा।
नीचे दिया गया उदाहरण दिखाता है कि Nginx Ingress का उपयोग करके canary deployment को कैसे कॉन्फ़िगर किया जाए। यहां उपयोग किए गए कस्टम एनोटेशन Nginx के लिए विशिष्ट हैं:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "5" name: api-canary spec: rules: - http: paths: - backend: serviceName: api-v2 servicePort: 8080 path: /
उपरोक्त कॉन्फ़िगरेशन 5% ट्रैफिक को api-v2 सेवा पर रूट करेगा।
एनोटेशन के अलावा, APISIX जैसे Ingress controllers के पास Ingress API की सीमाओं को दूर करने के लिए कस्टम Kubernetes CRDs हैं।
नीचे दिया गया उदाहरण APISIX CRD, ApisixRoute का उपयोग करके canary deployment को कॉन्फ़िगर करता है:
apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: api-canary spec: http: - name: route match: paths: - /* backends: - serviceName: api-v1 servicePort: 8080 weight: 95 - serviceName: api-v2 servicePort: 8080 weight: 5
इन कस्टम CRDs ने Ingress को कॉन्फ़िगर करना और अंतर्निहित API गेटवे की पूरी क्षमताओं का लाभ उठाना बहुत आसान बना दिया है, लेकिन पोर्टेबिलिटी की कीमत पर।
Kubernetes Gateway API
Gateway API एक नया Kubernetes ऑब्जेक्ट है जो Ingress API को "ठीक" करने का लक्ष्य रखता है।
यह Ingress controllers द्वारा विकसित कस्टम CRDs से प्रेरणा लेता है ताकि HTTP हेडर-आधारित मिलान, वेटेड ट्रैफिक स्प्लिटिंग, और अन्य सुविधाएं जोड़ सके जो Ingress API के साथ कस्टम स्वामित्व वाले एनोटेशन की आवश्यकता होती हैं।
नीचे दिया गया उदाहरण दिखाता है कि Kubernetes Gateway API के साथ canary deployment को कैसे कॉन्फ़िगर किया जाए:
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: api-canary spec: rules: - backendRefs: - name: api-v1 port: 8080 weight: 95 - name: api-v2 port: 8080 weight: 5
कोई भी Ingress controller (जो Gateway API को इम्प्लीमेंट करता है) अब इस कॉन्फ़िगरेशन को लागू कर सकता है।
Gateway API ने Ingress API पर कई सुधार भी किए हैं, लेकिन यह अभी भी अल्फा में है, और Gateway API इम्प्लीमेंटेशन लगातार बदल रहे हैं।
सर्विस मेश
API गेटवे और Kubernetes गेटवे एप्लिकेशन सीमाओं के पार काम करते हैं और एज समस्याओं को हल करते हैं जबकि आपके API को एब्स्ट्रैक्ट करते हैं।
सर्विस मेश एक अलग चुनौती को हल करते हैं।
एक सर्विस मेश सेवा-से-सेवा संचार (ईस्ट-वेस्ट ट्रैफिक) के बारे में अधिक चिंतित होता है न कि सेवा-क्लाइंट संचार (नॉर्थ-साउथ ट्रैफिक) के बारे में।
आमतौर पर, यह API/सेवाओं के साथ साइडकार प्रॉक्सी को डिप्लॉय करके प्राप्त किया जाता है।
यहां, साइडकार प्रॉक्सी सेवा-से-सेवा संचार को संभालते हैं बजाय इसके कि डेवलपर को सेवाओं में नेटवर्किंग लॉजिक को कोड करना पड़े।
कई सर्विस मेश उपलब्ध हैं। कुछ लोकप्रिय हैं:
- Istio: अब तक का सबसे लोकप्रिय सर्विस मेश। यह Envoy proxy के ऊपर बना है, जिसका उपयोग कई सर्विस मेश करते हैं।
- Linkerd: एक हल्का सर्विस मेश जो linkerd2-proxy का उपयोग करता है, जो विशेष रूप से Linkerd के लिए Rust में लिखा गया है।
- Consul Connect: एक सर्विस मेश जो सुरक्षा और ऑब्जर्वेबिलिटी पर जोर देता है। यह या तो एक बिल्ट-इन प्रॉक्सी या Envoy के साथ काम कर सकता है।
Cilium जैसे नए सर्विस मेश ऑफरिंग साइडकार-आधारित सर्विस मेश के विकल्प प्रदान करते हैं जो eBPF के माध्यम से कर्नेल से सीधे नेटवर्किंग क्षमताओं का उपयोग करते हैं।
एक सामान्य सर्विस मेश को 8 सेवाओं के लिए 8 प्रॉक्सी की आवश्यकता होती है जबकि eBPF-आधारित सर्विस मेश जैसे Cilium को नहीं। Cilium Service Mesh – Everything You Need to Know से अनुकूलित।
सर्विस मेश में नॉर्थ-साउथ ट्रैफिक को संभालने के लिए बेसिक इनग्रेस/एग्रेस गेटवे भी होते हैं। इनग्रेस गेटवे एक सर्विस मेश में बाहरी ट्रैफिक के प्रवेश बिंदु होते हैं, और एग्रेस गेटवे मेश के अंदर की सेवाओं को बाहरी सेवाओं तक पहुंचने की अनुमति देते हैं।
Apache APISIX में भी एक सर्विस मेश इम्प्लीमेंटेशन है जिसे Amesh कहा जाता है। यह Istio के कंट्रोल प्लेन के साथ xDS प्रोटोकॉल का उपयोग करके काम करता है और साइडकार में डिफ़ॉल्ट Envoy प्रॉक्सी को प्रतिस्थापित करता है।
एक सर्विस मेश आपको canary deployments को कॉन्फ़िगर करने देता है। उदाहरण के लिए, आप एक सेवा से अनुरोधों को दूसरी सेवा के दो संस्करणों के बीच विभाजित कर सकते हैं।
नीचे दिया गया उदाहरण दिखाता है कि Istio सर्विस मेश के साथ canary deployment को कैसे कॉन्फ़िगर किया जाए:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: api-virtual-service spec: hosts: - api http: - route: - destination: host: api subset: v1 weight: 80 - destination: host: api subset: v2 weight: 20
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: api-destination-rule spec: host: api subsets: - name: v1 labels: version: "1.0" - name: v2 labels: version: "2.0"
ये कॉन्फ़िगरेशन Istio के लिए विशिष्ट हैं। एक अलग सर्विस मेश पर स्विच करने के लिए, आपको एक अलग लेकिन समान रूप से वेंडर-निर्भर कॉन्फ़िगरेशन बनाना होगा।
सर्विस मेश इंटरफेस (SMI) स्पेसिफिकेशन इस पोर्टेबिलिटी समस्या को हल करने के लिए बनाया गया था।
SMI स्पेसिफिकेशन Kubernetes CRDs का एक सेट है जिसका उपयोग एक सर्विस मेश उपयोगकर्ता सेवा मेश इम्प्लीमेंटेशन से बंधे बिना एप्लिकेशन को परिभाषित करने के लिए कर सकता है।
एक मानकीकरण प्रयास केवल तभी काम करेगा जब सभी प्रोजेक्ट्स इसमें शामिल हों। लेकिन SMI स्पेसिफिकेशन के साथ ऐसा नहीं हुआ, और केवल कुछ प्रोजेक्ट्स ने सक्रिय रूप से भाग लिया।
हाल ही में, Kubernetes SIG Network ने सर्विस मेश का समर्थन करने के लिए Gateway API को विकसित करना शुरू किया है।
GAMMA (Gateway API for Mesh Management and Administration) पहल Gateway API प्रोजेक्ट के साथ एक समर्पित समूह है जिसका लक्ष्य "सर्विस मेश तकनीक और उपयोग के मामलों से संबंधित Gateway API संसाधनों, शब्दार्थ, और अन्य कलाकृतियों की जांच, डिजाइन, और ट्रैक करना है।"
Gateway API Ingress API का एक प्राकृतिक अगला कदम है, लेकिन हमें यह देखना होगा कि यह सर्विस मेश के लिए कैसे काम करेगा। Istio ने घोषणा की है कि वह सभी ट्रैफिक प्रबंधन के लिए Gateway API को अपने डिफ़ॉल्ट API के रूप में उपयोग करने का इरादा रखता है और प्रोजेक्ट को आगे बढ़ाने के लिए काम कर रहा है।
नीचे दिया गया उदाहरण दिखाता है कि Istio में Gateway API के साथ canary deployment को कैसे कॉन्फ़िगर किया जाए। अंतर्निहित विचार गेटवे के बजाय अन्य सेवाओं से जुड़ने के लिए parentRefs का उपयोग करना है:
apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: api-canary spec: parentRefs: - kind: Service name: api-a port: 8080 rules: - backendRefs: - name: api-b-v1 port: 8080 weight: 95 - name: api-b-v2 port: 8080 weight: 5
कुछ चिंताएं हैं कि GAMMA प्रोजेक्ट एक विशेष प्रोजेक्ट की आवश्यकताओं को पूरा करने के लिए पक्षपाती हो सकता है बजाय बड़े समुदाय की, जो अंततः अन्य प्रोजेक्ट्स को अपने स्वयं के API का उपयोग करने के लिए प्रेरित करेगा, जैसा कि कस्टम CRD परिदृश्य में Kubernetes Ingress API के बाद हुआ था।
लेकिन Gateway API प्रोजेक्ट सर्विस मेश में ट्रैफिक प्रबंधन को मानकीकृत करने का सबसे अच्छा प्रयास रहा है। SMI प्रोजेक्ट ने भी GAMMA पहल में शामिल हो गया है एक साझा दृष्टि के साथ और सर्विस मेश प्रोजेक्ट्स द्वारा Gateway API के सुसंगत इम्प्लीमेंटेशन के लिए वकालत करने में मदद करेगा।
अन्य प्रोजेक्ट्स जैसे Flagger और Argo Rollouts ने भी Gateway API के साथ इंटीग्रेट किया है।
आपको क्या उपयोग करना चाहिए?
इस प्रश्न का केवल एक सही उत्तर है; "यह निर्भर करता है।"
यदि आप API विकसित कर रहे हैं और प्रमाणीकरण, सुरक्षा, रूटिंग, या मेट्रिक्स की आवश्यकता है, तो आप अपने API में इसे स्वयं बनाने के बजाय एक API गेटवे का उपयोग करना बेहतर है।
यदि आप Kubernetes वातावरण में कुछ ऐसा ही करना चाहते हैं, तो आपको अपने API गेटवे को Kubernetes पर काम करने के लिए मजबूर करने के बजाय एक Kubernetes गेटवे का उपयोग करना चाहिए। सौभाग्य से, बहुत सारे API गेटवे Kubernetes-नेटिव कॉन्फ़िगरेशन के साथ भी काम करते हैं।
लेकिन कभी-कभी, एक API गेटवे + Ingress controller द्वारा प्रदान की जाने वाली सुविधाएं Kubernetes वातावरण के लिए अधिक हो सकती हैं, और आप सरल ट्रैफिक प्रबंधन पर वापस स्विच करना चाह सकते हैं।
दूसरी ओर, सर्विस मेश पूरी तरह से अलग समस्याओं को हल करते हैं। वे नॉर्थ-साउथ ट्रैफिक को संभालने के लिए अपने स्वयं के गेटवे भी लाते हैं (आमतौर पर पर्याप्त) लेकिन आपको अधिक सुविधाओं के साथ अपने स्वयं के गेटवे का उपयोग करने की भी अनुमति देते हैं।
Kubernetes Gateway API के माध्यम से API गेटवे और सर्विस मेश का अभिसरण एप्लिकेशन डेवलपर को अंतर्निहित इम्प्लीमेंटेशन के बारे में चिंता करने के बजाय समस्याओं को हल करने पर ध्यान केंद्रित करने में आसान बना देगा।
Apache APISIX जैसे प्रोजेक्ट्स API गेटवे और सर्विस मेश ऑफरिंग बनाने के लिए एक ही तकनीक का उपयोग करते हैं और इन स्पेसिफिकेशन के साथ अच्छी तरह से इंटीग्रेट होते हैं, जो वेंडर-न्यूट्रल विकल्पों को प्रोत्साहित करते हैं।
यह भी संभव है कि आपको इनमें से किसी की भी आवश्यकता न हो। आपको माइक्रोसर्विसेज की भी आवश्यकता नहीं हो सकती या एक वितरित आर्किटेक्चर की, लेकिन जब आपको इनकी आवश्यकता होती है, तो गेटवे और मेश आपके जीवन को बहुत आसान बना सकते हैं।