Ecriture du manifeste YAML pour un Déploiement (ex: image `httpd` ou `nginx` customisée)

Comprendre la structure d'un manifeste de Déploiement

Le manifeste YAML est le coeur de l'approche déclarative de Kubernetes. Pour un Déploiement, ce fichier décrit l'état souhaité de votre application : quelle image de conteneur utiliser, combien d'instances (Pods) doivent tourner simultanément, et comment identifier ces Pods. C'est un plan que Kubernetes utilisera pour créer, mettre à jour et gérer vos Pods de manière automatisée.

Un manifeste de Déploiement typique comporte quatre champs principaux au premier niveau : `apiVersion`, `kind`, `metadata`, et `spec`. `apiVersion` spécifie la version de l'API Kubernetes à utiliser pour cet objet (pour les Déploiements, c'est souvent `apps/v1`). `kind` indique le type d'objet que nous créons, ici `Deployment`. `metadata` contient les informations d'identification de l'objet, comme son `name` et des `labels` pour l'organisation.

Le champ le plus important est `spec` (spécification). C'est ici que vous définissez le comportement désiré du Déploiement. Il contient notamment le nombre de `replicas` (Pods identiques) souhaités, le `selector` qui permet au Déploiement de trouver les Pods qu'il doit gérer, et le `template` qui est le modèle utilisé pour créer chaque Pod.

Définir le template de Pod et les conteneurs

Au sein de `spec`, le champ `template` est essentiel car il décrit le Pod que le Déploiement va créer. Il possède sa propre section `metadata` où l'on définit les `labels` du Pod. Ces labels sont cruciaux : ils doivent correspondre aux `matchLabels` définis dans le `selector` du Déploiement pour que celui-ci puisse reconnaître et gérer les Pods qu'il crée.

Le `template` contient également une section `spec`, qui détaille la configuration du Pod lui-même. La partie la plus importante de cette section est le tableau `containers`. Chaque élément de ce tableau définit un conteneur qui tournera à l'intérieur du Pod (même si souvent, un Pod ne contient qu'un seul conteneur principal).

Pour chaque conteneur, vous devez spécifier au minimum un `name` (un nom logique pour le conteneur dans le Pod) et l'`image` (le nom de l'image Docker ou OCI à utiliser, par exemple `nginx:latest` ou `httpd:latest`). Vous pouvez également définir les `ports` que le conteneur expose, via `containerPort`. Ce port est celui sur lequel l'application écoute à l'intérieur du conteneur (par exemple, 80 pour un serveur web standard).

Exemple concret : un Déploiement Nginx simple

Mettons ces concepts en pratique avec un exemple simple. Nous allons créer un fichier YAML nommé `nginx-deployment.yaml` pour déployer un serveur web Nginx. Ce déploiement demandera deux réplicas.

Voici le contenu du fichier `nginx-deployment.yaml` :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Nom du déploiement
  labels:
    app: nginx # Label pour identifier ce déploiement
spec:
  replicas: 2 # Nombre de Pods souhaités
  selector:
    matchLabels:
      app: nginx # Doit correspondre aux labels du template de Pod
  template:
    metadata:
      labels:
        app: nginx # Label appliqué aux Pods créés
    spec:
      containers:
      - name: nginx-webserver # Nom du conteneur dans le Pod
        image: nginx:1.25 # Image Docker à utiliser (version spécifique)
        ports:
        - containerPort: 80 # Port exposé par le conteneur Nginx

Analysons ce fichier : nous créons un objet `Deployment` nommé `nginx-deployment`. Il est configuré pour maintenir `replicas: 2` Pods. Le `selector` recherche les Pods ayant le label `app: nginx`. Le `template` définit que chaque Pod aura ce même label `app: nginx` et contiendra un unique conteneur nommé `nginx-webserver`, basé sur l'image `nginx:1.25`, exposant le port `80`. Notez l'utilisation d'une version spécifique de l'image (`1.25`) plutôt que `latest`, ce qui est une bonne pratique pour la reproductibilité. Vous pourriez remplacer `nginx:1.25` par `httpd:latest` si vous préférez Apache, ou par le nom de votre propre image customisée si elle est disponible dans un registre accessible par votre cluster.

Ce fichier constitue la première étape de notre déploiement. Une fois ce fichier sauvegardé, nous pourrons l'appliquer à notre cluster Kubernetes. La prochaine étape consistera à créer un Service pour rendre ces Pods Nginx accessibles.