नौकरी इंटरव्यू ने मुझे Kubernetes के बारे में क्या सिखाया

 (notnotp.com)
19 पॉइंट द्वारा GN⁺ 2 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Kubernetes को छोटी कंपनियाँ भी तकनीकी scalability से ज़्यादा deployment के तरीकों में एकरूपता और संगठनात्मक संचालन की समस्याओं को हल करने के मानक के रूप में अपना रही हैं
  • हाल की नौकरी खोज प्रक्रिया में जिन कंपनियों से बात हुई, वे सभी Kubernetes का उपयोग कर रही थीं, और यह 5 साल पहले वाले VM·serverless·K8s सह-अस्तित्व वाले परिदृश्य से अलग था
  • CTOs ने जिन मुख्य कारणों का ज़िक्र किया, वे थे: हर service को एक ही तरीके से deploy करना, YAML और Helm charts में operational knowledge छोड़ना, और GitOps के ज़रिए changes का history track करना
  • छोटी कंपनियाँ HPA, Pod Disruption Budget, node affinity जैसी advanced features से ज़्यादा संगठनात्मक फ़ायदों के कारण Kubernetes जैसी जटिलता स्वीकार कर रही हैं
  • शुरुआती चरण की कंपनियों के लिए product पर फ़ोकस करने हेतु Kubernetes के बिना शुरू करना बेहतर हो सकता है, और जब CTO अकेले engineering नहीं संभालते, उस समय से इसे अपनाने की ज़रूरत बढ़ने लगती है

हाल की नौकरी खोज में दिखा बदलाव

  • हाल की नौकरी खोज में job postings पढ़ने, इंटरव्यू देने और लगभग बारह engineering teams से बात करने पर यह सामने आया कि जिन सभी कंपनियों से बात हुई, वे Kubernetes का उपयोग कर रही थीं
  • 5 साल पहले नौकरी खोजते समय, कुछ समूह Kubernetes का कम उपयोग करते थे, कुछ VM/VPS/EC2 पर systemd का इस्तेमाल करते थे, और कुछ Lambda तथा Cloud Run जैसे serverless विकल्पों पर थे
  • जहाँ मैं अभी काम करता हूँ वहाँ Big Tech स्तर की समस्याएँ हैं, इसलिए Kubernetes स्पष्ट रूप से उपयुक्त है, लेकिन सिर्फ़ दो services वाले 10-लोगों के startup तक इसका उपयोग कर रहे थे, यह चौंकाने वाला था
  • जिन कंपनियों से बात हुई वे न तो microservices चला रही थीं और न ही high-scale के करीब के वातावरण में थीं, और Kubernetes के तकनीकी पक्ष में उनकी बड़ी दिलचस्पी भी नहीं थी

