Automatización del análisis de versiones canary en Google Kubernetes Engine con Spinnaker

En este instructivo, encontrarás los pasos para configurar la característica de análisis automatizado de versiones canary de Spinnaker en Google Kubernetes Engine (GKE).

Introducción

Spinnaker es un sistema de entrega continua de código abierto dirigido por Netflix y Google con el objetivo de administrar la implementación de aplicaciones en diferentes plataformas informáticas, entre las que se incluyen App Engine, GKE, Compute Engine, AWS y Azure. Mediante Spinnaker, puedes emplear métodos de implementación avanzados, que incluyen la implementación de versiones canary.

En una implementación de versiones canary, expones una nueva versión de tu app a una pequeña parte del tráfico de producción y analizas su comportamiento antes de realizar la implementación completa. Esto te permite reducir riesgos antes de implementar una versión nueva en todos los usuarios. Para usar implementaciones de versiones canary, debes comparar con precisión el comportamiento de las versiones anteriores respecto de las versiones nuevas de la app. Las diferencias pueden ser sutiles y tardar un tiempo en aparecer. Es posible que también tengas muchas métricas diferentes para examinar. Obtén más información sobre el patrón de versión canary en Implementación de aplicaciones y estrategias de prueba.

Para resolver esos problemas, Spinnaker tiene una característica de análisis automatizado de versiones canary. Esta característica lee las métricas de ambas versiones del sistema de supervisión y ejecuta un análisis estadístico para automatizar la comparación. En este instructivo se muestra cómo realizar un análisis automatizado de versiones canary en una app implementada en GKE y supervisada por Cloud Monitoring.

Spinnaker es una plataforma avanzada de implementación y administración de apps para organizaciones con situaciones de implementación complejas, que por lo general incluyen una función dedicada de ingeniería de versiones. Puedes realizar este instructivo aun si no tienes experiencia previa con Spinnaker. Sin embargo, la implementación del análisis automatizado de versiones canary en producción suele estar a cargo de equipos con experiencia previa en Spinnaker, que cuentan con un sistema de supervisión sólido y con conocimientos para determinar si una versión es segura.

Acerca de este instructivo

La app de este instructivo es una simple versión de “Hello World” cuya tasa de error se configura con una variable de entorno. Para esta app se proporciona una imagen de Docker precompilada. Como se ilustra en la siguiente imagen, la app expone métricas en el formato Prometheus, un sistema de supervisión de código abierto popular en la comunidad de Kubernetes y compatible con Cloud Monitoring.

Objetivos

• Instalar Spinnaker para Google Cloud.
• Implementar una app en GKE sin una implementación de versiones canary.
• Configurar y ejecutar una implementación de versiones canary de la aplicación.
• Configurar el análisis automatizado de versiones canary.
• Evaluar el análisis automatizado de versiones canary.

Costos

Importante:En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

• GKE
• Monitoring

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud sean aptos para obtener una prueba gratuita.

Antes de comenzar

1. Selecciona o crea un proyecto de Google Cloud.

   Ir a la página Administrar recursos

2. Habilita la facturación en tu proyecto.

   Habilitar la facturación

3. Crea un lugar de trabajo.

   Ir a la documentación de Monitoring

   Nota: Para este instructivo, el lugar de trabajo debería tener el mismo nombre que el proyecto de Google Cloud que estés usando. Puedes usar un lugar de trabajo existente solo si cumple con este requisito.

Cuando completes el instructivo puedes borrar los recursos que hayas creado para evitar que se te sigan facturando. Para obtener más detalles consulta la sección Limpieza.

Implementa Spinnaker para Google Cloud mediante Cloud Shell

En esta sección, vas a configurar la infraestructura necesaria para completar el instructivo. Ejecuta todos los comandos de terminal de este instructivo desde Cloud Shell.

Spinnaker para Google Cloud te ofrece una manera de configurar y administrar Spinnaker en un entorno listo para la producción, optimizado para Google Cloud. Spinnaker para Google Cloud configura muchos recursos (GKE, Memorystore, depósitos de Cloud Storage y cuentas de servicio) necesarios para ejecutar Spinnaker en Google Cloud, integra Spinnaker en servicios relacionados, como Cloud Build, y proporciona un entorno de administración basado en Cloud Shell para las instalaciones de Spinnaker, con asistentes y herramientas comunes como spin y hal.

