Kubernetes vs Docker Swarm : que devriez-vous utiliser ?

0
141

Kubernetes et le mode Swarm de Docker’s sont deux outils d'orchestration de conteneurs qui vous permettent de faire évoluer les réplicas de charge de travail sur plusieurs machines physiques. Bien que Kubernetes soit le choix le plus populaire, Docker Swarm présente des avantages uniques qui méritent également d'être pris en compte.

Voici comment ces deux technologies se comparent à travers leurs fonctions clés. Les deux ont le même objectif final – vous permettant de mettre à l'échelle des conteneurs – mais y parvenir de manières parfois tout à fait différentes. Quel que soit votre choix, vous pourrez lancer et mettre à l'échelle des conteneurs créés à partir d'images créées avec Docker ou un autre moteur de conteneurs populaire.

Présentation

Kubernetes a été initialement développé en tant que projet open source chez Google. Il réside désormais au sein de la Cloud Native Computing Foundation (CNCF), un effort intersectoriel visant à promouvoir et à maintenir des projets cloud natifs largement utilisés.

La configuration de Kubernetes nécessite la création d'un cluster de machines physiques appelé nœuds. Ces machines exécutent vos conteneurs et sont contrôlées par un nœud principal centralisé qui émet des instructions de planification des conteneurs. Les nœuds de travail agissent sur ces instructions pour extraire les images des registres et démarrer vos conteneurs.

Kubernetes est censé être de niveau entreprise et prêt pour la production. Ses capacités de planification intègrent la mise à l'échelle automatique, le placement automatique, la répartition de la charge et la surveillance continue des arrêts et redémarrages de conteneurs.

Publicité

Le mode Swarm est l'orchestrateur intégré de Docker, inclus en tant que partie de la distribution Docker standard. Toute machine sur laquelle Docker est installé peut créer ou rejoindre un cluster swarm.

Swarm vous permet également de lier plusieurs machines physiques indépendantes dans un cluster. Il unifie efficacement un ensemble d'hôtes Docker en un seul hôte virtuel. La courbe d'apprentissage est relativement courte et les utilisateurs familiarisés avec Docker à hôte unique peuvent généralement se familiariser rapidement avec le mode Swarm.

Comme Kubernetes, un seul nœud de gestionnaire Swarm est responsable de la planification et de la surveillance des conteneurs. Le gestionnaire peut réagir aux incidents dans le cluster, comme la mise hors ligne d'un nœud, et replanifier les conteneurs en conséquence. Il prend également en charge les mises à jour progressives, vous permettant de faire évoluer les charges de travail sans affecter la disponibilité.

Ajout de nouvelles charges de travail

Kubernetesles applications sont déployées en créant une représentation déclarative des ressources de votre pile dans un fichier YAML. Le YAML est “appliqué” à votre cluster, généralement à l'aide d'une CLI telle que kubectl, puis par le plan de contrôle Kubernetes s'exécutant sur le nœud principal.

Des outils supplémentaires via des projets comme Helm vous permettent d'“installer” applications utilisant des “graphiques.” préconfigurés Il s'agit de collections de fichiers YAML qui ont été empaquetés pour être facilement ajoutés à votre cluster.

Kubernetes propose des dizaines de types de ressources qui résument les fonctions de cluster telles que la mise en réseau, le stockage et les déploiements de conteneurs. Apprendre les différents types de ressources et leurs rôles présente une courbe d'apprentissage assez raide pour un nouveau venu. Nous vous encourageons à examiner l'architecture globale de votre système, pas seulement les écrous et les boulons des conteneurs individuels.

Publicité

Docker Swarmutilise également des fichiers YAML, mais des déploiements simples peuvent être créés sans eux. L'interface de ligne de commande Swarm propose des commandes impératives comme alternative afin que vous puissiez lancer un trio de conteneurs NGINX en exécutant :

docker service create –replicas 3 –name nginx nginx:latest

