Partager via

KubernetesManifest@1 - Tâche Déployer sur Kubernetes v1

  • Article

Utilisez les fichiers manifeste Kubernetes pour déployer sur des clusters ou même bakez les fichiers manifeste à utiliser pour les déploiements à l’aide de graphiques Helm.

Syntax

# Deploy to Kubernetes v1
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@1
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #connectionType: 'kubernetesServiceConnection' # 'azureResourceManager' | 'kubernetesServiceConnection'. Required when action != bake. Service connection type. Default: kubernetesServiceConnection.
    #kubernetesServiceConnection: # string. Alias: kubernetesServiceEndpoint. Required when action != bake && connectionType = kubernetesServiceConnection. Kubernetes service connection. 
    #azureSubscriptionConnection: # string. Alias: azureSubscriptionEndpoint. Required when action != bake && connectionType = azureResourceManager. Azure subscription. 
    #azureResourceGroup: # string. Required when action != bake && connectionType = azureResourceManager. Resource group. 
    #kubernetesCluster: # string. Required when action != bake && connectionType = azureResourceManager. Kubernetes cluster. 
    #useClusterAdmin: false # boolean. Optional. Use when connectionType = azureResourceManager. Use cluster admin credentials. Default: false.
    #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.


connectionType - Type de connexion de service
string. Nécessaire lorsque action != bake. Valeurs autorisées : azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (Connexion Kubernetes Service). Valeur par défaut : kubernetesServiceConnection.

Sélectionnez un type de connexion de service Kubernetes.

  • kubernetesServiceConnection(Connexion Kubernetes Service) : vous permet de fournir un fichier KubeConfig, de spécifier un compte de service ou d’importer un instance AKS avec l’option Abonnement Azure. L’importation d’un instance AKS avec l’option Abonnement Azure nécessite un accès au cluster Kubernetes au moment de la configuration de la connexion de service.
  • azureResourceManager(Azure Resource Manager) : vous permet de sélectionner un instance AKS. N’accède pas au cluster Kubernetes au moment de la configuration de la connexion de service.

Pour plus d’informations, consultez Remarques.


kubernetesServiceConnection - Connexion au service Kubernetes
Alias d’entrée : kubernetesServiceEndpoint. string. Nécessaire lorsque action != bake && connectionType = kubernetesServiceConnection.

Spécifie une connexion de service Kubernetes.


azureSubscriptionConnection - Abonnement Azure
Alias d’entrée : azureSubscriptionEndpoint. string. Nécessaire lorsque action != bake && connectionType = azureResourceManager.

Sélectionnez l’abonnement Azure Resource Manager qui contient Azure Container Registry. Remarque : Pour configurer une nouvelle connexion de service, sélectionnez l’abonnement Azure dans la liste, puis cliquez sur « Autoriser ». Si votre abonnement n’est pas répertorié, ou si vous souhaitez utiliser un principal de service existant, vous pouvez configurer une connexion de service Azure à l’aide du bouton « Ajouter » ou « Gérer ».


azureResourceGroup - Groupe de ressources
string. Nécessaire lorsque action != bake && connectionType = azureResourceManager.

Sélectionnez un groupe de ressources Azure.


kubernetesCluster - Cluster Kubernetes
string. Nécessaire lorsque action != bake && connectionType = azureResourceManager.

Sélectionnez un cluster managé Azure.


useClusterAdmin - Utiliser les informations d’identification de l’administrateur de cluster
boolean. facultatif. Utilisez quand connectionType = azureResourceManager. Valeur par défaut : false.

Utilisez les informations d’identification de l’administrateur de cluster au lieu des informations d’identification utilisateur du cluster par défaut.


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. facultatif. 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. facultatif. 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 ligne de base-variant 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 base et canary.

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 ligne 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é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 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 ligne de base et de canary 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. Elles reçoivent à la place le nombre spécifié de réplicas, ce qui signifie qu’elles 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. facultatif. 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. facultatif. 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. facultatif. 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. facultatif. Utilisez quand action = bake && renderType = helm.

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


overrideFiles - Remplacer les fichiers
string. facultatif. 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 bakés.


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

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


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

Spécifie l’argument qui doit être le chemin du 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.


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

Spécifie le nom de l’objet K8s.


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. facultatif. 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 transmettre un secret qui contient un mot de passe de registre de conteneurs au Kubelet, afin qu’il puisse extraire une image privée pour le compte de votre pod.


secretName - Nom du secret
string. facultatif. 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. facultatif. 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. facultatif. 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 dans le cluster. Les fichiers manifeste sous le imagePullSecrets champ peuvent ensuite faire référence au nom de ce secret.


rolloutStatusTimeout - Délai d’expiration pour les status de déploiement
string. facultatif. 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 status.


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 dans les étapes, les travaux et les étapes en aval.

manifestsBundle
Emplacement des bundles de manifeste créés par l’action bake

Remarques

Considérations relatives à la connexion Kubernetes Service lors de l’accès à AKS

Vous pouvez créer une connexion de service Kubernetes avec l’une des options suivantes.

  • KubeConfig
  • Compte Service Account
  • Abonnement Azure

Capture d’écran du choix d’une méthode d’authentification de connexion de service Kubernetes.

