APISIX Ingress Controller हज़ारों Pod Replicas का समर्थन कैसे करता है?
Xin Rong
October 21, 2022
1,000+ Kubernetes Pods
Pods Kubernetes में सबसे छोटे deployable objects हैं। हम एक एप्लिकेशन के एकल इंस्टेंस को चलाने के लिए एक Pod का उपयोग करते हैं, इसलिए हम scalability के कारण Pod को सीमित संसाधन आवंटित करते हैं। हालांकि, यदि हमें high-traffic scenarios का सामना करना पड़ता है, तो हम उन्हें हैंडल करने के लिए horizontal scaling का उपयोग करेंगे।
उदाहरण के लिए, ऑनलाइन रिटेलर्स के लिए, ब्लैक फ्राइडे ट्रैफ़िक में तेजी से वृद्धि लाएगा। इस परिदृश्य को हैंडल करने के लिए, हमें अधिक ट्रैफ़िक को संभालने के लिए सेवाओं को ऑटोस्केल करना होगा। हम ऑटोस्केलिंग रणनीति के आधार पर अधिक रेप्लिकेशन्स को डिप्लॉय करेंगे, जिसके परिणामस्वरूप अधिक Pods होंगे।
प्रत्येक Pod का एक डायनामिक IP पता होता है। Endpoints API ने Kubernetes में नेटवर्क एंडपॉइंट्स को ट्रैक करने का एक सीधा तरीका प्रदान किया है ताकि हम Pod IP में परिवर्तनों को समय पर मॉनिटर करके लोड बैलेंसिंग प्राप्त कर सकें। हालांकि, जैसे-जैसे Kubernetes क्लस्टर और सेवाएं अधिक Pods के लिए अधिक ट्रैफ़िक को हैंडल करने के लिए बढ़ते हैं, उदाहरण के लिए, ऊपर उल्लिखित ब्लैक फ्राइडे परिदृश्य, Pods की संख्या बढ़ती रहती है, और Endpoints API बड़ा हो जाता है। परिणामस्वरूप, Endpoints API की सीमाएं अधिक स्पष्ट हो जाती हैं, और यह प्रदर्शन बाधा बन जाता है।
Endpoints API की सीमा समस्या को हल करने के लिए, Kubernetes ने v1.21 संस्करण में EndpointSlice API का समर्थन शुरू किया। EndpointSlice API Endpoints API में विशाल नेटवर्क एंडपॉइंट्स को हैंडल करने की प्रदर्शन समस्या को हल करने में मदद करता है और इसमें उत्कृष्ट scalability और extensibility है।
हम नीचे दिए गए डायग्राम से उनके बीच के अंतर को सीधे पता लगा सकते हैं:
- ट्रैफ़िक स्पाइक के दौरान Endpoints में परिवर्तन
- ट्रैफ़िक स्पाइक के दौरान Endpointslices में परिवर्तन
Kubernetes में, एप्लिकेशन एक-दूसरे के साथ कैसे संचार करते हैं? Endpoints और EndpointSlice के बीच विशिष्ट अंतर क्या हैं? Pod और Endpoints/EndpointSlice के बीच क्या संबंध है? APISIX इन सुविधाओं का समर्थन कैसे करता है, और उन्हें इंस्टॉल और उपयोग करने का तरीका क्या है? हम इस लेख में इन प्रश्नों पर ध्यान केंद्रित करेंगे।
Kubernetes में एप्लिकेशन तक कैसे पहुंचें
Service के माध्यम से
Kubernetes में प्रत्येक Pod का अपना अद्वितीय IP पता होता है। आमतौर पर, Service selector का उपयोग करके Pod के साथ कनेक्शन बनाएगा, एक ही DNS उपडोमेन नाम प्रदान करेगा, और लोड बैलेंसिंग प्राप्त करेगा। इसके अलावा, Kubernetes क्लस्टर के अंदर के एप्लिकेशन एक-दूसरे के साथ संचार करने के लिए DNS का उपयोग कर सकते हैं।
जब Service बनाई जाती है, तो Kubernetes Service को एक Endpoints संसाधन से जोड़ेगा। हालांकि, यदि Service ने किसी भी selectors को निर्दिष्ट नहीं किया है, तो Kubernetes स्वचालित रूप से Service के लिए Endpoints नहीं बनाएगा।
Endpoints क्या है, और Pod के साथ इसका क्या संबंध है
Endpoints Kubernetes में एक संसाधन ऑब्जेक्ट है, जो etcd में संग्रहीत होता है, और इसमें एक Service से मेल खाने वाले Pod के एक्सेस पते के संदर्भ शामिल होते हैं। इसलिए, प्रत्येक Service के पास केवल एक Endpoints संसाधन हो सकता है। Endpoints संसाधन Pod क्लस्टर को मॉनिटर करेगा और Service में किसी भी Pod के बदलने पर तुरंत अपडेट करेगा।
- 3
httpbinरेप्लिकेशन्स को डिप्लॉय करें, और Pod की स्थिति, IP जानकारी सहित जांचें
$ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES httpbin-deployment-fdd7d8dfb-8sxxq 1/1 Running 0 49m 10.1.36.133 docker-desktop <none> <none> httpbin-deployment-fdd7d8dfb-bjw99 1/1 Running 4 (5h39m ago) 23d 10.1.36.125 docker-desktop <none> <none> httpbin-deployment-fdd7d8dfb-r5nf9 1/1 Running 0 49m 10.1.36.131 docker-desktop <none> <none>
httpbinसेवा बनाएं, और Endpoints endpoints की स्थिति जांचें
$ kubectl get endpoints httpbin NAME ENDPOINTS AGE httpbin 10.1.36.125:80,10.1.36.131:80,10.1.36.133:80 23d
उपरोक्त दो उदाहरणों से, हम देख सकते हैं कि Endpoints में httpbin संसाधन के प्रत्येक नेटवर्क एंडपॉइंट Pod के IP पते से मेल खाता है
Endpoints के नुकसान
- Endpoints में स्टोरेज सीमा है, यदि किसी Endpoints संसाधन में 1000 से अधिक एंडपॉइंट्स हैं, तो Endpoints कंट्रोलर एंडपॉइंट्स को 1000 तक काट देगा।
- एक सेवा के पास केवल एक Endpoints संसाधन हो सकता है, जिसका अर्थ है कि Endpoints संसाधन को संबंधित Service के लिए बैकिंग करने वाले प्रत्येक Pod के IP पते और अन्य नेटवर्क जानकारी को स्टोर करने की आवश्यकता होती है। परिणामस्वरूप, Endpoint API संसाधन बड़ा हो जाता है, और जब संसाधन में एकल नेटवर्क एंडपॉइंट बदलता है तो इसे अपडेट करना पड़ता है। जब व्यवसाय को बार-बार एंडपॉइंट्स परिवर्तन की आवश्यकता होती है, तो एक विशाल API संसाधन एक-दूसरे को भेजा जाएगा, जो Kubernetes घटकों के प्रदर्शन को प्रभावित करता है
Endpointslices क्या है
Endpointslices Endpoints का एक अधिक scalable और extensible विकल्प है और विशाल नेटवर्क एंडपॉइंट्स को प्रोसेस करने के कारण होने वाली प्रदर्शन समस्या को हल करने में मदद करता है। यह टोपोलॉजिकल रूटिंग जैसी अतिरिक्त सुविधाओं के लिए एक extensible प्लेटफॉर्म प्रदान करने में भी मदद करता है। यह सुविधा Kubernetes v1.21 में समर्थित है।
EndpointSlice API को इस समस्या को हल करने के लिए sharding के समान दृष्टिकोण के साथ डिज़ाइन किया गया था। एकल Endpoints संसाधन के साथ एक Service के लिए सभी Pod IPs को ट्रैक करने के बजाय, हम उन्हें कई छोटे EndpointSlices में विभाजित करते हैं।
डिफ़ॉल्ट रूप से, कंट्रोल प्लेन EndpointSlices को बनाता है और प्रबंधित करता है ताकि प्रत्येक में 100 से अधिक एंडपॉइंट्स न हों। आप इसे --max-endpoints-per-slice kube-controller-manager फ्लैग के साथ कॉन्फ़िगर कर सकते हैं, जो 1000 तक हो सकता है।
हमें इसकी आवश्यकता क्यों है
एक परिदृश्य पर विचार करें
मान लें कि एक Service है जो 2000 Pods द्वारा समर्थित है, जो 1.0 MB Endpoints संसाधन के साथ समाप्त हो सकता है। प्रोडक्शन वातावरण में, यदि इस Service में रोलिंग अपडेट या एंडपॉइंट माइग्रेशन होता है, तो Endpoint संसाधन बार-बार अपडेट होंगे। रोलिंग अपडेट के बारे में सोचें जो सभी Pods को बदल देगा etcd में किसी भी अनुरोध के अधिकतम आकार सीमा के कारण। Kubernetes ने Endpoints के लिए 1000 एंडपॉइंट्स की अधिकतम सीमा निर्धारित की है। यदि 1000 से अधिक एंडपॉइंट्स हैं, तो Endpoints संसाधन में अतिरिक्त नेटवर्क एंडपॉइंट्स पर कोई संदर्भ नहीं होगा।
मान लें कि Service को कुछ विशेष आवश्यकताओं के कारण कई रोलिंग अपडेट की आवश्यकता है; उस स्थिति में, Kubernetes घटकों के बीच एक विशाल API संसाधन ऑब्जेक्ट स्थानांतरित किया जाएगा, जो Kubernetes घटकों के प्रदर्शन को महत्वपूर्ण रूप से प्रभावित करता है।
यदि हम EndpointSlice का उपयोग करें तो क्या होगा
मान लें कि एक Service है जो 2000 Pods द्वारा समर्थित है, और हम कॉन्फ़िगरेशन में प्रत्येक Endpointslices को 100 एंडपॉइंट्स आवंटित करते हैं, तो हम 20 Endpointslices के साथ समाप्त होंगे। अब जब एक Pod जोड़ा या हटाया जाता है, तो केवल एक छोटे EndpointSlice को अपडेट करने की आवश्यकता होती है। स्पष्ट रूप से, यह scalability और नेटवर्क extensibility में एक उल्लेखनीय सुधार है। मान लें कि प्रत्येक Service में ऑटोस्केलिंग आवश्यकता है। उस स्थिति में, Service अधिक Pods को डिप्लॉय करेगी, और Endpoints संसाधन को बढ़ते ट्रैफ़िक को हैंडल करने के लिए बार-बार अपडेट करना होगा जब ट्रैफ़िक स्पाइक होता है, और अंतर अधिक ध्यान देने योग्य हो जाएगा। इससे भी महत्वपूर्ण बात यह है कि अब एक Service के लिए सभी Pod IPs को एकल संसाधन में स्टोर करने की आवश्यकता नहीं है, हमें etcd में संग्रहीत ऑब्जेक्ट्स के आकार सीमा के बारे में चिंता करने की आवश्यकता नहीं है।
Endpoints VS EndpointSlice का निष्कर्ष
क्योंकि EndpointSlice Kubernetes v1.21 से समर्थित है, सभी निष्कर्ष Kubernetes v1.21 को संदर्भित करते हैं।
Endpoints के उपयोग के मामले:
- ऑटोस्केलिंग की आवश्यकता है, लेकिन Pods की संख्या अपेक्षाकृत छोटी है, और संसाधन स्थानांतरण विशाल नेटवर्क ट्रैफ़िक और अतिरिक्त हैंडलिंग आवश्यकताओं का कारण नहीं बनेगा।
- ऑटोस्केलिंग की आवश्यकता नहीं है, और Pods की संख्या विशाल नहीं होगी। हालांकि, यद्यपि Pods की संख्या निश्चित है, Service रोलिंग अपडेट और फॉल्ट्स को छोड़ नहीं सकती है।
EndpointSlice के उपयोग के मामले:
- ऑटोस्केलिंग की आवश्यकता है, और Pods की संख्या विशाल है (सैकड़ों Pods)
- Pods की संख्या विशाल है (सैकड़ों Pods) Endpoints की अधिकतम एंडपॉइंट्स सीमा 1000 होने के कारण; 1000 से अधिक एंडपॉइंट्स वाले किसी भी Pod को EndpointSlice का उपयोग करना होगा।
APISIX Ingress Controller में अभ्यास
APISIX Ingress Controller Endpoints या EndpointSlice संसाधन में परिवर्तनों को देखकर लोड बैलेंसिंग और हेल्थ चेक प्राप्त करता है। Kubernetes v1.16+ का समर्थन करने के लिए, APISIX Ingress Controller इंस्टॉलेशन के दौरान डिफ़ॉल्ट रूप से Endpoints का उपयोग करेगा।
यदि आपके क्लस्टर का संस्करण Kubernetes v1.21+ है, तो आपको APISIX Ingress Controller इंस्टॉलेशन के दौरान EndpointSlice सुविधा का समर्थन करने के लिए watchEndpointSlice=true फ्लैग निर्दिष्ट करने की आवश्यकता है।
नोट: Kubernetes v1.21+ वाले क्लस्टर में, हम Endpointslice सुविधा का उपयोग करने की सलाह देते हैं, अन्यथा जब Pods की संख्या
--max-endpoints-per-sliceफ्लैग के कॉन्फ़िगरेशन मान से अधिक हो जाती है, तो कॉन्फ़िगरेशन खो जाएगी क्योंकि APISIX Ingress Controller Endpoints संसाधन ऑब्जेक्ट को देख रहा है।
20 Pod रेप्लिकेशन्स के साथ Service बनाना
Kubernetes में httpbin एप्लिकेशन Service को कॉन्फ़िगर करें, और 20 Pod रेप्लिकेशन्स बनाएं
- kubectl apply -f httpbin-deploy.yaml
# htppbin-deploy.yaml apiVersion: apps/v1 kind: Deployment metadata: name: httpbin-deployment spec: replicas: 20 selector: matchLabels: app: httpbin-deployment strategy: rollingUpdate: maxSurge: 50% maxUnavailable: 1 type: RollingUpdate template: metadata: labels: app: httpbin-deployment spec: terminationGracePeriodSeconds: 0 containers: - livenessProbe: failureThreshold: 3 initialDelaySeconds: 2 periodSeconds: 5 successThreshold: 1 tcpSocket: port: 80 timeoutSeconds: 2 readinessProbe: failureThreshold: 3 initialDelaySeconds: 2 periodSeconds: 5 successThreshold: 1 tcpSocket: port: 80 timeoutSeconds: 2 image: "kennethreitz/httpbin:latest" imagePullPolicy: IfNotPresent name: httpbin-deployment ports: - containerPort: 80 name: "http" protocol: "TCP" --- apiVersion: v1 kind: Service metadata: name: httpbin spec: selector: app: httpbin-deployment ports: - name: http port: 80 protocol: TCP targetPort: 80 type: ClusterIP
APISIX Ingress के माध्यम से प्रॉक्सी
- Helm का उपयोग करके APISIX Ingress Controller इंस्टॉल करें
EndpointSlice सुविधा का समर्थन करने के लिए --set ingress-controller.config.kubernetes.watchEndpointSlice=true का उपयोग करें।
helm repo add apisix https://charts.apiseven.com helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update kubectl create ns ingress-apisix helm install apisix apisix/apisix \ --set gateway.type=NodePort \ --set ingress-controller.enabled=true \ --namespace ingress-apisix \ --set ingress-controller.config.apisix.serviceNamespace=ingress-apisix \ --set ingress-controller.config.kubernetes.watchEndpointSlice=true
- CRD संसाधन का उपयोग करके प्रॉक्सी करें
उपयोगकर्ता APISIX Ingress Controller में Endpoints और EndpointSlice सुविधाओं के समर्थन को नोटिस नहीं कर सकते हैं, और उनकी कॉन्फ़िगरेशन समान हैं
apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: httpbin-route spec: http: - name: rule match: hosts: - httpbin.org paths: - /get backends: - serviceName: httpbin servicePort: 80
- APISIX Pod की जांच करके, हम देख सकते हैं कि APISIX के upstream ऑब्जेक्ट के nodes फ़ील्ड में 20 Pods के IP पते शामिल हैं।
kubectl exec -it ${Pod for APISIX} -n ingress-apisix -- curl "http://127.0.0.1:9180/apisix/admin/upstreams" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1'
{ "action": "get", "count": 1, "node": { "key": "\/apisix\/upstreams", "nodes": [ { "value": { "hash_on": "vars", "desc": "Created by apisix-ingress-controller, DO NOT modify it manually", "pass_host": "pass", "nodes": [ { "weight": 100, "host": "10.1.36.100", "priority": 0, "port": 80 }, { "weight": 100, "host": "10.1.36.101", "priority": 0, "port": 80 }, { "weight": 100, "host": "10.1.36.102", "priority": 0, "port": 80 }, { "weight": 100, "host": "10.1.36.103", "priority": 0, "port": 80 }, { "weight": 100, "host": "10.1.36.104", "priority": 0, "port": 80 }, { "weight": 100, "host": "10.1.36.109", "priority": 0, "port": 80 }, { "weight": 100, "host": "10.1.36.92", "priority": 0, "port": 80 } ... // ignore 13 nodes below // 10.1.36.118 // 10.1.36.115 // 10.1.36.116 // 10.1.36.106 // 10.1.36.113 // 10.1.36.111 // 10.1.36.108 // 10.1.36.114 // 10.1.36.107 // 10.1.36.110 // 10.1.36.105 // 10.1.36.112 // 10.1.36.117 ], "labels": { "managed-by": "apisix-ingress-controller" }, "type": "roundrobin", "name": "default_httpbin_80", "scheme": "http" }, "key": "\/apisix\/upstreams\/5ce57b8e" } ], "dir": true } }
- EndpointSlice के नेटवर्क एंडपॉइंट्स से मेल खाएं
addressType: IPv4 apiVersion: discovery.k8s.io/v1 endpoints: - addresses: - 10.1.36.92 ... - addresses: - 10.1.36.100 ... - addresses: - 10.1.36.104 ... - addresses: - 10.1.36.102 ... - addresses: - 10.1.36.101 ... - addresses: - 10.1.36.103 ... - addresses: - 10.1.36.109 ... - addresses: - 10.1.36.118 ... - addresses: - 10.1.36.115 ... - addresses: - 10.1.36.116 ... - addresses: - 10.1.36.106 ... - addresses: - 10.1.36.113 ... - addresses: - 10.1.36.111 ... - addresses: - 10.1.36.108 ... - addresses: - 10.1.36.114 ... - addresses: - 10.1.36.107 ... - addresses: - 10.1.36.110 ... - addresses: - 10.1.36.105 ... - addresses: - 10.1.36.112 ... - addresses: - 10.1.36.117 ... kind: EndpointSlice metadata: labels: endpointslice.kubernetes.io/managed-by: endpointslice-controller.k8s.io kubernetes.io/service-name: httpbin name: httpbin-dkvtr namespace: default ports: - name: http port: 80 protocol: TCP
निष्कर्ष
यह लेख उन परिदृश्यों का परिचय देता है जहां Kubernetes को बड़ी संख्या में Pods को डिप्लॉय करने की आवश्यकता होती है और हमें जिन समस्याओं का सामना करना पड़ता है। यह Endpoints और EndpointSlice के बीच के अंतरों की तुलना भी करता है, और APISIX Ingress Controller इंस्टॉलेशन के दौरान EndpointSlice सुविधा को सक्षम करने का तरीका बताता है। यदि आपके क्लस्टर का संस्करण Kubernetes v1.21+ है, तो हम APISIX Ingress Controller इंस्टॉलेशन के दौरान EndpointSlice सुविधा को सक्षम करने की सलाह देते हैं। इसलिए, यह कॉन्फ़िगरेशन के नुकसान से बच सकता है, और हमें --max-endpoints-per-slice फ्लैग के कॉन्फ़िगरेशन मान के बारे में चिंता करने की आवश्यकता नहीं है।