1~
2यदि आप सॉफ्टवेयर डेवलपमेंट की दुनिया में काम करते हैं, तो आपने निश्चित रूप से कुबेरनेट्स के बारे में सुना होगा। लेकिन यह वास्तव में क्या है, और यह कंटेनरीकृत अनुप्रयोगों के प्रबंधन के लिए वास्तविक मानक क्यों बन गया है? यह गाइड आपको बुनियादी बातों से लेकर मौलिक अवधारणाओं तक ले जाएगी, जिसमें आपको समझने में मदद करने के लिए व्यावहारिक उदाहरण और आरेख शामिल हैं।
3~
4## कुबेरनेट्स से पहले: थोड़ा इतिहास
5~
6यह समझने के लिए कि कुबेरनेट्स इतना क्रांतिकारी क्यों है, आइए एक कदम पीछे चलते हैं।
7~
81.  **पारंपरिक डिप्लॉयमेंट**: शुरुआत में, एप्लिकेशन भौतिक सर्वरों पर चलाए जाते थे। यह दृष्टिकोण महंगा, स्केल करने में कठिन और संसाधन टकरावों का खतरा था।
92.  **वर्चुअलाइज्ड डिप्लॉयメント**: फिर वर्चुअल मशीनें (VMs) आईं। VMs ने एक ही हार्डवेयर पर कई अलग-अलग एप्लिकेशन चलाने की अनुमति दी, जिससे संसाधन उपयोग और सुरक्षा में सुधार हुआ। हालाँकि, प्रत्येक VM एक संपूर्ण ऑपरेटिंग सिस्टम चलाता है, जो बहुत सारे संसाधनों की खपत करता है।
103.  **कंटेनरीकृत डिप्लॉयमेंट**: कंटेनर (जैसे डॉकर) अगला विकास हैं। वे एक ही होस्ट ऑपरेटिंग सिस्टम साझा करते हैं लेकिन अलग-अलग प्रक्रियाएं चलाते हैं। वे हल्के, शुरू करने में तेज और पोर्टेबल होते हैं।
11~
12कंटेनरों ने पोर्टेबिलिटी की समस्या को हल कर दिया, लेकिन एक और समस्या पैदा कर दी: उत्पादन के माहौल में सैकड़ों (या हजारों) कंटेनरों का प्रबंधन कैसे करें? यह कैसे सुनिश्चित करें कि वे हमेशा चल रहे हैं, एक-दूसरे से संवाद कर सकते हैं, और लोड के आधार पर स्केल कर सकते हैं?
13~
14यहीं पर **कुबेरनेट्स** आता है।
15~
16## कुबेरनेट्स क्या है?
17~
18कुबेरनेट्स (अक्सर **K8s** के रूप में संक्षिप्त) कंटेनर ऑर्केस्ट्रेशन के लिए एक ओपन-सोर्स प्लेटफॉर्म है। सरल शब्दों में, यह कंटेनरीकृत अनुप्रयोगों की तैनाती, स्केलिंग और प्रबंधन को स्वचालित करता है। Google द्वारा बनाया गया और अब क्लाउड नेटिव कंप्यूटिंग फाउंडेशन (CNCF) द्वारा बनाए रखा गया, कुबेरनेट्स बड़े पैमाने पर माइक्रोसेवा के साथ काम करने वाले किसी भी व्यक्ति के लिए पसंदीदा उपकरण बन गया है।
19~
20## कुबेरनेट्स क्लस्टर की वास्तुकला
21~
22एक कुबेरनेट्स वातावरण को **क्लस्टर** कहा जाता है। एक क्लस्टर मशीनों के एक सेट से बना होता है, जिन्हें **नोड्स** कहा जाता है, जो हमारे एप्लिकेशन चलाते हैं। वास्तुकला को दो मुख्य भागों में बांटा गया है: कंट्रोल प्लेन और वर्कर नोड्स।
23~
24```mermaid
25graph TD
26    subgraph "कंट्रोल प्लेन (मास्टर)"
27        A["API सर्वर"]
28        B["etcd"]
29        C["शेड्यूलर"]
30        D["कंट्रोलर मैनेजर"]
31    end
32~
33    subgraph "वर्कर नोड 1"
34        E["क्यूबलेट"] --- F["कंटेनर रनटाइम"]
35        G["क्यूब-प्रॉक्सी"]
36        F --- H["पॉड"]
37        F --- I["पॉड"]
38    end
39~
40    subgraph "वर्कर नोड 2"
41        J["क्यूबलेट"] --- K["कंटेनर रनटाइम"]
42        L["क्यूब-प्रॉक्सी"]
43        K --- M["पॉड"]
44    end
45~
46    A -- "के साथ संचार करता है" --> E
47    A -- "के साथ संचार करता है" --> J
48    User -- "kubectl" --> A
49    C -- "पॉड्स को नोड्स को सौंपता है" --> E
50    D -- "स्थिति बनाए रखता है" --> A
51    A -- "स्थिति सहेजता/पढ़ता है" --> B
52```
53~
54### कंट्रोल प्लेन
55~
56कंट्रोल प्लेन क्लस्टर का "मस्तिष्क" है। यह वैश्विक निर्णय लेता है (जैसे शेड्यूलिंग) और क्लस्टर की घटनाओं का पता लगाता है और उन पर प्रतिक्रिया करता है। इसके मुख्य घटक हैं:
57~
58-   **API सर्वर (`kube-apiserver`)**: यह क्लस्टर का प्रवेश द्वार है। यह कुबेरनेट्स API को उजागर करता है, जिसका उपयोग उपयोगकर्ताओं ( `kubectl` के माध्यम से), क्लस्टर घटकों और बाहरी उपकरणों द्वारा संचार के लिए किया जाता है।
59-   **etcd**: एक सुसंगत और अत्यधिक उपलब्ध कुंजी-मूल्य डेटाबेस। यह सभी क्लस्टर डेटा को संग्रहीत करता है, जो सिस्टम की वांछित और वर्तमान स्थिति का प्रतिनिधित्व करता है।
60-   **शेड्यूलर (`kube-scheduler`)**: संसाधन आवश्यकताओं, नीतियों और अन्य बाधाओं को ध्यान में रखते हुए, नए बनाए गए पॉड्स को एक उपलब्ध वर्कर नोड को सौंपता है।
61-   **कंट्रोलर मैनेजर (`kube-controller-manager`)**: नियंत्रकों को चलाता है, जो नियंत्रण लूप हैं जो क्लस्टर की स्थिति को देखते हैं और इसे वांछित स्थिति में लाने के लिए काम करते हैं। उदाहरण के लिए, `नोड कंट्रोलर` नोड्स का प्रबंधन करता है, जबकि `प्रतिकृति नियंत्रक` यह सुनिश्चित करता है कि पॉड्स की सही संख्या चल रही है।
62~
63### वर्कर नोड
64~
65वर्कर नोड्स वे मशीनें (भौतिक या आभासी) हैं जहाँ एप्लिकेशन वास्तव में चलाए जाते हैं। प्रत्येक नोड को कंट्रोल प्लेन द्वारा प्रबंधित किया जाता है और इसमें निम्नलिखित घटक होते हैं:
66~
67-   **क्यूबलेट**: प्रत्येक नोड पर चलने वाला एक एजेंट। यह सुनिश्चित करता है कि पॉड्स में वर्णित कंटेनर चल रहे हैं और स्वस्थ हैं।
68-   **क्यूब-प्रॉक्सी**: एक नेटवर्क प्रॉक्सी जो नोड्स पर नेटवर्क नियमों का प्रबंधन करता है। यह क्लस्टर के अंदर या बाहर नेटवर्क सत्रों से पॉड्स के लिए नेटवर्क संचार की अनुमति देता है।
69-   **कंटेनर रनटाइम**: कंटेनरों को चलाने के लिए जिम्मेदार सॉफ्टवेयर। डॉकर सबसे प्रसिद्ध है, लेकिन कुबेरनेट्स `containerd` और `CRI-O` जैसे अन्य रनटाइम का भी समर्थन करता है।
70~
71## मौलिक कुबेरनेट्स ऑब्जेक्ट्स
72~
73कुबेरनेट्स में, सब कुछ **ऑब्जेक्ट्स** द्वारा दर्शाया जाता है। ये ऑब्जेक्ट "इरादे के रिकॉर्ड" हैं: एक बार जब आप एक ऑब्जेक्ट बनाते हैं, तो कुबेरनेट्स लगातार यह सुनिश्चित करने के लिए काम करता है कि यह मौजूद है और वांछित स्थिति से मेल खाता है।
74~
75यहाँ सबसे महत्वपूर्ण हैं:
76~
77### पॉड
78~
79**पॉड** कुबेरनेट्स में सबसे छोटी निष्पादन इकाई है। यह एक या एक से अधिक कंटेनरों का प्रतिनिधित्व करता है जो एक ही नोड पर एक साथ चलाए जाते हैं, नेटवर्क और स्टोरेज जैसे संसाधनों को साझा करते हैं।
80~
81आमतौर पर, आप प्रति पॉड केवल एक कंटेनर चलाते हैं, लेकिन उन्नत परिदृश्यों में (जैसे लॉगिंग या निगरानी के लिए "साइडकार कंटेनर"), आपके पास अधिक हो सकते हैं।
82~
83आप लगभग कभी भी सीधे पॉड नहीं बनाते हैं। आप डिप्लॉयमेंट्स जैसे उच्च-स्तरीय अमूर्तता का उपयोग करते हैं।
84~
85### डिप्लॉयमेंट
86~
87एक **डिप्लॉयमेंट** वह ऑब्जेक्ट है जिसका आप सबसे अधिक उपयोग करेंगे। यह समान पॉड्स के समूह के लिए वांछित स्थिति का वर्णन करता है। डिप्लॉयमेंट नियंत्रक इसके लिए जिम्मेदार है:
88~
89-   एक **रेप्लिकासेट** बनाना और प्रबंधित करना (एक और ऑब्जेक्ट जो यह सुनिश्चित करता है कि एक पॉड की एक विशिष्ट संख्या में प्रतिकृतियां हमेशा चल रही हैं)।
90-   पॉड्स की संख्या को ऊपर या नीचे **स्केल** करना।
91-   बिना डाउनटाइम के, नियंत्रित तरीके से एप्लिकेशन **अपडेट** का प्रबंधन करना (जैसे, *रोलिंग अपडेट*)।
92~
93यहाँ एक डिप्लॉयमेंट के लिए एक उदाहरण YAML फ़ाइल है जो एक NGINX सर्वर की 3 प्रतिकृतियां चलाती है:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### सर्विस
119~
120कुबेरनेट्स में पॉड क्षणभंगुर होते हैं: उन्हें किसी भी समय बनाया और नष्ट किया जा सकता है। प्रत्येक पॉड का अपना आईपी पता होता है, लेकिन यह आईपी स्थिर नहीं होता है। तो, हम अपने एप्लिकेशन को मज़बूती से कैसे उजागर करते हैं?
121~
122एक **सर्विस** के साथ। एक सर्विस एक अमूर्तता है जो पॉड्स के एक तार्किक सेट और उन तक पहुँचने की नीति को परिभाषित करती है। यह पॉड्स के एक समूह के लिए एक **स्थिर पहुँच बिंदु** (एक वर्चुअल आईपी पता और एक डीएनएस नाम) प्रदान करता है।
123~
124```mermaid
125graph TD
126    subgraph "सर्विस (nginx-service)"
127        A["क्लस्टरआईपी: 10.96.0.10"]
128    end
129~
130    subgraph "पॉड्स"
131        B("पॉड 1 - आईपी: 192.168.1.2")
132        C("पॉड 2 - आईपी: 192.168.1.3")
133        D("पॉड 3 - आईपी: 192.168.1.4")
134    end
135~
136    A -- "चयनकर्ता: app=nginx" --> B
137    A -- "चयनकर्ता: app=nginx" --> C
138    A -- "चयनकर्ता: app=nginx" --> D
139~
140    Client -- "nginx-service को अनुरोध" --> A
141```
142~
143सर्विस `लेबल` पर आधारित `चयनकर्ता` का उपयोग उन पॉड्स को खोजने के लिए करता है जिन्हें इसे ट्रैफ़िक अग्रेषित करना चाहिए।
144~
145यहाँ हमारे NGINX डिप्लॉयमेंट के लिए एक सर्विस कैसे बनाएँ:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # डिफ़ॉल्ट - केवल क्लस्टर के भीतर सेवा को उजागर करता है
161```
162~
163विभिन्न प्रकार की सेवाएँ हैं:
164- `क्लस्टरआईपी`: सेवा को क्लस्टर-आंतरिक आईपी पर उजागर करता है (डिफ़ॉल्ट)।
165- `नोडपोर्ट`: प्रत्येक वर्कर नोड पर एक स्थिर पोर्ट पर सेवा को उजागर करता है।
166- `लोडबैलेंसर`: क्लाउड प्रदाता (जैसे, AWS, GCP) में एक बाहरी लोड बैलेंसर बनाता है और सेवा को एक सार्वजनिक आईपी सौंपता है।
167~
168### इनग्रेस
169~
170एक `लोडबैलेंसर` सर्विस बहुत अच्छी है, लेकिन प्रत्येक सेवा के लिए एक बनाना महंगा हो सकता है। बाहरी दुनिया के लिए कई HTTP/HTTPS सेवाओं को उजागर करने के लिए, आप एक **इनग्रेस** का उपयोग करते हैं।
171~
172एक इनग्रेस बाहरी यातायात के लिए एक "बुद्धिमान राउटर" के रूप में कार्य करता है। यह आपको होस्ट (जैसे, `api.mysite.com`) या पथ (जैसे, `mysite.com/api`) के आधार पर रूटिंग नियम परिभाषित करने की अनुमति देता है।
173~
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("API पॉड 1")
184        ServiceA --> PodA2("API पॉड 2")
185~
186        ServiceB --> PodB1("UI पॉड 1")
187        ServiceB --> PodB2("UI पॉड 2")
188    end
189```
190~
191यहाँ एक इनग्रेस का एक उदाहरण है:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### अन्य उपयोगी ऑब्जेक्ट्स
220~
221-   **नेमस्पेस**: आपको एक भौतिक क्लस्टर के अंदर "वर्चुअल क्लस्टर" बनाने की अनुमति देता है। वातावरणों (जैसे, `development`, `staging`, `production`) या टीमों को अलग करने के लिए उपयोगी।
222-   **कॉन्फिगमैप और सीक्रेट**: कंटेनर छवि से अलग किए गए कॉन्फ़िगरेशन डेटा और रहस्यों (जैसे पासवर्ड या एपीआई कुंजी) का प्रबंधन करने के लिए।
223-   **स्टेटफुलसेट**: एक डिप्लॉयमेंट के समान, लेकिन स्टेटफुल अनुप्रयोगों (जैसे डेटाबेस) के लिए विशिष्ट है जिन्हें स्थिर नेटवर्क पहचान और स्थायी भंडारण की आवश्यकता होती है।
224-   **परसिस्टेंटवॉल्यूम (पीवी) और परसिस्टेंटवॉल्यूमक्लेम (पीवीसी)**: क्लस्टर में स्थायी भंडारण का प्रबंधन करने के लिए।
225~
226## निष्कर्ष
227~
228कुबेरनेट्स एक अविश्वसनीय रूप से शक्तिशाली उपकरण है, लेकिन इसकी सीखने की अवस्था खड़ी हो सकती है। इस गाइड ने केवल सतह को खरोंचा है, लेकिन हमें उम्मीद है कि इसने आपको बुनियादी अवधारणाओं की ठोस समझ दी है।
229~
230**अब क्या करें?**
231- **स्थानीय रूप से प्रयोग करें**: अपने कंप्यूटर पर कुबेरनेट्स क्लस्टर बनाने के लिए [मिनिक्यूब](https://minikube.sigs.k8s.io/docs/start/) या [काइंड](https://kind.sigs.k8s.io/docs/user/quick-start/) स्थापित करें।
232- **`kubectl` का उपयोग करें**: `kubectl` कमांड से परिचित हों, जो क्लस्टर के साथ बातचीत करने के लिए आपका मुख्य उपकरण है। इस लेख से NGINX डिप्लॉयमेंट और सर्विस बनाने का प्रयास करें।
233- **आधिकारिक ट्यूटोरियल देखें**: [कुबेरनेट्स दस्तावेज़ीकरण](https://kubernetes.io/docs/tutorials/) उदाहरणों से भरा एक शानदार संसाधन है।
234~
235कंटेनर ऑर्केस्ट्रेशन क्लाउड-नेटिव दुनिया में एक मौलिक कौशल है, और कुबेरनेट्स में महारत हासिल करना संभावनाओं की दुनिया खोल देगा। मज़े करो!