Les conteneurs isolent une application et facilitent sa livraison, mais l’orchestration ajoute des règles de réseau, de stockage, de déploiement et de supervision. Le choix doit suivre l’équipe et les besoins d’exploitation.
Partir des contraintes
Listez le nombre de services, les horaires de charge, la persistance des données et les compétences disponibles. Une application avec un ou deux services peut fonctionner avec une plateforme managée simple. Plusieurs équipes, régions ou règles réseau peuvent justifier un orchestrateur plus complet.
Considérez les opérations quotidiennes : mises à jour, certificats, logs, sauvegardes et contrôle des accès. Le coût d’un système inclut le temps nécessaire pour l’administrer, pas seulement la facture des nœuds.
Séparer calcul et données
Les conteneurs sont adaptés au calcul sans état lorsque les données résident dans un service prévu pour la persistance. Une base ou un volume attaché demande des sauvegardes, des tests de reprise et une stratégie de déplacement. Ne traitez pas un volume temporaire comme une sauvegarde.
Les tâches planifiées et les workers doivent gérer une interruption. Vérifiez les doublons et l’arrêt propre avec les règles décrites dans notre guide sur les files d’attente.
Définir le déploiement
Chaque image doit avoir un tag immuable ou un digest. Le déploiement doit produire une version, vérifier la santé et conserver la version précédente. Un registre bien géré aide à retrouver l’image, comme expliqué dans l’article sur le registre de conteneurs.
Les sondes de santé doivent représenter les dépendances nécessaires. Une application qui répond alors que sa base est inaccessible peut recevoir du trafic et aggraver l’incident. Distinguez démarrage, disponibilité et capacité à recevoir une nouvelle requête.
Organiser les ressources
Définissez des limites et réservations réalistes. Une limite trop haute permet à un service de monopoliser le nœud ; une limite trop basse provoque des redémarrages. Observez la charge réelle avant d’ajuster les valeurs.
Utilisez des quotas par équipe ou environnement. Les règles réseau doivent limiter les communications et les secrets doivent être injectés par un mécanisme contrôlé. Les accès administrateur doivent être temporaires et journalisés.
Tester la panne
Arrêtez une instance de test et vérifiez la redistribution, le stockage, les logs et les alertes. Testez une image incorrecte, une dépendance lente et une hausse de trafic. Le runbook de reprise cloud doit citer les actions adaptées à votre plateforme.
Sources : Kubernetes, concepts, CNCF, cloud native landscape.