Cette page a été traduite par l'API Cloud Translation.

Déploiements Canary sur GKE et GKE Enterprise à 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 GKE ou GKE Enterprise à l'aide de Cloud Deploy avec le maillage de services de l'API Kubernetes Gateway.

Un déploiement Canary est un déploiement progressif d'une nouvelle version de votre application. Vous augmentez progressivement le pourcentage de trafic envoyé vers 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 GKE et GKE Enterprise avec l'API Gateway

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.
Cloud Deploy crée un déploiement portant le nom de votre déploiement d'origine plus -canary, ainsi qu'un service portant le nom du service d'origine plus -canary.

Les secrets, les ConfigMaps et les autoscalers horizontaux de pods sont également copiés et renommés avec -canary.
Pour chaque phase canary, Cloud Deploy modifie l'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'un délai peut s'écouler avant que les modifications apportées aux ressources HTTPRoute ne soient propagées, vous pouvez inclure la propriété routeUpdateWaitTime dans votre configuration. Le système attendra alors un certain temps avant que cette propagation ne soit effectuée.
Au cours de 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 HTTPRoute est désormais 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 GKE et GKE Enterprise en une 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

Pour en savoir plus sur les rôles disponibles qui incluent ces autorisations, consultez Rôles et autorisations IAM.

Préparer votre `skaffold.yaml`

Votre fichier skaffold.yaml définit la façon dont vos fichiers manifestes Kubernetes sont affichés et déployés. Pour un déploiement canary sur GKE/GKE Enterprise, assurez-vous qu'il pointe correctement vers vos fichiers manifestes et définit les artefacts de compilation nécessaires. Aucune configuration spéciale spécifique aux versions Canary n'est requise dans skaffold.yaml au-delà de ce qui est nécessaire pour un déploiement standard. Vous pouvez utiliser des profils Skaffold pour gérer différentes variantes de fichier manifeste 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. Le Service doit définir un selector qui correspond aux libellés des pods gérés par le Deployment. Le libellé par défaut recherché par Cloud Deploy est app, mais il peut être configuré dans le pipeline.

En plus de Deployment et Service, vos fichiers manifestes doivent inclure une ressource HTTPRoute configurée pour la répartition du trafic, faisant référence à 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 un fractionnement précis du trafic basé sur des pourcentages, géré par le maillage/la passerelle et orchestré par Cloud Deploy.

Configurez les ressources de l'API Gateway : assurez-vous que votre passerelle et votre maillage de services sous-jacent (par exemple, Istio) ou le contrôleur de passerelle sont correctement configurés dans vos clusters.
- Utiliser Istio
- Contrôleur GKE Gateway
Dans votre fichier manifeste Kubernetes fourni à Cloud Deploy lorsque vous avez créé la version, incluez les éléments suivants :
- Un HTTPRoute qui fait référence à votre ressource Gateway
- Déploiement
- Un service
Configurez votre pipeline de livraison et la cible sur laquelle vous allez effectuer le déploiement Canary :
- La configuration de la cible est identique à celle de n'importe quelle autre cible.
- Dans la séquence de progression pour la cible spécifique, la configuration du pipeline de déploiement inclut une strophe gatewayServiceMesh pour référencer votre configuration HTTPRoute de l'API Kubernetes Gateway, ainsi que 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 est votre configuration httpRoute qui définit le comportement de routage souhaité.
  - SERVICE correspond à la configuration de votre service, dont Cloud Deploy a besoin pour les déploiements Canary sur GKE et GKE Enterprise.
  - DEPLOYMENT correspond à la configuration de votre déploiement, dont Cloud Deploy a besoin pour les déploiements Canary sur GKE et GKE Enterprise.
  - WAIT_TIME correspond à la durée pendant laquelle Cloud Deploy attend 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 une version Canary à l'aide de l'API Gateway sans Istio, et que l'API Gateway est connectée à un équilibreur de charge Google Cloud , 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 un libellé de sélecteur de pod. Il 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 une analyse Canary automatisée personnalisée

Cela combine la définition de phase personnalisée (noms, pourcentages, profils, validation, hooks) avec la gestion automatique du trafic de Cloud Deploy pour GKE ou GKE Enterprise. Vous définissez les phases, mais Cloud Deploy gère la manipulation des ressources sous-jacentes en fonction des pourcentages et du runtimeConfig choisi.

Pour configurer cela, incluez à la fois 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 des pourcentages de runtimeConfig et 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: 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

Déployer une ressource HTTPRoute dans un autre cluster

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

Pour ce faire, vous utilisez une strophe routeDestinations dans la configuration de votre stratégie canary afin d'identifier le ou les clusters de destination pour l'HTTPRoute, ainsi qu'un paramètre booléen permettant de propager le service au même cluster non cible. Vous créez une strophe associatedEntities dans votre configuration cible pour identifier les clusters.

Configurez associatedEntities sur votre cible.

Chaque entité est un cluster dans lequel Cloud Deploy déploiera l'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 de routeDestinations dans votre configuration canary.
- PATH correspond au chemin d'accès à la ressource qui identifie le cluster GKE dans lequel votre HTTPRoute (et éventuellement le service) sera déployé.
- dnsEndpoint indique s'il faut utiliser 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 autant de clusters que vous le souhaitez, avec ou sans internalIp.
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 le stanza 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 du routeDestinations dans votre configuration canary.
  
  Vous pouvez également fournir la valeur @self pour déployer l'HTTPRoute sur le cluster cible en plus de la destination associée.
- propagateService indique si vous souhaitez déployer le service sur le cluster associé, en plus de la route HTTPRoute. La valeur par défaut est false.

Exécuter le canary GKE ou GKE Enterprise

Enregistrez le pipeline et les cibles : appliquez vos fichiers de configuration de pipeline de diffusion et de cible GKE ou GKE Enterprise.
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=gke-targets.yaml --region=REGION
```
Le pipeline de déploiement inclut la configuration Canary automatisée ou personnalisée pour l'environnement d'exécution de votre choix.

Créez une version : lancez 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 livraison identifié par PIPELINE_NAME contient la configuration Canary automatisée ou personnalisée décrite dans ce document.

Faites avancer la phase Canary :
CLI gcloud
```
gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION
```
Où :

ROLLOUT_NAME est le nom du déploiement en cours que vous faites passer à la phase suivante.

RELEASE_NAME est le nom de la version à laquelle appartient ce déploiement.

PIPELINE_NAME est le nom du pipeline de livraison que vous utilisez pour gérer le déploiement de cette version.

REGION est le 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.
Console Google Cloud
1. Ouvrez la page des pipelines de diffusion.
2. Cliquez sur votre pipeline dans la liste des pipelines de diffusion.
  
  La page "Détails 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 de détails du déploiement s'affiche.
  
  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 canary et que votre application n'a pas encore été déployée sur ce runtime, Cloud Deploy ignore la phase canary et exécute la phase stable. Consultez Ignorer des phases la première fois pour en savoir plus.

Étapes suivantes

Essayez le guide de démarrage rapide du déploiement Canary.
Découvrez comment gérer le cycle de vie des déploiements de votre canary.
En savoir plus sur le déploiement en parallèle
En savoir plus sur les stratégies de déploiement Cloud Deploy