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

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

Cette version de la tâche est déconseillée ; utilisez KubernetesManifest@1 pour tirer parti des dernières fonctionnalités telles que fédération des identités de charge de travail.

Syntaxe

# 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.

Spécifie l’action à effectuer.

kubernetesServiceConnection - de connexion de service Kubernetes
string. Obligatoire lorsque action != bake.

Spécifie une connexion de service Kubernetes .

namespace - espace de noms
string.

Spécifie l’espace de noms des 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 de deploy avant une action de promote ou reject 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 trafic en pourcentage est effectué au niveau de la requête à 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 SMI TrafficSplit.

Pour la valeur pod, le fractionnement de pourcentage n’est pas possible au niveau de la requête 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 le canari. Le calcul est un pourcentage de réplicas spécifiés dans les manifestes d’entrée pour la variante stable.

percentage - pourcentage
string. Obligatoire lorsque strategy = Canary && action = deploy. Valeur par défaut : 0.

Pourcentage utilisé pour calculer le nombre de réplicas variant de référence et canary-variant des charges de travail contenues dans les fichiers manifestes.

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 référence et de canari.

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 hello-world-baseline et hello-world-canary sont créés avec un réplica chacun. La variante de référence est créée avec la même image et la même balise que la version stable, qui est la variante de quatre réplicas 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 référence et de canari
string. Obligatoire lorsque strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valeur par défaut : 1.

Lorsque vous définissez trafficSplitMethod sur smi, le fractionnement du trafic en pourcentage est contrôlé dans le plan de maillage de service. Vous pouvez contrôler le nombre réel de réplicas pour les variantes de référence et de canary 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 ligne de base et de canari reçoivent chacune la moitié des 20%spécifiés. Les variantes de référence et de canari ne reçoivent pas chacun trois réplicas. Ils reçoivent plutôt le nombre spécifié de réplicas, ce qui signifie qu’ils reçoivent chacun un réplica.

manifestes manifests -
string. Obligatoire lorsque action = deploy || action = promote || action = reject.

Spécifie le chemin d’accès aux fichiers manifestes à 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 manifestes. 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é dans le 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 - du 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. Obligatoire lorsque action = bake && renderType = kompose.

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

helmChart - graphique Helm
string. Obligatoire lorsque action = bake && renderType = helm.

Spécifie le chemin du graphique Helm à cuire.

releaseName - nom de publication Helm
string. Optionnel. Utilisez quand action = bake && renderType = helm.

Spécifie le nom de publication 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 manifestes des graphiques Helm sont cuits.

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

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

kustomizationPath - chemin d’accès Kustomization
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 référentiel.

ressource resourceToPatch - pour corriger les
string. Obligatoire 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 type et par nom comme cible de correctif.

Les valeurs acceptables sont fichier et nom.

resourceFileToPatch - chemin d’accès au fichier
string. Obligatoire lorsque action = patch && resourceToPatch = file.

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

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

Spécifie le type d’objet K8s, tel que deployment, replicaSet et bien plus encore.

name - Nom
string. Obligatoire lorsque action = scale || resourceToPatch = name.

Spécifie le nom de l’objet K8s.

replicas - nombre de réplicas
string. Obligatoire lorsque action = scale.

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

mergeStrategy - stratégie de fusion
string. Obligatoire 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 commande kubectl delete. Voici un exemple : arguments: deployment hello-world foo-bar

patch - patch
string. Obligatoire lorsque action = patch.

Spécifie le contenu du correctif.

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

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

nom de secret secretName -
string. Optionnel. Utilisez quand action = createSecret.

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

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 de 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 manifestes sous le champ imagePullSecrets peuvent ensuite faire référence au nom de ce secret.

rolloutStatusTimeout - délai d’attente pour l’état 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 terminer watch on rollout'état.

Options de contrôle de la tâche

Toutes les tâches ont des options de contrôle en plus de leurs entrées de tâches. 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 en aval, les travaux et les étapes.

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

Remarques

Remarque

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

Utilisez une tâche de manifeste Kubernetes dans un pipeline de build ou de mise en production pour baker 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 comme entrée une liste d’images conteneur que vous pouvez spécifier avec leurs balises et synthèses. La même entrée est remplacée dans les fichiers manifestes nontemplatés avant l’application au cluster. Cette substitution garantit que les nœuds de cluster extrayent la version droite de l’image.

