Nota. traducción: Este tutorial de Weaveworks presenta las estrategias de implementación de aplicaciones más populares y cómo implementar las más avanzadas con el operador Flagger Kubernetes. Está escrito en un lenguaje sencillo y contiene diagramas visuales que permiten que incluso los ingenieros novatos comprendan el problema.
Diagrama tomado de estrategias de implementación realizadas en Container Solutions
Uno de los mayores desafíos en el desarrollo de aplicaciones nativas de la nube en la actualidad es la velocidad de implementación. Con un enfoque de microservicio, los desarrolladores ya están trabajando y diseñando aplicaciones totalmente modulares, lo que permite que diferentes equipos escriban código y realicen cambios en la aplicación al mismo tiempo.
Las implementaciones más breves y frecuentes tienen los siguientes beneficios:
- Reducción del tiempo de comercialización.
- Las nuevas funciones llegan a los usuarios más rápido.
- Los comentarios de los usuarios llegan más rápido al equipo de desarrollo. Esto significa que el equipo puede agregar funciones y solucionar problemas más rápidamente.
- La moral de los desarrolladores aumenta: es más divertido trabajar con más funciones en desarrollo.
Pero a medida que aumenta la frecuencia de lanzamiento, también aumentan las posibilidades de afectar negativamente la confiabilidad de la aplicación o la experiencia del usuario. Por eso es importante que los equipos de operaciones y DevOps creen procesos y administren estrategias de implementación de una manera que minimice el riesgo para el producto y los usuarios. (Para obtener más información sobre la automatización del proceso de CI/CD, consulte .)
En esta publicación, analizaremos varias estrategias de implementación de Kubernetes, incluidas implementaciones continuas y métodos más avanzados, como implementaciones canary y sus variaciones.
Estrategias de implementación
Existen varios tipos diferentes de estrategias de implementación que se pueden utilizar según el propósito. Por ejemplo, es posible que necesite realizar cambios en algún entorno para realizar más pruebas, o en un subconjunto de usuarios/clientes, o puede que necesite realizar pruebas limitadas en los usuarios antes de crear una función. disponible al público.
Rolling (implementación gradual y continua)
Esta es la estrategia de implementación estándar para Kubernetes. Gradualmente, uno por uno, reemplaza los pods con la versión anterior de la aplicación por pods con la nueva versión, sin tiempo de inactividad del clúster.
Kubernetes espera a que los nuevos pods estén listos (revisándolos con ) antes de proceder a enrollar los viejos. Si ocurre un problema, dicha actualización continua se puede cancelar sin detener todo el clúster. En el archivo YAML de tipo de implementación, la nueva imagen reemplaza la imagen anterior:
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 continua se pueden especificar en el archivo de manifiesto:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recrear (recreación)
En este tipo de implementación más simple, los pods viejos se eliminan todos a la vez y se reemplazan por otros nuevos:
El manifiesto correspondiente se parece a esto:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Azul/Verde (implementaciones azul-verde)
La estrategia de implementación azul-verde (a veces también denominada rojo/negro, es decir, rojo-negro) implica la implementación simultánea de las versiones antigua (verde) y nueva (azul) de la aplicación. Una vez alojadas ambas versiones, la verde está disponible para el usuario general, mientras que la azul está disponible para que el equipo de control de calidad automatice las pruebas a través de un servicio independiente o reenvío directo de puertos:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Después de que la versión azul (nueva) haya sido probada y aprobada para su lanzamiento, el servicio se cambia a ella y la verde (antigua) se minimiza:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (implementaciones canarias)
Los lanzamientos de Canarias son similares al azul-verde, pero mejor controlados y utilizados enfoque paso a paso. Varias estrategias diferentes entran en esta categoría, incluidos los lanzamientos encubiertos y las pruebas A/B.
Esta estrategia se utiliza cuando es necesario probar alguna funcionalidad nueva, generalmente en el backend de la aplicación. La esencia del enfoque es crear dos servidores casi idénticos: uno atiende a casi todos los usuarios y el otro, con nuevas funciones, atiende sólo a un pequeño subgrupo de usuarios, tras lo cual se comparan los resultados de su trabajo. Si todo va sin errores, la nueva versión se implementará gradualmente en toda la infraestructura.
Aunque esta estrategia se puede implementar exclusivamente utilizando Kubernetes, reemplazando los pods antiguos por otros nuevos, es mucho más conveniente y sencillo utilizar una malla de servicios como Istio.
Por ejemplo, es posible que tenga dos manifiestos de Git diferentes: uno normal con una etiqueta 0.1.0 y uno canario con una etiqueta 0.2.0. Al cambiar los pesos en el manifiesto de Istio Virtual Gateway, puede controlar la distribución del tráfico entre estas dos implementaciones:
Puede encontrar una guía paso a paso para implementar implementaciones canary con Istio en . (Nota. traducir: También tradujimos material sobre canarios en Istio. .)
Implementaciones en Canarias con Weaveworks Flagger
Permite un control fácil y eficiente de los rollos canarios.
Flagger automatiza el trabajo con ellos. Utiliza Istio o AWS App Mesh para enrutar y cambiar el tráfico, y métricas de Prometheus para analizar los resultados. Además, el análisis de las implementaciones canary se puede complementar con webhooks para realizar pruebas de aceptación, pruebas de carga y cualquier otro tipo de comprobaciones.
Basado en la implementación de Kubernetes y, si es necesario, pods de escalamiento horizontal (HPA), Flagger crea conjuntos de objetos (implementaciones de Kubernetes, servicios ClusterIP y servicios virtuales Istio o App Mesh) para analizar e implementar implementaciones canary:
Implementación de un bucle de control (bucle de control)Flagger cambia gradualmente el tráfico al servidor canary mientras mide métricas de rendimiento clave, como la tasa de éxito de las solicitudes HTTP, la duración promedio de las solicitudes y el estado del pod. Según el análisis de KPI (indicadores clave de rendimiento), la parte canaria crece 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. .
Implementaciones oscuras (ocultas) o A/B
El despliegue sigiloso es otra variación de la estrategia canaria (con la que, por cierto, Flagger también puede funcionar). La diferencia entre las implementaciones sigilosas y canarias es que las implementaciones sigilosas se ocupan del front-end, no del backend como lo hacen las implementaciones canarias.
Otro nombre para estas implementaciones es prueba A/B. En lugar de abrir el acceso a una nueva función a todos los usuarios, se ofrece sólo a una parte limitada de ellos. Normalmente, estos usuarios no saben que son probadores pioneros (de ahí el término "implementación silenciosa").
Con interruptores de función (función alterna) y otras herramientas, puede monitorear cómo los usuarios interactúan con una nueva función, si son adictos a ella o si encuentran confusa la nueva interfaz de usuario, y otros tipos de métricas.
Implementaciones de abanderados y A/B
Además del enrutamiento ponderado, Flagger también puede enrutar el tráfico al servidor canary según los parámetros HTTP. Las pruebas A/B pueden utilizar encabezados HTTP o cookies para redirigir a un segmento específico de usuarios. Esto es especialmente efectivo en el caso de aplicaciones frontend que requieren que la sesión esté vinculada al servidor. (afinidad de sesión). Puede encontrar más información en la documentación de Flagger.
El autor está agradecido. , ingeniero de Weaveworks (y creador de Flagger), por todos estos increíbles esquemas de implementación.
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com