Déploiement avec `kubectl apply`

La commande `kubectl apply` : l'approche déclarative en action

Maintenant que nous disposons de nos fichiers manifestes YAML décrivant l'état souhaité pour notre Déploiement Nginx (`nginx-deployment.yaml`) et notre Service (`nginx-service.yaml`), il est temps de demander à Kubernetes de concrétiser cette configuration. L'outil principal pour interagir avec l'API Kubernetes est `kubectl`, et la commande clé pour l'approche déclarative est `kubectl apply`.

Contrairement aux commandes impératives (comme `kubectl run` ou `kubectl create`) qui disent à Kubernetes comment faire quelque chose, `kubectl apply -f ` lui indique quel état final est désiré. Kubernetes se charge ensuite de déterminer les actions nécessaires pour atteindre cet état. Si l'objet décrit dans le fichier n'existe pas, il le crée. S'il existe déjà, Kubernetes compare la configuration dans le fichier avec la configuration actuelle de l'objet dans le cluster et applique uniquement les différences.

Cette nature déclarative et idempotente (appliquer plusieurs fois le même fichier produit le même résultat final) est l'un des grands avantages de Kubernetes. Elle facilite l'automatisation, la gestion des configurations via le versionnement (par exemple avec Git) et réduit les risques d'erreurs lors des mises à jour.

Application des manifestes de Déploiement et de Service

Pour déployer notre application Nginx, nous devons appliquer les deux fichiers manifestes que nous avons créés. Ouvrez votre terminal, assurez-vous que `kubectl` est configuré pour communiquer avec votre cluster local (Minikube, Kind, etc.) et naviguez jusqu'au répertoire où vous avez sauvegardé vos fichiers `nginx-deployment.yaml` et `nginx-service.yaml`.

Exécutez ensuite les commandes suivantes. L'ordre dans lequel vous appliquez ces deux fichiers n'a généralement pas d'impact critique pour des objets indépendants comme ceux-ci, mais il est souvent logique d'appliquer le Déploiement en premier :

kubectl apply -f nginx-deployment.yaml

Après l'exécution de cette commande, vous devriez voir une sortie indiquant que le déploiement a été créé, quelque chose comme :

deployment.apps/nginx-deployment created

Appliquez ensuite le manifeste du Service :

kubectl apply -f nginx-service.yaml

De même, vous obtiendrez une confirmation :

service/nginx-service created

Si vous réexécutez les mêmes commandes `kubectl apply`, la sortie changera probablement en `deployment.apps/nginx-deployment configured` et `service/nginx-service configured`, indiquant que les objets existent déjà et que Kubernetes a vérifié/appliqué la configuration spécifiée dans les fichiers.

Que se passe-t-il en coulisses ?

Lorsque vous exécutez `kubectl apply -f nginx-deployment.yaml`, `kubectl` envoie le contenu du fichier YAML à l'API Server de Kubernetes. Le contrôleur de Déploiement détecte cette nouvelle ressource ou sa mise à jour. Il lit la spécification (`spec`), notamment le nombre de `replicas` (2 dans notre cas) et le `template` du Pod.

Le contrôleur crée alors un objet ReplicaSet (géré automatiquement par le Déploiement) responsable de maintenir le nombre souhaité de Pods. Le ReplicaSet, à son tour, demande la création des Pods basés sur le `template` fourni. Le scheduler de Kubernetes assigne ensuite ces Pods à des Noeuds disponibles dans le cluster.

De manière similaire, lorsque vous appliquez `nginx-service.yaml`, le contrôleur de Service crée la ressource Service. Il configure le routage interne (ClusterIP) et, comme nous avons spécifié `type: NodePort`, il demande à Kube-Proxy sur chaque Noeud d'ouvrir le `nodePort` spécifié (30080) et de rediriger le trafic arrivant sur ce port vers les Pods correspondants (identifiés par le `selector`).

Tout ce processus est asynchrone. La commande `kubectl apply` retourne rapidement après avoir soumis la requête à l'API Server, mais la création et la mise en route effective des Pods peuvent prendre quelques secondes. C'est pourquoi l'étape suivante consiste à vérifier l'état réel des ressources que nous venons de demander.