Kubernetes [Best Practices ] actualizar tus clústeres sin parada

Nota del traductor: En Google cloud Español os indicamos que es la última entrega de una serie de videos y blogs en siete partes de Google Developer Advocate Sandeep Dinesh sobre cómo aprovechar al máximo su entorno de Kubernetes.

La máxima de -Si funciona no toques-  no es aplicable a los servicios que están expuestos en internter y es una buena práctica mantener la aplicación actualizada para optimizar la seguridad y el rendimiento. Kubernetes y Docker pueden hacer que estas actualizaciones sean mucho más fáciles, ya que puede construir un nuevo contenedor con las actualizaciones y desplegar lo con relativa facilidad.

Al igual que sus aplicaciones, Kubernetes constantemente obtiene nuevas funciones y actualizaciones de seguridad, por lo que los nodos subyacentes y la infraestructura de Kubernetes deben mantenerse actualizados.

En este episodio de Best-Practices de Kubernetes, echemos un vistazo a cómo Google Kubernetes Engine puede hacer que la actualización de su clúster de Kubernetes sea transparente.

Las dos partes de un grupo

Cuando se trata de actualizar su clúster, hay dos partes y ambos necesitan actualizarse: los maestros y los nodos. Los maestros necesitan actualizarse primero, y luego los nodos pueden seguir. Veamos cómo actualizar ambos usando Kubernetes Engine.

Actualización del maestro sin tiempo de inactividad

Kubernetes Engine actualiza automáticamente el maestro a medida que se lanzan nuevas versiones , sin embargo, por lo general, no se actualizará automáticamente a una nueva versión (por ejemplo, de 1.7 a 1.8). Cuando esté listo para actualizar a una nueva versión, puede simplemente hacer clic en el botón maestro de actualización en la consola de Kubernetes Engine, por ejemplo:

Sin embargo, es posible que haya notado que el cuadro de diálogo dice lo siguiente:

"Cambiar la versión maestra puede provocar varios minutos de inactividad de la gestionde  control. Durante ese período, no podrá editar este clúster ".

Cuando el maestro realiza una actualización, las implementaciones, los servicios, etc. continúan funcionando como se esperaba. Sin embargo, todo lo que requiere la API de Kubernetes deja de funcionar. Esto significa que kubectl deja de funcionar, las aplicaciones que usan la API de Kubernetes para obtener información sobre el funcionamiento del clúster y, básicamente, no puede realizar ningún cambio en el clúster mientras se está actualizando.

Entonces, ¿cómo actualizar el maestro sin incurrir en tiempo de inactividad?

Masters de alta disponibilidad con clusters regionales de Kubernetes Engine

Mientras que los clústeres Kubernetes Engine estándar "Zonal" solo tienen un nodo maestro que los respalda, puede crear clústeres "Regionales" que proporcionan maestros de zonas múltiples y altamente disponibles.

Al crear su clúster, asegúrese de seleccionar la opción "regional":

¡Y eso es! Kubernetes Engine crea automáticamente sus nodos y maestros en tres zonas, con los maestros detrás de una dirección IP con equilibrio de carga, por lo que la API de Kubernetes continuará funcionando durante una actualización.

Actualización de nodos con tiempo de inactividad cero

Al actualizar los nodos, hay algunas estrategias diferentes que puede usar. Hay dos en los que me quiero enfocar:

1. Actualización continua
2. Migración con grupos de nodos

1. Actualización continua

La forma más sencilla de actualizar los nodos de Kubernetes es utilizar una actualización continua. Es el mecanismo de actualización predeterminado que Kubernetes Engine usa para actualizar sus nodos.

Una actualización continua funciona de la siguiente manera. Uno a uno, un nodo se vacía y se condiciona para que no haya más módulos que se ejecutan en ese nodo. Luego se elimina el nodo y se crea un nuevo nodo con la versión actualizada de Kubernetes. Una vez que ese nodo está en funcionamiento, se actualiza el siguiente nodo. Esto continúa hasta que se actualicen todos los nodos.

Puede dejar que Kubernetes Engine administre este proceso por completo habilitando actualizaciones automáticas de nodos en el grupo de nodos.

Si no selecciona esto, el panel de control de Kubernetes Engine le avisará cuando haya disponible una actualización:

Simplemente haga clic en el enlace y siga el mensaje para comenzar la actualización continua.

Advertencia: asegúrese de que sus pods sean administrados por ReplicaSet, Deployment, StatefulSet o algo similar. ¡Los pods autónomos no serán gestionados!

Si  es simple realizar una actualización continua en Kubernetes Engine, tiene algunos inconvenientes.

Una desventaja es que obtiene un nodo menos de capacidad en su clúster. Este problema se resuelve fácilmente escalando su grupo de nodos para agregar capacidad adicional, y luego des-escalando nuevamente una vez que la actualización ha finalizado.