Lorsque vous sélectionnez l’option Abonnement Azure , Kubernetes doit être accessible à Azure DevOps au moment de la configuration de la connexion de service. Il peut y avoir différentes raisons pour lesquelles une connexion de service ne peut pas être créée, par exemple vous avez créé un cluster privé ou si les comptes locaux du cluster sont désactivés. Dans ce cas, Azure DevOps ne peut pas se connecter à votre cluster au moment de la configuration de la connexion de service et vous verrez un écran Chargement des espaces de noms bloqué.

Capture d’écran de la sélection d’une boîte de dialogue d’authentification de connexion de service Kubernetes bloquée lors du chargement des espaces de noms.

À compter de Kubernetes 1.24, les jetons à longue durée de vie ne sont plus créés par défaut. Kubernetes recommande de ne pas utiliser de jetons de longue durée. Par conséquent, les tâches utilisant une connexion de service Kubernetes créée avec l’option Abonnement Azure n’ont pas accès au jeton permanent requis pour l’authentification et ne peuvent pas accéder à votre cluster Kubernetes. Cela entraîne également la boîte de dialogue Chargement des espaces de noms figé.

Utiliser la connexion de service Azure Resource Manager pour accéder à AKS

Pour les clients AKS, le type de connexion de service Azure Resource Manager fournit la meilleure méthode pour se connecter à un cluster privé ou à un cluster dont les comptes locaux sont désactivés. Cette méthode ne dépend pas de la connectivité du cluster au moment où vous créez une connexion de service. L’accès à AKS est différé au runtime de pipeline, ce qui présente les avantages suivants :

  • L’accès à un cluster AKS (privé) peut être effectué à partir d’un agent auto-hébergé ou identique avec une visibilité directe vers le cluster.
  • Un jeton est créé pour chaque tâche qui utilise une connexion de service Azure Resource Manager. Cela garantit que vous vous connectez à Kubernetes avec un jeton de courte durée, qui est la recommandation Kubernetes.
  • AKS est accessible même lorsque les comptes locaux sont désactivés.

FAQ sur la connexion de service

Je reçois le message d’erreur suivant : Impossible de trouver un secret associé au compte de service. Ce qui se passe

Vous utilisez la connexion au service Kubernetes avec l’option Abonnement Azure. Nous mettons à jour cette méthode pour créer des jetons de longue durée. Cette option devrait être disponible à la mi-mai. Toutefois, il est recommandé de commencer à utiliser le type de connexion de service Azure et de ne pas utiliser de jetons de longue durée conformément aux instructions Kubernetes.

J’utilise AKS et ne souhaite rien changer. Puis-je continuer à utiliser des tâches avec la connexion au service Kubernetes ?

Nous mettons à jour cette méthode pour créer des jetons de longue durée. Cette option devrait être disponible à la mi-mai. Toutefois, n’oubliez pas que cette approche va à l’encontre des conseils de Kubernetes.

J’utilise les tâches Kubernetes et la connexion au service Kubernetes, mais pas AKS. Dois-je être inquiet ?

Vos tâches continueront à fonctionner comme avant.

Le type de connexion de service Kubernetes sera-t-il supprimé ?

Nos tâches Kubernetes fonctionnent avec n’importe quel cluster Kubernetes, quel que soit l’endroit où elles s’exécutent. La connexion au service Kubernetes continue d’exister.

Je suis un client AKS et tout va bien, dois-je agir ?

Il n’est pas nécessaire de changer quoi que ce soit. Si vous utilisez la connexion au service Kubernetes et que vous avez sélectionné l’abonnement Azure lors de la création, vous devez connaître les conseils Kubernetes sur l’utilisation de jetons de longue durée.

Je crée un environnement Kubernetes et n’ai pas la possibilité d’utiliser des connexions de service

Si vous ne pouvez pas accéder à votre AKS au moment de la création de l’environnement, vous pouvez utiliser un environnement vide et définir l’entrée connectionType sur une connexion de service Azure Resource Manager.

AKS est configuré avec le RBAC Azure Active Directory et mon pipeline ne fonctionne pas. Ces mises à jour permettront-elles de résoudre ce problème ?

L’accès à Kubernetes lorsque le RBAC AAD est activé n’est pas lié à la création de jetons. Pour éviter une invite interactive, nous allons prendre en charge kubelogin dans une prochaine mise à jour.

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 comme 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 extraient la version appropriée 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 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/execution
    • 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 du 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 deploy pour augmenter les fichiers manifeste 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 conduit à la création de noms de charge de travail avec suffixe -baseline et -canary. La tâche prend en charge deux méthodes de fractionnement du trafic :

    • Interface de maillage de service : l’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 base 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 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 des pourcentages. 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 requête. Toutefois, vous pouvez effectuer des déploiements de canaris en utilisant des variantes 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 satisfaites. Le manifeste Kubernetes respecte ces requêtes 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 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 manifeste. 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 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 ligne de base avec 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 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 baker

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 correction d’objets :

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 permettrait de le suspendre afin que l’administrateur du pipeline puisse évaluer les mesures clés pour les versions de ligne de base et canary puis prendre la décision de déterminer si les modifications de canary sont fiables et suffisantes 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, seul le variant stable des charges de travail déclarées dans les fichiers manifestes d’entrée reste déployé dans le cluster, tandis que les versions de ligne de base et canary éphémères sont nettoyées.

Configuration requise

Condition requise Description
Types de pipelines YAML, build classique, version classique
S’exécute sur Agent, DeploymentGroup
Demandes None
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