Lorsque des fichiers YAML sont utilisés, le format est toujours beaucoup plus concis que les ressources Kubernetes. Les définitions de la pile Swarm sont très similaires aux fichiers Docker Compose ; Swarm peut déployer la plupart des fichiers Compose tels quels, ce qui vous permet de transférer facilement vos charges de travail Dockerisées existantes vers une opération à grande échelle dans un cluster Swarm multinœud.

Kubernetes fonctionne avec des abstractions qui se situent bien au-dessus de vos conteneurs réels. . Vous devez comprendre des termes tels que Ensemble de réplicas, Déploiement et Pod, et leur relation avec les conteneurs que vous exécutez. En revanche, la définition des services Swarm semblera familière à quiconque a déjà utilisé Docker et Docker Compose.

Scaling Containers

Kubernetes et Docker Swarm sont tous deux conçus avec l'évolutivité comme objectif principal. À un niveau de base, ils vous permettent de répliquer vos conteneurs sur plusieurs nœuds de travail isolés, améliorant ainsi votre résilience aux pannes matérielles et vous permettant d'ajouter de nouvelles instances de conteneurs pour répondre à la demande.

Kubernetesfournit des garanties solides concernant la réplication, la cohérence et la distribution. Il peut adapter automatiquement vos services en fonction de facteurs externes, garantissant que vos charges de travail restent accessibles même pendant les périodes de pointe de la demande. Cette automatisation peut être un facteur décisif pour les équipes d'exploitation occupées.

Docker Swarm nécessite une mise à l'échelle manuelle, soit en mettant à jour le fichier Compose de votre pile, soit en utilisant une CLI commande pour modifier le nombre de répliques. C'est simple mais efficace : les changements s'appliquent beaucoup plus rapidement que Kubernetes, car Swarm est un système moins compliqué. Cela signifie qu'il peut être le meilleur choix si vous avez besoin d'une réactivité extrême.

Publicité

Les deux orchestrateurs sont également efficaces pour maintenir une haute disponibilité. Kubernetes et Docker Swarm replanifieront chacun les conteneurs en cas d'échec ou si un nœud de travail se déconnecte. Ce comportement maintient automatiquement le nombre de réplicas spécifié, en supposant que des ressources suffisantes sont disponibles sur vos autres nœuds.

Mise en réseau et équilibrage de charge

Kubernetesexpose les charges de travail via “services” qui agissent comme des équilibreurs de charge dans le cluster. Le trafic atteint généralement le service via une entrée, une ressource qui vous permet de filtrer les demandes entrantes en fonction de propriétés telles que leur nom d'hôte et leur URL.

Comme d'habitude avec Kubernetes, cela signifie qu'il y a plusieurs étapes et abstractions à apprendre. Vos pods conteneurs doivent référencer un service, lui-même référencé par une entrée définissant vos règles de routage. L'avantage est que tout cela est intégré à Kubernetes ; la seule condition préalable est un équilibreur de charge externe pointant vers l'adresse IP principale de votre cluster. Les fournisseurs de cloud Kubernetes gérés offrent généralement une méthode en un clic pour créer un tel équilibreur de charge.

La mise en réseau se comporte différemment dans Docker Swarm. De la même manière que les conteneurs Docker classiques, vous pouvez facilement publier des ports sur un réseau d'entrée accessible sur tous les hôtes de l'essaim. Cela intègre un maillage de routage qui garantit que les demandes entrantes atteignent une instance de votre conteneur sur l'un des nœuds disponibles. Swarm propose également un mode de mise en réseau par hôte où les ports ne sont ouverts que sur les hôtes individuels sur lesquels les conteneurs s'exécutent.

Ce qui manque à Swarm, c'est un moyen intégré d'acheminer le trafic vers les conteneurs en fonction des caractéristiques de la demande telles que le nom d'hôte et l'URL. Pour y parvenir, vous ajoutez généralement un proxy inverse tel que NGINX, Traefik ou HAProxy qui sert de point d'entrée à votre essaim, fait correspondre les demandes entrantes et les transmet au conteneur approprié. L'ajout d'un composant d'infrastructure supplémentaire pour exposer les services derrière différents noms de domaine peut rendre Swarm moins adapté à plusieurs charges de travail de production.

