18 articles tagués avec « Orchestration »

Un snapshot de volume ne suffit pas à sauvegarder une base de données. Dans le cas traité ici, une application web stocke ses données dans MariaDB et ses fichiers joints sur un second volume, tous deux sur Longhorn avec des snapshots quotidiens. Restaurer le snapshot du volume de MariaDB revient à redémarrer la base après une coupure de courant : InnoDB sait le plus souvent rejouer son journal, mais rien ne garantit que l'état obtenu corresponde à un instant où l'application était cohérente, et le snapshot n'est lisible que par Longhorn. Un dump logique, produit par la base elle-même, donne une copie cohérente, portable et lisible. Cet article décrit un CronJob qui produit ce dump avec l'archive des fichiers joints, vérifie le résultat avant de le publier et gère sa propre rotation, sur le même principe que la sauvegarde des volumes Docker.

Un nœud Kubernetes équipé d'une carte NVIDIA n'expose rien de plus qu'un autre : le kubelet ne connaît que le CPU, la mémoire et le stockage éphémère, et un conteneur ne voit pas les périphériques /dev/nvidia* de l'hôte. Pour qu'un pod d'entraînement ou d'inférence obtienne une carte, plusieurs couches doivent coopérer : le pilote sur l'hôte, un runtime de conteneurs capable d'injecter le GPU, un composant qui annonce les cartes au scheduler, et des labels qui permettent de choisir entre des cartes différentes. Cet article décrit cette chaîne sur un cluster kubeadm hétérogène, ses pièges et la supervision des cartes.

Sur un cluster Kubernetes, chaque application exposée par l'ingress controller pose la même question d'authentification : certaines n'en ont aucune (tableau de bord, interface de supervision, outil interne), d'autres gèrent leurs propres comptes et ignorent ceux des autres. Un fournisseur d'identité unique, interrogé par Traefik en forward-auth pour les premières et en OpenID Connect par les secondes, ramène ces décisions à un seul annuaire. Authentik remplit ce rôle avec deux capacités absentes d'une configuration minimale : l'inscription en libre-service et les connexions par fournisseur externe (GitHub, LDAP, SAML). Son déploiement sur Kubernetes ajoute des pièges propres à Traefik en mode CRD : priorité des routers, références entre namespaces et route de callback de l'outpost.

Sur un cluster on-premise sans provisionneur dynamique, le stockage persistant repose souvent sur des PersistentVolumes local ou hostPath : un répertoire d'un nœud précis, déclaré à la main. Le pod qui consomme le volume est épinglé à ce nœud ; si celui-ci tombe, aucun pod ne peut être replanifié ailleurs, puisque les données n'existent nulle part ailleurs. Longhorn, projet de la CNCF, fournit à la place des volumes bloc répliqués de façon synchrone sur plusieurs nœuds, exposés à Kubernetes par un driver CSI.

Sur un hôte Docker, certains services consomment des ressources en permanence pour un usage de quelques minutes par semaine : une application JVM embarquant un moteur de conversion bureautique occupe environ 1 Go de RAM au repos, une application web accompagnée de sa base PostgreSQL et de son cache Redis mobilise trois conteneurs pour une consultation mensuelle. Dans l'écosystème Kubernetes, Knative ou KEDA traitent ce cas par le scale-to-zero ; avec Docker seul, aucun mécanisme natif n'arrête un conteneur inactif ni ne le redémarre à la requête suivante. Sablier comble ce manque : il arrête un groupe de conteneurs après une période sans trafic et le redémarre à la première requête entrante, en s'intégrant au reverse proxy.

Un hôte unique qui fait tourner une vingtaine de services Docker Compose, un dépôt Git qui contient un dossier par stack : la question du déploiement se pose dès la deuxième modification. Se connecter en SSH, faire un git pull, relancer docker compose up -d dans le bon dossier fonctionne, mais l'opération est manuelle, oubliable et non tracée. Cet article décrit un workflow GitHub Actions qui déploie, à chaque push sur la branche principale, uniquement les stacks modifiées, sans orchestrateur et sans agent installé sur l'hôte.

EKS (Elastic Kubernetes Service) est Kubernetes hébergé sur AWS. Le plan de contrôle (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) est géré par AWS dans un compte isolé, non accessible. Ce qui reste à la charge de l'utilisateur : les nœuds workers, le réseau, le stockage, et les intégrations IAM.

Mettre à jour une application en production sans interruption de service repose sur deux conditions : une stratégie de déploiement progressive qui maintient des pods sains pendant la transition, et des probes de santé correctement configurées pour que Kubernetes sache quand un pod est prêt à recevoir du trafic. À cela s'ajoutent les contraintes de ressources et de sécurité qui complètent une configuration production-ready.

Une application Kubernetes avec un seul réplica a une disponibilité structurellement limitée. Un crash de nœud, une maintenance planifiée ou une mise à jour du cluster suffit à provoquer une interruption totale. Trois mécanismes combinés permettent de construire une infrastructure résiliente : la réplication multi-nœud via TopologySpreadConstraints, la protection contre les disruptions planifiées via PodDisruptionBudget, et l'adaptation dynamique à la charge via HorizontalPodAutoscaler.

Docker Swarm (mode Swarm de Docker Engine) est le système d'orchestration intégré à Docker : il regroupe plusieurs hôtes Docker en un cluster et y maintient des services répliqués. Il ne demande aucun composant supplémentaire et réutilise le format Compose, au prix d'un périmètre fonctionnel plus restreint que celui de Kubernetes.