Bonjour à tous!
Dans cet article, nous avons décidé de spéculer un peu sur quand et pourquoi les entreprises ont besoin de Kubernetes. La technologie d'entrée est-elle difficile, à quelle vitesse et comment elle sera rentable. Est-ce que cela en vaut la peine et ce que tout cela menace. Nous ne nous fixons pas la tâche de rédiger une revue technique approfondie, dont il existe de nombreux, mais dans les documents suivants, nous partagerons certainement nos meilleures pratiques en termes d'architecture et de stabilité des applications sous Kubernetes. Maintenant, nous nous concentrons sur si le jeu en vaut la chandelle et ce que nous obtenons à la sortie.
Le délai de mise sur le marché - la vitesse de mise à jour des mises à jour sur le marché - devient aujourd'hui un facteur clé de l'efficacité des solutions informatiques. Le produit doit être amélioré chaque jour: ajoutez-lui de nouvelles fonctions et modules, maintenez la documentation et les scripts en parfait état. Dans le même temps, les systèmes en ligne doivent fonctionner correctement et être mis à jour sans affecter les utilisateurs.
Les microservices, les conteneurs et l'infrastructure pour leur orchestration - Kubernetes (ou K8S, on l'appelle dans les cercles techniques) protègent la mise à jour continue discrète.
Comment Kubernetes fournit des mises à jour système continues
La tâche principale lors de la mise à jour d'une solution informatique est d'assurer son bon fonctionnement après le transfert de l'environnement de développement vers la plateforme produit. Et aussi dans le bon fonctionnement du système au moment de la mise à jour du produit.
Le problème réside dans le fait que les paramètres de l'environnement de développement et des serveurs industriels ne correspondent souvent pas. Les conteneurs résolvent ce problème en combinant tous les composants logiciels dans un seul package isolé de l'environnement externe. Cela vous permet de déployer des applications rapidement et de manière fiable sur n'importe quelle infrastructure et facilite la mise à jour de la base de code du système.
Inaperçues par les utilisateurs, les mises à jour ont lieu grâce à la duplication des conteneurs et à la redirection séquentielle des utilisateurs de l'un à l'autre. Pour la gestion des conteneurs (orchestration), nous utilisons Kuberenetes. En fin de compte, il facilite la gestion, le déploiement et la mise à niveau de la solution, la surveillance des performances et le débogage en cas de panne.
Quand une entreprise a besoin de Kubernetes
Il est temps pour les entreprises de penser à passer à la plateforme Kubernetes lorsque:
- Un projet ou un système est un outil important pour les entreprises et doit donc être tolérant aux pannes et continuer à fonctionner, même si une partie est en panne.
- Le système est lourdement chargé, tout en conservant des mises à jour ou des améliorations rapides.
- Le système a périodiquement besoin de capacités supplémentaires. Et en a besoin rapidement.
- Et avec tout cela, la vitesse de livraison des mises à jour à l'environnement industriel est mesurée en semaines, mois, années, mais jamais - heures ou jours.
Vous avez également besoin de Kubernetes comme outil d'automatisation et de standardisation du travail avec la solution, si en plus des éléments ci-dessus:
- Il n'y a pas d'isolement entre les systèmes informatiques de l'entreprise et chacun peut influencer l'autre.
- Si vous devez écrire un script distinct à chaque fois pour communiquer avec les paramètres du serveur sur lequel le système est déployé, c'est-à-dire que vous pouvez faire évoluer ce processus uniquement à la main.
- Il y a des personnes clés dans l'équipe de développement - porteuses de «connaissances secrètes» sur le projet ou le système, et elles semblent uniques et irremplaçables.
Essentiellement, le passage à Kubernetes est un must pour les entreprises qui ont besoin de prendre en charge les systèmes d'information en ligne 24/7.
Pourquoi Kubernetes?
Kubernetes n'est pas la seule alternative pour l'intégration et le déploiement continus (CI / CD). Mais c'est Kubernetes qui est devenu la norme de l'industrie pour la gestion des systèmes qui nécessitent une haute disponibilité.
Pour nous en tant que développeur, les arguments décisifs en faveur de Kubernetes sont les suivants:
- La plateforme se concentre sur les applications, pas sur les infrastructures.
- Kubernetes est pratique pour travailler avec un centre de données, ainsi qu'avec plusieurs, répartis dans différentes villes.
- Prise en charge facile de la solution grâce à une documentation claire et une communauté active.
- Configuration flexible de différentes applications, distribution sécurisée du trafic.
- Prise en charge du conteneur Docker.
Quels sont les avantages de l'activité Kubernetes?
- Configuration flexible et processus de mise à jour automatisé
Vous déterminez vous-même quelle partie du système mettre en service commercial. Kubernetes vous permet de faire un cycle de libération court. Toutes les opérations - du code source du système à la version dans l'environnement du produit - se déroulent automatiquement. Vous n'avez pas besoin d'une équipe d'ingénieurs pour faire fonctionner le système. Les mises à jour actuelles n'affectent pas les performances du système et peuvent être effectuées à tout moment pour les développeurs. - Placement et mise à l'échelle du système
Le système peut être placé à la fois sur la puissance de calcul du client (ou dans le centre de données) et sur n'importe quel fournisseur de cloud, par exemple Amazon ou Azure. Tout niveau de performances et de tolérance aux pannes peut être facilement atteint en faisant évoluer le cluster. - Normalisation et auto-documentation
La solution ne nécessite pas d'instructions. Il est auto-documenté et immédiatement emballé automatiquement dans une unité d'utilisation - un conteneur. Nous décrivons la configuration dans Kubernetes comme un plan / diagramme. Nous n'écrivons pas de scripts qui préparent l'environnement, comme c'était le cas avant Kubernetes. Au lieu de cela, nous transmettons à Kubernetes des informations (un diagramme) sur le fonctionnement de la solution. Et il met lui-même en œuvre ce schéma.
Les développeurs écrivent maintenant une application pour travailler dans un conteneur. Les ingénieurs DevOps écrivent un schéma de fonctionnement d'une application dans un conteneur, et Kubernetes lui-même effectue les tâches de construction d'une solution.
La technologie Kubernetes est standardisée. Il vous sera facile de former un nouvel employé à votre système de libération ou de transférer le système à un nouvel entrepreneur.
La description de configuration finale créée par Kubernetes est également la documentation du système. À partir des noms, il est immédiatement clair quels paramètres sont configurés et à quoi ils servent.
Pour cette raison, la plate-forme Kubernetes dans son ensemble universalise les versions, les mises à jour et la version de l'application.
- Test en direct sans douleur
Le processus de test de la solution a changé. Les développeurs peuvent, à la demande, créer des environnements identiques à ceux des produits pour des tests automatisés. De plus, les journaux généraux du fonctionnement de l'application et du fonctionnement de Kubernetes avec l'application aident à rechercher les problèmes et à trouver les erreurs encore plus rapidement.
Ce que nécessitera une transition commerciale vers Kubernetes
Kubernetes lui-même ne sera qu'une petite partie de votre nouveau système. Vous devez être prêt à ce que Kubernetes, en tant qu'outil de normalisation de l'ensemble du cycle de développement, de mise à jour et de publication des applications, entraîne un changement de tout au moment de la transition: architecture logicielle, processus de développement et maintenance de l'infrastructure.
- Architecture de la solution
Du point de vue du produit, la transition n'est possible que si le système est implémenté ou mis à niveau vers une architecture de microservices basée sur des services qui peuvent être conditionnés dans des conteneurs (services sans état). - Processus de développement
Du point de vue du processus de développement, la transition implique principalement un changement de pensée. Toute amélioration de la situation et «béquilles» ajoutées au dernier moment sont complètement exclues. Un développeur de solutions informatiques ne peut travailler que comme une seule équipe, ce qui crée initialement un produit décomposable testé, pris en charge, pris en charge et conditionné. Tout doit être construit logiquement de la première ligne de code à l'opération. - Processus de mise à jour
Même au stade du développement de l'architecture de l'application, vous devez réfléchir à la façon de mettre à jour la solution sans s'arrêter. Et comprenez immédiatement comment vous allez mettre à jour la base de données, l'API, comment il est logique de prendre en charge plusieurs versions de l'application, en tenant compte du fait que les gens travaillent avec le système pendant la mise à jour et qu'ils peuvent tomber dans différentes versions.
Et une autre façon de penser est liée au fait que lors du passage à Kubernetes, l'infrastructure commence à fonctionner en mode lecture seule, et pour mettre à jour le système, vous devez créer de nouvelles versions des images d'application et dire à Kubernetes d'utiliser la nouvelle version, et elle désactivera plus tard l'ancienne version et se supprimera.
De sorte que les améliorations du système et les changements dans la technologie de travail ne peuvent être évités. Le déménagement ne sera pas rapide. Mais vous ne devrez changer le paradigme qu'une seule fois.
Affaire. Comment nous avons transféré le système de microservices à Kubernetes
Nous opérons dans un environnement de produit une solution très chargée basée sur une architecture de microservices, qui transmet plus de 300 000 transactions par jour, et aux heures de pointe - 60 à 80 000 par heure. Nous mettons régulièrement à jour le produit, il existe également des versions plus urgentes qui nécessitaient auparavant de suspendre le système ou une partie de ses fonctionnalités pendant un certain temps.
Nous sommes entrés dans l'environnement de l'épicerie sans K8S, mais nous avons d'abord développé le système avec un œil. Il a fallu 6 semaines pour traduire la solution en Kubernetes. Nous avons évolué dans les directions suivantes:
1) Configuration du pipeline de déploiement
a. Configuration du pipeline pour l'assemblage continu, les tests et la mise à jour des applications (CI / CD) dans les environnements de test.
b. Mettre en place des mises à jour continues dans un environnement industriel.
c. Préparation et configuration de l'environnement au plus près de l'environnement industriel (préprod). Nous avons déployé et testé le cluster à côté des machines virtuelles actuelles.
d. Développement d'un plan de migration vers un environnement industriel.
Donc, tout semble être simple, nous avons un pipeline CI / CD pour tous les environnements et vous pouvez changer, mais c'est trop tôt!
2) Sélection de la configuration du cluster
Nous avons passé quelques semaines à sélectionner la configuration la plus stable des composants et des versions du cluster Kubernetes: système d'exploitation + Docker + Kubernetes.
Nous avons testé 3 configurations différentes de systèmes d'exploitation (Ubuntu, CentOS, Oracle Linux dernières versions). Sur chaque système d'exploitation, nous avons vérifié 2 versions différentes de Docker et Kubernetes - celle qui était livrée dans les dernières versions des packages de système d'exploitation standard et la dernière version du fabricant. En conséquence, les configurations de la distribution standard d'Oracle Linux ont montré la plus grande stabilité, et nous nous sommes installés sur elles.
3) Configuration des paramètres du conteneur
Nous avons passé un peu plus de temps à régler les paramètres du conteneur - nous avons configuré les exigences de mémoire, de disque et de processus.
Et seulement après avoir fait tout cela et testé divers paramètres du fonctionnement du système (stabilité, tolérance aux pannes, etc.) dans le préprode sous des charges proches de celles du combat, et que le système a fonctionné de manière stable, nous sommes passés à l'étape finale - la migration.
Ensuite, tout était simple.
Jour C. Migration
Pour la migration de combat, nous avons choisi le temps avec la charge système minimale: le nombre minimum d'utilisateurs et l'absence d'une charge augmentée selon le planning de fonctionnement interne des algorithmes système.
Le temps d'arrêt du système était d'environ une heure et n'a pratiquement pas affecté les utilisateurs. La migration elle-même consistait à basculer les utilisateurs d'un système à un autre et à constater que tout se passait bien.
La vie avec Kubernetes
Maintenant, le processus de mise à jour n'affecte pas les performances du système, il peut être effectué à tout moment qui convient aux développeurs et se présente comme suit:
- Les développeurs ont fait une révision, l'ont testée, ont envoyé le code à la publication.
- Le code a été automatiquement assemblé, empaqueté dans des images de docker et publié dans un référentiel de docker privé.
- Kubernetes lève automatiquement de nouvelles versions de services, vérifie que les services fonctionnent correctement, permute les utilisateurs à utiliser de nouvelles versions de services, arrête le travail des anciennes versions et les supprime du cluster. La mise à jour a eu lieu.
Résumant notre expérience
Vous avez besoin de Kubernetes si:
- Une haute disponibilité du système est requise.
- Le système évolue de manière dynamique et vous devez apporter des modifications à l'environnement du produit les yeux fermés.
- Vous souhaitez travailler en équipe unique, du code à l'environnement du produit.
- Vous créez un système dynamique et évolutif que vous opérerez pendant des années.
Kubernetes est «cher», car entrer dans la technologie nécessitera:
- Étude par des développeurs de technologies connexes.
- Examen des processus de conception, de développement, de déploiement, de test et de gestion de l'environnement.
- Expérience dans le fonctionnement de Kubernetes lui-même: vous devez maintenant surveiller non seulement votre système, mais aussi les services d'application Kubernetes.
Remboursez Kubernetes très rapidement:
- La procédure de mise à jour du système est beaucoup plus simple et plus rapide. Les développeurs sont libérés de tout un bloc de travail.
- Chaque nouveau spécialiste entrera déjà dans le projet sur rails.
- Le convoyeur sera transparent et automatisé.
- L'expérience sera répétée par votre équipe pour d'autres systèmes.
- Vous mettrez à jour le système sans le mettre hors service, ce qui signifie que vous n'arrêterez pas l'activité.
PS Conseils pratiques: divisez l'entrée de la technologie en deux étapes: développer un système avec la bonne architecture de microservices et le déplacer sous le contrôle de K8S. Ainsi, la transition sous Kubernetes ne se transformera pas en refactoring global.