Kubernetes կլաստերի արդիականացում առանց ընդհատման

Ձեր Kubernetes կլաստերի թարմացման գործընթացը

Ինչ-որ պահի, երբ օգտագործվում է Kubernetes կլաստերը, անհրաժեշտություն է առաջանում թարմացնել գործող հանգույցները: Սա կարող է ներառել փաթեթի թարմացումներ, միջուկի թարմացումներ կամ նոր վիրտուալ մեքենայի պատկերների տեղակայում: Kubernetes տերմինաբանության մեջ սա կոչվում է «Կամավոր խանգարում»..

Այս գրառումը 4 գրառումներից բաղկացած շարքի մի մասն է.

1. Այս գրառումը.
2. Կուբերնետես կլաստերում պատիճների ճիշտ անջատում
3. Փոդի հետաձգված ավարտը, երբ այն ջնջվում է
4. Ինչպես խուսափել Kubernetes կլաստերի անգործությունից՝ օգտագործելով PodDisruptionBudgets-ը

(մոտավորապես մոտ ապագայում սպասեք շարքի մնացած հոդվածների թարգմանություններին)

Այս հոդվածում մենք նկարագրելու ենք բոլոր այն գործիքները, որոնք Kubernetes-ը տրամադրում է ձեր կլաստերում աշխատող հանգույցների համար զրոյական պարապուրդի հասնելու համար:

Խնդրի սահմանում

Մենք սկզբում միամիտ մոտեցում կցուցաբերենք, կբացահայտենք խնդիրները և կգնահատենք այս մոտեցման պոտենցիալ ռիսկերը և կձևավորենք գիտելիքներ՝ լուծելու այն խնդիրները, որոնց մենք հանդիպում ենք ողջ ցիկլի ընթացքում: Արդյունքը կոնֆիգուրացիան է, որն օգտագործում է կյանքի ցիկլի կեռիկներ, պատրաստականության զոնդեր և Pod-ի խափանման բյուջեներ՝ հասնելու մեր զրոյական ժամանակի նպատակին:

Մեր ճանապարհորդությունը սկսելու համար բերենք կոնկրետ օրինակ։ Ենթադրենք, մենք ունենք երկու հանգույցներից բաղկացած Kubernetes կլաստեր, որում հավելվածն աշխատում է ետևում գտնվող երկու փոդով: Service:

Եկեք սկսենք երկու pods-ով Nginx-ով և Service-ով, որոնք աշխատում են մեր երկու Kubernetes կլաստերային հանգույցների վրա:

Մենք ցանկանում ենք թարմացնել մեր կլաստերի երկու աշխատող հանգույցների միջուկի տարբերակը: Ինչպե՞ս ենք մենք դա անում: Պարզ լուծում կարող է լինել նոր հանգույցների բեռնումը թարմացված կազմաձևով, այնուհետև փակել հին հանգույցները՝ նորերը գործարկելիս: Թեև սա կաշխատի, այս մոտեցման հետ կապված մի քանի խնդիրներ կլինեն.

• Երբ դուք անջատեք հին հանգույցները, դրանց վրա աշխատող բլոկները նույնպես կանջատվեն: Իսկ եթե պատյանները պետք է մաքրել նրբագեղ անջատման համար: Վիրտուալացման համակարգը, որն օգտագործում եք, կարող է չսպասել մաքրման գործընթացի ավարտին:
• Իսկ եթե անջատեք բոլոր հանգույցները միաժամանակ: Դուք կստանաք արժանապատիվ պարապուրդ, մինչ պատյանները տեղափոխվում են նոր հանգույցներ:

Մեզ պետք է մի միջոց, որը նրբագեղ կերպով տեղափոխում է բլոկները հին հանգույցներից՝ միաժամանակ ապահովելով, որ մեր աշխատող գործընթացներից ոչ մեկը չի աշխատում, մինչ մենք փոփոխություններ ենք կատարում հանգույցում: Կամ երբ մենք կատարում ենք կլաստերի ամբողջական փոխարինում, ինչպես օրինակում (այսինքն, մենք փոխարինում ենք VM պատկերները), մենք ցանկանում ենք գործող հավելվածները հին հանգույցներից տեղափոխել նորերը։ Երկու դեպքում էլ մենք ցանկանում ենք կանխել նոր բլոկների պլանավորումը հին հանգույցների վրա, այնուհետև հեռացնել բոլոր գործող բլոկները դրանցից: Այս նպատակներին հասնելու համար մենք կարող ենք օգտագործել հրամանը kubectl drain.

