Proceso de actualización para su clúster de Kubernetes
En algún momento, cuando se utiliza un clúster de Kubernetes, es necesario actualizar los nodos en ejecución. Esto puede incluir actualizaciones de paquetes, actualizaciones del kernel o implementación de nuevas imágenes de máquinas virtuales. En la terminología de Kubernetes, esto se llama .
Esta publicación es parte de una serie de 4 publicaciones:
- Esta publicación.
- Apagado correcto de pods en un cluster de Kubernetes
- Terminación retrasada de un pod cuando se elimina
- Cómo evitar el tiempo de inactividad del clúster de Kubernetes utilizando PodDisruptionBudgets
(aprox. Se esperan traducciones de los artículos restantes de la serie en un futuro próximo)
En este artículo, describiremos todas las herramientas que proporciona Kubernetes para lograr un tiempo de inactividad cero para los nodos que se ejecutan en su clúster.
Definición del problema
Al principio adoptaremos un enfoque ingenuo, identificaremos problemas y evaluaremos los riesgos potenciales de este enfoque, y desarrollaremos conocimientos para resolver cada uno de los problemas que encontremos a lo largo del ciclo. El resultado es una configuración que utiliza enlaces de ciclo de vida, sondas de preparación y presupuestos de interrupción de Pod para lograr nuestro objetivo de tiempo de inactividad cero.
Para comenzar nuestro viaje, tomemos un ejemplo concreto. Digamos que tenemos un clúster de Kubernetes de dos nodos, en el que se ejecuta una aplicación con dos pods ubicados detrás Service:
Comencemos con dos pods con Nginx y Service ejecutándose en nuestros dos nodos del clúster de Kubernetes.
Queremos actualizar la versión del kernel de dos nodos trabajadores en nuestro clúster. Cómo hacemos esto? Una solución sencilla sería iniciar nodos nuevos con la configuración actualizada y luego apagar los nodos antiguos mientras se inician los nuevos. Si bien esto funcionará, habrá algunos problemas con este enfoque:
- Cuando apagas nodos antiguos, los pods que se ejecutan en ellos también se apagarán. ¿Qué pasa si es necesario limpiar las cápsulas para que se apaguen correctamente? Es posible que el sistema de virtualización que está utilizando no espere a que se complete el proceso de limpieza.
- ¿Qué pasa si apagas todos los nodos al mismo tiempo? Obtendrá un tiempo de inactividad decente mientras los pods se trasladan a nuevos nodos.
Necesitamos una manera de migrar pods de nodos antiguos sin problemas y al mismo tiempo garantizar que ninguno de nuestros procesos de trabajo se esté ejecutando mientras realizamos cambios en el nodo. O cuando hacemos un reemplazo completo del clúster, como en el ejemplo (es decir, reemplazamos imágenes de VM), queremos transferir aplicaciones en ejecución desde nodos antiguos a otros nuevos. En ambos casos, queremos evitar que se programen nuevos pods en nodos antiguos y luego expulsar de ellos todos los pods en ejecución. Para lograr estos objetivos podemos utilizar el comando kubectl drain.
Redistribuir todos los pods de un nodo
La operación de drenaje le permite redistribuir todos los pods de un nodo. Durante la ejecución del drenaje, el nodo se marca como no programable (marca NoSchedule). Esto evita que aparezcan nuevas vainas. Luego, el drenaje comienza a desalojar las cápsulas del nodo, apaga los contenedores que se están ejecutando actualmente en el nodo y envía una señal. TERM contenedores en una vaina.
Aunque kubectl drain hará un gran trabajo al desalojar las cápsulas, hay otros dos factores que pueden causar que falle la operación de drenaje:
- Su solicitud debe poder finalizar correctamente al momento de su envío.
TERMseñal. Cuando se desalojan los pods, Kubernetes envía una señalTERMcontenedores y espera a que se detengan durante un período de tiempo específico, después del cual, si no se han detenido, los termina por la fuerza. En cualquier caso, si su contenedor no percibe la señal correctamente, aún puede apagar los pods incorrectamente si se están ejecutando actualmente (por ejemplo, una transacción de base de datos está en progreso). - Pierdes todos los pods que contienen tu aplicación. Es posible que no esté disponible cuando se lanzan nuevos contenedores en nuevos nodos o, si sus pods se implementan sin controladores, es posible que no se reinicien en absoluto.
Evitar el tiempo de inactividad
Para minimizar el tiempo de inactividad debido a una interrupción voluntaria, como una operación de drenaje en un nodo, Kubernetes proporciona las siguientes opciones de manejo de fallas:
En el resto de la serie, utilizaremos estas funciones de Kubernetes para mitigar el impacto de la migración de pods. Para que sea más fácil seguir la idea principal, usaremos nuestro ejemplo anterior con la siguiente configuración de recursos:
---
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: 80Esta configuración es un ejemplo mínimo. Deployment, que gestiona los pods nginx en el clúster. Además, la configuración describe el recurso. Service, que se puede utilizar para acceder a pods nginx en un clúster.
A lo largo del ciclo, ampliaremos iterativamente esta configuración para que eventualmente incluya todas las capacidades que proporciona Kubernetes para reducir el tiempo de inactividad.
Para obtener una versión completamente implementada y probada de las actualizaciones del clúster de Kubernetes para lograr cero tiempo de inactividad en AWS y más allá, visite .
Lea también otros artículos en nuestro blog:
Fuente: habr.com