12 articles tagués avec « Orchestration »

EKS 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.

EKS Auto Mode, disponible depuis fin 2024, étend ce périmètre géré. En plus du control plane, AWS prend en charge le provisionnement des nœuds (via Karpenter intégré), le driver de stockage EBS, et le contrôleur de load balancing. Pour quelqu'un qui vient de kubeadm on-premise, c'est l'équivalent d'avoir Karpenter, le EBS CSI Driver et le AWS Load Balancer Controller préconfigurés et maintenus par AWS.

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 une seule 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 est le système d'orchestration natif de Docker qui permet de gérer un cluster de conteneurs de manière simple et intégrée. Contrairement à Kubernetes, Swarm est plus léger et plus facile à configurer, le rendant idéal pour les petits à moyens déploiements.

Kubectl est l'outil en ligne de commande officiel pour interagir avec les clusters Kubernetes. Il couvre l'intégralité des opérations courantes : déploiement, débogage, inspection, mise à l'échelle.

Par défaut, les certificats générés par kubeadm ont une durée de validité d'un an. À l'expiration, les composants du cluster ne peuvent plus s'authentifier entre eux — le cluster devient inaccessible. Le renouvellement est une opération de maintenance prévisible, à planifier avant l'expiration plutôt qu'en urgence.

Kubernetes expose une API déclarative : on décrit l'état souhaité via des ressources YAML, et le cluster converge vers cet état. Quatre ressources couvrent la majorité des besoins : Pod, Deployment, StatefulSet, Service. Comprendre pourquoi chacune existe — et pas seulement comment l'écrire — évite les mauvais choix d'architecture.

Gérer des conteneurs sur une seule machine est simple. Gérer des centaines de conteneurs répartis sur des dizaines de machines, avec des contraintes de disponibilité, de mise à l'échelle et de mise à jour sans interruption, est un problème fondamentalement différent. Kubernetes est la réponse à ce problème : un système d'orchestration qui prend en charge le placement, le redémarrage, la mise à l'échelle et la communication des conteneurs à l'échelle d'un cluster.

Une image Docker doit être identique entre les environnements — dev, staging, prod. Ce qui change entre environnements, c'est la configuration : URL de base de données, niveau de log, clés API. Kubernetes fournit deux ressources pour externaliser cette configuration : ConfigMap pour les données non sensibles, Secret pour les credentials.

Les pods sont éphémères. Quand un pod est supprimé ou recréé, son système de fichiers disparaît avec lui. Pour les workloads qui ont besoin de conserver des données — bases de données, systèmes de fichiers partagés, queues persistantes — Kubernetes fournit un système de stockage découplé du cycle de vie des pods.