Cómo automatizar el análisis de detección de fallos en Google Kubernetes Engine con Spinnaker

En este instructivo encontrarás los pasos para configurar la característica de análisis automatizado de detección de fallos 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 implementar métodos de implementación avanzados, inclusive implementaciones de detección de fallos.

En una implementación de detección de fallos, expones una nueva versión de tu aplicación a una pequeña parte del tráfico de la 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 tus usuarios. Para utilizar la implementación de detección de fallos, debes comparar con precisión el comportamiento de las versiones nueva y anterior de tu aplicación. La diferencia puede ser sutil y demorar cierto tiempo en manifestarse. Es posible que también tengas muchas métricas diferentes para examinar.

Para resolver esos problemas, Spinnaker tiene una característica de análisis automatizado de detección de fallos. 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. Este instructivo te muestra cómo realizar un análisis automatizado de detección de fallos en una aplicación implementada en GKE y supervisada por Stackdriver.

Spinnaker es una plataforma avanzada de implementación y administración de aplicaciones para organizaciones con situaciones de implementación complejas, que por lo general presenta una función de ingeniería de versión dedicada. Puedes realizar este instructivo aun si no tienes experiencia previa con Spinnaker. Sin embargo, por lo general, los que se encargan de realizar la implementación del análisis automatizado de detección de fallos en producción son equipos con experiencia previa en Spinnaker, con un sistema de supervisión sólido y con conocimiento para determinar si una versión es segura.

Acerca de este instructivo

La aplicación en este instructivo es una simple aplicación “Hola, mundo” cuya tasa de error se configura con una variable de entorno. Para esta aplicación se proporciona una imagen de Docker precompilada. Como se muestra en la imagen siguiente, la aplicación expone las métricas en formato Prometheus, un sistema de supervisión de código abierto popular en la comunidad Kubernetes y compatible con Stackdriver.

Objetivos

• Crear un clúster de GKE.
• Instalar Spinnaker.
• Implementar una aplicación en GKE sin una implementación de detección de fallos.
• Configurar y ejecutar una implementación de detección de fallos de la aplicación.
• Configurar el análisis automatizado de detección de fallos.
• Evaluar el análisis automatizado de detección de fallos.

Costos

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

• GKE
• Stackdriver

Usa la calculadora de precios a fin de generar una estimación de los costos según el uso previsto. Los usuarios nuevos de GCP pueden optar a una prueba gratuita.

Antes de comenzar

1. Selecciona o crea un proyecto de GCP.

   IR A LA PÁGINA ADMINISTRAR RECURSOS

2. Habilita la facturación para tu proyecto.

   HABILITAR FACTURACIÓN

3. Crea una cuenta de Stackdriver.

   IR A LA DOCUMENTACIÓN DE Stackdriver

   Nota: Para este instructivo, el lugar de trabajo de Stackdriver debe tener el mismo nombre que el proyecto de GCP que estás utilizando. Puedes usar un lugar de trabajo de Stackdriver existente en este instructivo solo si cumple con este requisito.

Cuando finalices este instructivo, puedes evitar que continúe la facturación borrando los recursos que creaste. Consulta la sección Limpieza para obtener más detalles.

Cómo configurar tu entorno

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

1. Abre Cloud Shell.

   IR A CLOUD SHELL

2. Exporta el ID del proyecto como una variable.

   export GOOGLE_CLOUD_PROJECT=[PROJECT_ID]
   

   donde:

   • [PROJECT_ID] representa el ID del proyecto que estás utilizando.

3. Crea un clúster de GKE.

   gcloud config set project $GOOGLE_CLOUD_PROJECT
   gcloud config set compute/zone us-central1-f
   gcloud services enable container.googleapis.com
   gcloud beta container clusters create kayenta-tutorial \
       --machine-type=n1-standard-2 --enable-stackdriver-kubernetes \
       --scopes=gke-default,compute-ro
   

