ProHoster > Blogi > Haldamine > Kubernetese klastri uuendamine ilma seisakuta

Kubernetese klastri uuendamine ilma seisakuta

Kubernetese klastri uuendamine ilma seisakuta

Kubernetese klastri täiendamise protsess

Mingil hetkel tekib Kubernetese klastri kasutamisel vajadus töötavate sõlmede värskendamiseks. See võib hõlmata paketivärskendusi, kerneli värskendusi või uute virtuaalmasina kujutiste juurutamist. Kubernetese terminoloogias nimetatakse seda "Vabatahtlik katkestamine".

See postitus on osa neljast postitusest koosnevast seeriast:

  1. See postitus.
  2. Kaunade õige väljalülitamine Kubernetese klastris
  3. Podi viivitusega lõpetamine selle kustutamisel
  4. Kuidas vältida Kubernetese klastri seisakuid, kasutades PodDisruptionBudgets

(umbes. Sarja ülejäänud artiklite tõlkeid oodatakse lähiajal)

Selles artiklis kirjeldame kõiki tööriistu, mida Kubernetes pakub teie klastris töötavate sõlmede tööseisakute nulli saavutamiseks.

Probleemi määratlemine

Me läheneme alguses naiivselt, tuvastame probleemid ja hindame selle lähenemisviisiga kaasnevaid võimalikke riske ning kogume teadmisi, et lahendada kõik probleemid, millega tsükli jooksul kokku puutume. Tulemuseks on konfiguratsioon, mis kasutab meie nullseisaku eesmärgi saavutamiseks elutsükli konkse, valmisolekusonde ja Podi katkestuste eelarveid.

Teekonna alustamiseks võtame konkreetse näite. Oletame, et meil on kahest sõlmest koosnev Kubernetese klaster, milles töötab rakendus, mille taga on kaks kausta Service:

Kubernetese klastri uuendamine ilma seisakuta

Alustame kahe podiga, kus Nginx ja Service töötavad meie kahes Kubernetese klastri sõlmes.

Soovime värskendada oma klastri kahe töötaja sõlme kerneli versiooni. Kuidas me seda teeme? Lihtne lahendus oleks käivitada uued sõlmed värskendatud konfiguratsiooniga ja seejärel sulgeda vanad sõlmed uute käivitamise ajal. Kuigi see toimib, on selle lähenemisviisiga mõned probleemid:

  • Kui lülitate vanad sõlmed välja, lülitatakse välja ka neil töötavad kaustad. Mis siis, kui kaunad tuleb graatsiliseks väljalülitamiseks tühjendada? Teie kasutatav virtualiseerimissüsteem ei pruugi oodata puhastusprotsessi lõpuleviimist.
  • Mis siis, kui lülitate kõik sõlmed korraga välja? Kui kaunad uutesse sõlmedesse kolivad, saate korraliku seisaku.

Vajame viisi, kuidas sõlmed vanadest sõlmedest graatsiliselt migreerida, tagades samal ajal, et sõlmes muudatuste tegemise ajal ei tööta ükski meie tööprotsess. Või kui me asendame klastri täielikult, nagu näites (st asendame VM-pildid), tahame töötavaid rakendusi vanadest sõlmedest uutesse üle kanda. Mõlemal juhul tahame takistada uute kaustade loomist vanadele sõlmedele ja seejärel kõik töötavad kaustad neist välja tõsta. Nende eesmärkide saavutamiseks saame kasutada käsku kubectl drain.

Kõikide kaunade ümberjagamine sõlmest

Tühjendus võimaldab teil sõlmest kõik kaunad ümber jagada. Tühjendamise ajal märgitakse sõlm planeerimatuks (lipp NoSchedule). See hoiab ära uute kaunade ilmumise sellele. Seejärel hakkab dreen kaunasid sõlmest välja ajama, sulgeb parajasti sõlmes töötavad konteinerid, saates signaali TERM konteinerid kaunas.

kuigi kubectl drain saab kaunade väljatõstmisega suurepäraselt hakkama, on veel kaks tegurit, mis võivad äravoolu ebaõnnestumist põhjustada:

  • Teie taotlus peab saama pärast esitamist sujuvalt lõpetada TERM signaal. Kui kaunad on välja tõstetud, saadab Kubernetes signaali TERM konteinerid ja ootab nende peatumist teatud aja, pärast mida, kui nad pole peatunud, lõpetab see need sunniviisiliselt. Igal juhul, kui teie konteiner signaali õigesti ei taju, võite ikkagi kustutada kaustasid valesti, kui need parasjagu töötavad (nt pooleli on andmebaasi tehing).
  • Kaotate kõik teie rakendust sisaldavad kaunad. See ei pruugi olla saadaval, kui uutes sõlmedes käivitatakse uued konteinerid või kui teie kaustad on juurutatud ilma kontrolleriteta, ei pruugita neid üldse taaskäivitada.

Seisakute vältimine

Tahtlikust katkestusest (nt sõlme tühjendamisest) tingitud seisakuaja minimeerimiseks pakub Kubernetes järgmisi rikete käsitlemise valikuid.

Ülejäänud sarjas kasutame neid Kubernetese funktsioone, et leevendada kaustade migratsiooni mõju. Põhiidee järgimise hõlbustamiseks kasutame ülaltoodud näidet järgmise ressursikonfiguratsiooniga:

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

See konfiguratsioon on minimaalne näide Deployment, mis haldab klastris olevaid nginxi kaunasid. Lisaks kirjeldab konfiguratsioon ressurssi Service, mida saab kasutada nginxi kaunadele juurdepääsuks kobaras.

Kogu tsükli jooksul laiendame seda konfiguratsiooni korduvalt, nii et see hõlmaks lõpuks kõiki Kubernetesi pakutavaid võimalusi seisakuaegade vähendamiseks.

Täielikult juurutatud ja testitud Kubernetese klastri värskenduste versiooni saamiseks AWS-is ja väljaspool seisakuid külastage veebisaiti Gruntwork.io.

Loe ka teisi meie ajaveebi artikleid:

Allikas: www.habr.com

Lisa kommentaar