La naturaleza completamente automatizada de la actualización progresiva lo hace fácil pero usted tiene menos control sobre el proceso. También lleva tiempo volver a la versión anterior si hay un problema, ya que debe detener la actualización continua y luego deshacerla.

2. Migración con grupos de nodos

En lugar de actualizar el grupo de nodos "activo" como lo haría con una actualización continua, puede crear un grupo de nodos nuevo, esperar a que se ejecuten todos los nodos y luego migrar las cargas de trabajo de un nodo a la vez.

Supongamos que nuestro clúster de Kubernetes tiene tres VM en este momento. Puede ver los nodos con el siguiente comando:

kubectl get nodes
NAME                                        STATUS  AGE
gke-cluster-1-default-pool-7d6b79ce-0s6z    Ready   3h
gke-cluster-1-default-pool-7d6b79ce-9kkm    Ready   3h
gke-cluster-1-default-pool-7d6b79ce-j6ch    Ready   3h

Creando el nuevo grupo de nodos

Para crear el nuevo grupo de nodos con el nombre "pool-two", ejecute el siguiente comando:

gcloud container node-pools create pool-two

Nota: Recuerde personalizar este comando para que el nuevo grupo de nodos sea el mismo que el anterior. También puede usar la GUI para crear un nuevo grupo de nodos si lo desea.

Ahora bien, si comprueba los nodos, notará que hay tres nodos más con el nuevo nombre del grupo:

$ kubectl get nodes
NAME                                        STATUS  AGE
gke-cluster-1-pool-two-9ca78aa9–5gmk        Ready   1m
gke-cluster-1-pool-two-9ca78aa9–5w6w        Ready   1m
gke-cluster-1-pool-two-9ca78aa9-v88c        Ready   1m
gke-cluster-1-default-pool-7d6b79ce-0s6z    Ready   3h
gke-cluster-1-default-pool-7d6b79ce-9kkm    Ready   3h
gke-cluster-1-default-pool-7d6b79ce-j6ch    Ready   3h

¡Sin embargo, los pods todavía están en los nodos antiguos! Cambiemos los pods de lugar.

Elimine el antiguo grupo

Ahora necesitamos mover el trabajo al nuevo grupo de nodos. Avancemos sobre un nodo a la vez de manera continua.

Primero, ajuste cada uno de los nodos antiguos. Esto evitará que se programen nuevos pods en ellos. Es como meterlos en mantenimiento.

kubectl cordon nodo

Una vez que todos los nodos antiguos están acordonados, los pods solo se pueden programar en los nuevos nodos. Esto significa que puede comenzar a eliminar pods de los nodos antiguos, y Kubernetes los programa automáticamente los crea dentro de  los nuevos nodos. 

Advertencia: asegúrese de que sus pods sean administrados por ReplicaSet, Deployment, StatefulSet o algo similar. ¡Los pods independientes no se reprogramarán!

Ejecute el siguiente comando para vaciar cada nodo. Esto elimina todos los pods en ese nodo.

kubectl drain  --force

Después de vaciar un nodo, asegúrese de que los nuevos pods estén activos y en ejecución antes de continuar con el siguiente.

Si tiene algún problema durante la migración, conecte el antiguo grupo y luego desactive  y vacié  el nuevo grupo. Los pods vuelven a programarse en el grupo anterior.


Borre el grupo anterior. 

Una vez que todos los pods se reprograman de manera segura, es hora de eliminar el grupo anterior. Reemplazar "grupo predeterminado" con el grupo que desea eliminar. 

gcloud container node-pools delete default-pool

¡Aacabas de actualizar con éxito todos sus nodos! 

Conclusión

Para utilizar Kubernetes Engine, puede mantener su clúster de Kubernetes actualizado con solo unos pocos clics.

Si no está utilizando un servicio gestionado como Kubernetes, puede seguir utilizando la actualización continua o método de grupos de nodos con su propio clúster para actualizar los nodos. La diferencia es que debe agregar manualmente los nuevos nodos a su clúster y realizar la actualización maestra a a mano, lo cual puede ser complicado.

Recomiendo utilizar los clústeres regionales de Kubernetes Engine para los maestros de alta disponibilidad y las actualizaciones automáticas de nodos para tener una solución rápida, tenga en cuenta que la actualización es gratuita.

Si necesita el controlar de forma adicional  las actualizaciones de su nodo, el uso de conjuntos de nodos le otorga ese control sin renunciar a las ventajas de una plataforma administrada de Kubernetes que Kubernetes Engine le ofrece.

Y así concluye esta serie sobre las mejores prácticas de Kubernetes. Si tiene ideas para otros temas que le gustaría abordar en el futuro, puede encontrarme en Twitter.