Déploiements Canary sur GKE et les clusters associés à GKE à l'aide de la mise en réseau de l'API Gateway

Ce document explique comment configurer et utiliser des déploiements Canary pour déployer vos applications sur des clusters GKE ou GKE associés à l'aide de Cloud Deploy avec Kubernetes Gateway API service mesh.

Un déploiement Canary est un déploiement progressif d'une nouvelle version de votre application, dans lequel vous augmentez progressivement le pourcentage de trafic envoyé à la nouvelle version, tout en surveillant les performances de l'application. Cela vous permet de détecter rapidement les problèmes potentiels et de minimiser leur impact sur vos utilisateurs.

Fonctionnement des déploiements Canary pour les clusters GKE et GKE associés à l'aide de l'API Gateway

  1. En plus des références de déploiement et de service, vous fournissez une ressource HTTPRoute, avec une règle backendRefs qui fait référence au service.

  2. Cloud Deploy crée un déploiement avec le nom de votre déploiement d'origine plus -canary, et un service avec le nom de service d'origine plus -canary.

    Les secrets, les ConfigMaps et les autoscalers horizontaux de pods sont également copiés et renommés avec -canary.

  3. Pour chaque phase Canary, Cloud Deploy modifie la ressource HTTPRoute afin de mettre à jour la pondération entre les pods du déploiement d'origine et ceux du déploiement Canary, en fonction du pourcentage de cette phase.

    Étant donné qu'il peut y avoir un délai de propagation des modifications aux ressources HTTPRoute, vous pouvez inclure la propriété routeUpdateWaitTime dans votre configuration. Le système attendra alors un délai spécifié pour cette propagation.

  4. Pendant la phase stable, le déploiement -canary est réduit à zéro, et le déploiement d'origine est mis à jour pour utiliser le déploiement de la nouvelle version.

    De plus, la ressource HTTPRoute est maintenant rétablie à la valeur d'origine que vous avez fournie.

    Cloud Deploy ne modifie pas le déploiement ni le service d'origine avant la phase stable.

Avec Cloud Deploy, vous pouvez configurer des déploiements Canary sur des clusters GKE et GKE associés en une seule ou plusieurs étapes.

Les instructions fournies ici ne concernent que la configuration Canary. Le document Déployer sur un cluster Google Kubernetes Engine contient les instructions générales pour configurer et exécuter votre pipeline de déploiement.

Assurez-vous de disposer des autorisations requises.

En plus des autres autorisations Identity and Access Management dont vous avez besoin pour utiliser Cloud Deploy, vous devez disposer des autorisations suivantes pour effectuer des actions supplémentaires qui peuvent être nécessaires pour un déploiement Canary :

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

Consultez les rôles et les autorisations IAM pour en savoir plus sur les rôles disponibles qui incluent ces autorisations.

Préparer votre fichier skaffold.yaml

Votre fichier skaffold.yaml définit la façon dont vos fichiers manifestes Kubernetes sont rendus et déployés. Pour un déploiement Canary sur des clusters GKE ou GKE associés, assurez-vous que le fichier skaffold.yaml pointe correctement vers vos fichiers manifestes et définit tous les artefacts de compilation nécessaires. Aucune configuration spéciale spécifique à Canary n'est requise dans skaffold.yaml au-delà de ce qui est nécessaire pour un déploiement standard. Vous pouvez également utiliser des profils Skaffold pour gérer différentes variantes de fichiers manifestes pour les phases Canary personnalisées.

Préparer vos fichiers manifestes Kubernetes

Vos fichiers manifestes Kubernetes doivent inclure une ressource Deployment et une ressource Service. La ressource Service doit définir un selector qui correspond aux étiquettes des pods gérés par la ressource Deployment. L'étiquette par défaut que Cloud Deploy recherche est app, mais elle peut être configurée dans le pipeline.

En plus des ressources Deployment et Service, vos fichiers manifestes doivent inclure une ressource HTTPRoute configurée pour la répartition du trafic, faisant référence à la ressource Service et à la passerelle associée.

