Ecrire un manifeste simple pour un Déploiement

De l'intention à la déclaration : la naissance du manifeste

La première étape concrète de notre séquence de déploiement consiste à traduire notre besoin applicatif en une description que Kubernetes peut comprendre. Cette traduction prend la forme d'un fichier manifeste YAML. Pour gérer une application web stateless classique, comme un serveur Nginx, l'objet Kubernetes le plus approprié est le `Deployment`. C'est lui qui va garantir qu'un nombre spécifié d'instances (Pods) de notre application sont en cours d'exécution et qui gérera leur cycle de vie, notamment lors des mises à jour.

Ecrire un manifeste de Deployment revient à spécifier plusieurs informations clés : comment nommer ce Deployment, combien de copies de notre application nous souhaitons (les réplicas), et à quoi ressemble l'application elle-même (quelle image de conteneur utiliser, quels ports exposer). Ce fichier deviendra la "source de vérité" pour notre application au sein du cluster.

Ce processus peut sembler intimidant au début, mais il suit une structure logique basée sur les quatre piliers que nous avons vus : `apiVersion`, `kind`, `metadata`, et `spec`. Nous allons construire un exemple simple pour illustrer comment ces éléments s'assemblent pour former un manifeste de Deployment fonctionnel.

Structure d'un manifeste de déploiement : exemple concret

Considérons l'objectif de déployer un serveur web Nginx standard, en s'assurant qu'il y a toujours deux instances (Pods) disponibles. Voici à quoi pourrait ressembler un manifeste YAML minimaliste pour réaliser cela :

# ./nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx # Ces labels doivent correspondre au selector
    spec:
      containers:
      - name: nginx
        image: nginx:1.25 # Utilise une version spécifique de Nginx
        ports:
        - containerPort: 80 # Port exposé par le conteneur Nginx

Décortiquons ce fichier. `apiVersion: apps/v1` spécifie que nous utilisons l'API stable du groupe `apps` pour les Deployments. `kind: Deployment` indique sans ambiguïté le type d'objet que nous créons. Ces deux champs sont essentiels pour que Kubernetes sache comment interpréter le reste du fichier.

La section `metadata` contient des informations d'identification. `name: nginx-deployment` donne un nom unique à notre objet Deployment au sein de son namespace. Les `labels` (ici, `app: nginx`) servent à organiser et potentiellement sélectionner ce Deployment plus tard, mais sont surtout cruciaux pour lier le Deployment aux Pods qu'il crée, comme nous allons le voir.

Vient ensuite la section `spec`, qui décrit l'état désiré. `replicas: 2` est notre instruction directe à Kubernetes : "Assure-toi qu'il y a toujours 2 Pods correspondant à ce déploiement". C'est l'une des fonctionnalités clés du Deployment : maintenir le nombre souhaité d'instances.

Le coeur du déploiement : sélecteur et modèle de pod

Deux sous-sections critiques à l'intérieur de `spec` sont `selector` et `template`. Le `selector` définit comment le Deployment identifie les Pods qu'il doit gérer. Ici, `matchLabels: { app: nginx }` indique que ce Deployment gérera tous les Pods qui possèdent le label `app` avec la valeur `nginx`.

La section `template` est la plus importante : elle décrit le modèle, le "plan" du Pod que le Deployment doit créer lorsqu'il a besoin de nouvelles instances (par exemple, au démarrage initial ou si un Pod existant disparaît). Ce template est lui-même une structure de Pod miniature, contenant ses propres `metadata` et `spec`.

Dans `template.metadata`, nous trouvons les `labels` qui seront appliqués aux Pods créés. Remarquez que `labels: { app: nginx }` correspond exactement au `selector.matchLabels` défini plus haut. C'est absolument crucial : le Deployment utilise son `selector` pour trouver les Pods dont les labels correspondent, et ces labels sont définis dans le `template`. Sans cette correspondance, le Deployment ne reconnaîtrait pas les Pods qu'il a créés.

Enfin, `template.spec` décrit le contenu effectif du Pod. C'est ici que nous définissons la liste des `containers`. Dans notre cas, un seul conteneur nommé `nginx`, utilisant l'image Docker `nginx:1.25` (il est recommandé d'utiliser une version spécifique plutôt que `latest` pour la reproductibilité) et exposant le `containerPort` 80, le port standard pour HTTP.

Finalisation et préparation pour l'application

Une fois que vous avez rédigé ce manifeste, en veillant à la bonne indentation (YAML y est sensible !) et à la logique (correspondance sélecteur/labels du template), vous devez l'enregistrer dans un fichier. Suivant notre commentaire en début d'exemple, nous pourrions l'enregistrer sous le nom `nginx-deployment.yaml`.

Ce fichier contient maintenant une description déclarative complète de notre souhait : un déploiement nommé `nginx-deployment` qui maintient 2 réplicas de Pods, chaque Pod exécutant un conteneur Nginx version 1.25 exposant le port 80, et les Pods étant identifiables par le label `app: nginx`.

Avec ce fichier en main, nous sommes prêts pour l'étape suivante de notre séquence de déploiement : utiliser la commande `kubectl apply` pour soumettre ce manifeste à l'API Kubernetes et lui demander de transformer cette description en ressources concrètes au sein du cluster. C'est ce que nous aborderons dans le sous-chapitre suivant.