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.

Arquitectura de la aplicación

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

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

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).

    Ícono de vista previa web para el puerto 8080.

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).

    Crea el menú desplegable de la aplicación

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

    • Nombre: sampleapp
    • Correo electrónico del propietario: [example@example.com]

  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 -d@simple-deploy.json -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).

    Comienza la ejecución manual de la canalización de implementación simple

  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:

    Gráfico de solicitudes HTTP que respondió la aplicación

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:

Ilustraciones de las etapas de una canalización de implementación de detección de fallos

  • 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.

  • 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.

    Etapa Manual judgement (Criterio manual) de la canalización de detección de fallos

  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-*
  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.

    Gráfico que compara la tasa de error de la detección de fallos con la versión de línea base

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

    Etapa Manual judgement (Criterio manual) de la canalización de detección de fallos

  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:

    Gráfico que compara la tasa de solicitudes 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.

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).

    Captura de pantalla de las características de la canalización

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
  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.

  1. Ve a Entrega > Canalizaciones, y para la canalización Canary Deploy (Implementación de detección de fallos), haz clic en Configure (Configurar).

    Captura de pantalla del botón de configuración para la implementación de detección de fallos

  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.
  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).

    Captura de pantalla del botón Deploy to Production (Implementación en producción) para la canalizació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.

    Edita la precondición existente de la implementación exitosa

    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:Visualización de la canalización del análisis de detección de fallos

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.

      Ícono de informe del resumen de análisis de detección de fallos

  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:

  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

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...