Despliegues canary en GKE y clústeres de GKE adjuntos mediante redes basadas en servicios

En este documento se describe cómo configurar y usar los lanzamientos canary para desplegar tus aplicaciones en clústeres de GKE o de GKE conectados mediante Cloud Deploy con redes basadas en servicios.

Un despliegue canario es un lanzamiento progresivo de una nueva versión de tu aplicación, en el que aumentas gradualmente el porcentaje de tráfico enviado a la nueva versión mientras monitorizas el rendimiento de la aplicación. De esta forma, podrás detectar posibles problemas con antelación y minimizar el impacto en tus usuarios.

Cómo funcionan los despliegues canary en GKE y en clústeres de GKE adjuntos con redes basadas en servicios

1. Proporciona el nombre del recurso de despliegue y del recurso de servicio.

2. Cloud Deploy crea un recurso Deployment adicional con el nombre de tu recurso Deployment actual más -canary.

Los secretos y los ConfigMaps también se copian y se les cambia el nombre con -canary.

1. Cloud Deploy modifica el servicio para ajustar el selector de forma que seleccione los pods de la implementación actual y los pods canary.

   Cloud Deploy calcula el número de pods que se van a usar en la versión canary en función del cálculo descrito en la sección de aprovisionamiento de pods. Este cálculo varía en función de si habilitas o inhabilitas el aprovisionamiento excesivo de pods.

   Si pasamos a la fase stable, Cloud Deploy añade las etiquetas que se van a usar para que coincidan los pods, de modo que estén disponibles para las ejecuciones canary posteriores.

   Cloud Deploy crea un objeto Deployment que incluye el porcentaje de pods específico de la fase y lo actualiza en cada fase. Para ello, se calcula el número de pods como porcentaje del número original de pods. Esto puede provocar una división del tráfico inexacta. Si necesitas una división exacta del tráfico, puedes conseguirlo con la API Gateway.

2. Durante la fase stable, la implementación -canary se reduce a cero y la implementación original se sustituye por la nueva.

   Cloud Deploy no modifica la implementación original hasta la fase stable, a menos que inhabilite el aprovisionamiento excesivo.

Cloud Deploy aprovisiona pods para alcanzar el porcentaje de canary solicitado de la forma más precisa posible. Se basa en el número de pods, no en el tráfico a los pods. Si quieres que tu lanzamiento canary se base en el tráfico, debes usar la API Gateway.

En el caso de la versión canary basada en la red de GKE, puedes habilitar o inhabilitar el aprovisionamiento excesivo de pods. En las secciones siguientes se describe cómo calcula Cloud Deploy el número de pods que se deben aprovisionar para la implementación canary en cada fase de la implementación.

Aprovisionamiento de pods con sobreaprovisionamiento habilitado

Si habilitas el aprovisionamiento excesivo (disablePodOverprovisioning: false), Cloud Deploy podrá crear suficientes pods adicionales para ejecutar el porcentaje de versión canary que quieras, en función del número de pods que ejecuten tu implementación. La siguiente fórmula muestra cómo calcula Cloud Deploy el número de pods que se deben aprovisionar para la implementación canary de cada fase canary cuando el sobreaprovisionamiento de pods está habilitado:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Con esta fórmula, el número de réplicas actual (el número de pods que ya tienes antes de esta versión canary) se multiplica por el porcentaje de la fase canary y el resultado se divide entre (100 menos el porcentaje).

Por ejemplo, si ya tienes 4 pods y tu fase canary es del 50%, el número de pods canary será 4. El resultado de 100-percentage se usa como porcentaje: 100-50=50, que se trata como .50.

Advertencia: Si se usan porcentajes de canary superiores al 50 %, el número de pods puede aumentar considerablemente. En el ejemplo anterior, con 4 pods, una versión canary del 90% dará como resultado 36 pods canary. Por este motivo, si quieres usar porcentajes superiores al 50%, te recomendamos que inhabilites el aprovisionamiento excesivo, tal como se describe en la siguiente sección.

El sobreaprovisionamiento de pods es el comportamiento predeterminado.

Aprovisionamiento de pods con el aprovisionamiento excesivo inhabilitado

Puedes inhabilitar el aprovisionamiento excesivo (disablePodOverprovisioning: true) para asegurarte de que Cloud Deploy no aumente el número de réplicas.

