KubernetesManifest@0 - Tâche Déployer sur Kubernetes v0

Utilisez une tâche de manifeste Kubernetes dans un pipeline de build ou de mise en production pour créer et déployer des manifestes sur des clusters Kubernetes à l’aide de graphiques Helm.

Syntax

# Deploy to Kubernetes v0
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@0
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #kubernetesServiceConnection: # string. Required when action != bake. Kubernetes service connection. 
    #namespace: # string. Namespace. 
    #strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
    #trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
    #percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
    #baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
    #manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests. 
    #containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers. 
    #imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets. 
    #renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
    #dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file. 
    #helmChart: # string. Required when action = bake && renderType = helm. Helm Chart. 
    #releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name. 
    #overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files. 
    #overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides. 
    #kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path. 
    #resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
    #resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path. 
    #kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind. 
    #name: # string. Required when action = scale || resourceToPatch = name. Name. 
    #replicas: # string. Required when action = scale. Replica count. 
    #mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
    #arguments: # string. Optional. Use when action = delete. Arguments. 
    #patch: # string. Required when action = patch. Patch. 
    #secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
    #secretName: # string. Optional. Use when action = createSecret. Secret name. 
    #secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments. 
    #dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection. 
    #rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.

Entrées

action - Action
string. Valeurs autorisées : bake, createSecret (créer un secret), delete, deploy, patch, promote, , scale, reject. Valeur par défaut : deploy.

Indique l'action à effectuer.

kubernetesServiceConnection - Connexion au service Kubernetes
string. Nécessaire lorsque action != bake.

Spécifie une connexion de service Kubernetes.

namespace - Noms
string.

Spécifie l’espace de noms pour les commandes à l’aide de l’indicateur –namespace . Si l’espace de noms n’est pas fourni, les commandes s’exécutent dans l’espace de noms par défaut.

strategy - Stratégie
string. Optionnel. Utilisez quand action = deploy || action = promote || action = reject. Valeurs autorisées : canary, none. Valeur par défaut : none.

Spécifie la stratégie de déploiement utilisée dans l’action deploy avant une action ou reject une promote action. Actuellement, canary est la seule stratégie de déploiement acceptable.

trafficSplitMethod - Méthode de fractionnement du trafic
string. Optionnel. Utilisez quand strategy = canary. Valeurs autorisées : pod, smi. Valeur par défaut : pod.

Pour la valeur smi, le fractionnement du pourcentage de trafic est effectué au niveau de la demande à l’aide d’un maillage de service. Un maillage de service doit être configuré par un administrateur de cluster. Cette tâche gère l’orchestration des objets TrafficSplit SMI.

Pour la valeur pod, le fractionnement du pourcentage n’est pas possible au niveau de la demande en l’absence d’un maillage de service. Au lieu de cela, l’entrée de pourcentage est utilisée pour calculer les réplicas pour la ligne de base et canary. Le calcul est un pourcentage de réplicas spécifiés dans les manifestes d’entrée pour la variante stable.

percentage - Pourcentage
string. Nécessaire lorsque strategy = Canary && action = deploy. Valeur par défaut : 0.

Pourcentage utilisé pour calculer le nombre de réplicas de type baseline-variant et canary-variant des charges de travail contenues dans les fichiers manifeste.

Pour l’entrée de pourcentage spécifiée, calculez :

(pourcentage × nombre de réplicas) / 100

Si le résultat n’est pas un entier, le plancher mathématique du résultat est utilisé lors de la création de variantes de base et de validité.

Par exemple, supposons que le déploiement hello-world se trouve dans le fichier manifeste d’entrée et que les lignes suivantes se trouvent dans l’entrée de tâche :

replicas: 4
strategy: canary
percentage: 25

Dans ce cas, les déploiements et hello-world-canary sont créés hello-world-baseline avec un réplica chacun. La variante de base est créée avec la même image et la même balise que la version stable, qui est la variante à quatre réplica avant le déploiement. La variante canary est créée avec l’image et la balise correspondant aux modifications nouvellement déployées.

baselineAndCanaryReplicas - Réplicas de base et de validité
string. Nécessaire lorsque strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valeur par défaut : 1.

Lorsque vous définissez trafficSplitMethodsmisur , le pourcentage de fractionnement du trafic est contrôlé dans le plan de maillage de service. Vous pouvez contrôler le nombre réel de réplicas pour les variantes canary et de base de référence indépendamment du fractionnement du trafic.

Par exemple, supposons que le manifeste de déploiement d’entrée spécifie 30 réplicas pour la variante stable. Supposons également que vous spécifiez l’entrée suivante pour la tâche :

strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1

Dans ce cas, la variante stable reçoit 80 % du trafic, tandis que les variantes de base et de validité reçoivent chacune la moitié des 20 % spécifiés. Les variantes de base et de validité ne reçoivent pas trois réplicas chacune. Ils reçoivent à la place le nombre spécifié de réplicas, ce qui signifie qu’ils reçoivent chacun un réplica.

manifests - Se manifeste
string. Nécessaire lorsque action = deploy || action = promote || action = reject.

Spécifie le chemin des fichiers manifeste à utiliser pour le déploiement. Chaque ligne représente un chemin d’accès unique. Un modèle de correspondance de fichier est une valeur acceptable pour chaque ligne.

containers - Conteneurs
string. Optionnel. Utilisez quand action = deploy || action = promote || action = bake.

Spécifie l’URL de ressource complète de l’image à utiliser pour les substitutions sur les fichiers manifeste. L’URL contosodemo.azurecr.io/helloworld:test est un exemple.

imagePullSecrets - ImagePullSecrets
string. Optionnel. Utilisez quand action = deploy || action = promote.

Spécifie une entrée multiligne où chaque ligne contient le nom d’un secret de Registre Docker qui a déjà été configuré au sein du cluster. Chaque nom de secret est ajouté sous imagePullSecrets pour les charges de travail qui se trouvent dans les fichiers manifeste d’entrée.

renderType - Moteur de rendu
string. Optionnel. Utilisez quand action = bake. Valeurs autorisées : helm, kompose, kustomize. Valeur par défaut : helm.

Spécifie le type de rendu utilisé pour produire les fichiers manifestes.

dockerComposeFile - Chemin d’accès au fichier docker compose
string. Nécessaire lorsque action = bake && renderType = kompose.

Spécifie un chemin d’accès au fichier docker-compose.

helmChart - Graphique Helm
string. Nécessaire lorsque action = bake && renderType = helm.

Spécifie le chemin d’accès du graphique Helm à baker.

releaseName - Nom de la version Helm
string. Optionnel. Utilisez quand action = bake && renderType = helm.

Spécifie le nom de la version Helm à utiliser.

overrideFiles - Remplacer les fichiers
string. Optionnel. Utilisez quand action = bake && renderType = helm.

Spécifie une entrée multiligne qui accepte le chemin d’accès aux fichiers de remplacement. Les fichiers sont utilisés lorsque les fichiers manifeste des graphiques Helm sont cuits.

overrides - Substitue
string. Optionnel. Utilisez quand action = bake && renderType = helm.

Spécifie les valeurs de remplacement à définir.

kustomizationPath - Chemin d’accès à la kustomisation
string. Optionnel. Utilisez quand action = bake && renderType = kustomize.

Spécifie l’argument qui doit être le chemin d’accès au répertoire contenant le fichier ou une URL de dépôt git avec un suffixe de chemin d’accès spécifiant same par rapport à la racine du dépôt.

resourceToPatch - Ressource à corriger
string. Nécessaire lorsque action = patch. Valeurs autorisées : file, name. Valeur par défaut : file.

Indique l’une des méthodes correctives suivantes :

• Un fichier manifeste identifie les objets à corriger.
• Un objet individuel est identifié par son genre et son nom en tant que cible de correctif.

Les valeurs acceptables sont fichier et nom.

resourceFileToPatch - Chemin d’accès au fichier
string. Nécessaire lorsque action = patch && resourceToPatch = file.

Spécifie le chemin d’accès au fichier utilisé pour un correctif.

kind - Genre
string. Nécessaire lorsque action = scale || resourceToPatch = name. Valeurs autorisées : deployment, replicaset, statefulset.

Spécifie le type d’objet K8s, par deploymentexemple , replicaSet et bien plus encore.

name - Nom
string. Nécessaire lorsque action = scale || resourceToPatch = name.

Spécifie le nom de l’objet K8s.

replicas - Nombre de réplicas
string. Nécessaire lorsque action = scale.

Spécifie le nombre de réplicas à mettre à l’échelle.

mergeStrategy - Stratégie de fusion
string. Nécessaire lorsque action = patch. Valeurs autorisées : json, merge, strategic. Valeur par défaut : strategic.

Spécifie le type de correctif fourni.

arguments - Arguments
string. Optionnel. Utilisez quand action = delete.

Spécifie les arguments de la kubectl delete commande. Voici un exemple : arguments: deployment hello-world foo-bar

patch - Patch
string. Nécessaire lorsque action = patch.

Spécifie le contenu du correctif.

secretType - Type de secret
string. Nécessaire lorsque action = createSecret. Valeurs autorisées : dockerRegistry, generic. Valeur par défaut : dockerRegistry.

Crée ou met à jour un générique ou docker imagepullsecret. Spécifiez dockerRegistry pour créer ou mettre à jour le imagepullsecret du registre sélectionné. Un imagePullSecret est un moyen de passer un secret qui contient un mot de passe de registre de conteneurs à Kubelet, afin qu’il puisse extraire une image privée au nom de votre pod.

secretName - Nom du secret
string. Optionnel. Utilisez quand action = createSecret.

Spécifie le nom du secret. Vous pouvez utiliser ce nom secret dans le fichier de configuration Kubernetes YAML.

secretArguments - Arguments
string. Optionnel. Utilisez quand action = createSecret && secretType = generic.

Spécifie les clés et les valeurs littérales à insérer dans le secret. Par exemple, --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Connexion au service du Registre Docker
string. Optionnel. Utilisez quand action = createSecret && secretType = dockerRegistry.

Spécifie les informations d’identification de la connexion de service spécifiée qui sont utilisées pour créer un secret de Registre Docker au sein du cluster. Les fichiers manifeste sous le imagePullSecrets champ peuvent ensuite faire référence au nom de ce secret.

rolloutStatusTimeout - Délai d’attente pour les status de déploiement
string. Optionnel. Utilisez quand action = deploy || action = patch || action = scale || action = promote. Valeur par défaut : 0.

Spécifie la durée d’attente (en secondes) avant de se terminer watch on rollout status.

Options de contrôle des tâches

Toutes les tâches ont des options de contrôle en plus de leurs entrées de tâche. Pour plus d’informations, consultez Options de contrôle et propriétés de tâche courantes.

Variables de sortie

Cette tâche définit les variables de sortie suivantes, que vous pouvez utiliser dans les étapes, les travaux et les étapes en aval.

manifestsBundle
Spécifie l’emplacement des bundles de manifeste créés par l’action bake.

Remarques

Notes

Il existe une version plus récente de cette tâche disponible qui offre une prise en charge supplémentaire pour le ciblage d’un cluster Kubernetes de différentes façons, à l’aide de la connectionType propriété . Pour plus d’informations, consultez KubernetesManifest@1 et KubernetesManifest@1 remarques sur la connexion au service

Utilisez une tâche de manifeste Kubernetes dans un pipeline de build ou de mise en production pour créer et déployer des manifestes sur des clusters Kubernetes.

Cette tâche prend en charge les éléments suivants :

• Substitution d’artefact : l’action de déploiement prend en entrée une liste d’images conteneur que vous pouvez spécifier avec leurs balises et leurs synthèses. La même entrée est remplacée dans les fichiers manifestes non créés avant l’application au cluster. Cette substitution garantit que les nœuds de cluster extrayent la version appropriée de l’image.

• Stabilité du manifeste : la status de déploiement des objets Kubernetes déployés est vérifiée. Les vérifications de stabilité sont incorporées pour déterminer si la tâche status est une réussite ou un échec.

• Annotations de traçabilité : les annotations sont ajoutées aux objets Kubernetes déployés pour superposer les informations de traçabilité. Les annotations suivantes sont prises en charge :

  • azure-pipelines/org
  • azure-pipelines/project
  • azure-pipelines/pipeline
  • azure-pipelines/pipelineId
  • azure-pipelines/exécution
  • azure-pipelines/executionuri
  • azure-pipelines/jobName

• Gestion des secrets : l’action createSecret permet de créer des secrets de registre Docker à l’aide de connexions au service de registre Docker. Il permet également de créer des secrets génériques à l’aide de variables de texte brut ou de variables secrètes. Avant le déploiement sur le cluster, vous pouvez utiliser l’entrée secrets avec l’action deploy pour augmenter les fichiers manifestes d’entrée avec la valeur appropriée imagePullSecrets .

• Créer un manifeste : l’action bake de la tâche permet de créer des modèles dans des fichiers manifeste Kubernetes. L’action utilise des outils tels que Helm, Compose et Kustomize. Avec la baking, ces fichiers manifeste Kubernetes sont utilisables pour les déploiements sur le cluster.

