3-नोड होमलैब के लिए कuberneties वितरणों की तुलना

हमारे होमलैब के लिए सर्वोत्तम कubernates फ्लेवर का चयन

Page content

मैं स्व-होस्टेड क्यूबर्नेट्स वैरिएंट्स की तुलना कर रहा हूँ जो यूबंटू-आधारित होमलैब के लिए उपयुक्त हैं जिसमें 3 नोड्स हैं (प्रत्येक में 16GB RAM, 4 कोर), जिसमें सेटअप और रखरखाव की आसानी, पर्सिस्टेंट वॉल्यूम्स और लोडबालेंसर का समर्थन पर ध्यान केंद्रित किया गया है।

परिदृश्य: हमारे पास तीन यूबंटू नोड्स (16 GB RAM, 4 CPU कोर प्रत्येक) होमलैब में हैं। हाई-एवेलिएबिलिटी (HA) और ARM समर्थन प्राथमिकता नहीं हैं। हम एक आसान-से-इंस्टॉल, कम-रखरखाव क्यूबर्नेट्स क्लस्टर चाहते हैं (या तो सिंगल-नोड या 3-नोड) जिसमें पर्सिस्टेंट वॉल्यूम्स (PV) और लोडबालेंसर (LB) सर्विसों का समर्थन हो (ताकि स्टोरेज या बाहरी आईपी की आवश्यकता वाले क्लाउड-नेटिव ऐप्स सुचारू रूप से काम करें)। हम 3-नोड क्लस्टर विकल्पों पर ध्यान केंद्रित करेंगे बिना HA या ARM CPU संगतता की आवश्यकताओं के।

क्यूबर्नेट्स होमलैब

