K8s में सर्विस डिस्कवरी और DNS
अंतर-सर्विस संचार के लिए Kubernetes सर्विस डिस्कवरी और DNS समाधान को कैसे संभालता है, इसका अध्ययन करें।
K8s में सर्विस डिस्कवरी और DNS, CoddyKit पर डेवलपरों के लिए Docker और Kubernetes का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह डेवलपरों के लिए Docker और Kubernetes सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। डेवलपरों के लिए Docker और Kubernetes पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
सेवा खोज का परिचय
K8s में सेवा खोज और DNS में आपका स्वागत है! गतिशील Kubernetes क्लस्टर में Pods लगातार बनाए, नष्ट और स्थानांतरित किए जाते हैं, जिससे IP पते लगातार बदलते रहते हैं।
एक Pod में चलने वाले एप्लिकेशन दूसरे Pod या सेवा में चलने वाले एप्लिकेशन को कैसे खोजकर उनसे संचार करते हैं?
यहीं सेवा खोज काम आती है। यह वह प्रक्रिया है जिससे सेवाएँ एक-दूसरे को उनके विशिष्ट, अस्थायी IP पते जाने बिना खोजती हैं।
K8s में DNS की भूमिका
आप इंटरनेट पर DNS (डोमेन नेम सिस्टम) के बारे में पहले से जानते होंगे। यह google.com जैसे मनुष्यों के लिए पढ़ने योग्य नामों को IP पतों में बदलता है।
Kubernetes आंतरिक रूप से इसी तरह की अवधारणा का उपयोग करता है। अस्थिर Pod IP पर निर्भर रहने के बजाय, K8s अपनी सेवाओं को स्थिर DNS नाम देता है।
इससे आपके एप्लिकेशन सरल और एकसमान नामों का उपयोग करके अन्य सेवाओं से जुड़ सकते हैं।
CoreDNS: K8s DNS सर्वर
हर Kubernetes क्लस्टर के साथ अपना DNS सर्वर आता है, जो आम तौर पर CoreDNS होता है (या पुराने संस्करणों में कभी-कभी kube-dns)।
CoreDNS आपके क्लस्टर के भीतर एक Pod के रूप में चलता है और सभी आंतरिक Kubernetes सेवा नामों को उनके संबंधित क्लस्टर IP पतों में बदलने के लिए ज़िम्मेदार होता है।
क्लस्टर सेट अप करते समय यह आपके लिए अपने-आप कॉन्फ़िगर हो जाता है।
Pods को DNS कॉन्फ़िगरेशन कैसे मिलता है
जब कोई Pod शुरू होता है, तो Kubernetes उसमें DNS कॉन्फ़िगरेशन अपने-आप जोड़ देता है।
- हर Pod की
/etc/resolv.confफ़ाइल को क्लस्टर के CoreDNS सेवा IP की ओर संकेत करने के लिए अपडेट किया जाता है। - इसमें खोज पथ भी शामिल होते हैं, जिससे आप छोटे सेवा नामों का उपयोग कर सकते हैं।
इसका अर्थ है कि Pod के भीतर का कोई भी एप्लिकेशन नाम समाधान के लिए तुरंत क्लस्टर के DNS का उपयोग कर सकता है।
सेवा के DNS नाम
जब आप कोई Kubernetes सेवा बनाते हैं (जैसे, ClusterIP सेवा), तो CoreDNS उसके लिए अपने-आप एक DNS रिकॉर्ड बना देता है।
अपने namespace के भीतर किसी सेवा के DNS नाम का सबसे सामान्य प्रारूप है: <service-name>।
उदाहरण के लिए, default namespace में my-web-app नाम वाली सेवा तक उसी namespace के अन्य Pods केवल my-web-app का उपयोग करके पहुँच सकते हैं।
उदाहरण: उसी namespace से पहुँच
मान लीजिए कि आपके पास default namespace में hello-app नाम का परिनियोजन और hello-service नाम की सेवा है। default में कोई भी अन्य Pod hello-service के माध्यम से उस तक पहुँच सकता है।
परिनियोजन और सेवा का एक सरल उदाहरण यहाँ है:
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-app
spec:
selector:
matchLabels:
app: hello
replicas: 1
template:
metadata:
labels:
app: hello
spec:
containers:
- name: hello-container
image: busybox
command: ["sh", "-c", "while true; do echo Hello K8s; sleep 5; done"]
---
apiVersion: v1
kind: Service
metadata:
name: hello-service
spec:
selector:
app: hello
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIPउसी namespace के DNS का परीक्षण
पिछले दृश्य का YAML लागू करने के बाद, आप सेवा खोज का परीक्षण कर सकते हैं। पहले उसी namespace में एक अस्थायी Pod (जैसे, debug-pod) बनाएँ।
फिर debug-pod में exec करके सेवा को ping करने का प्रयास करें:
kubectl run debug-pod --image=busybox --restart=Never --rm -it --command -- sh- Pod के भीतर:
ping hello-service
आपको hello-service का ClusterIP सफलतापूर्वक खोजा हुआ दिखाई देना चाहिए!
क्रॉस-namespace DNS (FQDN)
यदि आपकी सेवाएँ अलग-अलग नामस्थानों में हों तो क्या होगा? Kubernetes Fully Qualified Domain Name (FQDN) प्रारूप का उपयोग करता है:
<service-name>.<namespace-name>.svc.cluster.local
सुविधा के लिए, यदि Pod का नामस्थान उसके DNS खोज पथ में है (जैसा कि आमतौर पर होता है), तो आप अक्सर इसका छोटा रूप उपयोग कर सकते हैं:
<service-name>.<namespace-name>
इससे आपके अनुप्रयोग के विभिन्न भागों के बीच स्पष्ट और अस्पष्टतारहित संचार संभव होता है।
उदाहरण: नामस्थानों के बीच पहुँच
मान लीजिए कि prod नामस्थान में एक backend-service है। default नामस्थान के किसी Pod से आप इसे इस प्रकार पहुँच सकते हैं:
ping backend-service.prodKubernetes DNS नाम का समाधान संभालता है और नामस्थानों के बीच भी ट्रैफ़िक को सही सेवा तक पहुँचाता है।
इससे मज़बूत पृथक्करण मिलता है और आवश्यकता होने पर संचार भी संभव रहता है।
त्वरित जाँच
Kubernetes Service Discovery और DNS के संबंध में निम्नलिखित में से कौन-से कथन TRUE हैं?
पुनरावलोकन: Service Discovery और DNS
बहुत अच्छा! इस पाठ में आपने सीखा कि आंतरिक संचार के लिए Kubernetes सेवा खोज और DNS नाम समाधान कैसे संभालता है:
- Pods के IP अस्थायी होते हैं, इसलिए एक स्थिर खोज तंत्र आवश्यक होता है।
- CoreDNS क्लस्टर का आंतरिक DNS सर्वर है।
- Services को स्थिर DNS नाम मिलते हैं, जिनका समाधान अन्य Pods कर सकते हैं।
- Pods को क्लस्टर के DNS का उपयोग करने के लिए स्वचालित रूप से कॉन्फ़िगर किया जाता है।
- आप उसी नामस्थान में सेवाओं को नाम से और अन्य नामस्थानों में FQDNs का उपयोग करके पहुँच सकते हैं।
यह शक्तिशाली प्रणाली सुनिश्चित करती है कि आपके अनुप्रयोग हमेशा एक-दूसरे को विश्वसनीय रूप से खोज सकें!
एआई शिक्षक के साथ डेवलपरों के लिए Docker और Kubernetes सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 12
- पाठ
- 48
अक्सर पूछे जाने वाले प्रश्न
क्या “K8s में सर्विस डिस्कवरी और DNS” पाठ निःशुल्क है?
हाँ—“K8s में सर्विस डिस्कवरी और DNS” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और डेवलपरों के लिए Docker और Kubernetes पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। डेवलपरों के लिए Docker और Kubernetes पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“K8s में सर्विस डिस्कवरी और DNS” में मैं क्या सीखूँगा?
अंतर-सर्विस संचार के लिए Kubernetes सर्विस डिस्कवरी और DNS समाधान को कैसे संभालता है, इसका अध्ययन करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ डेवलपरों के लिए Docker और Kubernetes का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या डेवलपरों के लिए Docker और Kubernetes शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर डेवलपरों के लिए Docker और Kubernetes शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“K8s में सर्विस डिस्कवरी और DNS” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस डेवलपरों के लिए Docker और Kubernetes पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर डेवलपरों के लिए Docker और Kubernetes पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- Kubernetes Ingress और रूटिंग
- नेटवर्क नीतियाँ लागू करना
- K8s में सर्विस डिस्कवरी और DNS
- TLS termination और HTTPS से Ingress सुरक्षित करना