Exemple concret : créer un Déploiement pour plusieurs Pods Nginx

Passer de la théorie à la pratique : le manifeste de Déploiement

Après avoir compris le rôle essentiel du Déploiement pour maintenir l'état désiré et le concept sous-jacent du ReplicaSet, il est temps de mettre ces connaissances en application. Nous allons créer un Déploiement qui garantira l'exécution de trois instances (réplicas) d'un serveur web Nginx. Contrairement à l'approche impérative rapide de `kubectl run`, nous utiliserons ici l'approche déclarative, qui est la méthode standard et recommandée pour gérer les ressources Kubernetes en production.

L'approche déclarative implique la création d'un fichier manifeste, généralement au format YAML (YAML Ain't Markup Language). Ce fichier décrit l'état final que nous souhaitons atteindre pour notre Déploiement : le nombre de réplicas, l'image de conteneur à utiliser, les ports, les labels, etc. Kubernetes lira ensuite ce fichier et prendra les mesures nécessaires pour faire correspondre l'état réel du cluster à cette description.

Préparons-nous à rédiger notre premier manifeste de Déploiement. Créez un fichier nommé, par exemple, `nginx-deployment.yaml` et ouvrez-le dans votre éditeur de texte préféré. Nous allons le remplir étape par étape.

Construction du fichier `nginx-deployment.yaml`

Un manifeste Kubernetes typique commence par des champs définissant la version de l'API à utiliser et le type d'objet que nous créons. Pour un Déploiement, nous utilisons `apps/v1` comme `apiVersion` et `Deployment` comme `kind`.

Ensuite, nous ajoutons les `metadata`, qui contiennent des informations d'identification pour notre objet, comme son nom. Donnons-lui un nom descriptif : `nginx-deployment`.

La partie la plus importante est la section `spec` (spécification), où nous décrivons l'état désiré. Ici, nous allons définir trois éléments clés :

• `replicas` : C'est ici que nous indiquons le nombre souhaité de Pods. Mettons `3`.
• `selector` : Ce champ est crucial. Il indique au Déploiement (et au ReplicaSet qu'il crée) quels Pods il doit gérer. Il utilise des labels. Nous allons définir un `matchLabels` qui ciblera les Pods ayant le label `app: nginx`.
• `template` : Cette section définit le modèle (blueprint) des Pods qui seront créés. C'est essentiellement une spécification de Pod imbriquée.
  • Il doit contenir ses propres `metadata`, notamment un `labels` qui doit correspondre au `selector.matchLabels` du Déploiement (ici, `app: nginx`). C'est ainsi que le lien est établi.
  • Il contient ensuite la `spec` du Pod, définissant les conteneurs. Nous y mettrons un conteneur nommé `nginx`, utilisant l'image `nginx:latest`, et spécifiant que le conteneur écoute sur le port `80`.

Le manifeste YAML complet

En rassemblant tous ces éléments, notre fichier `nginx-deployment.yaml` ressemble à ceci :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Nom du déploiement
  labels:
    app: nginx # Label pour le déploiement lui-même (optionnel mais bonne pratique)
spec:
  replicas: 3 # Nombre désiré de Pods
  selector:
    matchLabels:
      app: nginx # Sélectionne les Pods avec ce label
  template:
    metadata:
      labels:
        app: nginx # Label appliqué aux Pods créés (doit correspondre au sélecteur)
    spec:
      containers:
      - name: nginx
        image: nginx:latest # Image du conteneur
        ports:
        - containerPort: 80 # Port exposé par le conteneur

Prenez le temps de bien comprendre chaque section. La relation entre `spec.selector.matchLabels` et `spec.template.metadata.labels` est fondamentale. C'est ce qui permet au Déploiement de savoir quels Pods il doit compter et gérer pour atteindre le nombre `replicas`.

Ce fichier décrit maintenant de manière déclarative notre objectif : un ensemble de 3 Pods Nginx gérés de manière robuste.

Appliquer le manifeste et vérifier le résultat

Maintenant que notre manifeste est prêt, nous pouvons demander à Kubernetes de le réaliser. Utilisez la commande `kubectl apply` en lui passant le nom de notre fichier :

kubectl apply -f nginx-deployment.yaml

Kubernetes va lire le fichier, comprendre qu'il doit créer un objet Déploiement nommé `nginx-deployment`, et commencer le travail. Vous devriez voir un message comme `deployment.apps/nginx-deployment created`.

Pour vérifier que le Déploiement a bien été créé et qu'il fait son travail, nous pouvons utiliser plusieurs commandes `kubectl get` :

• Vérifier le Déploiement lui-même :

  kubectl get deployment nginx-deployment
  
  # Sortie attendue (peut prendre quelques secondes pour que tout soit prêt) :
  # NAME               READY   UP-TO-DATE   AVAILABLE   AGE
  # nginx-deployment   3/3     3            3           30s

  Ici, `READY 3/3`, `UP-TO-DATE 3`, et `AVAILABLE 3` confirment que nos 3 réplicas sont opérationnels.
• Vérifier le ReplicaSet créé :

  kubectl get rs -l app=nginx # Filtrer par label
  
  # Sortie attendue :
  # NAME                          DESIRED   CURRENT   READY   AGE
  # nginx-deployment-xxxxxxxxxx   3         3         3       45s

  Nous voyons le ReplicaSet géré par notre Déploiement, responsable de nos 3 Pods.
• Vérifier les Pods individuels :

  kubectl get pods -l app=nginx # Filtrer par label
  
  # Sortie attendue :
  # NAME                                READY   STATUS    RESTARTS   AGE
  # nginx-deployment-xxxxxxxxxx-aaaaa   1/1     Running   0          1m
  # nginx-deployment-xxxxxxxxxx-bbbbb   1/1     Running   0          1m
  # nginx-deployment-xxxxxxxxxx-ccccc   1/1     Running   0          1m

  Et voilà ! Nos trois Pods Nginx sont bien en cours d'exécution, chacun avec un nom unique généré automatiquement, et tous portant le label `app=nginx`.

Félicitations ! Vous avez créé avec succès votre premier Déploiement Kubernetes en utilisant l'approche déclarative. Votre application Nginx est maintenant déployée avec 3 réplicas, bénéficiant de l'auto-réparation et de la capacité de mise à l'échelle offertes par le Déploiement. La prochaine étape logique est d'exposer ces Pods pour qu'ils soient accessibles, ce qui est le rôle des Services.