kubectl apply vs set : Choisir la bonne commande pour les mises à jour de ressources

Kubernetes, la plateforme d'orchestration de conteneurs leader, fournit des outils puissants pour gérer le cycle de vie des applications. Un aspect essentiel de cette gestion implique la mise à jour des ressources existantes comme les Deployments, les Services ou les ConfigMaps. Bien que kubectl offre plusieurs commandes à cette fin, kubectl apply et la famille de commandes kubectl set/kubectl edit représentent deux philosophies fondamentalement différentes : les mises à jour déclaratives versus impératives.

Comprendre quand et comment utiliser chaque approche est crucial pour maintenir des déploiements Kubernetes stables, fiables et auditables. Une mauvaise utilisation de ces commandes peut entraîner une dérive de configuration, un débogage difficile et des incohérences opérationnelles. Cet article approfondira les nuances de kubectl apply, kubectl set et kubectl edit, vous fournissant les connaissances nécessaires pour prendre des décisions éclairées concernant vos stratégies de mise à jour des ressources.

Le défi principal : Gérer l'état des ressources

Dans Kubernetes, chaque composant — d'un Pod en cours d'exécution à un Service réseau — est représenté comme un objet API. Ces objets ont un état désiré, que vous définissez dans des fichiers manifestes YAML ou JSON, et un état observé, qui reflète leur réalité actuelle au sein du cluster. L'objectif principal de toute commande de mise à jour kubectl est de concilier ces deux états, mais la méthode de conciliation varie considérablement.

Comprendre kubectl apply : L'approche déclarative

kubectl apply est la pierre angulaire de la gestion déclarative des ressources dans Kubernetes. Avec cette approche, vous définissez l' état désiré de vos ressources dans un fichier de configuration local (ou un répertoire de fichiers), puis vous indiquez à Kubernetes de faire correspondre l'état du cluster à cette définition.

Comment kubectl apply fonctionne (fusion à trois voies)

Lorsque vous exécutez kubectl apply -f votre-manifeste.yaml, Kubernetes effectue une fusion à trois voies sophistiquée :

1. Dernière configuration appliquée : L'état de la ressource tel qu'il a été appliqué pour la dernière fois à l'aide de kubectl apply. Cet état est stocké dans une annotation (kubectl.kubernetes.io/last-applied-configuration) sur l'objet en direct.
2. Configuration en direct : L'état actuel de la ressource dans le serveur API Kubernetes.
3. Nouvelle configuration : L'état défini dans votre fichier votre-manifeste.yaml.

L'algorithme de fusion compare ces trois versions pour déterminer les modifications à apporter. Il gère intelligemment les conflits, priorisant les changements de la nouvelle configuration tout en respectant les champs qui ont été modifiés de manière impérative depuis la dernière apply (bien que cela puisse entraîner des problèmes, comme discuté ci-dessous).

Ce processus garantit l'idempotence : l'application du même manifeste plusieurs fois entraînera le même état de cluster sans effets secondaires indésirables, à condition qu'aucun autre changement ne se soit produit.

Exemple pratique : Application d'un déploiement

Supposons que vous ayez un fichier deployment.yaml :

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
  labels:
    app: my-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webapp
  template:
    metadata:
      labels:
        app: my-webapp
    spec:
      containers:
      - name: webapp-container
        image: nginx:1.21.0
        ports:
        - containerPort: 80

Pour créer ou mettre à jour ce déploiement, vous exécuteriez :

kubectl apply -f deployment.yaml

Si vous modifiez ultérieurement l'image en nginx:1.22.0 dans deployment.yaml et exécutez kubectl apply à nouveau, Kubernetes mettra à jour le déploiement pour utiliser la nouvelle image tout en préservant les autres paramètres.

Avantages de kubectl apply

• Source de vérité : Vos fichiers de configuration deviennent la source unique de vérité pour l'état désiré de votre cluster. Cela s'aligne bien avec les principes GitOps.
• Auditabilité et contrôle de version : Les modifications sont suivies dans votre système de contrôle de version (par exemple, Git), offrant une piste d'audit claire et des retours arrière faciles.
• Cohérence : Assure la cohérence entre les environnements (développement, staging, production).
• Idempotence : Les opérations apply répétées ont le même effet, empêchant les modifications involontaires.
• Mises à jour complexes : Gère les mises à jour complexes impliquant plusieurs types de ressources ou des changements significatifs sur de nombreux champs.

Quand utiliser kubectl apply

• Méthode principale pour toutes les créations et mises à jour de ressources.
• Lors du déploiement d'applications via des pipelines CI/CD.
• Pour la gestion de l'infrastructure en tant que code.
• Lorsque vous travaillez en équipe pour garantir des configurations cohérentes.