• stabilité du manifeste: l’état de déploiement des objets Kubernetes déployés est vérifié. Les vérifications de stabilité sont incorporées pour déterminer si l’état de la tâche est un succès 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/projet
  • 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 de 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 ainsi que l’action de deploy pour augmenter les fichiers manifestes d’entrée avec la valeur imagePullSecrets appropriée.

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

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

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

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

  • Kubernetes sans maillage de service: en l’absence de maillage de service, vous n’obtenez peut-être pas le pourcentage exact de fractionnement souhaité au niveau de la requête. Toutefois, vous pouvez effectuer des déploiements canary à l’aide de variantes de ligne de base et de canari 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 remplies. Le manifeste Kubernetes respecte ces demandes lors de la création de variantes de référence et de canari. Ce comportement de routage permet d’obtenir l’effet prévu du routage uniquement d’une partie des requêtes totales vers le canari.

  Comparez les charges de travail de référence et de canari à l’aide d’une tâche d’intervention manuelle dans les pipelines de mise en production ou d’une tâche retarder dans les pipelines YAML. Effectuez la comparaison avant d’utiliser l’action de promotion ou de rejet de la tâche.

Déployer une action

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

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 tagVariable1 ou de tagVariable2 est ajoutée en tant que balise au nom de l’image. Vous pouvez également spécifier des synthèses dans l’entrée des conteneurs pour la substitution d’artefact.

Remarque

Bien que vous puissiez créer deploy, promoteet reject actions 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 afin que vous puissiez suspendre le pipeline et comparer la variante de référence à la variante canary.
3. Action de promotion qui s’exécute si une tâche d’intervention manuelle est reprise et une action de rejet qui s’exécute si une tâche d’intervention manuelle est rejetée.

Créer une action secrète

Le code YAML suivant montre un exemple de création de secrets de Registre Docker à l’aide de connexion de 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 bake

Le code YAML suivant est un exemple de baking manifest files from Helm charts. Notez l’utilisation d’une entrée de nom dans la première tâche. Ce nom est ultérieurement référencé à partir de l’étape de déploiement pour spécifier le chemin d’accès aux manifestes générés 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

Remarque

Pour utiliser Helm directement pour gérer les versions et les restaurations, consultez la tâche Package 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 fichier kustomization.yaml.

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 manifest files generated with 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 d’objets de mise à l’échelle :

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

Action Supprimer

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

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

Résolution des problèmes

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

Vous pouvez accorder l’accès aux agents hébergés via votre pare-feu en autorisant les adresses IP des agents hébergés. 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 utilise ceci pour les déploiements canary.

Si la tâche inclut les entrées de action: deploy et de strategy: canary, pour chaque charge de travail (Déploiement, ReplicaSet, Pod, ...) définie dans les fichiers manifeste d’entrée, une -baseline et -canary variante du déploiement sont créées. Dans cet exemple, il existe une sampleapp de déploiement dans le fichier manifeste d’entrée et qu’après l’exécution du numéro 22 du pipeline, la variante stable de ce déploiement nommé sampleapp est déployée dans le cluster. Dans l’exécution suivante (dans ce cas, le numéro d’exécution 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 d’une entrée de tâche percentage avec la valeur du nombre souhaité de réplicas pour la variante stable finale de sampleapp en fonction des fichiers manifestes d’entrée.

À l’exclusion du 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, elle permet de suspendre le pipeline afin que l’administrateur du pipeline puisse évaluer les métriques clés des versions de référence et de canary et prendre la décision de déterminer si les modifications canary sont sécurisées et suffisantes pour un déploiement complet.

Les entréesaction: promote et strategy: canary ou action: reject et strategy: canary des tâches de manifeste Kubernetes peuvent être utilisées pour promouvoir ou rejeter les modifications canary 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 les versions éphémères et canary sont nettoyées.

Spécifications

Besoin	Descriptif
Types de pipelines	YAML, Build Classique, Version Classique
Exécutions sur	Agent, DeploymentGroup
demandes	Aucun
fonctionnalités de	Cette tâche ne répond à aucune demande de tâches ultérieures dans le travail.
restrictions de commande	N'importe quel
variables settables	N'importe quel
Version de l’agent	Toutes les versions de l’agent prises en charge.
Catégorie de tâche	Déployer