Kubernetes est un excellent outil pour exécuter des conteneurs Docker dans un environnement de production en cluster. Cependant, il existe des problèmes que Kubernetes ne peut pas résoudre. Pour les déploiements de production fréquents, nous avons besoin d'un déploiement Bleu/Vert entièrement automatisé pour éviter les temps d'arrêt dans le processus, qui doit également gérer les requêtes HTTP externes et effectuer des déchargements SSL. Cela nécessite une intégration avec un équilibreur de charge tel que ha-proxy. Un autre défi est la mise à l'échelle semi-automatique du cluster Kubernetes lui-même lorsqu'il s'exécute dans un environnement cloud, par exemple en réduisant partiellement le cluster la nuit.
Bien que Kubernetes ne dispose pas de ces fonctionnalités prêtes à l'emploi, il fournit une API que vous pouvez utiliser pour résoudre des problèmes similaires. Des outils de déploiement automatisé Bleu/Vert et de mise à l'échelle d'un cluster Kubernetes ont été développés dans le cadre du projet Cloud RTI, créé sur la base de l'open source.
Cet article, une transcription vidéo, vous montre comment configurer Kubernetes avec d'autres composants open source pour créer un environnement prêt pour la production qui accepte le code d'un commit git sans temps d'arrêt en production.
Ainsi, une fois que vous avez accès à vos applications depuis le monde extérieur, vous pouvez commencer à mettre en place entièrement l'automatisation, c'est-à-dire l'amener au stade où vous pouvez effectuer un commit git et vous assurer que ce commit git aboutit en production. Naturellement, lors de la mise en œuvre de ces étapes, lors de la mise en œuvre du déploiement, nous ne voulons pas subir de temps d'arrêt. Ainsi, toute automatisation dans Kubernetes commence par l'API.
Kubernetes n'est pas un outil qui peut être utilisé de manière productive dès le départ. Bien sûr, vous pouvez le faire, utiliser kubectl et ainsi de suite, mais l'API reste la chose la plus intéressante et la plus utile de cette plate-forme. En utilisant l'API comme un ensemble de fonctions, vous pouvez accéder à presque tout ce que vous souhaitez faire dans Kubernetes. kubectl lui-même utilise également l'API REST.
Il s'agit de REST, vous pouvez donc utiliser n'importe quel langage ou outil pour travailler avec cette API, mais votre vie sera beaucoup plus facile grâce aux bibliothèques personnalisées. Mon équipe a écrit 2 bibliothèques de ce type : une pour Java/OSGi et une pour Go. Le second n'est pas souvent utilisé, mais de toute façon vous avez à votre disposition ces choses utiles. Il s'agit d'un projet open source sous licence partielle. Il existe de nombreuses bibliothèques de ce type pour différentes langues, vous pouvez donc choisir celles qui vous conviennent le mieux.
Ainsi, avant de commencer à automatiser votre déploiement, vous devez vous assurer que le processus ne sera soumis à aucun temps d'arrêt. Par exemple, notre équipe effectue des déploiements de production en milieu de journée, lorsque les utilisateurs utilisent au maximum les applications. Il est donc important d'éviter les retards dans ce processus. Afin d'éviter les temps d'arrêt, 2 méthodes sont utilisées : le déploiement bleu/vert ou la mise à jour continue. Dans ce dernier cas, si vous disposez de 5 répliques de l’application en cours d’exécution, elles sont mises à jour séquentiellement les unes après les autres. Cette méthode fonctionne très bien, mais elle ne convient pas si différentes versions de l'application s'exécutent simultanément pendant le processus de déploiement. Dans ce cas, vous pouvez mettre à jour l'interface utilisateur pendant que le backend exécute l'ancienne version et l'application cessera de fonctionner. Par conséquent, du point de vue de la programmation, travailler dans de telles conditions est assez difficile.
C'est l'une des raisons pour lesquelles nous préférons utiliser le déploiement bleu/vert pour automatiser le déploiement de nos applications. Avec cette méthode, vous devez vous assurer qu’une seule version de l’application est active à la fois.
Le mécanisme de déploiement bleu/vert ressemble à ceci. Nous recevons du trafic pour nos applications via ha-proxy, qui le transmet aux répliques en cours d'exécution de l'application de la même version.
Lorsqu'un nouveau déploiement est effectué, nous utilisons Deployer, qui reçoit les nouveaux composants et déploie la nouvelle version. Le déploiement d'une nouvelle version d'une application signifie qu'un nouvel ensemble de réplicas est « généré », après quoi ces réplicas de la nouvelle version sont lancés dans un nouveau pod distinct. Cependant, ha-proxy ne sait rien d’eux et ne leur achemine pas encore de charge de travail.
Par conséquent, il est tout d’abord nécessaire d’effectuer une vérification des performances des nouvelles versions de vérification de l’état pour garantir que les réplicas sont prêts à supporter la charge.
Tous les composants de déploiement doivent prendre en charge une certaine forme de vérification de l'état. Cela peut être une vérification d'appel HTTP très simple, lorsque vous recevez un code avec le statut 200, ou une vérification plus approfondie, dans laquelle vous vérifiez la connexion des répliques avec la base de données et d'autres services, la stabilité des connexions de l'environnement dynamique. , et si tout démarre et fonctionne correctement. Ce processus peut être assez complexe.
Une fois que le système a vérifié que toutes les répliques mises à jour fonctionnent, Deployer mettra à jour la configuration et transmettra le bon confd, qui reconfigurera ha-proxy.
Ce n'est qu'après cela que le trafic sera dirigé vers le pod contenant des répliques de la nouvelle version et que l'ancien pod disparaîtra.
Ce mécanisme n'est pas une fonctionnalité de Kubernetes. Le concept de déploiement Bleu/Vert existe depuis assez longtemps et a toujours utilisé un équilibreur de charge. Tout d'abord, vous dirigez tout le trafic vers l'ancienne version de l'application, et après la mise à jour, vous le transférez complètement vers la nouvelle version. Ce principe n'est pas utilisé uniquement dans Kubernetes.
Je vais maintenant vous présenter un nouveau composant de déploiement - Deployer, qui effectue des contrôles de santé, reconfigure les proxys, etc. Il s’agit d’un concept qui ne s’applique pas au monde extérieur et existe au sein de Kubernetes. Je vais vous montrer comment créer votre propre concept Deployer à l'aide d'outils open source.
Ainsi, la première chose que fait Deployer est de créer un contrôleur de réplication RC à l'aide de l'API Kubernetes. Cette API crée des pods et des services pour un déploiement ultérieur, c'est-à-dire qu'elle crée un tout nouveau cluster pour nos applications. Dès que RC sera convaincu que les répliques ont démarré, il effectuera un Health check sur leur fonctionnalité. Pour ce faire, Deployer utilise la commande GET /health. Il exécute les composants d'analyse appropriés et vérifie tous les éléments qui prennent en charge le fonctionnement du cluster.
Une fois que tous les pods ont signalé leur état de santé, Deployer crée un nouvel élément de configuration : le stockage distribué etcd, qui est utilisé en interne par Kubernetes, y compris le stockage de la configuration de l'équilibreur de charge. Nous écrivons des données sur etcd, et un petit outil appelé confd surveille etcd pour les nouvelles données.
S'il détecte des modifications dans la configuration initiale, il génère un nouveau fichier de paramètres et le transfère à ha-proxy. Dans ce cas, ha-proxy redémarre sans perdre aucune connexion et adresse la charge aux nouveaux services qui permettent à la nouvelle version de nos applications de fonctionner.
Comme vous pouvez le constater, malgré l'abondance de composants, il n'y a rien de compliqué ici. Vous avez juste besoin de prêter plus d'attention à l'API et etcd. Je veux vous parler du déployeur open source que nous utilisons nous-mêmes - Amdatu Kubernetes Deployer.
Il s'agit d'un outil d'orchestration des déploiements Kubernetes et possède les fonctionnalités suivantes :
- Déploiement Bleu/Vert ;
- mise en place d'un équilibreur de charge externe ;
- gestion des descripteurs de déploiement ;
- gérer le déploiement réel ;
- vérifier la fonctionnalité des contrôles de santé pendant le déploiement ;
- implémentation de variables d'environnement dans des pods.
Ce déploiement est construit sur l'API Kubernetes et fournit une API REST pour gérer les handles et les déploiements, ainsi qu'une API Websocket pour diffuser les journaux pendant le processus de déploiement.
Il place les données de configuration de l'équilibreur de charge dans etcd, vous n'avez donc pas besoin d'utiliser ha-proxy avec une prise en charge prête à l'emploi, mais utilisez facilement votre propre fichier de configuration d'équilibreur de charge. Amdatu Deployer est écrit en Go, comme Kubernetes lui-même, et est sous licence Apache.
Avant de commencer à utiliser cette version du déployeur, j'ai utilisé le descripteur de déploiement suivant, qui spécifie les paramètres dont j'ai besoin.
L'un des paramètres importants de ce code est d'activer l'indicateur « useHealthCheck ». Nous devons préciser qu'un contrôle d'intégrité doit être effectué pendant le processus de déploiement. Ce paramètre peut être désactivé lorsque le déploiement utilise des conteneurs tiers qui n'ont pas besoin d'être vérifiés. Ce descripteur indique également le nombre de répliques et l'URL du frontend dont ha-proxy a besoin. À la fin se trouve l'indicateur de spécification du pod "podspec", qui appelle Kubernetes pour obtenir des informations sur la configuration du port, l'image, etc. Il s'agit d'un descripteur JSON assez simple.
Un autre outil qui fait partie du projet open source Amdatu est Deploymentctl. Il dispose d'une interface utilisateur pour configurer les déploiements, stocke l'historique des déploiements et contient des webhooks pour les rappels d'utilisateurs et de développeurs tiers. Vous ne pouvez pas utiliser l'interface utilisateur car Amdatu Deployer lui-même est une API REST, mais cette interface peut vous faciliter grandement le déploiement sans impliquer aucune API. Deploymentctl est écrit en OSGi/Vertx en utilisant Angular 2.
Je vais maintenant démontrer ce qui précède à l'écran à l'aide d'un enregistrement préenregistré afin que vous n'ayez pas à attendre. Nous allons déployer une simple application Go. Ne vous inquiétez pas si vous n'avez jamais essayé Go auparavant, c'est une application très simple donc vous devriez pouvoir la comprendre.
Ici, nous créons un serveur HTTP qui répond uniquement à /health, donc cette application teste uniquement la vérification de l'état et rien d'autre. Si la vérification réussit, la structure JSON présentée ci-dessous est utilisée. Il contient la version de l'application qui sera déployée par le déployeur, le message que vous voyez en haut du fichier et le type de données booléen - si notre application fonctionne ou non.
J'ai un peu triché avec la dernière ligne, car j'ai placé une valeur booléenne fixe en haut du fichier, ce qui m'aidera à l'avenir à déployer même une application « malsaine ». Nous y reviendrons plus tard.
Alors, commençons. Tout d'abord, nous vérifions la présence de pods en cours d'exécution à l'aide de la commande ~ kubectl get pods et, en fonction de l'absence de réponse de l'URL du frontend, nous nous assurons qu'aucun déploiement n'est actuellement en cours.
Ensuite, sur l'écran, vous voyez l'interface Deploymentctl que j'ai mentionnée, dans laquelle les paramètres de déploiement sont définis : espace de noms, nom de l'application, version de déploiement, nombre de répliques, URL frontale, nom du conteneur, image, limites de ressources, numéro de port pour la vérification de l'état, etc. Les limites de ressources sont très importantes, car elles vous permettent d'utiliser la quantité maximale de matériel possible. Ici, vous pouvez également consulter le journal de déploiement.
Si vous répétez maintenant la commande ~ kubectl get pods, vous pouvez voir que le système « se fige » pendant 20 secondes, pendant lesquelles ha-proxy est reconfiguré. Après cela, le pod démarre et notre réplique est visible dans le journal de déploiement.
J'ai supprimé les 20 secondes d'attente de la vidéo et vous voyez désormais à l'écran que la première version de l'application a été déployée. Tout cela a été fait en utilisant uniquement l'interface utilisateur.
Essayons maintenant la deuxième version. Pour ce faire, je modifie le message de l'application de "Bonjour Kubernetes !" sur « Hello, Deployer ! », le système crée cette image et la place dans le registre Docker, après quoi nous cliquons simplement à nouveau sur le bouton « Deploy » dans la fenêtre Deploymentctl. Dans ce cas, le journal de déploiement est automatiquement lancé de la même manière que lors du déploiement de la première version de l'application.
La commande ~ kubectl get pods montre qu'il y a actuellement 2 versions de l'application en cours d'exécution, mais le frontend montre que nous exécutons toujours la version 1.
L'équilibreur de charge attend la fin de la vérification de l'état avant de rediriger le trafic vers la nouvelle version. Au bout de 20 secondes, nous passons à curl et constatons que nous avons désormais déployé la version 2 de l'application, et que la première a été supprimée.
Il s’agissait du déploiement d’une application « saine ». Voyons ce qui se passe si, pour une nouvelle version de l'application, je change le paramètre Healthy de true à false, c'est-à-dire que j'essaie de déployer une application défectueuse qui a échoué au contrôle de santé. Cela peut se produire si des erreurs de configuration ont été commises dans l'application au stade du développement et qu'elle a été envoyée en production sous cette forme.
Comme vous pouvez le voir, le déploiement passe par toutes les étapes ci-dessus et ~kubectl get pods montre que les deux pods sont en cours d'exécution. Mais contrairement au déploiement précédent, le journal affiche l’état du délai d’attente. Autrement dit, en raison de l'échec du contrôle de santé, la nouvelle version de l'application ne peut pas être déployée. En conséquence, vous voyez que le système est revenu à l'ancienne version de l'application et que la nouvelle version a simplement été désinstallée.
La bonne chose à ce sujet est que même si vous recevez un grand nombre de requêtes simultanées dans l'application, elles ne remarqueront même pas le temps d'arrêt lors de la mise en œuvre de la procédure de déploiement. Si vous testez cette application en utilisant le framework Gatling, qui lui envoie autant de requêtes que possible, alors aucune de ces requêtes ne sera abandonnée. Cela signifie que nos utilisateurs ne remarqueront même pas les mises à jour de version en temps réel. En cas d'échec, le travail continuera sur l'ancienne version ; en cas de succès, les utilisateurs passeront à la nouvelle version.
Il n'y a qu'une seule chose qui peut échouer : si le contrôle de santé réussit, mais que l'application échoue dès que la charge de travail lui est appliquée, c'est-à-dire que l'effondrement ne se produira qu'une fois le déploiement terminé. Dans ce cas, vous devrez revenir manuellement à l'ancienne version. Nous avons donc examiné comment utiliser Kubernetes avec les outils open source conçus à cet effet. Le processus de déploiement sera beaucoup plus facile si vous intégrez ces outils dans vos pipelines de construction/déploiement. Dans le même temps, pour démarrer le déploiement, vous pouvez utiliser soit l'interface utilisateur, soit automatiser entièrement ce processus en utilisant, par exemple, commit to master.
Notre serveur de build créera une image Docker, la poussera dans Docker Hub ou dans le registre que vous utilisez. Docker Hub prend en charge le webhook, nous pouvons donc déclencher le déploiement à distance via Deployer de la manière indiquée ci-dessus. De cette façon, vous pouvez entièrement automatiser le déploiement de votre application vers une production potentielle.
Passons au sujet suivant : la mise à l'échelle du cluster Kubernetes. Notez que la commande kubectl est une commande de mise à l'échelle. Avec plus d'aide, nous pouvons facilement augmenter le nombre de réplicas dans notre cluster existant. Cependant, en pratique, nous souhaitons généralement augmenter le nombre de nœuds plutôt que de pods.
Dans le même temps, pendant les heures de travail, vous devrez peut-être augmenter le coût des services Amazon, et la nuit, pour réduire le coût des services Amazon, vous devrez peut-être réduire le nombre d'instances d'application en cours d'exécution. Cela ne signifie pas qu'il suffira d'augmenter uniquement le nombre de pods, car même si l'un des nœuds est inactif, vous devrez toujours payer Amazon pour cela. Autrement dit, en plus de faire évoluer les pods, vous devrez augmenter le nombre de machines utilisées.
Cela peut être difficile car, que nous utilisions Amazon ou un autre service cloud, Kubernetes ne sait rien du nombre de machines utilisées. Il lui manque un outil qui vous permet de faire évoluer le système au niveau des nœuds.
Nous devrons donc nous occuper à la fois des nœuds et des pods. Nous pouvons facilement adapter le lancement de nouveaux nœuds à l'aide de l'API AWS et des machines du groupe Scaling pour configurer le nombre de nœuds de travail Kubernetes. Vous pouvez également utiliser cloud-init ou un script similaire pour enregistrer des nœuds dans le cluster Kubernetes.
La nouvelle machine démarre dans le groupe Scaling, s'initie en tant que nœud, s'enregistre dans le registre maître et commence à fonctionner. Après cela, vous pouvez augmenter le nombre de réplicas à utiliser sur les nœuds résultants. La réduction nécessite plus d'efforts, car vous devez vous assurer qu'une telle étape n'entraîne pas la destruction des applications déjà en cours d'exécution après avoir éteint les machines « inutiles ». Pour éviter un tel scénario, vous devez définir les nœuds sur le statut « non planifiable ». Cela signifie que le planificateur par défaut ignorera ces nœuds lors de la planification des pods DaemonSet. Le planificateur ne supprimera rien de ces serveurs, mais n'y lancera pas non plus de nouveaux conteneurs. L'étape suivante consiste à évincer le nœud de drainage, c'est-à-dire à transférer les pods en cours d'exécution vers une autre machine ou vers d'autres nœuds disposant d'une capacité suffisante pour cela. Une fois que vous vous êtes assuré qu'il n'y a plus de conteneurs sur ces nœuds, vous pouvez les supprimer de Kubernetes. Après cela, ils cesseront tout simplement d’exister pour Kubernetes. Ensuite, vous devez utiliser l'API AWS pour désactiver les nœuds ou les machines inutiles.
Vous pouvez utiliser Amdatu Scalerd, un autre outil de mise à l'échelle open source similaire à l'API AWS. Il fournit une CLI pour ajouter ou supprimer des nœuds dans un cluster. Sa fonctionnalité intéressante est la possibilité de configurer le planificateur à l'aide du fichier json suivant.
Le code affiché réduit la capacité du cluster de moitié pendant la période nocturne. Il configure à la fois le nombre de réplicas disponibles et la capacité souhaitée du cluster Amazon. L'utilisation de ce planificateur réduira automatiquement le nombre de nœuds la nuit et l'augmentera le matin, économisant ainsi le coût d'utilisation des nœuds d'un service cloud comme Amazon. Cette fonctionnalité n'est pas intégrée à Kubernetes, mais l'utilisation de Scalerd vous permettra de faire évoluer cette plate-forme comme vous le souhaitez.
Je tiens à souligner que beaucoup de gens me disent : « C'est bien beau tout ça, mais qu'en est-il de ma base de données, qui est généralement statique ? Comment pouvez-vous exécuter quelque chose comme ça dans un environnement dynamique comme Kubernetes ? À mon avis, vous ne devriez pas faire cela, vous ne devriez pas essayer de gérer un entrepôt de données dans Kubernetes. C'est techniquement possible, et il existe des tutoriels sur Internet à ce sujet, mais cela vous compliquera sérieusement la vie.
Oui, il existe un concept de magasins persistants dans Kubernetes, et vous pouvez essayer d'exécuter des magasins de données comme Mongo ou MySQL, mais c'est une tâche assez laborieuse. Cela est dû au fait que les entrepôts de données ne prennent pas entièrement en charge l'interaction avec un environnement dynamique. La plupart des bases de données nécessitent une configuration importante, y compris une configuration manuelle du cluster, n'aiment pas la mise à l'échelle automatique et d'autres choses similaires.
Par conséquent, vous ne devriez pas vous compliquer la vie en essayant de gérer un entrepôt de données dans Kubernetes. Organisez leur travail de manière traditionnelle en utilisant des services familiers et donnez simplement à Kubernetes la possibilité de les utiliser.
Pour conclure le sujet, je voudrais vous présenter la plateforme Cloud RTI basée sur Kubernetes, sur laquelle travaille mon équipe. Il fournit une journalisation centralisée, une surveillance des applications et des clusters, ainsi que de nombreuses autres fonctionnalités utiles qui vous seront utiles. Il utilise divers outils open source tels que Grafana pour afficher la surveillance.
Une question s'est posée sur la raison pour laquelle utiliser l'équilibreur de charge ha-proxy avec Kubernetes. Bonne question car il existe actuellement 2 niveaux d'équilibrage de charge. Les services Kubernetes résident toujours sur des adresses IP virtuelles. Vous ne pouvez pas les utiliser pour les ports sur des machines hôtes externes, car si Amazon surcharge son hôte cloud, l'adresse changera. C'est pourquoi nous plaçons ha-proxy devant les services - pour créer une structure plus statique permettant au trafic de communiquer de manière transparente avec Kubernetes.
Une autre bonne question est de savoir comment gérer les modifications du schéma de base de données lors d'un déploiement bleu/vert ? Le fait est que quelle que soit l’utilisation de Kubernetes, modifier le schéma de la base de données est une tâche difficile. Vous devez vous assurer que l'ancien et le nouveau schéma sont compatibles, après quoi vous pouvez mettre à jour la base de données, puis mettre à jour les applications elles-mêmes. Vous pouvez échanger à chaud la base de données, puis mettre à jour les applications. Je connais des personnes qui ont démarré un tout nouveau cluster de bases de données avec un nouveau schéma. C'est une option si vous avez une base de données sans schéma comme Mongo, mais ce n'est de toute façon pas une tâche facile. Si vous n'avez plus de questions, merci de votre attention !
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