Nota: La instalación demora varios minutos.

1. En Cloud Shell, abre Spinnaker para Google Cloud. De este modo, se clona el Spinnaker para el repositorio de Google Cloud en el entorno de Cloud Shell y, luego, se inician las instrucciones de instalación detalladas.

   Ir a Cloud Shell

2. Instala Spinnaker para Google Cloud:

   PROJECT_ID=${DEVSHELL_PROJECT_ID} ~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup_properties.sh
   ~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup.sh
   

   Nota: Este comando de instalación se usa solo para la configuración básica del instructivo. Para una configuración de producción, sigue las instrucciones detalladas que se incluyen en Spinnaker para Google Cloud.

3. Instala el complemento de integración Monitoring-Prometheus:

   export KUBE_NAMESPACE=prometheus
   export GCP_PROJECT=$DEVSHELL_PROJECT_ID
   export DATA_DIR=/prometheus/
   export DATA_VOLUME=prometheus-storage-volume
   export SIDECAR_IMAGE_TAG=0.7.0
   export GCP_REGION=us-east1-c
   export KUBE_CLUSTER=spinnaker-1
   
   kubectl create namespace ${KUBE_NAMESPACE}
   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/prometheus-service-account.yaml
   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/prometheus-configmap.yaml
   curl -sS https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/gke-prometheus-deployment.yaml | \
     envsubst | \
     kubectl apply -f -
   

4. Reinicia Cloud Shell para cargar la configuración del entorno nuevo.

   

5. Conéctate a Spinnaker:

   ~/cloudshell_open/spinnaker-for-gcp/scripts/manage/connect_unsecured.sh
   

6. En Cloud Shell, selecciona el ícono de Vista previa en la Web y, luego, selecciona Preview on port 8080.

   

   Nota: Por el momento esta instancia de Spinnaker no es de acceso público y solo tú tienes acceso, sin autenticación. La instancia de producción de Spinnaker es un componente fundamental de la infraestructura, por lo que debes protegerla adecuadamente. A continuación se mencionan varias opciones disponibles de seguridad y autenticación:

   • Usa las herramientas que proporciona Spinnaker para Google Cloud, que te ayudarán a proteger la implementación mediante IAP con un certificado SSL.
   • Consulta la documentación de seguridad de Spinnaker.
   • Usa G Suite como proveedor de identidad para la autenticación de Spinnaker.
   • Usa Grupos de Google para la autorización de Spinnaker.
   • Configura Identity-Aware Proxy delante de Spinnaker para tener un mayor control sobre quién puede acceder.

Implementa una app con Spinnaker

En esta sección aprenderás a configurar Spinnaker para implementar una aplicación en el clúster de GKE.

Crea una app de Spinnaker

Antes de la implementación, debes crear la app de Spinnaker.

1. En Spinnaker, selecciona Actions y, luego, Create Application.

   

2. En el diálogo New Application, ingresa los siguientes valores:

   • Name: sampleapp

   • Owner Email: [[e-mail]]

     Advertencia: Para que el resto del instructivo funcione, la app debe llamarse sampleapp.

3. Selecciona Create.

Ahora te encuentras en la sampleapp de Spinnaker. Todavía no está configurada, de modo que la mayoría de las pestañas están vacías.

Crea y ejecuta una canalización de implementación

En esta sección, primero implementarás la app con una canalización simple de Spinnaker que tome un parámetro successRate para crear un Deployment de GKE con cuatro pods. Los pods generan errores al azar a una tasa correspondiente al parámetro successRate. En este instructivo, generan 500 errores a una tasa de 100 - successRate.

1. En Cloud Shell, crea la canalización con el archivo JSON proporcionado. El siguiente comando publica la definición de JSON de la canalización directamente en la API de Spinnaker.

   cd ~
   wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/simple-deploy.json
   sed "s/my-kubernetes-account/spinnaker-install-account/g" simple-deploy.json > updated-simple-deploy.json
   spin pipeline save --file updated-simple-deploy.json
   

2. En la sección Pipelines de Spinnaker, aparece una canalización llamada Simple deploy. Si no la ves, vuelve a cargar la página. Selecciona Start Manual Execution.

   

