Le modèle déclaratif et l'API Kubernetes

Dire "quoi", pas "comment" : le paradigme déclaratif

L'une des caractéristiques les plus fondamentales et puissantes de Kubernetes est son approche déclarative de la gestion des ressources. Au lieu de fournir une série d'instructions séquentielles (approche impérative) pour atteindre un objectif, vous décrivez l'état final désiré de votre système dans un fichier manifeste, et vous laissez Kubernetes déterminer la meilleure façon d'y parvenir et de le maintenir.

Pensez à un thermostat : vous ne lui dites pas "chauffe pendant 5 minutes, puis arrête-toi, puis vérifie la température, puis réchauffe si besoin". Vous déclarez simplement : "Je veux que la température soit de 21°C". Le thermostat compare en permanence la température actuelle à votre état désiré et active ou désactive le chauffage pour atteindre et maintenir cet objectif. Kubernetes fonctionne de manière similaire pour vos applications et votre infrastructure.

Cette approche déclarative présente plusieurs avantages majeurs. Elle rend les configurations plus faciles à comprendre, à versionner (vos fichiers YAML peuvent être stockés dans Git) et à reproduire. Elle améliore la résilience : si un composant tombe en panne ou si l'état actuel dévie de l'état désiré pour une raison quelconque, les contrôleurs de Kubernetes détecteront l'écart et prendront automatiquement des mesures pour corriger la situation et revenir à l'état déclaré. Cela simplifie énormément l'automatisation et la gestion d'état des systèmes distribués complexes.

Ce travail continu de comparaison entre l'état désiré et l'état actuel, suivi des actions correctives nécessaires, est appelé la boucle de réconciliation. Elle est au coeur du fonctionnement des contrôleurs Kubernetes (comme le Deployment Controller, le ReplicaSet Controller, etc.) qui surveillent les objets API et agissent pour réaliser l'état spécifié dans leur champ `spec`.

L'API Kubernetes : la tour de contrôle universelle

Comment Kubernetes expose-t-il et gère-t-il tous ces états désirés et actuels ? Via son API (Application Programming Interface). L'API Kubernetes est le point central de toute interaction avec le cluster. C'est une interface RESTful basée sur HTTP, qui permet aux utilisateurs, aux administrateurs et aux composants internes du système de créer, lire, mettre à jour et supprimer des ressources Kubernetes.

Il est crucial de comprendre que dans Kubernetes, tout est une ressource API, ou un objet API. Un Pod, un Service, un Deployment, un Secret, un ConfigMap, un Noeud, un Namespace... toutes ces entités sont des objets définis et accessibles via l'API. Chaque objet représente une intention (l'état désiré) ou l'état observé du système.

Chaque objet API possède une structure bien définie, caractérisée par des champs communs :

• `apiVersion`: La version de l'API Kubernetes utilisée pour créer cet objet (ex: `v1`, `apps/v1`, `batch/v1`).
• `kind`: Le type de l'objet (ex: `Pod`, `Service`, `Deployment`).
• `metadata`: Contient les métadonnées de l'objet, comme son `name` (unique au sein d'un namespace pour un type donné), son `namespace` (sauf pour les objets globaux), ses `labels` et ses `annotations`.
• `spec` (spécification): C'est ici que vous décrivez l'état désiré de l'objet. Par exemple, pour un Deployment, la `spec` contiendra le nombre de réplicas souhaités, le template du Pod à utiliser, la stratégie de mise à jour, etc. Ce champ est défini par l'utilisateur.
• `status`: Ce champ décrit l'état actuel de l'objet, tel qu'observé et rapporté par le système Kubernetes (ses contrôleurs). Par exemple, pour un Deployment, le `status` indiquera le nombre de réplicas actuellement disponibles, prêts, etc. Ce champ est géré par Kubernetes lui-même et est en lecture seule pour l'utilisateur.

L'outil `kubectl` que nous avons appris à utiliser n'est fondamentalement qu'un client HTTP qui traduit vos commandes en requêtes REST envoyées à l'API Server.

Interaction : modèle déclaratif et API en action

Le modèle déclaratif et l'API fonctionnent en parfaite synergie. Lorsque vous écrivez un fichier YAML décrivant, par exemple, un Deployment, vous définissez les champs `apiVersion`, `kind`, `metadata` et surtout la `spec` (votre état désiré).

Ensuite, vous utilisez une commande comme `kubectl apply -f mon-deployment.yaml`. Que se passe-t-il ?

1. `kubectl` lit le fichier YAML.
2. Il contacte l'API Server (authentification, autorisation).
3. Il envoie une requête HTTP (souvent un PUT ou un PATCH) à l'endpoint de l'API correspondant (`/apis/apps/v1/namespaces/default/deployments/mon-nom` par exemple) avec le contenu du YAML comme corps de la requête.
4. L'API Server valide la requête, vérifie les permissions, applique les éventuels contrôles d'admission, puis persiste l'objet (ou la mise à jour) dans la base de données `etcd`.
5. Les contrôleurs pertinents (ici, le Deployment Controller et le ReplicaSet Controller) qui surveillent constamment l'API Server sont notifiés du changement (création ou mise à jour de l'objet Deployment).
6. Les contrôleurs comparent alors la `spec` (état désiré) avec le `status` (état actuel) et effectuent les actions nécessaires (créer/supprimer des Pods via l'API Server) pour atteindre l'état désiré.
7. Les contrôleurs mettent à jour le champ `status` de l'objet via l'API Server pour refléter le nouvel état actuel.

Ce flux illustre comment l'approche déclarative, exprimée via des manifestes, est mise en oeuvre grâce à l'API centralisée et aux boucles de réconciliation des contrôleurs. Comprendre ce mécanisme est fondamental pour utiliser Kubernetes efficacement. La prochaine étape est d'apprendre à écrire ces fameux fichiers manifestes YAML pour décrire les objets de base.