Configurer un déploiement Canary automatisé

Utilisez l'API Kubernetes Gateway (avec Istio ou toute implémentation compatible) pour une répartition précise du trafic basée sur un pourcentage, gérée par le maillage/la passerelle, orchestrée par Cloud Deploy.

  1. Configurer les ressources de l'API Gateway : assurez-vous que votre passerelle et le maillage de services sous-jacent (par exemple, Istio) ou le contrôleur de passerelle sont correctement configurés dans vos clusters.

  2. Dans votre fichier manifeste Kubernetes, fourni à Cloud Deploy lorsque vous avez créé la version, incluez les éléments suivants :

    • Une HTTPRoute qui fait référence à votre ressource Gateway

    • Un déploiement

    • Un service

  3. Configurez votre pipeline de diffusion et la cible vers laquelle vous allez effectuer le déploiement Canary :

    • La configuration de la cible est la même que pour n'importe quelle cible.

    • La configuration du pipeline de diffusion, dans la séquence de progression de la cible spécifique, inclut une strophe gatewayServiceMesh pour faire référence à la configuration HTTPRoute de votre API Kubernetes Gateway, ainsi qu'à votre déploiement et à votre service.

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

      Où...

      • ROUTE correspond à votre configuration httpRoute qui définit le comportement de routage souhaité.

      • SERVICE correspond à votre configuration de service, requise par Cloud Deploy pour les déploiements Canary sur des clusters GKE et GKE associés.

      • DEPLOYMENT correspond à votre configuration de déploiement, requise par Cloud Deploy pour les déploiements Canary sur des clusters GKE et GKE associés.

      • WAIT_TIME correspond à la durée pendant laquelle Cloud Deploy doit attendre la fin de la propagation des modifications apportées à la ressource HTTPRoute, afin d' éviter les requêtes abandonnées. Par exemple : routeUpdateWaitTime: 60s.

        Si vous exécutez un déploiement Canary à l'aide de l'API Gateway sans Istio, et que l' API Gateway est connectée à un Google Cloud équilibreur de charge, une petite quantité de trafic peut être perdue lorsque l'instance Canary est réduite. Vous pouvez configurer ce paramètre si vous constatez ce comportement.

      • LABEL est une étiquette de sélecteur de pod. Elle doit correspondre au sélecteur d'étiquettes du service et du déploiement Kubernetes définis dans votre fichier manifeste. Cette opération est facultative. La valeur par défaut est app.

Configurer un déploiement Canary automatisé personnalisé

Un déploiement Canary automatisé personnalisé combine une définition de phase personnalisée (noms, pourcentages, profils, vérification, hooks) avec la gestion automatique du trafic de Cloud Deploy pour les clusters GKE ou GKE associés. Vous définissez les phases, mais Cloud Deploy gère la manipulation des ressources sous-jacentes en fonction des pourcentages et de la runtimeConfig choisie.

Pour configurer cela, incluez une section runtimeConfig avec serviceNetworking et la section customCanaryDeployment (définissant phaseConfigs) dans le bloc strategy.canary. Cloud Deploy utilisera les profils Skaffold spécifiés pour le rendu, mais ajustera automatiquement le trafic en fonction de la runtimeConfig et des pourcentages de phase.

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:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []

Déployer une ressource HTTPRoute sur un autre cluster

Lorsque vous avez configuré un déploiement Canary à l'aide d'un maillage de services de l'API Gateway, vous pouvez spécifier un autre cluster non cible sur lequel déployer la ressource HTTPRoute.