Բոլոր պատյանների վերաբաշխում հանգույցից

Դրենաժային գործողությունը թույլ է տալիս վերաբաշխել բոլոր պատյանները հանգույցից: Դրենաժի կատարման ընթացքում հանգույցը նշվում է որպես չպլանավորված (դրոշ NoSchedule) Սա թույլ չի տալիս նոր պատիճներ հայտնվել դրա վրա: Այնուհետև արտահոսքը սկսում է հանգույցներից դուրս հանել պատյանները, անջատում է բեռնարկղերը, որոնք ներկայումս աշխատում են հանգույցի վրա՝ ազդանշան ուղարկելով: TERM տարաներ պատիճում:

Չնայած որ kubectl drain Հիանալի աշխատանք կկատարի պատիճները հեռացնելու համար, կան ևս երկու գործոն, որոնք կարող են հանգեցնել ջրահեռացման աշխատանքի ձախողմանը.

• Ձեր դիմումը պետք է կարողանա նրբանկատորեն դադարեցվել ներկայացնելուց հետո TERM ազդանշան. Երբ պատիճները վտարվում են, Kubernetes-ը ազդանշան է ուղարկում TERM բեռնարկղերը և սպասում է, որ դրանք որոշակի ժամանակ կանգնեն, որից հետո, եթե չեն կանգնել, հարկադրաբար դադարեցնում է դրանք։ Ամեն դեպքում, եթե ձեր բեռնարկղը ճիշտ չի ընկալում ազդանշանը, դուք դեռ կարող եք սխալ մարել պատյանները, եթե դրանք ներկայումս աշխատում են (օրինակ, տվյալների բազայի գործարքն ընթացքի մեջ է):
• Դուք կորցնում եք ձեր հավելվածը պարունակող բոլոր պատյանները: Այն կարող է հասանելի չլինել, երբ նոր բեռնարկղերը գործարկվեն նոր հանգույցների վրա, կամ եթե ձեր պատիճները տեղադրվեն առանց կարգավորիչների, դրանք կարող են ընդհանրապես չվերագործարկվել:

Խուսափելով պարապուրդից

Որպեսզի նվազագույնի հասցվի կամավոր խափանումներից առաջացած խափանումները, օրինակ՝ հանգույցի վրա ջրահեռացման գործողությունից, Kubernetes-ը տրամադրում է ձախողումների հետ կապված հետևյալ տարբերակները.

• Նրբագեղ դադարեցում
• Կյանքի ցիկլի կեռիկներ
• PodDisruptionBudgets

Շարքի մնացած մասում մենք կօգտագործենք Kubernetes-ի այս հնարավորությունները՝ մեղմելու գաղթական բլոկների ազդեցությունը: Հիմնական գաղափարին հետևելը հեշտացնելու համար մենք կօգտագործենք վերը նշված մեր օրինակը հետևյալ ռեսուրսի կազմաձևով.

---
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 pods կլաստերում: Բացի այդ, կոնֆիգուրացիան նկարագրում է ռեսուրսը Service, որը կարող է օգտագործվել կլաստերում nginx pods մուտք գործելու համար:

Ողջ ցիկլի ընթացքում մենք պարբերաբար կընդլայնենք այս կազմաձևը, որպեսզի այն ի վերջո ներառի բոլոր հնարավորությունները, որոնք ապահովում է Kubernetes-ը՝ կրճատելու անգործությունը:

Kubernetes-ի կլաստերի թարմացումների լիովին ներդրված և փորձարկված տարբերակի համար AWS-ում և դրանից դուրս զրոյական խափանումների համար այցելեք Gruntwork.io.

Կարդացեք նաև մեր բլոգի այլ հոդվածներ.

• Զրոյական պարապուրդի տեղակայում և տվյալների բազաներ
• Kubernetes. ինչու՞ է այդքան կարևոր ստեղծել համակարգի ռեսուրսների կառավարումը:
• Tekton Pipeline - Kubernetes-ի հայրենի խողովակաշարեր
• Nginx-ի համար դինամիկ մոդուլների կառուցում
• Ներածություն Hashicorp հյուպատոսի Kubernetes թույլտվությանը
• Ինչի՞ հանգեցրեց միգրացիան ClickHouse-ից առանց թույլտվության դեպի ClickHouse թույլտվությամբ:

Source: www.habr.com