प्रोडक्शन में Kubernetes के हमारे वर्षों से मिले निष्कर्ष
Production में Kubernetes को लेकर प्रतिक्रियाएँ मिश्रित हैं, और कई इंजीनियर तर्क देते हैं कि इसकी जटिलता, operational pitfalls (जैसे certificate expiry से clusters का down होना), और लगातार upgrade burden छोटी टीमों या सरल apps के लिए उचित नहीं हैं, जिन्हें VMs या हल्के container platforms पर चलाया जा सकता है। दूसरे लोग deployment के लिए एक unified abstraction, on-prem और cloud के बीच portability, और rich tooling जैसे फायदे बताते हैं—बशर्ते आप managed services (EKS/AKS/GKE) इस्तेमाल करें, clusters को non-snowflake रखें, और platform team में निवेश करें। चर्चा ECS, Nomad, Ray, और Proxmox जैसे alternatives, stateful workloads और dev environments से जुड़े trade-offs, और इस व्यापक चिंता को भी छूती है कि Kubernetes को अक्सर वास्तविक जरूरत साबित होने से पहले ही perceived scalability के कारण अपना लिया जाता है.
छोटी टीमों बनाम बड़े संगठनों के लिए Kubernetes
- कई लोगों का तर्क है कि छोटी टीमों/स्टार्टअप्स के लिए Kubernetes जरूरत से ज्यादा है; जटिलता और ownership लागत गति को कुचल देती है।
- कुछ का कहना है कि यह मुख्यतः तब समझ में आता है जब आपके पास सैकड़ों इंजीनियर और एक समर्पित platform team हो।
- अन्य लोग जवाब देते हैं कि team size से ज्यादा महत्वपूर्ण problem complexity और scale है; कुछ लोग तो personal projects के लिए भी k8s का उपयोग करते हैं क्योंकि उन्हें एक standard abstraction पसंद है।
Managed बनाम self-managed clusters
- मजबूत सहमति: control planes को स्वयं manage करना जोखिम भरा है; cert expiry और upgrade issues ने multi-day outages पैदा किए हैं।
- Managed offerings (EKS/AKS/GKE) को कहीं अधिक reliable माना जाता है और ये दर्द को बहुत कम करते हैं, हालांकि outage-free नहीं हैं।
- कई commenters article के outages को k8s की inherent flaws से ज्यादा खराब operational practices (manifests/backup न होना, खराब cert management) मानते हैं।
जटिलता, abstractions, और फायदे
- आलोचक steep learning curves की सूची देते हैं: PKI/certs, etcd, CNI networking, DNS, ingress controllers, Helm, GitOps, YAML sprawl, frequent deprecations.
- समर्थक unified resource model को रेखांकित करते हैं: on-prem/cloud पर समान manifests, pluggable storage/ingress, automatic service discovery, scaling, failover, और node maintenance workflows.
- कुछ लोग k8s को dev/QA platform के रूप में उत्कृष्ट बताते हैं (consistent environments, complex topologies को आसानी से spin up करना) लेकिन production के लिए more opinionated runtimes की तुलना में “बस ठीक-ठाक” मानते हैं।
विकल्प और सरल तरीके
- सुझाए गए विकल्प: ECS, Fargate, Azure Container Apps, Nomad, Ray, Docker Compose/Swarm, Proxmox, Ubuntu MicroCloud, CI/CD के साथ plain VMs, या autoscaled servers पर monoliths.
- कई products के लिए, commenters मानते हैं कि कुछ VMs + load balancer + managed DB अधिक सस्ता, सरल, और पर्याप्त scalable होता।
Developer environments & GitOps
- कुछ टीमें local/dev clusters (kind/k3s/k3d, Tilt, kustomize) या prod से मिलते-जुलते छोटे shared clusters चलाती हैं, अक्सर S3 और अन्य services के लिए mocks के साथ।
- GitOps (Argo/Flux) पर mixed प्रतिक्रियाएँ मिलती हैं: कुछ इसे versioning और drift detection के लिए अनिवार्य मानते हैं; अन्य सोचते हैं कि यह एक और sync layer जोड़ता है और direct Helm/kubectl को पसंद करते हैं।
लागत, staffing, और TCO
- बार-बार चिंता: लेखों में infra costs, engineer time, या simpler stacks के मुकाबले opportunity cost शायद ही कभी quantify की जाती है।
- कई लोग नोट करते हैं कि managed services पर भी k8s को own करने के लिए कम-से-कम आंशिक FTEs चाहिए होते हैं।
“Learnings” बनाम “lessons”
- लंबे sub-thread में “learnings” को corporate jargon बनाम स्वीकार्य आधुनिक usage के रूप में बहस की गई; कई लोगों को यह खटकता है, कुछ इसे उपयोगी nuance मानकर बचाव करते हैं।