Les conteneurs de type “Docker” font dorénavant partie des infrastructures modernes, et de plus en plus d’applications sont livrées sous cette forme.
Mais Piloter “Docker” dans un Datacenter devient très rapidement “compliqué” : Est-ce que le conteneur est démarré ? sur quel serveur ? combien de répliques ? sont-ils bien “loadbalancé” ? etc….
Pour permettre l’orchestration automatisée de tous ces “conteneurs”, il y a “Kubernetes”. Il existe d’autres orchestrateurs tels que “Docker Swarm”, “Mesos”… Mais Kubernetes a réussi à s’imposer chez tous les plus gros fournisseurs de Cloud (AWS, Microsoft, Google…) et permettre ainsi la construction de “Cloud hybrides”.
Docker c’est quoi ?
Bien trop long à expliquer, mais tellement rapide à démarrer… Le lien WikiPedia qui vous entrainera vers de longues soirées de lecture.
Un orchestrateur de conteneurs pour Docker, c’est quoi ?
Un orchestrateur de conteneurs est une application située entre l’utilisateur et Docker, elle permet :
(source : https://www.silicon.fr/avis-expert/orchestration-des-conteneurs-quels-cas-dusage-et-quelles-solutions)
– Le provisionning et le placement des conteneurs : l’orchestrateur répartit et déploie les conteneurs sur les machines hôtes selon des besoins spécifiés en termes de mémoire et CPU.
– Le monitoring : une vue d’ensemble sur les métriques et les health-checks à la fois des conteneurs et des machines hôtes peut être portée par l’outil d’orchestration.
– La gestion du failover des conteneurs et la scalabilité : en cas d’indisponibilité d’une machine hôte par exemple, l’orchestrateur permet de redémarrer le conteneur sur une deuxième machine hôte. Cette scalabilité, en fonction de la solution d’orchestration utilisée, peut être manuelle ou automatique (autoscaling).
– La gestion des mises à jour et rollbacks des conteneurs : le principe du rolling update permet à l’orchestrateur d’assurer la mise à jour des conteneurs de manière successive et sans induire d’indisponibilité applicative. Pendant la phase de mise à jour d’un conteneur, les autres conteneurs disponibles sont exécutés. En cas de besoin, l’orchestrateur permet également d’effectuer un retour-arrière sur la version précédente.
– Le Service Discovery et la gestion du trafic réseau : les conteneurs étant volatiles, les informations réseaux de chaque conteneur (comme l’adresse IP) sont variables. L’orchestrateur offre un niveau d’abstraction permettant de regrouper un ou plusieurs conteneurs, de leur allouer une adresse IP fixe et de l’exposer à d’autres conteneurs.
Et Kubernetes c’est quoi ?
Kubernetes est un projet initié par Google (2014), puis rendu opensource et aujourd’hui maintenu par la Cloud Native Computing Foundation (CNCF). Cette application opère toutes les fonctionnalités d’un orchestrateur de conteneurs décrites ci-avant. Pour résumer, Kubernetes est chargée de géré le cycle de vie des conteneurs dans un Datacenter. Le projet avance très très vite, il est donc nécessaire de garder un oeil toujours ouvert sur cette technologie.
Proof Of Concept (POC) MytinyDC
Kubernetes, c’est compliqué, mais en prenant son temps, tout fini par fonctionner. Dans une configuration simple, un cluster Kubernetes est constitué d’un serveur de type “master”, et d’un ou plusieurs serveurs de type “worker”.
- Le “master” est chargé de superviser le cycle de vie des conteneurs,
- les “workers” sont chargés d’exécuter les applications du Datacenter livrées sous forme de conteneurs.
Le POC est relativement simple, installer un cluster Kubernetes sur des plateformes arm et amd64, deployer une application de test (genre nginx), vérifier la stabilité du cluster. Je commencerai ensuite l’implémentation de MytinyDC sur Kubernetes avec la réinstallation de Nextcloud, que je tenterai de mettre à l’echelle (scaling). Il s’agira d’un cas assez complet : serveur PHP-fpm, serveur de fichier NFS, Base de donnée Postgresql, serveur Apache2…
** Serveur physique ou Machine virtuelle
Dans ce contexte :
- monservice1 (associé au pod service 1) est “loadbalancé” sur le worker1 et le worker2
- monservice2 (associé au pod service 2) est “loadbalancé” sur le worker1 et le worker2
- monservice3 n’est pas équilibré - single point of failure