मुझे Kubernetes की ज़रूरत नहीं थी, और शायद आपको भी नहीं है

मैंने Kubernetes छोड़कर Google Cloud Run क्यों चुना

Kubernetes अपनाने की पृष्ठभूमि

• 2013 में लॉन्च किए गए ऑनलाइन 3D एडिटिंग प्लेटफ़ॉर्म Clara.io में bare-metal server का उपयोग करके इंफ्रास्ट्रक्चर को optimize किया गया, लेकिन hardware management और monitoring में बहुत अधिक काम लगता था।
• 2018 में Threekit.com प्रोजेक्ट में Kubernetes चुना गया। उस समय Azure, AWS, Docker ने Kubernetes को standard के रूप में अपनाया, जिससे यह mainstream बन गया।

Kubernetes की सीमाएँ

1. लागत की समस्या:

   • management node, cluster redundancy जैसी बुनियादी cluster setup लागत काफ़ी अधिक होती है।
   • धीमे autoscaling के कारण services को overprovision करना पड़ता है, जिससे unused resources की लागत आती है।

2. वर्कलोड मैनेजमेंट की कठिनाई:

   • job scheduling जटिल है, और built-in scheduler तथा Argo भी large-scale jobs में अप्रभावी हैं।

3. जटिलता का बोझ:

   • बहुत सारी सुविधाएँ होने से साधारण काम भी जटिल हो जाते हैं।
   • Kubernetes को manage करने के लिए dedicated DevOps स्टाफ चाहिए, जिससे लागत और बढ़ती है।

Google Cloud Run पर स्विच

Cloud Run Kubernetes की जटिलता की जगह एक सरल और cost-effective environment देता है।

नई सेटिंग

• Docker container-आधारित इंफ्रास्ट्रक्चर:
  • इसमें auto-scaling services और long-running jobs के लिए containers शामिल हैं।
  • Cloud Run container deployment, scaling, downtime management और job execution को automate करता है।

Cloud Run के फ़ायदे

1. लागत दक्षता:

   • billing CPU और memory usage time के आधार पर होती है।
   • idle services पर कोई लागत नहीं आती।
   • उदाहरण: Web3D Survey साइट 500,000 मासिक ट्रैफ़िक संभालते हुए $4/माह में चल सकती है।

2. तेज़ और स्थिर autoscaling:

   • Kubernetes की तुलना में कुछ ही सेकंड में scaling हो जाती है।
   • demand spikes को तेज़ी से संभाला जा सकता है।

3. Kubernetes मैनेजमेंट का बोझ नहीं:

   • Cloud Run, Google के Borg पर आधारित है, इसलिए Kubernetes cluster management की ज़रूरत नहीं पड़ती।

4. सरल asynchronous jobs:

   • Cloud Run Tasks का उपयोग करके automatic retry और large-scale job execution आसान हो जाता है।

Kubernetes की संभावित समस्या: cluster lock-in

• Kubernetes features पर निर्भर होने से cluster के बाहर resources का integration या विस्तार कठिन हो सकता है।
• किसी specific infrastructure पर निर्भरता बढ़ जाती है, जिससे scaling और migration जटिल तथा महँगे हो जाते हैं।

Cloud Run उपयोग को लेकर आम सवाल

“क्या GCP dependency चिंता की बात नहीं है?”

• Docker-आधारित setup होने के कारण AWS जैसे दूसरे cloud पर migration लगभग 1 हफ़्ते में संभव है।
• व्यावहारिक रूप से, political factors को छोड़कर cloud provider बदलने के मामले बहुत कम होते हैं।

“क्या Cloud Run भी आख़िरकार Managed Kubernetes नहीं है?”

• Cloud Run Knative interface का उपयोग करता है, लेकिन यह Kubernetes नहीं बल्कि Google के Borg पर चलता है।
• यह Kubernetes की जटिलता को हटाकर एक सरल interface देता है।

मौजूदा workflow की कमियाँ

1. service name management की असुविधा:

   • local और server पर consistent configuration management के लिए abstraction layer की ज़रूरत होती है।
   • Kubernetes जैसी naming management सुविधा मौजूद नहीं है।

2. Cloud Run Task emulation की कमी:

   • local में jobs विकसित करते समय log output capture और tracking सहित सरल emulation environment उपलब्ध नहीं है।

निष्कर्ष

• Cloud Run लागत, गति, scalability और simplicity के लिहाज़ से एक बेहतरीन समाधान है
• बड़ी कंपनियों या जटिल आवश्यकताओं वाले मामलों में Kubernetes उपयोगी हो सकता है, लेकिन
• जहाँ सरलता और दक्षता अधिक महत्वपूर्ण हों, वहाँ Cloud Run कहीं अधिक व्यावहारिक है
• PS: Kubernetes के कुछ specific extensions जोड़कर इन समस्याओं को हल किया जा सकता है, लेकिन इससे केवल जटिलता बढ़ेगी, और ऐसी Kubernetes environment पर निर्भर रहना उचित नहीं लगता जो साधारण ज़रूरतों से कहीं आगे हो

[blurblah]

कोई silver bullet नहीं होती। बस स्थिति के हिसाब से उसे सही तरीके से इस्तेमाल करना चाहिए, हाहा।
सिर्फ इसलिए कि यह ट्रेंडी है, अगर बिना आलोचनात्मक सोच के kubernetes अपना लिया जाए तो मुश्किलें बढ़ सकती हैं, लेकिन फिर भी मुझे लगता है कि थोड़ा बड़े पैमाने के environment में यह एक अच्छा tool है।
इसे अपनाने के बाद अगर बस adoption करके छोड़ दिया जाए, तो आप इसका सही इस्तेमाल नहीं कर पाएंगे।
और यह किसी भी tool पर लागू होता है, क्योंकि कोई भी tool 100% डेवलपर या user की needs पूरी नहीं कर सकता, इसलिए उचित स्तर की automation ज़रूरी लगती है।