La siguiente fórmula muestra cómo calcula Cloud Deploy el aprovisionamiento de pods para la implementación canary de cada fase canary cuando el sobreaprovisionamiento de pods está inhabilitado:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

En esta fórmula, ReplicaCountOfCanaryDeploymentOnCluster solo existe si ya había una fase canary. Si es la primera fase canary, no hay ReplicaCountOfCanaryDeploymentOnCluster.

Si empiezas con 4 pods, ese número se multiplica por el porcentaje de lanzamiento canary (por ejemplo, el 50 % o .5) para obtener 2. Por lo tanto, la implementación original se reduce a 2 y se crean 2 pods para la implementación canaria. Si tienes una fase canary del 75 %, tendrás 2 (despliegue original) +2 (primera fase canary), *.75, para obtener 3 pods canary y 1 pod que ejecuten el despliegue original.

Con Cloud Deploy, puedes configurar implementaciones canary en clústeres de GKE y clústeres adjuntos de GKE en una sola fase o en varias.

Las instrucciones que se incluyen aquí solo hacen referencia a la configuración de la versión canary. En el documento Desplegar en un clúster de Google Kubernetes Engine se incluyen las instrucciones generales para configurar y ejecutar tu flujo de procesamiento de despliegue.

Comprueba que tienes los permisos necesarios

Además de otros permisos de gestión de identidades y accesos que necesitas para usar Cloud Deploy, debes tener los siguientes permisos para realizar acciones adicionales que pueden ser necesarias para una implementación canaria:

• clouddeploy.rollouts.advance
• clouddeploy.rollouts.ignoreJob
• clouddeploy.rollouts.cancel
• clouddeploy.rollouts.retryJob
• clouddeploy.jobRuns.get
• clouddeploy.jobRuns.list
• clouddeploy.jobRuns.terminate

Consulta Roles y permisos de gestión de identidades y accesos para obtener más información sobre los roles disponibles que incluyen estos permisos.

Prepara tu skaffold.yaml

El archivo skaffold.yaml define cómo se renderizan y se despliegan los manifiestos de Kubernetes. Para que una implementación canary en GKE o en clústeres adjuntos de GKE funcione correctamente, asegúrate de que apunta a tus manifiestos y define los artefactos de compilación necesarios. No se requiere ninguna configuración específica de la versión canary en skaffold.yaml, más allá de lo que se necesita para un despliegue estándar. Puedes usar perfiles de Skaffold para gestionar diferentes variaciones de manifiesto para fases canary personalizadas.

Preparar los manifiestos de Kubernetes

Tus manifiestos de Kubernetes deben incluir un recurso Deployment y un recurso Service. El Service debe definir un selector que coincida con las etiquetas de los pods gestionados por el Deployment. La etiqueta predeterminada que busca Cloud Deploy es app, pero se puede configurar en la canalización.

Configurar una versión canary automatizada

Configura una versión canary automatizada directamente en la definición de tu flujo de procesamiento de entrega para una fase específica de clústeres de GKE o de GKE adjuntos mediante la red de servicios estándar de Kubernetes.

En la fase de la canalización, incluya una propiedad strategy de la siguiente manera:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

En esta configuración...

• SERVICE_NAME es el nombre del servicio de Kubernetes, definido en tu manifiesto.

• DEPLOYMENT_NAME es el nombre de tu implementación de Kubernetes, definida en tu manifiesto.

• LABEL es una etiqueta de selector de pods. Debe coincidir con el selector de etiquetas del servicio de Kubernetes definido en el manifiesto. Esto es opcional. El valor predeterminado es app.

• PERCENTAGES es una lista separada por comas de valores de porcentaje que representan tus incrementos de lanzamiento canary. Por ejemplo, [5, 25, 50].

  Además, no incluye 100, ya que en la versión canary se supone que la implementación es del 100% y se gestiona en la fase stable.

• Puedes habilitar la verificación de la implementación (verify: true). Si lo haces, se habilitará un trabajo verify en cada fase.

• PREDEPLOY_ACTION

  Es el mismo ACTION_NAME que has usado en tu skaffold.yaml para definir la acción personalizada que quieres ejecutar antes de la implementación.

• POSTDEPLOY_ACTION

  Es el mismo ACTION_NAME que has usado en tu skaffold.yaml para definir la acción personalizada que quieres ejecutar después de la implementación.

