Docker Swarm, Kubernetes et Mesos sont les frameworks d'orchestration de conteneurs les plus populaires. Dans son exposé, Arun Gupta compare les aspects suivants de Docker, Swarm et Kubernetes :
- Développement local.
- Fonctions de déploiement.
- Applications multi-conteneurs.
- Découverte des services.
- Faire évoluer le service.
- Tâches à exécution unique.
- Intégration avec Maven.
- Mise à jour "roulante".
- Création d'un cluster de base de données Couchbase.
En conséquence, vous comprendrez clairement ce que chaque outil d’orchestration a à offrir et apprendrez à utiliser ces plateformes efficacement.
Arun Gupta est le technologue en chef des produits open source chez Amazon Web Services, qui développe les communautés de développeurs Sun, Oracle, Red Hat et Couchbase depuis plus de 10 ans. Possède une vaste expérience de travail dans la direction d'équipes interfonctionnelles développant et mettant en œuvre une stratégie pour les campagnes et les programmes de marketing. Il a dirigé des équipes d'ingénieurs Sun, est l'un des fondateurs de l'équipe Java EE et le créateur de la branche américaine de Devoxx4Kids. Arun Gupta est l'auteur de plus de 2 40 articles sur des blogs informatiques et a donné des conférences dans plus de XNUMX pays.
La ligne 55 contient un COUCHBASE_URI pointant vers ce service de base de données, qui a également été créé à l'aide du fichier de configuration Kubernetes. Si vous regardez la ligne 2, vous pouvez voir kind: Service est le service que je crée appelé couchbase-service, et le même nom est répertorié sur la ligne 4. Vous trouverez ci-dessous quelques ports.
Les lignes clés sont 6 et 7. En service, je dis : « Hé, ce sont les étiquettes que je recherche ! », et ces étiquettes ne sont rien de plus que des noms de paires variables, et la ligne 7 pointe vers mon couchbase-rs-pod. application. Voici les ports qui donnent accès à ces mêmes étiquettes.
À la ligne 19, je crée un nouveau type ReplicaSet, la ligne 31 contient le nom de l'image et les lignes 24 à 27 pointent vers les métadonnées associées à mon pod. C’est exactement ce que recherche le service et à quoi la connexion doit être établie. À la fin du fichier, il y a une sorte de connexion entre les lignes 55-56 et 4, disant : « utilisez ce service ! »
Ainsi, je démarre mon service lorsqu'il existe un jeu de réplicas, et comme chaque jeu de réplicas a son propre port avec l'étiquette correspondante, il est inclus dans le service. Du point de vue d'un développeur, il vous suffit d'appeler le service, qui utilise ensuite l'ensemble de répliques dont vous avez besoin.
En conséquence, j'ai un pod WildFly qui communique avec le backend de la base de données via Couchbase Service. Je peux utiliser le frontend avec plusieurs pods WildFly, qui communiquent également avec le backend couchbase via le service couchbase.
Nous verrons plus tard comment un service situé en dehors du cluster communique via son adresse IP avec des éléments situés à l'intérieur du cluster et possédant une adresse IP interne.
Les conteneurs sans état sont donc une excellente solution, mais est-il utile d'utiliser des conteneurs avec état ? Examinons les paramètres système pour les conteneurs avec état ou persistants. Dans Docker, il existe 4 approches différentes de la disposition du stockage des données auxquelles vous devez prêter attention. Le premier est Implicit Per-Container, ce qui signifie que lorsque vous utilisez des conteneurs satateful couchbase, MySQL ou MyDB, ils démarrent tous avec le bac à sable par défaut. Autrement dit, tout ce qui est stocké dans la base de données est stocké dans le conteneur lui-même. Si le conteneur disparaît, les données disparaissent avec lui.
Le second est explicite par conteneur, lorsque vous créez un stockage spécifique avec la commande docker volume create et que vous y stockez des données. La troisième approche par hôte est associée au mappage de stockage, lorsque tout ce qui est stocké dans le conteneur est simultanément dupliqué sur l'hôte. Si le conteneur tombe en panne, les données resteront sur l'hôte. Cette dernière est l'utilisation de plusieurs hôtes Multi-Host, ce qui est conseillé au stade de la production de diverses solutions. Supposons que vos conteneurs contenant vos applications s'exécutent sur l'hôte, mais que vous souhaitiez stocker vos données quelque part sur Internet et que vous utilisiez pour cela le mappage automatique pour les systèmes distribués.
Chacune de ces méthodes utilise un emplacement de stockage spécifique. Les données implicites et explicites par conteneur stockent les données sur l'hôte dans /var/lib/docker/volumes. Lors de l'utilisation de la méthode Par hôte, le stockage est monté à l'intérieur du conteneur et le conteneur lui-même est monté sur l'hôte. Pour les multihôtes, des solutions telles que Ceph, ClusterFS, NFS, etc. peuvent être utilisées.
Si un conteneur persistant tombe en panne, le répertoire de stockage devient inaccessible dans les deux premiers cas, mais dans les deux derniers cas, l'accès est maintenu. Cependant, dans le premier cas, vous pouvez accéder au référentiel via un hôte Docker exécuté sur une machine virtuelle. Dans le second cas, les données ne seront pas perdues non plus, car vous avez créé un stockage Explicite.
En cas de panne de l'hôte, le répertoire de stockage est indisponible dans les trois premiers cas ; dans le dernier cas, la connexion avec le stockage n'est pas interrompue. Enfin, la fonction partagée est totalement exclue pour le stockage dans le premier cas et est possible dans le reste. Dans le second cas, vous pouvez partager le stockage selon que votre base de données prend en charge ou non le stockage distribué. Dans le cas du Per-Host, la distribution des données n'est possible que sur un hôte donné, et pour un multihost elle est assurée par extension de cluster.
Ceci doit être pris en compte lors de la création de conteneurs avec état. Un autre outil Docker utile est le plugin Volume, qui fonctionne sur le principe des « piles présentes, mais doivent être remplacées ». Lorsque vous démarrez un conteneur Docker, il est indiqué : "Hé, une fois que vous démarrez un conteneur avec une base de données, vous pouvez stocker vos données dans ce conteneur !" Il s'agit de la fonctionnalité par défaut, mais vous pouvez la modifier. Ce plugin vous permet d'utiliser un lecteur réseau ou quelque chose de similaire au lieu d'une base de données conteneur. Il inclut un pilote par défaut pour le stockage basé sur l'hôte et permet l'intégration de conteneurs avec des systèmes de stockage externes tels qu'Amazon EBS, Azure Storage et les disques persistants GCE.
La diapositive suivante montre l'architecture du plugin Docker Volume.
La couleur bleue représente le client Docker associé à l'hôte Docker bleu, qui dispose d'un moteur de stockage local qui vous fournit des conteneurs pour stocker les données. Le vert indique le Plugin Client et le Plugin Daemon, qui sont également connectés à l'hôte. Ils offrent la possibilité de stocker des données dans un stockage réseau du type de backend de stockage dont vous avez besoin.
Le plugin Docker Volume peut être utilisé avec le stockage Portworx. Le module PX-Dev est en fait un conteneur que vous exécutez et qui se connecte à votre hôte Docker et vous permet de stocker facilement des données sur Amazon EBS.
Le client Portworx vous permet de surveiller l'état de divers conteneurs de stockage connectés à votre hôte. Si vous visitez mon blog, vous pourrez lire comment tirer le meilleur parti de Portworx avec Docker.
Le concept de stockage dans Kubernetes est similaire à Docker et est représenté par des répertoires accessibles à votre conteneur dans un pod. Ils sont indépendants de la durée de vie de tout conteneur. Les types de stockage disponibles les plus courants sont hostPath, nfs, awsElasticBlockStore et gsePersistentDisk. Jetons un coup d'œil au fonctionnement de ces magasins dans Kubernetes. En règle générale, le processus de connexion comprend 3 étapes.
La première est qu’une personne côté réseau, généralement un administrateur, vous fournit un stockage persistant. Il existe un fichier de configuration PersistentVolume correspondant pour cela. Ensuite, le développeur de l'application écrit un fichier de configuration appelé PersistentVolumeClaim, ou une demande de stockage PVC, qui dit : « J'ai 50 Go de stockage distribué provisionné, mais pour que d'autres personnes puissent également utiliser sa capacité, je dis à ce PVC que j'ai actuellement besoin de seulement 10 Go". Enfin, la troisième étape consiste à ce que votre demande soit montée en tant que stockage et que l'application qui possède le pod, ou le jeu de réplicas, ou quelque chose de similaire, commence à l'utiliser. Il est important de rappeler que ce processus comprend les 3 étapes mentionnées et est évolutif.
La diapositive suivante montre le conteneur de persistance Kubernetes de l'architecture AWS.
À l’intérieur du rectangle marron qui représente le cluster Kubernetes se trouvent un nœud maître et deux nœuds travailleurs, indiqués en jaune. L'un des nœuds de travail contient un pod orange, un stockage, un contrôleur de réplique et un conteneur Docker Couchbase vert. A l'intérieur du cluster, au dessus des nœuds, un rectangle violet indique le Service accessible de l'extérieur. Cette architecture est recommandée pour stocker les données sur l'appareil lui-même. Si nécessaire, je peux stocker mes données dans EBS en dehors du cluster, comme indiqué dans la diapositive suivante. Il s'agit d'un modèle typique de mise à l'échelle, mais il y a un aspect financier à prendre en compte lors de son utilisation : le stockage des données quelque part sur le réseau peut être plus coûteux que sur un hôte. Lors du choix des solutions de conteneurisation, c’est l’un des arguments de poids.
Tout comme avec Docker, vous pouvez utiliser des conteneurs Kubernetes persistants avec Portworx.
C'est ce que la terminologie actuelle de Kubernetes 1.6 appelle un « StatefulSet » : une façon de travailler avec des applications avec état qui traite les événements relatifs à l'arrêt du pod et à l'exécution d'un arrêt progressif. Dans notre cas, ces applications sont des bases de données. Sur mon blog, vous pouvez lire comment créer un StatefulSet dans Kubernetes à l'aide de Portworx.
Parlons de l'aspect développement. Comme je l'ai dit, Docker a 2 versions - CE et EE, dans le premier cas, nous parlons d'une version stable de l'édition communautaire, qui est mise à jour une fois tous les 3 mois, contrairement à la version mise à jour mensuellement de EE. Vous pouvez télécharger Docker pour Mac, Linux ou Windows. Une fois installé, Docker se mettra automatiquement à jour et il sera très simple de démarrer.
Pour Kubernetes, je préfère la version Minikube - c'est un bon moyen de démarrer avec la plateforme en créant un cluster sur un seul nœud. Pour créer des clusters de plusieurs nœuds, le choix des versions est plus large : ce sont kops, kube-aws (CoreOS+AWS), kube-up (obsolète). Si vous souhaitez utiliser Kubernetes basé sur AWS, je vous recommande de rejoindre l'AWS SIG, qui se réunit en ligne tous les vendredis et publie une variété de documents intéressants sur l'utilisation d'AWS Kubernetes.
Examinons comment la mise à jour continue est effectuée sur ces plates-formes. S'il existe un cluster de plusieurs nœuds, il utilise une version spécifique de l'image, par exemple WildFly:1. Une mise à jour continue signifie que la version de l'image est remplacée séquentiellement par une nouvelle sur chaque nœud, l'un après l'autre.
Pour ce faire, j'utilise la commande docker service update (nom du service), dans laquelle je précise la nouvelle version de l'image WildFly:2 et la méthode de mise à jour update-parallelism 2. Le chiffre 2 signifie que le système mettra à jour 2 images d'application simultanément, puis un délai de mise à jour de 10 secondes 10s, après quoi les 2 images suivantes seront mises à jour sur 2 nœuds supplémentaires, etc. Ce mécanisme simple de mise à jour continue vous est fourni dans le cadre de Docker.
Dans Kubernetes, une mise à jour continue fonctionne comme ceci. Le contrôleur de réplication rc crée un ensemble de répliques de la même version, et chaque pod de cette webapp-rc reçoit une étiquette située dans etcd. Lorsque j'ai besoin d'un pod, j'utilise le service d'application pour accéder au référentiel etcd, qui me fournit le pod en utilisant l'étiquette spécifiée.
Dans ce cas, nous avons 3 pods dans le contrôleur de réplication exécutant l'application WildFly version 1. Lors de la mise à jour en arrière-plan, un autre contrôleur de réplication est créé avec le même nom et le même index à la fin - - xxxxx, où x sont des nombres aléatoires, et avec les mêmes étiquettes. Application Service dispose désormais de trois pods avec l'ancienne version de l'application et de trois pods avec la nouvelle version dans le nouveau contrôleur de réplication. Après cela, les anciens pods sont supprimés, le contrôleur de réplication avec les nouveaux pods est renommé et mis en service.
Passons au suivi. Docker dispose de nombreuses commandes de surveillance intégrées. Par exemple, l'interface de ligne de commande Docker Container stats vous permet d'afficher des informations sur l'état des conteneurs sur la console toutes les secondes - utilisation du processeur, utilisation du disque, charge du réseau. L'outil Docker Remote API fournit des données sur la façon dont le client communique avec le serveur. Il utilise des commandes simples, mais est basé sur l'API Docker REST. Dans ce cas, les mots REST, Flash, Remote signifient la même chose. Lorsque vous communiquez avec l'hôte, il s'agit d'une API REST. L'API Docker Remote vous permet d'obtenir plus d'informations sur l'exécution des conteneurs. Mon blog décrit les détails de l'utilisation de cette surveillance avec Windows Server.
La surveillance des événements du système Docker lors de l'exécution d'un cluster multi-hôtes permet d'obtenir des données sur un crash d'hôte ou un crash de conteneur sur un hôte spécifique, la mise à l'échelle des services, etc. À partir de Docker 1.20, il inclut Prometheus, qui intègre les points de terminaison dans les applications existantes. Cela vous permet de recevoir des métriques via HTTP et de les afficher sur des tableaux de bord.
Une autre fonctionnalité de surveillance est cAdvisor (abréviation de Container Advisor). Il analyse et fournit des données sur l'utilisation des ressources et les performances des conteneurs en cours d'exécution, fournissant ainsi des métriques Prometheus prêtes à l'emploi. La particularité de cet outil est qu'il ne fournit que les données des 60 dernières secondes. Par conséquent, vous devez être en mesure de collecter ces données et de les mettre dans une base de données afin de pouvoir surveiller un processus à long terme. Il peut également être utilisé pour afficher graphiquement les métriques du tableau de bord à l’aide de Grafana ou Kibana. Mon blog contient une description détaillée de la façon d'utiliser cAdvisor pour surveiller les conteneurs à l'aide du tableau de bord Kibana.
La diapositive suivante montre à quoi ressemble le résultat du point de terminaison Prometheus et les métriques disponibles à afficher.
En bas à gauche, vous voyez les métriques des requêtes HTTP, des réponses, etc., à droite se trouve leur affichage graphique.
Kubernetes comprend également des outils de surveillance intégrés. Cette diapositive montre un cluster typique contenant un nœud maître et trois nœuds de travail.
Chacun des nœuds de travail contient un cAdvisor lancé automatiquement. De plus, il existe Heapster, un système de surveillance des performances et de collecte de métriques compatible avec Kubernetes version 1.0.6 et supérieure. Heapster vous permet de collecter non seulement des mesures de performances des charges de travail, des pods et des conteneurs, mais également des événements et autres signaux générés par l'ensemble du cluster. Pour collecter des données, il communique avec le Kubelet de chaque pod, stocke automatiquement les informations dans la base de données InfluxDB et les affiche sous forme de métriques sur le tableau de bord Grafana. Cependant, gardez à l'esprit que si vous utilisez miniKube, cette fonctionnalité n'est pas disponible par défaut, vous devrez donc utiliser des modules complémentaires pour la surveillance. Tout dépend donc de l'endroit où vous exécutez les conteneurs et des outils de surveillance que vous pouvez utiliser par défaut et que vous devez installer en tant que modules complémentaires distincts.
La diapositive suivante montre les tableaux de bord Grafana qui affichent l'état d'exécution de mes conteneurs. Il y a beaucoup de données intéressantes ici. Bien entendu, il existe de nombreux outils commerciaux de surveillance des processus Docker et Kubernetes, tels que SysDig, DataDog, NewRelic. Certains d’entre eux bénéficient d’une période d’essai gratuite de 30 ans, vous pouvez donc essayer de trouver celui qui vous convient le mieux. Personnellement, je préfère utiliser SysDig et NewRelic, qui s'intègrent bien à Kubernetes. Il existe des outils qui s'intègrent aussi bien aux plates-formes Docker qu'à Kubernetes.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com