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

मूल लेख ↗ Hacker News चर्चा ↗

Kubernetes नया डिफ़ॉल्ट के रूप में

  • कई टिप्पणीकार कहते हैं कि Kubernetes ने प्रभावी रूप से VM+systemd और अधिकांश अन्य orchestrators पर “जीत” हासिल कर ली है, मुख्यतः इन कारणों से:
    • प्रमुख क्लाउड्स पर managed offerings परिपक्व और turnkey हो गए हैं।
    • इसके आसपास tools, companies, और talent का बहुत बड़ा ecosystem बन गया है।
    • यह infrastructure और GitOps के लिए एक “lingua franca” की तरह काम करता है।

छोटी टीमों और startups के लिए उपयुक्तता

  • Kubernetes कब समझ में आता है, इस पर कड़ा मतभेद है:
    • कुछ लोग इसे बहुत छोटी टीमों के लिए भी उचित मानते हैं यदि वे पहले से “cloud native” हैं, क्योंकि uniform deployments, आसान onboarding, और साझा knowledge मिलती है।
    • अन्य लोग 2–3 engineers पर k8s अपनाने को एक red flag मानते हैं: VMs या सरल container platforms की तुलना में अनावश्यक complexity।
    • कई लोगों का तर्क है कि article के non-technical benefits (operational/organizational) बहुत छोटे N पर complexity की भरपाई नहीं करते।

Complexity, upgrades, और ecosystem churn

  • कई लोग नोट करते हैं कि k8s “batteries included” नहीं है: ingress, cert management, DNS, storage, और GitOps अपने-अपने upgrade cycles और breaking changes वाले कई controllers जोड़ते हैं।
  • Upgrade cadence को इस तरह देखा जाता है:
    • एक feature के रूप में (regular security और drift control, “push-button” cluster upgrades के साथ)।
    • या एक burden के रूप में (लगातार API churn, ingress/gateway changes, addons को sync में रखना)।
  • कुछ लोग networking और DNS layers (जैसे CoreDNS scaling, overlays) को कई startups के लिए overkill मानते हैं।

विकल्प और “सरल” stacks

  • बार-बार इनका उल्लेख होता है:
    • पारंपरिक “linux + web server + database + language runtime” on VMs, जिन्हें अक्सर Ansible, shell scripts, या NixOS से manage किया जाता है।
    • हल्के orchestrators और PaaS जैसे tools (Nomad, Docker Swarm, ECS/Fargate, Cloud Run, Heroku-like systems, custom “kube-lite” projects)।
  • एक recurring pattern: टीमें k8s आज़माती हैं, फिर कुछ लोग operational load कम करने के लिए सरल, अधिक “boring” setups पर लौट जाते हैं।

LLMs और उपयोग में आसानी

  • कुछ का दावा है कि LLMs k8s और Terraform को बहुत आसान बना देते हैं: manifests, Helm charts, dashboards generate करना, और clusters debug करना।
  • अन्य लोग उन systems पर काम करने के लिए LLMs का उपयोग करने के खिलाफ़ कड़ी चेतावनी देते हैं जिन्हें आप समझते नहीं, क्योंकि errors सूक्ष्म और उच्च-प्रभाव वाले होते हैं।

Stateful workloads और managed services

  • कई लोग तर्क देते हैं कि durable state (databases, blob stores, caches) को आम तौर पर managed cloud services के माध्यम से Kubernetes के बाहर रखना बेहतर है:
    • Managed offerings को in-cluster stateful operators की तुलना में अधिक reliable और migrate करने में आसान माना जाता है।
  • अन्य लोग modern k8s-native database operators के साथ सफलता की रिपोर्ट करते हैं, लेकिन स्वीकार करते हैं कि वे significant complexity जोड़ते हैं।

Hiring, hype, और culture

  • Kubernetes को इस रूप में देखा जाता है:
    • Hiring और resume-building के लिए आकर्षक; कुछ इसे “resume++” या hype-driven कहते हैं।
    • साथ ही CTOs के लिए एक सुरक्षित, standard choice भी, जो bespoke infra से बचना चाहते हैं और widely understood patterns पर निर्भर रहना चाहते हैं।
  • कुछ लोग k8s अपनाने की आलोचना करते हैं कि यह tooling के साथ cultural/process समस्याओं को छिपाता है, बजाय fundamentals को ठीक करने के।