Comment Kubernetes et virtualisation se différencient et se complètent
Vus de l’extérieur, containers et machines virtuelles semblent servir le même besoin : exécuter des applications sans tenir compte des limites de l’infrastructure sous-jacente. Vu de l’intérieur, choisir une plateforme ou l’autre est d’abord une question d’infrastructure.
Kubernetes est-il un hyperviseur ? Tout administrateur d’hyperviseur ou de Kubernetes répondra : bien sûr que non ! L’un n’a rien à voir avec l’autre. Mais lorsque votre activité quotidienne consiste juste à exécuter des applications indépendamment du matériel sous-jacent, la question n’est finalement pas si dénuée de sens.
La véritable question est plutôt de savoir dans quel cas il est pertinent d’utiliser l’un ou l’autre. Il y a d’autant moins de réponses universelles que, dans certains cas, il est pertinent d’utiliser des containers Kubernetes depuis des machines virtuelles Linux.
Similitudes et différences entre Kubernetes et un hyperviseur
Certaines similitudes pourraient vous faire penser que Kubernetes est un hyperviseur. Avec Kubernetes, vous exécutez des containers – qui contiennent des applications – depuis une plateforme logicielle. Cette plateforme décide de déployer ces applications sur tels ou tels serveurs, selon l’activité.
Avec un hyperviseur, on procède de la même manière pour exécuter des machines virtuelles – qui contiennent aussi des applications – sur plusieurs serveurs. Celles-ci sont également placées en fonction de la charge de travail, dynamiquement.
À ce stade, il convient de préciser que Kubernetes n’exécute pas lui-même les charges de travail. C’est le moteur de containers, Docker le plus souvent, qui le fait. Kubernetes place les containers sur les bons serveurs, où le moteur de containers les exécute.
Plutôt que de se demander si Kubernetes est un hyperviseur, la question serait plutôt de savoir si les moteurs de containers sont des hyperviseurs. Dans les faits, la plupart des gens font la confusion entre les deux.
Avec un hyperviseur, chaque machine virtuelle possède ses propres caractéristiques matérielles (mais virtuelles) et son propre système d’exploitation pour les piloter. Par exemple, dans une machine virtuelle, il y a nécessairement un OS qui possède un pilote pour le stockage et un pilote pour le réseau. Ce stockage et ce réseau sont des ressources virtuelles présentées par l’hyperviseur à partir de ressources physiques.
On notera cependant que les containers ont été conçus dans l’idée d’exécuter des applications « pour le cloud », ou « cloud native ». Afin d’assurer leur portabilité du data center à un cloud public et d’un cloud public à un autre cloud public, ces applications ne devraient jamais accéder directement au système de fichiers de l’OS hôte ni aux adresses IP de son réseau local. Elles devraient à la place envoyer des requêtes HTTP vers des hôtes – domaines applicatifs, systèmes de stockage objet – renseignés dans le DNS. Pour autant, cette pratique est contournée, car il est intéressant d’exécuter au format container des applications prévues pour des serveurs physiques ou des machines virtuelles.
Faut-il lancer des containers par-dessus des machines virtuelles ?
Les entreprises se posent ensuite la question de lancer leurs containers directement depuis des serveurs physiques, ou depuis des machines virtuelles exécutées par des serveurs physiques. Dans tous les cas, il faut un système d’exploitation et un moteur de container par machine physique ou virtuelle.
La réponse dépend de facteurs tels que l’élasticité, les coûts, les ressources et les besoins de performance.
Déployer des applications avec Kubernetes sur des serveurs physiques, également appelés serveurs bare-metal, permet d’éviter le goulet d’étranglement de l’hyperviseur. Dans un tel déploiement bare-metal, toutes les ressources matérielles sont consacrées uniquement aux applications containerisées. Chaque cycle du processeur est affecté aux applications métiers. En outre, les paquets réseau et les lectures et écritures de stockage sont traités directement, sans intervention de l’hyperviseur.
Pour autant, les progrès réalisés en matière d’optimisation des VMs ont permis de réduire considérablement la charge de calcul que représente un hyperviseur. Au point qu’une entreprise pourrait considérer que les fonctions de haut niveau qu’apportent les plateformes virtualisées l’emportent sur le faible gain en puissance de calcul que l’on obtient sans virtualisation.
VMware, par exemple, affirme que son système de virtualisation vSphere 7 peut offrir des performances supérieures de 8 % à celles d’un serveur bare-metal, lors de l’exécution de charges de travail Kubernetes. Le planificateur de puissance CPU de l’hyperviseur ESXi de VMware optimiserait ainsi les accès à la mémoire des pods (ensembles de containers similaires) en regroupant en RAM les similitudes, ce que ne saurait pas faire Linux.
L’exécution de Kubernetes dans des VM permet également aux équipes informatiques de choisir plusieurs tailles de serveurs pour différents types de déploiement. Dans un déploiement bare-metal, l’ensemble des ressources du serveur est offert aux containers. Il est plus compliqué de limiter les ressources pour les containers. Alors que cela est facile pour les VMs. Le contrôle précis des ressources par Kubernetes se fait au niveau du pod.
Déploiement et facilité de gestion
La facilité de déploiement est un argument clairement en faveur des VMs. Même si les plateformes de virtualisation nécessitent un travail supplémentaire pour installer à la fois un hyperviseur et des VMs sur le matériel, les hyperviseurs demandent ensuite moins de manipulations sur l’infrastructure pour déployer des applications. De plus, les mises à jour de l’hyperviseur sous-jacent sont moins fréquentes que celles du système d’exploitation d’un serveur bare-metal.
Une fois les hyperviseurs en place, les déploiements de VMs sont indépendants du matériel. Lorsque du matériel est ajouté, toutes les VM restent intactes et peuvent être déplacées facilement entre les hyperviseurs. Cela simplifie la gestion de la plateforme et élimine les temps d’arrêt pendant les opérations de maintenance de l’infrastructure.
Moyennant un coût supplémentaire chez VMware, il est possible de souscrire à l’offre Tanzu, qui confie les fonctions de moteur de containers à ESXi lui-même. Ce qui simplifie encore les configurations. Les VMs qui font office de nœuds pour un cluster Kubernetes correspondent ici à un modèle avec un Linux préinstallé.
Figure 1. La page du client vSphere.
Une fois les hyperviseurs en place, les déploiements de VMs sont indépendants du matériel. Lorsque du matériel est ajouté, toutes les VM restent intactes et peuvent être déplacées facilement entre les hyperviseurs. Cela simplifie la gestion de la plateforme et élimine les temps d’arrêt pendant les opérations de maintenance de l’infrastructure.
Moyennant un coût supplémentaire chez VMware, il est possible de souscrire à l’offre Tanzu, qui confie les fonctions de moteur de containers à ESXi lui-même. Ce qui simplifie encore les configurations. Les VMs qui font office de nœuds pour un cluster Kubernetes correspondent ici à un modèle avec un Linux préinstallé.
Il est intéressant d’exécuter au format container des applications prévues pour des serveurs physiques ou des machines virtuelles.
Les containers, quant à eux, fonctionnent tous au-dessus du même système d’exploitation, celui à partir duquel est exécuté le moteur de containers. Ce système d’exploitation gère le matériel, la mise en réseau, voire l’accès au stockage. Les containers sont donc beaucoup plus légers en mémoire que des machines virtuelles, puisqu’ils ne contiennent que l’application. Mais du point de vue de l’application, il n’y a pas de différence : elle communique avec un système d’exploitation et peut accéder à son stockage, comme à son réseau.
Toutefois, un tel déploiement n’apporte pas exactement un cluster Kubernetes entièrement conforme. Certaines fonctionnalités – les ressources réseau/stockage personnalisées, les modules tiers – ne peuvent pas être mises en œuvre sur la plateforme. Néanmoins, vSphere avec VMware Tanzu permet de mettre en production des clusters Kubernetes génériques à l’intérieur de VMs qui sont de simples machines Linux. Et cette construction simplifie radicalement l’évolutivité de l’infrastructure.
Un autre avantage du déploiement de Kubernetes par des VMs est que les administrateurs qui gèrent l’hyperviseur peuvent se familiariser avec la nouvelle plateforme au fil du temps, plutôt que de se lancer dès le premier jour dans un déploiement entièrement nouveau de type bare-metal.
Haute disponibilité et élasticité
Les hyperviseurs protègent les VM et peuvent être redémarrés rapidement et automatiquement sur un autre hôte en cas de panne. Mais les équipes informatiques doivent être prudentes lorsqu’elles placent plusieurs VMs sur le même hyperviseur. En cas de défaillance de cette machine, les conséquences sont beaucoup plus graves qu’en cas de perte d’un seul hôte bare-metal, car davantage de charges de travail sont perdues. Cette limitation peut généralement être surmontée avec des règles qui répartissent les VMs sur différents serveurs.
Pour garantir davantage la haute disponibilité, il convient de configurer la gestion des défaillances à la fois dans les couches Kubernetes et VMs. En cas de panne, une seule plateforme à la fois doit tenter de remettre les charges de travail en état de marche.
Concernant l’élasticité, Kubernetes semble le mieux pourvu puisqu’il est né chez Google, qui gère des centres de données à grande échelle. La plupart des entreprises ne chapeautent pas des déploiements aussi grands que Google. Mais lorsque Kubernetes constitue le cœur d’une infrastructure sur des centaines, voire des milliers de serveurs, les configurations bare-metal sont probablement le meilleur choix.
Les serveurs bare-metal éliminent les coûts associés aux licences des hyperviseurs. En outre, les entreprises qui effectuent des déploiements à grande échelle disposent généralement d’administrateurs qualifiés qui se consacrent à l’utilisation d’une seule plateforme.
Une fois que de nombreux serveurs bare-metal sont en place, Kubernetes peut équilibrer les charges de travail sur ces hôtes et gérer les défaillances. Cet environnement homogène est généralement plus simple à administrer. Exécuter Kubernetes dans des VMs est plus cohérent pour des environnements hétérogènes.
