ડાઉનટાઇમ વિના કુબરનેટ્સ ક્લસ્ટરને અપગ્રેડ કરવું

તમારા કુબરનેટ્સ ક્લસ્ટર માટે અપગ્રેડ પ્રક્રિયા

અમુક સમયે, કુબરનેટ્સ ક્લસ્ટરનો ઉપયોગ કરતી વખતે, ચાલી રહેલ નોડ્સને અપડેટ કરવાની જરૂર છે. આમાં પેકેજ અપડેટ્સ, કર્નલ અપડેટ્સ, અથવા નવી વર્ચ્યુઅલ મશીન ઈમેજોની જમાવટ શામેલ હોઈ શકે છે. Kubernetes પરિભાષામાં આને કહેવામાં આવે છે "સ્વૈચ્છિક વિક્ષેપ".

આ પોસ્ટ 4-પોસ્ટ શ્રેણીનો ભાગ છે:

1. આ પોસ્ટ.
2. કુબરનેટીસ ક્લસ્ટરમાં પોડ્સનું યોગ્ય રીતે બંધ કરવું
3. જ્યારે પોડ કાઢી નાખવામાં આવે ત્યારે તેને પૂર્ણ કરવામાં વિલંબ થાય છે
4. PodDisruptionBudgets નો ઉપયોગ કરીને કુબરનેટ્સ ક્લસ્ટર ડાઉનટાઇમ કેવી રીતે ટાળવું

(આશરે. નજીકના ભવિષ્યમાં શ્રેણીમાં બાકીના લેખોના અનુવાદની અપેક્ષા)

આ લેખમાં, અમે તમારા ક્લસ્ટરમાં ચાલતા નોડ્સ માટે શૂન્ય ડાઉનટાઇમ હાંસલ કરવા માટે કુબરનેટ્સ પ્રદાન કરે છે તે તમામ સાધનોનું વર્ણન કરીશું.

સમસ્યા વ્યાખ્યાયિત

અમે સૌપ્રથમ નિષ્કપટ અભિગમ અપનાવીશું, સમસ્યાઓ ઓળખીશું અને આ અભિગમના સંભવિત જોખમોનું મૂલ્યાંકન કરીશું, અને સમગ્ર ચક્ર દરમિયાન આપણને આવતી દરેક સમસ્યાઓને ઉકેલવા માટે જ્ઞાનનું નિર્માણ કરીશું. પરિણામ એ એક રૂપરેખાંકન છે જે અમારા શૂન્ય ડાઉનટાઇમ ધ્યેયને હાંસલ કરવા માટે લાઇફસાઇકલ હુક્સ, રેડીનેસ પ્રોબ્સ અને પોડ વિક્ષેપ બજેટનો ઉપયોગ કરે છે.

અમારી મુસાફરી શરૂ કરવા માટે, ચાલો એક નક્કર ઉદાહરણ લઈએ. ચાલો કહીએ કે અમારી પાસે બે નોડ્સનું કુબરનેટ્સ ક્લસ્ટર છે, જેમાં પાછળ સ્થિત બે પોડ્સ સાથે એપ્લિકેશન ચાલી રહી છે. Service:

ચાલો Nginx સાથેના બે પોડ્સ અને અમારા બે Kubernetes ક્લસ્ટર નોડ્સ પર ચાલતી સર્વિસ સાથે શરૂઆત કરીએ.

અમે અમારા ક્લસ્ટરમાં બે વર્કર નોડ્સના કર્નલ વર્ઝનને અપડેટ કરવા માંગીએ છીએ. આપણે આ કેવી રીતે કરીએ? એક સરળ ઉકેલ એ છે કે અપડેટ કરેલ રૂપરેખાંકન સાથે નવા નોડ્સ બુટ કરો અને પછી નવા નોડ્સ શરૂ કરતી વખતે જૂના નોડ્સને બંધ કરો. જ્યારે આ કામ કરશે, ત્યાં આ અભિગમ સાથે થોડી સમસ્યાઓ હશે:

• જ્યારે તમે જૂના ગાંઠો બંધ કરશો, ત્યારે તેમના પર ચાલતા પોડ્સ પણ બંધ થઈ જશે. જો આકર્ષક શટડાઉન માટે શીંગોને સાફ કરવાની જરૂર હોય તો શું? તમે જે વર્ચ્યુઅલાઈઝેશન સિસ્ટમનો ઉપયોગ કરી રહ્યાં છો તે ક્લીનઅપ પ્રક્રિયા પૂર્ણ થવાની રાહ જોઈ શકશે નહીં.
• જો તમે એક જ સમયે તમામ ગાંઠો બંધ કરો તો શું? જ્યારે શીંગો નવા નોડ્સ પર જાય છે ત્યારે તમને યોગ્ય ડાઉનટાઇમ મળશે.

જ્યારે અમે નોડમાં ફેરફાર કરીએ છીએ ત્યારે અમારી કોઈપણ કાર્યકર પ્રક્રિયાઓ ચાલી રહી નથી તેની ખાતરી કરતી વખતે અમને જૂના નોડ્સમાંથી પોડ્સને આકર્ષક રીતે સ્થાનાંતરિત કરવાની રીતની જરૂર છે. અથવા જ્યારે આપણે ક્લસ્ટરનું સંપૂર્ણ રિપ્લેસમેન્ટ કરીએ છીએ, ઉદાહરણ તરીકે (એટલે ​​​​કે, અમે VM છબીઓને બદલીએ છીએ), અમે ચાલી રહેલ એપ્લિકેશનને જૂના નોડ્સમાંથી નવામાં સ્થાનાંતરિત કરવા માંગીએ છીએ. બંને કિસ્સાઓમાં, અમે નવા પોડ્સને જૂના નોડ્સ પર સુનિશ્ચિત થવાથી રોકવા માંગીએ છીએ, અને પછી તેમાંથી તમામ ચાલી રહેલા પોડ્સને બહાર કાઢીએ છીએ. આ લક્ષ્યો હાંસલ કરવા માટે આપણે આદેશનો ઉપયોગ કરી શકીએ છીએ kubectl drain.

નોડમાંથી તમામ શીંગોનું પુનઃવિતરણ

ડ્રેઇન ઑપરેશન તમને નોડમાંથી તમામ શીંગોને ફરીથી વિતરિત કરવાની મંજૂરી આપે છે. ડ્રેઇન એક્ઝેક્યુશન દરમિયાન, નોડને અનશેડ્યુલેબલ તરીકે ચિહ્નિત કરવામાં આવે છે (ધ્વજ NoSchedule). આ તેના પર નવા શીંગો દેખાવાથી અટકાવે છે. પછી ડ્રેઇન નોડમાંથી શીંગો બહાર કાઢવાનું શરૂ કરે છે, સિગ્નલ મોકલીને હાલમાં નોડ પર ચાલી રહેલા કન્ટેનરને બંધ કરે છે. TERM પોડ માં કન્ટેનર.

તેમ છતાં kubectl drain શીંગો બહાર કાઢવાનું એક મહાન કાર્ય કરશે, ત્યાં અન્ય બે પરિબળો છે જે ડ્રેઇન ઓપરેશનને નિષ્ફળ કરી શકે છે:

