ProHoster > Blogs > Administrācija > Kubernetes klastera jaunināŔana bez dīkstāves

Kubernetes klastera jaunināŔana bez dīkstāves

Kubernetes klastera jaunināŔana bez dīkstāves

JaunināŔanas process jūsu Kubernetes klasterim

Kādā brÄ«dÄ«, izmantojot Kubernetes klasteru, ir jāatjaunina darbojoÅ”ie mezgli. Tas var ietvert pakotņu atjauninājumus, kodola atjauninājumus vai jaunu virtuālās maŔīnas attēlu izvietoÅ”anu. Kubernetes terminoloÄ£ijā to sauc "BrÄ«vprātÄ«gs traucējums".

Šī ziņa ir daļa no 4 ziņu sērijas:

  1. Å is ieraksts.
  2. Pareiza pākstu izslēgÅ”ana Kubernetes klasterÄ«
  3. Aizkavēta aplikuma pārtraukÅ”ana, kad tā tiek dzēsta
  4. Kā izvairīties no Kubernetes klastera dīkstāves, izmantojot PodDisruptionBudgets

(aptuveni. Tuvākajā laikā sagaidiet pārējo sērijas rakstu tulkojumus)

Å ajā rakstā mēs aprakstÄ«sim visus rÄ«kus, ko nodroÅ”ina Kubernetes, lai panāktu nulles dÄ«kstāvi jÅ«su klasterÄ« strādājoÅ”ajiem mezgliem.

Problēmas definÄ“Å”ana

Sākumā mēs izmantosim naivu pieeju, identificēsim problēmas un novērtēsim Ŕīs pieejas iespējamos riskus, kā arÄ« veidosim zināŔanas, lai atrisinātu katru problēmu, ar kuru saskaramies visa cikla laikā. Rezultāts ir konfigurācija, kas izmanto dzÄ«ves cikla āķus, gatavÄ«bas zondes un Pod traucējumu budžetus, lai sasniegtu mÅ«su nulles dÄ«kstāves mērÄ·i.

Lai sāktu savu ceļojumu, ņemsim konkrētu piemēru. Pieņemsim, ka mums ir divu mezglu Kubernetes klasteris, kurā darbojas lietojumprogramma ar diviem podiem, kas atrodas aiz Service:

Kubernetes klastera jaunināŔana bez dīkstāves

Sāksim ar diviem podiem ar Nginx un Service, kas darbojas mūsu divos Kubernetes klastera mezglos.

Mēs vēlamies atjaunināt divu mÅ«su klastera darbinieku mezglu kodola versiju. Kā mēs to darām? VienkārÅ”s risinājums bÅ«tu palaist jaunus mezglus ar atjaunināto konfigurāciju un pēc tam izslēgt vecos mezglus, startējot jaunos. Lai gan tas darbosies, ar Å”o pieeju bÅ«s dažas problēmas:

  • Izslēdzot vecos mezglus, tiks izslēgti arÄ« tajos strādājoÅ”ie podi. Ko darÄ«t, ja pākstis ir jāiztÄ«ra, lai to graciozai izslēgtu? JÅ«su izmantotā virtualizācijas sistēma var nesagaidÄ«t, lÄ«dz tiks pabeigts tÄ«rÄ«Å”anas process.
  • Ko darÄ«t, ja vienlaikus izslēdzat visus mezglus? JÅ«s iegÅ«sit pienācÄ«gu dÄ«kstāvi, kamēr pāksti pārvietosies uz jauniem mezgliem.

Mums ir nepiecieÅ”ams veids, kā graciozi migrēt aplikumus no veciem mezgliem, vienlaikus nodroÅ”inot, ka neviens no mÅ«su darbinieku procesiem nedarbojas, kamēr veicam izmaiņas mezglā. Vai arÄ« veicot pilnÄ«gu klastera nomaiņu, kā tas ir piemērā (tas ir, mēs aizstājam VM attēlus), mēs vēlamies pārsÅ«tÄ«t darbojoŔās lietojumprogrammas no vecajiem mezgliem uz jauniem. Abos gadÄ«jumos mēs vēlamies neļaut jauniem podiem ieplānot plānoÅ”anu vecajos mezglos un pēc tam izlikt no tiem visus darbojoÅ”os blokus. Lai sasniegtu Å”os mērÄ·us, mēs varam izmantot komandu kubectl drain.

Visu pākstu pārdalīŔana no mezgla

Drenāžas darbÄ«ba ļauj pārdalÄ«t visas pākstis no mezgla. Drenāžas izpildes laikā mezgls tiek atzÄ«mēts kā neplānojams (karogs NoSchedule). Tas neļauj uz tā parādÄ«ties jaunas pākstis. Pēc tam drenāža sāk izspiest pākstis no mezgla, izslēdz konteinerus, kas paÅ”laik darbojas mezglā, nosÅ«tot signālu TERM konteineri podiņā.

Kaut gan kubectl drain veiks lielisku darbu, izliekot pākstis, ir divi citi faktori, kas var izraisīt kanalizācijas darbības neveiksmi:

  • JÅ«su pieteikumam jābÅ«t iespējai pēc iesniegÅ”anas graciozi pārtraukt TERM signāls. Kad pākstis tiek izliktas, Kubernetes sÅ«ta signālu TERM konteinerus un gaida to apstāŔanos uz noteiktu laiku, pēc kura, ja tie nav apstājuÅ”ies, tos pārtrauc piespiedu kārtā. Jebkurā gadÄ«jumā, ja jÅ«su konteiners neuztver signālu pareizi, jÅ«s joprojām varat nepareizi nodzēst aplikumus, ja tie paÅ”laik darbojas (piemēram, notiek datu bāzes transakcija).
  • JÅ«s zaudējat visas pākstis, kurās ir jÅ«su pieteikums. Tas var nebÅ«t pieejams, kad jaunos mezglos tiek palaisti jauni konteineri vai, ja jÅ«su podi ir izvietoti bez kontrolleriem, tie var netikt restartēti vispār.

IzvairīŔanās no dīkstāves

Lai samazinātu dÄ«kstāves laiku, ko izraisa brÄ«vprātÄ«gi traucējumi, piemēram, mezgla iztukÅ”oÅ”anas darbÄ«ba, Kubernetes nodroÅ”ina Ŕādas kļūdu apstrādes iespējas:

Pārējās sērijas daļās mēs izmantosim Ŕīs Kubernetes funkcijas, lai mazinātu pod migrācijas ietekmi. Lai bÅ«tu vieglāk ievērot galveno ideju, mēs izmantosim iepriekÅ” minēto piemēru ar Ŕādu resursu konfigurāciju:

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

Šī konfigurācija ir minimāls piemērs Deployment, kas pārvalda nginx pākstis klasterī. Turklāt konfigurācijā ir aprakstīts resurss Service, ko var izmantot, lai piekļūtu nginx pākstīm klasterī.

Visa cikla laikā mēs iteratÄ«vi paplaÅ”ināsim Å”o konfigurāciju, lai tā galu galā ietvertu visas Kubernetes nodroÅ”inātās iespējas, lai samazinātu dÄ«kstāves laiku.

Lai iegūtu pilnībā ieviestu un pārbaudītu Kubernetes klastera atjauninājumu versiju, lai bez dīkstāves AWS un ne tikai, apmeklējiet vietni Gruntwork.io.

Lasiet arī citus rakstus mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru