Se usó la API de Cloud Translation para traducir esta página.

Implementaciones de versiones canary en GKE y GKE Enterprise con redes basadas en servicios

En este documento, se describe cómo configurar y usar las implementaciones de versiones canary para implementar tus aplicaciones en GKE o GKE Enterprise con Cloud Deploy y redes basadas en servicios.

Una implementación de versiones canary es un lanzamiento progresivo de una nueva versión de tu aplicación, en el que aumentas gradualmente el porcentaje de tráfico que se envía a la nueva versión mientras supervisas el rendimiento de la aplicación. Esto te ayuda a detectar posibles problemas con anticipación y minimizar el impacto en tus usuarios.

Cómo funcionan las implementaciones canary para GKE y GKE Enterprise con redes basadas en servicios

Proporcionas el nombre del recurso de Deployment y el recurso de Service.
Cloud Deploy crea un recurso de Deployment adicional con el nombre de tu Deployment actual más -canary.

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

Cloud Deploy modifica el servicio para ajustar el selector y seleccionar los Pods en la Deployment actual y los Pods de la versión canary.

Cloud Deploy calcula la cantidad de pods que se usarán para la versión canary según el cálculo que se describe en la sección de aprovisionamiento de pods. Ese cálculo difiere según si habilitas o inhabilitas el aprovisionamiento excesivo de pods.

Si omitimos la fase de stable, Cloud Deploy agrega las etiquetas que se usarán para hacer coincidir los Pods, de modo que estén disponibles para las ejecuciones posteriores de la versión canary.

Cloud Deploy crea una Deployment que incluye el porcentaje de Pods específico de la fase y lo actualiza para cada fase. Para ello, se calcula la cantidad de pods como un porcentaje de la cantidad original de pods. Esto puede generar una división del tráfico inexacta. Si necesitas una división de tráfico exacta, puedes lograrlo con la API de Gateway.
Durante la fase stable, la Deployment de -canary se reduce a cero y la Deployment original se reemplaza por la nueva.

Cloud Deploy no modifica la Deployment original hasta la fase stable, a menos que inhabilites el aprovisionamiento excesivo.

Cloud Deploy aprovisiona pods para alcanzar el porcentaje de versión canary solicitado de la manera más precisa posible. Esto se basa en la cantidad de Pods, no en el tráfico hacia ellos. Si deseas que tu versión canary se base en el tráfico, debes usar la API de 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 siguientes secciones, se describe cómo Cloud Deploy calcula la cantidad de Pods que se aprovisionarán para la implementación de versiones canary en cada fase de la versión canary.

Aprovisionamiento de Pod con aprovisionamiento excesivo habilitado

Habilitar el aprovisionamiento excesivo (disablePodOverprovisioning: false) permite que Cloud Deploy cree suficientes Pods adicionales para ejecutar el porcentaje de versión canary que desees, según la cantidad de Pods que ejecutan tu implementación existente. La siguiente fórmula muestra cómo Cloud Deploy calcula la cantidad de Pods que se aprovisionarán para la implementación de versiones canary en cada fase de canary cuando se habilita el aprovisionamiento excesivo de Pods:

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

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

Por ejemplo, si ya tienes 4 pods y tu fase de lanzamiento de la versión canary es del 50%, la cantidad de pods de la versión canary es 4. (El resultado de 100-percentage se usa como porcentaje: 100-50=50, que se trata como .50).

El aprovisionamiento excesivo de Pods es el comportamiento predeterminado.

Aprovisionamiento de Pod con el aprovisionamiento excesivo inhabilitado

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

La siguiente fórmula muestra cómo Cloud Deploy calcula el aprovisionamiento de pods para la implementación de versiones canary en cada fase de la versión canary cuando la provisión excesiva de pods está inhabilitada:

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

En esta fórmula, ReplicaCountOfCanaryDeploymentOnCluster solo existe si ya hubo una fase de lanzamiento canary. Si esta es la primera fase de la versión canary, no hay ReplicaCountOfCanaryDeploymentOnCluster.