• તમારી અરજી સબમિશન પર આકર્ષક રીતે સમાપ્ત કરવામાં સક્ષમ હોવી જોઈએ TERM સંકેત જ્યારે શીંગો બહાર કાઢવામાં આવે છે, ત્યારે કુબરનેટ્સ સિગ્નલ મોકલે છે TERM કન્ટેનર અને તેમને ચોક્કસ સમય માટે રોકવાની રાહ જુએ છે, તે પછી, જો તેઓ બંધ ન થયા હોય, તો તે તેમને બળજબરીથી સમાપ્ત કરે છે. કોઈ પણ સંજોગોમાં, જો તમારું કન્ટેનર યોગ્ય રીતે સિગ્નલને સમજી શકતું નથી, તો પણ તમે પોડ્સને ખોટી રીતે ઓલવી શકો છો જો તેઓ હાલમાં ચાલી રહ્યા હોય (ઉદાહરણ તરીકે, ડેટાબેઝ વ્યવહાર ચાલુ છે).
• તમે તમારી એપ્લિકેશન ધરાવતી બધી શીંગો ગુમાવો છો. જ્યારે નવા નોડ્સ પર નવા કન્ટેનર લોંચ કરવામાં આવે ત્યારે તે ઉપલબ્ધ ન હોઈ શકે, અથવા જો તમારી પોડ્સ નિયંત્રકો વિના જમાવવામાં આવે, તો તે બિલકુલ પુનઃપ્રારંભ થઈ શકશે નહીં.

ડાઉનટાઇમ ટાળવું

સ્વૈચ્છિક વિક્ષેપમાંથી ડાઉનટાઇમ ઘટાડવા માટે, જેમ કે નોડ પર ડ્રેઇન ઓપરેશનથી, કુબરનેટ્સ નીચેના નિષ્ફળતા સંભાળવાના વિકલ્પો પૂરા પાડે છે:

• આકર્ષક સમાપ્તિ
• જીવનચક્ર હુક્સ
• PodDisruptionBudges

બાકીની શ્રેણીમાં, અમે સ્થાનાંતરિત પોડ્સની અસરને ઘટાડવા માટે આ કુબરનેટ્સ સુવિધાઓનો ઉપયોગ કરીશું. મુખ્ય વિચારને અનુસરવાનું સરળ બનાવવા માટે, અમે નીચેના સંસાધન ગોઠવણી સાથે ઉપરના અમારા ઉદાહરણનો ઉપયોગ કરીશું:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

આ રૂપરેખાંકન એક ન્યૂનતમ ઉદાહરણ છે Deployment, જે ક્લસ્ટરમાં nginx પોડ્સનું સંચાલન કરે છે. વધુમાં, રૂપરેખાંકન સંસાધનનું વર્ણન કરે છે Service, જેનો ઉપયોગ ક્લસ્ટરમાં nginx પોડ્સને ઍક્સેસ કરવા માટે થઈ શકે છે.

આખા ચક્ર દરમિયાન, અમે આ ગોઠવણીને પુનરાવર્તિત રીતે વિસ્તૃત કરીશું જેથી કરીને તેમાં ડાઉનટાઇમ ઘટાડવા માટે કુબરનેટ્સ દ્વારા પૂરી પાડવામાં આવતી તમામ ક્ષમતાઓનો સમાવેશ થાય.

AWS અને તેના પછીના શૂન્ય ડાઉનટાઇમ માટે Kubernetes ક્લસ્ટર અપડેટ્સના સંપૂર્ણ અમલમાં મૂકાયેલા અને પરીક્ષણ કરેલ સંસ્કરણ માટે, મુલાકાત લો Gruntwork.io.

અમારા બ્લોગ પર અન્ય લેખો પણ વાંચો:

• શૂન્ય ડાઉનટાઇમ જમાવટ અને ડેટાબેસેસ
• કુબરનેટ્સ: સિસ્ટમ રિસોર્સ મેનેજમેન્ટને ગોઠવવું શા માટે એટલું મહત્વપૂર્ણ છે?
• ટેકટન પાઈપલાઈન - કુબરનેટસ-નેટિવ પાઈપલાઈન
• Nginx માટે ડાયનેમિક મોડ્યુલ બનાવવું
• હાશિકોર્પ કોન્સ્યુલના કુબરનેટ્સ ઓથોરાઇઝેશનનો પરિચય
• અધિકૃતતા સાથે ક્લિકહાઉસમાંથી અધિકૃતતા વિના ક્લિકહાઉસમાં સ્થાનાંતરણ શું તરફ દોરી ગયું?

સોર્સ: www.habr.com