3. En la ventana Confirm execution, selecciona una Success Rate de 70 y, luego, selecciona Run. Luego de unos segundos, la canalización implementa con éxito la configuración de la app y los cuatro pods.

4. En Cloud Shell, crea un pod que realice solicitudes a la nueva aplicación hasta que termine el instructivo.

   kubectl -n default run injector --generator=run-pod/v1 --image=alpine:3.10 -- \
       /bin/sh -c "apk add --no-cache curl; \
       while true; do curl -sS --max-time 3 \
       http://sampleapp:8080/; done"
   

Verifica los registros del inyector

1. Para ver el comportamiento de la app, verifica los registros del inyector.

   kubectl -n default logs -f \
       $(kubectl -n default get pods -l run=injector \
       -o=jsonpath='{.items[0].metadata.name}')
   

2. Una gran cantidad de mensajes de error interno del servidor aparecen en el registro. Para dejar de seguir los registros del inyector, presiona Ctrl+C.

Cómo verificar el estado de la aplicación

Ahora que la aplicación está implementada y procesa tráfico, comprueba que se esté comportando correctamente. Claro que ya sabes que, en este instructivo, no funciona de forma correcta, ya que la implementaste con solo el 70% de tasa de éxito.

La app expone un extremo /metrics con métricas en el formato Prometheus que son transferidas por Monitoring. En esta sección visualizarás esas métricas en Monitoring.

1. En Google Cloud Console, ve a Monitoring.

   Ir a Monitoring

2. Si el Explorador de métricas aparece en el panel de navegación, selecciona Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.

3. Asegúrate de que esté seleccionada la pestaña Métrica.

4. Selecciona la casilla con la etiqueta Find resource type and metric y, luego, ingresa external.googleapis.com/prometheus/requests.

5. Para definir mejor el gráfico, en el campo Group by, ingresa http_code.

   En el siguiente gráfico, las tasas de solicitudes HTTP que respondió la app se agrupan según el código de estado HTTP:

   

   Si no tienes datos en Monitoring o no puedes encontrar la métrica external.googleapis.com/prometheus/requests, espera unos minutos para que Monitoring transfiera los datos antes de volver a cargar el Explorador de métricas.

   Como puedes ver en el gráfico, en este momento la app tiene una tasa de error inaceptable: alrededor del 30%, según lo esperado. En el resto del instructivo, te guiaremos en la configuración de una canalización de una implementación de versiones canary y un análisis automático para evitar futuras implementaciones de una app con una tasa de error tan alta.

Creación de una implementación de versiones canary

En esta sección crearás una canalización de implementación de versiones canary, sin análisis automatizado, para probar la versión nueva de la aplicación antes de implementarla por completo en producción. Para simplificar, la canalización que creas en esta sección se basa en el balanceo de cargas de Kubernetes a fin de enviar tráfico a la versión canary. Como consecuencia, no puedes elegir qué parte del tráfico se enruta a la versión canary. Para implementar políticas de enrutamiento de tráfico avanzadas, puedes usar Istio.

En la siguiente imagen se muestran las diferentes etapas de la canalización:

• Paso 0: Al igual que en la canalización Simple Deploy (Implementación simple), la canalización toma un parámetro de Tasa de éxito como entrada. Esta canalización nueva, utiliza este parámetro para simular diferentes tasas de éxito. Esta es la Configuration de la canalización.

• Paso 1: La etapa Find Baseline Version (Buscar versión de línea base) recupera la versión actual de la aplicación que se está ejecutando en producción de la última ejecución de la canalización Simple Deploy (Implementación simple). En este instructivo, recupera la tasa de éxito de la aplicación implementada en la actualidad.

  En paralelo con la etapa Find Baseline Version, la etapa Deploy Canary Config implementa la configuración de tasa de éxito nueva para la versión canary de la aplicación.

• Paso 2: La etapa Deploy Canary (Implementar detección de fallos) y la etapa Deploy Baseline (Implementar línea base) implementan las dos versiones para realizar una comparación, la versión de detección de fallos nueva y una versión de línea base. La versión canary usa la configuración que se creó en Deploy Canary Config, mientras que la versión del modelo de referencia usa la configuración de la versión de producción.

  Nota: Lee Prácticas recomendadas de Canary para comprender por qué es mejor comparar una versión canary con una versión del modelo de referencia, y no directamente con la instancia que se ejecuta en producción.

