IBM Research a publié un papier comparant les performances des conteneurs et des machines virtuelles, utilisant Docker et KVM, montrant le coût de Docker utilisé avec NAT ou AUFS et s'interrogeant sur la pratique d'exécuter des conteneurs dans des machines virtuelles.
Les auteurs ont exécuté des mesures sur le CPU, la mémoire, le réseau et les I/O entre des exécutions natives, avec un conteneur et dans une machine virtuelle en utilisant respectivement KVM et Docker comme technologie de virtualisation et de conteneurs. Des mesures ont aussi été faites avec l'utilisation de Redis et MySQL. Redis permet de tester la couche réseau avec de petits paquets et un nombre important de clients, alors que MySQL utilise la mémoire, le réseau et le système de fichier de manière intense.
Les résultats montrent que Docker égale ou dépasse les performances de KVM dans tous les cas testés. Pour les performances mémoire et CPU, KVM et Docker introduisent un léger mais négligeable surcoût, bien que les applications avec des I/O intenses nécessitent des réglages.
Les performances de Docker se dégradent lorsque l'on utilise des fichiers stockés sur AUFS, contrairement à l'utilisation des volumes qui ont de meilleures performances. Un volume est un répertoire spécialement désigné dans un ou plusieurs conteneurs qui évite l'utilisation d'AUFS, donc n'est pas affecté par son coût. L'utilisation d'AUFS implique un surcoût important en I/O, surtout lorsque l'on utilise de nombreuses couches et une hiérarchie profonde de répertoires.
L'option par défaut de Docker --net=bridge introduit un surcoût du fait de la réécriture des paquets NAT, observable avec un débit important. Les performances réseau peuvent être améliorées en utilisant --net=host qui permet de ne pas créer une couche réseau spécifique au conteneur, mais de réutiliser l'interface de l'hôte. Cette option doit être utilisée avec précaution, car elle donne la possibilité aux conteneurs d'ouvrir des ports inférieurs à 1024 comme n'importe quel processus root et d'accéder aux services réseaux tels que D-bus, ce qui peut permettre aux processus du conteneur d'exécuter des commandes non prévues telles que redémarrer l'hôte.
Les performances de KVM se sont considérablement améliorées depuis sa création, mais il reste guère conseillé pour des utilisations sensibles à la latence ou ayant d'importants I/O à cause du surcoût à chaque opération I/O. Ce surcoût est important pour des petits I/Os mais négligeable pour des I/Os importants.
Grâce à ces résultats, le papier s'interroge sur l'implémentation des IaaS utilisant des machines virtuelles :
La sagesse conventionnelle (dans la mesure où elle existe dans le jeune écosystème du cloud) dit qu'un IaaS est implémenté en utilisant des VMs et un PaaS en utilisant des conteneurs. Nous ne voyons aucune raison technique à cela, particulièrement dans les cas où un conteneur basé sur IaaS peut offrir de meilleures performances ou un déploiement simplifié. Les conteneurs peuvent aussi éliminer la distinction entre les IaaS et les serveurs non virtualisés puisqu'ils offrent le contrôle et l'isolation d'une VMs avec les performances d'un serveur physique.
Malgré la pratique courante d'exécuter les conteneurs dans un environnement virtualisé, le papier recommande de le faire sur des serveurs Linux physiques, sinon ils ont un surcoût de performance introduit par la VM sans avoir un avantage par rapport à une utilisation non virtualisée.