Conseils et avertissements pour kubectl apply

• Gardez toujours vos fichiers manifestes à jour avec l'état désiré. Toutes les modifications kubectl set ou kubectl edit non reflétées dans vos fichiers manifestes seront écrasées ou provoqueront des conflits de fusion lors de la prochaine apply.
• Gestionnaires de champs : Kubernetes 1.16+ a introduit l'Application côté serveur (SSA), qui suit le « gestionnaire de champs » (par exemple, kubectl, un contrôleur) responsable de chaque champ d'une ressource. Cela aide à prévenir les conflits lorsque plusieurs sources modifient la même ressource. Bien que puissant, soyez conscient de la manière dont les différents outils pourraient interagir avec la gestion des champs.

Comprendre kubectl set et kubectl edit : L'approche impérative

kubectl set et kubectl edit appartiennent à la famille de commandes impératives. Au lieu de définir l'état désiré dans un fichier, vous instruisez directement Kubernetes d'effectuer des actions spécifiques ou de modifier des objets en direct au sein du cluster. Ces commandes sont excellentes pour des changements rapides et ad hoc, mais elles comportent certaines mises en garde.

kubectl set : Modifications impératives ciblées

kubectl set est conçu pour effectuer des modifications spécifiques et courantes sur les ressources sans avoir besoin de toucher un fichier manifeste. Il offre plusieurs sous-commandes pour modifier des champs particuliers.

Comment kubectl set fonctionne

kubectl set modifie directement l'objet en direct dans le serveur API Kubernetes en fonction des arguments de ligne de commande que vous fournissez. Il n'interagit pas avec les fichiers manifestes locaux et ne met pas à jour l'annotation last-applied-configuration.

Exemple pratique : Définir une image

Pour mettre à jour l'image d'un conteneur au sein d'un déploiement nommé my-webapp :

kubeclt set image deployment/my-webapp webapp-container=nginx:1.22.0

Cette commande modifie directement le champ image pour le webapp-container au sein du déploiement my-webapp. Si vous aviez précédemment géré my-webapp avec kubectl apply, ce changement créerait une « dérive » entre votre deployment.yaml local et l'état du cluster en direct.

Autres commandes kubectl set courantes :

• kubectl set resources : Pour définir les requêtes/limites de ressources.
• kubectl set env : Pour ajouter ou mettre à jour des variables d'environnement.
• kubectl set selector : Pour modifier le sélecteur d'une ressource.

kubectl edit : Modifications impératives interactives

kubectl edit vous permet de modifier directement n'importe quel champ d'un objet ressource en direct dans votre cluster en utilisant votre éditeur de texte par défaut configuré (par exemple, vi, nano).

Comment kubectl edit fonctionne

Lorsque vous exécutez kubectl edit <type-de-ressource>/<nom-de-ressource> :

1. kubectl récupère la définition YAML actuelle de la ressource en direct du serveur API.
2. Il ouvre cette définition dans votre éditeur de texte local.
3. Vous effectuez les modifications souhaitées et enregistrez le fichier.
4. kubectl renvoie ensuite la définition modifiée au serveur API, qui tente d'appliquer les changements. S'il y a des erreurs de syntaxe ou des champs invalides, les changements seront rejetés.

Comme kubectl set, kubectl edit opère également directement sur l'objet en direct et ne met pas à jour les fichiers manifestes locaux ni l'annotation last-applied-configuration.

Exemple pratique : Éditer un déploiement

Pour ouvrir le déploiement my-webapp dans votre éditeur :

kubeclt edit deployment/my-webapp

Votre éditeur s'ouvrira avec une représentation YAML du déploiement en direct. Vous pouvez alors modifier des champs comme replicas, image, ou ajouter de nouvelles annotations/labels. Une fois que vous enregistrez et fermez l'éditeur, kubectl tente d'appliquer ces changements.

Avantages de kubectl set et kubectl edit

• Rapidité : Excellent pour les corrections rapides et ponctuelles ou le débogage dans un environnement de développement.
• Flexibilité : Modifiez directement n'importe quel champ d'une ressource (avec edit).
• Changements ad hoc : Utile lorsque vous n'avez pas de fichier manifeste facilement disponible ou que vous ne voulez pas en créer un pour un changement trivial.

Quand utiliser kubectl set/kubectl edit

• Débogage dans un cluster de développement : Augmenter temporairement le nombre de réplicas ou changer une image pour tester une correction.
• Petits changements non critiques et temporaires dans des environnements hors production.
• Exploration des définitions de ressources : kubectl edit est un moyen pratique de voir le YAML complet et en direct d'une ressource.

Avertissements pour kubectl set et kubectl edit

