Ce que j'ai compris dans la documentation, c'est que:

• kubectl create = Crée une nouvelle ressource k8s dans le cluster
• kubectl replace = Met à jour une ressource dans le cluster en direct
• kubectl apply = Si je veux faire créer + remplacer ( Référence )

Mes questions sont

1. Pourquoi y a-t-il trois opérations pour effectuer la même tâche dans un cluster?
2. Quels sont les cas d'utilisation de ces opérations?
3. En quoi diffèrent-ils les uns des autres sous le capot?

Ce sont deux approches différentes:

Gestion impérative

kubectl createest ce que nous appelons la gestion impérative . Dans cette approche, vous indiquez à l'API Kubernetes ce que vous souhaitez créer, remplacer ou supprimer, et non à quoi vous voulez que votre monde de cluster K8 ressemble.

Gestion déclarative

kubectl applyfait partie de l' approche de la gestion déclarative , où les modifications que vous avez pu appliquer à un objet vivant (c'est-à-dire par le biais scale) sont " maintenues " même si vous avez d' applyautres modifications de l'objet.

Vous pouvez en savoir plus sur la gestion impérative et déclarative dans la documentation Kubernetes Object Management .

Lors de l'exécution dans un script CI, vous aurez des problèmes avec les commandes impératives car create déclenche une erreur si la ressource existe déjà.

Ce que vous pouvez faire est d' appliquer (modèle déclaratif) la sortie de votre commande impérative, en utilisant --dry-run=trueet les -o yamloptions:

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

La commande ci-dessus ne déclenchera pas d'erreur si la ressource existe déjà (et mettra à jour la ressource si nécessaire).

Ceci est très utile dans certains cas où vous ne pouvez pas utiliser le modèle déclaratif (par exemple lors de la création d'un secret de registre docker).

Juste pour donner une réponse plus simple, d'après ma compréhension:

apply- apporte des modifications incrémentielles à un objet existant
create- crée un tout nouvel objet (auparavant inexistant / supprimé)


En prenant cela à partir d'un article DigitalOcean qui a été lié par le site Web de Kubernetes:

Nous utilisons Appliquer au lieu de créer ici afin qu'à l'avenir, nous puissions appliquer progressivement les modifications aux objets Ingress Controller au lieu de les remplacer complètement.

Ce sont des commandes impératives :

kubectl run = kubectl create deployment

Avantages:

• Simple, facile à apprendre et facile à retenir.
• Ne nécessite qu'une seule étape pour apporter des modifications au cluster.

Désavantages:

• Ne pas intégrer aux processus de révision des changements.
• Ne fournissez pas de piste d'audit associée aux modifications.
• Ne fournissez pas de source d'enregistrement, sauf pour ce qui est en direct.
• Ne fournissez pas de modèle pour créer de nouveaux objets.

Ce sont des configurations d'objet impératives :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Avantages par rapport aux commandes impératives:

• Peut être stocké dans un système de contrôle de source tel que Git.
• Peut s'intégrer à des processus tels que l'examen des modifications avant l'envoi et les pistes d'audit.
• Fournit un modèle pour créer de nouveaux objets.

Inconvénients par rapport aux commandes impératives:

• Nécessite une compréhension de base du schéma d'objet.
• Nécessite l'étape supplémentaire d'écriture d'un fichier YAML.

Avantages par rapport à la configuration d'objet déclarative:

• Plus simple et plus facile à comprendre.
• Plus mature après la version 1.5 de Kubernetes.

Inconvénients par rapport à la configuration d'objet déclarative:

• Fonctionne mieux sur les fichiers, pas sur les répertoires.
• Les mises à jour des objets vivants doivent être reflétées dans les fichiers de configuration, sinon elles seront perdues lors du prochain remplacement.

Ce sont des configurations d'objets déclaratifs

kubectl diff -f configs/

kubectl apply -f configs/

Avantages par rapport à la configuration d'objet impérative:

• Les modifications apportées directement aux objets vivants sont conservées, même si elles ne sont pas fusionnées dans les fichiers de configuration.
• Meilleure prise en charge des opérations sur les répertoires et détection automatique des types d'opérations (créer, corriger, supprimer) par objet.

Inconvénients par rapport à la configuration impérative des objets:

• Plus difficile à déboguer et à comprendre les résultats lorsqu'ils sont inattendus.
• Les mises à jour partielles à l'aide de diffs créent des opérations complexes de fusion et de correctif.

L'explication ci-dessous de la documentation officielle m'a aidé à comprendre kubectl apply.

Cette commande comparera la version de la configuration que vous envoyez avec la version précédente et appliquera les modifications que vous avez apportées, sans écraser les modifications automatisées des propriétés que vous n'avez pas spécifiées.

kubectl create d'autre part, créera (ne devrait pas exister) des ressources.

kubectl create peut fonctionner avec un fichier de configuration d'objet à la fois. Ceci est également connu sous le nom de gestion impérative

kubectl create -f filename | url

kubectl apply fonctionne avec les répertoires et ses sous-répertoires contenant des fichiers yaml de configuration d'objet. Ceci est également connu sous le nom de gestion déclarative. Plusieurs fichiers de configuration d'objet provenant de répertoires peuvent être récupérés. kubectl applique le répertoire -f /

Détails:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

Nous aimons Kubernetes parce qu'une fois que nous leur donnons ce que nous voulons, il continue à comprendre comment y parvenir sans notre participation.

«créer», c'est comme jouer à DIEU en prenant les choses en main. Il est bon pour le débogage local lorsque vous souhaitez uniquement travailler avec le POD et ne vous souciez pas du contrôleur de déploiement / réplication.

"appliquer" joue selon les règles. "appliquer" est comme un outil maître qui vous aide à créer et à modifier et ne nécessite rien de vous pour gérer les pods.