प्रिय दोस्त, तुमने Kubernetes बना लिया है

 (macchaffee.com)
8 पॉइंट द्वारा GN⁺ 2024-11-26 | 8 टिप्पणियां | WhatsApp पर शेयर करें

  • दोस्त के नाम एक चिट्ठी

    • यह समझाने वाला लेख कि Kubernetes से बचने की कोशिश करते-करते आखिरकार वैसा ही एक सिस्टम बना लिया गया।
    • दोस्त ने साधारण container execution के लिए "boring technology" चुनना चाहा, लेकिन आखिर में जटिल scripts और configuration की वजह से समस्याएँ खड़ी हो गईं।
    • Docker Compose पर जाने से भी सारी समस्याएँ हल नहीं होतीं, और deployment, rolling updates, rollback, scaling के लिए अलग solutions की ज़रूरत पड़ती है—यह बात समझ में आती है.

  • सर्वर विस्तार और नेटवर्क की जटिलता

    • दूसरे server तक विस्तार करने की ज़रूरत महसूस होती है।
    • service discovery की कोशिश के लिए Tailscale जैसे overlay network का उपयोग किया जाता है।
    • network की जटिलता सुलझाने की कोशिश की जाती है, लेकिन अंत में और ज़्यादा समस्याओं का सामना करना पड़ता है।

  • maintenance और automation

    • सवाल उठता है कि अगर scripts बनाने वाला व्यक्ति छुट्टी पर चला जाए या नौकरी छोड़ दे, तो जटिल setup और undocumented configuration changes को कौन संभालेगा।
    • custom scripts की maintenance समस्या हल करने के लिए Ansible का उपयोग कर VM को immutable और version-controlled बनाया जाता है।
    • यह सोचा जाता है कि Kubernetes का उपयोग न करने से maintenance अधिक आसान होगी।

  • container spawning और security समस्याएँ

    • programmatically दूसरे containers बनाने की आवश्यकता सामने आती है।
    • Docker socket को web app पर mount करना security के लिहाज़ से जोखिम भरा है, इसलिए इसे हल करने के लिए अलग service लिखी जाती है।
      • Docker API के सिर्फ सुरक्षित हिस्से को expose करने वाली अलग service लिखकर समस्या हल की जाती है।

  • निष्कर्ष

    • आखिरकार यह एहसास होता है कि Kubernetes जैसा ही एक सिस्टम बना लिया गया है।
      • standard configuration format, deployment method, overlay network, service discovery, immutable nodes, API server सहित एक जटिल सिस्टम पूरा हो जाता है।

  • PS

    • यह नहीं कहा जा रहा कि Kubernetes की जगह कोई बेहतर solution हो ही नहीं सकता।
    • लेकिन Kubernetes को जटिल कहकर खारिज करने से पहले, यह समझने की सलाह दी जाती है कि वह किन समस्याओं को हल करने की कोशिश करता है।

संबंधित पढ़ाई

8 टिप्पणियां

 
savvykang 2024-11-26

डिप्लॉयमेंट handover की समस्या हल करने के लिए Kubernetes अपनाने की बात मुझे ज़्यादा समझ में नहीं आती।
 
kandk 2024-11-26

मेंटेनेंस और ऑटोमेशन code level पर आसानी से किए जा सकते हैं.
Infra as code भी संभव है.
 
savvykang 2024-11-26

EKS जैसी managed k8s service environments में load balancer भी होता है और Route 53 integration भी संभव है, लेकिन self-hosted k8s में न तो load balancer implementation होता है और न ही DNS integration बहुत लचीला होता है। जिन कंपनियों में k8s management team अलग से होती है, वहाँ आपके बताए हुए फ़ायदे सच हो सकते हैं.

सुनने में यह एक ठीक-ठाक solution लगता है, लेकिन असल में इस्तेमाल करने पर यह हर situation में काम नहीं करता।
 
kandk 2024-11-26

k8s को मैनेज करने वाली टीम न हो तब भी इसे इस्तेमाल करना आसान है। EKS इस्तेमाल कर लें।
 
