La virtualisation matérielle offre une liste d’avantages tels que la scalabilité, la sécurité, l’isolation, etc. en utilisant des hyperviseurs pour partager le matériel physique avec des machines virtuelles (VM). À l’heure actuelle, les machines virtuelles ne sont pas la seule forme de virtualisation, car les conteneurs sont également devenus très populaires. Alors que les VM partagent le matériel physique des machines sous-jacentes, les conteneurs partagent le noyau du système d’exploitation sous-jacent. Les conteneurs ne sont pas des machines virtuelles légères, mais sont des packages exécutables normalisés utilisés pour fournir des applications, y compris des applications développées en utilisant l’architecture logicielle basée sur les microservices, et comprennent tous les composants nécessaires pour exécuter les applications.
Le moteur Docker est la plateforme la plus populaire pour exécuter des conteneurs. Kubernetes est un terme que vous pouvez entendre de plus en plus fréquemment dans le domaine de la conteneurisation et de l’informatique en nuage. Mais qu’est-ce qui est mieux – Docker ou Kubernetes ? C’est un sujet de débat populaire, mais le formuler ainsi n’est pas techniquement correct. Par exemple, vous ne pouvez pas demander : « Qu’est-ce qui est mieux – chaud ou bleu ? »
Qu’est-ce que Docker ?
Docker est une application autonome open source qui fonctionne comme un moteur utilisé pour exécuter des applications conteneurisées. Il est installé sur votre système d’exploitation (OS), de préférence sur Linux, mais peut également être installé sur Windows et macOS, qui à leur tour s’exécutent sur une machine physique ou virtuelle.
Une application s’exécutant dans un conteneur est isolée du reste du système et des autres conteneurs, mais donne l’illusion de s’exécuter dans sa propre instance OS. Plusieurs conteneurs Docker peuvent être exécutés sur un seul système d’exploitation simultanément ; vous pouvez gérer ces conteneurs avec Docker, et Docker peut fonctionner sans Kubernetes. Si vous avez plusieurs hôtes pour exécuter des conteneurs, les gérer manuellement peut être difficile, et il est généralement préférable de choisir un outil de gestion centralisé ou une solution d’orchestration.
Docker Compose est un outil d’orchestration de conteneurs de base utilisé pour exécuter des applications Docker multi-conteneurs. Vous pouvez configurer un fichier de configuration YAML (yml) Docker Compose pour définir des applications multi-conteneurs au lieu de configurer manuellement des fichiers Dockerfiles séparés pour chaque conteneur. Après avoir configuré le fichier YAML unique, vous pouvez exécuter tous les conteneurs nécessaires avec une seule commande dans votre console Linux. Utiliser Docker Compose est une façon d’orchestrer vos conteneurs Docker, mais il existe une alternative puissante à Docker Compose disponible qui s’appelle Kubernetes.
Qu’est-ce que Kubernetes ?
Kubernetes est une solution d’orchestration de conteneurs open source utilisée pour gérer des logiciels et des services conteneurisés avec un haut degré d’automatisation.
Kubernetes est un projet de Google destiné à automatiser le déploiement, le dimensionnement et la disponibilité des applications s’exécutant dans des conteneurs. Vous pouvez augmenter le nombre d’hôtes exécutant des conteneurs jusqu’à 11 ou plus d’hôtes. De plus, vous pouvez créer un cluster de conteneurs Docker avec Kubernetes afin de garantir une haute disponibilité et un équilibrage de charge.
Les hôtes utilisés dans un cluster sont appelés nœuds. Le type d’architecture de Kubernetes est maître-esclave – le cluster se compose de nœuds maîtres et de nœuds de travail. Le nombre minimum recommandé de nœuds requis par Kubernetes est de quatre. Bien que vous puissiez construire un cluster avec une seule machine, pour exécuter toutes les exemples et tests, vous avez besoin d’au moins quatre nœuds. Un cluster Kubernetes qui gère le trafic de production devrait avoir un minimum de trois nœuds de travail. L’utilisation de deux nœuds maîtres protège votre cluster contre l’échec d’un nœud maître. Vous pouvez utiliser plus de deux nœuds maîtres si nécessaire.
- Les nœuds maîtres sont utilisés pour gérer l’état d’un cluster, qui inclut l’acceptation des demandes des clients, la planification des opérations avec des conteneurs, l’exécution des boucles de contrôle, etc. Une copie de la base de données etcd qui stocke toutes les données du cluster doit être exécutée sur chaque nœud maître. Le nœud maître exécute un ensemble de trois processus : kube-apiserver, kube-controller-manager et kube-scheduler.
- Les nœuds de travail sont utilisés pour exécuter les charges de travail des applications en exécutant des conteneurs. Les deux processus Kubernetes s’exécutent sur le nœud non maître : kubelet (pour communiquer avec les nœuds maîtres) et kube-proxy (pour refléter les services réseau Kubernetes sur chaque nœud).
- Le contrôleur de réplication est un composant utilisé pour s’assurer que les répliques de Pod dont le nombre est spécifié sont toujours en cours d’exécution à tout moment. Ainsi, vous pouvez vous assurer que les Pods sont toujours disponibles chaque fois que vous en avez besoin.
Différentes CLI et API sont utilisées pour communiquer les services entre eux si Kubernetes est utilisé. Il existe également des termes spécifiques utilisés pour nommer les objets et les ressources de l’API RESTful qui sont des composants du cluster construit avec Kubernetes. - Pod est une unité de planification de base dans Kubernetes. Il s’agit d’un groupe de ressources dans lequel plusieurs conteneurs peuvent fonctionner. Les conteneurs appartenant à un Pod peuvent s’exécuter sur le même hôte et utiliser les mêmes ressources et le même réseau local. Les conteneurs dans le Pod sont isolés mais peuvent communiquer entre eux assez facilement. Ainsi, les Pods sont généralement utilisés dans Kubernetes mais si vous utilisez une application Docker autonome, seuls les pools de conteneurs sont disponibles.
- Service est un ensemble de conteneurs qui travaillent ensemble pour fournir, par exemple, le fonctionnement d’une application multi-niveaux. Kubernetes prend en charge le nommage dynamique et l’équilibrage de charge des Pods en utilisant des abstractions. Cette approche garantit une connexion transparente entre les services par le nom, et vous permet de suivre leur état actuel.
- Les étiquettes sont des paires clé/valeur qui sont liées aux Pods et à d’autres objets ou services, en plus de permettre de les regrouper facilement et d’assigner des tâches.
- Les espaces de noms sont une méthode qui permet de diviser logiquement le cluster Kubernetes unifié en plusieurs clusters virtuels. Chaque cluster virtuel peut exister dans un environnement virtuel limité par des quotas sans avoir d’impact sur les autres clusters virtuels.
Kubernetes peut être utilisé avec Docker, bien que Docker ne soit pas la seule plateforme de conteneur avec laquelle Kubernetes peut être utilisé. Kubernetes peut également fonctionner en conjonction avec des conteneurs Windows, des conteneurs Linux, rkt, etc. K8s est le nom de Kubernetes que l’on peut parfois trouver dans la documentation technique.
Kubernetes vs Docker: Comparaison du réseau
Examinons les options de réseau pour chaque solution.
Docker propose trois modes réseau pour la communication réseau entre les conteneurs.
Pont. Ce mode est utilisé par défaut, créant un pont virtuel de couche 3. Le nom du réseau sur votre hôte est docker0 pour ce réseau. Docker crée automatiquement un pont réseau de couche 3 et configure des règles de masquage pour l’interface réseau externe, en utilisant le principe de traduction d’adresses réseau (NAT), ce qui permet aux conteneurs de communiquer entre eux et de se connecter aux réseaux externes. Vous pouvez configurer la redirection de port pour l’interface réseau de la machine hôte si vous souhaitez vous connecter à un conteneur depuis d’autres hôtes et réseaux externes. Ainsi, en vous connectant au port approprié de la machine hôte, vous êtes redirigé vers le port nécessaire du conteneur Docker. Vous pouvez créer plus d’une interface réseau pour un conteneur Docker si nécessaire.
Hôte. Dans ce mode, un pilote réseau hôte garantit qu’un conteneur n’est pas isolé de l’hôte Docker. Le conteneur partage la pile réseau de l’hôte, et le nom d’hôte du conteneur est le même que celui du système d’exploitation hôte. Si vous exécutez un conteneur sur lequel un port TCP 8080 est écouté, l’application du conteneur est disponible sur le port TCP 8080 de l’adresse IP de la machine hôte. Le pilote de réseau hôte n’est disponible que pour les machines Linux.
Aucun. Aucune adresse IP n’est configurée pour l’interface réseau d’un conteneur donné, à l’exception de l’adresse 127.0.0.1 pour l’interface de bouclage. Il n’y a pas d’accès aux réseaux externes si le mode réseau Aucun est défini.
Réseautage multi-hôte pour les conteneurs Docker. Si des conteneurs s’exécutent sur différents hôtes, ils peuvent communiquer entre eux après configuration du réseau de superposition. Un service de stockage clé-valeur valide (Consul, Etcd ou ZooKeeper) doit être configuré pour créer de tels réseaux.
Kubernetes. Si vous utilisez des conteneurs Docker autonomes, chaque conteneur peut être considéré comme une unité de base qui communique via le réseau en utilisant l’interface réseau appropriée. Si vous utilisez Kubernetes, les Pods sont les unités de base du cluster de conteneurs. Chaque pod a sa propre adresse IP et est composé d’au moins un conteneur. Un pod peut être composé de plusieurs conteneurs utilisés pour des tâches liées. Les conteneurs du même pod ne peuvent pas ouvrir le même port simultanément. Cette restriction est utilisée car un pod composé de plusieurs conteneurs a toujours une seule adresse IP.
De plus, Kubernetes crée un conteneur spécial pause pour chaque Pod. Ce conteneur spécial est destiné à fournir une interface réseau (pour la communication interne et externe) pour les autres conteneurs, et est généralement en pause (en mode veille). Ces conteneurs de pause se réveillent lorsque Kubernetes envoie un signal « SIGTERM ».
Flannel est généralement utilisé comme tissu réseau pour connecter les conteneurs dans Kubernetes en utilisant les principes de superposition réseau. Le réseau de superposition vous permet d’exécuter des conteneurs en communiquant via le réseau logique de différents hôtes physiques du cluster (appelés nœuds). Le magasin de clés/valeurs open source etcd est utilisé pour enregistrer les mappages entre les adresses IP réelles attribuées aux conteneurs par les hôtes sur lesquels les conteneurs s’exécutent, et les adresses IP dans le réseau de superposition.
Le réseau Kubernetes peut être intégré à VMware NSX-T en utilisant le Plugin Conteneur NSX. Cette intégration vous permet d’utiliser une topologie réseau multi-locataire qui n’est pas disponible « prête à l’emploi » dans Kubernetes.
Le modèle de réseau Kubernetes offre les fonctionnalités suivantes:
- Tous les conteneurs peuvent communiquer avec tous les autres conteneurs au sein d’un cluster sans NAT.
- Tous les nœuds du cluster peuvent communiquer avec tous les conteneurs au sein d’un cluster sans NAT. Inversement, tous les conteneurs peuvent communiquer avec tous les nœuds du cluster.
- Les conteneurs voient leurs propres adresses IP et ces adresses IP sont vues par d’autres composants de Kubernetes.
Ingress est un objet API de Kubernetes qui est utilisé pour gérer l’accès aux services dans le cluster depuis l’extérieur (principalement HTTP et HTTPS). Vous pouvez configurer Ingress pour effectuer un accès externe aux services conteneurisés, pour l’équilibrage de charge, la terminaison SSL et l’hébergement virtuel basé sur le nom. Un contrôleur Ingress doit être déployé sur le nœud maître afin que les règles d’ingress fonctionnent.
Cas d’utilisation
L’utilisation de Docker en tant que logiciel autonome est bonne pour le développement d’applications, car les développeurs peuvent exécuter leurs applications dans des environnements isolés. De plus, les testeurs peuvent également utiliser Docker pour exécuter des applications dans des environnements sandbox. Si vous souhaitez utiliser Docker pour exécuter un grand nombre de conteneurs dans l’environnement de production, vous pouvez rencontrer quelques complications en cours de route. Par exemple, certains conteneurs peuvent facilement être surchargés ou échouer. Vous pouvez redémarrer manuellement le conteneur sur la machine appropriée, mais la gestion manuelle peut prendre beaucoup de votre temps et de votre énergie précieux.
Kubernetes vous permet de résoudre ces problèmes en fournissant des fonctionnalités clés telles que la haute disponibilité, l’équilibrage de charge, les outils d’orchestration de conteneurs, etc. Par conséquent, Kubernetes est le plus adapté aux environnements de production très chargés avec un grand nombre de conteneurs Docker. Le déploiement de Kubernetes est plus difficile que l’installation d’une application Docker autonome, c’est pourquoi Kubernetes n’est pas toujours utilisé pour le développement et les tests.
Kubernetes vs Docker Swarm
Docker Swarm est un outil de regroupement natif pour Docker qui peut transformer un ensemble d’hôtes Docker en un seul hôte virtuel. Docker Swarm est entièrement intégré au moteur Docker et vous permet d’utiliser des API standard et des processus de mise en réseau ; il est destiné au déploiement, à la gestion et à l’échelle des conteneurs Docker.
Swarm est un cluster d’hôtes Docker appelés nœuds. Considérons les principaux composants d’un cluster lors de l’utilisation de Docker Swarm avant de comparer le déploiement du cluster avec Kubernetes et Docker Swarm :
Les nœuds gestionnaires sont utilisés pour effectuer l’orchestration du contrôle, la gestion du cluster et la distribution des tâches.
Les nœuds travailleurs sont utilisés pour exécuter des conteneurs dont les tâches sont attribuées par les nœuds gestionnaires. Chaque nœud peut être configuré en tant que nœud gestionnaire, nœud travailleur, ou les deux afin d’effectuer à la fois les fonctions de nœud gestionnaire et de nœud travailleur. Notez que les nœuds travailleurs exécutent des services Swarm.
Services. Un service de Docker Swarm définit l’état optimal requis pour chaque service conteneurisé. Un service contrôle des paramètres tels que le nombre de répliques, les ressources réseau disponibles pour lui, les ports qui doivent être rendus accessibles depuis les réseaux externes, etc. La configuration du service, telle que la configuration du réseau, peut être modifiée et appliquée à un conteneur sans nécessiter de redémarrer le service avec le conteneur manuellement.
Tâches. Une tâche est un emplacement dans lequel s’exécute un seul conteneur. Les tâches sont les parties d’un service Swarm.
Ainsi, Docker Swarm et Kubernetes sont deux plates-formes différentes utilisées à des fins similaires. Maintenant, il est temps de les comparer dans un ensemble approprié de catégories.
Déploiement de cluster
Docker Swarm. Une API Docker standard vous permet de déployer un cluster avec Swarm en utilisant une interface de ligne de commande Docker standard, ce qui facilite le déploiement, surtout lorsqu’il est utilisé pour la première fois. La facilité de déploiement pour Swarm, comparée à Kubernetes, est également obtenue par la capacité d’un seul maître Docker à décider comment distribuer les services. Aucun Pod n’est utilisé dans Docker Swarm.
Kubernetes vous oblige à utiliser des commandes spécifiées différentes des commandes Docker standard. Des APIs spécifiées sont utilisées dans Kubernetes, ce qui signifie que même si vous connaissez les commandes pour la gestion de Docker, vous devrez peut-être également apprendre à utiliser un ensemble supplémentaire d’outils pour le déploiement de Kubernetes. Les nœuds doivent être définis manuellement dans le cluster Kubernetes – vous devez sélectionner le nœud maître, définir le contrôleur, l’ordonnanceur, etc.
Scalabilité
Docker Swarm. Grâce à l’API simple fournie par Docker, le déploiement de conteneurs et la mise à jour de service dans des clusters de grande et petite taille peuvent être effectués plus rapidement. Une interface de ligne de commande (CLI) est assez simple et facile à comprendre. Par conséquent, Swarm peut être considéré comme une solution plus évolutive par rapport à Kubernetes.
Kubernetes offre des API comparativement unifiées et un certain nombre de fonctionnalités qui entraînent souvent un processus de déploiement plus lent. Il existe trois types de composants à configurer : Pod, Deploy et Service. En ce qui concerne la mise à l’échelle automatique, Kubernetes est préférable en raison de sa capacité à analyser les charges des serveurs et à se redimensionner automatiquement en fonction des besoins. Kubernetes est le choix optimal pour les grands réseaux distribués et les systèmes complexes.
Haute disponibilité
Les deux options de solution possèdent des mécanismes de réplication de services et de redondance similaires, et dans les deux cas, le système est auto-régulé et ne nécessite pas de reconfiguration manuelle après le redémarrage d’un nœud en panne.
Docker Swarm. Les nœuds gestionnaires gèrent les ressources des nœuds travailleurs et de l’ensemble du cluster. Les nœuds du cluster Swarm participent à la réplication des services.
Kubernetes. Les services d’équilibrage de charge de Kubernetes détectent les nœuds défaillants et les éliminent du cluster. Tous les Pods sont répartis entre les nœuds, offrant ainsi une haute disponibilité en cas de défaillance d’un nœud sur lequel s’exécute une application conteneurisée.
Équilibrage de charge
Docker Swarm. L’équilibrage de charge est une fonctionnalité intégrée et peut être effectué automatiquement en utilisant le réseau Swarm interne. Toutes les demandes adressées au cluster sont distribuées et redirigées vers les nœuds du cluster ; n’importe quel nœud peut se connecter à n’importe quel conteneur. Docker Swarm utilise un élément DNS pour distribuer les demandes entrantes aux noms de service.
Kubernetes. Les politiques définies dans les Pods sont utilisées pour l’équilibrage de charge dans Kubernetes. Dans ce cas, les Pods de conteneurs doivent être définis comme des services. Vous devez configurer manuellement les paramètres d’équilibrage de charge, tandis que Ingress peut être utilisé pour l’équilibrage de charge.
Création et exécution de conteneurs
Docker Swarm. La grande majorité des commandes disponibles pour Docker CLI peuvent être utilisées lorsque Docker Swarm est utilisé, grâce à l’API normalisée de Docker Swarm. Docker Compose définit le travail avec les volumes et les réseaux utilisés, en plus de définir quels conteneurs doivent être regroupés ensemble. Le nombre précis de répliques peut être défini avec Docker Compose pour Docker Swarm.
Kubernetes. Kubernetes a sa propre API, son client et nécessite que les fichiers YAML soient configurés. C’est l’une des principales différences, car Docker Compose et Docker CLI ne peuvent pas être utilisés pour déployer des conteneurs dans ce cas. Dans Kubernetes, le système de définition des services suit un principe de fonctionnement similaire à celui de Docker Compose, mais est plus complexe. La fonctionnalité de Docker Compose est réalisée en utilisant des Pods, des Déploiements et des Services dans Kubernetes, au sein desquels chaque couche est utilisée pour son propre but spécifié. Les Pods sont responsables de l’interaction des conteneurs, tandis que les déploiements sont responsables de la haute disponibilité et du réseau pour un nœud unique dans le cluster (tout comme Docker Compose pour une application Docker autonome sans Swarm), et les services Kubernetes sont responsables de la configuration du fonctionnement du service à l’intérieur du cluster, de la tolérance aux pannes, etc.
Réseau
Docker Swarm. Il existe un réseau interne par défaut pour la communication des conteneurs au sein d’un cluster, sur lequel d’autres réseaux peuvent être ajoutés si nécessaire. Les réseaux sont protégés par des certificats TLS générés. La génération manuelle de certificats est prise en charge pour le chiffrement du trafic de données des conteneurs.
Kubernetes. Le modèle réseau de Kubernetes est assez différent et est implémenté en utilisant des plugins, dont l’un est Flannel, l’option la plus populaire. Les pods interagissent les uns avec les autres, et cette interaction peut être restreinte par des politiques. Il existe un réseau interne géré par le service etcd. Le chiffrement TLS est également disponible, mais doit être configuré manuellement. Le modèle de réseau Kubernetes suppose la configuration de deux CIDR, l’adressage sans classe inter-domaines, également connu sous le nom de supernetting.
Surveillance
Docker Swarm. Il n’y a pas d’outils intégrés de surveillance et de journalisation, bien que vous puissiez configurer manuellement des outils de surveillance tiers. ELK ou Reimann peuvent être utilisés à cette fin.
Kubernetes. Des outils intégrés sont fournis par Kubernetes pour la journalisation et la surveillance. Elasticsearch et Kibana (ELK) peuvent être utilisés pour surveiller l’état complet du cluster, tandis que Heapster, Grafana et Influx sont pris en charge pour surveiller les services de conteneurs.
Interface utilisateur graphique (GUI)
Docker Swarm. L’interface graphique peut être activée avec des outils tiers tels que Portainer.io qui fournit une interface web conviviale. En alternative, vous pouvez utiliser l’Édition Entreprise de Docker qui fournit une interface graphique pour la gestion des clusters.
Kubernetes. L’interface graphique fournie par Kubernetes est un tableau de bord fiable auquel on peut accéder via une interface web avec laquelle vous pouvez facilement contrôler votre cluster. L’interface graphique peut être un outil très précieux pour les utilisateurs ayant peu d’expérience dans la gestion de Kubernetes avec l’interface en ligne de commande.
Conclusion
Docker Swarm est une solution Docker native qui utilise principalement l’API Docker et l’interface en ligne de commande. Kubernetes, en revanche, est le projet de Google utilisé pour le déploiement d’un cluster sur lequel des conteneurs s’exécutent.
À la différence, Docker Swarm et Kubernetes offrent une haute disponibilité, l’équilibrage de charge, le réseau de superposition et des fonctionnalités de mise à l’échelle. Docker Swarm est le plus simple des deux à déployer, car la plupart de ses fonctionnalités sont automatisées, et il consomme peu de ressources matérielles. Cependant, sa fonctionnalité est limitée par l’API Docker et des outils de surveillance natifs font défaut.
En revanche, Kubernetes est une solution modulaire offrant un haut niveau de flexibilité qui est soutenue par la majorité des grandes entreprises depuis plusieurs années. Des outils intégrés pour surveiller les services et l’ensemble du cluster sont disponibles pour Kubernetes, bien que le déploiement et la configuration soient plus difficiles, ce qui en fait une solution plus exigeante. Kubernetes n’est pas compatible avec l’interface en ligne de commande Docker et Docker Compose. L’utilisation de Kubernetes est préférable dans les environnements étendus où des applications multi-conteneurs très chargées s’exécutent.