Nota perev.: Este material de revisión de Weaveworks presenta las estrategias de implementación de aplicaciones más populares y habla sobre la posibilidad de implementar las más avanzadas utilizando el operador de Kubernetes, Flagger. Está escrito en un lenguaje simple y contiene diagramas visuales que hacen posible que incluso los ingenieros novatos comprendan el problema.
El diagrama está tomado de otra revisión de las estrategias de implementación realizadas en Container Solutions.Uno de los mayores problemas en el desarrollo de aplicaciones nativas en la nube hoy en día es la implementación de implementación. Con el enfoque de microservicio, los desarrolladores ya están trabajando con aplicaciones totalmente modulares y diseñándolas, lo que permite a diferentes equipos escribir código y realizar cambios en la aplicación al mismo tiempo.
Las implementaciones más cortas y frecuentes tienen las siguientes ventajas:
- Se reduce el tiempo de comercialización.
- Las nuevas funciones llegan a los usuarios más rápido.
- Los comentarios de los usuarios llegan al equipo de desarrollo más rápido. Esto significa que el equipo puede complementar funciones y solucionar problemas más rápidamente.
- La moral de los desarrolladores aumenta: es más interesante trabajar con una gran cantidad de funciones en el desarrollo.
Pero con el aumento de las frecuencias de lanzamiento, también aumentan las posibilidades de afectar negativamente la confiabilidad de la aplicación o la experiencia del usuario. Es por eso que 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. (Obtenga más información sobre la automatización de canalizaciones de CI / CD
aquí ).
En esta publicación, discutiremos varias estrategias de implementación en Kubernetes, incluidas las implementaciones continuas y métodos más avanzados, como las implementaciones canarias y sus variaciones.
Estrategias de implementación
Existen varios tipos diferentes de estrategias de implementación que puede utilizar en función de su objetivo. Por ejemplo, es posible que deba realizar cambios en un determinado entorno para realizar más pruebas, o en un subconjunto de usuarios / clientes, o tal vez deba realizar pruebas limitadas en los usuarios antes de hacer que alguna función
esté disponible públicamente .
Rolling (despliegue gradual, "rodante")
Esta es una estrategia de implementación estándar en Kubernetes. Gradualmente, uno por uno, reemplaza los pods con la versión anterior de la aplicación con pods con la nueva versión, sin tiempo de inactividad del clúster.
Kubernetes espera hasta que las nuevas cápsulas estén listas para trabajar (verificándolas con
pruebas de preparación ) antes de comenzar a colapsar las antiguas. Si se produce un problema, dicha actualización continua se puede interrumpir sin detener todo el clúster. En el archivo de implementación tipo YAML, la nueva imagen reemplaza a 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: 8080
Los parámetros para una actualización continua 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 de despliegue más simple, las vainas viejas se matan de una vez y se reemplazan por otras nuevas:
El manifiesto correspondiente se parece a esto:
spec: replicas: 3 strategy: type: Recreate template: ...
Azul / Verde (despliegue azul-verde)
La estrategia de implementación azul-verde (a veces también llamada rojo / negro, es decir, rojo-negro) implica el despliegue simultáneo de las versiones antigua (verde) y nueva (azul) de la aplicación. Después de colocar ambas versiones, los usuarios comunes obtienen acceso al verde, mientras que el azul está disponible para que el equipo de QA automatice las pruebas a través de un servicio separado o reenvío directo de puertos:
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp-02 spec: template: metadata: labels: app: awesomeapp version: "02"
Una vez que se ha probado la versión azul (nueva) y se ha aprobado su lanzamiento, el servicio cambia a ella y se minimiza el verde (antiguo):
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
Canarias (despliegue canario)
Los rollos canarios se ven como azul verdoso, pero se manejan mejor y utilizan un enfoque
progresivo por pasos. Este tipo incluye varias estrategias diferentes, incluidos los lanzamientos "ocultos" y las pruebas A / B.
Esta estrategia se usa cuando es necesario experimentar alguna funcionalidad nueva, como regla, en el backend de la aplicación. La esencia del enfoque es crear dos servidores casi idénticos: uno sirve a casi todos los usuarios y el otro, con nuevas características, solo sirve a un pequeño subconjunto de usuarios, después de lo cual se comparan sus resultados. Si todo va bien, la nueva versión se está implementando gradualmente en toda la infraestructura.
Aunque esta estrategia solo se puede implementar usando las herramientas de Kubernetes, reemplazando los pods viejos por otros nuevos, es mucho más conveniente y fácil usar una malla de servicio como Istio.
Por ejemplo, puede tener dos manifiestos diferentes en Git: el normal con la etiqueta 0.1.0 y el "canario" con la etiqueta 0.2.0. Al cambiar los pesos en el manifiesto de la puerta de enlace virtual Istio, puede controlar la distribución del tráfico entre estas dos implementaciones:
Para un tutorial sobre la implementación de implementaciones canarias con Istio, consulte
Flujos de trabajo de GitOps con Istio .
( Nota de traducción : También tradujimos material sobre rollos de canario en Istio aquí ).Despliegues de Canarias con Weaveworks Flagger
Weaveworks Flagger hace que sea fácil y eficiente administrar implementaciones de canarios.
Flagger automatiza el trabajo con ellos. Utiliza Istio o AWS App Mesh para enrutar y cambiar el tráfico, así como las métricas de Prometheus para analizar los resultados. Además, el análisis de las implementaciones canarias se puede complementar con webhooks para pruebas de aceptación, pruebas de estrés y cualquier otro tipo de verificación.
Basado en la implementación de Kubernetes y, si es necesario, en el escalado horizontal de pod (HPA), Flagger crea conjuntos de objetos (implementaciones de Kubernetes, servicios ClusterIP y servicios virtuales Istio o App Mesh) para el análisis e implementación de implementaciones canarias:
Implementando un
bucle de control , Flagger cambia gradualmente el tráfico al servidor canario, mientras mide simultáneamente indicadores clave de rendimiento, como el porcentaje de solicitudes HTTP exitosas, la duración promedio de la solicitud y el estado del pod. Según el análisis de KPI (indicadores clave de rendimiento), la porción canaria crece o se colapsa, y los resultados del análisis se publican en Slack. Puede encontrar una descripción y una demostración de este proceso en
Progressive Delivery for App Mesh .
Despliegue oscuro (oculto) o A / B
El despliegue encubierto es otra variación de la estrategia canaria (Flagger también puede trabajar con ella, por cierto). La diferencia entre los despliegues encubiertos y los canarios es que los despliegues encubiertos se ocupan de la interfaz y no del servidor, como los canarios.
Otro nombre para estas implementaciones es prueba A / B. En lugar de abrir el acceso a la nueva función a todos los usuarios, se ofrece solo a una parte limitada de ellos. Por lo general, estos usuarios no saben que son probadores pioneros (de ahí el término "implementación encubierta").
Mediante el uso de
conmutadores de función y otras herramientas, puede supervisar cómo los usuarios interactúan con la nueva función, si los cautiva o si encuentran que la nueva interfaz de usuario es confusa y otros tipos de métricas.
Despliegues de Flagger y A / B
Además del enrutamiento ponderado, Flagger también puede dirigir el tráfico al servidor canario, según la configuración de HTTP. Para las pruebas A / B, puede usar encabezados HTTP o cookies para redirigir a un segmento específico de usuarios. Esto es especialmente efectivo para aplicaciones frontend que requieren
afinidad de sesión para el servidor. Para obtener más información, consulte la documentación de Flagger.
El autor agradece a Stefan Prodan , ingeniero de Weaveworks (y creador de Flagger), por todas estas impresionantes implementaciones.PD del traductor
Lea también en nuestro blog: