Google Cloud ने घोषणा की है कि इसकी GKE सेवा अब 'जनरली-अवेलेबल' (generally-available) टू-स्टेप कंट्रोल-प्लेन अपग्रेड प्रदान करती है, जिससे ग्राहक सॉफ्टवेयर बाइनरी अपग्रेड को डेटा-फॉर्मेट माइग्रेशन से अलग कर सकते हैं और माइनर वर्जन बदलावों के दौरान रोलबैक विंडो को खुला रख सकते हैं।

GKE को एक सुरक्षित रास्ते की आवश्यकता क्यों थी

Kubernetes कंट्रोल प्लेन को एक माइनर वर्जन से अगले वर्जन पर अपग्रेड करने में हमेशा जोखिम रहा है। 1.33 से 1.34 पर जाना न केवल बाइनरी को बदलता है बल्कि अंतर्निहित डेटा स्ट्रक्चर्स को भी फिर से लिखता है। यदि नए वर्जन में कोई बग है, तो क्लस्टर को आसानी से वापस (revert) नहीं किया जा सकता; प्रशासकों को पुराने डेटाबेस स्नैपशॉट को रीस्टोर करना होगा या पूरे क्लस्टर को फिर से बनाना होगा, जो एक समय लेने वाली और त्रुटि-प्रवण प्रक्रिया है।

टू-स्टेप अपग्रेड कैसे काम करता है

नया फ्लो अपग्रेड को दो अलग-अलग चरणों में विभाजित करता है:

  • स्टेप 1 – बाइनरी अपग्रेड (emulated mode)। GKE पुराने डेटा फॉर्मेट को सुरक्षित रखते हुए कंट्रोल-प्लेन बाइनरी को टारगेट वर्जन में बदल देता है। चूंकि कोई नया डेटा स्ट्रक्चर नहीं लिखा जाता है, इसलिए इस चरण के दौरान क्लस्टर रोलबैक-सुरक्षित रहता है।
  • स्टेप 2 – फाइनलाइजेशन (Finalization)। एक कॉन्फ़िगर करने योग्य प्रतीक्षा अवधि के बाद, GKE संग्रहीत डेटा को नए फॉर्मेट में बदल देता है। एक बार यह कन्वर्जन पूरा हो जाने के बाद, रोलबैक करने के लिए उसी स्नैपशॉट-रीस्टोर प्रयास की आवश्यकता होगी जिससे बचने के लिए टू-स्टेप प्रक्रिया बनाई गई थी।

यह अलगाव एक "सोक विंडो" (soak window) बनाता है जहाँ ऑपरेटर्स अपरिवर्तनीय डेटा माइग्रेशन को लागू किए बिना प्रोडक्शन में अपग्रेड किए गए बाइनरी का निरीक्षण कर सकते हैं।

व्यवहार में सोक विंडो (soak window)

GKE सोक अवधि के दौरान प्रमुख हेल्थ मेट्रिक्स—API लेटेंसी, एरर रेट और पॉड हेल्थ की स्वचालित रूप से निगरानी करता है। यदि सेवा किसी विसंगति (anomaly) का पता लगाती है, तो यह रोलआउट को रोक देती है, जिससे क्लस्टर बाइनरी-ओनली स्थिति में रहता है जहाँ रोलबैक अभी भी संभव है। Google इस पैटर्न का पालन करने वाले अपग्रेड के लिए 99.999% सफलता दर का हवाला देता है।

उन क्लस्टर्स के लिए जो GKE के ऑटो-अपग्रेड फीचर का उपयोग करते हैं, प्लेटफॉर्म बिना किसी मैन्युअल हस्तक्षेप के पूरी टू-स्टेप सीक्वेंस को व्यवस्थित (orchestrate) करता है। जो उपयोगकर्ता पूर्ण नियंत्रण पसंद करते हैं, वे Cloud CLI या Terraform के माध्यम से इस प्रक्रिया को शुरू कर सकते हैं।

मैन्युअल टू-स्टेप अपग्रेड चलाना

48-घंटे की सुरक्षा विंडो के साथ एक विशिष्ट मैन्युअल अपग्रेड इस प्रकार दिखता है:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

वर्तमान स्थिति का निरीक्षण करने के लिए:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

यदि सोक के दौरान कोई दोष (defect) सामने आता है, तो एडमिनिस्ट्रेटर बिना डेटा हानि के रोलबैक कमांड जारी कर सकता है और पिछले वर्जन पर वापस जा सकता है। जब क्लस्टर स्थिर साबित होता है, तो complete-control-plane-upgrade कमांड के साथ अपग्रेड को जल्दी पूरा किया जा सकता है।

सीमाएं और आवश्यकताएं

  • यह फीचर वर्जन 1.33 या उसके बाद के GKE क्लस्टर्स पर लागू होता है।
  • एक समय में केवल एक ही माइनर वर्जन को अपग्रेड किया जा सकता है; वर्जन को स्किप करना समर्थित नहीं है।
  • टू-स्टेप प्रक्रिया के दौरान Autopilot और रीजनल क्लस्टर्स दोनों उपलब्ध रहते हैं।

संभावित कमियां

बाइनरी और डेटा अपग्रेड को अलग करने से अपग्रेड टाइमलाइन में एक अतिरिक्त चरण जुड़ जाता है, जो उन संगठनों के लिए समग्र विंडो को बढ़ा सकता है जिन्हें तेजी से वर्जन बदलाव की आवश्यकता होती है। सोक अवधि स्वचालित हेल्थ चेक पर भी निर्भर करती है; जो टीमें अत्यधिक कस्टमाइज्ड वर्कलोड चलाती हैं, उन्हें एज-केस रिग्रेशन (edge-case regressions) को पकड़ने के लिए GKE की मॉनिटरिंग के साथ अपने स्वयं के ऑब्जर्वेबिलिटी टूलिंग (observability tooling) की आवश्यकता हो सकती है।

आगे क्या देखने की उम्मीद करें

Google ने मेजर वर्जन अपग्रेड तक टू-स्टेप मॉडल का विस्तार करने के लिए कोई रोडमैप साझा नहीं किया है, जिसमें कई मामलों में अभी भी पूर्ण क्लस्टर पुनर्संरचना (recreation) की आवश्यकता होती है। ऑब्जर्वर्स नोड-पूल अपग्रेड के लिए इसी तरह के सेफ्टी नेट और किसी भी थर्ड-पार्टी CI/CD पाइपलाइन के साथ एकीकरण (integration) की घोषणाओं पर नज़र रखेंगे जो सोक-विंडो चेक को ऑटोमेट कर सके।

निष्कर्ष (Takeaway): बाइनरी अपग्रेड को डेटा माइग्रेशन से अलग करके, GKE प्लेटफॉर्म इंजीनियरों को माइनर वर्जन बदलावों के लिए एक व्यावहारिक रोलबैक विंडो देता है, जिससे डाउनटाइम को न्यूनतम रखते हुए क्लस्टर रखरखाव की परिचालन लागत (operational cost) कम हो जाती है।