• Stratégie de déploiement : le choix de la canary stratégie avec l’action deploy entraîne la création de noms de charge de travail avec -baseline suffixe et -canary. La tâche prend en charge deux méthodes de fractionnement du trafic :

  • Interface de maillage de service : l’abstraction SMI (Service Mesh Interface ) permet la configuration avec des fournisseurs de maillage de services comme Linkerd et Istio. La tâche de manifeste Kubernetes mappe les objets SMI TrafficSplit aux services stables, de référence et de validité pendant le cycle de vie de la stratégie de déploiement.

    Les déploiements Canary basés sur un maillage de service et qui utilisent cette tâche sont plus précis. Cette précision est due à la façon dont les fournisseurs de maillage de services activent le fractionnement granulaire du trafic basé sur le pourcentage. Le maillage de services utilise le registre de services et les conteneurs side-car qui sont injectés dans des pods. Cette injection se produit en même temps que les conteneurs d’application pour obtenir le fractionnement granulaire du trafic.

  • Kubernetes sans maillage de service : en l’absence d’un maillage de service, vous risquez de ne pas obtenir le pourcentage exact de fractionnement souhaité au niveau de la demande. Toutefois, vous pouvez effectuer des déploiements de validité en utilisant des variantes de base et de validité en regard de la variante stable.

    Le service envoie des requêtes aux pods des trois variantes de charge de travail, car les contraintes d’étiquette de sélecteur sont satisfaites. Le manifeste Kubernetes respecte ces demandes lors de la création de variantes de base et de validité. Ce comportement de routage obtient l’effet prévu du routage uniquement d’une partie du nombre total de requêtes vers le canary.

  Comparez les charges de travail de base et de validité à l’aide d’une tâche d’intervention manuelle dans les pipelines de mise en production ou d’une tâche De retard dans les pipelines YAML. Effectuez la comparaison avant d’utiliser l’action de promotion ou de rejet de la tâche.

Déployer l’action

Le code YAML suivant est un exemple de déploiement sur un espace de noms Kubernetes à l’aide de fichiers manifeste :

steps:
- task: KubernetesManifest@0
  displayName: Deploy
  inputs:
    kubernetesServiceConnection: someK8sSC1
    namespace: default
    manifests: |
      manifests/deployment.yml
      manifests/service.yml
    containers: |
      foo/demo:$(tagVariable1)
      bar/demo:$(tagVariable2)
    imagePullSecrets: |
      some-secret
      some-other-secret

Dans l’exemple ci-dessus, la tâche tente de trouver des correspondances pour les images foo/demo et bar/demo dans les champs d’image des fichiers manifestes. Pour chaque correspondance trouvée, la valeur de ou tagVariable2 est ajoutée en tant que balise au nom de tagVariable1 l’image. Vous pouvez également spécifier des synthèses dans l’entrée de conteneurs pour la substitution d’artefact.

Notes

Bien que vous puissiez créer deploydes actions , promoteet reject avec une entrée YAML liée à la stratégie de déploiement, la prise en charge d’une tâche d’intervention manuelle n’est actuellement pas disponible pour les pipelines de build.

Pour les pipelines de mise en production, nous vous conseillons d’utiliser des actions et des entrées liées à la stratégie de déploiement dans la séquence suivante :

1. Action de déploiement spécifiée avec strategy: canary et percentage: $(someValue).
2. Tâche d’intervention manuelle permettant de suspendre le pipeline et de comparer la variante de base avec la variante canary.
3. Action de promotion qui s’exécute si une tâche d’intervention manuelle est reprise et action de rejet qui s’exécute si une tâche d’intervention manuelle est rejetée.

Créer une action de secret

Le code YAML suivant montre un exemple de création de secrets de Registre Docker à l’aide d’une connexion au service Docker Registry :

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: dockerRegistry
    secretName: foobar
    dockerRegistryEndpoint: demoACR
    kubernetesServiceConnection: someK8sSC
    namespace: default

Ce code YAML montre un exemple de création de secrets génériques :

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: generic
    secretName: some-secret
    secretArguments: --from-literal=key1=value1
    kubernetesServiceConnection: someK8sSC
    namespace: default

Action de cuisson

Le code YAML suivant est un exemple de baking de fichiers manifeste à partir de graphiques Helm. Notez l’utilisation d’une entrée de nom dans la première tâche. Ce nom est ensuite référencé à partir de l’étape de déploiement pour spécifier le chemin d’accès aux manifestes qui ont été produits par l’étape bake.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: someK8sSC
    namespace: default
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Notes

Pour utiliser Helm directement pour gérer les mises en production et les restaurations, consultez la tâche Empaqueter et déployer des graphiques Helm.

Exemple Kustomize

Le code YAML suivant est un exemple de fichiers manifeste de baking générés avec Kustomize qui contiennent un kustomization.yaml fichier.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from kustomization path
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Exemple Kompose

Le code YAML suivant est un exemple de baking de fichiers manifeste générés avec Kompose, un outil de conversion pour Docker Compose.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Docker Compose
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Action de mise à l’échelle

Le code YAML suivant montre un exemple de mise à l’échelle d’objets :

steps:
- task: KubernetesManifest@0
  displayName: Scale
  inputs: 
    action: scale
    kind: deployment
    name: bootcamp-demo
    replicas: 5
    kubernetesServiceConnection: someK8sSC
    namespace: default

Action de correctif

Le code YAML suivant montre un exemple de mise à jour corrective d’objet :

steps:
- task: KubernetesManifest@0
  displayName: Patch
  inputs: 
    action: patch
    kind: pod
    name: demo-5fbc4d6cd9-pgxn4
    mergeStrategy: strategic
    patch: '{"spec":{"containers":[{"name":"demo","image":"foobar/demo:2239"}]}}'
    kubernetesServiceConnection: someK8sSC
    namespace: default

Supprimer l'action

Ce code YAML montre un exemple de suppression d’objet :

steps:
- task: KubernetesManifest@0
  displayName: Delete
  inputs:
    action: delete
    arguments: deployment expressapp
    kubernetesServiceConnection: someK8sSC
    namespace: default

Dépannage

Mon cluster Kubernetes se trouve derrière un pare-feu et j’utilise des agents hébergés. Comment puis-je effectuer un déploiement sur ce cluster ?

Vous pouvez accorder l’accès à travers votre pare-feu aux agents hébergés en autorisant leurs adresses IP. Pour plus d’informations, consultez Plages d’adresses IP d’agent.

Comment fonctionnent les requêtes d’itinéraires de service stables et variants avec des déploiements de contrôles de validité ?

La relation de sélecteur d’étiquette entre les pods et les services dans Kubernetes permet de configurer des déploiements afin qu’un seul service route les requêtes vers les variants stable et de contrôles de validité. La tâche de manifeste Kubernetes l’utilise pour les déploiements de contrôles de validité.

Si la tâche inclut les entrées de action: deploy et strategy: canary, pour chaque charge de travail (Deployment, ReplicaSet, Pod, ...) définie dans les fichiers manifeste d’entrée, un et -canary une -baseline variante du déploiement sont créés. Dans cet exemple, il existe un déploiement sampleapp dans le fichier manifeste d’entrée et qu’une fois l’exécution 22 du pipeline terminée, la variante stable de ce déploiement nommée sampleapp est déployée dans le cluster. Dans l’exécution suivante (dans ce cas, exécutez le numéro 23), la tâche de manifeste Kubernetes avec action: deploy et strategy: canary entraînerait la création de déploiements sampleapp-baseline et sampleapp-canary dont le nombre de réplicas est déterminé par le produit de l’entrée de percentage tâche avec la valeur du nombre souhaité de réplicas pour la dernière variante stable de en fonction des sampleapp fichiers manifeste d’entrée.

Si l’on exclut le nombre de réplicas, la version de base a la même configuration que la variante stable, tandis que la version canary a les nouvelles modifications introduites par l’exécution actuelle (dans ce cas, le numéro d’exécution 23). Si une intervention manuelle est configurée dans le pipeline après l’étape mentionnée ci-dessus, cela permet de suspendre le pipeline afin que l’administrateur de pipeline puisse évaluer les métriques clés pour les versions de base de référence et de canari et prendre la décision de déterminer si les modifications de validité sont sécurisées et suffisamment bonnes pour un déploiement complet.

Lesaction: promote entrées et strategy: canary ou action: reject et strategy: canary des tâches du manifeste Kubernetes peuvent être utilisées pour promouvoir ou rejeter les modifications de validité respectivement. Notez que dans les deux cas, à la fin de cette étape, seule la variante stable des charges de travail déclarées dans les fichiers manifeste d’entrée reste déployée dans le cluster, tandis que la base de référence éphémère et les versions canary sont nettoyées.

Configuration requise

Condition requise	Description
Types de pipelines	YAML, build classique, version classique
S’exécute sur	Agent, DeploymentGroup
Demandes	Aucune
Capabilities	Cette tâche ne répond à aucune demande pour les tâches suivantes dans le travail.
Restrictions de commande	Quelconque
Variables paramétrables	Quelconque
Version de l’agent	Toutes les versions d’agent prises en charge.
Catégorie de la tâche	Déployer