• Paso 3: La etapa Manual Judgment (Criterio manual) detiene la canalización hasta que continuas. Durante esta etapa, puedes verificar si la versión canary se comporta correctamente.

• Paso 4: Cuando pasas la etapa Manual Judgment (Criterio manual), tanto la etapa Delete Canary (Borrar detección de fallos) como la etapa Delete Baseline (Borrar línea base) limpian la infraestructura.

  En paralelo a la limpieza, se lanza la etapa Deploy to Production (Implementar en producción) y esta activa la canalización Simple Deploy (Implementación simple) con el mismo parámetro de Tasa de éxito que configuraste al inicio. La misma versión de la app que probaste en la versión canary se implementa en producción.

  La etapa implementación a producción solo se activa si decides continuar durante la etapa orden manual.

• Paso 5: Finalmente, la etapa Successful Deployment (Implementación correcta) valida que toda la canalización sea correcta. Verifica que hayas dado la autorización en la etapa Orden manual y se ejecuta solo si las etapasImplementación en producción, Borrar versión canary y Borrar modelo de referencia se ejecutaron de forma correcta.

Ahora puedes crear y ejecutar la canalización Canary Deploy (Implementación de detección de fallos).

1. Para crear la canalización implementación de versión canary, ejecuta el siguiente comando con el fin de recuperar el ID de la canalización Implementación simple y, luego, inyéctalo en la canalización implementación de versión canary:

   cd ~
   wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/canary-deploy.json
   export PIPELINE_ID=$(spin pipeline get -a sampleapp -n 'Simple deploy' | jq -r '.id')
   jq '(.stages[] | select(.refId == "9") | .pipeline) |= env.PIPELINE_ID | (.stages[] | select(.refId == "8") | .pipeline) |= env.PIPELINE_ID' canary-deploy.json | \
       sed "s/my-kubernetes-account/spinnaker-install-account/g" > updated-canary-deploy.json
       spin pipeline save --file updated-canary-deploy.json
   

2. Si no ves la canalización implementación de versión canary en Spinnaker, vuelve a cargar la página de sampleapp, y selecciona Canalizaciones.

3. Para iniciar la canalización Canary Deploy (Implementación de detección de fallos):

   1. Selecciona Start Manual Execution.
   2. Selecciona una Success Rate de 80.
   3. Selecciona Run.

4. Cuando la canalización alcance la etapa Manual Judgment, no selecciones Continue porque primero debes comparar la versión canary con la versión del modelo de referencia.

   

5. En Cloud Shell, ejecuta el comando kubectl -n default get pods para ver los pods nuevos con las etiquetas canary y baseline:

   NAME                                READY STATUS  RESTARTS  AGE
   injector-66bd655ffd-9ntwx           1/1   Running 0         30m
   sampleapp-5cdf8f55dd-995rz          1/1   Running 0         28m
   sampleapp-5cdf8f55dd-dqq8n          1/1   Running 0         28m
   sampleapp-5cdf8f55dd-ntq57          1/1   Running 0         28m
   sampleapp-5cdf8f55dd-rlpzp          1/1   Running 0         28m
   sampleapp-baseline-567b8d6849-gsgqr 1/1   Running 0          4m
   sampleapp-canary-54b9759dd6-gmjhc   1/1   Running 0          4m
   

6. En Google Cloud Console, ve a Monitoring.

   Ir a Monitoring

7. Si el Explorador de métricas aparece en el panel de navegación, selecciona Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.

8. Asegúrate de que esté seleccionada la pestaña Métrica.

9. Para mostrar la tasa de error del modelo de referencia y la versión canary, especifica los siguientes parámetros:

   1. Metric: external.googleapis.com/prometheus/requests
   2. Filters:
      1. http_code igual a 500
      2. version diferente (!=) de prod

   Si faltan datos en Monitoring, espera unos minutos hasta que aparezcan.

10. Compara la versión canary (de color violeta en el siguiente gráfico) con la versión del modelo de referencia (de color azul en el siguiente gráfico). Es posible que los colores varíen en tu gráfico. En este instructivo, la versión canary tiene una tasa de error más baja que la versión del modelo de referencia. Por lo tanto, es seguro implementar por completo la versión canary en producción. Si la versión canary no tuvo una tasa de error más baja, quizás desees detener la implementación en esta etapa y hacer algunas correcciones en la app.

    