savvykang 2024-11-26

क्या यह उस दावे जैसा ही नहीं है कि सिर्फ source code दे देने से ही handover पूरा हो जाता है? मुझे लगता है कि work manual और काम के execution history की अब भी ज़रूरत होगी।
 
kbumsik 2024-11-26

Infra as Code का मकसद खुद ही यही है कि सिर्फ source code देकर काम पूरा हो जाए.
हाँ, बेशक किसी भी code की तरह इसकी भी बुनियादी documentation तो होनी ही चाहिए.
 
kandk 2024-11-26

अगर source code अच्छी तरह लिखा गया हो और documentation अच्छी हो, तो यह संभव है.
काम के manual और काम के execution history अलग से हों तो मदद मिलेगी, लेकिन वह इस लेख से अलग बात लगती है.
 
GN⁺ 2024-11-26
Hacker News राय

  • कई कंपनियों में shell scripts का उपयोग करके deployment सफलतापूर्वक करने का अनुभव है

    • 2 PHP services के साथ प्रतिदिन 1 अरब से अधिक requests संभालते हुए, सर्वर पर files transfer करके और migrations चलाकर बिना downtime deployment किया गया
    • retirement accounts जैसे ऐसे उद्योगों में, जहाँ web scale की ज़रूरत नहीं होती, Jenkins के ज़रिए Docker commands से deployment किया गया
    • test environments को ज़रूरत पड़ने पर कुछ ही मिनटों में उपलब्ध कराया जा सकता था
    • मौजूदा कंपनी Kubernetes अपनाने की कोशिश कर रही है, लेकिन complexity की वजह से संघर्ष कर रही है

  • Kubernetes में YAML files संभालने के लिए दो-तीन समर्पित कर्मचारियों की ज़रूरत पड़ती है

    • cloud provider चुनने पर वह जटिल हिस्सों को संभाल सकता है, लेकिन इसकी अतिरिक्त लागत आती है
    • YAML files ऐसी configuration files हैं जिन्हें इंसानों को नहीं लिखना चाहिए, बल्कि tools को generate करना चाहिए
    • ज़्यादातर websites और services को Kubernetes की ज़रूरत नहीं होती

  • यह सोचना गलत है कि simple चीज़ें fragile होती हैं

    • YAML files और Kubernetes की complexity को समझना और debug करना उससे भी अधिक कठिन है
    • Kubernetes के विकल्प के रूप में shell scripts मौजूद हैं

  • ऐसे मामले भी होते हैं जहाँ Kubernetes की ज़रूरत नहीं होती

    • EC2 instances और simple shell scripts से 100,000 से अधिक concurrent users संभाले जा सकते हैं
    • अगर कोई समस्या नहीं है, तो बेवजह बदलने की ज़रूरत नहीं है

  • shell scripts से iptables rules और sysctl editing को आसानी से manage किया जा सकता है

    • work queue का उपयोग करके containers को programmatically बनाने के बजाय jobs को push किया जा सकता है

  • Kubernetes की आलोचना करना unprofessional नहीं है

    • अगर आप Google या Netflix जैसे बड़े पैमाने के applications नहीं चला रहे हैं, तो simple scripts लिखना बेहतर है

  • यह मान लेना गलत है कि homegrown systems की सारी limitations cost हैं, और general-purpose solutions की सारी flexibility benefits हैं

    • आप चाहते हैं कि codebase में मिलते-जुलते patterns का पालन हो और services उसी तरीके से deploy हों

  • Kubernetes की समस्या यह है कि अनगिनत open source libraries सिस्टम को समझना कठिन बना देती हैं और bugs पैदा करती हैं

  • जो लोग Kubernetes की learning curve पार कर चुके हैं, वे कहते हैं कि complexity इतनी बुरी नहीं है

    • developers को Kubernetes सिखाने वाली training में लगभग 30 मिनट लगते हैं और उससे वे Helm charts लिखने में सक्षम हो जाते हैं