मैं कुबेरनेट्स में इनग्रेड और लोड बैलेंसर की भूमिकाओं को लेकर काफी उलझन में हूं।
जहां तक मैं समझता हूं कि इंटरनेट से आने वाली ट्रैफिक को क्लस्टर में चलने वाली सेवाओं को मैप करने के लिए इनग्रेड का उपयोग किया जाता है।
लोड बैलेंसर की भूमिका एक मेजबान को ट्रैफ़िक अग्रेषित करने की है। इस संबंध में कि भार बेलन से कैसे अलग होता है? अमेज़ॅन ईएलबी और एएलबी की तुलना में कुबेरनेट्स के अंदर लोड बैलेंसर की अवधारणा क्या है?
जवाबों:
लोड बैलेंसर: एक कुबेरनेट्स लोडबैलेंसर सेवा एक ऐसी सेवा है जो बाहरी लोड बैलेंसरों को इंगित करती है जो आपके कुबेरनेट क्लस्टर में नहीं हैं, लेकिन कहीं और मौजूद हैं। वे आपकी फली के साथ काम कर सकते हैं, यह मानते हुए कि आपकी फली बाहरी रूप से निष्क्रिय है। Google और AWS मूल रूप से यह क्षमता प्रदान करते हैं। अमेज़ॅन के संदर्भ में, एडब्ल्यूएस में चलने पर ईएलबी और कुबेरनेट्स के साथ यह मानचित्र सीधे स्वचालित रूप से तैनात किए गए प्रत्येक लोडबेलर सेवा के लिए ईएलबी उदाहरण को प्रावधान और कॉन्फ़िगर कर सकता है।
इनग्रेड: एक इंग्रेस वास्तव में एक नियंत्रक को पास करने के लिए नियमों का एक सेट है जो उनके लिए सुन रहा है। आप निगलना नियमों का एक गुच्छा तैनात कर सकते हैं, लेकिन कुछ भी नहीं होगा जब तक कि आपके पास एक नियंत्रक न हो जो उन्हें संसाधित कर सकता है। यदि कोई ऐसा करने के लिए कॉन्फ़िगर किया गया है, तो एक LoadBalancer सेवा इंसर्ग नियम के लिए सुन सकती है।
आप एक NodePort सेवा भी बना सकते हैं , जिसमें क्लस्टर के बाहर एक बाहरी रूप से चलने योग्य IP है, लेकिन एक पॉड को इंगित करता है जो आपके क्लस्टर के भीतर मौजूद है। यह एक इनवेशन कंट्रोलर हो सकता है।
एक इनग्निशन कंट्रोलर बस एक पॉड होता है जिसे इंग्रेस नियमों की व्याख्या के लिए कॉन्फ़िगर किया जाता है। कुबेरनेट्स द्वारा समर्थित सबसे लोकप्रिय इंग्रेस नियंत्रकों में से एक नगनेक्स है। अमेज़ॅन के संदर्भ में, ALB का उपयोग एक नियंत्रक के रूप में किया जा सकता है ।
एक उदाहरण के लिए, यह nginx कंट्रोलर आपके द्वारा परिभाषित नियमों को निगलना और उन्हें nginx.conf फाइल में अनुवाद करने में सक्षम है जो इसे लोड करता है और इसकी फली में शुरू होता है।
उदाहरण के लिए मान लें कि आपने निम्न के रूप में एक अंतर्ग्रहण को परिभाषित किया है:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
यदि आप अपने nginx नियंत्रक पॉड का निरीक्षण करते हैं, तो आपको निम्नलिखित नियम दिखाई देंगे /etc/nginx.conf:
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginx ने आपके क्लस्टर में http://kubernetes.foo.bar/appसेवा को इंगित करने के लिए रूट करने के लिए एक नियम बनाया है appsvc।
यहाँ एक उदाहरण है कि एक नगनेक्स इंग्रेस कंट्रोलर के साथ कुबेरनेट क्लस्टर कैसे लागू किया जाए। उम्मीद है की यह मदद करेगा!
मुझे यह बहुत दिलचस्प लेख मिला जो कि NodePort, LoadBalancer और Ingress के बीच के अंतरों की व्याख्या करता है।
लेख में मौजूद सामग्री से:
भार संतुलन:
इंटरनेट पर एक सेवा को उजागर करने का एक मानक तरीका है LoadBalancer सेवा। GKE पर, यह एक नेटवर्क लोड बैलेंसर को स्पिन करेगा जो आपको एक एकल IP पता देगा जो आपकी सेवा में सभी ट्रैफ़िक को अग्रेषित करेगा।
यदि आप किसी सेवा को सीधे उजागर करना चाहते हैं, तो यह डिफ़ॉल्ट विधि है। आपके द्वारा निर्दिष्ट पोर्ट पर सभी ट्रैफ़िक को सेवा में भेज दिया जाएगा। कोई फ़िल्टरिंग, कोई रूटिंग, आदि नहीं है। इसका मतलब है कि आप इसे लगभग किसी भी तरह का ट्रैफ़िक भेज सकते हैं, जैसे HTTP, TCP, UDP, Websockets, gRPC, या जो भी हो।
बड़ी नकारात्मक बात यह है कि आप प्रत्येक सेवा को एक लोडबेलर के साथ उजागर करते हैं, उसे अपना आईपी पता मिलेगा, और आपको लोडबेलर के लिए प्रति उजागर सेवा के लिए भुगतान करना होगा, जो महंगा हो सकता है!
प्रवेश:
प्रगति वास्तव में एक प्रकार की सेवा नहीं है। इसके बजाय, यह कई सेवाओं के सामने बैठता है और आपके क्लस्टर में "स्मार्ट राउटर" या एंट्रीपॉइंट के रूप में कार्य करता है।
आप एक इनग्रेड के साथ कई अलग-अलग चीजें कर सकते हैं, और कई प्रकार के इनग्रेड कंट्रोलर हैं जिनकी अलग-अलग क्षमताएं हैं।
डिफ़ॉल्ट GKE प्रवेश नियंत्रक आपके लिए एक HTTP (S) लोड बैलेंसर को स्पिन करेगा। यह आपको बैकएंड सेवाओं के लिए मार्ग आधारित और उपडोमेन आधारित मार्ग दोनों करने देगा। उदाहरण के लिए, आप foo.yourdomain.com पर foo सेवा में सब कुछ भेज सकते हैं, और yourdomain.com/bar/ पथ पर बार सेवा के तहत सब कुछ।
आपकी सेवाओं को उजागर करने के लिए इनग्रेड सबसे शक्तिशाली तरीका है, लेकिन यह सबसे जटिल भी हो सकता है। Google क्लाउड लोड बैलेंसर, नग्नेक्स, कंटूर, इस्तियो, और बहुत से, कई प्रकार के इनग्रेडिएंट नियंत्रक हैं। सर्टिफिकेट-मैनेजर की तरह, इनग्रेड कंट्रोलर्स के लिए भी प्लगइन्स हैं, जो आपकी सेवाओं के लिए एसएसएल प्रमाणपत्रों को स्वचालित रूप से व्यवस्थित कर सकते हैं।
यदि आप एक ही आईपी पते के तहत कई सेवाओं को उजागर करना चाहते हैं, तो इनग्रेड सबसे उपयोगी है, और ये सभी सेवाएं समान L7 प्रोटोकॉल (आमतौर पर HTTP) का उपयोग करती हैं। यदि आप देशी GCP एकीकरण का उपयोग कर रहे हैं, तो आप केवल एक लोड बैलेंसर के लिए भुगतान करते हैं, और क्योंकि Ingress "स्मार्ट" है, तो आपको बॉक्स से कई सुविधाएँ मिल सकती हैं (जैसे SSL, प्रामाणिक, रूटिंग, आदि)
टी एल: डॉ
आइए व्यावहारिक उपयोग के मामले के साथ शुरू करें: आपके पास एक एकल डोमेन नाम के तहत तैनात करने के लिए सेवा कार्यान्वयन पैकेज (एएसआईपी फॉर क्लैरिटी और संक्षिप्तता) द्वारा समर्थित कई एपिस हैं। जैसा कि आप एक अत्याधुनिक डेवलपर हैं, आपने एक माइक्रो-सर्विसेज आर्किटेक्चर को लागू किया है जिसके लिए प्रत्येक एएसआईपी के लिए अलग-अलग तैनाती की आवश्यकता होती है ताकि उन्हें व्यक्तिगत रूप से उन्नत या स्केल किया जा सके। बेशक, ये एएसआईपी व्यक्तिगत डॉकटर कंटेनर में कूटबद्ध होते हैं और कंटेनर रिपोजिटरी से कुबेरनेट्स (K8s) के लिए उपलब्ध होते हैं।
मान लीजिए कि अब आप इसे Google के GKE K8s पर तैनात करना चाहते हैं। निरंतर उपलब्धता को लागू करने के लिए, प्रत्येक एएसआईपी उदाहरण (प्रतिकृति) को विभिन्न नोड्स (वीएम) पर तैनात किया जाता है, जहां प्रत्येक वीएम का अपना क्लाउड आंतरिक आईपी पता होता है। प्रत्येक ASIP परिनियोजन को एक उपयुक्त नाम "परिनियोजन .yaml" फ़ाइल में कॉन्फ़िगर किया गया है जहाँ आप घोषित रूप से निर्दिष्ट करते हैं, अन्य बातों के अलावा, दिए गए ASIP K8 के प्रतिकृतियों की संख्या को तैनात करना चाहिए।
अगला कदम है ouside दुनिया के लिए एपीआई को उजागर करना और तैनात ASIP उदाहरण में से एक के लिए फ़नल अनुरोध। चूंकि हमारे पास अलग-अलग नोड्स पर चलने वाले एक ही एएसआईपी के कई प्रतिकृतियां हैं, इसलिए हमें कुछ ऐसी चीजों की आवश्यकता है जो उन प्रतिकृतियों के बीच अनुरोध को वितरित करेगी। इसे हल करने के लिए, हम एक "सेवा.यूमल" फ़ाइल बना और लागू कर सकते हैं जो एक K8s सेवा (KServ) को कॉन्फ़िगर करेगा जो बाहरी रूप से एक आईपी पते के माध्यम से उजागर और सुलभ होगा। यह KServ एपीआई ASIPs द्वारा कॉन्फ़िगर किए गए के बीच एपीआई के अनुरोध वितरण का प्रभार लेगा। ध्यान दें कि एक KSIP स्वचालित रूप से K8 मास्टर द्वारा पुन: कॉन्फ़िगर किया जाएगा जब एक ASIP का नोड विफल हो जाता है और पुनरारंभ होता है। ऐसे मामले में आंतरिक आईपी पते का पुन: उपयोग नहीं किया जाता है और केएसईआरवी को नए एएसआईपी की तैनाती के स्थान की सलाह दी जानी चाहिए।
लेकिन हमारे पास अन्य एपि सेवा पैकेज हैं जो एक ही डोमेन नाम पर उजागर किए जाएंगे। एक नया KServ कताई एक नया बाहरी IP पता बनाएगा और हम इसे एक ही डोमेन नाम पर उजागर नहीं कर पाएंगे। ठीक है, यह वह जगह है जहाँ Ingress आता है।
इन्टरनेट और इंटरनेट के बीच के सभी इनसर्विस में हम बाहर की दुनिया को उजागर करते हैं। लोड लोड संतुलन, एसएसएल समाप्ति और नाम-आधारित वर्चुअल होस्टिंग प्रदान करने में सक्षम है। बाद की क्षमता URL के विश्लेषण द्वारा सही सेवा के लिए आने वाले अनुरोध को रूट करने में सक्षम है। बेशक, इनग्रेड को कॉन्फ़िगर किया जाना चाहिए और एक ... "ingress.yaml" फ़ाइल के साथ लागू किया जाना चाहिए, जो राइट केसर को अनुरोध भेजने के लिए फिर से लिखना और आवश्यक मार्गों को निर्दिष्ट करेगा।
इंटरनेट -> प्रगति -> K8s सेवाएँ -> प्रतिकृतियां
इसलिए, सही प्रवेश, KServices और ASIPs कॉन्फ़िगरेशन के साथ, हम समान डोमेन नाम का उपयोग करके कई API को सुरक्षित रूप से उजागर कर सकते हैं।
बाहरी ट्रैफ़िक प्राप्त करने के लिए आपके क्लस्टर में पॉड्स की अनुमति देने के 4 तरीके हैं:
1.) होस्टनेटवर्किंग का उपयोग करके पॉड: सच और (1 नोड प्रति नोड को होस्ट नोड पर बंदरगाहों को सीधे सुनने की अनुमति देता है। मिनिक्यूब, नंगे धातु, और रास्पबेरी पी की कभी-कभी। यह मार्ग जो पोर्ट नोड 80/443 पर होस्ट नोड को सुनने की अनुमति दे सकता है, लोड बैलेंसर या उन्नत क्लाउड लोड बैलेंसर कॉन्फ़िगरेशन का उपयोग नहीं करने देता है, यह कुबेरनेट्स सेवाओं को भी बायपास करता है जो एसएनएटी से बचने और बाहरी ट्रैफ़िकपॉलिसी के समान प्रभाव को प्राप्त करने के लिए उपयोगी हो सकता है: स्थानीय परिदृश्यों में जहाँ यह AWS की तरह समर्थित नहीं है।)
2.) NodePort Service
3.) LoadBalancer Service (जो NodePort Service पर निर्मित होती है)
4.) Ingress Controller + Ingress Objects (जो ऊपर बनाता है)
कहते हैं कि आपके पास अपने क्लस्टर में 10 वेबसाइट होस्ट हैं और आप उन सभी को बाहरी ट्रैफ़िक में उजागर करना चाहते हैं।
* यदि आप टाइप लोडबलर सेवा का उपयोग करते हैं, तो आप 10 हा क्लाउड लोड बैलेंसर्स (प्रत्येक लागत पैसे) को स्पॉन करेंगे। यदि आप टाइप इनग्रेड
कंट्रोलर का उपयोग करते हैं तो आप 1 एचए क्लाउड लोड बैलेंसर (पैसा बचाते हैं) स्पॉन करेंगे, और यह एक इनग्रेड को इंगित करेगा। आपके क्लस्टर में चल रहा नियंत्रक।
एक इनवेशन कंट्रोलर है:
आपके क्लस्टर लोड बैलेंस के अंदर L7 LB / Ingress नियंत्रक / आपके क्लस्टर के अंदर क्लस्टर IP सेवाओं के लिए ट्रैफ़िक को उल्टा करता है, यह HTTPS को समाप्त भी कर सकता है यदि आपके पास Kubernetes Secret ऑफ़ टाइप TLS सर्टिफ़िकेट है, और कांग्रेस ऑब्जेक्ट जो इसे संदर्भित करता है।)
Ingress: Ingress Object + Ingress Controller
इनग्रेड ऑब्जेक्ट:
एक सेवा वस्तु की तरह, सिवाय इसके कि यह अपने आप कुछ नहीं करती है। एक इनग्रेड ऑब्जेक्ट सिर्फ अनुरोध पथ, अनुरोध डोमेन और लक्ष्य कुबेरनेट सेवा जैसी चीजों को निर्दिष्ट करके, अपने क्लस्टर में लेयर 7 ट्रैफ़िक को रूट करने का एक तरीका बताता है, जबकि एक सेवा ऑब्जेक्ट वास्तव में सेवाएं बनाता है
इनग्रेस कंट्रोलर:
एक सेवा जो:
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Objects
3. Creates internal L7 routing rules based on these Ingress Objects
उदाहरण के लिए, Nginx Ingress नियंत्रक, पोर्ट 80 और 443 को सुनने के लिए एक सेवा का उपयोग कर सकता है और फिर नई Ingress ऑब्जेक्ट्स पढ़ सकता है और उन्हें नए सर्वर {} अनुभागों में पार्स कर सकता है जो इसे गतिशील रूप से nginx.conf में रखता है।
LoadBalancer: एक्सटर्नल लोड Balancer प्रदाता + सेवा प्रकार
बाहरी लोड बैलेंसर प्रदाता:
बाहरी लोड बैलेंसर प्रदाता आमतौर पर AWS और GKE जैसे बादलों में कॉन्फ़िगर किए जाते हैं और बाहरी लोड बैलेंसरों के निर्माण के माध्यम से बाहरी आईपी को असाइन करने का एक तरीका प्रदान करते हैं। इस कार्यक्षमता का उपयोग सेवा को "लोडबेलर" प्रकार के रूप में नामित करके किया जा सकता है।
सेवा प्रकार:
जब सेवा प्रकार LoadBalancer के लिए सेट किया जाता है, तो Kubernetes, Kubernetes पॉड्स के लिए प्रविष्टियों के साथ एक बाहरी लोड बैलेंसर बनाने का प्रयास करता है, जिससे उन्हें बाहरी IP असाइन किया जाता है।
कुबेरनेट्स सेवा नियंत्रक बाहरी लोड बैलेंसर, स्वास्थ्य जांच (यदि आवश्यक हो), फ़ायरवॉल नियमों (यदि आवश्यक हो) के निर्माण को स्वचालित करता है और नव निर्मित या कॉन्फ़िगर किए गए लोडबॉलर के बाहरी आईपी को पुनर्प्राप्त करता है जो क्लाउड प्रदाता द्वारा आवंटित किया गया था और इसमें पॉपुलेट करता है सेवा वस्तु।
रिश्तों:
Ingress Controller Services को अक्सर LoadBalancer प्रकार के रूप में प्रावधान किया जाता है, ताकि http और https अनुरोधों को बाहरी IP के माध्यम से विशिष्ट आंतरिक सेवाओं के लिए अनुमानित / रूट किया जा सके।
हालाँकि, इसके लिए एक LoadBalancer की कड़ाई से आवश्यकता नहीं है। चूंकि, hostNetwork या hostPort के उपयोग के माध्यम से आप तकनीकी रूप से होस्ट पर एक पोर्ट को एक सेवा में बाँध सकते हैं (आपको इसे मेजबान बाहरी आईपी: पोर्ट के माध्यम से देखने की अनुमति देता है)। हालांकि आधिकारिक तौर पर यह अनुशंसित नहीं है क्योंकि यह वास्तविक नोड पर बंदरगाहों का उपयोग करता है।
संदर्भ:
https://kubernetes.io/docs/concepts/configuration/overview/#services
https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/
https://kubernetes.io/docs/concepts/services-networking/ingress/
सरल शब्दों में, लोड बैलेंसर कई बैकएंड सेवाओं (एक ही प्रकार के) के बीच अनुरोधों को वितरित करता है, जबकि प्रवेश एक एपीआई गेटवे (रिवर्स प्रॉक्सी) की तरह अधिक होता है, जो उदाहरण के लिए, URL के आधार पर एक विशिष्ट बैकेंड सेवा के लिए अनुरोध को रूट करता है।