Procesi i përditësimit për klasterin tuaj Kubernetes
Në një moment gjatë përdorimit të klasterit Kubernetes, lind nevoja për të përditësuar nodet në funksion. Kjo mund të përfshijë përditësime paketash, përditësimin e bërthamës ose shpërndarjen e imazheve të reja të makinerive virtuale. Në terminologjinë e Kubernetes, kjo quhet .
Ky post është pjesë e një cikli prej 4 postimesh:
- Ky post.
- PĂ«rfundimi korrekt i podâave nĂ« klasterin Kubernetes
- PĂ«rfundimi i vonuar i podâit nĂ« momentin e fshirjes
- Si të shmangni ndërprerjet në funksionimin e klasterit Kubernetes me ndihmën e PodDisruptionBudgets
(shën. përk. përkthimet e artikujve të tjerë të ciklit prisni së shpejti)
Në këtë artikull do të përshkruajmë të gjitha mjetet që ofron Kubernetes për të arritur zero kohë ndërprerjeje për nodet që punojnë në klasterin tuaj.
PĂ«definedimi i problemit
Në fillim, do të përdorim një qasje naive, duke identifikuar problemet dhe duke vlerësuar rreziqet e mundshme të kësaj qasjeje dhe duke mbledhur njohuri për të zgjidhur çdo problem që do të hasim gjatë gjithë ciklit. Si rezultat, do të arrijmë një konfigurim që përdor lifecycle hooks, readiness probes dhe Pod disruption budgets për të arritur kohën tonë zero të pushimit.
Për të nisur rrugëtimin tonë, le të marrim një shembull konkret. Supozoni se kemi një klaster Kubernetes me dy node, në të cilin është duke ecuar një aplikacion me dy podë, që ndodhen pas Shërbimi:
Le të fillojmë me dy podë me Nginx dhe Service të nisur në dy node të klasterit tonë Kubernetes.
Ne duam të përditësojmë versionin e bërthamës së dy nodeve punuese në klasterin tonë. Si do ta bëjmë këtë? Një zgjidhje e thjeshtë do të ishte të ngarkonim node të reja me konfigurim të përditësuar dhe më pas të fiknim node të vjetra, duke filluar njëkohësisht të rejat. Megjithatë, kjo do të sjellë disa probleme me një qasje të tillë:
- Kur tĂ« çaktivizoni nodet e vjetra, pod'Ă«t qĂ« janĂ« tĂ« ekzekutuar nĂ« to gjithashtu do tĂ« çaktivizohen. ĂfarĂ« ndodh nĂ«se pod'Ă«t duhet tĂ« pastrohen pĂ«r njĂ« çaktivizim tĂ« saktĂ«? Sistemi i virtualizimit qĂ« po pĂ«rdorni mund tĂ« mos presĂ« pĂ«r tĂ« pĂ«rfunduar procesin e pastrimit.
- ĂfarĂ« ndodh nĂ«se çaktivizoni tĂ« gjitha nodet njĂ«kohĂ«sisht? Do tĂ« keni njĂ« periudhĂ« tĂ« konsiderueshme prapa derisa pod'Ă«t tĂ« transferohen nĂ« nodet e reja.
Na nevojitet një mënyrë e saktë për migrimin e pod'ëve nga nodet e vjetra dhe nga ana tjetër duhet të jemi të sigurt që asnjë nga proceset tona të punës nuk është në ekzekutim ndërsa ne bëjmë ndryshime në nodë. Ose kur ne bëjmë një zëvendësim të plotë të klasterit, si në shembull (dmth. zëvendosim imazhet e VM), ne duam të transferojmë aplikacionet funksionuese nga nodet e vjetra në ato të reja. Në të dyja rastet, ne duam të parandalojmë planifikimin e pod'ëve të rinj në nodet e vjetra dhe pastaj të largohemi nga të gjitha pod'ët e ekzekutuar. Për të arritur këto qëllime mund të përdorim komandën kubectl drain.
Rredistribuimi i të gjitha pod'ëve nga nodë
Operacioni drain lejon rredistribuimin e tĂ« gjitha pod'Ă«ve nga nodĂ«. GjatĂ« procesit tĂ« ekzekutimit tĂ« drain, nodĂ«ja shĂ«nohet si e pa-planifikueshme (flamuri NoSchedule). Kjo parandalon shfaqjen e podĂ«ve tĂ« rinj. Pastaj, procesi i shkarkimit fillon tĂ« zhvendosĂ« podâĂ«t nga nodet, pĂ«rfundon funksionimin e konteinerĂ«ve qĂ« aktualisht janĂ« tĂ« aktivizuar nĂ« nodĂ«n duke dĂ«rguar sinjalin TERM konteinerĂ«ve nĂ« pod.
Megjithatë kubectl drain ndonëse ai do të përballet mirë me zhvendosjen e podëve, ka edhe dy faktorë të tjerë që mund të shkaktojnë dështim gjatë operacionit të shkarkimit:
- Aplikacioni juaj duhet të jetë në gjendje të përfundojë siç duhet kur të dërgohet
TERMsinjali. Kur podâĂ«t zhvendosen, Kubernetes dĂ«rgon sinjalinTERMkonteinerĂ«ve dhe pret ndalimin e tyre pĂ«r njĂ« periudhĂ« tĂ« caktuar kohore, pas sĂ« cilĂ«s, nĂ«se ata nuk janĂ« ndaluar, i pĂ«rfundon ato me forcĂ«. NĂ« çdo rast, nĂ«se konteineri juaj nuk e kupton saktĂ«sisht sinjalin, ju still mund tĂ« fikni podâĂ«t nĂ« mĂ«nyrĂ« jo korrekte, nĂ«se ata janĂ« aktivĂ« nĂ« atĂ« moment tĂ« caktuar (pĂ«r shembull, nĂ«se njĂ« transaksion Ă«shtĂ« nĂ« zhvillim nĂ« DB). - Ju humbni tĂ« gjithĂ« podâĂ«t nĂ« tĂ« cilĂ«t ndodhet aplikacioni juaj. Ai mund tĂ« jetĂ« i paqasjeur nĂ« momentin e fillimit tĂ« konteinerĂ«ve tĂ« rinj nĂ« nodat e reja ose, nĂ«se podâĂ«t tuaj janĂ« shpĂ«rndarĂ« pa kontrollet, ato mund tĂ« mos rifillojnĂ« nĂ« parim.
Shmangim ndalimin
Për të minimizuar kohën e ndaljes nga ndërprerjet vullnetarë, siç është operacioni drain për node, Kubernetes ofron këto mundësi për trajtimin e dështimeve:
NĂ« pjesĂ«t e tjera tĂ« ciklit, ne do tĂ« pĂ«rdorim kĂ«to funksione tĂ« Kubernetes pĂ«r tĂ« zbutur pasojat e zhvendosjes sĂ« podâave. PĂ«r ta bĂ«rĂ« mĂ« tĂ« lehtĂ« ndjekjen e ideve kryesore, ne do tĂ« pĂ«rdorim shembullin tonĂ« mĂ« lart me kĂ«tĂ« konfigurim tĂ« burimeve:
---
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: 80Kjo konfigurim Ă«shtĂ« njĂ« shembull minimal Deployment, i cili menaxhon podâĂ«t nginx nĂ« klaster. PĂ«r mĂ« tepĂ«r, konfigurimi pĂ«rshkruan burimin ShĂ«rbimi, i cili mund tĂ« pĂ«rdoret pĂ«r tĂ« aksesuar podâĂ«t nginx nĂ« klaster.
Gjatë gjithë ciklit, ne do të zgjerim iterativ këtë konfigurim, në mënyrë që në fund të përfshijë të gjitha mundësitë që ofron Kubernetes për të ulur kohën e ndaljes.
Për të marrë një version të plotë të integruar dhe të testuar të përditësimeve të klasterit Kubernetes me zero kohë pezullimi në AWS dhe burime të tjera, vizitoni .
Shihni gjithashtu artikuj të tjerë në blogun tonë:
Burimi: habr.com