11. En Spinnaker, en el diálogo orden manual, selecciona Continuar.

12. Cuando finalice la implementación, regresa a Monitoring.

    Ir a Monitoring

13. Si el Explorador de métricas aparece en el panel de navegación, selecciona Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.

14. Asegúrate de que esté seleccionada la pestaña Métrica.

15. Selecciona el cuadro que tiene la etiqueta Find resource type and metric y, a continuación, selecciona estos elementos en el menú o ingresa sus nombres. Usa la siguiente información para completar los campos de este cuadro de texto:

    1. En Metric, selecciona o ingresa external.googleapis.com/prometheus/requests.
    2. En el campo Group By, ingresa http_code.

    En el siguiente gráfico, la tasa de solicitudes HTTP que respondió la app se divide según el código de estado HTTP:

    

    En este gráfico, se muestra la tasa de códigos HTTP, 200 y 500, para todos los pods: producción, modelo de referencia y versión canary. Debido a que la versión canary tenía una tasa de error más baja, la implementaste en producción. Luego de un período corto durante la implementación, en el que la cantidad total de solicitudes es ligeramente más baja, puedes ver que la tasa de error general disminuye: la versión canary se implementó correctamente en producción.

Automatización del análisis de versiones canary

Una implementación de versión canary es útil, pero la forma en que está configurada en este momento, indica que es un proceso manual. Debes verificar manualmente que la versión canary se comporte como deseas antes de realizar la implementación completa; y la diferencia entre la versión canary y la del modelo de referencia no siempre es clara.

La automatización del análisis de versiones canary es una buena idea: evitas ocuparte de esa tarea y el análisis estadístico automatizado es más adecuado que el manual para detectar problemas en un conjunto de métricas. En esta sección, la etapa orden manual se reemplaza por un análisis automatizado de versión canary.

Nota: El análisis de versiones canary no está diseñado para detectar errores o fallas. Detecta la desviación de determinadas métricas y se asegura de que el comportamiento de la versión nueva sea similar al de la versión anterior. Ya que es posible que estés de acuerdo con el aumento (o disminución) de una métrica específica, puedes considerar que el aumento o la disminución de una métrica es aceptable.

Habilita la compatibilidad con versiones canary

Primero configura la característica de análisis automatizado de versiones canary en Spinnaker, que se llama Kayenta. Para configurar Kayenta, usa Halyard, la misma herramienta que se usa en la configuración y la implementación de Spinnaker.

1. Configura Kayenta para usar Monitoring como backend:

   hal config canary google enable
   hal config canary google account add kayenta-tutorial --project $DEVSHELL_PROJECT_ID
   hal config canary google edit --stackdriver-enabled=true
   

2. Aplica la configuración nueva:

   ~/cloudshell_open/spinnaker-for-gcp/scripts/manage/push_and_apply.sh
   

   La implementación demora unos minutos.

Configura la característica de análisis automatizado de versión canary

Una vez que Kayenta está habilitado, configúralo para sampleapp.

1. En Spinnaker, selecciona Config (Configuración).

2. En la sección Features, selecciona Canary y, luego, Save Changes.

   

Crea una configuración de versión canary

En Spinnaker, el análisis automatizado de versiones canary ejecuta una prueba estadística en diferentes métricas y arroja una puntuación como resultado. Esta puntuación oscila entre 0 y 100 y representa la cantidad de métricas que aprueban o reprueban en la comparación entre el modelo de referencia y la versión canary. Puedes modificar la puntuación ubicando las métricas en diferentes grupos, con diferentes ponderaciones en cada grupo. Según la puntuación del análisis, es posible que quieras seguir adelante con la implementación o no. Si utilizas una métrica única, como en este instructivo, la puntuación solo puede ser 0 (reprobado) o 100 (aprobado).

Es posible que una aplicación tenga varias configuraciones de versiones canary que se pueden compartir entre distintas aplicaciones. Una configuración de versión canary consta de dos elementos principales:

• Un conjunto de métricas para analizar (posiblemente en diferentes grupos)
• Umbrales marginal y de aprobación para la puntuación