Pour ce faire, utilisez une strophe routeDestinations dans la configuration de votre stratégie Canary pour identifier le ou les clusters de destination de la ressource HTTPRoute, et un paramètre booléen pour propager le service au même cluster non cible. Ensuite, créez une strophe associatedEntities dans la configuration de votre cible pour identifier les clusters.

  1. Configurez associatedEntities sur votre cible.

    Chaque entité est un cluster dans lequel Cloud Deploy déploiera la ressource HTTPRoute et, éventuellement, le service Kubernetes. Dans la définition de votre cible, incluez une strophe associatedEntities :

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

    Où :

    • KEY est un nom arbitraire pour ce groupe d'entités associées. Vous utiliserez ce nom pour faire référence aux entités à partir de routeDestinations dans votre configuration Canary.

    • PATH est le chemin d'accès à la ressource qui identifie le cluster GKE dans lequel votre ressource HTTPRoute (et éventuellement le service) sera déployée.

    • dnsEndpoint indique s'il faut utiliser ou non le point de terminaison DNS du cluster si plusieurs points de terminaison sont configurés. La valeur par défaut est false.

    • internalIp indique s'il faut utiliser ou non l'adresse IP interne (adresse IP privée) du cluster si plusieurs points de terminaison sont configurés. La valeur par défaut est false.

    Vous pouvez inclure n'importe quel nombre de clusters, avec ou sans internalIp.

  2. Configurez routeDestinations dans votre configuration Canary.

    Chaque destination de route fait référence à une strophe associatedEntities et indique s'il faut également déployer le service sur l'autre cluster. Ajoutez les éléments suivants dans la strophe gatewayServiceMesh de votre configuration Canary :

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

    Où :

    • KEY correspond au nom que vous avez configuré dans la cible, dans associatedEntities. Utilisez ce nom pour faire référence aux entités à partir de routeDestinations dans votre configuration Canary.

      Vous pouvez également fournir la valeur @self pour déployer la ressource HTTPRoute sur le cluster cible en plus de la destination associée.

    • propagateService indique si vous souhaitez ou non déployer le service sur le cluster associé, en plus de la ressource HTTPRoute. La valeur par défaut est false.

Exécuter le déploiement Canary sur des clusters GKE ou GKE associés

  1. Enregistrer le pipeline et les cibles : appliquez vos fichiers de configuration de pipeline de diffusion et de cible de clusters GKE ou GKE associés.

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

    Le pipeline de diffusion inclut la configuration Canary automatisée ou personnalisée pour l'environnement d'exécution de votre choix.

  2. Créer une version : démarrez le déploiement en fournissant le nom de l'image.

    
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

    Le pipeline de diffusion identifié par PIPELINE_NAME contient la configuration Canary automatisée ou personnalisée décrite dans ce document.

  3. Avancer le déploiement Canary :

    Gcloud CLI 

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

    Où :

    ROLLOUT_NAME correspond au nom du déploiement actuel que vous faites passer à la phase suivante.

    RELEASE_NAME correspond au nom de la version à laquelle appartient ce déploiement.

    PIPELINE_NAME correspond au nom du pipeline de diffusion que vous utilisez pour gérer le déploiement de cette version.

    REGION correspond au nom de la région dans laquelle la version a été créée, par exemple us-central1. Ce champ est obligatoire.

    Pour en savoir plus sur la commande gcloud deploy rollouts advance, consultez la documentation de référence de Google Cloud SDK.

    Google Cloud Console

    1. Ouvrez la page des pipelines de diffusion.

    2. Cliquez sur votre pipeline dans la liste des pipelines de diffusion.

      La page d'informations du pipeline de diffusion affiche une représentation graphique de la progression de votre pipeline de diffusion.

    3. Dans l'onglet Déploiements, sous Détails du pipeline de diffusion, cliquez sur le nom de votre déploiement.

      La page d'informations du déploiement s'affiche.

      Informations sur le déploiement dans la console Google Cloud

      Notez que dans cet exemple, le déploiement comporte une phase canary-50 et une phase stable. Votre déploiement peut comporter plus de phases ou des phases différentes.

    4. Cliquez sur Avancer le déploiement.

      Le déploiement passe à la phase suivante.

Phases ignorées

Si vous déployez un déploiement Canary et que votre application n'a pas encore été déployée dans cet environnement d'exécution, Cloud Deploy ignore la phase Canary et exécute la phase stable. Consultez la section Ignorer les phases la première fois pour découvrir pourquoi cela se produit.

Étape suivante