Partager via

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

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

Syntaxe

# 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.
    #resourceType: 'Microsoft.ContainerService/managedClusters' # string. Optional. Use when action = deploy. Resource type. Default: Microsoft.ContainerService/managedClusters.

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

Données d'entrée

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. Obligatoire lorsque action != bake. Valeurs autorisées : azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (Connexion au service Kubernetes). Valeur par défaut : kubernetesServiceConnection.

Sélectionnez un type de connexion au service Kubernetes.

  • kubernetesServiceConnection (Connexion au service Kubernetes) : vous permet de fournir un fichier KubeConfig, de spécifier un compte de service ou d’importer une instance AKS avec l’option d’abonnement Azure . L’importation d’une instance AKS avec l’option abonnement Azure nécessite l’accès au cluster Kubernetes au moment de la configuration de la connexion de service.
  • azureResourceManager (Azure Resource Manager) : vous permet de sélectionner une 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 - de connexion de service Kubernetes
Alias d’entrée : kubernetesServiceEndpoint. string. Obligatoire lorsque action != bake && connectionType = kubernetesServiceConnection.

Spécifie une connexion de service Kubernetes .


azureSubscriptionConnection - abonnement Azure
Alias d’entrée : azureSubscriptionEndpoint. string. Obligatoire 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 et 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 au service Azure à l’aide du bouton « Ajouter » ou « Gérer ».


azureResourceGroup - groupe de ressources
string. Obligatoire lorsque action != bake && connectionType = azureResourceManager.

Sélectionnez un groupe de ressources Azure.


kubernetesCluster - de cluster Kubernetes
string. Obligatoire lorsque action != bake && connectionType = azureResourceManager.

Sélectionnez un cluster managé Azure.


useClusterAdmin - Utiliser les informations d’identification de l’administrateur de cluster
boolean. Optionnel. 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 de cluster par défaut.


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.


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

Spécifie le nom de l’objet K8s.


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.


resourceType - type de ressource
string. Optionnel. Utilisez quand action = deploy. Valeur par défaut : Microsoft.ContainerService/managedClusters.

Le type de la ressource (flotte, cluster géré).


Options de contrôle de tâche

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

manifestsBundle
L’emplacement des bundles de manifestes 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 de service
  • 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 au service. Il peut y avoir différentes raisons pour lesquelles une connexion de service ne peut pas être créée, par exemple, vous créé un cluster privé ou le cluster a comptes locaux 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 bloqué charger des espaces de noms écran.

Capture d’écran du choix 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 de longue durée 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 s’authentifier et ne peuvent pas accéder à votre cluster Kubernetes. Cela entraîne également le gel boîte de dialogue Chargement des espaces de noms.

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 de groupe identique en ligne de vue sur 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. Que se passe-t-il?

Vous utilisez la connexion de service Kubernetes avec l’option Abonnement Azure. Nous mettons à jour cette méthode pour créer des jetons de longue durée. Cela devrait être disponible 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 de Kubernetes .

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

Nous mettons à jour cette méthode pour créer des jetons de longue durée. Cela devrait être disponible mi-mai. Toutefois, sachez que cette approche est contre conseils Kubernetes.

J’utilise les tâches Kubernetes et la connexion de service Kubernetes, mais pas AKS. Dois-je m’inquiéter ?

Vous continuerez à travailler comme avant.

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

Nos tâches Kubernetes fonctionnent avec n’importe quel cluster Kubernetes, quel que soit leur emplacement d’exécution. La connexion du service Kubernetes continuera d’exister.

Je suis un client AKS et tout fonctionne correctement, dois-je agir ?

Il n’est pas nécessaire de changer quoi que ce soit. Si vous utilisez la connexion de 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 pendant 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.

J’ai configuré AKS avec Azure Active Directory RBAC et mon pipeline ne fonctionne pas. Ces mises à jour seront-elles résolues ?

L’accès à Kubernetes quand AAD RBAC est activé n’est pas lié à la création de jetons. Pour empêcher 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 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 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 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
Capacités Cette tâche ne répond à aucune demande de tâches ultérieures dans le travail.
restrictions de commande N'importe lequel
variables settables N'importe lequel
Version de l’agent Toutes les versions de l’agent prises en charge.
Catégorie de tâche Déployer
  • Last updated on