En una canalización de implementación, se utiliza una configuración de versión canary en la etapa Canary Analysis. Esta etapa puede incluir varias ejecuciones de versiones canary. Si la puntuación de cualquiera de las ejecuciones está por debajo del umbral marginal, se detiene la etapa y no se realizan las otras ejecuciones. Para que toda la etapa se considere exitosa, la puntuación de la última ejecución debe estar por encima del umbral de aprobación.

Para crear una configuración de versión canary, sigue estos pasos:

1. Ahora que la versión canary está habilitada, la sección Pipelines se reemplaza por Delivery (si no ves la sección Delivery, vuelve a cargar Spinnaker). En la sección Delivery, ve a Canary Configs.
2. Selecciona Add Configuration.
3. En Configuration Name, ingresa kayenta-test.
4. En la sección Metrics, selecciona Add Metric.

5. En el cuadro de diálogo Add Metric, ingresa los siguientes valores y, luego, selecciona OK:

   • Name: error_rate
   • Fail on: increase
   • Resource Type: k8s_container
   • Metric type: external.googleapis.com/prometheus/requests
   • Aligner: ALIGN_RATE

   • Filter Template: Elige Create new.

     • Para Name de la plantilla del filtro nueva, ingresa: http_code
     • Para Template de la plantilla del filtro nueva, ingresa: metric.labels.http_code = "500" AND resource.label.pod_name = starts_with("${scope}")
     • Selecciona Save.
   Nota: Aligner es un parámetro de la API de Cloud Monitoring que compara la tasa de cambio de las métricas en lugar de su valor absoluto. La app de este instructivo expone la cantidad total de errores desde que comenzó como una métrica. Kayenta debe comparar si la tasa de esos errores cambia entre una y otra versión de la app.

6. En la sección Scoring, establece Group 1 en 100.

7. Selecciona Save changes.

Agrega una etapa de análisis de versiones canary a la canalización

Ahora que ya tienes una configuración de versión canary, modifica la canalización de implementación existente para reemplazar la etapa Manual Judgment por una etapa Canary Analysis que use esta configuración.

Nota: Si cometes un error en esta sección que no puedes solucionar, usa los comandos que se enumeran en el repositorio del instructivo.

1. Ve a Entrega > Canalizaciones, y para la canalización Canary Deploy (Implementación de versión canary), selecciona Configure (Configurar).

   

2. Selecciona Add stage.

3. En Type, selecciona Canary Analysis.

4. En la sección Depends On, modifica la etapa nueva para que dependa de las siguientes selecciones:

   • Deploy Canary
   • Deploy Baseline

5. Completa la sección Canary Analysis Configuration con los siguientes valores:

   Nombre del parámetro	Valor	Definición
   Analysis Type	Real Time (Manual)	El modo automático, en el que la versión canary y la del modelo de referencia se crean para ti, aún no está disponible en Kubernetes.
   Config Name	kayenta-test	Nombre de la configuración de versión canary que creaste antes.
   Lifetime	0 hours 5 minutes	Tiempo que debería durar el análisis de versiones canary.
   Retraso	0	Tiempo que le damos a la aplicación para arrancar antes de realizar el análisis.
   Interval	5	Ventana de tiempo que debería usar Kayenta para ejecutar un análisis estadístico único.
   Baseline	sampleapp-baseline	Implementación en GKE que debería usar Kayenta como modelo de referencia.
   Baseline Location	default	Espacio de nombres en GKE en el que reside el modelo de referencia.
   Canary	sampleapp-canary	Implementación en GKE que Kayenta debería usar como versión canary.
   Canary Location	default	Espacio de nombres en GKE en el que reside la versión canary.
   Marginal	75	Puntuación límite para una versión canary marginal aprobada.
   Pass	95	Puntuación límite para una versión canary general aprobada.

   Nota: Un análisis de versiones canary se compone de varias ejecuciones de versiones canary. Una ejecución de versión canary tiene dos partes: un período (definido por el parámetro interval) durante el cual se juntan las métricas, y la etapa real de análisis estadístico de esas métricas. Kayenta realiza la mayor cantidad posible de ejecuciones en el período lifetime que proporcionas. Por ejemplo, si configuras un intervalo de cinco minutos y un período lifetime de una hora, Kayenta realiza 12 ejecuciones de versiones canary. Para obtener más información sobre la configuración correcta de esos parámetros, consulta las Prácticas recomendadas de Canary.

