Kubernetes से नफ़रत करने वालों के लिए एक गाइड

Kubernetes पर एक आलोचनात्मक गाइड

• Kubernetes ने कुछ इंजीनियरों के बीच अनावश्यक रूप से जटिल और समय बर्बाद करने वाले टूल के रूप में प्रतिष्ठा हासिल की है, और छोटी टीमों में इसका उपयोग over-engineering माना जाता है।
• Jamsocket ने कई वर्षों तक production environment में Kubernetes चलाया है, और केवल ज़रूरी features का उपयोग करके बाकी को नज़रअंदाज़ करने के तरीके से इसका कुशल उपयोग ढूँढा।

Kubernetes का उपयोग क्यों करें

• Kubernetes तब सबसे परिपक्व रास्ता है जब आप एक साथ ये तीनों चीज़ें चाहते हों:
  • कई processes/servers/scheduled jobs चलाना।
  • उन्हें redundancy के साथ चलाना और load distribute करना।
  • code के ज़रिए उनकी configuration और आपसी संबंधों को परिभाषित करना।
• Kubernetes एक abstraction layer है जो computers के एक pool को एक headless computer की तरह ट्रीट करने देती है।
• Jamsocket दिन में कई बार deploy करता है, और अगर उसके product में समस्या आती है तो उसके ग्राहकों के products भी प्रभावित होते हैं, इसलिए rolling deploys उसे बार-बार deploy करने का आत्मविश्वास देते हैं।

Kubernetes का उपयोग कैसे किया जाता है

• Jamsocket एक ऐसी service है जो web app के साथ communicate कर सकने वाले dynamic processes बनाती है, AWS Lambda जैसी, लेकिन यहाँ process की lifetime एक single request/response के बजाय WebSocket connection पर निर्भर करती है।
• Kubernetes का उपयोग API server, container registry, controller, log collector, कुछ DNS services, metrics collection जैसी long-running processes चलाने के लिए किया जाता है।
• जिन चीज़ों के लिए Kubernetes का उपयोग नहीं किया जाता: temporary processes, static/marketing sites, और वे चीज़ें जो सीधे data store करती हैं।
• Google Kubernetes Engine का उपयोग करके Kubernetes management को बाहर सौंपा गया है, और ज़रूरत पड़ने पर Amazon EKS पर migrate करना अपेक्षाकृत आसान है।

Kubernetes resources जिनका सक्रिय रूप से उपयोग होता है

• Deployments: ज़्यादातर pods deployments के ज़रिए बनाए जाते हैं।
• Services: internal services के लिए ClusterIP और external services के लिए LoadBalancer का उपयोग।
• CronJobs: cleanup scripts आदि के लिए उपयोग।
• ConfigMaps और Secrets: ऊपर दिए गए resources तक data पहुँचाने के लिए उपयोग।

जिनका सावधानी से उपयोग किया जाता है

• StatefulSet और PersistentVolumeClaim का उपयोग किया जाता है, लेकिन महत्वपूर्ण data को Kubernetes के बाहर managed services में store करना पसंद किया जाता है।
• RBAC complexity बढ़ाता है, इसलिए जहाँ तक संभव हो इससे बचा जाता है।

जिनसे सक्रिय रूप से बचा जाता है

• YAML हाथ से लिखना: Kubernetes resource definitions बनाने के लिए TypeScript और Pulumi का उपयोग।
• non-standard resources और operators: ये third-party software को Kubernetes infrastructure का उपयोग करने देते हैं, लेकिन व्यवहार में इन्हें इस्तेमाल करना कठिन होता है।
• Helm: operators और YAML conventions की वजह से उपयोग नहीं किया जाता।
• जिन भी चीज़ों के नाम में "mesh" शामिल हो: इन्हें ज़रूरी नहीं माना गया।
• Ingress resources: अनावश्यक indirectness जोड़ने से बचा जाता है।
• पूरी k8s stack को local में replicate करना: Docker Compose या अपने scripts से केवल सिस्टम के ज़रूरी हिस्से शुरू किए जाते हैं।