4. Instala el complemento de integración para Stackdriver-Prometheus.

   kubectl apply --as=admin --as-group=system:masters -f \
       https://storage.googleapis.com/stackdriver-prometheus-documentation/rbac-setup.yml
   curl -sS "https://storage.googleapis.com/stackdriver-prometheus-documentation/prometheus-service.yml" | \
       sed "s/_stackdriver_project_id:.*/_stackdriver_project_id: $GOOGLE_CLOUD_PROJECT/" | \
       sed "s/_kubernetes_cluster_name:.*/_kubernetes_cluster_name: kayenta-tutorial/" | \
       sed "s/_kubernetes_location:.*/_kubernetes_location: us-central1-f/" | \
       kubectl apply -f -
   

5. Implementa Spinnaker en tu clúster de GKE nuevo.

   curl -sSL "https://spinnaker.io/downloads/kubernetes/quick-install.yml" | \
       sed 's/version:.*/version: 1.10.5/g' | kubectl apply -f -
   

6. La implementación toma unos minutos en completarse. Para verificar el progreso, ejecuta el comando watch kubectl -n spinnaker get pods. Para detener el comando watch, presiona Ctrl+C. Una vez finalizada la implementación, este comando muestra todos los pods como Ready 1/1.

   NAME                                READY  STATUS    RESTARTS   AGE
   minio-deployment-7c665c4b57-jx7px   1/1    Running   0          5m
   spin-clouddriver-789c6fff77-rjtc6   1/1    Running   0          4m
   spin-deck-68b5968f7f-trmkn          1/1    Running   0          4m
   spin-echo-57dbff9fb8-rq5qc          1/1    Running   0          4m
   spin-front50-67965475b8-l24db       1/1    Running   0          4m
   spin-gate-6d8bbf8c45-m9pzn          1/1    Running   0          4m
   spin-halyard-59fd54bd69-xns49       1/1    Running   0          5m
   spin-kayenta-99b97b85f-4gvsv        1/1    Running   0          4m
   spin-orca-5748974888-cph9g          1/1    Running   0          4m
   spin-redis-6d49c9c5b9-q2hzm         1/1    Running   0          4m
   spin-rosco-6b4ddbcb94-mjrht         1/1    Running   0          4m
   

7. Para acceder a Spinnaker, redirecciona un puerto local al componente deck de Spinnaker.

   DECK_POD=$(kubectl -n spinnaker get pods -l \
       cluster=spin-deck,app=spin \
       -o=jsonpath='{.items[0].metadata.name}')
   kubectl -n spinnaker port-forward $DECK_POD 8080:9000 >/dev/null &
   

8. En Cloud Shell, haz clic en el ícono Vista previa web y selecciona Preview on port 8080 (Vista previa en puerto 8080).

   

   Nota: Por el momento, esta instancia de Spinnaker no es de acceso público y solo tú tienes acceso sin autenticación. Una instancia de producción de Spinnaker es un componente fundamental de tu infraestructura, por eso debes asegurarlo de manera correcta. Tienes varias opciones de seguridad y autenticación disponibles:

   • Consulta la documentación de seguridad de Spinnaker.
   • Utiliza G Suite como proveedor de identidad para la autenticación de Spinnaker.
   • Utiliza Google Groups para la autorización de Spinnaker.
   • Configura un Cloud Identity-Aware Proxy frente a Spinnaker para tener más control sobre quién tiene acceso a este.

Cómo implementar una aplicación con Spinnaker

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

Cómo crear una aplicación de Spinnaker

Antes de la implementación, debes crear una aplicación de Spinnaker.

1. En Spinnaker, haz clic en Actions (Acciones) > Create Application (Crear aplicación).

   

2. En el diálogo Aplicación nueva, ingresa los siguientes valores:

   • Nombre: sampleapp

   • Correo electrónico del propietario: [[e-mail]]

     Advertencia: Para que el resto de este instructivo funcione, el nombre de la aplicación debe ser sampleapp.

3. Haz clic en Crear.

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.

Cómo crear y ejecutar una canalización de implementación