Si comienzas con 4 pods, ese número se multiplica por el porcentaje de la versión canary (por ejemplo, el 50% o .5) para obtener 2. Por lo tanto, la implementación original ahora se reduce a 2, y se crean 2 pods nuevos para la implementación de versiones canary. Si luego tienes una etapa canary del 75%, tendrás 2 (implementación original) +2 (primera etapa canary), *.75, para obtener 3 pods canary y 1 pod que ejecutan la implementación original.

Con Cloud Deploy, puedes configurar implementaciones de versiones canary en GKE y GKE Enterprise en una sola etapa o en varias.

Las instrucciones que se incluyen aquí solo abarcan lo específico de la configuración de la versión canary. En el documento Implementa en un clúster de Google Kubernetes Engine, se incluyen las instrucciones generales para configurar y ejecutar tu canalización de implementación.

Asegúrate de tener los permisos necesarios

Además de otros permisos de Identity and Access Management que necesitas para usar Cloud Deploy, necesitas los siguientes permisos para realizar acciones adicionales que podrían ser necesarias para una implementación de versiones canary:

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 IAM para obtener más información sobre qué roles disponibles incluyen estos permisos.

Prepara tu `skaffold.yaml`

Tu archivo skaffold.yaml define cómo se renderizan y se implementan tus manifiestos de Kubernetes. Para que una implementación de versiones canary en GKE o GKE Enterprise funcione correctamente, asegúrate de que apunte correctamente a tus manifiestos y defina los artefactos de compilación necesarios. No se requiere ninguna configuración especial específica de la versión canary en skaffold.yaml más allá de lo que se necesita para una implementación estándar. Puedes usar perfiles de Skaffold para administrar diferentes variaciones de manifiestos para las fases de lanzamiento de versiones canary personalizadas.

Prepara tus 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 administrados por el Deployment. La etiqueta predeterminada que busca Cloud Deploy es app, pero se puede configurar en la canalización.

Configura una versión canary automatizada

Configura una versión canary automatizada directamente en la definición de tu canalización de entrega para una etapa específica de GKE o GKE Enterprise con redes de servicio de Kubernetes estándar.

En la etapa de la canalización, incluye 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, se dan las siguientes situaciones:

SERVICE_NAME es el nombre del servicio de Kubernetes, definido en tu manifiesto.
DEPLOYMENT_NAME es el nombre de tu Deployment de Kubernetes, definido en tu manifiesto.
LABEL es una etiqueta del selector de Pods. Debe coincidir con el selector de etiquetas del servicio de Kubernetes definido en tu 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 la versión canary, por ejemplo, [5, 25, 50].

Además, no incluye 100, ya que se supone una implementación del 100% en la versión canary, y la fase stable se encarga de ello.
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 que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.
POSTDEPLOY_ACTION

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

Configura una versión canary personalizada

Puedes configurar tu versión canary de forma manual en lugar de depender por completo de la automatización que proporciona Cloud Deploy. Con la configuración personalizada de la versión canary, puedes especificar lo siguiente en la definición de tu canalización de entrega:

Nombres de las fases de lanzamiento

En una versión canary completamente automatizada, Cloud Deploy nombra las fases por ti (canary-25, canary-75, stable, por ejemplo). Sin embargo, con una versión canary personalizada, puedes asignar cualquier nombre a cada fase, siempre que sea único entre todas las fases de esta etapa de la versión canary y cumpla con las restricciones de ID de recursos. Sin embargo, el nombre de la fase final (100%) debe ser stable.
Objetivos de porcentaje para cada fase

Especifica los porcentajes por separado, por fase.
Perfiles de Skaffold que se usarán para la fase

Puedes usar un perfil de Skaffold independiente para cada fase, el mismo perfil o cualquier combinación. Además, cada perfil puede usar un manifiesto de Kubernetes diferente. También puedes usar más de un perfil para una fase determinada. Cloud Deploy los combina.
Indica si hay un trabajo de verificación para la fase.

Recuerda que, si habilitas la verificación, también debes configurar tu skaffold.yaml para la verificación.
Indica si hay trabajos previos o posteriores a la implementación para la fase.

Si habilitas trabajos previos a la implementación o posteriores a ella, debes configurar tu skaffold.yaml para esos trabajos.

Todos los tipos de destino son compatibles con la versión canary personalizada.

Elementos de configuración de versión canary personalizados

En el siguiente código YAML, se muestra la configuración de las fases de la implementación de canary completamente personalizada:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

