Despliegues canary en GKE y GKE Enterprise con la API Gateway

En este documento se describe cómo configurar y usar los lanzamientos canary para desplegar tus aplicaciones en GKE o GKE Enterprise mediante Cloud Deploy con malla de servicios de la API Gateway de Kubernetes.

Un despliegue canary 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 GKE Enterprise con la API Gateway

1. Además de las referencias a Deployment y Service, proporciona un recurso HTTPRoute con una regla backendRefs que hace referencia al Service.

2. Cloud Deploy crea un nuevo Deployment con el nombre del Deployment original más -canary, así como un nuevo Service con el nombre del Service original más -canary.

   Los secretos, los ConfigMaps y los autoescaladores de pods horizontales también se copian y se les cambia el nombre con -canary.

3. En cada fase de lanzamiento de la versión canary, Cloud Deploy modifica el objeto HTTPRoute para actualizar la ponderación entre los pods de la implementación original y los de la implementación canary, en función del porcentaje de esa fase.

   Como puede haber un retraso en la propagación de los cambios en los recursos de HTTPRoute, puede incluir la propiedad routeUpdateWaitTime en su configuración para que el sistema espere un periodo determinado a que se produzca la propagación.

4. Durante la fase stable, la -canary se reduce a cero y la implementación original se actualiza para usar la implementación de la nueva versión.

   Además, el HTTPRoute se ha revertido al original que proporcionaste.

   Cloud Deploy no modifica el Deployment ni el Service originales hasta la fase stable.

Con Cloud Deploy, puedes configurar implementaciones canarias en GKE y GKE Enterprise en una o varias fases.

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, necesitas 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

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

Prepara tu skaffold.yaml

El archivo skaffold.yaml define cómo se renderizan y se implementan los manifiestos de Kubernetes. Para que una implementación canary en GKE o GKE Enterprise funcione correctamente, asegúrate de que apunte 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 una implementación estándar. Puedes usar perfiles de Skaffold para gestionar diferentes variaciones de manifiesto en fases canary personalizadas.

Prepara tus archivos de manifiesto 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.

Además de Deployment y Service, tus archivos de manifiesto deben incluir un recurso HTTPRoute configurado para la división del tráfico, que haga referencia a Service y a la pasarela asociada.

Configurar una versión canary automatizada

Usa la API de Kubernetes Gateway (con Istio o cualquier implementación compatible) para dividir el tráfico de forma precisa y basada en porcentajes, gestionado por la malla o la pasarela y orquestado por Cloud Deploy.

1. Configura los recursos de la API Gateway: asegúrate de que tu Gateway y la malla de servicios subyacente (por ejemplo, Istio) o el controlador de Gateway estén configurados correctamente en tus clústeres.

   • Usar Istio

   • Controlador de GKE Gateway

2. En el archivo de manifiesto de Kubernetes que proporcionaste a Cloud Deploy al crear la versión, incluye lo siguiente:

   • Un HTTPRoute que hace referencia a tu recurso Gateway

   • Una implementación

   • Un servicio

3. Configura tu flujo de procesamiento de entrega y el destino al que vas a hacer el lanzamiento canary:

   • La configuración del destino es la misma que la de cualquier otro destino.

   • La configuración de la canalización de entrega, en la secuencia de progresión del destino específico, incluye una sección gatewayServiceMesh para hacer referencia a la configuración de la API Gateway de Kubernetes HTTPRoute, así como a tu implementación y servicio.

     strategy:
      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "ROUTE"
              service: "SERVICE"
              deployment: "DEPLOYMENT"
              routeUpdateWaitTime: "WAIT_TIME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages:
          - 50
     

     ¿Dónde...?

     • ROUTE es la configuración de httpRoute que define el comportamiento de enrutamiento que quieres.

     • SERVICE es la configuración de tu servicio, que Cloud Deploy necesita para los despliegues canary en GKE y GKE Enterprise.

     • DEPLOYMENT es la configuración de tu despliegue, que Cloud Deploy requiere para los despliegues canary en GKE y GKE Enterprise.

     • WAIT_TIME es el tiempo que Cloud Deploy espera a que se propaguen los cambios en el recurso HTTPRoute para evitar que se pierdan solicitudes. Por ejemplo: routeUpdateWaitTime: 60s.

       Si ejecutas la versión canary con la API Gateway sin Istio y la API Gateway está conectada a un balanceador de carga, es posible que se pierda una pequeña cantidad de tráfico cuando se reduzca la escala de la instancia canary. Google Cloud Puedes configurar este ajuste si observas este comportamiento.

     • LABEL es una etiqueta de selector de pods. Debe coincidir con el selector de etiquetas del servicio y el deployment de Kubernetes definidos en tu archivo de manifiesto. Este paso es opcional. El valor predeterminado es app.

