Muy buenas, soy Miguel y para hoy les traigo un tutorial.
Índice
Actualizaciones continuas, recreaciones, implementaciones en rampa, implementaciones de canary y más
Los recursos de implementación dentro de Kubernetes han simplificado las implementaciones de contenedores y son uno de los recursos de Kubernetes más utilizados. Las implementaciones administran ReplicaSets y ayudan a crear múltiples estrategias de implementación manipulándolas de manera apropiada para producir el efecto deseado.
Sorprendentemente, las implementaciones solo tienen dos tipos de estrategia: RollingUpdate
y Recreate
.
Si bien RollingUpdate
es la estrategia predeterminada en la que Kubernetes crea un nuevo ReplicaSet y comienza a escalar el nuevo ReplicaSet y al mismo tiempo escalar el antiguo ReplicaSet hacia abajo, la estrategia Recreate
escala el antiguo ReplicaSet a cero y crea uno nuevo con las réplicas deseadas inmediatamente.
Sin embargo, eso no limita la capacidad de Kubernetes para implementaciones más avanzadas. Hay controles más detallados en la especificación de implementación que pueden ayudarnos a implementar múltiples patrones y estrategias de implementación. Veamos posibles escenarios, cuándo usarlos y cómo se ven con ejemplos prácticos.
Recrear
Ahora, uno podría preguntarse por qué alguien usaría esto, pero créame, hay casos de uso para esto y hay una razón por la que Kubernetes todavía ha permitido que esto exista en su API.
Utilice la estrategia Recreate
si:
- Su aplicación no es compatible con varias versiones.
- Tiene un volumen ReadWriteOnce montado en su Pod y no puede compartirlo con una réplica.
- Quiere dejar de procesar datos antiguos y necesita ejecutar algunos requisitos previos antes de iniciar su nueva aplicación.
Para comprender mejor, creemos una implementación de NGINX con la estrategia Recreate
:
Actualicemos la imagen y veamos qué sucede con los conjuntos de réplicas:
kubectl set image deployment/nginx nginx=bharamicrosystems/nginx:v2
Puede observar que el conjunto de réplicas antiguo se establece inmediatamente en 0 y se crea inmediatamente uno nuevo con diez réplicas.
RollingUpdate
Las actualizaciones continuas son la estrategia de implementación predeterminada para las implementaciones de Kubernetes. Sin embargo, es posible que las actualizaciones continuas no controladas no sean algo que desee.
Creemos una implementación de NGINX con la estrategia RollingUpdate
predeterminada :
Actualice la imagen y observe lo que sucede con los conjuntos de réplicas:
kubectl set image deployment/nginx nginx=bharamicrosystems/nginx:v2
¿Notaste algo? La réplica deseada del antiguo ReplicaSet está disminuyendo y el nuevo ReplicaSet aumenta a medida que los nuevos Pods están listos. También vale la pena señalar que Kubernetes realiza esta actualización continua con el mejor esfuerzo posible sin preocuparse por ninguna interrupción en la aplicación existente.
Es posible que no queramos una actualización tan abrupta y queramos implementar una versión lentamente para poder revertirla si encontramos problemas mientras se implementa la aplicación. Para eso, veamos algunas estrategias que podemos implementar usando actualizaciones continuas.
Despliegue lento en rampa
Un lanzamiento acelerado es cuando queremos lanzar lentamente nuevas réplicas mientras nos deshacemos de las antiguas. Podemos elegir cuántas réplicas queremos implementar a la vez y también debemos asegurarnos de que no haya pods no disponibles durante la operación.
A continuación, se muestra un ejemplo de la implementación anterior realizada con una estrategia de implementación lenta en rampa:
Si ya lo ha notado, hemos agregado propiedades maxSurge=1
y maxUnvailable=0
al RollingUpdate
. Eso significa que lanzaremos una cápsula a la vez sin cápsulas no disponibles. Por lo tanto, la implementación mantendrá un mínimo de diez pods en un momento dado.
Actualicemos la imagen y veamos por nosotros mismos:
kubectl set image deployment/nginx nginx=bharamicrosystems/nginx:v2
Despliegue controlado con el mejor esfuerzo
Hemos analizado la estrategia de lanzamiento lento y acelerado y, aunque garantiza que su aplicación sea estable, el lanzamiento del lanzamiento es lento. Si su implementación contiene cientos de contenedores, puede llevar mucho tiempo implementar la versión completa. Además, es posible que haya notado en el escenario anterior que, a veces, el número de réplicas es superior a diez.
Una forma de resolver estos dos problemas es mediante una estrategia de implementación controlada con el mejor esfuerzo. En esto, solo especificaremos el parámetro máximo no disponible a un porcentaje particular que podemos permitir que no esté disponible, y Kubernetes se encargará de generar nuevos contenedores lo más rápido posible. También estableceremos el aumento máximo en este caso en 0 para asegurarnos de que Kubernetes no haga girar nada más allá de diez réplicas del pod. Eso es algo que no se puede hacer con una estrategia de Despliegue Lento Rampado.
Definamos una implementación con un 20% máximo de pods no disponibles y sin aumento máximo:
Y luego actualice la imagen a v2:
kubectl set image deployment/nginx nginx=bharamicrosystems/nginx:v2
Como habrá notado, en un momento dado, solo el 20% de los pods se eliminan del antiguo conjunto de réplicas y se crean simultáneamente en el nuevo conjunto de réplicas. Además, en un momento dado, las réplicas actuales no superan las diez. Eso también garantiza que tenga la cantidad correcta de pods en ejecución en un momento determinado para proporcionar la mejor utilización posible de los recursos.
Implementaciones azul-verde
Las implementaciones Blue-Green, o las implementaciones Canary, garantizan que dos versiones de una aplicación determinada se estén ejecutando en un momento determinado. Es posible que desee hacer esto para probar una nueva función o desee tener cuidado antes de implementar la versión completa.
Esta estrategia te ayuda a realizar lanzamientos de Canary y pruebas A / B. Eso ha dado lugar a un aumento reciente del paradigma de pruebas en producción, y las organizaciones maduras están utilizando estas características para comprender el comportamiento de sus clientes.
Las implementaciones de Kubernetes no brindan esta característica y, por lo tanto, necesitamos usar los servicios de Kubernetes para eso.
Primero, creemos una implementación que ejecute nginx: v1. No nos preocuparemos demasiado por la estrategia de implementación aquí y lo mantendremos en una estrategia de implementación controlada con el mejor esfuerzo:
Ahora expongamos la implementación a un servicio LoadBalancer
llamado nginx
:
Espere a que Kubernetes asigne una IP externa al LoadBalancer
y curl la IP externa una vez que la tengamos:
kubectl get svc nginx EXTERNAL_IP=$(kubectl get svc nginx|grep nginx|awk {'print $4'}) for i in 1..10 do curl $EXTERNAL_IP done
Veremos que obtenemos «Esta es la versión 1» diez de cada diez veces
Supongamos que está lanzando una nueva versión de nginx: v2 pero solo desea permitirle el 20% del tráfico. En ese escenario, tendremos que organizar la implementación siguiendo los siguientes pasos:
1. Cree otra implementación nginx-v2 con las mismas etiquetas y dos réplicas:
2. Reduzca la implementación de nginx-v1 a ocho réplicas:
kubectl scale deployment nginx-v1 --replicas=8
3. Ahora vuelva a ejecutar el comando curl y observe:
for i in {1..10} do curl $EXTERNAL_IP done
Verá que aproximadamente dos de cada diez solicitudes provienen de v2.
Para migrar aún más el tráfico a la versión 2, podemos seguir escalando la implementación de la versión 1 hacia abajo y hacia arriba la versión 2.
De forma predeterminada, Kubernetes solo le permite administrar las implementaciones Blue-Green y las versiones Canary mediante la creación de varias réplicas. Aún así, si desea tener un control detallado, es posible que desee considerar una malla de servicios como Istio.
Le permitiría migrar lentamente el tráfico y tener una división de tráfico basada en porcentajes, independientemente de la cantidad de réplicas que pueda tener.
Conclusión
Estos fueron un subconjunto de algunas estrategias de implementación que generalmente emplean las organizaciones. Puede tener sus métodos y estrategia de implementación y, como siempre, no existe una forma correcta de hacerlo.
¡Gracias por leer! Espero que hayas disfrutado el artículo.
Añadir comentario