इंसानों को Pod का इंतज़ार नहीं करना चाहिए

• Kubernetes को container startup time से ज़्यादा robustness और modularity पर ज़ोर देकर डिज़ाइन किया गया है, इसलिए जहाँ किसी इंसान को Pod शुरू होने का इंतज़ार करना पड़े, वहाँ यह उपयुक्त नहीं है।
• Jamsocket interactive workloads के लिए process को तेज़ी से schedule और run करने हेतु Plane नाम का MIT-licensed Rust orchestrator उपयोग करता है।

उच्च-स्तरीय abstractions

• Kubernetes के कुछ alternatives बहुत अच्छे हैं, खासकर जब infrastructure को code के रूप में specify करने की ज़रूरत न हो।
• Railway, Render, Flight Control जैसी services का उपयोग करके Kubernetes के बजाय दूसरे solutions चुने जा सकते हैं।
• यदि आप Kubernetes के प्रति अपने approach को व्यवस्थित ढंग से manage करते हैं, तो कोई नहीं कह सकता कि आपने इसे बहुत जल्दी चुना।

GN⁺ की राय

• Kubernetes, खासकर बड़े systems में complexity management और automation के लिए एक शक्तिशाली टूल होने के बावजूद, उसकी complexity छोटे projects या startups के लिए बोझ बन सकती है।
• यह लेख Kubernetes का उपयोग करते समय पैदा हो सकने वाली अत्यधिक complexity से बचने के तरीके बताता है, जिससे beginners या छोटी टीमें भी Kubernetes के फ़ायदों का उपयोग कर सकें।
• Kubernetes का उपयोग करने से पहले, वास्तव में किन features की ज़रूरत है और टीम की technical capability क्या है, इसे देखते हुए management complexity और cost के मुकाबले उसके benefits का सावधानी से आकलन करना चाहिए।
• Kubernetes के बजाय सरल और आसानी से manage होने वाली services का उपयोग बेहतर हो सकता है। उदाहरण के लिए, Docker Swarm, Apache Mesos, Nomad आदि, जिनके अपने-अपने फायदे और सीमाएँ हैं।
• Kubernetes अपनाते समय existing infrastructure के साथ integration, security, management cost, और learning curve जैसी बातों पर विचार करना चाहिए।
• Kubernetes चुनने से मिलने वाले फ़ायदों में scalability, high availability, और अलग-अलग cloud environments में consistent deploy experience शामिल हैं। लेकिन इसके लिए resource management और orchestration की समझ आवश्यक है।

[GN⁺]

Hacker News टिप्पणियाँ

• पहली टिप्पणी का सार:

  • Kubernetes जैसे जटिल सिस्टम को अपनाने पर, उसकी जटिलता लगातार फैलती जाती है और अलग-अलग components एक-दूसरे को मज़बूत करते हुए अनिवार्य माने जाने लगते हैं।
  • जब cloud पहली बार आया था, तब लोग load balancer और database management की जटिलता कम होने से आकर्षित हुए थे।
  • stateless app server कोई बड़ा maintenance issue नहीं थे, लेकिन microservices का प्रचार करते-करते ऐसे problems पैदा कर दिए गए जो पहले थे ही नहीं।
  • अब यह संस्कृति जम चुकी है, इसलिए इस दावे से बस हाथ हिलाकर सहमत होना मुश्किल है कि microservices अनिवार्य हैं।

• दूसरी टिप्पणी का सार:

  • एक ऐसे व्यक्ति के रूप में जो छोटे और मध्यम व्यवसायों में Kubernetes लागू करता है, कुछ असंतुष्ट engineers थे, लेकिन ज़्यादातर ने संतुष्टि जताई।
  • Kubernetes जटिल है, लेकिन यह जटिल समस्याओं के लिए सही tool है।
  • standards होना undocumented साधारण अव्यवस्था से बेहतर है, और "kubectl explain X" को AWS documentation से कहीं बेहतर बताया गया।
  • Kubernetes जटिल ज़रूर है, लेकिन यह उसी तरह काम करता है जैसा developers ने अपनी पिछली नौकरियों में इस्तेमाल किया था, और speed महत्वपूर्ण है।