En esta sección, primero implementas la aplicación con una simple canalización de Spinnaker que toma un parámetro successRate para crear una implementación en GKE con cuatro pods. Esos pods arrojan errores al azar a una tasa que corresponde con el parámetro successRate. En este instructivo, arrojan 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.

   wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/simple-deploy.json
   curl [e-mail] -X POST \
       -H "Content-Type: application/json" -H "Accept: */*" \
       http://localhost:8080/gate/pipelines
   

2. En la sección Canalizaciones de Spinnaker, aparece una canalización llamada Simple deploy (Implementación simple). Si no la ves, vuelve a cargar la página. Haz clic en Start Manual Execution (Comenzar ejecución manual).

   

3. En la ventana Confirmar ejecución, selecciona una Tasa de éxito de 70, y luego haz clic en Ejecutar. Luego de unos segundos, la canalización implementa correctamente la configuración de la aplicación y los cuatro pods.

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

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

Cómo verificar los registros del inyector

1. Para ver el comportamiento de la aplicación, 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 en este instructivo ya sabes que no funciona correctamente ya que la implementaste con solo el 70% de tasa de éxito.

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

1. En Stackdriver, ve a Explorador de métricas.

   EXPLORADOR DE MÉTRICAS

2. En el campo Encontrar tipo de recurso y métrica, ingresa el siguiente comando:

   external.googleapis.com/prometheus/requests
   

3. Para definir mejor el gráfico, ingresa http_code en el campo Agrupar según. En el siguiente gráfico, las tasas de solicitudes HTTP que respondió la aplicación se agrupan según el código de estado HTTP:

   

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

Como puedes ver en el gráfico, la aplicación tiene actualmente una tasa de error inaceptable; alrededor del 30%, según lo esperado. El resto del instructivo te guía por los pasos de la configuración de una canalización de implementación de detección de fallos y un análisis automático para evitar futuras implementaciones de una aplicación con una tasa de error tan alta.

Cómo crear una implementación de detección de fallos

En esta sección, crearás una canalización de implementación de detección de fallos, sin análisis automatizado, para probar la versión nueva de la aplicación antes de implementarla por completo en producción. En la siguiente imagen, se muestran las diferentes etapas de esta 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 Configuración 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 (Buscar versión de línea base), la etapa Deploy Canary Config (Configurar implementación de detección de fallos) implementa la configuración de tasa de éxito nueva para la versión de detección de fallos 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 de detección de fallos utiliza la configuración que se creó en Deploy Canary Config (Configurar implementación de detección de fallos), mientras que la versión de línea base utiliza la configuración de la versión de producción.

  Nota: Lee las Recomendaciones de detección de fallos para comprender por qué es mejor comparar una versión de detección de fallos con una línea base 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 de detección de fallos 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 aplicación que probaste en la detección de fallos se implementa en producción.

• La etapa Deploy to Production (Implementar en producción) solo se activa si decides continuar durante la etapa Manual Judgment (Criterio manual).

• Paso 5: Finalmente, la etapa Successful Deployment (Implementación correcta) valida que toda la canalización sea correcta. Verifica que hayas dado la instrucción en la etapa Manual Judgment (Criterio manual) y solo se ejecuta si las etapas Deploy to Production (Implementar en producción), Delete Canary (Borrar detección de fallos) y Delete Baseline (Borrar línea base) se ejecutaron correctamente.

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

1. Para crear la canalización Canary Deploy (Implementación de detección de fallos), ejecuta el siguiente comando con el fin de buscar el ID de la canalización Simple deploy (Implementación simple) y, luego, inyéctalo en la canalización Canary Deploy (Implementación de detección de fallos):

   wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/canary-deploy.json
   export PIPELINE_ID=$(curl \
       localhost:8080/gate/applications/sampleapp/pipelineConfigs/Simple%20deploy \
       | jq -r '.id')
   jq '(.stages[] | select(.refId == "9") | .pipeline) |= env.PIPELINE_ID | (.stages[] | select(.refId == "8") | .pipeline) |= env.PIPELINE_ID' canary-deploy.json | \
       curl -d@- -X POST \
       -H "Content-Type: application/json" -H "Accept: */*" \
       http://localhost:8080/gate/pipelines
   

