Introduction aux fichiers manifestes YAML

YAML : le langage de la déclaration Kubernetes

Nous avons établi que Kubernetes fonctionne sur un modèle déclaratif, où vous décrivez l'état désiré de vos ressources via son API. Mais comment fournir cette description de manière structurée et lisible par l'homme et la machine ? La réponse la plus courante dans l'écosystème Kubernetes est : YAML (acronyme récursif pour "YAML Ain't Markup Language").

Les fichiers manifestes Kubernetes sont des fichiers texte, le plus souvent avec l'extension `.yaml` ou `.yml`, qui contiennent la définition d'un ou plusieurs objets API Kubernetes. Ils servent de plans ou de modèles que vous soumettez à l'API Server via `kubectl` pour créer, mettre à jour ou supprimer des ressources dans votre cluster.

Pourquoi YAML ? Il a été choisi pour sa lisibilité humaine (comparé à JSON ou XML, par exemple), sa capacité à représenter des structures de données complexes (listes, dictionnaires imbriqués) de manière assez concise, et sa facilité de traitement par les logiciels. Il est devenu le standard de facto pour la configuration dans de nombreux outils Cloud Native et DevOps.

Syntaxe de base de YAML pour Kubernetes

Bien que YAML ait des fonctionnalités avancées, la syntaxe utilisée dans les manifestes Kubernetes est généralement assez simple et repose sur quelques concepts clés :

• Paires Clé-Valeur : La structure de base est `clé: valeur`. La clé est un nom, et la valeur peut être une chaîne de caractères, un nombre, un booléen (`true`/`false`), ou une structure plus complexe (liste ou dictionnaire). Notez l'espace obligatoire après les deux-points (`:`).

  nom: mon-application
  replicas: 3
  port: 8080

• Indentation : L'indentation est cruciale en YAML car elle définit la structure et l'imbrication. Utilisez des espaces (pas de tabulations !) et soyez cohérent (généralement 2 espaces par niveau d'indentation). Les éléments au même niveau d'indentation appartiennent à la même structure parent.

  metadata:
    name: mon-pod
    labels:
      app: backend

  Ici, `name` et `labels` sont des clés sous `metadata`. `app` est une clé sous `labels`.
• Listes (Séquences) : Les éléments d'une liste commencent par un tiret (`-`) suivi d'un espace. Tous les éléments de la liste doivent avoir la même indentation.

  args:
    - "--param1=valeur1"
    - "--param2=valeur2"
  
  ports:
  - containerPort: 80
    protocol: TCP
  - containerPort: 443
    protocol: TCP

  Ici, `args` est une liste de chaînes, et `ports` est une liste de dictionnaires.
• Dictionnaires (Mappings) : Ce sont des ensembles de paires clé-valeur, comme vu dans les exemples précédents (`metadata`, `labels`).
• Chaînes de caractères multilignes : Utilisez `|` pour préserver les retours à la ligne, ou `>` pour les remplacer par des espaces (sauf pour les lignes vides).

  script: |
    echo "Ligne 1"
    echo "Ligne 2"
  
  description: >
    Ceci est une description
    qui s'étend sur plusieurs
    lignes.

• Commentaires : Tout ce qui suit un croisillon (`#`) sur une ligne est ignoré.

  # Ceci est un commentaire
  replicas: 3 # Nombre de réplicas souhaité

• Séparation de documents : Vous pouvez inclure plusieurs définitions d'objets Kubernetes dans un seul fichier YAML en les séparant par trois tirets (`---`).

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: mon-configmap
  ---
  apiVersion: v1
  kind: Pod
  metadata:
    name: mon-pod
  ...

Attention : La principale source d'erreurs en YAML est l'indentation incorrecte. Utilisez un éditeur de texte avec un bon support YAML qui peut vous aider à la visualiser et à la valider.

Structure typique d'un manifeste Kubernetes

Comme mentionné précédemment, chaque objet API Kubernetes défini dans un manifeste YAML doit comporter au minimum les champs suivants au niveau supérieur :

• `apiVersion` : Indique la version de l'API à utiliser pour cet objet. Par exemple, `v1` pour les objets principaux comme Pods, Services, Namespaces ; `apps/v1` pour les Deployments, StatefulSets, DaemonSets ; `batch/v1` pour les Jobs, etc. La documentation Kubernetes spécifie l'apiVersion correcte pour chaque `kind`.
• `kind` : Le type d'objet que vous définissez (ex: `Pod`, `Service`, `Deployment`, `Namespace`, `ConfigMap`, `Secret`). Sensible à la casse.
• `metadata` : Un dictionnaire contenant les métadonnées de l'objet. Le champ `name` sous `metadata` est presque toujours requis et doit être unique pour ce `kind` au sein d'un `namespace`. D'autres champs courants sous `metadata` sont `namespace`, `labels` et `annotations`.

En plus de ces champs obligatoires, la plupart des objets auront également :

• `spec` : C'est là que vous définissez l'état désiré pour l'objet. La structure de `spec` varie énormément en fonction du `kind` de l'objet. C'est la partie la plus importante à définir pour l'utilisateur.

Voici un squelette très simple pour un objet Pod :

apiVersion: v1       # Version de l'API pour les Pods
kind: Pod           # Type d'objet
metadata:
  name: mon-premier-pod # Nom du Pod
  labels:           # Etiquettes (optionnel mais recommandé)
    app: webserver
spec:               # Spécification de l'état désiré
  containers:       # Liste des conteneurs dans ce Pod\  - name: nginx-container # Nom du conteneur
    image: nginx:latest  # Image Docker à utiliser
    ports:
    - containerPort: 80 # Port exposé par le conteneur

Utilisation des manifestes avec kubectl

Une fois que vous avez écrit votre fichier manifeste (par exemple, `mon-objet.yaml`), vous utilisez `kubectl` pour l'appliquer au cluster :

• `kubectl apply -f mon-objet.yaml` : C'est la commande recommandée. Elle crée l'objet s'il n'existe pas, ou le met à jour s'il existe déjà, en appliquant uniquement les changements nécessaires. C'est l'incarnation de l'approche déclarative.
• `kubectl create -f mon-objet.yaml` : Crée l'objet, mais échouera s'il existe déjà. Moins flexible que `apply`.
• `kubectl replace -f mon-objet.yaml` : Remplace l'objet existant par la nouvelle définition. Peut être destructeur si des champs importants sont modifiés.
• `kubectl delete -f mon-objet.yaml` : Supprime l'objet défini dans le fichier.

L'utilisation de `kubectl apply` avec des fichiers manifestes stockés dans un système de contrôle de version comme Git est la base de nombreuses pratiques DevOps et GitOps pour gérer l'infrastructure et les applications Kubernetes de manière fiable et reproductible.

Maîtriser la lecture et l'écriture de manifestes YAML est une compétence essentielle. Au fur et à mesure que nous explorerons différents objets Kubernetes dans les prochains chapitres, nous nous familiariserons de plus en plus avec les structures YAML spécifiques à chacun.