Kubernetes अपनाने के कारण और निर्णय के मानदंड

  • Kubernetes क्यों इस्तेमाल किया जा रहा है

    • पहला कारण uniformity था; जब सभी services एक ही तरीके से deploy होती हैं, तो ऐसी स्थिति नहीं बनती कि कोई एक service अब भी पुराने bare VM के bash scripts या Docker Compose में फँसी रह जाए
    • दूसरा कारण साझा किया जा सकने वाला और hiring के लिए उपयोगी knowledge था; Kubernetes एक common language की तरह इस्तेमाल होने से सिर्फ़ Helm charts और Kube configs देखकर architecture जल्दी समझा जा सकता है
    • जब knowledge लोगों के दिमाग़ में रहने के बजाय YAML में रहता है, तो किसी के जाने के बाद उसके उत्तराधिकारी को execution का तरीका समझने में कई हफ़्ते बर्बाद नहीं करने पड़ते
    • मेरी मौजूदा कंपनी में on-call SRE किसी अनजान service को भी संभाल सकता है, क्योंकि Kubernetes patterns अलग-अलग teams में एक जैसे हैं
    • यह फ़ायदा तभी मिलता है जब configuration ज़रूरत से ज़्यादा विचित्र न हो
    • तीसरा कारण traceability था; cluster पर सीधे kubectl apply -f चलाने के बजाय Helm charts को git में डालकर, फिर MR approval और FluxCD या ArgoCD deployment से गुज़रने पर change history बची रहती है
    • ऐसा flow GitOps और Kubernetes के स्वाभाविक मेल के कारण लगभग बिना अतिरिक्त लागत के compliance में मदद करता है
    • मेरी मौजूदा कंपनी इसी तरीके से ISO certification आसानी से पास कर रही है

  • निकला हुआ निष्कर्ष

    • CTOs की यह पसंद कोई मूर्खतापूर्ण निर्णय नहीं थी, बल्कि वास्तविक समस्याओं को हल करने का तरीका थी
    • Kubernetes देखने में तकनीकी समस्याओं का तकनीकी समाधान लगता है, लेकिन कई CTOs अपेक्षा से अधिक गैर-तकनीकी फ़ायदों में रुचि रखते थे
    • छोटी कंपनियों की तकनीकी समस्याएँ इतनी बड़ी नहीं होतीं कि Kubernetes अनिवार्य हो; और संभव है कि उनके manifests में topologySpreadConstraints, HPA, Pod Disruption Budget, या node affinity rules न हों
    • वे VM इस्तेमाल करने के समय जितने ही nodes बनाए रखते हुए भी, संगठनात्मक लाभों के लिए complex software चलाने की लागत स्वीकार कर रही हैं

  • हाल में यह बदलाव क्यों आया

    • 5 साल पहले VM और systemd, serverless और Kubernetes सभी विकल्प मौजूद थे, लेकिन अब job postings में VM और systemd का संयोजन लगभग गायब हो चुका है, serverless niche में रह गया है, और Kubernetes जीत गया है
    • यह बदलाव ठीक कब और क्यों हुआ, इसका कारण पूरी तरह स्पष्ट नहीं है
    • एक संभावित कारण यह है कि EKS, GKE, AKS जैसे managed Kubernetes प्लेटफ़ॉर्म mature हो गए, और Kubernetes सीख चुके लोगों की संख्या इतनी बढ़ गई कि किसी दूसरे तरीके के लिए hiring करना उल्टा अधिक कठिन हो गया
    • Helm ने दूसरों द्वारा बनाए गए charts को ज्यों-का-त्यों इस्तेमाल करने के विकल्प को व्यावहारिक बना दिया

  • Kubernetes कब इस्तेमाल करना चाहिए

    • मेरा निजी मानदंड वह क्षण है जब CTO अब अकेला engineer नहीं रह जाता
    • जैसे ही दूसरा engineer जुड़ता है, deployment ऐसे व्यक्ति को भी करना होता है जिसने server खुद सेट up नहीं किया हो, और हर चीज़ के लिए SSH keys बाँटने के बजाय उचित access control की ज़रूरत पड़ती है
    • अंततः कोई न कोई कंपनी छोड़ता है, और उसके साथ लोगों के पास मौजूद operational knowledge भी जा सकती है
    • इस बिंदु से knowledge को लोगों की बजाय system के भीतर रहना चाहिए
    • उससे पहले के चरण में cluster debugging वास्तव में कठिन हो सकती है, और product पर लगने वाली ऊर्जा infrastructure में खर्च हो सकती है
    • किसी बड़े ग्राहक के साथ call से ठीक पहले CrashLoopBackOff में फँसे pod का कारण दो घंटे तक खोजने की तुलना में, VPS पर जल्दी से git pull करके ठीक करना तेज़ और समझ में आने वाला emergency response हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2 일 전
