Kubernetes est un excellent outil pour déployer des conteneurs Docker dans un environnement de production en cluster. Cependant, certaines tâches ne peuvent pas être résolues par Kubernetes. Lors d'un déploiement fréquent en environnement de production, nous avons besoin d'un déploiement Blue/Green entièrement automatisé pour éviter les temps d'arrêt, ce qui nécessite également de traiter les requêtes HTTP externes et d'effectuer le déchargement SSL. Cela nécessite une intégration avec un répartiteur de charge comme ha-proxy. Une autre tâche consiste à effectuer un dimensionnement semi-automatique du cluster Kubernetes lorsqu'il fonctionne dans un environnement cloud, par exemple, réduire partiellement la taille du cluster la nuit.
Bien que Kubernetes ne possède pas ces fonctionnalités « prêtes à l'emploi », il fournit une API que vous pouvez utiliser pour résoudre de telles tâches. Les outils pour le déploiement Blue/Green automatisé et le dimensionnement du cluster Kubernetes ont été développés dans le cadre du projet Cloud RTI, qui a été créé sur la base d'open-source.
Cet article, qui déchiffre une vidéo, explique comment configurer Kubernetes avec d'autres composants open-source pour créer un environnement prêt à la production, qui, sans temps d'arrêt en production, prend en compte le code des modifications git commit.
Donc, une fois que vous avez accès à vos applications depuis le monde extérieur, vous pouvez passer à la configuration complète de l'automatisation, c'est-à-dire l'amener à un stade où vous pouvez effectuer un git commit et vous assurer que ce git commit se termine en production. Naturellement, lors de la mise en œuvre de ces étapes, lors 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 que l'on peut utiliser de manière productive « prêt à l'emploi ». Bien sûr, vous pouvez le faire, utiliser kubectl, etc., mais l'API est tout de même la fonctionnalité la plus intéressante et utile de cette plateforme. En utilisant l'API comme un ensemble de fonctions, vous pouvez accéder pratiquement à tout ce que vous souhaitez faire dans Kubernetes. kubectl lui-même utilise également l'API REST.
C'est un REST, donc vous pouvez utiliser n'importe quel langage et outil pour travailler avec cette API, mais les bibliothèques utilisateur faciliteront considérablement votre vie. Mon équipe a écrit 2 de ces bibliothèques : une pour Java / OSGi et une pour Go. La deuxième est moins souvent utilisée, mais de toute façon, ces outils utiles sont à votre disposition. Ce sont en partie des projets open-source sous licence. Il existe de nombreuses bibliothèques de ce type pour différents langages, vous pouvez donc choisir celles qui vous conviennent le mieux.
Donc, avant de commencer l'automatisation du déploiement, il est essentiel de s'assurer que ce processus ne souffrira d'aucun temps d'arrêt. Par exemple, notre équipe effectue des déploiements en production au milieu de la journée, lorsque les utilisateurs utilisent intensément les applications, il est donc très important d'éviter les retards dans ce processus. Pour éviter les temps d'arrêt, nous utilisons 2 méthodes : le déploiement blue/green ou la mise à jour continue. Dans le dernier cas, si vous avez 5 répliques de l'application en marche, elles sont mises à jour successivement. Cette méthode fonctionne très bien, mais elle n'est pas adaptée si différentes versions de l'application sont en cours d'exécution pendant le déploiement. Dans ce cas, vous pouvez mettre à jour l'interface utilisateur pendant que le backend continue de fonctionner avec l'ancienne version, ce qui perturbera l'application. Ainsi, 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 blue/green pour automatiser le déploiement de nos applications. Avec cette méthode, vous devez vous assurer qu'à un moment donné, une seule version de l'application est active.
Le mécanisme de déploiement blue/green fonctionne comme suit. Nous recevons le trafic pour nos applications via ha-proxy, qui le dirige vers les répliques de l'application de la même version.
Lors d'un nouveau déploiement, nous utilisons Deployer, auquel de nouveaux composants sont fournis, et il effectue le déploiement de la nouvelle version. Le déploiement d'une nouvelle version de l'application signifie qu'un nouvel ensemble de répliques est 'mis en place', après quoi ces répliques de la nouvelle version sont lancées dans un pod séparé et nouveau. Cependant, ha-proxy n'en sait rien et ne dirige pour l'instant aucune charge de travail vers elles.
Il est donc primordial d'effectuer d'abord un contrôle de la fonctionnalité des nouvelles versions par le biais d'un health checking, afin de s'assurer que les répliques sont prêtes à prendre en charge la charge.
Tous les composants de déploiement doivent prendre en charge une forme quelconque de health check. Cela peut être une simple vérification HTTP par appel, où vous obtenez un code avec un statut 200, ou un contrôle plus profond, où vous vérifiez la connexion des répliques à la base de données et à d'autres services, la robustesse des connexions dans l'environnement dynamique, et si tout est lancé et fonctionne correctement. Ce processus peut être assez complexe.
Une fois que le système a vérifié le bon fonctionnement de toutes les répliques mises à jour, 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 avec les répliques de la nouvelle version, et le pod ancien disparaîtra.
Ce mécanisme n'est pas une spécificité de Kubernetes. Le concept de déploiement Blue/Green existe depuis assez longtemps et a toujours utilisé un équilibreur de charge. Au départ, vous dirigez tout le trafic vers l'ancienne version de l'application, puis, après la mise à jour, vous le transférez entièrement vers la nouvelle version. Ce principe est utilisé non seulement dans Kubernetes.
Je vais maintenant vous présenter un nouveau composant de déploiement – Deployer, qui effectue des vérifications de fonctionnalité, reconfigure le proxy, etc. C'est un concept qui ne concerne pas le monde extérieur et existe à l'intérieur de Kubernetes. Je vais montrer comment créer votre propre concept Deployer en utilisant des outils open-source.
Ainsi, la première chose que fait Deployer est de créer un contrôleur de réplication RC, en utilisant 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. Une fois que le RC s'assure que les répliques ont démarré, il effectuera un contrôle de leur état de santé. Pour cela, Deployer utilise la commande GET /health. Cela lance les composants de vérification appropriés et vérifie tous les éléments qui garantissent le bon fonctionnement du cluster.
Après que tous les pods aient signalé leur « santé », Deployer crée un nouvel élément de configuration : le stockage distribué etcd, qui est utilisé à l'intérieur de Kubernetes, notamment pour stocker la configuration de l'équilibreur de charge. Nous enregistrons les données dans etcd, et un petit outil, confd, surveille etcd à la recherche de nouvelles données.
S'il détecte des modifications de la configuration initiale, il génère un nouveau fichier de paramètres et le transmet à ha-proxy. Dans ce cas, ha-proxy se redémarre sans perdre aucune connexion et dirige la charge vers les nouveaux services qui assurent le fonctionnement de la nouvelle version de nos applications.
Comme vous pouvez le voir, malgré la multitude de composants, il n'y a rien de compliqué ici. Vous devez simplement porter plus d'attention à l'API et à etcd. Je tiens à vous parler d'un déployeur open-source que nous utilisons nous-mêmes : Amdatu Kubernetes Deployer.
C'est un outil d'orchestration de déploiements Kubernetes, doté des fonctionnalités suivantes :
- déploiement Blue/Green ;
- configuration de l'équilibreur de charge externe ;
- gestion des descripteurs de déploiement ;
- gestion du déploiement effectif ;
- vérification de l'état de santé pendant le déploiement ;
- injection de variables d'environnement dans les pods.
Ce Deployer est construit sur l'API Kubernetes et offre une API REST pour la gestion des descripteurs et des déploiements, ainsi qu'une API Websocket pour les journaux en continu pendant le déploiement.
Il place les données de configuration de l'équilibreur de charge dans etcd, vous pouvez donc ne pas utiliser ha-proxy avec un support « prêt à l'emploi », mais facilement utiliser votre propre fichier de configuration d'équilibreur. Amdatu Deployer est écrit en Go, tout 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 précise les paramètres dont j'ai besoin.
L'un des paramètres importants de ce code est l'activation du drapeau « useHealthCheck ». Nous devons indiquer qu'une vérification de l'état doit être effectuée lors du déploiement. Ce paramètre peut être désactivé lorsque des conteneurs de tiers sont utilisés et qu'il n'est pas nécessaire de les vérifier. Ce descripteur indique également le nombre de réplicas et l'URL du frontend dont ha-proxy a besoin. Enfin, il mentionne le drapeau de spécification du pod « podspec », qui interroge Kubernetes pour obtenir des informations sur la configuration des ports, l'image, etc. C'est un descripteur assez simple au format JSON.
Un autre outil qui fait partie du projet open-source Amdatu est Deploymentctl. Il dispose d'une interface utilisateur pour configurer le déploiement, stocke l'historique des déploiements et contient des webhooks pour les appels de retour de la part d'utilisateurs et développeurs tiers. Vous pouvez ne pas utiliser l'interface utilisateur, car le déployeur Amdatu est une API REST, mais cette interface peut grandement faciliter le déploiement sans avoir à utiliser une API. Deploymentctl est écrit en OSGi/Vertx en utilisant Angular 2.
Maintenant, je vais illustrer ce que j'ai dit à l'écran, en utilisant un enregistrement préalablement réalisé, afin que vous n'ayez pas à attendre. Nous allons déployer une application simple en Go. Ne vous inquiétez pas si vous n'avez jamais travaillé avec Go, cette application est très basique, donc tout devrait vous sembler clair.
Ici, nous créons un serveur HTTP qui répond uniquement à /health, donc cette application vérifie simplement l'état de santé et rien de plus. Si la vérification réussit, la structure JSON affichée ci-dessous est utilisée. Elle contient la version de l'application qui sera déployée par le déployeur, un message que vous voyez en haut du fichier, et un type de données booléen — si notre application fonctionne ou non.
Pour la dernière ligne, j'ai un peu triché, car j'ai mis une valeur booléenne fixe en haut du fichier, qui m'aidera par la suite à déployer même une application « non saine ». Nous allons examiner cela plus tard.
Alors, commençons. D'abord, nous vérifions s'il y a des pods en cours d'exécution avec la commande ~ kubectl get pods et par l'absence de réponse de l'URL du frontend, nous concordons qu'aucun déploiement n'est en cours.
Ensuite, à l'écran, vous voyez l'interface Deploymentctl que j'ai mentionnée, où sont définis les paramètres de déploiement : l'espace de noms, le nom de l'application, la version du déploiement, le nombre de répliques, l'URL du frontend, le nom du conteneur, l'image, les limites de ressources, le numéro de port pour la vérification de l'état, etc. Les limites de ressources sont très importantes, car elles permettent d'utiliser au maximum les capacités matérielles. Vous pouvez également consulter le journal du déploiement dans le journal de déploiement.
Si nous répétons maintenant la commande ~ kubectl get pods, nous voyons que le système "se fige" pendant 20 secondes, pendant lesquelles une reconfiguration de ha-proxy a lieu. Après cela, le pod se lance et notre réplique peut être vue dans le journal du déploiement.
J'ai coupé l'attente de 20 secondes de la vidéo, et maintenant vous voyez à l'écran que la première version de l'application est déployée. Tout cela a été fait uniquement à l'aide de l'interface utilisateur.
Maintenant, essayons la deuxième version. Pour cela, je change le message de l'application de « Bonjour, Kubernetes ! » à « Bonjour, Deployer ! », le système crée cette image et la place dans le registre Docker, après quoi nous appuyons simplement à nouveau sur le bouton « Déployer » dans la fenêtre Deploymentctl. Cela lance automatiquement le journal du déploiement exactement comme 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, cependant, le frontend indique que nous avons toujours la version 1 en fonction.
L'équilibreur de charge attend qu'un contrôle de l'état soit effectué, puis redirigera le trafic vers la nouvelle version. Après 20 secondes, nous passons à curl et voyons que maintenant nous avons déployé la version 2 de l'application, tandis que la première a été supprimée.
C'était le déploiement d'une application "saine" - healthy. Voyons ce qui se passera si, pour la nouvelle version de l'application, je change la valeur du paramètre Healthy de true à false, c'est-à-dire que j'essaie de déployer une application insaine qui n'a pas passé le contrôle de l'état. Cela peut arriver s'il y a eu des erreurs de configuration pendant la phase de développement, et qu'elle a été envoyée en production dans cet état.
Comme vous pouvez le voir, le déploiement passe par toutes les étapes mentionnées ci-dessus, et ~ kubectl get pods montre que les deux pods sont en cours d'exécution. Cependant, contrairement au déploiement précédent, le journal indique un état de timeout. Cela signifie que, parce que la vérification de la santé n'a pas réussi, 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'utilisation de l'ancienne version de l'application, tandis que la nouvelle version a simplement été supprimée.
Ce qui est bien, c'est que même si vous avez un grand nombre de requêtes simultanées entrant dans l'application, elles ne remarqueront même pas de temps d'arrêt pendant la procédure de déploiement. Si vous testez cette application avec le framework Gatling, qui lui envoie le maximum de requêtes possible, aucune de ces requêtes ne sera abandonnée. Cela signifie que nos utilisateurs ne remarqueront même pas la mise à jour des versions en temps réel. Si elle échoue, le travail continuera avec l'ancienne version, si elle réussit, les utilisateurs passeront à la nouvelle version.
Il n'y a qu'une seule chose qui peut causer un échec : si la vérification de la santé a réussi, mais que l'application a échoué dès qu'elle a reçu une charge de travail, c'est-à-dire que l'effondrement ne se produira qu'après la fin du déploiement. Dans ce cas, vous devrez revenir manuellement à l'ancienne version. Nous avons donc examiné comment utiliser Kubernetes avec les outils open-source qui lui sont destinés. La procédure de déploiement sera beaucoup plus simple si vous intégrez ces outils dans les pipelines de création/déploiement Build/Deploy. Ainsi, vous pouvez utiliser à la fois l'interface utilisateur et automatiser complètement ce processus, par exemple, en appliquant un commit to master.
Notre serveur de construction Build Server créera une image Docker, la placera dans Docker Hub ou tout autre registre que vous utilisez. Le Hub Docker prend en charge le webhook, donc nous pouvons lancer un déploiement distant via Deployer comme indiqué ci-dessus. De cette manière, le déploiement de l'application dans un environnement de production potentiel peut être complètement automatisé.
Passons à la prochaine thématique : la mise à l'échelle d'un cluster Kubernetes. Je note que la commande kubectl est la commande de mise à l'échelle. Avec elle, il est facile d'augmenter le nombre de répliques dans notre cluster actuel. Cependant, en pratique, nous souhaitons généralement augmenter non le nombre de pods, mais celui de nœuds.
Cela signifie qu'au cours de vos horaires de travail, vous pourriez avoir besoin d'augmenter le nombre de nœuds, tandis que la nuit, afin de réduire le coût des services Amazon, vous souhaiterez diminuer le nombre d'instances de votre application. Cela ne signifie pas qu'il suffit de mettre à l'échelle seulement le nombre de pods, car même si l'un des nœuds est inoccupé, vous devrez toujours payer Amazon pour cela. Donc, en plus de mettre à l'échelle les pods, vous devrez également mettre à l'échelle le nombre de machines utilisées.
Cela peut poser des problèmes, car peu importe si nous utilisons Amazon ou un autre service cloud, Kubernetes ne sait rien du nombre de machines utilisées. Il manque un outil permettant de mettre à l'échelle le système au niveau des nœuds.
Nous devrons donc gérer à la fois les nœuds et les pods. Nous pouvons facilement mettre à l'échelle le lancement de nouveaux nœuds à l'aide de l'API AWS et des groupes de mise à l'échelle pour configurer le nombre de nœuds de travail Kubernetes. Il est également possible d'utiliser cloud-init ou un script similaire pour enregistrer les nœuds dans le cluster Kubernetes.
Une nouvelle machine démarre dans le groupe de mise à l'échelle, s'initie en tant que nœud, s'enregistre dans le registre maître et commence à fonctionner. Après cela, il est possible d'augmenter le nombre de répliques pour les nœuds nouvellement formés. La réduction de l'échelle nécessite plus d'efforts, car il faut s'assurer qu'une telle mesure ne conduira pas à la destruction des applications déjà fonctionnelles après la désactivation des machines « inutiles ». Pour éviter ce scénario, il est nécessaire de mettre les nœuds en statut « unschedulable ». 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 également aucun nouveau conteneur. L'étape suivante consiste à drainer le nœud, c'est-à-dire à transférer les pods actifs vers une autre machine ou d'autres nœuds ayant suffisamment de capacité. Une fois qu'il n'y a plus de conteneurs sur ces nœuds, ils peuvent être supprimés de Kubernetes. Après cela, pour Kubernetes, ils cesseront simplement d'exister. Il est ensuite nécessaire d'utiliser l'API AWS pour désactiver les nœuds ou machines inutiles.
Vous pouvez utiliser Amdatu Scalerd — un autre outil open-source pour la mise à l'échelle, similaire à l'API AWS. Il fournit une CLI pour ajouter ou supprimer des nœuds dans le cluster. Une de ses caractéristiques intéressantes est la possibilité de configurer le planificateur à l'aide du fichier json suivant.
Le code illustré réduit de moitié la capacité du cluster pendant la nuit. Il configure à la fois le nombre de répliques existantes et la capacité souhaitée du cluster Amazon. L'utilisation de ce planificateur réduira automatiquement le nombre de nœuds la nuit et les augmentera le matin, permettant ainsi d'économiser sur le coût d'utilisation des nœuds d'un service cloud tel qu'Amazon. Cette fonctionnalité n'est pas intégrée dans Kubernetes, mais l'utilisation de Scalerd vous permettra de mettre à l'échelle cette plateforme comme bon vous semble.
Je voudrais attirer votre attention sur le fait que de nombreuses personnes me disent : « Tout cela est bien, mais qu'en est-il de ma base de données, qui est généralement statique ? » Comment peut-on faire fonctionner quelque chose de similaire dans un environnement aussi dynamique que Kubernetes ? À mon avis, vous ne devriez pas le faire, ne pas essayer d'organiser un stockage de données dans Kubernetes. Techniquement, c'est possible, il existe des guides en ligne à ce sujet, mais cela compliquerait sérieusement votre vie.
Oui, dans Kubernetes, il existe le concept de volumes persistants, et vous pouvez essayer de faire fonctionner des systèmes de gestion de bases de données comme Mongo ou MySQL, mais c'est une tâche assez laborieuse. Cela s'explique par le fait que les systèmes de gestion de bases 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 des ajustements importants, y compris la configuration manuelle du cluster, n'aiment pas l'autoscaling et d'autres choses semblables.
Par conséquent, il n'est pas nécessaire de compliquer votre vie en essayant de faire fonctionner un stockage de données dans Kubernetes. Organisez leur fonctionnement de manière traditionnelle avec des services familiers et laissez simplement Kubernetes les utiliser.
Pour conclure ce sujet, je voudrais vous présenter la plateforme Cloud RTI basée sur Kubernetes, sur laquelle travaille mon équipe. Elle offre une gestion centralisée des journaux, un monitoring des applications et des clusters, et possède de nombreuses autres fonctionnalités utiles dont vous aurez besoin. Elle utilise divers outils open-source, tels que Grafana pour l'affichage de la surveillance.
La question a été posée sur l'utilité d'un équilibreur de charge ha-proxy avec Kubernetes. C'est une bonne question, car il existe actuellement 2 niveaux d'équilibrage de charge. Les services Kubernetes fonctionnent encore sur des adresses IP virtuelles. Vous ne pouvez pas les utiliser pour les ports 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 pour un flux de trafic ininterrompu avec Kubernetes.
Une autre bonne question – comment gérer les modifications de schéma de base de données lors d'un déploiement blue/green ? En effet, quel que soit l'utilisation de Kubernetes, modifier un schéma de base de données est une tâche complexe. Vous devez garantir la compatibilité entre l'ancien et le nouveau schéma, après quoi vous pourrez mettre à jour la base de données et ensuite les applications elles-mêmes. Vous pouvez effectuer un « échange à chaud » de la base de données, puis mettre à jour les applications. Je connais des personnes qui ont chargé un tout nouveau cluster de base 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 dans tous les cas, ce n'est pas une tâche simple. S'il n'y a plus de questions, merci de votre attention !
Un peu de publicité 🙂
Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, , un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).
Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur
Source : habr.com
