Associés aux nouvelles applications les containers s’imposent dans les entreprises et l’orchestrateur de containers Kubernetes revêt un rôle de plus en plus stratégique. Pourquoi ce type de virtualisation est-il plébiscité et comment va-t-il cohabiter avec les machines virtuelles (VM) et les micro VM sans pour autant complexifier la tâche des équipes informatiques ? Autant de questions que j’ai posées à Alexandre Caussignac.
Thu Trang Nguyen. L’utilisation des VM et des containers correspond-elle à des époques et des contextes différents ?
Alexandre Caussignac. La généralisation des machines virtuelles (virtualisation de type 1) a eu lieu au début des années 2000. A l’époque les applications étaient monolithiques et les serveurs X86 souvent utilisés à moins de 20% de leur capacité. En découplant le matériel du logiciel les machines virtuelles ont amélioré l’efficacité des serveurs et ouvert la voie aux infrastructures définies par logicielles (Software Defined). La virtualisation a été étendue au stockage et au réseau et une majorité d’entreprises utilise ce socle d’infrastructures virtualisées pour bâtir leur cloud privé. L’adoption de la virtualisation est telle qu’aujourd’hui de nombreux fournisseurs de cloud public ont noué des partenariats avec VMware pour étendre la virtualisation de manière homogène dans un cloud hybride. Le container (virtualisation de type 2) est apparu en entreprise en 2013 dans un contexte applicatif bien différent.
L’arrivée des containers est donc liée à la modernisation des applications ?
La révolution numérique est passée par là. Les entreprises devaient produire et mettre en service très rapidement beaucoup plus d’applications et pouvoir continuellement les enrichir en fonctionnalités sans perturber l’utilisateur. On a ainsi vu apparaitre des notions d’intégration continue et de développement continu (CI/CD) associées à des méthodes DevOps. Pour donner plus d’agilité au développement, les nouvelles applications (souvent appelées cloud natives) sont conçues sur des architectures de microservices qui décomposent l’application en éléments autonomes et indépendants. Ces micro-services et les architectures distribuées avaient besoin d’une virtualisation adaptée à leurs caractéristiques : le container.
Pourquoi le container se prête il bien aux microservices ?
Une VM est l’équivalent d’un serveur logique. Elle contient le système d’exploitation et l’ensemble des couches applicatives. Cela convenait parfaitement à des applications monolithiques qui constituent encore l’essentiel du patrimoine applicatif des entreprises. Par contre avec les nouvelles applications distribuées cela revenait à créer autant de VMs que de microservices et donc à multiplier les systèmes d’exploitation.
Les conteneurs sont plus simples et plus légers que les machines virtuelles. Ils partagent le noyau de l’OS hôte et évitent ainsi la redondance des OS invités et les démarrages associés. Chaque container est dédié à une tâche (un processus) et n’embarque que ce qui lui est nécessaire pour fonctionner (les environnements d’exécution de code autonomes). Ils sont donc parfaitement adaptés aux applications nécessitant de la portabilité et de la scalabilité.
Machines Virtuelles et containers peuvent-ils collaborer ?
Les containers ont été vus tout d’abord comme une alternative aux VMs car on pouvait mettre six à huit fois plus de conteneurs que de machines virtuelles sur un serveur bare-metal. Avec le recul et l’expérience on s’est aperçu que l’association containers et machines virtuelles se révèle particulièrement bénéfique.
- Sécurité et portabilité ne sont plus antinomiques grâce à l’isolation éprouvée des VM. En regroupant plusieurs containers au sein d’une VM on limite la propagation du risque à celle-ci. Il n’est plus utile d’avoir recours à l’OS pour assurer la sécurité et on supprime ainsi toute adhérence qui nuirait à la portabilité.
- Efficacité et agilité renforcées. On peut s’affranchir de la limite recommandée de 100 containers par « container host » (porte containers) en découpant un serveur physique en unités logiques (des VM) pouvant chacune héberger jusqu’à 100 containers. On augmente la densité possible de containers et on offre une plus forte agilité utile pour le cloud.
- Segmentation plus fine par cluster Kubernetes Le recours aux VM évite les gros clusters avec un modèle multi tenant reposant sur une seule et même API de contrôle
- Performances améliorées pour les serveurs distribués car l’hyperviseur tire un meilleur parti des architectures distribuées NUMA que les OS du marché. Un test comparatif a d’ailleurs été effectué sur des applications Web.
Quel est le rôle des micro VMs vis-à-vis des containers ?
Avec les micro VMs, un nouveau modèle se dessine bénéficiant de l’isolation intrinsèque des machines virtuelles et de la portabilité et de la scalabilité des containers. De grands acteurs tels qu’Amazon Web Services et Google se basent déjà sur ces micro VMs pour mettre à disposition une bonne partie de leurs services managés (AWS Lambda, …). L’objectif est de réduire la machine virtuelle à la taille d’un container. Au sein d’une micro VM, un container ne sera plus contraint de partager l’OS. Cela permet de sécuriser et d’isoler le container avec une empreinte minime, portable et scalable.
Les containers ont simplifié la vie des développeurs mais n’ont-ils pas compliqué celles des opérateurs ?
C‘est la raison pour laquelle Kubernetes rencontre un tel succès car l’orchestration est plus que jamais nécessaire pour le monde de l’infrastructure. Mais la bataille stratégique ne repose plus réellement sur les runtimes de haut niveau (API), qui sont devenus une commodité dans la philosophie de Kubernetes via les interfaces (CRI, CNI, CSI), mais plutôt sur les runtimes de bas niveau (binaire que va exécuter le container). Et c’est là qu’entre en scène des approches comme les micro VM qui assurent isolation et portabilité.
Comment simplifier la gestion de toutes ces formes de virtualisation ?
Les entreprises ont des approches très pragmatiques et on trouvera chez la majorité d’entre elles une combinaison de VM, de containers et de micro VM avec le risque de créer de nouveaux Silo. VMware a pris la mesure de l’enjeu et a annoncé en aout 2019 le projet Pacific. VMware a ré–architecturé vSphere pour intégrer Kubernetes et offrir aux entreprises une unique plateforme pour gérer les applications existantes (monolithiques) et de nouvelles applications (à base de micro services). VM, containers et micro VM (standards ou éphémères) peuvent coexister directement sur l’hyperviseur et être gérés comme un tout cohérent (namespace VM/Container). Les équipes informatiques disposeront d’une vision unifiée des clusters, containers et VM fonctionnant sur VMware vCenter Server for Kubernetes.
Retrouvez + de points de vue : https://blogs.vmware.com/emea/fr/