• Dérive de configuration : Les changements effectués avec set ou edit ne sont pas reflétés dans vos fichiers manifestes locaux. La prochaine kubectl apply à partir de votre manifeste écrasera ces changements impératifs ou provoquera des conflits.
• Manque d'auditabilité : Ces changements ne sont pas suivis dans le contrôle de version, ce qui rend difficile de savoir qui a changé quoi et quand, entravant le débogage et la conformité.
• Non-idempotent : Effectuer à plusieurs reprises le même changement impératif peut entraîner un comportement inattendu si l'état initial est inconnu.
• Risque d'erreurs : L'édition manuelle (surtout avec edit) augmente les risques d'introduire des erreurs de syntaxe ou des configurations invalides.

Différences clés : kubectl apply vs. kubectl set/kubectl edit

Pour résumer les distinctions principales :

Caractéristique	kubectl apply (Déclaratif)	kubectl set/kubectl edit (Impératif)
Approche	Définit l'état désiré dans un fichier, Kubernetes réconcilie.	Manipule directement les objets en direct ou des champs spécifiques.
Source de vérité	Fichiers de configuration locaux (par exemple, dépôt Git).	L'objet cluster en direct lui-même (éphémère).
Idempotence	Oui, l'application du même fichier produit le même résultat.	Non, pas intrinsèquement. Chaque commande est une action explicite.
Auditabilité	Élevée (modifications suivies dans Git, last-applied-configuration).	Faible (pas de contrôle de version, les modifications sont immédiates sur le cluster).
Gestion des conflits	Fusion à 3 voies, utilise l'annotation last-applied-configuration.	Écrase directement (pour set) ou fusionne interactivement (pour edit).
Cas d'utilisation	Déploiements de production, CI/CD, GitOps, collaboration d'équipe.	Corrections rapides, débogage, changements ad hoc en non-production.
Risque de dérive	Faible, tant que les fichiers sont maintenus à jour.	Élevé, très susceptible de provoquer une dérive de configuration par rapport aux fichiers source.

Choisir la bonne commande : Bonnes pratiques

Pour les environnements de production et les équipes collaboratives, le choix est clair :

• Toujours préférer kubectl apply (ou les outils GitOps basés sur celui-ci comme Argo CD ou Flux CD) pour gérer vos ressources Kubernetes. Cela garantit que l'état de votre cluster est versionné, auditable et cohérent.
• Traitez vos fichiers manifestes Kubernetes comme votre source unique de vérité. Toutes les modifications des configurations de ressources devraient idéalement provenir de ces fichiers et être validées dans le contrôle de version.

Les commandes impératives comme kubectl set et kubectl edit devraient être réservées pour :

• Le débogage ou les tests temporaires dans les clusters de développement/staging. Si vous les utilisez, assurez-vous de revenir en arrière ou de mettre à jour immédiatement vos fichiers manifestes source pour refléter le nouvel état.
• Les opérations ponctuelles et éphémères qui ne représentent pas un état désiré à long terme (par exemple, mettre en pause un déploiement pendant un court instant).

Approche hybride (à utiliser avec prudence)

Dans certains scénarios, vous pourriez vous retrouver à devoir corriger rapidement quelque chose en production. Bien que généralement déconseillé, si vous devez utiliser kubectl edit :

1. Comprenez les implications de la dérive de configuration.
2. Capturez immédiatement les changements en exécutant kubectl get <resource> -o yaml > new-manifest.yaml.
3. Intégrez ces changements dans vos fichiers manifestes versionnés aussi rapidement que possible.

Avertissement : L'utilisation régulière de kubectl edit ou kubectl set en production sans mettre à jour vos manifestes source entraînera un état de cluster ingérable et irrécupérable où la configuration réelle divergera énormément de ce que votre équipe pense qu'elle devrait être.

Conclusion

kubectl apply, kubectl set et kubectl edit sont tous des outils puissants pour interagir avec votre cluster Kubernetes. Cependant, ils servent des objectifs différents et incarnent des philosophies distinctes de gestion des ressources. En comprenant la nature déclarative de kubectl apply et la nature impérative de kubectl set et kubectl edit, vous pouvez adopter les meilleures pratiques qui mènent à des déploiements Kubernetes plus stables, fiables et maintenables.

Pour presque toute gestion persistante des ressources, en particulier en production, privilégiez kubectl apply et contrôlez la version de vos fichiers de configuration. Réservez les commandes impératives pour le dépannage temporaire et ad hoc, et assurez-vous que tout changement critique est rapidement reflété dans vos manifestes déclaratifs. Cette discipline sera inestimable pour des opérations fluides et une collaboration transparente au sein de votre environnement Kubernetes.