Des containers physiques ou virtuels ?

Se poser la question d’exécuter des containers directement sur des serveurs physiques dit “Bare Metal” versus sur des serveurs virtuels dit des VMs est légitime, surtout lorsqu’on utilise un orchestrateur de container comme Kubernetes. Pour chaque nouvelle architecture applicative on me pose la question : est-il nécessaire de mettre en place une architecture virtuelle pour ces types d’application ou pour d’autres : SAP HANA, HADOOP, MONGO DB, CASSANDRA, …. et donc aussi Kubernetes ? L’élément déclencheur de cette réflexion est de vouloir faire l’économie du coût de l’hyperviseur. Mais ce dernier à beaucoup d’avantages opérationnel, sécuritaire, d’extensibilité et de souplesse.  Si vous êtes déjà convaincu par la nécessité de s’appuyer sur une architecture de virtualisation et vous pensez partir sur un hyperviseur dit gratuit, je vous invite à lire cet article : “C’est gratuit ! ?”.

Les containers vont s’exécuter sur un porte containers. Un porte container est un système d’exploitation en général Linux sur lequel vont s’exécuter les container. Sur du Bare Metal, on va maximiser le nombre d’exécution de containers alors que dans une VM on va à l’inverse plutôt minimiser le nombre d’exécution de containers voire 1 container par VM. Pour que ce soit efficace ou pertinent, il ne faut pas partir sur des VMs classiques mais sur des micros VMs sur lesquels est installé un systèmes d’exploitation épuré de services inutiles, durci (sécurité renforcée) et optimisé pour les containers de sortes à ce qu’ils consomment très peu de ressources et démarrent en quelques millisecondes.

Tout système d’exploitation a ses contraintes, ses limites et ses faiblesses :

• Sur un système d’exploitation, le nombre de container est limité (Exemple pour Kubernetes : https://kubernetes.io/docs/setup/best-practices/cluster-large/), la règle est la même pour un porte container basé sur une machine virtuelle. Par contre, un serveur de virtualisation hébergera plusieurs VMs soit autant de porte container à hauteur des ressources physiques disponibles soit : Max Container par OS x Nombre de VM porte containers par serveur de virtualisation.
• En Bare Metal, le porte containers est en contact directe avec le matériel. Les composants physiques du serveur doivent être compatibles avec le système d’exploitation et ses drivers. La virtualisation elle, fait abstraction et le porte container n’a plus à se soucier de la compatibilité du matériel et des drivers associés, vous pouvez changer de fournisseurs de serveurs et des composants.
• Le système d’exploitation du porte container doit être maintenu à jour et les opérations de maintenance auront un impact sur tous les containers qui y sont hébergés. Avec une approche VM, l’impact sera limité car comme expliqué juste avant, on privilégie peu de container par VM porte container voire même 1 container par VM.
• Le porte container est dédié à un usage : dev, prod, pré-prod, …, donc si toutes les ressources ne sont pas utilisées pour cet usage, il y aura beaucoup de perte (€€€). Avec la virtualisation, les serveurs physiques peuvent héberger des VMs porte containers de différents usages et la consommation des ressources sont ainsi optimales.
• En Bare Metal, le porte container exécutera un seul système d’exploitation. Avec une infrastructure virtualisée, un serveur physique peut héberger des porte containers, Windows et différents types de Linux.
• Les solutions d’orchestration comme Kubernetes orchestre des containers mais pas le provisionnement de porte containers. L’orchestrateur utilise les ressources physiques qu’il a à sa disposition à un instant T et s’il en manque, il faut rajouter un serveur, mais ce n’est pas lui qui va le faire, il va s’appuyer sur un IaaS (Infrastructure As A Service). En environnement virtualisé le déploiement de porte containers consiste au déploiement de VMs. Les IaaS basés sur des VMs sont beaucoup plus commun que ceux basés sur des serveurs physiques.
• Quid des performances ? Et bien là aussi un bon hyperviseur permet de gagner en performance, vSphere tire mieux parti des architecture NUMA que les systèmes d’exploitation du marché et permet ainsi d’avoir un gain de performance. Un test comparatif a été effectué par VMware sur des applications Web : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/docker-vsphere65-weathervane-perf.pdf
• L’isolation des containers entres eux, même si elle fonctionne correctement, elle peut avoir un gros impact sur tous les containers en cas de faille de sécurité. La virtualisation offre en plus, une isolation inter VMs donc inter porte containers beaucoup plus robuste et plus vous limitez le nombre de containers par VM plus la sécurité sera renforcée.
• Ne vous inquiétez pas sur la consommation des ressources par un porte container VM. Si un OS classique consomme des ressources et met du temps à démarrer, un OS optimisés pour l’hébergement des containers (Micro OS comme Photon OS), consomment peut de ressources et démarre en quelques millisecondes. De plus un bon hyperviseur à des optimisations de consommation de ressources lorsque des OS identiques sont exécutés en même temps.
• Un container doit pouvoir démarrer sur n’importe quel porte container d’un cluster (regroupement des ressources de plusieurs serveurs), s’il a besoin de persistance des données, il doit pouvoir y a accéder depuis n’importe où et pour cela, il faut un système de fichiers partagé en général un export NFS externe qu’il faut maintenir. La virtualisation propose un système de fichier partagé natif qui est complètement intégré. Sur vSphere ce système de fichiers peut s’appuyer sur pratiquement n’importe quelle baie de stockage du marché. L’utilisation de la solution hyper convergée vSAN offre néanmoins beaucoup plus d’avantages qui sont détaillés dans cet article : Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

J’ai apporté une liste non exhaustive des avantages à utiliser la virtualisation pour des containers, si vous avez encore des doutes, je vous invite à vérifier sur quel type d’architecture s’exécute les offres de containers as a service proposées par les grands acteurs du Cloud Publics. D’ailleurs RedHat et VMware ont annoncé lors du Red Hat Summit de mai 2019 une architecture de référence pour la solution Red Hat OpenShift basée sur le SDDC VMware : https://octo.vmware.com/vmware-red-hat-bring-red-hat-openshift-vmware-sddc/.

Les offres autour de Kubernetes ne cessent d’évoluer, VMware vient d’annoncer à VMworld 2019 le Projet Pacific, une nouvelle évolution de l’hyperviseur vSphere qui intégra nativement l’orchestrateur Kubernetes et les portes containers, ca fera l’objet d’un nouvel article 🤔😉.