Kubernetes vs Docker – Quelle est la différence ?
La virtualisation matérielle offre toute une série d’avantages, tels que l’évolutivité, la sécurité, l’isolation, etc., par l’utilisation d’hyperviseurs pour partager le matériel physique avec des machines virtuelles (VMs). À l’heure actuelle, les VMs ne sont pas la seule forme de virtualisation, les conteneurs étant également devenus très populaires. Alors que les VMs 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 des paquets exécutables standardisés utilisés pour fournir des applications, y compris celles développées par l’intermédiaire d’une architecture logicielle basée sur des microservices, et comprenant tous les composants nécessaires à leur exécution.
Le moteur Docker est la plateforme la plus populaire pour l’exécution de conteneurs. Kubernetes est un terme que vous entendrez de plus en plus souvent dans le domaine de la conteneurisation et du cloud computing. Mais lequel est le meilleur : Docker ou Kubernetes ? C’est un sujet de débat populaire, mais cette formulation n’est pas techniquement correcte. Par exemple, vous ne pouvez pas demander : « Qu’est-ce qui est mieux : le chaud ou le 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. Elle est installée sur votre système d’exploitation (OS), de préférence sur Linux, mais peut également être installée sur Windows et macOS, qui à leur tour fonctionnent sur une machine physique ou virtuelle.
Une application exécutée 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 de système d’exploitation. Plusieurs conteneurs Docker peuvent être exécutés simultanément sur un seul système d’exploitation ; vous pouvez gérer ces conteneurs avec Docker, et Docker peut fonctionner sans Kubernetes. Si vous disposez de plusieurs hôtes pour exécuter des conteneurs, leur gestion manuelle peut s’avérer 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 à l’aide d’une seule commande dans votre console Linux. L’utilisation de Docker Compose est un moyen d’effectuer l’orchestration de vos conteneurs Docker, mais il existe une alternative puissante à Docker Compose appelée Kubernetes.
Qu’est-ce que Kubernetes ?
Kubernetes est une solution open source d’orchestration de conteneurs utilisée pour gérer des logiciels et des services conteneurisés avec un haut degré d’automatisation.
Kubernetes est un projet Google destiné à automatiser le déploiement, l’évolutivité et la disponibilité des applications exécutées dans des conteneurs. Vous pouvez augmenter le nombre d’hôtes exécutant des conteneurs jusqu’à 11 hôtes ou plus. 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. L’architecture de Kubernetes est de type maître-esclave : le cluster se compose de nœuds maîtres et de nœuds de travail. Le nombre minimum de nœuds recommandé par Kubernetes est de quatre. Bien que vous puissiez créer un cluster avec une seule machine, vous avez besoin d’au moins quatre nœuds pour exécuter tous les exemples et tests. Un cluster Kubernetes qui gère le trafic de production doit comporter au moins trois nœuds de travail. L’utilisation de deux nœuds maîtres protège votre cluster contre la défaillance 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, ce qui inclut l’acceptation des requêtes des clients, la planification des opérations avec les 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 Workloads 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 garantir que les réplicas de pods dont le nombre est spécifié sont toujours en cours d’exécution à un moment donné. Vous pouvez ainsi vous assurer que les pods sont toujours disponibles lorsque vous en avez besoin.
Différentes interfaces CLI et API sont utilisées pour la communication entre les services 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 même 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 du 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 fonctionnent ensemble pour assurer, par exemple, le fonctionnement d’une application à plusieurs niveaux. Kubernetes prend en charge la dénomination dynamique et l’équilibrage de charge des pods par des abstractions. Cette approche garantit une connexion transparente entre les services par leur nom et vous permet de suivre leur état actuel.
- Les étiquettes sont des paires clé/valeur qui sont liées à des pods et à d’autres objets ou services, en plus de permettre de les regrouper facilement et de leur attribuer des tâches.
- Les espaces de noms est 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 conteneurs 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 trouve parfois dans la documentation technique.
Kubernetes vs Docker : Comparaison de la mise en réseau
Passons en revue les options de mise en réseau pour chaque solution.
Docker propose trois modes de mise en réseau pour la communication entre conteneurs.
Bridge. 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’adresse réseau (NAT), qui permet aux conteneurs de communiquer entre eux et de se connecter à des 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 à partir d’autres hôtes et de 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 plusieurs interfaces 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 son nom d’hôte est identique à celui du système d’exploitation hôte. Si vous exécutez un conteneur sur lequel le 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 réseau hôte n’est disponible que pour les machines Linux.
Aucune. 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 Aucune Aucune
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 possède sa propre adresse IP et se compose d’au moins un conteneur. Un pod peut se composer de plusieurs conteneurs qui sont utilisés pour des tâches connexes. Les conteneurs d’un même pod ne peuvent pas ouvrir le même port simultanément. Ce type de restriction est utilisé car un pod composé de plusieurs conteneurs dispose toujours d’une seule adresse IP.
De plus, Kubernetes crée un conteneur spécial pause container pour chaque pod. Ce conteneur spécial est destiné à fournir une interface réseau (pour la communication interne et externe) aux autres conteneurs, et est généralement en pause (en mode veille). Ces conteneurs en pause se réveillent lorsque Kubernetes envoie un signal « SIGTERM ».
Flannel est généralement utilisé comme structure réseau pour connecter des conteneurs dans Kubernetes par les principes de superposition de réseaux. Le réseau superposé vous permet d’exécuter des conteneurs en communiquant via le réseau logique entre 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 ils s’exécutent et les adresses IP du réseau superposé.
La mise en réseau Kubernetes peut être intégrée à VMware NSX-T par l’intermédiaire du plugin NSX Container. Cette intégration vous permet d’utiliser une topologie réseau multi-locataires qui n’est pas disponible « prête à l’emploi » dans Kubernetes.
Le modèle de mise en réseau Kubernetes offre les fonctionnalités suivantes :
- Tous les conteneurs peuvent communiquer avec n’importe quel autre conteneur 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 visibles par les autres composants de Kubernetes.
Ingress est un objet API de Kubernetes utilisé pour gérer l’accès aux services du 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 pour que les règles d’entrée fonctionnent.
Cas d’utilisation
L’utilisation de Docker en tant que logiciel autonome est utile 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 risquez de rencontrer certaines complications en cours de route. Par exemple, certains conteneurs peuvent facilement être surchargés ou tomber en panne. Vous pouvez redémarrer manuellement le conteneur sur la machine appropriée, mais la gestion manuelle peut vous prendre beaucoup de temps et d’énergie.
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, des outils d’orchestration de conteneurs, etc. Par conséquent, Kubernetes est particulièrement adapté aux environnements de production à forte charge 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 clustering natif pour Docker qui peut transformer un pool 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 et des processus de mise en réseau standard ; il est destiné au déploiement, à la gestion et à l’évolutivité des conteneurs Docker.
Swarm est un cluster d’hôtes Docker appelés nœuds. Examinons les principaux composants d’un cluster lorsque vous utilisez Docker Swarm avant de comparer le déploiement du cluster avec Kubernetes et Docker Swarm :
Les nœuds de gestion sont utilisés pour effectuer l’orchestration du contrôle, la gestion du cluster et la distribution des tâches.
Les nœuds de travail sont utilisés pour exécuter les conteneurs dont les tâches sont attribuées par les nœuds de gestion. Chaque nœud peut être configuré comme nœud de gestion, nœud de travail ou les deux afin d’exécuter les fonctions de nœud de gestion et de nœud de travail. Notez que les nœuds de travail exécutent les services Swarm.
Services. Un service 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éplicas, les ressources réseau disponibles, les ports qui doivent être accessibles depuis les réseaux externes, etc. La configuration du service, telle que la configuration réseau, peut être modifiée et appliquée à un conteneur sans avoir à redémarrer manuellement le service avec le conteneur.
Tâches. Une tâche est un emplacement dans lequel un seul conteneur est en cours d’exécution. Les tâches sont les composants d’un service Swarm.
Ainsi, Docker Swarm et Kubernetes sont deux plateformes différentes utilisées à des fins similaires. Il est maintenant temps de les comparer dans un ensemble de catégories appropriées.
Déploiement de cluster
Docker Swarm. Une API Docker standard vous permet de déployer un cluster avec Swarm par l’intermédiaire d’une interface CLI (interface de ligne de commande) Docker standard qui facilite le déploiement, en particulier lors de la première utilisation. La facilité du déploiement de Swarm par rapport à Kubernetes est également due à la capacité d’un seul maître Docker à décider de la manière de distribuer les services. Aucun pod n’est utilisé dans Docker Swarm.
Kubernetes vous oblige à utiliser des commandes spécifiques qui sont différentes des commandes Docker standard. Des API spécifiques 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, le planificateur, etc.
Évolutivité
Docker Swarm. Grâce à l’API simple fournie par Docker, le déploiement de conteneurs et la mise à jour des services dans des clusters de grande et petite taille peuvent être effectués plus rapidement. L’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 que Kubernetes.
Kubernetes fournit des API relativement unifiées et un certain nombre de fonctionnalités qui ralentissent souvent le processus de déploiement. Trois types de composants doivent être configurés : Pod, Déploiement et Service. En matière d’évolutivité, Kubernetes est préférable en raison de sa capacité à analyser les charges des serveurs et à offrir la possibilité d’augmenter ou de réduire automatiquement l’évolutivité en fonction des conditions à remplir. 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 chacune des mécanismes similaires de réplication et de redondance des services. Dans les deux cas, le système est autorégulé et ne nécessite aucune reconfiguration manuelle après le retour d’un nœud défaillant dans le cluster.
Docker Swarm. Les nœuds gestionnaires gèrent les ressources des nœuds de travail et de l’ensemble du cluster. Les nœuds du cluster Swarm participent à la réplication des services.
Kubernetes. Les nœuds défaillants sont détectés par les services d’équilibrage de charge de Kubernetes et sont éliminés du cluster. Tous les pods sont répartis entre les nœuds, ce qui garantit 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 qui peut être effectuée automatiquement par le réseau Swarm interne. Toutes les requêtes 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 requêtes entrantes vers les 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 qu’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 l’interface CLI Docker peuvent être utilisées avec Docker Swarm, grâce à l’API standardisé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. Le nombre précis de réplicas peut être défini avec Docker Compose pour Docker Swarm.
Kubernetes. Kubernetes dispose de sa propre API, de son propre client et nécessite des fichiers YAML pour être configuré. Il s’agit là d’une différence majeure, car Docker Compose et Docker CLI ne peuvent pas être utilisés pour effectuer le déploiement de 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 il est plus complexe. Les fonctionnalités de Docker Compose sont assurées par l’utilisation de pods, de déploiements et de services dans Kubernetes, chaque couche étant utilisée à des fins spécifiques. Les pods sont responsables de l’interaction entre les conteneurs, tandis que les déploiements sont responsables de la haute disponibilité et de la mise en réseau d’un seul nœud dans le cluster (un peu comme Docker Compose pour une application Docker autonome sans Swarm), et les services Kubernetes sont responsables de la configuration du fonctionnement des services à l’intérieur du cluster, de la tolérance aux pannes, etc.
Mise en réseau
Docker Swarm. Il existe un réseau interne par défaut pour la communication entre les conteneurs au sein d’un cluster, auquel 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 de réseau de Kubernetes est très différent et est mis en œuvre à l’aide de plugins, dont l’un est Flannel, l’option la plus populaire. Les pods interagissent entre eux, 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 mise en réseau Kubernetes suppose la configuration de deux CIDR, Classless Inter-Domain Routing, également connu sous le nom de supernetting.
Surveillance
Docker Swarm. Il n’existe pas d’outils intégrés pour la surveillance et la journalisation, mais vous pouvez configurer manuellement des outils de surveillance tiers. ELK ou Reimann peuvent être utilisés à cette fin.
Kubernetes. Kubernetes fournit des outils intégrés pour la journalisation et la surveillance. Elasticsearch et Kibana (ELK) peuvent être utilisés pour surveiller l’état de l’ensemble du cluster, tandis que Heapster, Grafana et Influx sont pris en charge pour la surveillance des services de conteneurs.
Interface utilisateur graphique (GUI)
Docker Swarm. L’interface graphique peut être activée à l’aide d’outils tiers tels que Portainer.io, qui fournit une interface web conviviale. Vous pouvez également utiliser l’Édition Enterprise 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 accessible via une interface web qui vous permet de contrôler facilement votre cluster. L’interface graphique peut être un outil très précieux pour les utilisateurs ayant une expérience minimale de la gestion de Kubernetes avec l’interface CLI.
Conclusion
Docker Swarm est une solution Docker native qui utilise principalement l’API et l’interface CLI de Docker. Kubernetes, en revanche, est un projet de Google utilisé pour déployer un cluster sur lequel s’exécutent des conteneurs.
Docker Swarm et Kubernetes offrent tous deux des fonctionnalités de haute disponibilité, d’équilibrage de charge, de réseau superposé et d’évolutivité. Docker Swarm est le plus facile à déployer des deux, car la plupart de ses fonctionnalités sont configurées automatiquement et il consomme peu de ressources matérielles. Ses fonctionnalités sont toutefois limitées par l’API Docker et il ne dispose pas d’outils de surveillance natifs.
Kubernetes, quant à lui, est une solution modulaire offrant un haut niveau de flexibilité, qui est prise en charge par la majorité des grandes entreprises depuis plusieurs années. Kubernetes dispose d’outils intégrés pour la surveillance des services et de l’ensemble du cluster, mais son déploiement et sa configuration sont plus difficiles, ce qui en fait une solution plus exigeante. Kubernetes n’est pas compatible avec Docker CLI et Docker Compose. L’utilisation de Kubernetes est préférable dans les grands environnements où s’exécutent des applications multi-conteneurs à forte charge.
