Procés d'actualització per al vostre clúster de Kubernetes
En algun moment, quan s'utilitza un clúster de Kubernetes, cal actualitzar els nodes en execució. Això pot incloure actualitzacions de paquets, actualitzacions del nucli o desplegament de noves imatges de màquines virtuals. En la terminologia de Kubernetes això s'anomena .
Aquesta publicació forma part d'una sèrie de 4 publicacions:
- Aquesta publicació.
- Tancament correcte dels pods en un clúster de Kubernetes
- Finalització retardada d'un pod quan s'elimina
- Com evitar el temps d'inactivitat del clúster de Kubernetes mitjançant PodDisruptionBudgets
(aprox. Espereu traduccions dels articles restants de la sèrie en un futur proper)
En aquest article, descriurem totes les eines que proporciona Kubernetes per aconseguir zero temps d'inactivitat per als nodes que s'executen al vostre clúster.
Definició del problema
En un principi, adoptarem un enfocament ingenu, identificarem problemes i avaluarem els riscos potencials d'aquest enfocament, i construirem coneixements per resoldre cadascun dels problemes que ens trobem al llarg del cicle. El resultat és una configuració que utilitza ganxos de cicle de vida, sondes de preparació i pressupostos d'interrupció del pod per aconseguir el nostre objectiu de temps d'inactivitat zero.
Per començar el nostre viatge, posem un exemple concret. Suposem que tenim un clúster de Kubernetes de dos nodes, en el qual s'executa una aplicació amb dos pods situats darrere Service:
Comencem amb dos pods amb Nginx i Service que s'executen als nostres dos nodes de clúster Kubernetes.
Volem actualitzar la versió del nucli de dos nodes de treball del nostre clúster. Com ho fem això? Una solució senzilla seria arrencar nous nodes amb la configuració actualitzada i després tancar els antics nodes mentre s'inicien els nous. Tot i que això funcionarà, hi haurà alguns problemes amb aquest enfocament:
- Quan desactiveu els nodes antics, els pods que s'hi executen també s'apagaran. Què passa si cal esborrar les beines per a un tancament elegant? És possible que el sistema de virtualització que utilitzeu no espereu que finalitzi el procés de neteja.
- Què passa si desactiveu tots els nodes alhora? Tindràs un temps d'inactivitat decent mentre les beines es mouen a nous nodes.
Necessitem una manera de migrar amb gràcia els pods des de nodes antics alhora que ens assegurem que cap dels nostres processos de treball s'està executant mentre fem canvis al node. O quan fem una substitució completa del clúster, com a l'exemple (és a dir, substituïm les imatges de VM), volem transferir aplicacions en execució de nodes antics a nous. En ambdós casos, volem evitar que es programin nous pods als nodes antics i, a continuació, desallotjar tots els pods en execució. Per aconseguir aquests objectius podem utilitzar l'ordre kubectl drain.
Redistribució de tots els pods des d'un node
L'operació de drenatge us permet redistribuir totes les beines des d'un node. Durant l'execució del drenatge, el node es marca com a no programable (bandera NoSchedule). Això evita que hi apareguin beines noves. A continuació, el drenatge comença a desallotjar les beines del node, tanca els contenidors que s'estan executant actualment al node, enviant un senyal TERM contenidors en una beina.
Encara kubectl drain farà un gran treball per desallotjar les beines, hi ha altres dos factors que poden fer que l'operació de drenatge falli:
- La vostra sol·licitud ha de poder finalitzar amb gràcia en el moment de la presentació
TERMsenyal. Quan els pods són desallotjats, Kubernetes envia un senyalTERMcontenidors i espera que s'aturin durant un període de temps determinat, després del qual, si no s'han aturat, els dóna de baixa per la força. En qualsevol cas, si el vostre contenidor no percep correctament el senyal, encara podeu apagar els pods de manera incorrecta si s'estan executant (per exemple, una transacció de base de dades està en curs). - Perds tots els pods que contenen la teva aplicació. És possible que no estigui disponible quan es llancin nous contenidors en nous nodes, o si els vostres pods es despleguen sense controladors, és possible que no es reiniciïn en absolut.
Evitant temps morts
Per minimitzar el temps d'inactivitat per interrupcions voluntàries, com ara una operació de drenatge en un node, Kubernetes ofereix les opcions de gestió d'errors següents:
A la resta de la sèrie, utilitzarem aquestes funcions de Kubernetes per mitigar l'impacte de la migració de pods. Per facilitar el seguiment de la idea principal, utilitzarem el nostre exemple anterior amb la configuració de recursos següent:
---
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: 80Aquesta configuració és un exemple mínim Deployment, que gestiona els pods nginx al clúster. A més, la configuració descriu el recurs Service, que es pot utilitzar per accedir als pods nginx en un clúster.
Al llarg del cicle, ampliarem de manera iterativa aquesta configuració perquè finalment inclogui totes les capacitats que Kubernetes ofereix per reduir el temps d'inactivitat.
Per obtenir una versió totalment implementada i provada de les actualitzacions del clúster de Kubernetes per a zero temps d'inactivitat a AWS i més enllà, visiteu .
Llegiu també altres articles al nostre blog:
Font: www.habr.com