लेख में तुलना की गई सपोर्ट टाइमलाइन का वैचारिक चित्र। चित्र में Azure की बाद वाली तारीख़ को Extended Support लिखा है, जबकि लेख की तालिका उसे LTS कहती है।
Kubernetes 1.34 का अपस्ट्रीम सपोर्ट जीवनचक्र 27 अक्टूबर 2026 को खत्म होता है। उस तारीख के बाद, Kubernetes प्रोजेक्ट 1.34 रिलीज़ ब्रांच के लिए सामान्यतः सुरक्षा अपडेट या बग फ़िक्स नहीं देगा।
जो संगठन अपने खुद के Kubernetes कंट्रोल प्लेन चलाते हैं, उनके लिए यह समय-सीमा सीधे मायने रखती है। 1.34 चला रहा क्लस्टर वर्कलोड चलाता रह सकता है, लेकिन हो सकता है कि नई खोजी गई समस्याओं के लिए उस वर्शन को अब अपस्ट्रीम फ़िक्स न मिलें।
मैनेज्ड Kubernetes चलाने वाली टीमों के लिए स्थिति अलग है।
Amazon EKS, Azure Kubernetes Service (AKS) और Google Kubernetes Engine (GKE) अपने-अपने रिलीज़ शेड्यूल और कुछ मामलों में एक्सटेंडेड-सपोर्ट विकल्प खुद संभालते हैं। इसलिए एक प्रोवाइडर पर Kubernetes 1.34 चला रहा क्लस्टर, किसी दूसरे प्रोवाइडर पर उसी माइनर वर्शन की तुलना में ज़्यादा समय तक सपोर्ट में रह सकता है।
तात्कालिक ऑपरेशनल सवाल सिर्फ़ यह नहीं है कि क्लस्टर 1.34 चला रहा है या नहीं। सवाल यह है कि उस डिस्ट्रीब्यूशन को कौन मैनेज करता है, कौन-सी सपोर्ट अवधि लागू होती है, और क्या क्लस्टर वर्कलोड को बाधित किए बिना सपोर्टेड अपग्रेड पूरा कर सकता है।
एक Kubernetes वर्शन, चार सपोर्ट टाइमलाइन
Kubernetes प्रोजेक्ट फ़िलहाल सबसे हाल की तीन माइनर ब्रांच बनाए रखता है: 1.35, 1.36 और 1.37। वर्शन 1.34 27 अगस्त 2026 को मेंटेनेंस मोड में गया, और इस समीक्षा के समय उसका सबसे नया सूचीबद्ध पैच 1.34.12 है।
मैनेज्ड प्रोवाइडर अपने परीक्षित रिलीज़, मेंटेनेंस नीतियों और जीवनचक्र व्यवस्थाओं के ज़रिए सपोर्ट बढ़ाते या संभालते हैं।
| प्लेटफ़ॉर्म | Kubernetes 1.34 सपोर्ट की समय-सीमा | इसका मतलब |
|---|---|---|
| अपस्ट्रीम / सेल्फ-मैनेज्ड | 27 अक्टूबर 2026 | अपस्ट्रीम पैच रिलीज़ खत्म होती हैं (27 अगस्त से सिर्फ़ गंभीर सुरक्षा फ़िक्स ही स्वीकार किए जा रहे हैं) |
| Amazon EKS | स्टैंडर्ड: 2 दिसंबर 2026। एक्सटेंडेड: 2 दिसंबर 2027 | एक्सटेंडेड सपोर्ट डिफ़ॉल्ट रूप से चालू रहता है (अपग्रेड नीति EXTENDED), प्रति क्लस्टर-घंटा अतिरिक्त लागत पर। एक्सटेंडेड सपोर्ट खत्म होने पर क्लस्टर अपने-आप अपग्रेड हो जाता है |
| Azure AKS | स्टैंडर्ड एंड ऑफ़ लाइफ़: नवंबर 2026। LTS: नवंबर 2027 | एक्सटेंडेड जीवनचक्र नामांकन और पात्रता पर निर्भर है। प्रकाशित महीने सटीक तारीखें नहीं हैं |
| Google GKE | स्टैंडर्ड: 25 जनवरी 2027। एक्सटेंडेड: 25 नवंबर 2027 | एक्सटेंडेड सपोर्ट सिर्फ़ Extended रिलीज़ चैनल में नामांकित क्लस्टर पर लागू होता है |
स्रोत: Kubernetes रिलीज़ शेड्यूल, Amazon EKS जीवनचक्र, AKS सपोर्टेड वर्शन और GKE रिलीज़ शेड्यूल। तारीखें 26 अक्टूबर 2026 तक की हैं, और प्रोवाइडर शेड्यूल बदल सकते हैं।
ये अंतर ऑपरेशनल रूप से अहम हैं।
दिसंबर की स्टैंडर्ड-सपोर्ट समय-सीमा के करीब पहुँच रही EKS क्लस्टर वाली टीम के पास नियंत्रित अपग्रेड तय करने का समय हो सकता है, हालाँकि एक्सटेंडेड-सपोर्ट शुल्क और अंततः प्रोवाइडर द्वारा किए जाने वाले अपग्रेड उस फ़ैसले को प्रभावित करते हैं।
AKS के लिए, क्लस्टर का सपोर्ट स्तर उसके जीवनचक्र नामांकन और सपोर्टेड वर्शन पर निर्भर करता है। लॉन्ग-टर्म सपोर्ट कभी अपने-आप चालू नहीं होता। क्लस्टर को स्पष्ट रूप से नामांकित करना पड़ता है।
GKE का Extended चैनल माइनर वर्शन को एक्सटेंडेड सपोर्ट खत्म होने तक सपोर्ट देता है, जबकि बाकी रिलीज़ चैनल (Rapid, Regular और Stable) वाले क्लस्टर स्टैंडर्ड सपोर्ट और स्वचालित अपग्रेड शेड्यूल का पालन करते हैं।
सेल्फ-मैनेज्ड क्लस्टर को इनमें से कोई व्यवस्था सिर्फ़ इसलिए नहीं मिल जाती कि उसके अपस्ट्रीम कंपोनेंट अभी चल रहे हैं। जारी सपोर्ट के लिए उपयुक्त डिस्ट्रीब्यूशन वेंडर, सपोर्ट प्रोवाइडर या आंतरिक रूप से चलाई जाने वाली पैच रणनीति चाहिए।
प्लेटफ़ॉर्म टीमों को सबसे पहले क्या जाँचना चाहिए
क्लस्टर में बदलाव से पहले उसका असली कंट्रोल-प्लेन वर्शन और नोड पर चल रहे वर्शन पता करें।
kubectl से पहुँच योग्य क्लस्टर के लिए दो उपयोगी कमांड ये हैं:
kubectl version
kubectl get nodes -o wideपहली कमांड क्लाइंट और सर्वर वर्शन की जानकारी देती है। दूसरी kubelet वर्शन समेत नोड का ब्योरा दिखाती है।
ये कमांड एक शुरुआती बिंदु देती हैं, लेकिन यह नहीं बतातीं कि मैनेज्ड सर्विस की सपोर्ट नीति उस वर्शन को कवर करती है या नहीं।
EKS, AKS या GKE के लिए, प्रोवाइडर के मैनेजमेंट इंटरफ़ेस या CLI में क्लस्टर का कॉन्फ़िगर किया Kubernetes वर्शन, रिलीज़ चैनल या सपोर्ट नीति जाँचें। इन्वेंटरी में नोड पूल और अलग से मैनेज होने वाले कंपोनेंट भी शामिल करें।
कंट्रोल प्लेन और नोड ज़रूरी नहीं कि एक ही समय पर नए माइनर वर्शन पर जाएँ।
मैनेज्ड प्रोवाइडर कंट्रोल प्लेन को अपने-आप अपग्रेड कर सकता है, जबकि कुछ नोड ग्रुप के लिए अलग कार्रवाई चाहिए हो सकती है। सेल्फ-मैनेज्ड क्लस्टर में आमतौर पर ऑपरेटरों को दोनों हिस्सों का तालमेल बिठाना पड़ता है।
इसलिए इन्वेंटरी में Kubernetes डिस्ट्रीब्यूशन, कंट्रोल-प्लेन वर्शन, नोड और नोड-पूल वर्शन, सपोर्ट की समय-सीमा, अपग्रेड नीति और दर्ज मेंटेनेंस पाबंदियाँ होनी चाहिए।
यही जानकारी तय करती है कि अगला कदम बिना सपोर्ट वाले वर्शन का तत्काल अपग्रेड है, योजनाबद्ध मेंटेनेंस बदलाव है, या यह पुष्टि कि एक्सटेंडेड-सपोर्ट व्यवस्था पहले से सक्रिय है।
सिर्फ़ तारीख नहीं, संगतता के आधार पर अपग्रेड की योजना बनाएँ
kubeadm इस्तेमाल करने वाले सेल्फ-मैनेज्ड Kubernetes क्लस्टर के लिए 1.34 से 1.35 पर जाना सपोर्टेड अगला माइनर-वर्शन कदम है। 1.34 से सीधे 1.36 या 1.37 पर छलांग लगाना kubeadm अपग्रेड प्रक्रिया में सपोर्टेड नहीं है।
मैनेज्ड सर्विस अपग्रेड के कुछ हिस्से स्वचालित कर सकती हैं, लेकिन उनके सपोर्टेड रास्ते और पूर्व-शर्तें अलग से माननी होती हैं।
Kubernetes एक वर्शन-स्क्यू नीति भी रखता है, जो कंट्रोल-प्लेन कंपोनेंट, kubelet और अन्य क्लस्टर सर्विस के वर्शन तय करती है।
kubelet उस API सर्वर से नया नहीं होना चाहिए जिससे वह संवाद करता है। मौजूदा नीति के तहत वह आमतौर पर तीन माइनर वर्शन तक पुराना हो सकता है, और अलग-अलग API-सर्वर वर्शन वाले क्लस्टर में अतिरिक्त पाबंदियाँ लागू होती हैं।
इससे कंट्रोल-प्लेन और नोड अपग्रेड चरणों में हो सकते हैं, लेकिन इसका मतलब यह नहीं कि हर वर्शन संयोजन सपोर्टेड है।
Kubernetes प्रोजेक्ट सलाह देता है कि पहले मौजूदा माइनर रिलीज़ के सबसे नए पैच पर अपडेट करें, और फिर अगले माइनर रिलीज़ के सबसे नए उपलब्ध पैच को लक्ष्य बनाएँ।
प्रोडक्शन क्लस्टर अपग्रेड करने से पहले, ज़्यादा निर्णायक संगतता जाँचें उन कंपोनेंट की हैं जो Kubernetes API के साथ करीबी तौर पर काम करते हैं।
एडमिशन वेबहुक उन API वर्शन या फ़ील्ड पर निर्भर हो सकते हैं जो रिलीज़ के बीच बदलते हैं। नेटवर्क और स्टोरेज कंपोनेंट को लक्ष्य वर्शन सपोर्ट करना होगा। ऑपरेटर, कस्टम रिसोर्स डेफ़िनिशन और क्लस्टर ऐड-ऑन को भी अपग्रेड की ज़रूरत पड़ सकती है।
वर्कलोड पर भी ध्यान चाहिए। PodDisruptionBudgets, रेप्लिका उपलब्धता, शेड्यूलिंग पाबंदियाँ और स्टोरेज व्यवहार तय करते हैं कि नोड को अस्वीकार्य व्यवधान के बिना ड्रेन किया जा सकता है या नहीं।
जो माइनर-वर्शन अपग्रेड API-सर्वर स्तर पर सफल रहे, वह ज़रूरी नहीं कि सफल एप्लिकेशन अपग्रेड हो, अगर अहम वर्कलोड दोबारा शेड्यूल न हों या कोई असंगत ऐड-ऑन काम करना बंद कर दे।
अपग्रेड-तैयारी की व्यावहारिक जाँच
जो टीमें अभी 1.34 पर हैं, उनके लिए यह आकलन एक उचित शुरुआती बिंदु है।
- सपोर्ट: डिस्ट्रीब्यूशन की असली सपोर्ट समय-सीमा पक्की करें, और यह भी कि एक्सटेंडेड सपोर्ट चालू है, उपलब्ध है या अतिरिक्त शुल्क के अधीन है।
- संगतता: लक्ष्य वर्शन के मुकाबले डिप्रिकेटेड API उपयोग, एडमिशन वेबहुक, CRD, कंट्रोलर, CNI और CSI ड्राइवर तथा ज़रूरी क्लस्टर ऐड-ऑन की समीक्षा करें।
- उपलब्धता: वर्कलोड रेप्लिका, PodDisruptionBudgets, नोड क्षमता, ड्रेनिंग व्यवहार और मेंटेनेंस विंडो की पुष्टि करें।
- रिकवरी: संबंधित बैकअप और रिस्टोर प्रक्रियाएँ पक्की करें, सेल्फ-मैनेज्ड कंट्रोल प्लेन के लिए etcd रिकवरी समेत, और डाउनग्रेड या रोलबैक पर प्रोवाइडर की सीमाएँ समझें।
- सत्यापन: अपग्रेड को किसी प्रतिनिधि नॉन-प्रोडक्शन क्लस्टर या नोड पूल पर परखें, फिर प्रोडक्शन रोलआउट के दौरान वर्कलोड की सेहत, नेटवर्किंग, स्टोरेज और एप्लिकेशन एरर दर पर नज़र रखें।
ये जाँचें माहौल के अनुपात में होनी चाहिए। छोटे डेवलपमेंट क्लस्टर और बहु-रीजन प्रोडक्शन प्लेटफ़ॉर्म को एक जैसी बदलाव प्रक्रिया की ज़रूरत नहीं, लेकिन दोनों के पास एक ज्ञात अपग्रेड रास्ता होना चाहिए।
टीमों को यह भी मानने से बचना चाहिए कि एक्सटेंडेड सपोर्ट का मतलब हर अपग्रेड ज़िम्मेदारी को टालना है। यह प्रोवाइडर की बताई शर्तों के तहत अतिरिक्त समय देता है, किसी खास Kubernetes वर्शन का स्थायी मेंटेनेंस नहीं।
27 अक्टूबर के बाद क्या बदलता है?
अपस्ट्रीम मेंटेनेंस पर निर्भर सेल्फ-मैनेज्ड Kubernetes 1.34 माहौल के लिए, 27 अक्टूबर उस ब्रांच के नियमित फ़िक्स का अंत है। जो संगठन उस पर बने रहते हैं, उन्हें इससे पैदा होने वाला मेंटेनेंस जोखिम स्वीकार करना होगा या खुद संभालना होगा।
EKS, AKS और GKE के लिए, यह समय-सीमा प्रोवाइडर-विशिष्ट जीवनचक्र जाँचने की याद दिलाती है, यह संकेत नहीं कि सभी मैनेज्ड 1.34 क्लस्टर रातों-रात सपोर्ट खो देंगे।
सही फ़ैसला ऑपरेटिंग मॉडल पर निर्भर करता है। जिस संगठन के पास परीक्षित अपग्रेड रास्ता है, उसके लिए अभी किसी सपोर्टेड माइनर वर्शन पर जाना उचित हो सकता है। कोई दूसरा संगठन संगतता का काम पूरा करने और कम जोखिम वाला बदलाव तय करने के लिए औपचारिक रूप से सपोर्टेड विस्तार इस्तेमाल कर सकता है।
जो नहीं होना चाहिए, वह यह है कि क्लस्टर इसलिए पुराने वर्शन पर पड़ा रहे कि वर्कलोड स्वस्थ दिखते हैं और किसी ने पक्का नहीं किया कि उसे बनाए रखने की ज़िम्मेदारी किसकी है।
Kubernetes 1.34 का अपस्ट्रीम जीवनचक्र 27 अक्टूबर 2026 को खत्म होता है। ऑपरेशनल ज़िम्मेदारी यह है कि हर क्लस्टर पर असल में लागू समय-सीमा तय करें और वह कवरेज खत्म होने से पहले सपोर्टेड, परीक्षित अपग्रेड पूरा करें।
और गहराई में
- Kubernetes: Version 1.34 Release Schedule। आधिकारिक रिलीज़ जीवनचक्र, मेंटेनेंस-मोड की तारीख और अपस्ट्रीम एंड-ऑफ़-लाइफ़ की समय-सीमा।
- Kubernetes: Version Skew Policy। API सर्वर, kubelet, कंट्रोलर और अन्य क्लस्टर कंपोनेंट के बीच सपोर्टेड वर्शन संबंध।
- Kubernetes: Upgrading kubeadm Clusters। आधिकारिक सेल्फ-मैनेज्ड अपग्रेड प्रक्रिया और माइनर-वर्शन क्रम की ज़रूरतें।
- Amazon EKS: Kubernetes Version Lifecycle। EKS स्टैंडर्ड और एक्सटेंडेड-सपोर्ट तारीखें, वर्शन नीतियाँ और संबंधित बिलिंग पहलू।
- Microsoft Learn: Supported Kubernetes Versions in AKS। AKS स्टैंडर्ड जीवनचक्र, लॉन्ग-टर्म सपोर्ट और प्लेटफ़ॉर्म-प्रेरित अपग्रेड शेड्यूल।
- Google Cloud: GKE Release Schedule। GKE स्टैंडर्ड और एक्सटेंडेड-सपोर्ट तारीखें, रिलीज़-चैनल उपलब्धता और अपग्रेड शेड्यूलिंग।
इस साइट पर संबंधित लेख
- Ingress-NGINX सेवानिवृत्त हो गया: कुबरनेट्स टीमों को आगे क्या करना चाहिए, सुरक्षा फ़िक्स बंद हो चुके एक और Kubernetes कंपोनेंट के बारे में और बदलाव की योजना कैसे बनाएँ।
- Kubernetes 1.37: अपग्रेड से पहले प्लेटफ़ॉर्म टीमों को समझने चाहिए ये तीन बदलाव, इस लेख में सपोर्टेड ब्रांच के रूप में सूचीबद्ध सबसे नए माइनर रिलीज़ के बारे में।
शोध समीक्षा 26 अक्टूबर 2026। सपोर्ट तारीखें समय-संवेदनशील हैं और प्रकाशन या ऑपरेशनल बदलाव से पहले प्रोवाइडर दस्तावेज़ों से दोबारा जाँची जानी चाहिए। यह लेख जीवनचक्र और अपग्रेड योजना बताता है, प्लेटफ़ॉर्म-विशिष्ट अपग्रेड निर्देशों का विकल्प नहीं है।