Name: Tremplin Numérique
Price range: $$$

Kubernetes est généralement décrit comme un système déclaratif. La plupart du temps, vous travaillez avec YAML qui définit à quoi devrait ressembler l’état final du système. Kubernetes prend également en charge les API impératives, où vous émettez une commande et obtenez une sortie immédiate.

Dans cet article, nous allons explorer les différences entre ces deux formes de gestion d’objets. Il y a de fortes chances que vous ayez déjà utilisé les deux, même si vous ne reconnaissez pas les termes.

Sommaire

Déclaratif vs impératif : définitions

Il est d’abord utile d’examiner la terminologie.

Quelque chose qui est déclaratif fait une déclaration du résultat final, indiquant l’intention mais pas le processus pour y parvenir. Dans Kubernetes, cela signifie « Il devrait y avoir un ReplicaSet avec trois pods ».

Une impératif agit comme une commande. Alors qu’un déclaratif est passif, les impératifs sont actifs et immédiats : « Créer un ReplicaSet avec trois pods ».

L’écosystème Kubernetes fournit des mécanismes pour interagir avec votre cluster sous l’une ou l’autre de ces formes. Les approches impératives sont prises en charge par les commandes CLI et les fichiers YAML individuels. La configuration déclarative est facilitée à l’aide de répertoires de fichiers qui sont combinés dans la représentation finale des ressources.

Gérer les objets de manière impérative

Voici un exemple de création d’un déploiement impératif :

kubectl create deployment my-deployment --image my-image:latest

Vous demandez à Kubernetes d’ajouter immédiatement un nouveau déploiement à votre cluster. La commande comprend un seul verbe (create) et le nom du type de ressource avec lequel vous travaillez (deployment).

Vous pouvez aussi écrire un fichier YAML et l’appliquer impérativement en utilisant le create commander:

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
        # ...

kubectl create -f deployment.yml

Comme précédemment, vous émettez une commande immédiate via un verbe actif. Kubernetes prendra la configuration de votre fichier et créera les ressources correspondantes dans le cluster. Si vous avez besoin de mettre à jour une ressource, vous devez modifier votre YAML et utiliser le replace commande pour effectuer le changement :

kubectl replace -f deployment.yml

Cette opération va supprimer la spécification de toutes les ressources existantes et remplacez-la par la version dans votre fichier de configuration. Ceci est véhiculé par le nom du replace commander. Cela signifie que vous perdrez toutes les modifications apportées à vos objets actifs qui ne sont pas présents dans votre YAML.

Lorsque Kubernetes utilise des commandes impératives, il faut lui dire exactement quoi faire. Par conséquent, il n’y a aucun moyen d’appliquer de manière sélective uniquement les parties modifiées de votre YAML. Pour cela, vous devrez passer aux opérations déclaratives.

Essayer la gestion déclarative

La gestion déclarative n’est disponible que lorsque vous utilisez des fichiers de configuration YAML. Il n’y a pas de commande déclarative. Lorsque vous utilisez des opérations déclaratives, vous ne dites pas à Kubernetes quoi faire en fournissant un verbe (create/replace). Au lieu de cela, vous utilisez le single apply commandez et faites confiance à Kubernetes pour déterminer les actions à effectuer.

kubectl apply -f deployment.yml

Poursuivant l’exemple de déploiement ci-dessus, appliquer le YAML ci-dessus à votre cluster agirait initialement de la même manière qu’un impératif create commander. Aucune ressource correspondante n’existera pour commencer, donc Kubernetes doit en créer une nouvelle.

Vous pourriez alors changer le replicas champ à 5 et répétez la apply commander. Cette fois, Kubernetes correspondra à la ressource existante, détectera le changement dans votre YAML et fera évoluer le déploiement sans affecter les autres champs.

En utilisant l’approche impérative, vous devez utiliser le kubectl scale pour modifier le nombre de répliques d’un déploiement existant. Si vous avez modifié le YAML que vous avez utilisé avec kubectl create, tu devrais courir kubectl replace – mais cela remplacerait l’ensemble du déploiement spec, au lieu de simplement mettre à l’échelle son nombre de répliques.

Déclaratif vs impératif : comparer les compromis

Les opérations impératives sont simples à comprendre et à raisonner. Chaque action est exprimée par un verbe avec une conséquence clairement définie. Pour cette raison, la plupart des gens commenceront leurs premières interactions avec Kubernetes en utilisant des commandes impératives qui peuvent être librement mappées à d’autres technologies telles que Docker.

La gestion déclarative expose le véritable pouvoir de Kubernetes. Vous déclarez à quoi devrait ressembler l’état final, puis laissez Kubernetes faire le reste. Chaque commande a la même action impérative – apply cet ensemble de fichiers YAML et faites progresser le cluster jusqu’à l’état qu’ils définissent.

La gestion déclarative est idéale pour les déploiements automatisés. Vous n’avez pas besoin de passer du temps à élaborer un ensemble d’instructions de migration chaque fois que vous mettez à jour une ressource. Au lieu de cela, ajustez votre YAML afin qu’il produise des objets correctement configurés s’ils étaient créés à nouveau à l’heure actuelle. Kubernetes gérera les mises à jour des objets existants afin qu’ils correspondent également au nouvel état.

Les fichiers YAML déclaratifs sont faciles à versionner, réviser et fusionner dans le cadre de votre système de contrôle de code source. Si vous utilisez des commandes impératives, vous n’avez aucun moyen de suivre l’évolution de votre cluster et il sera plus difficile de revenir à un état antérieur. Contrairement aux opérations impératives, les mises à jour déclaratives n’écrasent pas l’intégralité de l’objet, vous conserverez donc les modifications que vous avez apportées via d’autres mécanismes, indépendamment de vos fichiers YAML.

Néanmoins, la gestion impérative conserve certains avantages. La configuration déclarative ajoute des couches de complexité et peut être plus difficile à déboguer, en particulier lorsque Kubernetes sélectionne un plan d’action inattendu. Chaque modification entraîne une opération de fusion et de correction pour aligner vos objets sur l’état souhaité. Avec le modèle impératif, ce que vous demandez est ce que vous obtiendrez, à moins qu’une erreur ne se produise.

Comme toujours lorsque deux approches sont proposées, les deux stratégies sont utiles et celle que vous choisissez doit dépendre du contexte. Pour les clusters de production hébergeant des applications en direct avec des modifications fréquentes, vous souhaitez probablement des fichiers YAML déclaratifs versionnés. Si vous lancez rapidement de nouveaux conteneurs dans un cluster de développement, les commandes impératives vous feront gagner du temps et seront plus faciles à utiliser.

Conclusion

La gestion déclarative et impérative sont deux façons d’interagir avec votre cluster Kubernetes et ses ressources. Kubectl a intégré la prise en charge de ces deux stratégies, mais les techniques ne doivent pas être mélangées objet par objet. Si vous créez un objet de manière déclarative, il doit être géré de cette façon tout au long de sa vie – l’utilisation de commandes impératives avec lui peut entraîner un comportement inattendu.

Les opérations impératives affectent les objets actifs au sein de votre cluster. Vous définissez un verbe, une ressource et une configuration via des arguments de commande et des drapeaux. La gestion déclarative est basée sur les modifications apportées aux fichiers de configuration locaux que Kubectl compare et applique au cluster via des correctifs lorsque vous utilisez le kubectl diff et kubectl apply commandes.