Kubernetes 1.37 में 67 enhancements आए हैं।
अपग्रेड की योजना बनाने से पहले प्लेटफ़ॉर्म टीमों को इन सभी 67 को समझने की ज़रूरत नहीं है।
तीन बदलाव खास तौर पर देखने लायक हैं, क्योंकि ये इस बात को प्रभावित करते हैं कि क्लस्टर को कैसे सुरक्षित किया जा सकता है, idle वर्कलोड को कैसे स्केल किया जा सकता है, और लंबे समय से इस्तेमाल हो रहे एक मेट्रिक्स API को कैसे सपोर्ट मिलता है।
वे हैं:
- rootless kubelet का Beta तक पहुँचना;
- HPA scale-to-zero का Beta तक पहुँचना;
- Kubernetes Metrics API का स्थिर (stable) हो जाना।
इनमें से कोई भी यह संकेत नहीं देता कि आपको तुरंत अपग्रेड करना चाहिए।
लेकिन अपने अगले Kubernetes अपग्रेड साइकिल से पहले इन्हें समझना ज़रूरी है।
Rootless kubelet अब व्यावहारिक इस्तेमाल के करीब पहुँच रहा है
Kubernetes के node components परंपरागत रूप से host पर root privileges के साथ चलते आए हैं।
Kubernetes 1.37, KubeletInUserNamespace को Beta तक ले जाता है, जिसे अक्सर rootless Kubernetes कहा जाता है।
विचार बहुत सीधा है।
kubelet और संबंधित node components को host पर पूरी root access के साथ चलाने के बजाय, उन्हें एक non-root host user के रूप में एक Linux user namespace के अंदर चलाया जा सकता है।
अगर किसी container-runtime या node-component की vulnerability का फ़ायदा उठाया जाता है, तो host-level privileges कम करने से हमलावर द्वारा पहुँचाए जा सकने वाले नुकसान को घटाया जा सकता है।
यह एक उपयोगी सुरक्षा सुधार है।
लेकिन इसमें एक ज़रूरी बात है।
Kubernetes 1.37 में यह feature gate डिफ़ॉल्ट रूप से enabled है, लेकिन मौजूदा क्लस्टर अचानक rootless नहीं बन जाते। node को user namespace के अंदर चलाने के लिए जानबूझकर कॉन्फ़िगर करना ही होगा।
प्लेटफ़ॉर्म टीमों के लिए, इसका मतलब है कि यह अपग्रेड के दौरान अपने आप बदल जाने वाली चीज़ नहीं, बल्कि टेस्ट करने वाली चीज़ है।
Compatibility भी मायने रखती है।
कुछ CNI या CSI drivers अब भी उन privileges की उम्मीद कर सकते हैं जो एक सामान्य rootful node पर उपलब्ध होते हैं। Kubernetes खुद बताता है कि rootless environments में कुछ drivers को compatibility से जुड़ी दिक्कतें आ सकती हैं।
इसलिए असली सवाल यह नहीं है:
क्या Kubernetes अब root के बिना चल सकता है?
चल सकता है।
व्यावहारिक सवाल यह है:
क्या हमारा Kubernetes स्टैक इस तरह सही ढंग से चल सकता है?
इसमें container runtime, networking, storage drivers, node monitoring, और host-level access की ज़रूरत वाला कोई भी सॉफ़्टवेयर शामिल है।
Rootless mode एक ऐसा सुरक्षा सुधार है जिसे टेस्ट करना चाहिए।
बिना staging cycle के इसे पूरे production nodes पर enable करना मैं पसंद नहीं करूँगा।
महंगे वर्कर्स के लिए Scale-to-zero खास तौर पर दिलचस्प है
Horizontal Pod Autoscaler आमतौर पर कम से कम एक replica चालू रखता है।
Kubernetes 1.37 इसे बदल देता है।
HPA scale-to-zero अब Beta है और डिफ़ॉल्ट रूप से enabled है। कोई वर्कलोड पूरी तरह zero replicas तक स्केल डाउन हो सकता है और काम आने पर फिर से शुरू हो सकता है।
सामान्य हल्के वर्कलोड के लिए, यह उपयोगी हो सकता है।
GPU-आधारित AI या batch वर्कलोड के लिए, यह कहीं ज़्यादा दिलचस्प हो सकता है।
अगर कोई worker सिर्फ़ queue से jobs प्रोसेस करने के लिए है, तो queue खाली होने पर भी GPU-आधारित pod को चालू रखना महंगी क्षमता की बर्बादी हो सकती है।
scale-to-zero के साथ, Kubernetes उस आख़िरी idle replica को हटा सकता है।
इसमें एक पेंच है।
वर्कलोड को फिर से जगाने के लिए HPA सामान्य CPU या memory utilisation का इस्तेमाल नहीं कर सकता।
जब कोई pods नहीं होते, तो मापने के लिए कोई CPU या memory usage भी नहीं होता।
इसलिए scaling का सिग्नल किसी ऐसी चीज़ से आना चाहिए जो pods के न होने पर भी मौजूद रहे, जैसे:
- queue depth;
- pending jobs;
- कोई अन्य object metric;
- एक external metric.
cold-start समय भी एक कारक है।
जब काम आता है, तो Kubernetes को वह metric नोटिस करना होता है, एक pod शेड्यूल करना होता है, और प्रोसेसिंग शुरू होने से पहले एप्लिकेशन को स्टार्ट करना होता है।
background workers के लिए यह ठीक हो सकता है।
तुरंत जवाब देने की उम्मीद वाली user-facing HTTP सेवा के लिए यह उतना उपयुक्त नहीं है। Kubernetes Services स्केल-डाउन हुए एप्लिकेशन के फिर से शुरू होने तक requests को रोककर नहीं रखतीं, इसलिए request-driven वर्कलोड को किसी और buffering तरीके की ज़रूरत होती है।
AI प्लेटफ़ॉर्म के लिए, यह एक उपयोगी trade-off पैदा करता है:
कम idle लागत बनाम पहली प्रतिक्रिया में देरी।
यही वह हिस्सा है जिसे टीमों को मापना चाहिए।
सिर्फ़ इसलिए scale-to-zero enable मत कीजिए क्योंकि इससे पैसे बच सकते हैं।
यह टेस्ट कीजिए कि वर्कलोड को फिर से काम करने लायक बनने में कितना समय लगता है।
Metrics API का स्थिर होना उतना नाटकीय नहीं, फिर भी ज़रूरी है
Kubernetes 1.37, metrics.k8s.io को स्थिर v1 तक भी प्रमोट करता है।
यह वह API है जिसका इस्तेमाल kubectl top जैसे tools और resource-based autoscaling के पीछे CPU और memory मेट्रिक्स के लिए होता है।
ज़्यादातर टीमों के लिए, नाटकीय रूप से कुछ नहीं बदलता।
resource types और fields पिछले v1beta1 API जैसे ही रहते हैं।
असल में यही खास बात है।
यह कोई नई observability सुविधा नहीं है।
Kubernetes लंबे समय से इस्तेमाल हो रहे एक API को औपचारिक रूप से वही स्थिरता गारंटी दे रहा है जो एक GA API के साथ जुड़ी होती है।
Kubernetes resource metrics के आसपास integrations, automation, या internal tooling बनाए रखने वाली प्लेटफ़ॉर्म टीमों के लिए, इससे वर्षों से Beta में रही एक dependency को लेकर अनिश्चितता कम होती है।
उपयोगी है, लेकिन ऐसा कुछ नहीं जिसके लिए आपको अपना पूरा monitoring stack फिर से डिज़ाइन करना पड़े।
अपग्रेड से पहले टीमों को क्या टेस्ट करना चाहिए?
Kubernetes 1.37 रिलीज़ में इससे कहीं ज़्यादा बदलाव हैं, लेकिन ये तीन एक काफ़ी छोटी अपग्रेड चेकलिस्ट की ओर ले जाते हैं।
अगर आप rootless nodes आज़माना चाहते हैं, तो production में इस्तेमाल करने से पहले अपने CNI, CSI, runtime, monitoring, और host-level tooling को टेस्ट कीजिए।
अगर आप scale-to-zero इस्तेमाल करने की योजना बना रहे हैं, तो सुनिश्चित कीजिए कि आपके वर्कलोड के पास एक भरोसेमंद external या object metric हो, और पूरे cold-start समय को मापिए।
अगर आपके internal tools सीधे Metrics API का इस्तेमाल करते हैं, तो जाँच लीजिए कि वे metrics.k8s.io/v1 के लिए तैयार हैं या नहीं, भले ही API की संरचना में कोई बड़ा बदलाव न हुआ हो।
और किसी भी Kubernetes अपग्रेड की तरह, यह मान लेने के बजाय कि कोई फ़ीचर Beta या GA बनने का मतलब है कि उसके आसपास का हर component तैयार है, आप जो असली प्लेटफ़ॉर्म चला रहे हैं उसी को टेस्ट कीजिए।
Kubernetes 1.37 का सबसे उपयोगी हिस्सा
Kubernetes रिलीज़ आसानी से feature gates और enhancement नंबरों की लंबी सूचियाँ बन सकती हैं।
ज़्यादातर प्लेटफ़ॉर्म टीमों के लिए, इन्हें इस तरह पढ़ना उपयोगी तरीका नहीं है।
Kubernetes 1.37 में कुछ ज़रूरी बदलाव हैं, लेकिन व्यावहारिक कारणों से तीन खास तौर पर सामने आते हैं।
Rootless kubelet टीमों को node-level privilege घटाने का एक और तरीका देता है।
Scale-to-zero उन वर्कलोड की लागत घटा सकता है जिन्हें लगातार चलते रहने की ज़रूरत नहीं है, खासकर GPU-आधारित jobs जैसे महंगे वर्कर्स की।
और Metrics API आख़िरकार एक लंबे Beta दौर से निकलकर एक स्थिर API बन जाता है।
इनमें से किसी के लिए भी तुरंत production में बदलाव की ज़रूरत नहीं है।
लेकिन तीनों ही आपकी अगली staging और अपग्रेड चर्चा में शामिल करने लायक हैं।