2. Si no ves la canalización Canary Deploy (Implementación de detección de fallos) en Spinnaker, vuelve a cargar la página de sampleapp, y haz clic en Canalizaciones.

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

   1. Haz clic en Start Manual Execution (Comenzar ejecución manual).
   2. Selecciona una Tasa de éxito de 80.
   3. Haz clic en Ejecutar.

4. Cuando la canalización llegue a la etapa Manual Judgment (Criterio manual), todavía no hagas clic en Continue (Continuar) ya que debes comparar la versión de detección de fallos con la versión de línea base.

   

5. En Cloud Shell, ejecuta el comando kubectl -n default get pods para ver los pods nuevos etiquetados como detección de fallos y línea base:

   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 Stackdriver, ve a Explorador de métricas.

   EXPLORADOR DE MÉTRICAS

7. Si ya existen métricas configuradas en Explorador de métricas, quita todas las configuraciones existentes de la forma.

8. Selecciona los datos de detección de fallos como primera métrica, y especifica los siguientes parámetros:

   1. Métrica: external.googleapis.com/prometheus/requests

   2. Filtros:

      • http_code es 500
      • pod_name es sampleapp-canary-*
   Nota: Si faltan datos en Stackdriver, espera unos minutos hasta que aparezcan.

9. Para seleccionar los datos de línea base como segunda métrica, haz clic en + Agregar métrica, y completa los siguientes campos:

   1. Métrica: external.googleapis.com/prometheus/requests

   2. Filtros:

      • http_code es 500
      • pod_name es sampleapp-baseline-*