Observabilité

Kubernetes et Docker Swarmles deux ont des outils de journalisation et de surveillance intégrés qui vous permettent d'inspecter les journaux des conteneurs et la consommation des ressources. Dans le cas de Kubernetes, vous pouvez observer votre cluster à l'aide d'outils CLI populaires tels que kubectl, ou basculer vers une interface Web telle que le tableau de bord officiel. Swarm expose les journaux via son CLI de la même manière que les journaux de conteneur Docker réguliers – utiliser les journaux de service Docker pour diffuser à partir d'un service.

Publicité

Où Kubernetes’ la prise en charge de l'observabilité s'étend au-delà de celle de Swarm dans ses intégrations avec des outils tiers. L'ajout d'un système de surveillance tel que Prometheus vous permet d'interroger, de visualiser et de stocker des métriques et des alertes, tandis que des agrégateurs comme Fluentd offrent des fonctionnalités similaires pour les journaux. Ceux-ci vous aident à développer un cluster hautement observable que vous pouvez facilement inspecter de l'extérieur.

Ces outils peuvent toujours être utilisés avec Docker Swarm, mais vous devrez configurer vos propres procédures pour déplacer les données de votre essaim vers vos plateformes d'agrégation. Kubernetes offre une expérience plus transparente où les outils s'exécutent à l'intérieur de votre cluster, en l'inspectant de l'intérieur.

Conclusion

Kubernetes et Docker Swarm sont deux orchestrateurs de conteneurs que vous pouvez utiliser pour faire évoluer vos services. Ce que vous devez utiliser dépend de la taille et de la complexité de votre service, de vos objectifs en matière de réplication et de toutes les exigences particulières que vous avez en matière de mise en réseau et d'observabilité.

Kubernetes est un système de niveau production qui inclut une mise à l'échelle automatique, une entrée réseau et des intégrations faciles d'observabilité dans son installation par défaut. Cette installation peut être plus délicate à réaliser car vous devrez gérer votre propre cluster ou en créer un avec un fournisseur de cloud public. L'autogestion du plan de contrôle peut être assez complexe, l'administration de Kubernetes étant désormais considérée comme un titre de poste à part entière.

Le déploiement sur Kubernetes nécessite une compréhension des concepts sous-jacents, de la manière dont ils résument les principes fondamentaux des conteneurs, et le type de ressource que vous devez utiliser dans chaque scénario. Cela crée une courbe d'apprentissage relativement raide; Kubernetes a la réputation d'être complexe et de semer la confusion chez les nouveaux arrivants, ce qu'il convient de garder à l'esprit si vous n'avez pas d'équipe opérationnelle dédiée.

Docker Swarm est beaucoup plus simple à faire fonctionner. Si Docker est installé, vous avez déjà tout ce dont vous avez besoin. Swarm peut distribuer horizontalement vos conteneurs, les replanifier dans une situation de basculement et les faire évoluer à la demande.

Publicité

L'utilisation quotidienne est très similaire aux workflows Docker établis. Les commandes CLI de base rappellent les opérations régulières des conteneurs Docker et il y a une compatibilité avec vos fichiers Docker Compose existants. Cela rend Swarm idéal pour une utilisation rapide dans des environnements internes et des bacs à sable de développeurs déjà fortement dockerisés.

Vous n'avez pas besoin de tout mettre sur une seule plate-forme : de nombreuses équipes utilisent à la fois Swarm et Kubernetes pour différents systèmes , permettant de réaliser les avantages des deux. Swarm est plus simple, plus facile à entretenir, plus familier aux développeurs et plus rapide à faire évoluer vos services. Kubernetes est plus exigeant à exploiter et fondé sur ses propres abstractions, mais vous offre l'automatisation, une solution de mise en réseau entièrement intégrée et l'accès à un écosystème croissant d'outils de support.