„Kubernetes“ klasterio atnaujinimas be prastovos

„Kubernetes“ klasterio naujovinimo procesas

Tam tikru momentu, naudojant Kubernetes klasterį, reikia atnaujinti veikiančius mazgus. Tai gali apimti paketo naujinimus, branduolio naujinimus arba naujų virtualios mašinos vaizdų diegimą. Kubernetes terminologijoje tai vadinama "Savanoriškas sutrikimas".

Šis įrašas yra 4 įrašų serijos dalis:

1. Šis įrašas.
2. Teisingas ankščių išjungimas Kubernetes klasteryje
3. Atidėtas ankšties nutraukimas, kai jis ištrintas
4. Kaip išvengti „Kubernetes“ klasterio prastovos naudojant „PodDisruptionBudgets“.

(apytiksliai. Artimiausiu metu tikimasi likusių serijos straipsnių vertimų)

Šiame straipsnyje apibūdinsime visus įrankius, kuriuos „Kubernetes“ teikia, kad jūsų klasteryje veikiantys mazgai nebūtų prastovos.

Problemos apibrėžimas

Iš pradžių laikysimės naivaus požiūrio, nustatysime problemas ir įvertinsime galimą šio požiūrio riziką bei kaupsime žinias, kad išspręstume kiekvieną problemą, su kuria susiduriame viso ciklo metu. Rezultatas yra konfigūracija, kurioje naudojami gyvavimo ciklo kabliukai, parengties zondai ir „Pod“ trikdžių biudžetai, kad būtų pasiektas nulinės prastovos tikslas.

Norėdami pradėti savo kelionę, paimkime konkretų pavyzdį. Tarkime, kad turime dviejų mazgų „Kubernetes“ klasterį, kuriame veikia programa su dviem blokais, esančiais už Service:

Pradėkime nuo dviejų priedų su „Nginx“ ir „Service“, veikiančiais dviejuose „Kubernetes“ klasterio mazguose.

Norime atnaujinti dviejų mūsų klasterio darbuotojų mazgų branduolio versiją. Kaip tai darome? Paprastas sprendimas būtų paleisti naujus mazgus su atnaujinta konfigūracija ir išjungti senus mazgus paleidžiant naujus. Nors tai veiks, taikant šį metodą bus keletas problemų:

• Kai išjungiate senus mazgus, juose veikiantys ankštys taip pat bus išjungti. Ką daryti, jei ankštys turi būti išvalytos, kad būtų galima grakščiai išjungti? Naudojama virtualizacijos sistema gali nelaukti, kol bus baigtas valymo procesas.
• Ką daryti, jei išjungsite visus mazgus vienu metu? Sulauksite tinkamo prastovos, kol ankštys persikels į naujus mazgus.

Mums reikia būdo, kaip grakščiai perkelti blokus iš senų mazgų, tuo pačiu užtikrinant, kad jokie mūsų darbuotojų procesai nevyktų, kol atliekame mazgo pakeitimus. Arba kai visiškai pakeičiame klasterį, kaip parodyta pavyzdyje (ty pakeičiame VM vaizdus), norime perkelti veikiančias programas iš senų mazgų į naujus. Abiem atvejais norime neleisti naujiems blokams planuoti senus mazgus, o tada iškeldinti iš jų visus veikiančius blokus. Norėdami pasiekti šiuos tikslus, galime naudoti komandą kubectl drain.

Visų ankščių perskirstymas iš mazgo

Išleidimo operacija leidžia perskirstyti visas ankštis iš mazgo. Vykdant nutekėjimą mazgas pažymėtas kaip neplanuojamas (vėliava NoSchedule). Tai neleidžia ant jo atsirasti naujų ankščių. Tada drenažas pradeda išstumti ankštis iš mazgo, išjungia konteinerius, kurie šiuo metu veikia mazge, siųsdamas signalą TERM konteineriai ankštyje.

Nors kubectl drain puikiai iškels ankštis, yra dar du veiksniai, dėl kurių nutekėjimo operacija gali nepavykti:

• Jūsų paraiška turi turėti galimybę maloniai nutraukti po pateikimo TERM signalas. Kai ankštys iškeliamos, Kubernetes siunčia signalą TERM konteinerius ir laukia, kol jie sustos nurodytą laiką, o po to, jei nesustojo, juos nutraukia priverstinai. Bet kokiu atveju, jei jūsų konteineris netinkamai suvokia signalą, vis tiek galite netinkamai užgesinti blokus, jei jie šiuo metu veikia (pavyzdžiui, vyksta duomenų bazės operacija).
• Prarasite visas ankštis, kuriose yra jūsų programa. Jis gali būti nepasiekiamas, kai naujuose mazguose paleidžiami nauji konteineriai arba, jei jūsų blokai yra įdiegti be valdiklių, jie gali iš viso nepaleisti iš naujo.

Išvengti prastovų

Siekdama sumažinti prastovas dėl savanoriško sutrikimo, pvz., mazgo nutekėjimo operacijos, Kubernetes siūlo šias gedimų valdymo parinktis:

• Grakštus nutraukimas
• Gyvenimo ciklo kabliukai
• PodDisruptionBudgets

Likusioje serijos dalyje naudosime šias „Kubernetes“ funkcijas, kad sumažintume ankšties perkėlimo poveikį. Kad būtų lengviau laikytis pagrindinės idėjos, naudosime aukščiau pateiktą pavyzdį su tokia išteklių konfigūracija:

---
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

Ši konfigūracija yra minimalus pavyzdys Deployment, kuri valdo nginx ankštis klasteryje. Be to, konfigūracija aprašo išteklius Service, kurį galima naudoti norint pasiekti nginx ankštis klasteryje.

Per visą ciklą šią konfigūraciją nuolat plečiame, kad galiausiai ji apimtų visas „Kubernetes“ teikiamas galimybes, skirtas sumažinti prastovos laiką.

Norėdami gauti visiškai įdiegtą ir patikrintą Kubernetes klasterio naujinimų versiją, kad AWS ir ne tik prastovų būtų, apsilankykite Gruntwork.io.

Taip pat skaitykite kitus mūsų tinklaraščio straipsnius:

• Nulinis prastovų diegimas ir duomenų bazės
• Kubernetes: kodėl taip svarbu nustatyti sistemos išteklių valdymą?
• „Tekton Pipeline“ – „Kubernetes“ vietiniai vamzdynai
• Dinaminių modulių kūrimas Nginx
• Įvadas į Hashicorp konsulo Kubernetes įgaliojimą
• Ką lėmė perkėlimas iš ClickHouse be leidimo į ClickHouse su leidimu?

Šaltinis: www.habr.com