10. Compara la versión de detección de fallos (de color violeta en el siguiente gráfico) con la versión de línea base (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 de detección de fallos tiene una tasa de error más baja que la versión de línea base. Por lo tanto, es seguro implementar por completo la versión de detección de fallos en producción. Si la versión de detección de fallos 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 aplicación.

    Nota: Es posible que debas esperar unos minutos para obtener datos relevantes.

    

11. En Spinnaker, en el diálogo Manual Judgement (Criterio manual), haz clic en Continue (Continuar).

    

12. Cuando se finalice la implementación, vuelve a Explorador de métricas en Stackdriver.

    EXPLORADOR DE MÉTRICAS

13. Si ya existen métricas configuradas en Explorador de métricas, quita todas las configuraciones existentes de la forma.

14. En el campo Encontrar tipo de recurso y métrica, ingresa el siguiente comando:

    external.googleapis.com/prometheus/requests
    

15. En el campo Agrupar según, ingresa http_code. En el siguiente gráfico, la tasa de solicitudes HTTP que respondió la aplicación se divide según el código de estado HTTP:

    

    Este gráfico muestra la tasa de códigos HTTP, 200 y 500, para todos los pods: producción, línea base y detección de fallos. Debido a que la versión de detección de fallos tenía una tasa de error más baja, implementaste esta versión 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 general de errores disminuye: la versión de detección de fallos se implementó correctamente en producción.

Cómo automatizar el análisis de detección de fallos

Una implementación de detección de fallos es útil, pero en la implementación actual es un proceso manual. Debes verificar manualmente que la detección de fallos se comporte como deseas antes de realizar la implementación completa; y la diferencia entre la detección de fallos y la línea base no siempre es clara.

La automatización del análisis de detección de fallos es una buena idea; no debes hacerlo tú mismo y un análisis estadístico automatizado es más adecuado que un análisis humano para detectar problemas en un conjunto de métricas. En esta sección, la etapa Manual Judgement (Criterio manual) se reemplaza con un análisis automatizado de detección de fallos.

Nota: El análisis de detección de fallos no está diseñado para detectar errores o fallas. Detecta la desviación de métricas determinadas y se asegura de que el comportamiento de la versión nueva sea similar a 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 decir que el aumento o la disminución de una métrica es aceptable.

Cómo habilitar la asistencia de detección de fallos

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

1. En Cloud Shell, obtén el ID de tu proyecto.

   echo $GOOGLE_CLOUD_PROJECT
   

2. Obtén un shell en el pod de Halyard.

   export HALYARD_POD=$(kubectl -n spinnaker get pods -l \
       stack=halyard,app=spin \
       -o=jsonpath='{.items[0].metadata.name}')
   kubectl -n spinnaker exec -it $HALYARD_POD -- bash
   

3. Configura Kayenta para utilizar Stackdriver como backend.

   hal config canary google enable
   hal config canary google account add kayenta-tutorial --project [PROJECT_ID]
   hal config canary google edit --stackdriver-enabled=true
   

   donde:

   • [PROJECT_ID] representa el ID del proyecto que recuperas.

4. Aplica la configuración nueva y sal del pod de Halyard.

   hal deploy apply
   exit
   

5. La implementación toma unos minutos en completarse. Para verificar el progreso, ejecuta los comandos watch kubectl -n spinnaker get pods. Cuando se completa la implementación, este comando muestra todos los pods como Ready 1/1. Para detener el comando watch, presiona Ctrl+C.

   NAME                               READY  STATUS   RESTARTS AGE
   minio-deployment-7c665c4b57-prl6d  1/1    Running  0        1h
   spin-clouddriver-6c4f954667-8769c  1/1    Running  0        1h
   spin-deck-7d44499f9b-hkqz4         1/1    Running  0        1h
   spin-echo-6cf4bbbbfc-vxzlr         1/1    Running  0        1h
   spin-front50-7666c894c6-fm7sz      1/1    Running  0        1h
   spin-gate-76f789696d-vsn98         1/1    Running  0        1h
   spin-halyard-59fd54bd69-vb99h      1/1    Running  0        1h
   spin-kayenta-84f6b9b697-5krhh      1/1    Running  0        1m
   spin-orca-78f5c74c6f-srl4f         1/1    Running  0        1h
   spin-redis-6d49c9c5b9-gddgv        1/1    Running  0        1h
   spin-rosco-699cb484f7-grthh        1/1    Running  0        1h
   

Cómo configurar la característica de análisis automatizado de detección de fallos

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

1. En Spinnaker, haz clic en Config (Configuración).

2. En la sección Features (Características), selecciona Canary (Detección de fallos) y, luego, haz clic en Save Changes (Guardar cambios).

   

Cómo crear una configuración de detección de fallos

En Spinnaker, un análisis automatizado de detección de fallos 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 aprobaron o fallaron la comparación entre la línea base y la detección de fallos. 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).

Una aplicación puede tener varias configuraciones de detección de fallos que se pueden compartir en varias aplicaciones. Una configuración de detección de fallos consta de dos elementos principales:

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

En una canalización de implementación, se utiliza una configuración de detección de fallos en la etapa Canary Analysis (Análisis de detección de fallos). Esta etapa puede incluir varias ejecuciones de detección de fallos. 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 aprobado.

Para crear una configuración de detección de fallos, sigue estos pasos:

1. Ahora que la detección de fallos está habilitada, vuelve a cargar Spinnaker. La sección Canalizaciones se reemplaza por Entrega. En la sección Entrega, ve a Configuración de detección de fallos.

2. Haz clic en Agregar configuración.

3. En Nombre de configuración, ingresa kayenta-test.

4. En la sección Plantillas de filtro, haz clic en Agregar plantilla.

5. En el diálogo Agregar plantilla, agrega los siguientes valores y, luego, haz clic en Aceptar:

   • Nombre: http_code
   • Plantilla: metric.labels.http_code = "500" AND resource.label.pod_name = starts_with("${scope}")

   La variable scope se propaga en el entorno de ejecución con el nombre de la Implementación en GKE para la que Kayenta debería estar verificando las métricas. Para la línea base es sampleapp-baseline y en el caso de la detección de fallos es sampleapp-canary.