6. En la sección Execution Options, selecciona Ignore the failure. Ignoras la falla de modo que puedas destruir el modelo de referencia y la versión canary, aunque el análisis de versiones canary haya fallado. Más adelante en el instructivo, modificarás las etapas para tener en cuenta una potencial falla de la versión canary.

7. En el esquema de la canalización, selecciona Deploy to Production.

   

8. Cambia la sección Depend On, a los siguientes parámetros:

   1. Agrega Canary Analysis.
   2. Quita Manual Judgment.

9. Para asegurarte de que solo implementarás en producción si el análisis de versiones canary es exitoso, cambia el parámetro Conditional on Expression.

   ${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
   

10. En el esquema de canalización, selecciona Delete Canary y cambia la sección Depends On a los siguientes parámetros:

    1. Agrega Canary Analysis.
    2. Quita Manual Judgment.

11. En el esquema de canalización, selecciona Delete Baseline y cambia la sección Depends On.

    1. Agrega Canary Analysis.
    2. Quita Manual Judgment.

12. Para garantizar que toda la canalización falle si falla el análisis de versiones canary, en el esquema de la canalización, selecciona Successful deployment y, luego, el ícono de editar.

    

    1. Cambia la Expresión por lo siguiente:

       ${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
       

    2. Seleccione Update.

13. Para finalizar, reemplaza la etapa orden manual por la etapa análisis de versiones canary que creaste recientemente.

    1. En el esquema de la canalización, selecciona Manual Judgment.
    2. Selecciona Remove stage.

14. Selecciona Save changes.

    Ahora la canalización se ve como la siguiente imagen:

    

Prueba tu nueva canalización

Ahora que el análisis automatizado de versiones canary está configurado, prueba la canalización para asegurarte de que funcione como se espera.

1. Ve a Entrega > Canalizaciones y, para la canalización implementación de versiones canary, o implementación de versiones canary automatizada si usaste la CLI, selecciona Comenzar ejecución manual.

2. Selecciona una Success Rate de 60 y, luego, Run.

3. Para verificar el progreso actual del análisis de versiones canary, selecciona Canary Analysis y, luego, Task Status. Luego de unos minutos, la etapa Canary Analysis falla porque la tasa de éxito actual en producción es de 80. Cuando falle la etapa Canary Analysis, ve al informe de este análisis de versiones canary.

   1. Selecciona Canary Analysis.
   2. Selecciona Canary Summary.

   3. Selecciona el ícono de informe.

      En la página del informe, la tasa de error es más alta para la versión canary que para la versión del modelo de referencia.

      

4. Repite los pasos de esta sección, pero selecciona una Success Rate de 90 para lograr un análisis de versiones canary exitoso.

Limpieza

Sigue estos pasos para evitar que se apliquen cargos a tu cuenta de Google Cloud Platform por los recursos que usaste en el instructivo:

Precaución: Borrar un proyecto tiene las consecuencias que se enumeran a continuación.

• Se borra todo en el proyecto. Si utilizaste un proyecto existente para este instructivo, cuando lo borres, también borrarás cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varios instructivos y guías de inicio rápido, la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

1. En Cloud Console, ve a la página Administrar recursos.

   Ir a la página Administrar recursos

2. En la lista de proyectos, selecciona el proyecto que deseas borrar y haz clic en Borrar .
3. En el cuadro de diálogo, escribe el ID del proyecto y haz clic en Cerrar para borrar el proyecto.

Borra recursos

Si deseas conservar el proyecto de Google Cloud que usaste en este instructivo, borra los recursos individuales:

1. Borra el clúster de GKE.

   gcloud container clusters delete spinnaker-1
   

2. Cuando se te pida confirmación, escribe Y.

Próximos pasos

• Obtén más información sobre Spinnaker.
• Mira cómo Waze y Netflix usan Spinnaker y Kayenta.
• Consulta todos los recursos sobre la Entrega continua.
• Aprende a usar Spinnaker con Cloud Build y Cloud Source Repositories.
• Recorre un codelab dedicado a la Entrega continua en GKE mediante Spinnaker.
• Consulta spin, una herramienta de CLI para administrar las apps y canalizaciones de Spinnaker.
• Consulta otras estrategias de implementación y prueba de aplicaciones.
• Prueba otras características de Google Cloud. Consulta nuestros instructivos.