• तीसरी टिप्पणी का सार:

  • Kubernetes की आलोचना करना अभी चलन में है, लेकिन यह अब भी सबसे अच्छा solution है।
  • यह infrastructure को declarative तरीके से define करता है, और load balancing, self-healing तथा scaling देता है।
  • यह पूरे stack के लिए बेहतरीन observability देता है, और बहुत-सा pre-packaged software इस्तेमाल किया जा सकता है।
  • cloud, अपने server, और local environment में लगभग एक जैसा infrastructure बनाया जा सकता है, इसलिए किसी एक cloud provider पर निर्भरता नहीं बनती।

• चौथी टिप्पणी का सार:

  • Kubernetes का बड़ा फ़ायदा Helm और Operators हैं।
  • अगर आप complexity की कीमत चुका रहे हैं, तो infrastructure components के 'app store' जैसा लाभ और operations को programmatically manage करने की सुविधा भी मिलनी चाहिए।
  • उदाहरण के लिए, Ceph जैसी जटिल चीज़ को सेटअप करने के लिए Rook एक अच्छा तरीका है।
  • Helm और Operators infrastructure को managed 'turnkey' appliance तो नहीं बनाते, लेकिन declarative interface आम तौर पर manage करना आसान बनाता है।

• पाँचवीं टिप्पणी का सार:

  • Kubernetes एक अच्छी technology है, लेकिन उसकी complexity की वजह से maintainers अक्सर कंपनी के hero बन जाते हैं।
  • बहुत सारे adjustments और levers प्रोजेक्ट के असली लक्ष्य से ध्यान भटका सकते हैं।

• छठी टिप्पणी का सार:

  • मौजूदा कंपनी Kubernetes और Ansible-आधारित custom deployment system में बंटी हुई है।
  • Ansible वाला तरीका अच्छी तरह काम करता है, लेकिन Kubernetes पर जाने से deployment time घंटों से घटकर मिनटों में आ सकता है, और auto scaling भी अधिक तेज़ और कुशल हो सकती है।
  • Helm deployment failure की वजह पता लगाने में कठिनाई और काम करने के नए तरीके सीखने की ज़रूरत जैसी बातें पहले की teams से लगातार सुनने को मिलीं।

• सातवीं टिप्पणी का सार:

  • एक पूर्व Google site reliability engineer से बातचीत में कहा गया कि वास्तव में बहुत कम कंपनियों को Kubernetes की ज़रूरत होती है।
  • बहुत से लोग सिर्फ़ चलन देखकर development करते हैं।

• आठवीं टिप्पणी का सार:

  • Kubernetes सही tool हो सकता है, लेकिन इसे एक necessary evil की तरह स्वीकार करना चाहिए।
  • ऐसा software जिसमें कई पक्षों की विफलता के कारण collaboration टूट सकता हो, अक्सर समस्याएँ पैदा कर सकता है।

• नौवीं टिप्पणी का सार:

  • YAML को सीधे लिखना समस्या बन सकता है, इसलिए उसकी जगह TypeScript और Pulumi का उपयोग करके Kubernetes resource definitions तैयार की जाती हैं।
  • YAML linting करने के बजाय पूरा programming language runtime और third-party libraries लाई जाती हैं, और version maintenance, project compilation जैसी अतिरिक्त complexity भी स्वीकार की जाती है।

• दसवीं टिप्पणी का सार:

  • एक ऐसे व्यक्ति के रूप में जिसे कभी Kubernetes के लिए बहुत उत्साह था, Kubernetes का अच्छा हिस्सा उसके basic building blocks हैं—deployments, services, configmaps—और बाकी चीज़ें सिर्फ़ विशेष परिस्थितियों में इस्तेमाल की जानी चाहिए।
  • टीम settings को साफ़ और स्पष्ट रखने के लिए raw YAML लिखना और kustomize का उपयोग करना पसंद करती है।