6. En la sección Métricas, haz clic en Agregar métricas.

7. En el diálogo Agregar métricas, ingresa los siguientes valores y, luego, haz clic en Aceptar:

   • Nombre: error_rate
   • Falló en: increase
   • Plantilla del filtro: http_code
   • Tipo de recurso: k8s_container
   • Tipo de métrica: external.googleapis.com/prometheus/requests
   • Alineador: ALIGN_RATE
   Nota: El Alineador es un parámetro de la API de supervisión de Stackdriver que compara la tasa de cambio de las métricas en lugar de su valor absoluto. La aplicación de este instructivo expone la cantidad total de errores ya que comenzó como una métrica. Kayenta debe comparar si la tasa de esos errores cambia según las dos versiones de la aplicación.

8. En la sección Puntuación, selecciona los siguientes valores:

   • Marginal: 75
   • Aprobado: 95
   • Grupo 1: 100

9. Haz clic en Guardar cambios.

Cómo agregar una etapa de análisis de detección de fallos a la canalización

Ahora que ya tienes una configuración de detección de fallos, modifica tu canalización de implementación existente para reemplazar la etapa Manual Judgment (Criterio manual) por una etapa Canary Analysis (Análisis de detección de fallos) que utilice esta configuración.

Nota: Si cometes un error en esta sección del que no te puedes recuperar, utiliza 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 detección de fallos), haz clic en Configure (Configurar).

   

2. Haz clic en Agregar etapa.

3. En Tipo, selecciona Análisis de detección de fallos.

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

   • Deploy Canary (Implementar detección de fallos)
   • Deploy Baseline (Implementar línea base)

5. Completa la sección Canary Analysis Configuration (Configuración de análisis de detección de fallos) con los siguientes valores:

   Nombre del parámetro	Valor	Definición
   Tipo de análisis	Tiempo real (manual)	El modo automático, en el que la detección de fallos y la línea base se crean para ti aún no está disponible en Kubernetes.
   Nombre de configuración	kayenta-test	El nombre de la configuración de detección de fallos que creaste antes.
   Siempre	0 horas 5 minutos	El tiempo que debería durar el análisis de detección de fallos.
   Retraso	0	El tiempo que le damos a la aplicación para arrancar antes de realizar el análisis.
   Intervalo	5	La ventana de tiempo que debería usar Kayenta para ejecutar un análisis estadístico único.
   Punto de referencia	sampleapp-baseline	La Implementación en GKE que debería usar Kayenta como línea base.
   Ubicación de línea base	Predeterminado	El espacio de nombres en GKE en el que reside la línea base.
   Detección de fallos	sampleapp-canary	La Implementación en GKE que Kayenta debería usar como detección de fallos.
   Ubicación de detección de fallos	Predeterminado	El espacio de nombres en GKE en el que reside la detección de fallos.

   Nota: Un análisis de detección de fallos está compuesto por varias ejecuciones de detección de fallos. Una ejecución de detección de fallos tiene dos partes: una ventana de tiempo (definida por el parámetro de intervalo) durante la 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 de extensión que proporcionaste. Por ejemplo, si configuraste un intervalo de cinco minutos y un período de extensión de una hora, Kayenta realiza 12 ejecuciones de detección de fallos. Para obtener más información sobre la configuración correcta de esos parámetros, consulta las Recomendaciones de la detección de fallos.

6. En la sección Opciones de ejecución, selecciona Ignorar la falla. Ignoras la falla de modo que puedas destruir la línea base y la detección de fallos, aunque el análisis de detección de fallos haya fallado. Más adelante en el instructivo, modificarás las etapas para tener en cuenta una potencial falla de detección de fallos.

7. En el esquema de canalización, haz clic en Deploy to Production (Implementar en producción).

   

8. Cambia la sección Depende de, a los siguientes parámetros:

   1. Agrega Canary Analysis (Análisis de detección de fallos).
   2. Quita Manual Judgment (Criterio manual).

9. Para asegurarte de que solo implementarás en producción si el análisis de detección de fallos es exitoso, cambia el parámetro Condicional según expresión.

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

