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. To može uključivati ​​ažuriranja paketa, ažuriranja kernela ili implementaciju novih slika virtualnog stroja. U terminologiji Kubernetesa to se zove "Namjerni prekid".

Ovaj post je dio serije od 4 posta:

1. Ovaj post.
2. Ispravno isključivanje podova u Kubernetes klasteru
3. Odgođeno prekidanje mahuna kada se izbriše
4. Kako izbjeći zastoj Kubernetes klastera pomoću PodDisruptionBudgets

(otprilike. Očekujte prijevode preostalih članaka u seriji u bliskoj budućnosti)

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

Definiranje problema

Isprva ć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 tijekom ciklusa. Rezultat je konfiguracija koja koristi kuke životnog ciklusa, sonde spremnosti i proračune prekida Poda kako bi se postigao naš cilj nultog vremena zastoja.

Za početak našeg putovanja, uzmimo konkretan primjer. Recimo da imamo Kubernetes klaster od dva čvora, u kojem je pokrenuta aplikacija s dva modula smještena iza Service:

Započnimo s dva modula s Nginxom i uslugom koji rade na naša dva Kubernetes čvora klastera.

Želimo ažurirati verziju kernela dva radna čvora u našem klasteru. Kako ćemo to učiniti? Jednostavno rješenje bilo bi pokrenuti nove čvorove s ažuriranom konfiguracijom i zatim isključiti stare čvorove dok pokrećete nove. Iako će ovo funkcionirati, bit će nekoliko problema s ovim pristupom:

• Kada isključite stare čvorove, moduli koji rade na njima također će se isključiti. Što ako je module potrebno očistiti za elegantno isključivanje? Sustav virtualizacije koji koristite možda neće čekati da se završi proces čišćenja.
• Što ako isključite sve čvorove u isto vrijeme? Dobit ćete pristojno vrijeme zastoja dok se moduli premještaju na nove čvorove.

Trebamo način da graciozno migriramo podove sa starih čvorova, a pritom osiguravamo da nijedan od naših radnih procesa nije pokrenut dok vršimo izmjene na čvoru. Ili kada radimo potpunu zamjenu klastera, kao u primjeru (odnosno, mijenjamo VM slike), želimo prebaciti pokrenute aplikacije sa starih čvorova na nove. U oba slučaja želimo spriječiti nove podove da raspoređuju na starim čvorovima, a zatim izbaciti sve pokrenute podove iz njih. Za postizanje ovih ciljeva možemo koristiti naredbu kubectl drain.

Preraspodjela svih mahuna iz čvora

Operacija pražnjenja omogućuje vam redistribuciju svih mahuna iz čvora. Tijekom izvođenja drenaže, čvor je označen kao neplaniran (zastavica NoSchedule). To sprječava pojavu novih mahuna na njemu. Zatim odvod počinje izbacivati ​​mahune iz čvora, isključuje spremnike koji trenutno rade na čvoru, šaljući signal TERM spremnici u pod.

Iako kubectl drain obavit će izvrstan posao izbacivanja mahuna, postoje još dva faktora koji mogu uzrokovati neuspjeh operacije ispuštanja:

• Vaša prijava mora moći elegantno završiti nakon podnošenja TERM signal. Kada su mahune izbačene, Kubernetes šalje signal TERM spremnike i čeka da se zaustave određeno vrijeme, nakon čega ih, ako se nisu zaustavili, prisilno prekida. U svakom slučaju, ako vaš spremnik ne percipira signal ispravno, još uvijek možete neispravno ugasiti mahune ako su trenutno pokrenute (na primjer, transakcija baze podataka je u tijeku).
• Gubite sve pakete koji sadrže vašu aplikaciju. Možda neće biti dostupan kada se novi spremnici pokreću na novim čvorovima ili ako su vaši podovi raspoređeni bez kontrolera, možda se uopće neće ponovno pokrenuti.

Izbjegavanje zastoja

Kako bi smanjio vrijeme prekida rada zbog namjernog prekida, kao što je operacija pražnjenja na čvoru, Kubernetes pruža sljedeće opcije rukovanja kvarovima:

• Lijep prekid
• Kuke životnog ciklusa
• PodDisruptionBudgets

U ostatku serije koristit ćemo ove značajke Kubernetesa za ublažavanje utjecaja migracije podova. Kako bismo lakše pratili glavnu ideju, upotrijebit ćemo naš gornji primjer 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.

Tijekom ciklusa ovu ćemo konfiguraciju iterativno proširivati ​​tako da 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 prekida rada na AWS-u i šire, posjetite Gruntwork.io.

Također pročitajte ostale članke na našem blogu:

• Implementacija i baze podataka bez prekida rada
• Kubernetes: zašto je tako važno konfigurirati upravljanje resursima sustava?
• Tekton Pipeline - Kubernetes izvorni cjevovodi
• Izrada dinamičkih modula za Nginx
• Uvod u autorizaciju Kubernetesa tvrtke Hashicorp Consul
• Do čega je dovela migracija s ClickHouse bez autorizacije na ClickHouse s autorizacijom?

Izvor: www.habr.com