Google Cloud એ જાહેરાત કરી છે કે તેની GKE સેવા હવે સામાન્ય રીતે ઉપલબ્ધ (generally-available) બે-તબક્કાના કંટ્રોલ-પ્લેન અપગ્રેડ્સ ઓફર કરે છે, જે ગ્રાહકોને સોફ્ટવેર બાઈનરી અપગ્રેડને ડેટા-ફોર્મેટ માઈગ્રેશનથી અલગ રાખવાની અને માઇનર વર્ઝન ફેરફારો દરમિયાન રોલબેક વિન્ડો ખુલ્લી રાખવાની સુવિધા આપે છે.

GKE ને સુરક્ષિત માર્ગની જરૂર કેમ હતી

Kubernetes કંટ્રોલ પ્લેનને એક માઇનર વર્ઝનથી બીજા પર અપગ્રેડ કરવામાં હંમેશા જોખમ રહેલું છે. 1.33 થી 1.34 પરનું સંક્રમણ માત્ર બાઈનરી જ નથી બદલતું પરંતુ તેના અંતર્ગત ડેટા સ્ટ્રક્ચર્સને પણ ફરીથી લખે છે. જો નવા વર્ઝનમાં કોઈ બગ (bug) હોય, તો ક્લસ્ટરને સરળતાથી પૂર્વવત્ (revert) કરી શકાતું નથી; એડમિનિસ્ટ્રેટરોએ જૂના ડેટાબેઝ સ્નેપશોટ્સને રિસ્ટોર કરવા પડે અથવા આખું ક્લસ્ટર ફરીથી બનાવવું પડે, જે સમય માંગી લે તેવી અને ભૂલ-ભરેલી પ્રક્રિયા છે.

બે-તબક્કાનું અપગ્રેડ કેવી રીતે કામ કરે છે

નવો ફ્લો અપગ્રેડને બે અલગ તબક્કાઓમાં વિભાજિત કરે છે:

  • સ્ટેપ 1 – બાઈનરી અપગ્રેડ (emulated mode). GKE જૂના ડેટા ફોર્મેટને જાળવી રાખીને કંટ્રોલ-પ્લેન બાઈનરીઝને ટાર્ગેટ વર્ઝનમાં બદલે છે. કારણ કે કોઈ નવા ડેટા સ્ટ્રક્ચર્સ લખવામાં આવતા નથી, તેથી આ તબક્કા દરમિયાન ક્લસ્ટર રોલબેક-સેફ (rollback-safe) રહે છે.
  • સ્ટેપ 2 – ફાઇનલાઇઝેશન (Finalization). એક કોન્ફિગરેબલ વેઇટિંગ પીરિયડ પછી, GKE સંગ્રહિત ડેટાને નવા ફોર્મેટમાં રૂપાંતરિત કરે છે. એકવાર આ રૂપાંતર પૂર્ણ થઈ જાય પછી, રોલબેક કરવા માટે એ જ સ્નેપશોટ-રિસ્ટોર પ્રયાસોની જરૂર પડશે જે બે-તબક્કાની પ્રક્રિયાને ટાળવા માટે બનાવવામાં આવી હતી.

આ અલગતા એક “soak window” બનાવે છે જ્યાં ઓપરેટરો ડેટા માઈગ્રેશનના કાયમી ફેરફાર વગર પ્રોડક્શનમાં અપગ્રેડ કરેલી બાઈનરીઝનું નિરીક્ષણ કરી શકે છે.

પ્રેક્ટિકલમાં soak window

GKE soak પીરિયડ દરમિયાન મુખ્ય હેલ્થ મેટ્રિક્સ—API લેટન્સી, એરર રેટ્સ અને પોડ હેલ્થનું આપમેળે મોનિટરિંગ કરે છે. જો સર્વિસમાં કોઈ અસાધારણતા જણાય, તો તે રોલઆઉટ અટકાવી દે છે, જેનાથી ક્લસ્ટર બાઈનરી-ઓન્લી સ્ટેટમાં રહે છે જ્યાં રોલબેક હજુ પણ શક્ય છે. Google આ પેટર્ન અનુસરતા અપગ્રેડ્સ માટે 99.999% સફળતા દરનો ઉલ્લેખ કરે છે.