Configurar un lanzamiento canary personalizado y automatizado

Una versión canary personalizada y automatizada combina la definición de fases personalizadas (nombres, porcentajes, perfiles, verificación y ganchos) con la gestión automática del tráfico de Cloud Deploy para clústeres de GKE o clústeres adjuntos de GKE. Tú defines las fases, pero Cloud Deploy gestiona la manipulación de los recursos subyacentes en función de los porcentajes y el runtimeConfig elegido.

Para configurar un lanzamiento canary personalizado y automatizado, incluye una sección runtimeConfig con serviceNetworking y la sección customCanaryDeployment (que define phaseConfigs) en el bloque strategy.canary. Cloud Deploy utiliza los perfiles de Skaffold especificados para el renderizado, pero ajusta automáticamente el tráfico según los porcentajes de runtimeConfig y de fase.

serialPipeline:
  stages:
  - targetId: gke-prod
    profiles: []
    strategy:
      canary:
        # Include runtimeConfig for automatic traffic management
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "my-app"
              deployment: "my-deployment"
        # Include customCanaryDeployment for phase customization
        customCanaryDeployment:
          phaseConfigs:
          - phaseId: "warmup"
            percentage: 10
            profiles: ["profile-a"] # Profile used for rendering this phase
            verify: true
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify: true
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify: true

Ejecutar el canary de GKE o de clústeres de GKE adjuntos

1. Registra la canalización y los destinos: aplica los archivos de configuración de la canalización de distribución y de los clústeres de GKE o de GKE adjuntos.

   
   gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
   gcloud deploy apply --file=gke-targets.yaml --region=REGION
   

   El flujo de procesamiento de entrega incluye la configuración canary automatizada o personalizada del tiempo de ejecución que elijas.

2. Crea un lanzamiento: inicia la implementación y proporciona el nombre de la imagen.

   
   gcloud deploy releases create RELEASE_NAME \
                                   --delivery-pipeline=PIPELINE_NAME \
                                   --region=REGION
     # e.g., --images=my-cloudrun-service=gcr.io/my-project/my-app:v1.1
     # Add --skaffold-file or --source if not using default Skaffold config discovery
   

   El flujo de procesamiento de entrega identificado por PIPELINE_NAME contiene la configuración canary automatizada o personalizada que se describe en este documento.

3. Avanzar el lanzamiento canary:

   CLI de gcloud

   gcloud deploy rollouts advance ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION
   

   Donde:

   ROLLOUT_NAME es el nombre del lanzamiento actual al que vas a pasar a la siguiente fase.

   RELEASE_NAME es el nombre de la versión a la que pertenece este lanzamiento.

   PIPELINE_NAME es el nombre de la canalización de entrega que estás usando para gestionar la implementación de esta versión.

   REGION es el nombre de la región en la que se creó la versión, por ejemplo, us-central1. Este campo es obligatorio.

   Consulta la referencia del SDK de Google Cloud para obtener más información sobre el comando gcloud deploy rollouts advance.

   Google Cloud consola

   1. Abre la página de canalizaciones de entrega.

   2. Haga clic en la canalización que aparece en la lista de canalizaciones de entrega.

      La página de detalles del flujo de procesamiento de entrega muestra una representación gráfica del progreso del flujo de procesamiento de entrega.

   3. En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haga clic en el nombre del lanzamiento.

      Se muestra la página de detalles del lanzamiento.

      

      En este ejemplo, la implementación tiene una fase canary-50 y una fase stable. Tu lanzamiento puede tener más fases o fases diferentes.

   4. Haz clic en Avanzar lanzamiento.

      El lanzamiento pasa a la siguiente fase.

Fases omitidas

Si despliegas una versión canary y tu aplicación aún no se ha desplegado en ese tiempo de ejecución, Cloud Deploy se saltará la fase canary y ejecutará la fase estable. Consulta la sección Saltar fases la primera vez para saber por qué ocurre esto.

Siguientes pasos

• Prueba la guía de inicio rápido de la implementación canary.

• Consulta cómo gestionar el ciclo de vida de las implementaciones de tu versión canary.

• Más información sobre la implementación paralela

• Consulta más información sobre las estrategias de despliegue de Cloud Deploy.