À la fin mai avons organisé un meetup en ligne sur le thème . Nous avons discuté des conteneurs, de Kubernetes et de l'orchestration en général, des critères de choix d'infrastructure, et bien d'autres sujets. Les participants ont partagé des cas pratiques.
Participants :
- Evgueni Potapov, CEO de «ITSumma». Plus de la moitié de ses clients sont soit déjà en train de migrer, soit souhaitent migrer vers Kubernetes.
- Dmitri Stoliarov, CTO de «Flant». Possède plus de 10 ans d'expérience dans les systèmes de conteneurs.
- Denis Remtchouk (aka Eric Oldmann), COO d'argotech.io, ex-RAO EES. Il a promis de partager des cas dans le secteur «sanguinaire» de l'entreprise.
- Andrei Fedorovski, CTO de «News360.com»Après l'acquisition de la société par un autre acteur, il est responsable de plusieurs projets en ML et AI ainsi que de l'infrastructure.
- Ivan Krouglov, ingénieur système, ex-Booking.com.C'est la personne qui a réalisé beaucoup de choses avec Kubernetes de ses propres mains.
Thèmes :
- Les insights des participants sur les conteneurs et l'orchestration (Docker, Kubernetes, etc.) ; ce qu'ils ont essayé en pratique ou analysé.
- Cas : L'entreprise élabore un plan de développement de l'infrastructure sur plusieurs années. Comment se prend la décision de construire (ou de migrer l'infrastructure actuelle) sur des conteneurs et Kubernetes ou non ?
- Problématiques dans le monde du cloud-native, ce qui fait défaut, imaginons ensemble ce qui nous attend demain.
Une discussion intéressante s'est engagée, les opinions des participants étaient si variées et ont suscité tant de commentaires qu'il est souhaitable de les partager avec vous. Il y a , et ci-dessous – un résumé de la discussion.
Kubernetes est-il déjà un standard ou un excellent marketing ?
«Nous y sommes (Kubernetes. — Réd.) venus à une époque où personne n'en parlait encore. Nous y sommes arrivés quand il n'existait pas encore. Nous le voulions déjà avant cela» — Dmitri Stoliarov
Photo de Reddit.com
Il y a 5-10 ans, il existait une multitude d'outils, et aucun standard unifié. Un nouveau produit apparaissait tous les six mois, voire plusieurs. Au début Vagrant, puis Salt, Chef, Puppet,… «et tu dois constamment réécrire ta configuration tous les six mois. Tu as cinq admins qui sont toujours occupés à réécrire les configurations» — se remémore Andrei Fedorovski. Il considère que Docker et Kubernetes ont «écrasé» les autres. Docker est devenu un standard au cours des cinq dernières années, Kubernetes au cours des deux dernières. Et c'est bon pour l'industrie..
Dmitry Stolyarov et son équipe adorent Kubernetes. Ils ont souhaité cet outil avant même son apparition, et y sont parvenus alors que personne ne le connaissait encore. À l'heure actuelle, pour des raisons de commodité, ils n'acceptent pas de clients s'ils comprennent qu'ils ne pourront pas déployer Kubernetes pour eux. Cela dit, selon Dmitry, l'entreprise a « une multitude d'histoires de succès gigantesques sur la transformation de vieux systèmes hérités ».
Kubernetes n'est pas seulement une orchestration de conteneurs, c'est un système de gestion de configuration avec une API développée, des composants de gestion réseau, du load balancing L3 et des contrôleurs Ingress, qui permet de gérer les ressources de manière relativement facile, de se redimensionner et de s'abstraire des couches sous-jacentes de l'infrastructure.
Malheureusement, dans notre vie, tout a un coût. Et cette taxe est élevée, surtout lorsqu'il s'agit de passer à Kubernetes pour une entreprise avec une infrastructure développée, estime Ivan Kruglov. Il pourrait travailler aussi bien dans une entreprise avec une infrastructure traditionnelle que sur Kubernetes. L'essentiel est de comprendre les particularités de l'entreprise et du marché. Mais, par exemple, pour Evgeny Potapov, qui généraliserait Kubernetes à tout outil d'orchestration de conteneurs, cette question ne se pose pas.
Evgeny a fait une analogie avec la situation des années 1990, lorsque la programmation orientée objet est apparue comme un moyen de programmer des applications complexes. À ce moment-là, les débats ne cessaient pas et de nouveaux outils apparaissaient pour soutenir la POO. Ensuite, les microservices sont apparus comme un moyen de se détourner de la conception monolithique. Cela a, à son tour, conduit à l'émergence de conteneurs et d'outils de gestion de ceux-ci. « Je pense que nous arriverons bientôt à un moment où il ne sera plus question de savoir s'il faut écrire une petite application de manière microservice, cela sera fait par défaut sous forme de microservice », dit-il. De même, Docker et Kubernetes deviendront avec le temps des solutions standard sans nécessiter de choix.
Le problème des bases de données est stateless.
Photo par
De nos jours, il existe de nombreuses recettes pour lancer des bases de données dans Kubernetes. Même pour séparer la partie traitant avec le disque I/O de, disons, la partie applicative de la base. Est-il possible qu'à l'avenir, les bases de données soient modifiées au point d'être livrées dans une boîte où une partie serait orchestrée via Docker et Kubernetes, et dans l'autre partie de l'infrastructure, une partie de stockage serait fournie par un logiciel distinct ? Les bases vont-elles se transformer en produit ?
Cette description ressemble à une gestion de files d'attente, mais les exigences en matière de fiabilité et de synchronisation des informations dans les bases de données traditionnelles sont beaucoup plus élevées, estime Andreï. Le taux de réussite du cache dans des bases normales est maintenu à environ 99 %. Si un worker échoue, un nouveau est lancé, et le cache est « réchauffé » depuis le début. Tant que le cache n'est pas réchauffé, le worker fonctionne lentement, donc il ne peut pas supporter une charge utilisateur. Tant qu'il n'y a pas de charge utilisateur, le cache ne se réchauffe pas. C'est un cercle vicieux.
Dmitri n'est pas d'accord : les quorum et le sharding résolvent le problème. Mais Andreï insiste sur le fait que cette solution ne convient pas à tout le monde. Dans certaines situations, un quorum peut convenir, mais cela impose une charge supplémentaire sur le réseau. Une base NoSQL ne convient pas dans tous les cas.
Les participants à la rencontre se sont divisés en deux camps.
Denis et Andreï soutiennent que tout ce qui écrit sur disque - bases et autres - est impossible à réaliser dans l'écosystème actuel de Kubernetes. Il est impossible de maintenir l'intégrité et la cohérence des données de production dans Kubernetes. C'est une caractéristique fondamentale. Solution : infrastructure hybride.
Même les bases cloud native modernes, telles que MongoDB et Cassandra, ou les systèmes de messagerie comme Kafka ou RabbitMQ, nécessitent un stockage de données externe à Kubernetes.
Evgueni objecte : « Les bases dans Kubernetes sont une préoccupation pour l'espace post-soviétique ou semi-entrepreneurial, liée au manque d'adoption du cloud en Russie. Les petites ou moyennes entreprises en Occident utilisent le cloud. Utiliser les bases Amazon RDS est plus facile que de gérer Kubernetes soi-même. En Russie, on utilise Kubernetes 'on-premise' et on migre des bases lorsque l'on essaie de se débarrasser de leur hétérogénéité. »
Dmitri n'est pas non plus d'accord avec l'affirmation selon laquelle aucune base ne peut être maintenue dans Kubernetes : « Il y a différentes bases. Et si l'on essaie d'ajouter une énorme base de données relationnelle, alors il ne faut absolument pas le faire. Si l'on intègre quelque chose de petit et cloud native, qui est moralement prêt à une vie semi-éphémère, tout ira bien. » Dmitri a également mentionné que les outils de gestion des bases ne sont prêts ni pour Docker ni pour Kubernetes, ce qui entraîne de grandes difficultés.
Ivan, pour sa part, est convaincu que même en s'abstrayant des notions de stateful et stateless, l'écosystème des solutions d'entreprise dans Kubernetes n'est pas encore prêt. Il est difficile de respecter les exigences des législations et des régulateurs avec Kuber. Par exemple, il est impossible de créer une solution d'identité qui nécessite des garanties strictes d'identification du serveur, jusqu'au matériel lui-même. Ce domaine est en développement, mais il n'existe pas de solution pour le moment.
Les participants n'ont pas réussi à se mettre d'accord, il n'y aura donc pas de conclusions à ce sujet. À la place, donnons quelques exemples pratiques.
Cas 1. Cybersécurité du « mégarégulateur » avec des bases de données hors de Kuber
Dans le cas d'un système de cybersécurité avancé, l'utilisation de conteneurs et d'orchestration permet de se défendre contre les attaques et les intrusions. Par exemple, dans un mégarégulateur, Denis et son équipe ont implémenté une combinaison d'orchestrateur avec un service SIEM entraîné, qui analyse les journaux en temps réel et détermine le processus d'attaque, de piratage ou de panne. En cas d'attaque, de tentative d'intrusion ou d'attaque par ransomware, il déploie via l'orchestrateur des conteneurs avec des applications plus rapidement qu'ils ne peuvent être infectés ou plus rapidement qu'ils ne sont attaqués par l'agresseur.
Cas 2. Migration partielle des bases de données de Booking.com vers Kubernetes
Chez Booking.com, la base de données principale est MySQL avec réplication asynchrone — il y a un master et toute une hiérarchie de slaves. Au moment du départ d'Ivan de l'entreprise, un projet de transfert des slaves, qui peuvent être « abattus » avec un certain dommage, avait été lancé.
En plus de la base principale, il existe une installation Cassandra avec une orchestration sur mesure, qui a été développée avant que Kuber ne devienne populaire. Il n'y a pas de problèmes à ce niveau, mais elle utilise un stockage persistant sur des SSD locaux. Aucun stockage distant, même au sein d'un même centre de données, n'est utilisé en raison de problèmes de latence élevée.
La troisième classe de bases de données est le service de recherche de Booking.com, où chaque nœud du service représente une base de données. Les tentatives de transférer le service de recherche vers Kuber n'ont pas abouti, car chaque nœud possède 60 à 80 Go de stockage local, ce qui est difficile à « démarrer » et à « réchauffer ».
En fin de compte, le moteur de recherche n'a pas été transféré vers Kubernetes, et Ivan ne pense pas qu'il y aura de nouvelles tentatives dans un avenir proche. La base MySQL a été transférée à moitié : seuls les slaves, qui peuvent être « abattus » sans trop de risque. Cassandra s'est parfaitement intégrée.
Choix de l'infrastructure comme une question sans réponse universelle
Photo par
Supposons que nous ayons une nouvelle entreprise ou une entreprise dont une partie de l'infrastructure a été construite à l'ancienne. Un plan de développement de l'infrastructure est conçu pour des années. Comment décide-t-on de construire l'infrastructure sur des conteneurs et Kubernetes ou non ?
Les entreprises qui se battent pour des nanosecondes sont exclues de la discussion. Un conservatisme sain est rentable pour des raisons de fiabilité, mais pourtant, certaines entreprises devraient envisager de nouvelles approches.
Ivan : « Je commencerais sans aucun doute une entreprise dans le cloud actuellement, simplement parce que c'est plus rapide », même si ce n'est pas nécessairement moins cher. Avec le développement du capital-risque, les startups n'ont pas de gros problèmes d'argent, et le principal objectif est de conquérir le marché.
Ivan est d'avis que le niveau de développement de l'infrastructure actuelle est un critère de choix. S'il y a eu des investissements importants dans le passé et que cela fonctionne, il n'y a pas de raison de tout refaire. En revanche, si l'infrastructure n'est pas développée et qu'il y a des problèmes avec les outils, la sécurité et la surveillance, il est judicieux de se pencher sur une infrastructure distribuée.
Il faudra de toute façon payer des impôts, et Ivan paierait celui qui lui permettrait de payer moins à l'avenir. «Parce que simplement le fait que je sois dans un train conduit par d'autres me permettra d'aller beaucoup plus loin que si je prenais un autre train dans lequel je devrais ajouter du carburant moi-même.» — déclare Ivan. Lorsque l'entreprise est nouvelle et que les exigences en matière de latence sont de l'ordre de dizaines de millisecondes, Ivan se tournerait vers « les opérateurs », chez qui les bases de données classiques sont aujourd'hui « emballées ». Ils établissent une chaîne de réplication qui se commute d'elle-même en cas de failover, etc.
Pour une petite entreprise avec quelques serveurs dans Kubernetes, cela n'a pas de sens, - affirme Andrey. Mais si elle prévoit de croître jusqu'à une centaine de serveurs ou plus, une automatisation et un système de gestion des ressources sont nécessaires. Dans 90 % des cas, les coûts sont justifiés. Cela, peu importe le niveau de charge et les ressources. Pour tous, des startups aux grandes entreprises avec une audience de millions, il est sensé de regarder progressivement vers des produits d'orchestration de conteneurs. « Oui, c'est vraiment l'avenir », affirme Andrey.
Denis a identifié deux critères principaux — évolutivité et résilience des opérations. Il choisira les outils les plus adaptés à cette tâche. « Cela peut être une solution artisanalement assemblée, et dessus Nutanix Community Edition. Cela peut être une deuxième ligne sous forme d'application sur Kuber avec une base de données en arrière-plan, qui est répliquée et a des paramètres RTO et RPO définis » (objectifs de temps de récupération / point de récupération — ex.).
Evgueni a souligné un problème potentiel en matière de personnel. Actuellement, il n'y a pas beaucoup de spécialistes de haut niveau sur le marché qui comprennent « les entrailles ». En effet, si la technologie choisie est ancienne, il est difficile d'embaucher quelqu'un d'autre que des personnes plus âgées, fatiguées de la vie. Cependant, d'autres participants estiment qu'il s'agit d'une question de formation du personnel.
Si l'on pose la question du choix : lancer une petite entreprise dans le Public Cloud avec des bases dans Amazon RDS ou « sur site » avec des bases dans Kubernetes, alors malgré certains inconvénients, le choix des participants a été Amazon RDS.
Comme la plupart des auditeurs de la rencontre ne proviennent pas du « secteur sanglant » de l'entreprise, les solutions distribuées sont ce vers quoi il faut tendre. Les systèmes de stockage de données doivent être distribués, fiables, et créer une latence mesurée en millisecondes, au maximum en dizaines., — a résumé Andreï.
Évaluation de l'utilisation de Kubernetes
L'auditeur Anton Jbankov a posé une question piégeuse aux partisans de Kubernetes : comment avez-vous choisi et réalisé l'analyse coûts-avantages ? Pourquoi Kubernetes, pourquoi pas des machines virtuelles, par exemple ?
Photo par
Dmitri et Ivan ont répondu. Dans les deux cas, par essais et erreurs, une séquence de décisions a été prise, ce qui a conduit les deux participants à choisir Kubernetes. Actuellement, les entreprises commencent à développer elles-mêmes des logiciels qui ont un sens à transférer dans Kuber. Il ne s'agit pas de systèmes tiers classiques, comme 1C. Kubernetes aide lorsque les développeurs doivent lancer rapidement des versions, dans le cadre d'une amélioration continue sans interruption.
L'équipe d'Andreï a essayé de créer un cluster évolutif basé sur des machines virtuelles. Les nœuds tombaient comme des dominos, ce qui entraînait parfois la chute du cluster. « Théoriquement, on peut finir et maintenir à la main, mais c'est fastidieux. Et s'il existe une solution sur le marché qui permet de travailler dès la sortie de la boîte, nous y allons avec plaisir. Et c'est finalement ce que nous avons fait », raconte Andreï.
Des normes pour ce type d'analyse et de calcul existent, mais personne ne peut dire à quel point elles sont valables sur du matériel réel en exploitation. Pour ces calculs, il est également crucial de comprendre chaque outil et écosystème, mais cela est impossible.
Ce qui nous attend
Photo par
Lorsque les technologies avancent, de plus en plus de morceaux disparates apparaissent, puis il se produit une transition de phase, un fournisseur apparaît qui a tué suffisamment de « fonds » pour réunir le tout dans un seul outil.
Ne pensez-vous pas qu'il viendra un moment où un outil apparaîtra, tout comme Ubuntu l'a fait pour le monde Linux ? Peut-être qu'un outil unique de conteneurisation et d'orchestration inclura également Kubernetes. Cela rendra facile la construction de clouds on-premise.
Ivan a répondu : « Google construit actuellement Anthos — c'est leur offre groupée qui déploie le cloud et inclut Kubernetes, Service Mesh, la surveillance, — tout le nécessaire pour les microservices en on-premise. Nous sommes presque dans le futur. »
Denis a également mentionné Nutanix et VMWare avec leur produit vRealize Suite, qui peuvent gérer des tâches similaires sans conteneurisation.
Dmitry a partagé son avis selon lequel réduire la « douleur » et diminuer la taxe sont deux axes où nous pouvons attendre des améliorations.
Pour résumer la discussion, identifions les problèmes suivants de l'infrastructure moderne
- Trois participants ont immédiatement souligné le problème des solutions stateful.
- Divers problèmes de support de sécurité, y compris la probabilité que plusieurs versions de Python, de serveurs d'applications et de composants se retrouvent dans Docker.
Une surconsommation, pour laquelle il serait préférable d'organiser une réunion distincte.
Le problème de la formation, car l'orchestration représente un écosystème complexe.
Un problème général dans l'industrie est l'utilisation des outils à des fins non prévues.Les autres conclusions vous appartiennent. Il reste un sentiment que la combinaison Docker + Kubernetes a du mal à devenir la composante « centrale » du système. Par exemple, les systèmes d'exploitation sont installés en premier sur le matériel, ce qui ne peut pas être dit des conteneurs et de l'orchestration. Peut-être qu'à l'avenir, les systèmes d'exploitation et les conteneurs s'intégreront avec le logiciel de gestion cloud.
Photo parProfiter de l'occasion pour passer le bonjour à ma mère, je rappelle que nous avons un groupe Facebook , canal avec des publications intéressantes issues de différents blogs tech. Et mon canal , où je parle de la gestion du développement dans les entreprises de produits.
Source : habr.com