Lobste.rs की राय

  • यूरोप की तरफ़ वजह काफ़ी स्पष्ट है। CTO यह मानते हैं कि K8s पर ले जाने से managed K8s provider को कुछ ही हफ़्तों में बदला जा सकता है
    इसका मतलब यह नहीं कि यह सच है, लेकिन वे वास्तव में ऐसा मानते हैं। उन्हें यह भी लगता है कि PR environment ज़्यादा आसान हो जाता है
    लेकिन असली बात provider switch की है। उनका अनुमान है कि आने वाले कुछ वर्षों में अमेरिका से जुड़े provider के इस्तेमाल पर पाबंदी लग सकती है, खासकर GDPR, financial systems वगैरह में। इसलिए वे उस जोखिम के लिए पहले से तैयारी कर रहे हैं

  • यह इस बात का सबूत लगता है कि कंपनी के आकार से परे tech industry ने पूरी तरह दिशा खो दी है। stack लगातार ज़्यादा एकरूप और जटिल होता गया है, और नतीजतन ऐसे products और services ढूँढना और मुश्किल हो गया है जिन्हें दाँत भींचे बिना इस्तेमाल किया जा सके

    • low-level layers इतने buggy और complex हैं कि बचने के लिए आखिरकार Kubernetes जैसी चीज़ बनानी ही पड़ती है। अगर आप stack को और ऊँचा होने से रोकना चाहते हैं, तो नीचे की layers को बेहतर बनाना होगा
      हमें कहीं बेहतर operating system primitives चाहिए। उदाहरण के लिए, containers kernel की कई isolation features का बिना किसी सुसंगत design के मिला-जुला रूप थे, इसलिए उनमें बहुत छेद थे
      अब container isolation काफ़ी बेहतर हो गया है, लेकिन शुरुआत से security और correctness को design नहीं किया गया था; बाद में बस whack-a-mole की तरह fixes किए गए। जब तक kernel इस विशाल technical debt को साफ़ नहीं करता, या कोई ऐसा kernel नहीं बनाता जिसे लोग अपनाना चाहें, तब तक हम उसके ऊपर चीज़ें जोड़ते ही रहेंगे

  • पर्याप्त रूप से जटिल deployment tool अंततः एक अस्थायी, अनौपचारिक रूप से परिभाषित, buggy और slow Kubernetes का आधा-अधूरा implementation समेट ही लेता है

    • “आधा” कहना सही है। बस बात यह है कि वही आधा ज़रूरी आधा होता है
      मैं लंबी बात कर सकता हूँ कि 2009 में एक billion-dollar SaaS e-commerce कंपनी को कैसे चलाया गया, या बहुत बड़े AAA multiplayer game का online backend कैसे काम करता था; वे single-machine deployment की तुलना में साफ़ तौर पर Kubernetes के ज़्यादा क़रीब थे
      लेकिन वे तेज़ थे, और organization को ठीक जिस तरह की ज़रूरत थी उसी तरह opinionated थे, न कि ऐसे तरीक़े से जो product requirements से टकराए
      Kubernetes के “buggy” होने की बात अक्सर core system से कम, और उन तमाम interface layers से ज़्यादा आती है जिन्हें हम उसके ऊपर अपनी मनचाही तरह चलाने के लिए चढ़ाते हैं
    • यह बात Kubernetes नहीं बल्कि Erlang पर लागू होती है। Kubernetes के लिए यह बिल्कुल भी सही नहीं बैठती

  • समस्या यह है कि ज़्यादातर organizations K8s को आधे-अधूरे ढंग से अपनाती हैं, उसके लिए DevOps team भी रखती हैं, लेकिन अंत में K8s से जुड़ा लिखना, deploy करना, debug करना और operate करना सब software engineers पर ही डाल देती हैं
    एक अच्छी DevOps team को अंदरूनी तौर पर Heroku जैसा अनुभव देना चाहिए। ज़रूरी resources define करो, main में merge करो, और deployment हो जाना चाहिए; यह नहीं कि किसी ख़राब GitOps/DevOps dashboard में क्या गड़बड़ है, यही खोजते रहो
    मेरे हिसाब से developer experience का शिखर Heroku था, और K8s के बाद हमने वह खो दिया

    • node पर Pod चलते देख पाने के अलावा, मुझे समझ नहीं आता कि Heroku और Kubernetes के इस्तेमाल के अनुभव में इतना बड़ा फ़र्क़ क्या है
      हाँ, Heroku database integration या git push deployment जैसी चीज़ों में ज़्यादा integrated experience देता है, लेकिन Kubernetes के ऊपर custom wrapper बनाना भी कोई ख़ास बात नहीं। आख़िरकार आप सारे parameters वैसे के वैसे pass through करने लगते हैं

  • industry में technology adoption हमेशा “रेडीमेड लोगों को भर्ती करो, ज़रूरत न हो तो निकाल दो” वाले सिद्धांत पर चलती है। यह भी उसी का एक नया उदाहरण है

  • “ज्ञान लोगों के पास नहीं, system के पास होना चाहिए” — यह वाक्य उस बात को बहुत अच्छी तरह कहता है जिसे मैं बस धुँधले तौर पर सोचता रहा था
    ऐसी formalization तभी संभव है जब process में variability कम हो। पहले इंसान खुद काम करे, फिर process को document करे, फिर उसे script में बदले, और उसके बाद automation करे
    लोकप्रिय tools या ecosystem के सामान्य workflows में यह ज़्यादातर चरण लगभग मुफ़्त में मिल जाते हैं

  • मैं बहुत ज़्यादा DevOps नहीं करता, और अभी systemd तथा कभी-कभार इस्तेमाल होने वाले podman containers से ही system ठीक चल रहा है। मैं IoT/AgTech में काम करता हूँ
    इस लेख में वैसी “assertions” हैं जैसी अक्सर non-technical executives से सुनने को मिलती हैं। लगभग इस तरह: “उधर भी LoRa है न? तो सब हो गया? कल launch कर सकते हैं?”
    यह विश्वास रहता है कि असमानता ही सफलता की एकमात्र बाधा है। अगर दो systems Fiber, Modbus इस्तेमाल करते हों या उनके पास “API हो”, तो उन्हें तुरंत जोड़कर “1 + 1 is greater than the sum of its parts” जैसा शानदार अनुभव बना लिया जाएगा
    लेकिन सिर्फ़ इसलिए कि दो software किसी निम्न-स्तरीय interoperability standard पर सहमत हैं, यह असली काम ख़त्म नहीं हो जाता कि आसानी से parse होने वाले data का अर्थ क्या है और उसे उपयोगी रूप में कैसे इस्तेमाल किया जाए
    दो लोग एक ही भाषा बोल सकते हैं, इससे काम अपने-आप ग़ायब नहीं हो जाता। किसी common language के इस्तेमाल से यह भी नहीं मिटता कि टीम के कुछ लोगों ने उस tool का इस्तेमाल करते हुए उस समय की ज्ञात परिस्थितियों में कुछ निर्णय लिए थे
    शुरुआती दौर में science/engineering दुनिया में Fortran एक common language थी, लेकिन इससे यह नहीं रुका कि लोग अपने सहकर्मियों के काम को देखकर पूरी तरह चकित हों या उसे फिर से लिखना पड़े
    मुझे K8s के value या उसके मौजूदा “standard” बन जाने से शिकायत नहीं है। लेकिन यह दावा मानना मुश्किल है कि इससे किसी ख़ास तरह की programming problems ग़ायब हो जाती हैं। ugliness conservation law अब भी लागू है

  • Kubernetes एक ठीक-ठाक deployment platform है

  • deployment form factor भी एक और वजह है। मैं Canton node का काम करता हूँ, और upstream Canton software तथा उससे जुड़े apps Helm charts के रूप में दिए जाते हैं
    Kubernetes हमारे काम के लिए सही है या नहीं, इससे अलग — और मेरा मानना है कि नहीं है — software इसी तरह deploy और support किया जाता है। अगर आप इस रास्ते से हटते हैं, तो Kubernetes सँभालने से भी ज़्यादा काम बढ़ जाता है

  • क्या सिर्फ़ मुझे ही यह लेख बहुत ज़्यादा AI द्वारा लिखा हुआ लग रहा है, पता नहीं
    फिर भी, इसकी मूल बात से मैं सहमत हूँ। मैं अपने homelab/self-hosting setups को custom systemd configs, याद न रहने वाले shell commands, और “धत्त, वह setup procedure किस Markdown file में लिखा था?” जैसी हालत से बाहर ला रहा हूँ, और यह सच में ताज़गीभरा लग रहा है
    अभी मैं कोई असली continuous deployment system नहीं इस्तेमाल कर रहा, लेकिन सिर्फ़ एक छोटी apply shell script और YAML files के सेट के साथ यह एहसास अच्छा है कि disaster होने पर भी 90% तक recovery की जा सकती है
    systemd वैचारिक रूप से सरल है, लेकिन reproducibility जटिल है; Kubernetes इसका उल्टा है। आप concept cost ज़्यादा चुकाते हैं, लेकिन reproducibility और उससे आने वाली समझ कहीं अधिक मज़बूत हो जाती है। कम-से-कम अभी मुझे ऐसा लगता है
    मैं अभी भी Kubernetes सीखने के बीच के चरण में हूँ, लेकिन हाल में इसे काफ़ी मज़े से इस्तेमाल कर रहा हूँ

    • 10 साल पहले मैं सहमत होता, लेकिन अब तरह-तरह के namespace options और dynamic user integration की वजह से systemd भी “एक और monster” जैसा लगता है
      इस तरह की vertically integrated, first-class definitions ग़लत दिशा जैसी लगती हैं
    • AI ने लिखा या नहीं, यह इतना महत्वपूर्ण नहीं है। महत्वपूर्ण यह है कि लिखा अच्छा है या नहीं