Configurar un lanzamiento canary personalizado y automatizado

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 GKE o GKE Enterprise. Tú defines las fases, pero Cloud Deploy gestiona la manipulación de recursos subyacente en función de los porcentajes y el runtimeConfig elegido.

Para configurar esta opción, incluye una sección runtimeConfig con serviceNetworking y la sección customCanaryDeployment (que define phaseConfigs) en el bloque strategy.canary. Cloud Deploy usará los perfiles de Skaffold especificados para el renderizado, 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:
            gatewayServiceMesh:
              httpRoute: "my-route"
              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

Desplegar un HTTPRoute en otro clúster

Si tienes un lanzamiento canary configurado con una malla de servicios de la API Gateway, puedes especificar un clúster alternativo que no sea el de destino en el que desplegar la HTTPRoute.

Para ello, usa una sección routeDestinations en la configuración de tu estrategia canary para identificar el clúster o los clústeres de destino de la HTTPRoute y un ajuste booleano para propagar el servicio al mismo clúster que no es de destino. Además, debes crear una estrofa associatedEntities en la configuración de destino para identificar los clústeres.

1. Configura associatedEntities en tu objetivo.

   Cada entidad es un clúster en el que Cloud Deploy desplegará el objeto HTTPRoute y, opcionalmente, el objeto Service de Kubernetes. En la definición de destino, incluye una estrofa associatedEntities:

   associatedEntities:
     [KEY]:
       gkeClusters:
       - cluster: [PATH]
         dnsEndpoint: [true|false]
         internalIp: [true|false]
         proxyUrl:
   

   Donde:

   • KEY es un nombre arbitrario para este grupo de entidades asociadas. Usarás este nombre para hacer referencia a las entidades desde el routeDestinations de tu configuración canary.

   • PATH es la ruta del recurso que identifica el clúster de GKE en el que se desplegará tu HTTPRoute (y, opcionalmente, el servicio).

   • dnsEndpoint indica si se debe usar el endpoint DNS del clúster o no si se han configurado varios endpoints. El valor predeterminado es false.

   • internalIp indica si se debe usar la IP interna (IP privada) del clúster si se han configurado varios endpoints. El valor predeterminado es false.

   Puedes incluir el número de clústeres que quieras, con o sin internalIp.

2. Configura routeDestinations en tu configuración de versión canary.

   Cada destino de ruta hace referencia a una sección associatedEntities e indica si se debe implementar el servicio en el clúster alternativo. Añade lo siguiente en la estrofa gatewayServiceMesh de tu archivo de configuración de la versión canary:

   routeDestinations:
     destinationIds: ["KEY"]
     propagateService: [true|false]
   

   Donde:

   • KEY es el nombre que ha configurado en el objetivo, en associatedEntities. Usa este nombre para hacer referencia a las entidades del routeDestinations en tu configuración canary.

     También puede proporcionar el valor @self para implementar la HTTPRoute en el clúster de destino, además del destino asociado.

   • propagateService indica si quieres desplegar el servicio en el clúster asociado, además de en HTTPRoute. El valor predeterminado es false.

Ejecuta el canary de GKE o GKE Enterprise

1. Registra la canalización y los destinos: aplica los archivos de configuración de la canalización de entrega y del destino de GKE o GKE Enterprise.

   
   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 la versión 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 distribución 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 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. Es posible que tu lanzamiento tenga 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 en paralelo

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