ProHoster > Blog > administratë > Përmirësimi i një grupi Kubernetes pa ndërprerje

Përmirësimi i një grupi Kubernetes pa ndërprerje

Përmirësimi i një grupi Kubernetes pa ndërprerje

Procesi i përmirësimit për grupin tuaj Kubernetes

Në një moment, kur përdorni një grup Kubernetes, ekziston nevoja për të përditësuar nyjet e funksionimit. Kjo mund të përfshijë përditësime të paketave, përditësime të kernelit ose vendosjen e imazheve të reja të makinës virtuale. Në terminologjinë Kubernetes kjo quhet "Përçarje vullnetare".

Ky postim është pjesë e një serie me 4 postime:

  1. Ky postim.
  2. Mbyllja e saktë e pods në një grup Kubernetes
  3. Përfundimi i vonuar i një pod kur fshihet
  4. Si të shmangni kohën e ndërprerjes së grupit Kubernetes duke përdorur PodDisruptionBudgets

(përafërsisht Prisni përkthime të artikujve të mbetur në seri në të ardhmen e afërt)

Në këtë artikull, ne do të përshkruajmë të gjitha mjetet që ofron Kubernetes për të arritur zero ndërprerje për nyjet që funksionojnë në grupin tuaj.

Përcaktimi i problemit

Ne do të marrim një qasje naive në fillim, do të identifikojmë problemet dhe do të vlerësojmë rreziqet e mundshme të kësaj qasjeje dhe do të ndërtojmë njohuri për të zgjidhur secilin nga problemet që hasim gjatë ciklit. Rezultati është një konfigurim që përdor grepat e ciklit jetësor, sondat e gatishmërisë dhe buxhetet e ndërprerjes së pod për të arritur kohën tonë të ndërprerjes zero.

Për të filluar udhëtimin tonë, le të marrim një shembull konkret. Le të themi se kemi një grup Kubernetes me dy nyje, në të cilin një aplikacion po funksionon me dy pods të vendosura prapa Service:

Përmirësimi i një grupi Kubernetes pa ndërprerje

Le të fillojmë me dy pods me Nginx dhe Service që funksionojnë në dy nyjet tona të grupimit Kubernetes.

Ne duam të përditësojmë versionin e kernelit të dy nyjeve punëtore në grupin tonë. Si ta bëjmë këtë? Një zgjidhje e thjeshtë do të ishte nisja e nyjeve të reja me konfigurimin e përditësuar dhe më pas mbyllja e nyjeve të vjetra ndërsa nisni ato të reja. Ndërsa kjo do të funksionojë, do të ketë disa probleme me këtë qasje:

  • Kur çaktivizoni nyjet e vjetra, nyjet që funksionojnë në to do të fiken gjithashtu. Po sikur bishtajat duhet të pastrohen për mbyllje të këndshme? Sistemi i virtualizimit që po përdorni mund të mos presë që procesi i pastrimit të përfundojë.
  • Po sikur të fikni të gjitha nyjet në të njëjtën kohë? Ju do të merrni kohë joproduktive të mirë ndërkohë që podat lëvizin në nyje të reja.

Ne kemi nevojë për një mënyrë për të migruar me hijeshi pods nga nyjet e vjetra duke siguruar që asnjë nga proceset tona të punëtorit nuk po funksionon ndërsa bëjmë ndryshime në nyje. Ose kur bëjmë një zëvendësim të plotë të grupit, si në shembull (d.m.th., ne zëvendësojmë imazhet VM), duam të transferojmë aplikacionet e ekzekutuara nga nyjet e vjetra në ato të reja. Në të dyja rastet, ne duam të parandalojmë planifikimin e podeve të reja në nyjet e vjetra, dhe më pas t'i heqim të gjitha podet që funksionojnë prej tyre. Për të arritur këto qëllime ne mund të përdorim komandën kubectl drain.

Rishpërndarja e të gjitha podeve nga një nyje

Operacioni i kullimit ju lejon të rishpërndani të gjitha podet nga një nyje. Gjatë ekzekutimit të kullimit, nyja shënohet si e paplanifikuar (flamur NoSchedule). Kjo parandalon shfaqjen e bishtajave të reja në të. Më pas kullimi fillon të nxjerrë bishtajat nga nyja, mbyll kontejnerët që janë aktualisht në nyje duke dërguar një sinjal TERM kontejnerë në pod.

megjithëse kubectl drain do të bëjë një punë të shkëlqyeshme për nxjerrjen e bishtajave, ka dy faktorë të tjerë që mund të shkaktojnë dështimin e funksionimit të kullimit:

  • Aplikimi juaj duhet të jetë në gjendje të përfundojë me hijeshi pas dorëzimit TERM sinjal. Kur pods dëbohen, Kubernetes dërgon një sinjal TERM kontejnerët dhe pret që të ndalojnë për një kohë të caktuar, pas së cilës, nëse nuk janë ndalur, i ndërpret me forcë. Në çdo rast, nëse kontejneri juaj nuk e percepton saktë sinjalin, mund t'i shuani gabimisht podet nëse ato janë aktualisht në punë (për shembull, një transaksion i bazës së të dhënave është në proces).
  • Ju humbisni të gjitha pjesët që përmbajnë aplikacionin tuaj. Mund të mos jetë i disponueshëm kur kontejnerët e rinj lëshohen në nyje të reja, ose nëse podet tuaja vendosen pa kontrollues, ato mund të mos rinisin fare.

Shmangia e pushimeve

Për të minimizuar kohën e ndërprerjes nga ndërprerja vullnetare, si p.sh. nga një operacion kullimi në një nyje, Kubernetes ofron opsionet e mëposhtme të trajtimit të dështimit:

Në pjesën tjetër të serisë, ne do t'i përdorim këto veçori të Kubernetes për të zbutur ndikimin e grupeve të migrimit. Për ta bërë më të lehtë ndjekjen e idesë kryesore, ne do të përdorim shembullin tonë të mësipërm me konfigurimin e burimit të mëposhtëm:

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

Ky konfigurim është një shembull minimal Deployment, i cili menaxhon nginx pods në grup. Përveç kësaj, konfigurimi përshkruan burimin Service, i cili mund të përdoret për të hyrë në nginx pods në një grup.

Gjatë gjithë ciklit, ne do ta zgjerojmë në mënyrë të përsëritur këtë konfigurim në mënyrë që ai përfundimisht të përfshijë të gjitha aftësitë që ofron Kubernetes për të reduktuar kohën e ndërprerjes.

Për një version plotësisht të implementuar dhe të testuar të përditësimeve të grupit Kubernetes për kohë joproduktive në AWS dhe më gjerë, vizitoni Gruntwork.io.

Lexoni gjithashtu artikuj të tjerë në blogun tonë:

Burimi: www.habr.com

Shto një koment