જે ક્લસ્ટર્સ GKE ના auto-upgrade ફીચરનો ઉપયોગ કરે છે, તેના માટે પ્લેટફોર્મ મેન્યુઅલ હસ્તક્ષેપ વગર આખી બે-તબક્કાની પ્રક્રિયાનું સંચાલન કરે છે. જે વપરાશકર્તાઓ સંપૂર્ણ નિયંત્રણ પસંદ કરે છે તેઓ 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)"

જો soak દરમિયાન કોઈ ખામી જણાય, તો એડમિનિસ્ટ્રેટર ડેટા લોસ વગર રોલબેક કમાન્ડ આપી શકે છે અને અગાઉના વર્ઝનમાં પાછા ફરી શકે છે. જ્યારે ક્લસ્ટર સ્થિર સાબિત થાય, ત્યારે complete-control-plane-upgrade કમાન્ડ સાથે અપગ્રેડ વહેલા પૂર્ણ કરી શકાય છે.

મર્યાદાઓ અને જરૂરિયાતો

  • આ ફીચર વર્ઝન 1.33 અથવા તેનાથી પછીના GKE ક્લસ્ટર્સ માટે લાગુ પડે છે.
  • એક સમયે માત્ર એક જ માઇનર વર્ઝન અપગ્રેડ કરી શકાય છે; વર્ઝન સ્કીપ કરવાની સુવિધા ઉપલબ્ધ નથી.
  • બે-તબક્કાની પ્રક્રિયા દરમિયાન Autopilot અને રીજનલ ક્લસ્ટર્સ બંને ઉપલબ્ધ રહે છે.

સંભવિત ગેરફાયદા

બાઈનરી અને ડેટા અપગ્રેડને અલગ કરવાથી અપગ્રેડ ટાઈમલાઈનમાં એક વધારાનું સ્ટેપ ઉમેરાય છે, જે ઝડપી વર્ઝન ફેરફારોની જરૂર હોય તેવી સંસ્થાઓ માટે સમગ્ર વિન્ડો લંબાવી શકે છે. soak પીરિયડ ઓટોમેટેડ હેલ્થ ચેક્સ પર પણ આધાર રાખે છે; જે ટીમો અત્યંત કસ્ટમાઇઝ્ડ વર્કલોડ ચલાવે છે, તેમણે એજ-કેસ રિગ્રેસન્સ (edge-case regressions) પકડવા માટે GKE ના મોનિટરિંગમાં પોતાના ઓબ્ઝર્વેબિલિટી ટૂલ્સનો ઉપયોગ કરવાની જરૂર પડી શકે છે.

આગળ શું જોવું

Google એ મેજર વર્ઝન અપગ્રેડ્સ માટે બે-તબક્કાના મોડલને વિસ્તારવા માટે કોઈ રોડમેપ જાહેર કર્યો નથી, જેમાં ઘણા કિસ્સાઓમાં હજુ પણ આખા ક્લસ્ટરના પુનઃનિર્માણની જરૂર પડે છે. નિરીક્ષકો નોડ-પૂલ અપગ્રેડ્સ માટે સમાન સેફ્ટી નેટ્સ અને થર્ડ-પાર્ટી CI/CD પાઇપલાઇન્સ સાથેના કોઈપણ ઇન્ટિગ્રેશન વિશેની જાહેરાતોની રાહ જોશે જે soak-window ચેક્સને ઓટોમેટ કરી શકે.

મુખ્ય વાત (Takeaway): બાઈનરી અપગ્રેડ્સને ડેટા માઈગ્રેશનથી અલગ કરીને, GKE પ્લેટફોર્મ એન્જિનિયરોને માઇનર વર્ઝન ફેરફારો માટે વ્યવહારુ રોલબેક વિન્ડો આપે છે, જેનાથી ડાઉનટાઇમ ન્યૂનતમ રાખીને ક્લસ્ટર મેન્ટેનન્સનો ઓપરેશનલ ખર્ચ ઘટે છે.