En este archivo YAML

PHASE1_NAME

Es el nombre de la fase. Cada nombre de fase debe ser único.
[ "PROFILE_NAME" ]

Es el nombre del perfil que se usará para la fase. Puedes usar el mismo perfil para cada fase, uno diferente para cada una o cualquier combinación. También puedes especificar más de un perfil. Cloud Deploy usa todos los perfiles que especificas, además del perfil o manifiesto que usa la etapa general.
stable

La fase final debe llamarse stable.
PERCENTAGE1

Es el porcentaje de la implementación para la primera fase. Cada fase debe tener un valor de porcentaje único, y ese valor debe ser un porcentaje entero (no 10.5, por ejemplo), y las fases deben estar en orden ascendente.
verify: true|false

Indica a Cloud Deploy si se debe incluir un trabajo de verificación para la fase. Ten en cuenta que, para que cada fase use la verificación, Skaffold usa el mismo perfil de verificación que se especifica para la renderización y la implementación de esa fase.
PREDEPLOY_ACTION

Es el mismo que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.
POSTDEPLOY_ACTION

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

El porcentaje de la última fase debe ser 100. Las fases se ejecutan en el orden en que las configures en esta sección customCanaryDeployment, pero si los valores de porcentaje no están en orden ascendente, el comando para registrar la canalización de entrega falla con un error.

Ten en cuenta que la configuración de una versión canary personalizada no incluye una sección runtimeConfig. Si incluyes runtimeConfig, se considera una versión canary basada en un servicio personalizado.

Configura una versión canary personalizada y automatizada

Esto combina la definición de fases personalizadas (nombres, porcentajes, perfiles, verificación, hooks) con la administración automática del tráfico de Cloud Deploy para GKE o GKE Enterprise. Tú defines las fases, pero Cloud Deploy controla la manipulación de recursos subyacentes según los porcentajes y el runtimeConfig elegido.

Para configurar esto, incluye una sección runtimeConfig con serviceNetworking y la sección customCanaryDeployment (que define phaseConfigs) dentro del bloque strategy.canary. Cloud Deploy usará los perfiles de Skaffold especificados para la renderización, pero ajustará 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

Ejecuta la versión canary de GKE o GKE Enterprise

Registra la canalización y los destinos: Aplica los archivos de configuración de tu canalización de entrega y de destino de GKE o GKE Enterprise.
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=gke-targets.yaml --region=REGION
```
La canalización de entrega incluye la configuración de versión canary automatizada o personalizada para el entorno de ejecución que elegiste.

Crea una versión: 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

La canalización de entrega identificada por PIPELINE_NAME contiene la configuración de versión canary automatizada o personalizada que se describe en este documento.

Avanza la versión canary:
gcloud CLI
```
gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION
```
Aquí:

ROLLOUT_NAME es el nombre de la versión actual que avanzará a la siguiente fase.

RELEASE_NAME es el nombre de la versión de la que forma parte esta implementación.

PIPELINE_NAME es el nombre de la canalización de entrega que usas para administrar 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 console
1. Abre la página Canalizaciones de entrega.
2. Haz clic en tu canalización que se muestra en la lista de canalizaciones de entrega.
  
  En la página Detalles de la canalización de entrega, se muestra una representación gráfica del progreso de tu canalización de entrega.
3. En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre de tu lanzamiento.
  
  Se muestra la página de detalles del lanzamiento.
  
  Observa que, en este ejemplo, la versión tiene una fase canary-50 y una fase stable. Es posible que tu lanzamiento tenga más fases o fases diferentes.
4. Haz clic en Adelantar lanzamiento.
  
  El lanzamiento avanza a la siguiente fase.

Fases omitidas

Si implementas una versión canary y tu aplicación aún no se implementó en ese entorno de ejecución, Cloud Deploy omitirá la fase canary y ejecutará la fase estable. Consulta Cómo omitir fases la primera vez para saber por qué sucede esto.

¿Qué sigue?

Prueba la guía de inicio rápido de la implementación canary.
Descubre cómo administrar el ciclo de vida de las versiones de prueba de tus lanzamientos.
Obtén más información sobre la implementación en paralelo.
Obtén más información sobre las estrategias de implementación de Cloud Deploy.