- Kubernetes ने पिछले 10 वर्षों में container orchestration नवाचार का नेतृत्व किया है
- मौजूदा YAML configuration, etcd dependency, Helm package management आदि में कई सीमाएँ और सुधार की ज़रूरत देखी गई है
- HCL अपनाना, pluggable storage, नया package manager (KubePkg), IPv6 को default बनाना आदि को Kubernetes 2.0 के बदलावों के रूप में चर्चा में रखा गया है
- मौजूदा open संरचना भी महत्वपूर्ण है, लेकिन defaults और आधिकारिक दिशा-निर्देश ecosystem innovation पर निर्णायक प्रभाव डालते हैं
- यह स्पष्ट हुआ है कि Kubernetes को लगातार disruptive improvements के ज़रिए अधिक व्यापक users और organizations के लिए उपयुक्त बनना होगा
Kubernetes के 10 साल: सफलता और सीमाएँ
शुरुआत और विकास
- 2012~2013 में Google के अंदर के Linux container system Borg के बारे में अफवाहें sysadmin community में फैलनी शुरू हुईं
- 2014 में Kubernetes सार्वजनिक हुआ, और शुरुआत में इसका नाम उच्चारित करना भी कठिन था
- Microsoft, RedHat, IBM, Docker जैसी प्रमुख कंपनियाँ तेजी से जुड़ गईं और Kubernetes ecosystem standard के रूप में स्थापित होने लगा
- 2015 में v1.0 रिलीज़ और CNCF की शुरुआत के साथ एक खुले ecosystem का गंभीर निर्माण शुरू हुआ
प्रमुख innovation points
Containers का बड़े पैमाने पर प्रबंधन
- Kubernetes ने container-based software development और deployment के लिए scalability दी
- इसने साधारण development environment से लेकर हजारों servers तक एक जैसे environment की large-scale deployment संभव बनाई
- organizations को monolithic architecture से distributed microservices में बदलने का मौका मिला
कम लागत वाला maintenance और self-healing
- server management "Simpsons" (हर server का अलग nickname, manual operation) युग से "UUID" (पूरी replacement, automation, stateless) युग में तेजी से बदल गया
- machine lifespan, OS support period जैसी अवधारणाएँ लगभग गायब हो गईं, और failure होने पर "node recreation" से अपने-आप फिर से configuration हो जाती है
- Linux skills अब कई मामलों में अनिवार्य योग्यता नहीं, बल्कि "अच्छा हो तो बेहतर" जैसी चीज़ बन गई हैं
Batch jobs और Job management
- पहले "cron-only box" पर निर्भर batch processing अब queue-based automation tasks और retry mechanisms से बदली जा रही है
- job failure पर automatic restart और flexible handling के कारण operational efficiency और developer satisfaction में बड़ा सुधार हुआ
Service discovery और load balancing
- IP addresses को hardcode करने के बजाय internal DNS-based service naming अपनाया गया
- API, fixed IP, hostname के जरिए services के बीच connection सरल हुआ, और external services को भी internal की तरह संभालना संभव हुआ
Kubernetes 2.0: मुख्य सुधार प्रस्ताव
YAML से HCL तक, configuration language का बदलाव
YAML की सीमाएँ
- YAML देखने में आसान है और JSON, XML से बेहतर लग सकता है, लेकिन इसमें errors पैदा करना, type support की कमी, debugging में कठिनाई जैसी गंभीर समस्याएँ हैं
- उदाहरण) Norway problem ('NO' का false के रूप में interpret होना), indent errors, string और number का भ्रम जैसी कई failure स्थितियाँ इसमें मौजूद हैं
विकल्प: HCL अपनाना
- HCL(HashiCorp Configuration Language), Terraform का standard format है, और strong typing, validation, functions, conditional branching जैसी बेहतर सुविधाएँ देता है
- पहले से ही काफी Kubernetes clusters Terraform के साथ HCL का उपयोग कर रहे हैं
- HCL में type safety, duplication में कमी, dynamic settings, iteration, conditional logic, शानदार comment support, modularity, validation जैसी YAML से अधिक मजबूत क्षमताएँ हैं
- open source license issue (MPL 2.0 → Apache 2.0 compatibility) अभी भी है, लेकिन quality improvement के लिए इसका मूल्य पर्याप्त है
उदाहरण: HCL vs YAML
- type, variables, functions, conditionals, loops आदि में HCL के फायदों की वजह से configuration errors को पहले से रोका जा सकता है, maintainability बढ़ती है, और complex environments में consistency बनी रहती है
etcd के विकल्पों के लिए support
- etcd शक्तिशाली है, लेकिन छोटे clusters या low-spec environments में यह जरूरत से ज्यादा resources इस्तेमाल करता है
- Kine जैसे pluggable backends के लिए आधिकारिक support के माध्यम से default storage की flexibility बढ़ाने की ज़रूरत सामने आई है
- उदाहरण) k8s-dqlite: distributed SQLite+Raft के जरिए हल्की और flexible data layer प्रदान करता है
Helm से आगे: native package manager
Helm की सीमाएँ
- Helm एक ऐसा मामला है जहाँ temporary hacking solution standard बन गया; इसमें template complexity, debugging difficulty, dependency/version conflicts, validation की कमी जैसी कई समस्याएँ हैं
- कई charts की duplication, version mismatch, namespaces के बीच installation कठिनाई, chart search/metadata की कमी, semantic versioning का पालन न होना, unsafe CRD management जैसी व्यावहारिक परेशानियाँ सामने आती हैं
नए package system का प्रस्ताव: KubePkg
- Kubernetes resource form में package/dependency/semantic version/security/lifecycle/metadata तक का समग्र management
- उन्नत lifecycle hooks, state और backup/restore strategies, declarative configuration, verifiable signing process, audit records, organizational policy controls जैसी पूरी क्षमताएँ
- Linux package managers की खूबियों को आगे बढ़ाते हुए, वास्तविक infrastructure management के लिए मजबूत reliability और consistency देना इसका लक्ष्य है
मुख्य आवश्यकताएँ
- पूरी तरह Kubernetes-native resource structure
- stateful applications के लिए built-in support
- signing/validation/security scanning process को मजबूत करना
- structured declarative configuration + schema validation
- पूरे lifecycle का control और आसान Upgrade/Hook support
- Linux-style dependency/version resolution
- change history और audit trail
- organization-specific policy लागू करने की क्षमता
- परिचित Linux package management UX
IPv6 को default बनाना
- अभी IPv6 और dualstack support मौजूद है, लेकिन default अब भी IPv4 है
- cluster-to-cluster communication, NAT issues, IP shortage जैसी समस्याओं के समाधान के साथ यह सरल network structure और built-in IPSec जैसे लाभ देता है
- बड़े IP requirement वाले environments (उदाहरण: /20 range, 40 nodes, एक node पर 30 pod) जल्दी ही IPv4 की सीमा तक पहुँच जाते हैं
- public IPv6 environments में सरल operation, cloud users को आकर्षित करना, private address space management का कम बोझ जैसे व्यावहारिक फायदे स्पष्ट हैं
निष्कर्ष: बदलाव की ज़रूरत और defaults की ताकत
- कुछ लोग कहते हैं, "यह एक open platform है, community खुद संभाल लेगी", लेकिन defaults ही industry के व्यवहार को दिशा देते हैं
- Kubernetes 2.0 के लिए अब आधिकारिक विश्वास, बेहतर design, मजबूत defaults की ज़रूरत है
- industry standard और global datacenter operations के प्रमुख platform के रूप में इसकी स्थिति के अनुरूप एक नई छलांग का यह महत्वपूर्ण समय है
- mobile, web और अन्य तकनीकी क्षेत्रों में पहले भी साहसी बदलावों ने पूरे ecosystem को बदलते हुए दिखाया है
- अब Kubernetes के लिए भी एक प्रतीकात्मक 2.0 के माध्यम से अगले चरण पर विचार करने का समय है
2 टिप्पणियां
मुझे लगता है कि open source को जोड़कर बनाई गई vanilla k8s को कॉन्फ़िगर और ऑपरेट कर सकने वाले इंजीनियर आगे भी बहुत कम ही होंगे।
जैसे Hadoop cluster को Cloudera platform के रूप में बाँधकर खरीदे बिना, vanilla Hadoop ecosystem को ऑपरेट कर सकने वाले इंजीनियर बेहद कम थे।
Hacker News राय
Kubernetes की सबसे बड़ी समस्या यह है कि यह "बस काम करने वाला" सिस्टम नहीं है। वास्तव में, प्रोडक्शन में बिना परेशानी के सर्विस चला सकने वाले इंजीनियर बहुत कम हैं, और VM के ऊपर सीधे Kubernetes क्लस्टर बनाकर उसे मेंटेन करना तो उससे भी ज्यादा कठिन है। इसलिए आजकल उभर रहे serverless startups के पीछे यह धारणा फैली है कि Kubernetes (1) समय बहुत खाता है, (2) बहुत error-prone है, और (3) प्रोडक्शन में fail होने की संभावना ज्यादा है। मुझे लगता है कि Kubernetes 2.0 में दिशा ऐसी होनी चाहिए जहाँ कोई भी आसानी से deployment platform को self-host कर सके, उस पर भरोसे के साथ काम कर सके, और साथ ही एक छोटा लेकिन शक्तिशाली orchestrator core बना रहे। मैं खुद Rivet नाम का orchestrator और deployment platform बना रहा हूँ, और इसे Rivet open source serverless platform के रूप में पेश करता हूँ, लेकिन मैं अक्सर सोचता हूँ, “Kubernetes 2.0 आखिर होगा क्या?” लोग Rivet को मेरी उम्मीद से भी अधिक तरह-तरह के scenarios में अपनाने लगे हैं। Rivet की सबसे बड़ी ताकत यह है कि Kubernetes controller-स्तर की functionality को बहुत आसानी से बनाया जा सकता है, और इसके जरिए game servers, tenant-wise deployments, advanced workload orchestration, multi-tenancy, per-tenant billing, और मजबूत operator design जैसे कई scenarios को संभाला जा सकता है.
यह नज़रिया मुझे काफी खटकता है। शायद उम्र और थोड़े cynicism की वजह से, पर यह पैटर्न बार-बार दिखता है। X technology बहुत भारी लगती है, तो कोई कहता है, “मैं तो बस इसके बिना laptop पर कुछ simple चलाना चाहता हूँ,” और Y technology बना देता है। फिर Y popular हो जाती है, laptop के बाहर scale की ज़रूरत पड़ती है, features जुड़ते जाते हैं, और वह भी भारी हो जाती है। फिर कोई और कहता है, “अब Y भी बहुत भारी हो गई,” और वही कहानी दोहराई जाती है। यह मानो 'time wheel' की तरह है—न शुरुआत, न अंत, बस दोहराव।
असलियत यह है कि k3s (lightweight k8s) को maintain करना वाकई बहुत आसान है। अगर k3s auto-update और ठीक eviction rules हों, तो लगभग छूना नहीं पड़ता, और अगर Ceph जैसा storage कठिन लगे तो Lemon या Longhorn जैसे “zero-management” विकल्प भी चुने जा सकते हैं। हजारों Helm charts मौजूद हैं, इसलिए complex database भी 1 मिनट में deploy किया जा सकता है। सर्विस deployment भी काफी आसान है अगर आप commonly used Helm templates का उपयोग करें। Helm परफेक्ट नहीं है, लेकिन अगर ठीक से सेट किया जाए तो values completion जैसी सुविधाएँ भी मिलती हैं। entry barrier serverless से थोड़ा ऊँचा है, लेकिन एक हफ्ता सीखकर प्रोडक्शन में लाखों रुपये बचाना पूरी तरह worth it है।
Kubernetes जिस समस्या को हल करता है वह है: “इसे deploy कैसे करूँ?” Rivet के docs देखे तो वहाँ single container, Docker Compose, और manual deployment (docker commands) ही हैं। व्यावहारिक रूप से सवाल उठता है कि क्या इतनी scale पर serverless infra को सच में ऐसे deploy किया जा सकता है। मेरा पहला सवाल है: “इस स्तर पर क्या Rivet को Kubernetes के ऊपर (containers, kube-virt आदि के साथ) चलाया नहीं जा सकता?” मुझे नहीं लगता कि Docker Compose, Kubernetes से अधिक robust या scalable हो सकता है। और अगर बात cloud service बेचने की है, तो यह Kubernetes 2.0 वाले concept से भी मेल नहीं खाता। अगर मैं Rivet को self-host करता, तो docs बदलकर इसे Kubernetes पर चलाने योग्य बनाता।
अगर आप cluster maintenance को cloud vendor के हवाले करके “k8s as a service” इस्तेमाल कर रहे हैं, तो मुझे समझना है कि आखिर कौन-सी चीज़ इतनी complex लगती है। configuration की range बड़ी है, लेकिन किसी service को production तक पहुँचाने के लिए वास्तव में कुछ ही settings जानना काफी होता है। Docker Compose से बस थोड़ा अधिक complex configuration के साथ भी k8s पर deploy करना पूरी तरह संभव है। लेकिन अधिकांश apps के लिए यह “थोड़ा अधिक” भी शायद ज़रूरी नहीं होता। सच कहूँ तो यही तो Docker Compose की mass appeal थी, और अफसोस है कि उसे लगातार उतना ध्यान नहीं मिला।
infra operations में “बस काम कर जाए” जैसा कुछ कभी नहीं मिलेगा—यह मेरा अनुभव है। Heroku में भी scale पर issues आते हैं। अगर लक्ष्य ऐसा deployment platform बनाना है जिसे हर कोई आसानी से अपना सके, तो Kubernetes को किसी specific PaaS की foundational primitive की तरह समझना ज्यादा practical है। Rivet दिलचस्प है, और इसमें BEAM ecosystem के कुछ ideas भी दिखते हैं। व्यक्तिगत रूप से, मुझे बड़े-scale deployment से ज्यादा solidity और local-first approaches में रुचि है।
“Low maintenance”... मैं EKS (managed k8s) काफी इस्तेमाल करता हूँ, और cluster की स्थिति को लेकर सीधे चिंता करने की ज़रूरत नहीं पड़ती (हाँ, अगर मैं खुद nodes खराब कर दूँ तो अलग बात है)। Kubernetes सच में अपने आपको “जितना हो सके low maintenance” की तरह पेश करता है, लेकिन असल में यह maintenance का ही एक बड़ा ढेर है। सिर्फ yaml देकर software को दुनिया में तुरंत deploy कर पाने की क्षमता वाकई शानदार है। लेकिन इसकी कीमत है जटिल maintenance। cluster setup, ArgoCD bootstrap, hub-and-spoke model में दूसरे clusters register करना—यह सब किसी circus act जैसा लगता है। ऊपर से CNCF Landscape tooling में से काम के operators install करना, auxiliary tools (जो technically primary नहीं हैं, पर practically जरूरी हैं) मिलाकर कम से कम 30 चीज़ें चलती रहती हैं। values.yaml सेट करने में भी एक-दो घंटे नहीं, उससे ज्यादा लग जाते हैं, और ज्यादातर समय ArgoCD और templating पर जाता है। Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> another values.yaml, इतना लंबा chain सिर्फ एक boolean value पास करने में लग जाता है। cluster/operator update cycles भी तेज़ हैं, इसलिए maintenance issues हमेशा बने रहते हैं। Karpenter से autoscaling करते समय node replacement और zero-downtime एक और circus बन जाता है (stateful apps हों तो k8s में मज़ा दोगुना हो जाता है)। सार यह कि असली “Low maintenance” एक व्यंग्यात्मक अभिव्यक्ति है।
“Low Maintenance” आखिरकार alternatives के मुकाबले एक relative concept है। मेरे अनुभव में k8s के साथ scale, failover, rollback, disaster recovery, DevOps, और independent cluster spin-up जैसी चीज़ों के लिए समान गुणवत्ता की service पाने में maintenance burden काफी कम था। हो सकता है यह context-dependent हो, लेकिन मेरा अनुभव यही रहा है।
मैं पिछले 2 साल से hetzner पर k3s इस्तेमाल कर रहा हूँ और 100% uptime देखा है। maintenance burden इतना कम था कि एक बार master node की SSH key तक खो दी, फिर भी पूरे cluster को दोबारा provision करने में docs update सहित केवल 90 मिनट लगे। अगर सच में urgency होती, तो 15 मिनट में भी काम हो सकता था। अभी मैं cloudflare integration के साथ auto DNS, थोड़ा storage, और ARM-based 3-node 1-master setup के साथ 20 euro/माह में k8s cluster चला रहा हूँ।
लेकिन आप वास्तव में Kubernetes को manage नहीं कर रहे होते, बल्कि CI/CD system, secret management system, database operation automation जैसी सहायक systems को manage कर रहे होते हैं। पहले के समय में yaml की जगह cronjobs, ansible, systemd, bash scripts आदि होते।
यह कुछ ऐसा लगता है जैसे आपने अपना circus खुद खड़ा किया हो। आपको इतनी सारी चीज़ें install ही नहीं करनी चाहिए। हर नई चीज़ technical debt और maintenance cost जोड़ती है, चाहे tool मुफ्त ही क्यों न हो। अगर autoscaling से बचत से अधिक debt/maintenance बढ़ रहा है, तो उसे बंद कर देना बेहतर है।
अगर इसी तरह की services को अलग-अलग बनाकर और operate करके चलाना पड़ता, तो maintenance burden कहीं बड़ा होता। लेकिन Kubernetes इतना manageable है कि आग लगाने के बाद भी उसे छोड़ सकते हैं। बस आपको पता होना चाहिए कि आप क्या कर रहे हैं, ताकि “cool looking tools” install करने के लालच में न फँसें।
K8S yaml को मजबूरी नहीं बनाता। यह idiomatic हो सकता है, लेकिन mandatory नहीं। kubectl apply शुरू से json भी support करता है, और endpoints भी json तथा grpc हैं। jsonnet जैसी कई भाषाओं से config generate किया जा सकता है। दूसरी बात, मुझे समझ नहीं आता कि Helm charts में dependency और dependency ordering इतना issue क्यों बनता है। Kubernetes का मुख्य idiom loop में है: अगर dependency उपलब्ध नहीं है, तो app उसे recoverable error माने और उपलब्ध होने तक retry करे। या crash हो जाए, और ReplicaSet controller उसे अपने आप restart कर दे। अगर chart में dependency नहीं है, तो dependency conflict भी नहीं होगा। अगर कोई app सचमुच dependent है, तो dependent app/service को उसी Helm chart में शामिल करना सही है।
(मुख्य टिप्पणी का उद्धरण) > यह कहना कि crash होने पर ReplicaSet controller app को restart कर देगा, पर्याप्त नहीं है। मान लीजिए keycloak को उठने में 1 मिनट लगता है, तो उस पर निर्भर service keycloak के बिना तुरंत crash हो जाएगी, retry करती रहेगी, throttle हो जाएगी, और keycloak उठने के बाद भी 5~10 मिनट बेकार इंतज़ार करेगी। अगर dependency स्पष्ट है, तो main container पर जाने से पहले init container में dependency service check करके आगे बढ़ना ज्यादा उचित है। अच्छा होता अगर Kubernetes में explicit start dependency declaration होता। crash करके कुछ retry के बाद throttle लगा देना समाधान नहीं है। dependencies वास्तविक दुनिया का हिस्सा हैं।
मेरा मानना है कि dependency failures को recoverable होना चाहिए। मैंने पहले ऐसा outage देखा है जहाँ एक ऐसी dependency की वजह से fail-closed behavior हुआ जिसका असल में उपयोग भी नहीं था। servers के बीच dependencies लगभग हमेशा soft dependencies होती हैं। downstream dependency fail हो तो बस 500 लौटाओ, और load balancer unhealthy servers को avoid कर ले।
लोग कहते हैं “supposed to”, लेकिन यह केवल in-house software stack बनाने वाले case में अच्छी तरह फिट बैठता है। बहुत-सा पुराना software पहले सिर्फ docker support करता था और बाद में Kubernetes पर चलने लायक बनाया गया। developer अगर अपनी philosophy के अनुसार tools बनाते हैं, तो लोग उन्हें अपनी मनचाही तरह use करते हैं और नतीजा अक्सर बिखरा हुआ होता है। आखिरकार लोगों को features और choices दोनों देने पड़ते हैं, और market उन्हें अपने हिसाब से इस्तेमाल करता है।
“yaml की जगह json भी लिख सकते हैं” यह बताकर पूरे मुद्दे की आलोचना करना असल बात नहीं पकड़ता। यह वह चीज़ नहीं है जिसकी सच में किसी को परवाह है। मुझे यह बेवजह की nitpicking लगती है।
yaml को HCL से बदलने के विचार का मैं कड़ा विरोध करता हूँ। HCL developers के लिए देखना मुश्किल है और पढ़ना भी कठिन। import support, debugging difficulty जैसी usability शिकायतें बहुत हैं। मैं समझ नहीं पाता कि protobuf जैसी interface definition language को केंद्र में रखकर, user preference के मुताबिक सिर्फ representation conversion की छूट क्यों नहीं दी गई।
HCL सबसे खराब है। k8s yaml ही पर्याप्त रहा है, उससे कम कभी नहीं पड़ा। अगर configuration बहुत complex हो रही है, तो वह config map की नहीं, app design की समस्या अधिक है।
सच तो यह है कि HCL हो, JSON हो या YAML—client side पर serialize/deserialize कर दो, काम हो जाता है। यानी यह Kubernetes की समस्या नहीं, बस एक external transformation layer का मामला है।
Kubernetes interface definition पहले से protobuf-आधारित है (CRD को छोड़कर)।
HCL को लेकर मेरी मुख्य शिकायत उसका for loop syntax है। सच में भयानक है।
“HCL developers के लिए कठिन है और lint/debug करना मुश्किल है” जैसी बात मुझे ज्यादा इस तरह लगती है कि लोग कुछ नया सीखना नहीं चाहते। शायद complex domain को HCL सीखने की परेशानी के साथ गड्डमड्ड कर दिया जाता है।
मैं “Kubernetes 2.0” शैली का nebulous project बना रहा हूँ (अभी pre-alpha stage में)। लक्ष्य है: globally distributed/lightweight system, laptop पर single binary की तरह चल सके, और cloud में हजारों nodes तक scale कर सके; साथ ही Tailnet networking, BitTorrent storage, multi-tenancy, live migration आदि। इनमें से अधिकांश requirements ML operations से आईं, खासकर GPU scarcity की वजह से, और अगर ML भविष्य में सामान्य बात बन गया, तो शायद यही baseline बन जाए।
live migration दिलचस्प है। हम अभी कई clusters और clouds के बीच autoscaling-आधारित pricing strategy इस्तेमाल कर रहे हैं, लेकिन live migration तो एक बिल्कुल अलग स्तर की चुनौती है।
यह Kubernetes नहीं है, बल्कि GPU operations पर केंद्रित एक अलग system है।
“globally distributed” शायद उल्टा non-requirement हो सकता है। अगर Tailnet default network है, तो यह वह feature है जिसे मैं सबसे पहले हटाना चाहूँगा। Kubernetes का single NIC मान लेना cloud-centric और परेशान करने वाली विरासत है (कई CNI और हाल का Multus प्रोजेक्ट—संदर्भ: redhat ब्लॉग—इसलिए स्वागतयोग्य हैं)। multi-tenant design k8s से व्यवहार में कितना अलग है, यह जानने की जिज्ञासा है। और अगर storage BitTorrent से होगी, तो public container images भी share करने पर egress traffic bills बहुत बड़े हो सकते हैं।
GitHub पर Chart.yaml दिख रहा है, और template provider_aws.yaml आदि तो सच में वही code patterns हैं जिन्हें मैं नहीं देखना चाहता।
Kubernetes अभी भी बहुत complex लगता है। बस mainstream adoption की वजह से यह उतना महसूस नहीं होता। Kubernetes 2.0 में user experience, खासकर frequently performed operations—जैसे app deployment, service exposure, service account/image changes—और आसान होनी चाहिए। लेकिन अभी trend LLM का है, इसलिए follow-up development मुश्किल दिखता है।
Kubernetes में abstraction layers बहुत अधिक हैं। pods एक शानदार core concept है, लेकिन deployment, rep set, namespace आदि जुड़ते ही लगता है कि काश यह Docker Swarm जितना simple होता। Terraform भी single-layered था और सीखना आसान था। मुझे अब सच में एहसास हो रहा है कि K8s की learning curve कितनी steep है।
यह वही तरह का मुद्दा है जहाँ लगता है कि “computer programs की type distinctions आखिर मानव perception का परिणाम हैं।” operator/controller पुराने COM/CORBA की तरह over-abstracted लगते हैं (फायदा भी, नुकसान भी)। simple implementations के लिए कोई अधिक constrained k8s-lite शायद ज्यादा उपयुक्त हो। दूसरी ओर, complex environments में कई बार k8s की मौजूदा abstractions भी अपर्याप्त लगी हैं। चाहे वह Kubernetes 2.0 हो या कुछ और, क्या एक ही system वास्तव में दुनिया की सारी समस्याएँ इस तरह समेट सकता है कि human developers/designers उसे संभाल सकें—इस पर संदेह है।
मुझे ऐसा system चाहिए जिसमें “sane defaults” हों—यानी network/storage/load balancer जैसी चीज़ों के लिए बिना खास चुनाव किए default state ही पर्याप्त हो। yaml और HCL दोनों मुझे खास पसंद नहीं। config का बेहतर तरीका चाहिए, और सिर्फ language बदलने से समस्या हल नहीं होगी। मुझे लगता है IPv6 अनिवार्य होना चाहिए। Docker, containers, और Kubernetes—इन सबके अंदरूनी हिस्से IPv6-only होने चाहिए थे, और IPv4 को ingress controller पर exception की तरह handle किया जाना चाहिए था।
“Sane defaults” और “managed service customers को migrate कराना” — इन दोनों के बीच एक मूलभूत टकराव है। जितना लंबे समय तक k8s को देखता हूँ, उतना लगता है कि storage/networking जैसी “batteries not included” philosophy बढ़ती गई है, और AWS/GCP जैसी कंपनियाँ उसी के लिए महंगे integration services बेचती हैं। एक अर्थ में आज का practical K8s सिर्फ open source नहीं, बल्कि cloud gaps भरने वाले products बेचने का enabling tool भी बन चुका है।
(व्यक्तिगत अनुभव) Terraform/HCL, YAML से इस मायने में बेहतर लगता है कि यह invisible characters पर निर्भर नहीं करता, इसलिए पढ़ना आसान है।
“sane defaults” की वजह से ही मुझे k3s कहीं ज्यादा पसंद है।
2.0 release के लिए यह wish list कुछ modest लगती है। मेरे आसपास लगभग सभी लोग production k8s complexity से परेशान हैं। असली सवाल है कि backward compatibility और simplicity को एक साथ कैसे हासिल किया जाए। आमतौर पर backward compatibility की वजह से complexity बहुत बढ़ जाती है, क्योंकि नए system को पुराने और नए दोनों features का बोझ उठाना पड़ता है।
मुझे लगता है कि मैं पहले से ही Terraform के जरिए clusters और apps manage करते हुए “Kubernetes 2.0 world” में जी रहा हूँ।
tf applyसे cluster, nodes, cloud integrations (जैसे S3), और cluster के अंदर की services तक सब कुछ एक साथ set up हो जाता हैfrontend background से आने के नाते, मुझे Kubernetes काफी intuitive लगा। पहले मैं data लेकर reactive UI बनाता था, अब ऐसा लगता है कि मैं control plane के resource और config से मेल बैठाने वाला code लिख रहा हूँ।