[bungker]

Kubernetes में बस setup हो जाए तो उसके बाद सिर्फ मज़े ही मज़े हैं ... sob

[riki3]

Kubernetes मेरी रोज़ी-रोटी है, और एक समय था जब मुझे लगता था कि यही सही जवाब है।
लेकिन समय के साथ मैंने खुद को बहुत सी समस्याओं का सामना करते और समय बर्बाद करते हुए पाया।

मैं दूसरों को k8s की सिफारिश करता हूँ, लेकिन शायद अपनी service में इसका इस्तेमाल नहीं करूँगा। k8s तो k8s, अब मैं containers से भी थक चुका हूँ।

[joon14]

अगर आप AWS इस्तेमाल कर रहे हैं, तो क्या इसे ECS जैसा समझा जा सकता है?

[tujuc]

हाँ, मोटे तौर पर बात वही है। :)

[eclipsense]

Kubernetes का इस्तेमाल न कर पाना अपनी कमी है; यह कहना थोड़ा मुश्किल है कि Kubernetes अच्छा नहीं है।

[tujuc]

मैं भी लेखक की सोच से काफ़ी हद तक सहमत हूँ.
अभी हमारी कंपनी का आकार भी इतना नहीं है कि kube इस्तेमाल करने की ज़रूरत पड़े.

मुझे लगता था कि सभी डेवलपर Kube का इस्तेमाल करके मैनेजमेंट कर पाएँगे.
लेकिन कंपनी के औसत डेवलपर स्तर से भी कम इंफ्रास्ट्रक्चर समझ रखने वाले लोग सेटअप कर सकें और समस्याएँ सुलझा सकें, इसके लिए गाइड करना ज़्यादा बेहतर लगा...

[doolayer]

???: मुझे AI की ज़रूरत नहीं थी, और शायद आपको भी नहीं होगी.

[ilbanin00]

किसी भी प्रोडक्ट में कुछ न कुछ trade-offs होते हैं

[bbulbum]

managed सर्विसेज़ इस्तेमाल करने पर मुझे खास तौर पर मैनेजमेंट में कोई मुश्किल महसूस नहीं हुई,,
मुझे लगता है कि किसी भी टूल को अगर सही सीमा में इस्तेमाल किया जाए तो वह उपयोगी होता है, लेकिन Kubernetes के मामले में खास तौर पर 'जटिल configuration संभव होना' ही अक्सर मुख्य आलोचना बन जाती है।

[tujuc]

लगभग हर चीज़ को अपनी मर्ज़ी के मुताबिक बनाया जा सकता है, इसलिए... :) शायद इसी वजह से लोग इसे अक्सर बहुत जटिल तरीके से इस्तेमाल करते हैं हाहा...

[GN⁺]

Hacker News राय

• "cloud tech" के प्रति असंतोष जताते हुए कहा गया है कि Kubernetes इस्तेमाल करने पर YAML फ़ाइलों को बदलने और errors ठीक करने में बहुत समय चला जाता है। cloud integration से बचकर खुद server सेटअप करना चाहने की राय है

• Kubernetes में DevOps और management time के अलावा काफ़ी infrastructure cost भी आती है। cloud provider के managed Kubernetes का इस्तेमाल ज़्यादा efficient होने का सुझाव दिया गया है

• यह बताया गया है कि Kubernetes container orchestration tool नहीं बल्कि computer cluster बनाने का tool है, इसलिए अगर cluster की ज़रूरत नहीं है तो Kubernetes इस्तेमाल न भी करें तो चलेगा

• DevOps में अत्यधिक निवेश कम हो रहा है, और Kubernetes पर आलोचनात्मक नज़रिया साझा किया गया है। इस बात पर ज़ोर है कि छोटे startup के लिए एक single server ही काफ़ी हो सकता है

• Cloud Run इस्तेमाल करते समय TCP connection limits, execution environment के चयन, और auto scaling settings जैसी बातों पर ध्यान देने का उल्लेख है

• Cloud Run छोटे startup के लिए उपयुक्त है, लेकिन इसमें security architecture के बुनियादी हिस्से firewall control की कमी होने की ओर इशारा किया गया है। अंततः VPC की ज़रूरत पड़ने की बात कही गई है

• यह कहा गया है कि Google Cloud Run और Kubernetes की तुलना निष्पक्ष नहीं है, और दोनों के अपने फायदे-नुकसान बताए गए हैं। इस बात पर ज़ोर है कि Kubernetes जटिल कामों के लिए उपयुक्त है

• Kubernetes की learning curve कठिन है, लेकिन सही तरह इस्तेमाल किया जाए तो यह एक शक्तिशाली tool है

• Kubernetes पर की गई आलोचना से असहमति जताते हुए कहा गया है कि जटिल apps deploy करते समय Kubernetes API की ज़रूरत पड़ सकती है

• यह समझाया गया है कि Kubernetes की जटिलता ज़्यादातर system management tasks से आती है, जबकि Kubernetes खुद स्थिर है

• यह इशारा किया गया है कि IaC और CM को configuration कम करके management आसान बनाना चाहिए, लेकिन व्यवहार में अक्सर अधिक मेहनत लगती है। कई मामलों में Kubernetes की ज़रूरत नहीं होती, और एक अच्छा system administrator ज़्यादा महत्वपूर्ण होता है