नीचे हम लोकप्रिय लाइटवेट [क्यूबर्नेट्स(https://www.glukhov.org/hi/post/2024/10/kubernetes-cheatsheet/ “सबसे आम और उपयोगी k8s कमांड्स की सूची और विवरण - k8s चीटशीट”) डिस्ट्रीब्यूशन – K3s, MicroK8s, Minikube, और kubeadm (वैनिला क्यूबर्नेट्स) – की तुलना करते हैं और देखते हैं कि वे मुख्य मानदंडों (फीचर्स, इंस्टॉलेशन/रखरखाव, PV/LB समर्थन, रिसोर्स आवश्यकताएं, क्लस्टर सेटअप, और टूलिंग) पर कैसे प्रदर्शन करते हैं। इसके अलावा, होमलैब परिदृश्य के आधार पर किसे चुनने के लिए कुछ सिफारिशें भी हैं।

K3s (Rancher का लाइटवेट क्यूबर्नेट्स)

मुख्य विशेषताएं: K3s एक CNCF-सर्टिफाइड क्यूबर्नेट्स डिस्ट्रीब्यूशन है जो न्यूनतम रिसोर्स उपयोग के लिए डिज़ाइन किया गया है (यह 512 MB RAM से भी चल सकता है)। यह पूरे क्यूबर्नेट्स कंट्रोल प्लेन को एक ही बाइनरी और प्रक्रिया में पैक करता है, लाइटवेट घटकों का उपयोग करता है (जैसे कि डिफ़ॉल्ट में etcd के बजाय SQLite डेटास्टोर, नेटवर्किंग के लिए flannel)। इसमें ट्रैफिक के लिए एक बिल्ट-इन इंग्रेस कंट्रोलर (Traefik) और एक सरल सर्विस लोडबालेंसर शामिल है। K3s पुराने/अल्फा फीचर्स को हटा देता है ताकि ब्लॉट कम हो।

  • इंस्टॉलेशन और रखरखाव की आसानी: अत्यंत सरल - हम इसे एक-लाइन स्क्रिप्ट (curl ... | sh) के साथ इंस्टॉल कर सकते हैं या K3sup जैसे टूल्स का उपयोग कर सकते हैं। सर्वर डिफ़ॉल्ट घटकों के साथ आउट-ऑफ-द-बॉक्स बूट होता है। नोड्स जोड़ना सरल है (एजेंट को सर्वर से एक टोकन के साथ चलाएं)। अपग्रेड करना आसान है (बाइनरी बदलें या नए संस्करण के लिए इंस्टॉलेशन स्क्रिप्ट का उपयोग करें)। अलग से etcd सेटअप की आवश्यकता नहीं है (सिवाय जब आप एक मल्टी-मास्टर HA सेटअप चुनते हैं)। K3s को इंस्टॉल करने के बाद कम से कम फिडलिंग की आवश्यकता होती है, जिससे यह IoT और होमलैब्स के लिए लोकप्रिय होता है।

  • पर्सिस्टेंट वॉल्यूम समर्थन: बिल्ट-इन. डिफ़ॉल्ट में, K3s Rancher के local-path स्टोरेजक्लास के साथ आता है, जो प्रत्येक PVC के लिए होस्ट फाइलसिस्टम पर PVs को डायनेमिक रूप से प्रोविजन करता है। इसका मतलब है कि कोई भी PVC होस्टपाथ वॉल्यूम बनाकर स्वचालित रूप से पूरा हो जाएगा। यह एक सिंगल-नोड स्टोरेज समाधान है (प्रत्येक वॉल्यूम एक नोड के डिस्क पर होता है), लेकिन स्टेटफुल ऐप्स के लिए यह आउट-ऑफ-द-बॉक्स काम करता है। अधिक उन्नत स्टोरेज के लिए, हम Rancher के Longhorn (डिस्ट्रीब्यूटेड ब्लॉक स्टोरेज) जैसे कुछ जोड़ सकते हैं, जिसे K3s समर्थन करता है, लेकिन होमलैब के लिए डिफ़ॉल्ट local-path प्रोविजनर आमतौर पर पर्याप्त होता है।

  • लोडबालेंसर समर्थन: बिल्ट-इन. K3s में एक लाइटवेट कंट्रोलर ServiceLB (पहले “Klipper LB” कहा जाता था) शामिल है जो LoadBalancer प्रकार के सर्विसों को होस्ट पर एक IP/पोर्ट प्रदान करता है बिना किसी बाहरी क्लाउड प्रोवाइडर के। जब हम एक लोडबालेंसर सर्विस बनाते हैं, तो K3s प्रत्येक नोड पर छोटे LB पॉड्स (svc-...) का एक डेमनसेट तैनात करता है, जो होस्ट पोर्ट्स का उपयोग करके ट्रैफिक को सर्विस के लिए फॉरवर्ड करते हैं। मूल रूप से, K3s नोड के IP (आंतरिक या बाहरी) का उपयोग LB IP के रूप में करता है, और LB पॉड्स में iptables रूटिंग का उपयोग करता है ताकि ट्रैफिक को सर्विस के ClusterIP पर भेजा जा सके। यह जीरो कॉन्फ़िगरेशन के साथ काम करता है – सर्विस “पेंडिंग” नहीं रहेंगे (वैनिला K8s पर बेयर मेटल के विपरीत)। ट्रेड-ऑफ यह है कि LB बाहरी IP हमारे नोड के IP (या सभी नोड) में से एक होगा और हमें सुनिश्चित करना होगा कि पोर्ट फ्री है। अधिकांश होमलैब उपयोगों (HTTP/HTTPS पोर्ट्स पर कुछ सर्विसों को एक्सपोज़ करने) के लिए यह बिल्कुल ठीक है। अगर आवश्यक हो, तो हम बिल्ट-इन LB को डिसएबल कर सकते हैं और MetalLB को मैन्युअल रूप से इंस्टॉल कर सकते हैं, लेकिन अधिकांश उपयोगकर्ता सुविधाजनक डिफ़ॉल्ट के साथ रहते हैं।

  • रिसोर्स आवश्यकताएं: बहुत कम। K3s कम-एंड हार्डवेयर पर भी चल सकता है। आधिकारिक रूप से, 512 MB RAM और डिस्क के कुछ सौ MB सर्वर नोड के लिए पर्याप्त हैं। वास्तव में, एक छोटा क्लस्टर कंट्रोल प्लेन के लिए कुछ सौ MB मेमोरी का उपयोग कर सकता है। इसका बाइनरी <100 MB है। CPU ओवरहेड न्यूनतम है (K3s MicroK8s की तुलना में आइडल स्थिति में थोड़ा अधिक CPU का उपयोग करता है, लेकिन बहुत बड़ी मार्जिन से नहीं)। हमारे नोड्स (प्रत्येक में 16 GB) K3s को आराम से चलाने के लिए बहुत पर्याप्त हैं।

  • सिंगल-नोड बनाम मल्टी-नोड: दोनों के लिए उपयुक्त। K3s सिंगल-नोड (एक ही मशीन पर सभी कंट्रोल-प्लेन और वर्कलोड्स) या मल्टी-नोड के रूप में चल सकता है। 3-नोड सेटअप के लिए, हम 1 सर्वर (मास्टर) और 2 एजेंट्स चला सकते हैं, या तो HA के लिए सभी 3 सर्वर बना सकते हैं (यहाँ HA एक लक्ष्य नहीं है इसलिए आवश्यक नहीं है)। एजेंट्स को टोकन के साथ जोड़ना त्रिवेणी है। K3s का डिफ़ॉल्ट SQLite डेटास्टोर सिंगल-सर्वर के लिए काम करता है; मल्टी-सर्वर HA के लिए हम एम्बेडेड etcd (K3s कई सर्वर नोड्स शुरू करने पर स्वचालित रूप से यह कर सकता है) पर स्विच करेंगे।

  • CLI & UI टूल्स: हम K3s के साथ kubectl के माध्यम से ठीक उसी तरह इंटरैक्ट करते हैं जैसे किसी भी क्यूबर्नेट्स के साथ। K3s में अपना kubectl बिल्ड शामिल है (हम k3s kubectl ... चला सकते हैं या बस एक मानक kubectl का उपयोग करके इसे K3s के kubeconfig पर निर्देशित कर सकते हैं)। इंस्टॉलेशन कमांड्स के अलावा K3s-विशिष्ट CLI नहीं है; यह इरादतन मिनिमलिस्ट है। कोई बिल्ट-इन वेब UI शामिल नहीं है (अपस्ट्रीम डैशबोर्ड डिफ़ॉल्ट में इंस्टॉल नहीं किया जाता है)। हालांकि, हम K3s पर किसी भी मानक क्लस्टर की तरह Kubernetes Dashboard या अन्य टूल्स को मैन्युअल रूप से तैनात कर सकते हैं। Rancher (उसी कंपनी द्वारा बनाया गया GUI प्रबंधन टूल) को K3s पर इंस्टॉल किया जा सकता है अगर एक पूर्ण UI चाहिए, लेकिन यह K3s का हिस्सा नहीं है। मूल रूप से, K3s कोर k8s APIs प्रदान करता है और हम आवश्यकतानुसार अतिरिक्त जोड़ते हैं (इंग्रेस, स्टोरेज, आदि - जिनमें से कुछ पहले से ही पैक किए गए हैं जैसा कि उल्लेख किया गया है)।

MicroK8s (Canonical का लो-ऑप्स क्यूबर्नेट्स)

मुख्य विशेषताएं: MicroK8s Canonical का लाइटवेट क्यूबर्नेट्स डिस्ट्रीब्यूशन है, जो एक स्नैप पैकेज के रूप में प्रदान किया जाता है। यह एक सिंगल कमांड के साथ एक पूर्ण रूप से अनुकूलित क्यूबर्नेट्स क्लस्टर (अपस्ट्रीम बाइनरी) इंस्टॉल करता है और इसे एक मशीन या छोटे क्लस्टर पर आसान उपयोग के लिए डिज़ाइन किया गया है। यह “बैटरीज-इनक्लूडेड” दृष्टिकोण पर जोर देता है - हम सरल कमांड्स के साथ कई वैकल्पिक फीचर्स प्राप्त करते हैं। MicroK8s डिफ़ॉल्ट में एक वैनिला क्यूबर्नेट्स अनुभव प्रदान करता है (सभी मानक APIs) लेकिन आम आवश्यकताओं के लिए सुविधाजनक एड-ऑन्स के साथ। यह सिंगल-नोड और मल्टी-नोड डिप्लॉयमेंट्स का समर्थन करता है (हम नोड्स को “जॉइन” करके एक क्लस्टर बना सकते हैं), और यहां तक कि कंट्रोल प्लेन के लिए एक HA मोड भी है (Dqlite - एक डिस्ट्रीब्यूटेड SQLite - का उपयोग करते हुए जब हमारे पास 3 मास्टर होते हैं)।

  • इंस्टॉलेशन और रखरखाव की आसानी: बहुत आसान - बस snap install microk8s --classic एक यूबंटू मशीन पर चलाना है तो एक क्यूबर्नेट्स नोड सेटअप हो जाएगा। यह एक पैकेज है जिसमें सभी घटक शामिल हैं। MicroK8s को यूबंटू के स्नैप सिस्टम के माध्यम से बनाए रखा जाता है, जिसका मतलब है कि अपडेट्स एटॉमिक होते हैं और स्वचालित हो सकते हैं (हम Kubernetes संस्करणों के लिए एक चैनल ट्रैक कर सकते हैं)। यह स्वचालित अपडेट क्षमता इन विकल्पों में अद्वितीय है - हम सुरक्षा पैच और माइनर अपग्रेड्स के लिए स्नैप रिफ्रेश के माध्यम से ऑप्ट-इन कर सकते हैं। MicroK8s को microk8s कमांड के माध्यम से प्रबंधित किया जाता है, जिसमें फीचर्स को इनेबल/डिसएबल करने के लिए सबकमांड्स होते हैं। समग्र रूप से, यह बहुत कम फ्रिक्शन वाला है: कोई कंटेनर्स या VMs प्रबंधित करने की आवश्यकता नहीं है (होस्ट पर स्वदेशी रूप से चलता है), और कोई बाहरी etcd कॉन्फ़िगर करने की आवश्यकता नहीं है (एक आंतरिक डेटास्टोर का उपयोग करता है)। रखरखाव मुख्य रूप से स्नैप को अपडेट करने और microk8s.status का उपयोग करके निगरानी करने तक सीमित है।

  • पर्सिस्टेंट वॉल्यूम समर्थन: एड-ऑन के माध्यम से उपलब्ध। डिफ़ॉल्ट में, MicroK8s PVCs के लिए स्वचालित रूप से PVs प्रोविजन नहीं करता है जब तक कि हम “hostpath-storage” एड-ऑन को इनेबल नहीं करते। इसे इनेबल करना (सबसे microk8s enable hostpath-storage) एक डिफ़ॉल्ट स्टोरेजक्लास बनाता है जो होस्ट के एक डायरेक्टरी से वॉल्यूम्स आवंटित करता है। यह मूल रूप से K3s के local-path के समान एक डायनेमिक hostPath प्रोविजनर है। एक बार इनेबल होने पर, कोई भी PVC MicroK8s नोड पर एक hostpath PV से बाइंड हो जाएगा। (एक मल्टी-नोड MicroK8s क्लस्टर में, hostpath PV एक नोड पर रहेगा - टेस्टिंग या होमलैब उपयोग के लिए उपयुक्त लेकिन डिस्ट्रीब्यूटेड स्टोरेज नहीं)। MicroK8s Mayastor और अन्य स्टोरेज एड-ऑन्स भी प्रदान करता है अगर हम नोड्स के बीच अधिक उन्नत स्टोरेज चाहते हैं, लेकिन सरलता के लिए hostpath स्टोरेज अच्छा काम करता है। नोट: एड-ऑन डिफ़ॉल्ट में इनेबल नहीं होता है (चिज़ों को लीन रखने के लिए), इसलिए हम PVCs को काम करने के लिए इसे इनेबल करना चाहेंगे। Canonical यह नोट करता है कि यह उत्पादन HA उपयोग के लिए नहीं है (क्योंकि यह रिप्लिकेटेड नहीं है), लेकिन होमलैब के लिए यह आदर्श है।

  • लोडबालेंसर समर्थन: एड-ऑन के माध्यम से उपलब्ध। MicroK8s में एक डिफ़ॉल्ट लोडबालेंसर बंडल नहीं होता है, लेकिन यह MetalLB को एक आसान एड-ऑन के रूप में प्रदान करता है। microk8s enable metallb:<start-IP>-<end-IP> चलाना MetalLB को लेयर 2 मोड में तैनात करता है और हमें अपने LAN से LoadBalancer सर्विसों के लिए उपयोग करने के लिए IP पूल निर्दिष्ट करने देता है। एक बार इनेबल होने पर, कोई भी LoadBalancer प्रकार का सर्विस स्वचालित रूप से उस रेंज से एक IP प्राप्त करेगा (और MicroK8s इसे LAN पर ARP के माध्यम से विज्ञापित करेगा)। यह बेयर मेटल पर एक क्लाउड-जैसा अनुभव प्रदान करता है। (अगर हम MetalLB को इनेबल नहीं करते हैं, तो एक LoadBalancer सर्विस पेंडिंग रहेगा, क्योंकि MicroK8s खुद से एक नहीं लागू करता है - जैसे कि अपस्ट्रीम Kubernetes।) एक होमलैब में, MetalLB सरल है और हमें अपने स्थानीय नेटवर्क पर सर्विसों तक पहुंचने देता है। हमें इसके लिए अपने नेटवर्क में एक फ्री सबनेट या IP रेंज चुननी होगी। MicroK8s का इनेबल कमांड सेटअप को दर्दरहित बनाता है, लेकिन यह अभी भी एक अलग चरण है। (विरोध में, K3s LB के लिए आउट-ऑफ-द-बॉक्स काम करता है लेकिन नोड IP/पोर्ट्स का उपयोग करने के साथ सीमाओं के साथ।) कई MicroK8s उपयोगकर्ता एक कार्यात्मक LB के लिए अपने प्रारंभिक सेटअप के हिस्से के रूप में MetalLB को इनेबल कर देते हैं।

  • रिसोर्स आवश्यकताएं: MicroK8s काफी हल्का है, हालांकि K3s की तुलना में फुटप्रिंट थोड़ा अधिक है। यह सभी कोर सर्विसों (API सर्वर, कंट्रोलर, स्केड्यूलर, kubelet, etcd या Dqlite) स्वदेशी रूप से चलाता है। आइडल उपयोग आमतौर पर कंट्रोल प्लेन के लिए \ 500–600 MB RAM होता है, जो यह निर्भर करता है कि कौन से एड-ऑन्स इनेबल किए गए हैं। Canonical 540 MB बेसलाइन मेमोरी का उल्लेख करता है। आइडल स्थिति में CPU उपयोग कम होता है, और हमारे 16 GB नोड्स के पास पर्याप्त हेडरूम है। डिस्क स्पेस आवश्यकता छोटी है (स्नैप \ 200 MB प्लस etcd डेटा)। समग्र रूप से, MicroK8s मध्यम हार्डवेयर पर चल सकता है (यह तो Raspberry Pis के लिए भी ऑफर किया जाता है), और हमारे परिदृश्य में मशीनें इसे आसानी से समाहित कर लेती हैं। अगर कई एड-ऑन्स इनेबल किए गए हैं (डैशबोर्ड, मॉनिटरिंग, आदि), तो रिसोर्स उपयोग संबंधित रूप से बढ़ जाएगा।

  • सिंगल-नोड बनाम मल्टी-नोड: MicroK8s दोनों के लिए अच्छा काम करता है। हम इसे एक सिंगल-नोड क्लस्टर (जैसे कि एक डेव मशीन या एक सर्वर पर) के लिए उपयोग कर सकते हैं या नोड्स को “जॉइन” करके एक मल्टी-नोड क्लस्टर बना सकते हैं। MicroK8s दस्तावेज़ीकरण एक कमांड प्रदान करता है नोड जोड़ने के लिए (हम पहले नोड से एक जॉइन टोकन प्राप्त करते हैं और इसे अन्य पर उपयोग करते हैं)। एक मल्टी-नोड सेटअप में बिना HA के, एक नोड प्राथमिक कंट्रोल प्लेन होगा। 3 नोड्स के साथ, हम ha-cluster मोड इनेबल करने का विकल्प भी रखते हैं (Dqlite को 3 नोड्स पर चलाकर कंट्रोल प्लेन को HA बनाना), हालांकि हमारे मामले में HA की आवश्यकता नहीं है। सिंगल या तीन नोड्स के साथ, अनुभव वही Kubernetes API है। मल्टी-नोड MicroK8s K3s के दृष्टिकोण से थोड़ा नया है लेकिन अब काफी स्थिर है। यह एक अच्छा विकल्प है अगर हम कुछ यूबंटू बॉक्सों पर k8s चलाने वाले एक “माइक्रो क्लाउड” चाहते हैं जिसमें कम से कम प्रयास।

  • CLI & UI टूल्स: MicroK8s में microk8s कमांड-लाइन टूल शामिल है, जो बहुत उपयोगी है। उदाहरण के लिए, microk8s enable <addon> विभिन्न सर्विसों (DNS, इंग्रेस, स्टोरेज, metallb, डैशबोर्ड, आदि) को टॉगल करता है, और microk8s status दिखाता है कि क्या चल रहा है। यह एक एम्बेडेड kubectl भी शामिल करता है: हम microk8s kubectl ... (या इसे एक एलियास बनाकर) का उपयोग कर सकते हैं जो क्लस्टर से बात करता है - यह अच्छा है क्योंकि हमें kubeconfig कॉन्फ़िगर करने की आवश्यकता नहीं है। UI के लिए, MicroK8s Kubernetes Dashboard को एक एड-ऑन (microk8s enable dashboard) के रूप में प्रदान करता है, जो मानक वेब UI तैनात करेगा। एक बार इनेबल होने पर, हम इसे एक्सेस कर सकते हैं (यह पोर्ट 10443 पर या प्रॉक्सी के माध्यम से चलता है)। MicroK8s के पास अपना कस्टम GUI नहीं है - यह Kubernetes Dashboard या अन्य टूल्स पर निर्भर करता है - लेकिन इसे इनेबल करने की आसानी एक फायदा है। सारांश में, MicroK8s आम कार्यों के लिए एक-कमांड अनुभव और “यह बस काम करता है” दर्शन पर जोर देता है, बहुत सारी जटिलता को छिपा देता है (अंतर्निहित कुछ को छिपाने के बदले में)। यह इसे बहुत होमलैब-फ्रेंडली बनाता है उन लोगों के लिए जो प्रत्येक घटक के मैन्युअल सेटअप के बिना एक Kubernetes क्लस्टर चाहते हैं।

K3s vs MicroK8s की तुलना: दोनों लक्ष्यों और क्षमताओं में काफी समान हैं - हल्के, आसान, मल्टी-नोड के लिए उपयुक्त। K3s अतिरिक्त जोड़ने में थोड़ा अधिक “DIY” होता है (Helm चार्ट्स या मैन्युअल मैनिफेस्ट्स के लिए निर्भर करता है जिनका समावेश नहीं है) जबकि MicroK8s अपने CLI के माध्यम से बिल्ट-इन एड-ऑन्स प्रदान करता है। MicroK8s भी नीचे की तह में अधिक “वैनिला” Kubernetes है (अपस्ट्रीम घटक, बस स्नैप के रूप में पैक किए गए), जबकि K3s कुछ कस्टम बाइनरी और एक ही सेवा के लिए सब कुछ का उपयोग करता है। दोनों होमलैब के लिए अच्छे विकल्प हैं; निर्णय अक्सर पसंद पर आता है: अगर यूबंटू/स्नैप और एक एकीकृत महसूस पसंद है, तो MicroK8s उत्कृष्ट है, जबकि अगर हम एक मिनिमलिस्ट दृष्टिकोण पसंद करते हैं जिसमें शायद थोड़ा अधिक मैन्युअल नियंत्रण है, तो K3s उत्कृष्ट है। (हम अंत में सिफारिशें प्रदान करेंगे।)

मिनिक्यूब (सिंगल-नोड लोकल के8स)

मुख्य विशेषताएं: मिनिक्यूब मुख्य रूप से एक टूल है जो के8स (कुबर्नेट्स) को लोकल रूप से चलाने के लिए होता है, जो आमतौर पर एक डेवलपर के पीसी या लैपटॉप पर होता है, बजाय कई मशीनों पर फैले हुए पारंपरिक क्लस्टर के। यह हमारे मशीन पर एक वीएम या कंटेनर में एक सिंगल-नोड के8स क्लस्टर बनाता है। मिनिक्यूब अपने वाइड सपोर्ट ऑफ एन्वायरनमेंट्स के लिए जाना जाता है - यह लिनक्स, मैकओएस, विंडोज पर चल सकता है और विभिन्न हाइपरवाइजर्स (वर्चुअलबॉक्स, केवीएम, हाइपर-वी, डॉकर ड्राइवर, आदि) का सपोर्ट करता है। यह के8स SIGs द्वारा बनाए रखा जाता है और अक्सर टेस्टिंग और लर्निंग के लिए इस्तेमाल किया जाता है। हालांकि मिनिक्यूब को एक मल्टी-नोड कॉन्फ़िगरेशन में लाया जा सकता है, लेकिन यह मूल रूप से एक-नोड क्लस्टर के लिए बनाया गया है (मिनिक्यूब का “मल्टी-नोड” मोड वास्तव में सिर्फ एक ही होस्ट पर कंटेनर रनटाइम्स का इस्तेमाल करके कई नोड्स स्टार्ट करता है - जो एक क्लस्टर को सिमुलेट करने के लिए उपयोगी है, लेकिन अलग-अलग भौतिक मशीनों पर चलाने के लिए नहीं है)।

  • इंस्टॉलेशन और उपयोग की आसानी: मिनिक्यूब एक सिंगल मशीन पर शुरू करने में बहुत आसान है। हम मिनिक्यूब बाइनरी इंस्टॉल करते हैं, सुनिश्चित करते हैं कि हमारे पास एक वीएम ड्राइवर (या डॉकर) है, और minikube start चलाते हैं। यह एक लोकल वीएम/कंटेनर सेटअप करेगा और उसमें के8स लॉन्च करेगा। यह संभवतः एक के8स क्लस्टर चलाने के लिए सबसे सरल तरीका है। CLI (minikube) कमांड्स प्रदान करता है जो वीएम के साथ इंटरैक्ट करने के लिए हैं (स्टार्ट, स्टॉप, डिलीट) और एड-ऑन्स को इनेबल करने के लिए। क्योंकि मिनिक्यूब लोकल उपयोग के लिए डिज़ाइन किया गया है, यह एक “लॉन्ग-रनिंग” डेमन नहीं है - हम आमतौर पर इसे तब स्टार्ट करते हैं जब हमें इसकी ज़रूरत होती है और जब हम खत्म होते हैं तो इसे स्टॉप करते हैं, हालांकि हम इसे एक होमलैब सर्वर पर लगातार चलाने का विकल्प भी रखते हैं। मेन्टेनेंस/अपग्रेड आसान हैं: बस मिनिक्यूब संस्करण को अपडेट करें और क्लस्टर को रीस्टार्ट करें (मिनिक्यूब के8स संस्करण को भी एक फ्लैग के साथ अपडेट कर सकता है)। हालांकि, एक सीमा यह है कि मिनिक्यूब डिज़ाइन में सिंगल-नोड है (अधिक नोड्स जोड़ने का मतलब है उसी होस्ट पर अतिरिक्त वीएम इंस्टेंस स्टार्ट करना, नहीं कि वास्तविक अलग-अलग होस्ट्स को जोड़ना)। इसलिए, मिनिक्यूब को तीन अलग-अलग भौतिक नोड्स पर चलाने का मतलब तीन स्वतंत्र सिंगल-नोड क्लस्टर चलाना होगा, जो संभवतः हमारी इच्छा नहीं है। मिनिक्यूब डेवलपमेंट और टेस्टिंग के लिए एक मशीन पर चमकता है, लेकिन यह कई भौतिक सर्वरों पर फैले हुए क्लस्टर को मैनेज करने के लिए नहीं है।

  • पर्सिस्टेंट वॉल्यूम सपोर्ट: बिल्ट-इन (होस्टपाथ). मिनिक्यूब क्लस्टर स्वचालित रूप से एक डिफ़ॉल्ट स्टोरेजक्लास शामिल करते हैं जो एक होस्टपाथ प्रोविज़नर का उपयोग करते हैं। वास्तव में, मिनिक्यूब एक छोटा कंट्रोलर चलाता है जो वीएम के अंदर PVCs की मांग होने पर डायनामिक रूप से होस्टपाथ PVs बनाता है। इसका मतलब है कि हम PersistentVolumeClaims बना सकते हैं और वे मिनिक्यूब वीएम के फ़ाइलसिस्टम पर स्टोरेज का उपयोग करके संतुष्ट होंगे (आमतौर पर /tmp/hostpath-provisioner या समान के तहत)। यह आउट-ऑफ-द-बॉक्स काम करता है - बेसिक PV उपयोग के लिए कोई कॉन्फ़िगरेशन की ज़रूरत नहीं है। उदाहरण के लिए, मिनिक्यूब में डिफ़ॉल्ट “स्टैंडर्ड” स्टोरेजक्लास नोड पर होस्टपाथ स्टोरेज के लिए मैप होता है। एक चेतावनी: अगर हम मिनिक्यूब वीएम को रीस्टार्ट या डिलीट करते हैं, तो ये होस्टपाथ वॉल्यूम खो सकते हैं (मिनिक्यूब रीस्टार्ट्स के बीच कुछ डायरेक्टरीज़ को संरक्षित करने की कोशिश करता है - उदाहरण के लिए, /data, /var/lib/minikube, /tmp/hostpath* संरक्षित रहते हैं)। लेकिन सामान्यतः, एक नॉन-प्रोडक्शन एन्वायरनमेंट के लिए यह ठीक है। अगर हम अधिक सिमुलेट करना चाहते हैं, तो मिनिक्यूब में एक CSI होस्टपाथ ड्राइवर एड-ऑन भी है जो स्नैपशॉटिंग का सपोर्ट करता है और मल्टी-नोड मोड में काम कर सकता है, लेकिन यह अधिक प्रयोगात्मक है। निष्कर्ष: मिनिक्यूब होस्टपाथ के माध्यम से PVs का सपोर्ट करता है, जो स्टेटफुल ऐप्स के होमलैब टेस्ट के लिए पर्याप्त है।

  • लोडबैलेंसर सपोर्ट: टनलिंग (या MetalLB एड-ऑन) के माध्यम से सपोर्ट किया जाता है। क्लाउड में, एक लोडबैलेंसर सर्विस को एक क्लाउड LB मिलता है जिसमें एक बाहरी IP होता है। मिनिक्यूब में, स्पष्ट रूप से कोई क्लाउड प्रोवाइडर नहीं है, इसलिए मिनिक्यूब दो तंत्र प्रदान करता है:

    • मिनिक्यूब टनल: हम एक अलग प्रक्रिया में minikube tunnel चला सकते हैं जो हमारे होस्ट पर एक नेटवर्क रूट बनाएगा और हमारे लोडबैलेंसर सर्विस को एक IP असाइन करेगा। वास्तव में, यह हमारे होस्ट को “बाहरी LB” के रूप में कार्य करने के लिए उपयोग करता है। जब हम एक लोडबैलेंसर सर्विस बनाते हैं, तो मिनिक्यूब एक “बाहरी IP” दिखाएगा (आमतौर पर क्लस्टर के सबनेट से) और minikube tunnel प्रक्रिया उसको सर्विस के लिए रूट करेगी। इसके लिए टनल प्रक्रिया लगातार चलनी चाहिए (और आमतौर पर रूट अनुमति रूट्स बनाने के लिए) और यह एक छोटा कदम है, लेकिन मिनिक्यूब एक याद दिलाने वाली संदेश दिखाएगा अगर हमारे पास एक चल रही टनल के बिना लोडबैलेंसर सर्विस है (“External-IP pending” जब तक कि हम टनल स्टार्ट नहीं करते)।
    • MetalLB एड-ऑन: नए संस्करणों में मिनिक्यूब में एक MetalLB एड-ऑन भी शामिल है। हम minikube addons enable metallb कर सकते हैं और एक IP रेंज कॉन्फ़िगर कर सकते हैं (मिनिक्यूब हमसे पूछेगा)। यह प्रभावी रूप से मिनिक्यूब क्लस्टर के अंदर MetalLB डिप्लॉय करता है, जो फिर किसी भी बेयर-मेटल के8स में लोडबैलेंसर सर्विसों का हैंडलिंग करता है। यह एक अधिक “इन-क्लस्टर” समाधान है और एक अलग टनल प्रक्रिया की आवश्यकता नहीं है एक बार सेटअप के बाद।

    दोनों विकल्प काम करते हैं, और किसका उपयोग करना है यह हम पर निर्भर करता है। एक सर्विस को तेज़ी से एक्सपोज़ करने के लिए, minikube tunnel तेज़ और एफिमेरल है। एक अधिक स्थायी सेटअप के लिए, MetalLB एड-ऑन को इनेबल किया जा सकता है ताकि LBs वास्तविक IPs प्राप्त करें (उदाहरण के लिए, हम एक रेंज जैसे 10.0.0.240-250 को दे सकते हैं एक मिनिक्यूब के साथ ब्रिज्ड नेटवर्किंग)। याद रखें कि मिनिक्यूब आमतौर पर सिंगल-नोड होता है, इसलिए प्रभावी रूप से “लोड बैलेंसर” कई नोड्स के बीच बैलेंसिंग नहीं करता है - यह सिर्फ एकल नोड के सर्विस के लिए बाहरी एक्सेस प्रदान करता है। यह डेवलपमेंट के लिए ठीक है। एक होमलैब में, अगर हम अपने नोड्स में से एक का उपयोग करते हैं और उस पर मिनिक्यूब चलाते हैं, तो हम इनका उपयोग अपने ऐप्स तक पहुंचने के लिए कर सकते हैं। लेकिन अगर हम तीनों नोड्स का लाभ उठाना चाहते हैं, तो मिनिक्यूब का LB दृष्टिकोण उस स्थिति के लिए नहीं है।

  • रिसोर्स रिक्वायरमेंट्स: मिनिक्यूब स्वयं हल्का होता है, लेकिन क्योंकि यह आमतौर पर एक वीएम में एक पूर्ण सिंगल-नोड के8स चलाता है, तो रिसोर्स उपयोग एक सामान्य छोटे क्लस्टर के समान होता है। वीएम के लिए कम से कम 2 GB RAM और 2 CPUs की सिफारिश की जाती है। डिफ़ॉल्ट रूप से, मिनिक्यूब अपने वीएम के लिए 2 GB RAM आवंटित करता है। हमारे मामले में, 16 GB प्रति मशीन के साथ, यह त्रिवियल है। आइडल मिनिक्यूब (के8स) \ 600 MB मेमोरी का उपयोग कर सकता है। एक बात ध्यान में रखने योग्य है कि मिनिक्यूब हमारे OS के ऊपर चल रहा होगा - या तो एक हाइपरवाइजर के माध्यम से एक वीएम के रूप में या एक डॉकर कंटेनर के रूप में - जो कुछ ओवरहेड जोड़ता है। एक होमलैब सर्वर पर, हम मिनिक्यूब को “नोन” ड्राइवर के साथ चला सकते हैं (जो होस्ट पर के8स घटकों को सीधे इंस्टॉल करता है)। हालांकि, “नोन” (जिसे बेयर-मेटल भी कहा जाता है) ड्राइवर वास्तव में उसी के समान है जैसे कि उस नोड पर सिर्फ kubeadm का उपयोग करना, और मैन्युअल क्लीनअप की आवश्यकता होती है, इसलिए यह उतना लोकप्रिय नहीं है। अधिकांश लोग एक वीएम या डॉकर ड्राइवर का उपयोग करते हैं। सारांश में, हमारे होमलैब नोड्स में से कोई भी आसानी से मिनिक्यूब चला सकता है। एकमात्र सीमा यह है कि मिनिक्यूब तीनों नोड्स के रिसोर्स का उपयोग नहीं करेगा - यह उस एकल होस्ट पर सीमित रहेगा जिस पर यह चल रहा है (सिवाय एक होस्ट के अंदर प्रयोगात्मक मल्टी-नोड का उपयोग करने के)।

  • सिंगल-नोड बनाम मल्टी-नोड: प्राथमिक रूप से सिंगल-नोड। मिनिक्यूब एक मशीन पर एक सिंगल-नोड क्लस्टर के लिए आदर्श है। इसमें एक विशेषता है जो कई नोड्स को सिमुलेट करने के लिए है (उदाहरण के लिए, minikube start --nodes 3 डॉकर ड्राइवर के साथ तीन के8स नोड्स को एक होस्ट पर कंटेनर के रूप में स्टार्ट करेगा), लेकिन यह केवल टेस्टिंग के लिए है। हम मिनिक्यूब का उपयोग करके तीन अलग-अलग भौतिक सर्वरों पर एक वास्तविक मल्टी-नोड क्लस्टर नहीं बना सकते। अगर हमारे पास तीन मशीनें हैं, तो हमें तीन स्वतंत्र मिनिक्यूब इंस्टेंस चलाने होंगे (एक क्लस्टर में नहीं)। यह एक वास्तविक क्लस्टर अनुभव नहीं है (वे एक दूसरे के बारे में नहीं जानेंगे)। इसलिए, मिनिक्यूब सिफारिश नहीं किया जाता अगर हमारा उद्देश्य तीन नोड्स को एक के8स क्लस्टर में उपयोग करना है - यह बेहतर है जब हमारे पास एक मशीन (हमारा पीसी या एक सर्वर) है और हम उस पर के8स चलाना चाहते हैं। यह के8स बेसिक्स सीखने और लोकल डेवलपमेंट करने के लिए भी उत्कृष्ट है।

  • CLI & UI टूल्स: minikube CLI मुख्य इंटरफेस है। हम इसका उपयोग क्लस्टर स्टार्ट/स्टॉप करने के लिए करते हैं, और इसमें अच्छे शॉर्टकट्स हैं: उदाहरण के लिए, minikube dashboard के8स डैशबोर्ड को इनेबल करेगा और इसे हमारे ब्राउज़र में खोल देगा। minikube addons enable <addon> विभिन्न वैकल्पिक घटकों (इंग्रेस, metallb, metrics-server, आदि) को इनेबल कर सकता है। मिनिक्यूब स्वचालित रूप से kubectl एक्सेस सेटअप करता है (यह हमारे kubeconfig में एक कंटेक्स्ट “minikube” कॉन्फ़िगर करता है)। UI के लिए, जैसा कि उल्लेख किया गया है, के8स डैशबोर्ड dashboard कमांड के माध्यम से आसानी से एक्सेस किया जा सकता है। मिनिक्यूब के पास अपना एक अनूठा वेब UI नहीं है; यह मानक टूल्स पर निर्भर करता है। मिनिक्यूब डिबग करना भी आसान है क्योंकि हम minikube ssh का उपयोग कर सकते हैं ताकि नोड वीएम में प्रवेश कर सकें अगर आवश्यक हो। समग्र रूप से, टूलिंग एक सिंगल-नोड सिनारियो के लिए बहुत उपयोगकर्ता-मित्र है।

क्यूबेडम (वैनेला के8स हमारी अपनी नोड्स पर)

मुख्य विशेषताएं: क्यूबेडम एक “डिस्ट्रीब्यूशन” नहीं है, बल्कि सेक्रेट से एक के8स क्लस्टर बनाने के लिए आधिकारिक टूलकिट है। क्यूबेडम का उपयोग करने का मतलब है कि हम अपने मशीनों पर मानक अपस्ट्रीम के8स घटकों को डिप्लॉय कर रहे हैं। यह मूल रूप से हमारा “अपना” क्लस्टर बनाने का तरीका है, बेस्ट प्रैक्टिसेस का पालन करते हुए लेकिन उन अतिरिक्त चीजों के बिना जो डिस्ट्रीब्यूशन शामिल करते हैं। क्यूबेडम एक कंट्रोल प्लेन नोड (जिसमें etcd, API सर्वर, कंट्रोलर मैनेजर, स्केड्यूलर चल रहे हैं) सेटअप करेगा और वर्कर नोड्स को उसमें जोड़ देगा। परिणाम एक पूर्ण मानक के8स क्लस्टर होता है जो क्लाउड वीएम पर मिलने वाले के समान होता है। इस दृष्टिकोण से हमें पूर्ण नियंत्रण और लचीलापन मिलता है - हम नेटवर्किंग प्लगिन, स्टोरेज प्रोविज़नर, आदि का चयन करते हैं - लेकिन साथ ही साथ सबसे अधिक प्रारंभिक मैन्युअल काम और ज्ञान की आवश्यकता होती है। यह अक्सर प्रोडक्शन या लर्निंग एन्वायरनमेंट्स में के8स इंटरनल्स को समझने के लिए इस्तेमाल किया जाता है।

  • इंस्टॉलेशन और मेन्टेनेंस की आसानी: अन्य विकल्पों की तुलना में, क्यूबेडम सबसे अधिक शामिल है। हमें हर नोड पर मैन्युअल रूप से डिपेंडेंसीज (कंटेनर रनटाइम जैसे containerd, kubeadm, kubelet, kubectl) इंस्टॉल करने होंगे। फिर मास्टर पर kubeadm init चलाएं, और वर्कर्स पर kubeadm join चलाएं टोकन के साथ जो यह देता है। हमें इनीशियलाइज़ेशन के बाद एक CNI (नेटवर्क प्लगिन) सेटअप भी करना होगा (Calico, Flannel, आदि) क्योंकि क्यूबेडम डिफ़ॉल्ट रूप से एक नहीं इंस्टॉल करता है। इसके लिए अच्छी तरह से दस्तावेज़ीकृत चरण हैं (प्रक्रिया कठिन नहीं है, लेकिन कई चरण हैं) - वास्तव में, क्यूबेडम हमें एक शुरुआती क्लस्टर देता है लेकिन अपडेट्स की उम्मीद करता है। मेन्टेनेंस के मामले में, हम अपग्रेड (kubeadm में एक अपग्रेड कमांड है, लेकिन हमें नोड्स को ड्रेन करना, बाइनरीज अपडेट करना, आदि मैन्युअल रूप से करना होगा), etcd स्वास्थ्य, सर्टिफिकेट रिन्यूअल, आदि की निगरानी के लिए जिम्मेदार हैं। संक्षेप में, क्यूबेडम शक्तिशाली लेकिन मैन्युअल है। इसे अक्सर “द हार्ड वे” कहा जाता है (हालांकि स्रोत से बिल्ड करने से कठिन नहीं है)। एक होमलैब हॉबीस्ट के लिए जो सीखना पसंद करता है, क्यूबेडम के8स को गहरे से समझने का एक अच्छा तरीका है। लेकिन अगर हमारी प्राथमिकता “आसान और कम मेन्टेनेंस” है, तो क्यूबेडम K3s/MicroK8s से अधिक काम होगा। हर अपग्रेड या बदलाव के लिए हाथों-हाथ प्रयास की आवश्यकता होगी। इसके बावजूद, एक बार सेटअप होने पर, यह वास्तविक चीज है: एक मानक के8स क्लस्टर जिसमें कोई छिपे हुए एब्स्ट्रैक्शन्स नहीं हैं।

  • पर्सिस्टेंट वॉल्यूम सपोर्ट: डिफ़ॉल्ट में नहीं (मैन्युअल रूप से जोड़ना होगा)। एक क्यूबेडम-इंस्टॉल्ड क्लस्टर मूल रूप से एक खाली के8स है - यह डिफ़ॉल्ट स्टोरेजक्लास या डायनामिक प्रोविज़नर को आउट-ऑफ-द-बॉक्स शामिल नहीं करता है। क्लाउड एन्वायरनमेंट्स में, क्लाउड प्रोवाइडर आमतौर पर एक डिफ़ॉल्ट स्टोरेजक्लास प्रदान करता है (उदाहरण के लिए, AWS EBS, आदि), लेकिन एक होमलैब बेयर-मेटल एन्वायरनमेंट में, हमें अपने समाधान इंस्टॉल करने होंगे। सामान्य दृष्टिकोण:

    • होस्टपाथ प्रोविज़नर: हम K3s/Minikube के समान व्यवहार करने के लिए कुछ जैसे Rancher Local Path Provisioner इंस्टॉल कर सकते हैं (जो एक छोटा कंट्रोलर + स्टोरेजक्लास है जो होस्टपाथ PVs बनाता है)। यह एक सरल एड-ऑन है (सिर्फ एक YAML मैनिफेस्ट) और हमें लोकल डायनामिक स्टोरेज देता है।
    • NFS या NAS: कुछ होमलैब उपयोगकर्ता एक NFS सर्वर सेटअप करते हैं (या एक NAS का उपयोग करते हैं) और फिर स्टैटिक PVs या एक NFS CSI ड्राइवर का उपयोग प्रोविज़निंग के लिए करते हैं।
    • OpenEBS/Longhorn/Ceph: अधिक जटिल विकल्प जैसे Longhorn या Ceph RBD को Rook के माध्यम से डिप्लॉय करना है अगर हम नोड्स के बीच वितरित स्टोरेज चाहते हैं। इनके लिए अधिक रिसोर्स और जटिलता की आवश्यकता होती है।

    मुख्य बात यह है कि क्यूबेडम स्टोरेज के लिए “हल” नहीं देता - हमें इसे निर्णय लेना और कॉन्फ़िगर करना होगा। अगर आसानी प्राथमिकता है, तो सबसे सरल रास्ता एक होस्टपाथ प्रोविज़नर डिप्लॉय करना या NFS का उपयोग करना है। उदाहरण के लिए, Rancher का लोकल-पाथ प्रोविज़नर कुछ kubectl apply कमांड्स में इंस्टॉल किया जा सकता है और K3s के व्यवहार का अनुकरण करेगा (वॉल्यूम्स को /var/lib/rancher/ पर बनाएगा जिस भी नोड पर)। लेकिन यह एक मैन्युअल चरण है। जब तक हम ऐसा नहीं करते, तो हम जो भी PVC बनाते हैं वह Pending स्थिति में रहेगा क्योंकि के8स में डिफ़ॉल्ट प्रोविज़निंग का कोई प्रबंधन नहीं है। इसलिए, जबकि क्यूबेडम निश्चित रूप से पर्सिस्टेंट वॉल्यूम्स का सपोर्ट करता है (यह पूर्ण के8स है), डायनामिक PV का सपोर्ट उतना ही अच्छा है जितना कि हम इसे सेटअप करने में लगाए गए प्रयास।

  • लोडबैलेंसर सपोर्ट: डिफ़ॉल्ट में नहीं (मैन्युअल रूप से जोड़ना होगा)। यहां भी समान कहानी है: एक पारंपरिक ऑन-प्रेम क्लस्टर में, एक बिल्ट-इन लोडबैलेंसर इम्प्लीमेंटेशन नहीं होता है। अगर हम एक प्लेन क्यूबेडम क्लस्टर पर एक सर्विस के प्रकार लोडबैलेंसर बनाते हैं, तो यह pending स्थिति में रह जाएगा जब तक कि हम एक कंट्रोलर को डिप्लॉय नहीं करते जो इसे हैंडल करे। सामान्य समाधान MetalLB को स्वयं इंस्टॉल करना है। MetalLB को मैनिफेस्ट या Helm चार्ट के माध्यम से इंस्टॉल किया जा सकता है - हम एक IP रेंज कॉन्फ़िगर करेंगे और यह लोडबैलेंसर सर्विसों के लिए IPs आवंटित करेगा (जैसे MicroK8s में)। क्यूबेडम क्लस्टर पर MetalLB इंस्टॉल करने के लिए कई गाइड्स मौजूद हैं। एक विकल्प जो कुछ लोग उपयोग करते हैं वह kube-vip है कंट्रोल-प्लेन VIP और सर्विस LBs के लिए, लेकिन MetalLB सर्विसों के लिए सरल है। वास्तव में, क्यूबेडम के साथ हमारी आवश्यकताओं के अनुसार कोई भी लोड-बैलेंसिंग मेकेनिज्म सेटअप करने की स्वतंत्रता (या बोझ) है। अगर हम कोई सेटअप नहीं करते, तो हम बाहरी एक्सेस के लिए नोडपोर्ट सर्विसों तक सीमित रहेंगे। एक होमलैब के लिए, MetalLB इंस्टॉल करना अत्यधिक सिफारिश किया जाता है - यह सीधा है और हमें क्लाउड-जैसे सर्विस IP कार्यक्षमता देता है। लेकिन फिर भी, यह एक अतिरिक्त चरण है जिसे हमें करना होगा (जैसे K3s जो आउट-ऑफ-बॉक्स काम करता है या MicroK8s के साथ एक सरल इनेबल)।

  • रिसोर्स रिक्वायरमेंट्स: मानक के8स थोड़ा हल्का नहीं होता है जैसे कि ट्रिम्ड डाउन संस्करण। हर नोड पर एक kubelet और kube-proxy चलेंगे, और मास्टर पर etcd और कंट्रोल-प्लेन घटक चलेंगे। एक सिंगल कंट्रोल-प्लेन नोड अभी भी 2 GB RAM में चल सकता है, लेकिन आमतौर पर हम इसे कुछ अधिक आरामदायक रखना चाहेंगे अगर उस पर पॉड्स चल रहे हैं। पदोक गाइड 2 GB मास्टर और 2 GB वर्कर के लिए न्यूनतम सिफारिश करता है। हमारे सिनारियो (16 GB प्रति नोड) में, यह ठीक है। आइडल etcd और API सर्वर कुछ सौ MB मेमोरी का उपयोग कर सकते हैं। रनटाइम में एक क्यूबेडम क्लस्टर और MicroK8s के बीच कोई बड़ा अंतर नहीं है - आखिरकार, MicroK8s उसी घटकों का उपयोग करता है। अंतर सिर्फ यह है कि डिफ़ॉल्ट रूप से क्या चल रहा है (MicroK8s DNS और स्टोरेज को डिफ़ॉल्ट रूप से इनेबल कर सकता है, जबकि क्यूबेडम पर हम उन्हें इंस्टॉल करेंगे)। इसलिए रिसोर्स के मामले में, क्यूबेडम उतना ही हल्का या भारी हो सकता है जितना हम इसे कॉन्फ़िगर करते हैं। कुछ अतिरिक्त इंस्टॉल किए बिना, यह काफी हल्का हो सकता है। एक सामान्य सेटअप (उदाहरण के लिए, हम CoreDNS, Dashboard, आदि जोड़ते हैं) के साथ, \ 1 GB या उससे अधिक सिस्टम ओवरहेड्स का उपयोग होने की उम्मीद करें। हमारे पास पर्याप्त RAM है, इसलिए रिसोर्स एक चिंता नहीं हैं। यह अधिक मानव समय/रिसोर्सों की आवश्यकता है जो इसे मैनेज करने के लिए है बजाय CPU/RAM।

  • सिंगल-नोड बनाम मल्टी-नोड: क्यूबेडम दोनों कर सकता है, पूर्ण लचीलापन के साथ। हम एक सिंगल-नोड क्लस्टर इनीशियलाइज़ कर सकते हैं (और क्यूबेडम को एकल नोड को वर्कलोड्स चलाने की अनुमति देने के लिए मास्टर को अनटेन्ट करने के लिए भी कह सकते हैं)। या हम एक मास्टर और दो वर्कर्स (एक आम 3-नोड सेटअप) रख सकते हैं। हम 3 मास्टर और 3 वर्कर्स, आदि सेटअप भी कर सकते हैं - कोई भी टोपोलॉजी। हमारे मामले में, एक संभावित क्यूबेडम सेटअप 1 कंट्रोल-प्लेन नोड और 2 वर्कर्स होगा (क्योंकि HA की आवश्यकता नहीं है, हमें कई मास्टर की आवश्यकता नहीं है)। यह हमें एक कार्यात्मक 3-नोड क्लस्टर देता है। मल्टी-नोड के लिए प्रक्रिया अच्छी तरह से दस्तावेज़ीकृत है: मूल रूप से, सभी पर के8स इंस्टॉल करें, एक इनीशियलाइज़ करें, अन्य जोड़ें। परिणाम वही है जो एक मैनेज्ड क्लस्टर या अन्य डिस्ट्रो देगा: हमारे 3 नोड्स kubectl get nodes में दिखाई देंगे, आदि। इसलिए क्यूबेडम निश्चित रूप से “तीन नोड्स का उपयोग करने” की आवश्यकता को पूरा करता है।

  • CLI & UI टूल्स: क्यूबेडम के साथ, केवल विशेष CLI kubeadm ही है, जिसे सेटअप और (बाद में) अपग्रेड चरणों के लिए उपयोग किया जाता है। दैनिक उपयोग के लिए, kubectl का उपयोग क्लस्टर को मैनेज करने के लिए करें। डिफ़ॉल्ट में कुछ भी शामिल नहीं है - हम मैन्युअल रूप से के8स डैशबोर्ड या किसी अन्य टूल को डिप्लॉय कर सकते हैं (जैसे कि किसी भी क्लस्टर में)। वास्तव में, क्यूबेडम हमें एक खाली के8स कैनवास देता है। यह हम पर निर्भर करता है कि उस पर क्या पेंट करते हैं - जिसमें डैशबोर्ड, इंग्रेस कंट्रोलर्स, स्टोरेजक्लास, आदि जैसे सुविधाओं का इंस्टॉल करना शामिल है। कई थर्ड-पार्टी डैशबोर्ड्स (Lens, Octant, आदि) एक क्यूबेडम क्लस्टर से कनेक्ट कर सकते हैं अगर हम एक GUI मैनेजमेंट अनुभव चाहते हैं, लेकिन वे बाहरी टूल्स हैं। सारांश में, क्यूबेडम के साथ हम एक शुद्ध के8स एन्वायरनमेंट प्राप्त करते हैं - अधिकतम लचीलापन, लेकिन साथ ही साथ यह आवश्यकता भी है कि हम सब कुछ सेटअप करें जैसे कि यह एक प्रोडक्शन क्लस्टर हो।

  • क्यूबेस्प्रे देखें भी कि कैसे क्यूबेस्प्रे के साथ क्यूबेडम इंस्टॉल करें।

सिफारिशें

दिए गए प्राथमिकताओं (सेटअप/मेनटेनेंस की आसानी, और स्टोरेज और लोड बैलेंसर के लिए बिल्ट-इन सपोर्ट) और सीनारियो (3 यूबंटू नोड्स, एचए के बारे में चिंता नहीं) के आधार पर:

  • टॉप चॉइस: K3s या MicroK8s 3-नोड होमलैब के लिए सबसे उपयुक्त हैं:

    • दोनों बहुत आसान स्थापना (हर नोड पर एक सिंगल कमांड) होते हैं और न्यूनतम ऑनगोइंग मेनटेनेंस की आवश्यकता होती है। वे क्लस्टर चलाने की जटिलता को अधिकांश रूप से छिपा देते हैं।
    • दोनों मल्टी-नोड क्लस्टरिंग को आउट-ऑफ-द-बॉक्स सपोर्ट करते हैं (हम अपने 3 नोड्स को जोड़ सकते हैं और एक एकीकृत क्लस्टर देख सकते हैं)।
    • दोनों पर्सिस्टेंट वॉल्यूम्स और लोडबैलेंसर के लिए समाधान प्रदान करते हैं बिना बहुत प्रयास के: K3s में उन्हें डिफ़ॉल्ट रूप से शामिल किया गया है (लोकल पाथ स्टोरेज, क्लिपर LB) और MicroK8s उन्हें सरल enable कमांड्स के माध्यम से उपलब्ध कराता है। इसका मतलब है कि हम न्यूनतम मैनुअल सेटअप के साथ टाइपिकल एप्लिकेशन्स (PVCs के साथ डेटाबेस, type=LoadBalancer के साथ सर्विसेस) डिप्लॉय कर सकते हैं।
    • K3s अगर हम सबसे छोटे फुटप्रिंट चाहते हैं और इसके बिल्ट-इन डिफ़ॉल्ट्स (ट्रैफिक इंग्रेस, आदि) का उपयोग करने में कोई समस्या नहीं है तो आकर्षक हो सकता है। यह एक “सेटअप और यह बस काम करता है” दृष्टिकोण है जिसमें ओपिनियनेटेड डिफ़ॉल्ट्स होते हैं। यह होमलैब समुदाय में अपनी सरलता के लिए बहुत लोकप्रिय भी है। हम मुख्य रूप से स्टैंडर्ड kubectl का उपयोग करेंगे, और अगर आवश्यक हो तो पैकेज्ड घटकों को समायोजित या निष्क्रिय कर सकते हैं। K3s पसंदीदा हो सकता है अगर हम यूबंटू पर नहीं हैं या अगर हम रैंचर के इकोसिस्टम को पसंद करते हैं (या बाद में रैंचर के मैनेजमेंट UI का उपयोग करने की योजना बनाई है)।
    • MicroK8s अगर हम एक यूबंटू-सपोर्टेड समाधान पसंद करते हैं और फीचर्स को एक-kommend से सक्रिय करने के विचार को पसंद करते हैं तो आकर्षक हो सकता है। यह मूल रूप से वैनिला कubernates है, जिसे कुछ लोग आसान विस्तार करने के लिए पसंद करते हैं। एड-ऑन्स (जैसे microk8s enable ingress dns storage metallb) हमें कुछ मिनटों में एक पूर्ण रूप से कार्यात्मक “माइक्रो क्लाउड” दे सकते हैं। MicroK8s अपडेट्स को भी स्नैप्स के माध्यम से सुचारू रूप से हैंडल करता है, जो हमारे क्लस्टर को अपडेट रखने के लिए अच्छा हो सकता है बिना मैनुअल हस्तक्षेप के (हम इसे बंद कर सकते हैं या चैनल को नियंत्रित कर सकते हैं अप्रत्याशितताओं से बचने के लिए)। अगर हम सभी नोड्स पर यूबंटू चलाने के लिए (जो हम कर रहे हैं) और स्नैप्स का उपयोग करने में कोई समस्या नहीं है, तो MicroK8s एक कम मेनटेनेंस क्लस्टर के लिए एक उत्कृष्ट विकल्प है।

    संक्षेप में: इस सीनारियो के लिए K3s या MicroK8s से गलत नहीं होगा। दोनों हमें आसान, होमलैब-मित्र Kubernetes प्रदान करेंगे जिसमें हमें आवश्यक फीचर्स होंगे। कई उपयोगकर्ता दोनों के साथ 2-3 नोड होम सेटअप में सकारात्मक अनुभव रिपोर्ट करते हैं। MicroK8s को एड-ऑन्स और इंटीग्रेशन के कारण आसान उपयोग में थोड़ा फायदा हो सकता है, जबकि K3s को लीन चलाने और अंडर द हूड सरल होने में थोड़ा फायदा हो सकता है।

  • Minikube चुनने का समय: अगर हम केवल एक मशीन पर चल रहे होते या एक थ्रोअवे डेव क्लस्टर चाहते होते, तो Minikube टेस्टिंग के लिए एक लैपटॉप या एक नोड पर Kubernetes सेटअप करने का सबसे आसान तरीका होता। हालांकि, एक स्थायी 3-नोड क्लस्टर के लिए, Minikube सही उपकरण नहीं है - यह उन 3 नोड्स को एक क्लस्टर में मिला नहीं देगा। हम अपने हार्डवेयर का उपयोग कम करेंगे या 3 अलग-अलग क्लस्टर मैनेज करेंगे, जो इच्छित नहीं है। इसलिए, इस होमलैब में कई नोड्स के साथ, Minikube को मुख्य समाधान के रूप में अनुशंसित नहीं किया जाता है। हम अभी भी अपने व्यक्तिगत कंप्यूटर पर होमलैब क्लस्टर में डिप्लॉय करने से पहले चीजों को ट्राई करने के लिए Minikube का उपयोग कर सकते हैं, लेकिन क्लस्टर के लिए, K3s/MicroK8s जैसे कुछ का उपयोग करें।

  • Kubeadm चुनने का समय: अगर हमारा लक्ष्य Kubernetes इंटरनल्स सीखना होता या पूर्ण नियंत्रण और “प्रोडक्शन-लाइक” सेटअप होता, तो kubeadm एक अच्छा अभ्यास होता। यह हमें CNI, स्टोरेज, आदि को कैसे इंस्टॉल करना है, यह समझने के लिए मजबूर करेगा, और हम क्लस्टर को टुकड़ा-टुकड़ा बनाएंगे। हालांकि, उपयोग की आसानी के मामले में, kubeadm सबसे हैंड्स-ऑन होता है। हर फीचर की आवश्यकता (जैसे स्टोरेज या LB) को हम कोन्फ़िगर करना पड़ता है। एक सीखने-उन्मुख होमलैब के लिए, यह एक प्रो (शैक्षिक) हो सकता है; एक बस इसे चलाने होमलैब के लिए, यह एक कॉन हो सकता है। इसके अलावा, मेनटेनेंस अधिक शामिल होगा (विशेष रूप से अपडेट्स के दौरान)। जब तक कि हम विशेष रूप से सीखने या विशिष्ट कस्टम आवश्यकताओं के लिए वैनिला Kubernetes अनुभव चाहते हैं, K3s या MicroK8s का उपयोग करने से हमारी होमलैब वातावरण में बहुत समय और सिरदर्द बचेंगे। इसके बावजूद, कुछ अनुभवी उपयोगकर्ता घर पर भी kubeadm पसंद करते हैं ताकि वे किसी भी वेन्डर-स्पेसिफिक क्विर्क्स से बच सकें और सब कुछ अपने नियंत्रण में रख सकें। यह वास्तव में इस बात पर निर्भर करता है कि हम कितना प्रयास करना चाहते हैं। अधिकांश के लिए, kubeadm एक छोटे क्लस्टर के लिए ओवरकिल है जहां हाई एवेलिएबिलिटी की चिंता नहीं है।

  • अन्य विकल्प: कुछ अन्य लाइटवेट Kubernetes फ्लेवर भी हैं, जैसे k0s (Mirantis द्वारा) और उपकरण जैसे kind (Kubernetes in Docker)। पूर्णता के लिए:

    • k0s एक और सिंगल-बाइनरी Kubernetes डिस्ट्रो है, जिसका उद्देश्य K3s/MicroK8s के समान है, जो लचीलापन और न्यूनतम फुटप्रिंट पर केंद्रित है। यह अपेक्षाकृत नया है लेकिन होमलैब समुदाय में प्रशंसकों का है। यह हमारे 3 नोड्स पर आसानी से चल सकता है। यह (वर्तमान में) K3s/MicroK8s के समान बड़े उपयोगकर्ता बेस नहीं रखता है, लेकिन यह एक विकल्प है जिसे देखना चाहिए (विशेष रूप से अगर आप एक ओपन-सोर्स, कॉन्फ़िगरेबल, मिनिमल Kubernetes के विचार को पसंद करते हैं - कुछ रिपोर्ट्स तो k0s को K3s/MicroK8s के समान सेटअप में थोड़ा कम आइडल रिसोर्सेस का उपयोग करने का भी दिखाते हैं)।
    • kind मुख्य रूप से Docker कंटेनर्स में Kubernetes क्लस्टर टेस्टिंग के लिए है (अक्सर CI पाइपलाइन्स के लिए उपयोग किया जाता है)। यह कुछ ऐसा है जिसे हम हमेशा चलने वाले होमलैब क्लस्टर के रूप में चलाएंगे - यह एक मशीन पर त्वरित, क्षणिक क्लस्टर के लिए है (Minikube के उद्देश्य के समान)।
    • Rancher Kubernetes Engine (RKE) या K3d या अन्य भी उपलब्ध हैं, लेकिन वे या तो कंटेनराइज्ड क्लस्टर (k3d एक K3s क्लस्टर को Docker में चलाता है) के लिए बनाए गए हैं या अधिक जटिल डिप्लॉयमेंट सीनारियो के लिए। एक होमलैब में, K3s और MicroK8s आसान समाधान के रूप में डिफ़ैक्टो हो गए हैं।

निष्कर्ष: 3 अच्छे नोड्स वाले होमलैब के लिए, MicroK8s या K3s को कार्यात्मक Kubernetes क्लस्टर प्राप्त करने के लिए न्यूनतम परेशानी के साथ अनुशंसित विकल्प माने जाते हैं। वे हमें एक क्लस्टर में सभी नोड्स का लाभ उठाने देंगे, और पर्सिस्टेंट वॉल्यूम्स और लोडबैलेंसर सर्विसेस के लिए बिल्ट-इन सपोर्ट प्रदान करेंगे, जो हमने मांगा था। अगर हम एक अधिक प्लग-एंड-प्ले, यूबंटू-इंटीग्रेटेड समाधान पसंद करते हैं, तो MicroK8s के साथ जाएं। अगर हम एक सुपर लाइटवेट, Rancher द्वारा समर्थित समाधान पसंद करते हैं, तो K3s के साथ जाएं। दोनों ही तरीकों से हम कुछ मिनटों में एक कार्यात्मक क्लस्टर प्राप्त कर लेंगे। एक बार सेटअप होने के बाद, हम Kubernetes Dashboard या अन्य उपकरणों को डिप्लॉय कर सकते हैं ताकि इसे मैनेज किया जा सके, और पर्सिस्टेंट स्टोरेज और आसान सर्विस एक्सपोजर के साथ अपने एप्लिकेशन्स होस्टिंग शुरू कर सकते हैं। अपने होमलैब Kubernetes यात्रा का आनंद लें!

Kubernetes डिस्ट्रीब्यूशन्स होमपेज्स

अन्य उपयोगी लिंक्स