Appliquer le manifeste avec `kubectl apply -f `

L'outil clé de l'approche déclarative : `kubectl apply`

Une fois votre manifeste YAML rédigé et enregistré, l'étape suivante consiste à le communiquer au cluster Kubernetes. C'est là qu'intervient la commande `kubectl apply`. C'est la commande fondamentale pour mettre en oeuvre l'approche déclarative : vous présentez votre fichier de configuration (l'état désiré) à Kubernetes, et `kubectl apply` se charge de demander au cluster de faire le nécessaire pour atteindre cet état.

Cette commande est au coeur de la gestion des ressources via les manifestes. Elle permet non seulement de créer de nouvelles ressources, mais aussi de mettre à jour celles qui existent déjà, le tout à partir du même fichier YAML. Comprendre son fonctionnement est essentiel pour interagir efficacement avec votre cluster.

La syntaxe la plus courante est simple et directe : `kubectl apply -f `. L'option `-f` (ou `--filename`) indique à `kubectl` de lire la configuration depuis le fichier spécifié. Vous pouvez également appliquer tous les manifestes présents dans un répertoire en spécifiant le chemin du répertoire : `kubectl apply -f `.

Le mécanisme déclaratif en action : créer ou mettre à jour

La puissance de `kubectl apply` réside dans son comportement déclaratif et idempotent. Lorsque vous exécutez cette commande, `kubectl` envoie le contenu de votre manifeste à l'API Server de Kubernetes. L'API Server compare alors la configuration décrite dans le fichier avec l'état actuel de la ressource correspondante (identifiée par son `kind`, `apiVersion`, `name`, et `namespace`) dans le cluster.

Plusieurs scénarios sont possibles :

• Si l'objet n'existe pas encore : Kubernetes le crée conformément aux spécifications du manifeste. La commande affichera généralement un message comme `deployment.apps/nginx-deployment created`.
• Si l'objet existe déjà : Kubernetes compare la configuration dans le manifeste avec la configuration actuelle de l'objet dans le cluster. Il calcule les différences et applique uniquement les modifications nécessaires pour que l'objet corresponde à l'état décrit dans le manifeste. Les champs non spécifiés dans votre manifeste mais présents dans l'objet live ne sont généralement pas modifiés (c'est un mécanisme de fusion intelligente, ou "merge patch"). La commande affichera alors `deployment.apps/nginx-deployment configured` (ou parfois `unchanged` si aucune modification n'était nécessaire).

Ce mécanisme de comparaison et de mise à jour sélective est ce qui rend `apply` si pratique. Vous n'avez pas besoin de savoir si l'objet existe déjà ou non, ni d'écrire des logiques conditionnelles complexes. Vous décrivez simplement l'état final souhaité dans votre fichier YAML, et `kubectl apply -f mon-fichier.yaml` fait le nécessaire pour y parvenir. Ré-exécuter la même commande `apply` avec le même fichier ne provoquera généralement aucun changement si l'état désiré est déjà atteint (idempotence).

Exécution et interprétation du résultat

Prenons notre fichier `nginx-deployment.yaml` du sous-chapitre précédent. Pour l'appliquer au cluster, nous ouvririons un terminal configuré pour communiquer avec notre cluster Kubernetes (par exemple, Minikube ou Kind localement) et exécuterions la commande suivante :

kubectl apply -f nginx-deployment.yaml

Si c'est la première fois que nous appliquons ce manifeste, la sortie attendue serait :

deployment.apps/nginx-deployment created

Cela signifie que l'API Server a accepté notre demande et a créé un objet de type `Deployment` (du groupe d'API `apps`) nommé `nginx-deployment`.

Si, plus tard, nous modifions le fichier `nginx-deployment.yaml` (par exemple, en changeant `replicas: 2` en `replicas: 3`) et que nous réappliquons le même fichier avec la même commande :

kubectl apply -f nginx-deployment.yaml

La sortie serait alors :

deployment.apps/nginx-deployment configured

Cela indique que l'objet existant a été mis à jour pour correspondre à la nouvelle configuration spécifiée dans le fichier. Kubernetes va maintenant travailler en arrière-plan (via le contrôleur de Deployment) pour ajuster le nombre de Pods à 3.

Il est crucial de comprendre qu'un message `created` ou `configured` de la part de `kubectl apply` signifie que l'API Server a accepté la configuration. Cela ne garantit pas encore que les Pods sont effectivement en cours d'exécution ou que l'application fonctionne correctement. La validation de l'état réel des ressources est l'objet de l'étape suivante de notre séquence de déploiement.

Sous le capot : interaction avec l'API Server

Lorsque vous lancez `kubectl apply -f`, l'outil `kubectl` lit le fichier YAML, le parse, et effectue une requête HTTP (généralement un PATCH ou un POST selon que l'objet existe ou non) vers l'endpoint approprié de l'API Server Kubernetes. Le corps de cette requête contient la définition de l'objet issue de votre manifeste.

L'API Server reçoit cette requête. Il commence par valider la syntaxe du manifeste, vérifie que les `apiVersion` et `kind` sont corrects, et s'assure que vous avez les permissions nécessaires pour créer ou modifier cet objet (via RBAC). Si la validation échoue, `kubectl` retournera une erreur immédiate.

Si la validation réussit, l'API Server enregistre l'état désiré (la `spec` de votre manifeste) dans etcd, la base de données distribuée clé-valeur qui sert de "source de vérité" pour l'état du cluster. C'est cette écriture dans etcd qui déclenche l'action.

Les contrôleurs spécifiques à chaque `kind` (par exemple, le contrôleur de Deployment) surveillent en permanence les changements dans etcd pour les objets qu'ils gèrent. Lorsqu'un contrôleur détecte une modification de l'état désiré (la `spec`) ou une différence entre l'état désiré et l'état actuel (`status`), il initie les actions nécessaires pour réconcilier les deux. Dans le cas de notre Deployment, le contrôleur créera ou supprimera des ReplicaSets et des Pods pour atteindre le nombre de `replicas` spécifié.

Ainsi, `kubectl apply` est le point d'entrée qui enregistre votre intention, mais c'est le travail continu des contrôleurs en arrière-plan qui assure la réalisation effective de cet état désiré.