ProHoster > Блог > Administracija > Nadogradnja Kubernetes klastera bez zastoja

Nadogradnja Kubernetes klastera bez zastoja

Nadogradnja Kubernetes klastera bez zastoja

Proces nadogradnje za vaš Kubernetes klaster

U nekom trenutku, kada koristite Kubernetes klaster, postoji potreba za ažuriranjem pokrenutih čvorova. Ovo može uključivati ​​ažuriranja paketa, ažuriranja kernela ili postavljanje novih slika virtuelne mašine. U Kubernetes terminologiji to se zove "dobrovoljni prekid".

Ovaj post je dio serije od 4 posta:

  1. Ovaj post.
  2. Ispravno gašenje podova u Kubernetes klasteru
  3. Odgođeno prestanak modula kada se obriše
  4. Kako izbjeći zastoje Kubernetes klastera koristeći PodDisruptionBudgets

(cca. Očekujte prevode preostalih članaka iz serijala u bliskoj budućnosti)

U ovom članku ćemo opisati sve alate koje Kubernetes pruža za postizanje nulte zastoja za čvorove koji rade u vašem klasteru.

Definisanje problema

U početku ćemo zauzeti naivan pristup, identificirati probleme i procijeniti potencijalne rizike ovog pristupa, te izgraditi znanje za rješavanje svakog od problema s kojima se susrećemo tokom ciklusa. Rezultat je konfiguracija koja koristi kuke životnog ciklusa, sonde spremnosti i budžete za prekide u Podu kako bi se postigao naš cilj bez zastoja.

Za početak našeg putovanja, uzmimo konkretan primjer. Recimo da imamo Kubernetes klaster od dva čvora, u kojem aplikacija radi sa dva pod-a koja se nalaze iza Service:

Nadogradnja Kubernetes klastera bez zastoja

Počnimo s dva pod-a sa Nginxom i servisom koji rade na naša dva Kubernetes cluster čvora.

Želimo ažurirati verziju kernela za dva radna čvora u našem klasteru. Kako da ovo uradimo? Jednostavno rješenje bi bilo podizanje novih čvorova s ​​ažuriranom konfiguracijom, a zatim isključivanje starih čvorova dok pokrećete nove. Iako će ovo funkcionirati, bit će nekoliko problema s ovim pristupom:

  • Kada isključite stare čvorove, podovi koji rade na njima također će se isključiti. Šta ako je potrebno očistiti mahune za graciozno gašenje? Sistem virtuelizacije koji koristite možda neće čekati da se završi proces čišćenja.
  • Šta ako isključite sve čvorove u isto vrijeme? Dobit ćete pristojno vrijeme zastoja dok se podovi premještaju na nove čvorove.

Potreban nam je način da graciozno migriramo podove sa starih čvorova, istovremeno osiguravajući da nijedan od naših radnih procesa ne radi dok vršimo promjene na čvoru. Ili kada izvršimo potpunu zamjenu klastera, kao u primjeru (to jest, zamijenimo slike VM-a), želimo prenijeti pokrenute aplikacije sa starih čvorova na nove. U oba slučaja, želimo spriječiti nove podove da se zakažu na starim čvorovima, a zatim izbaciti sve pokrenute podove iz njih. Za postizanje ovih ciljeva možemo koristiti naredbu kubectl drain.

Preraspodjela svih podova iz čvora

Operacija drenaže vam omogućava da preraspodijelite sve mahune iz čvora. Tokom izvršavanja drena, čvor je označen kao neplaniran (zastavica NoSchedule). Ovo sprječava pojavljivanje novih mahuna na njemu. Zatim drain počinje izbacivati ​​mahune iz čvora, isključuje kontejnere koji trenutno rade na čvoru, šaljući signal TERM kontejneri u mahuni.

Iako kubectl drain će obaviti odličan posao izbacivanja mahuna, postoje još dva faktora koji mogu uzrokovati neuspjeh operacije odvoda:

  • Vaša prijava mora biti u mogućnosti da se završi graciozno nakon podnošenja TERM signal. Kada se mahune izbace, Kubernetes šalje signal TERM kontejnere i čeka da se zaustave određeno vrijeme, nakon čega ih, ako se nisu zaustavili, prinudno ukida. U svakom slučaju, ako vaš kontejner ne percipira signal ispravno, još uvijek možete pogrešno ugasiti podove ako su trenutno pokrenuti (na primjer, transakcija baze podataka je u toku).
  • Gubite sve module koji sadrže vašu aplikaciju. Možda neće biti dostupan kada se novi kontejneri pokreću na novim čvorovima ili ako su vaši podovi raspoređeni bez kontrolera, možda se uopće neće ponovo pokrenuti.

Izbjegavanje zastoja

Da bi se minimiziralo vrijeme zastoja zbog dobrovoljnog prekida, kao što je operacija pražnjenja na čvoru, Kubernetes pruža sljedeće opcije za rukovanje greškama:

U ostatku serije, koristit ćemo ove Kubernetes karakteristike da ublažimo utjecaj migracije podova. Da bismo lakše pratili glavnu ideju, koristit ćemo naš primjer iznad sa sljedećom konfiguracijom resursa:

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

Ova konfiguracija je minimalan primjer Deployment, koji upravlja nginx podovima u klasteru. Osim toga, konfiguracija opisuje resurs Service, koji se može koristiti za pristup nginx podovima u klasteru.

Tokom ciklusa, mi ćemo iterativno proširivati ​​ovu konfiguraciju tako da ona na kraju uključuje sve mogućnosti koje Kubernetes pruža za smanjenje vremena zastoja.

Za potpuno implementiranu i testiranu verziju ažuriranja Kubernetes klastera za nula zastoja na AWS-u i šire, posjetite Gruntwork.io.

Pročitajte i druge članke na našem blogu:

izvor: www.habr.com

Dodajte komentar