10. En el esquema de canalización, haz clic en Borrar detección de fallos, y cambia la sección Depende de a los siguientes parámetros:

    1. Agrega Canary Analysis (Análisis de detección de fallos).
    2. Quita Manual Judgment (Criterio manual).

11. En el esquema de canalización, haz clic en Borrar línea base, y cambia la sección Depende de.

    1. Agrega Canary Analysis (Análisis de detección de fallos).
    2. Quita Manual Judgment (Criterio manual).

12. Para asegurarse de que toda la canalización falla si falla el análisis de detección de fallos, haz clic en Successful deployment (Implementación exitosa) en el esquema de canalización y, luego, haz clic en el ícono Editar para la precondición existente.

    

    1. Cambia la Expresión por lo siguiente:

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

    2. Haz clic en Actualizar.

13. Para finalizar, reemplaza la etapa Manual Judgement (Criterio manual) por la etapa Canary Analysis (Análisis de detección de fallos) que creaste recientemente.

    1. En el esquema de canalización, haz clic en Manual Judgment (Criterio manual).
    2. Haz clic en Quitar etapa.

14. Haz clic en Guardar cambios. Ahora la canalización luce como la siguiente imagen:

Cómo probar la canalización nueva

Ahora que el análisis automatizado de detección de fallos está configurado, prueba la canalización para asegurarte de que funciona como se espera.

1. Ve a Entrega > Canalizaciones, y para la canalización Canary Deploy (Implementación de detección de fallos), o Implementación automatizada de detección de datos si utilizas CLI, haz clic en Comenzar ejecución manual.

2. Selecciona una Tasa de éxito de 60, y luego haz clic en Ejecutar.

3. Para verificar el progreso actual del análisis de detección de fallos, haz clic en Canary Analysis (Análisis de detección de fallos), y luego haz clic en Task Status (Estado de la tarea). Luego de unos minutos, la etapa Canary Analysis (Análisis de detección de fallos) falla porque la tasa de éxito actual en producción es de 80. Cuando falla la etapa Canary Analysis (Análisis de detección de fallos), ve al informe de este análisis de detección de fallos.

   1. Haz clic en Canary Analysis (Análisis de detección de fallos).
   2. Haz clic en Canary Summary (Resumen de detección de fallos).

   3. Haz clic en el ícono de Informe. En la página del informe, la tasa de error es más alta en el caso de la versión de detección de fallos que para la versión de línea base.

      

4. Repite los pasos en esta sección, pero selecciona una Tasa de éxito de 90 para lograr un análisis de detección de fallos exitoso.

Limpieza

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

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Todo en el proyecto se borra. Si utilizaste un proyecto existente para este instructivo, cuando lo borres, también borrarás cualquier otro trabajo que hayas realizado en el proyecto.
• Los ID personalizados de proyectos se pierden. 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 de 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 la GCP Console, dirígete a la página Proyectos.

   Ir a la página Proyectos

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, luego, haz clic en Cerrar para borrar el proyecto.

Cómo borrar los recursos

Si deseas conservar el proyecto de GCP que utilizaste para este instructivo, borra los recursos individuales:

1. Desinstala Spinnaker.

   kubectl delete -f https://spinnaker.io/downloads/kubernetes/quick-install.yml
   

2. Borra el clúster de GKE.

   gcloud container clusters delete kayenta-tutorial
   

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

Próximos pasos

• Lee más información sobre Spinnaker.
• Mira cómo Waze y Netflix utilizan Spinnaker y Kayenta.
• Mira todos los recursos sobre la Entrega continua.
• Aprende a usar Spinnaker con Cloud Build y Cloud Source Repositories.
• Revisa un codelab que abarca la Entrega continua en GKE utilizando Spinnaker.
• Consulta spin, una herramienta de CLI para administrar las aplicaciones y canalizaciones de Spinnaker.
• Prueba otras características de Google Cloud Platform tú mismo. Revisa nuestros instructivos.