Nota del traductor: Este material de revisión de Weaveworks presenta las estrategias de despliegue de aplicaciones más populares y explica cómo implementar las más avanzadas utilizando el operador de Kubernetes Flagger. Está redactado en un lenguaje sencillo y contiene diagramas claros que permiten entender el tema incluso a ingenieros principiantes.
El esquema fue tomado de de estrategias de despliegue, realizada en Container Solutions
Uno de los mayores problemas en el desarrollo de aplicaciones nativas de la nube hoy en día es acelerar el despliegue. Con un enfoque de microservicios, los desarrolladores ya trabajan con aplicaciones completamente modulares y las diseñan para permitir que diferentes equipos escriban código y realicen cambios en la aplicación simultáneamente.
Los despliegues más cortos y frecuentes tienen las siguientes ventajas:
- Se reduce el tiempo de lanzamiento al mercado.
- Las nuevas funciones llegan más rápidamente a los usuarios.
- Las respuestas de los usuarios llegan más rápido al equipo de desarrollo. Esto significa que el equipo puede agregar funciones y solucionar problemas de manera más ágil.
- Aumenta la moral de los desarrolladores: trabajar con una mayor cantidad de funciones en desarrollo es más interesante.
Pero con el aumento de la frecuencia de los lanzamientos también aumentan las probabilidades de afectar negativamente la confiabilidad de la aplicación o la experiencia del usuario. Por esta razón, es importante que los equipos de operaciones y DevOps construyan procesos y gestionen estrategias de despliegue de manera que minimicen el riesgo para el producto y los usuarios. (Descubre más sobre la automatización de la canalización CI/CD) .)
En esta publicación discutiremos diversas estrategias de despliegue en Kubernetes, incluyendo despliegues rolling y métodos más avanzados, tales como los despliegues canario y sus variaciones.
Estrategias de despliegue.
Existen varios tipos de estrategias de despliegue que se pueden utilizar dependiendo del objetivo. Por ejemplo, puede ser necesario realizar cambios en un entorno para pruebas posteriores, en un subconjunto de usuarios/clientes, o puede ser necesario realizar pruebas limitadas en usuarios antes de hacer una función pública.
Rolling (despliegue gradual)
Esta es la estrategia estándar de despliegue en Kubernetes. Sustituye gradualmente, uno por uno, los pods con la versión antigua de la aplicación por los pods con la nueva versión, sin provocar inactividad en el clúster.
Kubernetes espera a que los nuevos pods estén listos para funcionar (verificándolos mediante ), antes de proceder a desmantelar los antiguos. Si surge un problema, esta actualización gradual se puede interrumpir sin detener todo el clúster. En el archivo YAML que describe el tipo de despliegue, la nueva imagen sustituye a la antigua:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Los parámetros de la actualización gradual se pueden especificar en el archivo de manifiesto:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (recreación)
En este tipo más sencillo de despliegue, los pods antiguos se eliminan todos a la vez y se reemplazan por nuevos:
El manifiesto correspondiente se ve aproximadamente así:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (despliegues azul/verdes)
La estrategia de despliegue azul/verde (a veces también llamada roja/negra) implica el despliegue simultáneo de la versión antigua (verde) y la nueva (azul) de la aplicación. Después de desplegar ambas versiones, los usuarios comunes tienen acceso a la verde, mientras que la azul está disponible para el equipo de QA para la automatización de pruebas a través de un servicio separado o mediante redirección de puertos:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Una vez que la versión azul (nueva) ha sido probada y se ha aprobado su lanzamiento, el servicio se dirige hacia ella, mientras que la verde (antigua) se desmantela:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (despliegues canarios)
Los despliegues canarios son similares a los azul/verdes, pero se gestionan mejor y utilizan un enfoque por etapas. Este tipo incluye varias estrategias diferentes, incluidas las 'lanzamientos ocultos' y la prueba A/B.
Esta estrategia se aplica cuando es necesario probar alguna nueva funcionalidad, generalmente en el backend de la aplicación. La esencia del enfoque es crear dos servidores prácticamente idénticos: uno atiende a casi todos los usuarios, mientras que el otro, con las nuevas funciones, atiende solo a un pequeño subgrupo de usuarios, tras lo cual se comparan los resultados de su funcionamiento. Si todo transcurre sin errores, la nueva versión se despliega gradualmente en toda la infraestructura.
Aunque esta estrategia se puede implementar únicamente con herramientas de Kubernetes, reemplazando los pod antiguos por nuevos, es mucho más conveniente y sencillo utilizar un service mesh como Istio.
Por ejemplo, puede haber dos manifiestos diferentes en Git: uno normal con la etiqueta 0.1.0 y uno 'canary' con la etiqueta 0.2.0. Cambiando los pesos en el manifiesto del gateway virtual de Istio, se puede gestionar la distribución del tráfico entre estos dos deployments:
Una guía paso a paso para implementar deployments canarios con Istio se puede encontrar en el material . (Nota de traducción.: También hemos traducido un material sobre releases canarios en Istio .)
Despliegues canarios con Weaveworks Flagger
permite gestionar de manera fácil y eficaz los despliegues canarios.
Flagger automatiza el trabajo con ellos. Utiliza Istio o AWS App Mesh para enrutar y cambiar el tráfico, así como métricas de Prometheus para analizar los resultados. Además, el análisis de los despliegues canarios se puede complementar con webhooks para realizar pruebas de aceptación, de carga y cualquier otro tipo de verificación.
Basándose en el deployment de Kubernetes y, si es necesario, en la escalabilidad horizontal de los pod (HPA), Flagger crea conjuntos de objetos (deployments de Kubernetes, servicios ClusterIP y servicios virtuales de Istio o App Mesh) para llevar a cabo el análisis y la implementación de despliegues canarios:
Implementando el bucle de control (control loop), Flagger redirige gradualmente el tráfico al servidor canario, mientras mide indicadores clave de rendimiento, como la tasa de solicitudes HTTP exitosas, la duración media de la solicitud y la salud de los pod. Basándose en el análisis de los KPI (indicadores clave de rendimiento), la parte canaria se expande o se reduce, y los resultados del análisis se publican en Slack. Una descripción y demostración de este proceso se puede encontrar en el material .
Despliegues oscuros (escondidos) o A/B
El despliegue oculto es otra variación de la estrategia canaria (con la que, por cierto, Flagger también puede trabajar). La diferencia entre un despliegue oculto y uno canario es que los despliegues ocultos manejan el frontend, mientras que los canarios se ocupan del backend.
Otra denominación para estos despliegues es A/B testing. En lugar de abrir el acceso a una nueva función para todos los usuarios, se ofrece solo a una parte limitada de ellos. Normalmente, estos usuarios no saben que actúan como testers pioneros (de ahí el término 'despliegue oculto').
Con los interruptores de funcionalidad (feature toggles) y otras herramientas, se puede supervisar cómo los usuarios interactúan con la nueva función, si les atrae o si consideran que la nueva interfaz de usuario es confusa, así como otros tipos de métricas.
Flagger y los despliegues A/B
Además de laruta basada en pesos, Flagger también puede dirigir el tráfico al servidor canario según parámetros HTTP. En A/B testing, se pueden utilizar cabeceras HTTP o cookies para redirigir un segmento específico de usuarios. Esto es especialmente eficaz en aplicaciones frontend que requieren afinidad de sesión con el servidor (session affinity). Para más información, se puede consultar la documentación de Flagger.
El autor agradece a , ingeniero de Weaveworks (y creador de Flagger), por todos estos impresionantes esquemas de despliegue.
P.D. del traductor
También puedes leer en nuestro blog:
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
