Fin mai a tenu une réunion en ligne sur le sujet . Nous avons parlé des conteneurs, de Kubernetes et de l'orchestration en principe, des critères de choix de l'infrastructure et bien plus encore. Les participants ont partagé des cas issus de leur propre pratique.
Membres:
- Evgeniy Potapov, PDG d'ITSumma. Plus de la moitié de ses clients sont déjà en train de migrer ou souhaitent passer à Kubernetes.
- Dmitri Stolyarov, directeur technique de "Flant". Possède plus de 10 ans d’expérience dans le domaine des systèmes de conteneurs.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, ex-RAO UES. Il a promis de parler des cas de l'entreprise « sanglante ».
- Andrey Fedorovsky, directeur technique de « News360.com »Après avoir racheté l'entreprise par un autre acteur, il est responsable d'un certain nombre de projets et d'infrastructures ML et IA.
- Ivan Kruglov, ingénieur système, ex-Booking.com.La même personne qui a fait beaucoup de choses avec Kubernetes de ses propres mains.
Sujets:
- Points de vue des participants sur les conteneurs et l'orchestration (Docker, Kubernetes, etc.) ; ce qui a été essayé en pratique ou analysé.
- Cas : L'entreprise élabore un plan de développement des infrastructures depuis des années. Comment est prise la décision de construire (ou de migrer l'infrastructure actuelle) vers des conteneurs et Kuber ou non ?
- Problèmes dans le monde cloud natif, ce qui manque, imaginons ce qui se passera demain.
Une discussion intéressante s'est ensuivie, les opinions des participants étaient si différentes et ont suscité tellement de commentaires que je souhaite les partager avec vous. Manger , et ci-dessous un résumé de la discussion.
Kubernetes est-il déjà un standard ou un excellent marketing ?
«Nous y sommes arrivés (Kubernetes. - NDLR) alors que personne n'en était encore au courant. Nous sommes venus vers lui même lorsqu'il n'était pas là. Nous le voulions avant" - Dmitri Stoliarov
Photo de Reddit.com
Il y a 5 à 10 ans, il existait un grand nombre d'outils et il n'existait pas de norme unique. Tous les six mois, un nouveau produit apparaissait, voire plusieurs. D'abord Vagrant, puis Salt, Chef, Puppet,... « et vous reconstruisez votre infrastructure tous les six mois. Vous avez cinq administrateurs constamment occupés à réécrire les configurations », se souvient Andrey Fedorovsky. Il estime que Docker et Kubernetes ont « évincé » le reste. Docker est devenu un standard au cours des cinq dernières années, Kubernetes au cours des deux dernières années. Et c'est bon pour l'industrie..
Dmitry Stolyarov et son équipe adorent Kuber. Ils voulaient un tel outil avant son apparition et y sont parvenus alors que personne n'en connaissait l'existence. Actuellement, pour des raisons de commodité, ils n'acceptent pas un client s'ils comprennent qu'ils n'implémenteront pas Kubernetes avec lui. Dans le même temps, selon Dmitry, l’entreprise a « de nombreuses réussites gigantesques dans la reconstruction de ce terrible héritage ».
Kubernetes n'est pas seulement une orchestration de conteneurs, c'est un système de gestion de configuration avec une API développée, un composant réseau, un équilibrage L3 et des contrôleurs d'entrée, ce qui rend relativement facile la gestion des ressources, la mise à l'échelle et l'abstraction des couches inférieures de l'infrastructure.
Malheureusement, dans notre vie, nous devons tout payer. Et cette taxe est importante, surtout si l'on parle de la transition vers Kubernetes d'une entreprise dotée d'une infrastructure développée, comme le estime Ivan Kruglov. Il pouvait travailler librement aussi bien dans une entreprise dotée d'une infrastructure traditionnelle qu'avec Kuber. L'essentiel est de comprendre les caractéristiques de l'entreprise et du marché. Mais, par exemple, pour Evgeny Potapov, qui généraliserait Kubernetes à n'importe quel outil d'orchestration de conteneurs, une telle question ne se pose pas.
Evgeniy 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. A cette époque, le débat se poursuivait et de nouveaux outils apparaissaient pour prendre en charge la POO. Les microservices sont ensuite apparus comme un moyen de s’éloigner du concept monolithique. Cela a conduit à l’émergence de conteneurs et d’outils de gestion de conteneurs. "Je pense que nous arriverons bientôt à un moment où il ne sera plus question de savoir si cela vaut la peine d'écrire une petite application de microservice, elle sera écrite par défaut comme un microservice", estime-t-il. De même, Docker et Kubernetes deviendront à terme la solution standard sans qu'il soit nécessaire de choisir.
Le problème des bases de données chez les apatrides
Photo par
De nos jours, il existe de nombreuses recettes pour exécuter des bases de données dans Kubernetes. Même comment séparer la partie qui fonctionne avec le disque d'E/S de, conditionnellement, la partie application de la base de données. Est-il possible qu'à l'avenir les bases de données changent tellement qu'elles soient livrées dans une boîte, où une partie sera orchestrée via Docker et Kubernetes, et dans une autre partie de l'infrastructure, via un logiciel séparé, la partie stockage sera fournie ? Les bases changeront-elles en tant que produit ?
Cette description est similaire à la gestion des 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 Andrey. Le taux de réussite du cache dans les bases de données normales reste à 99 %. Si un travailleur tombe en panne, un nouveau est lancé et le cache « se réchauffe » à partir de zéro. Jusqu'à ce que le cache soit réchauffé, le travailleur fonctionne lentement, ce qui signifie qu'il ne peut pas être chargé avec la charge utilisateur. Tant qu'il n'y a pas de charge utilisateur, le cache ne se réchauffe pas. C'est un cercle vicieux.
Dmitry n'est fondamentalement pas d'accord : les quorums et le partage résolvent le problème. Mais Andrey insiste sur le fait que la solution ne convient pas à tout le monde. Dans certaines situations, le quorum convient, mais il impose une charge supplémentaire au réseau. Une base de données NoSQL ne convient pas dans tous les cas.
Les participants à la rencontre étaient divisés en deux camps.
Denis et Andrey affirment que tout ce qui est écrit sur le disque (bases de données, etc.) est impossible à réaliser dans l'écosystème Kuber actuel. 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 de données cloud natives modernes comme MongoDB et Cassandra, ou les files d'attente de messages comme Kafka ou RabbitMQ, nécessitent des magasins de données persistants en dehors de Kubernetes.
Evgeniy objecte : « Les bases de Kubera sont une blessure quasi-russe, ou quasi-entreprise, qui est associée au fait qu'il n'y a pas d'adoption du cloud en Russie. » Les petites ou moyennes entreprises occidentales sont Cloud. Les bases de données Amazon RDS sont plus faciles à utiliser que de bricoler vous-même Kubernetes. En Russie, ils utilisent Kuber « sur site » et y transfèrent des bases lorsqu'ils tentent de se débarrasser du zoo.
Dmitry n'est pas non plus d'accord avec l'affirmation selon laquelle aucune base de données ne peut être conservée dans Kubernetes : « La base est différente de la base. Et si vous poussez une base de données relationnelle géante, alors en aucun cas. Si vous poussez quelque chose de petit et de natif du cloud, qui est mentalement préparé à une vie semi-éphémère, tout ira bien. Dmitry a également mentionné que les outils de gestion de bases de données ne sont prêts ni pour Docker ni pour Kuber, ce qui entraîne de grandes difficultés.
Ivan, à son tour, est sûr que même si nous faisons abstraction des concepts d'état et d'apatride, l'écosystème de solutions d'entreprise dans Kubernetes n'est pas encore prêt. Avec Kuber, il est difficile de respecter les exigences législatives et réglementaires. Par exemple, il est impossible de créer une solution de fourniture d'identité exigeant des garanties strictes d'identification des serveurs, jusqu'au matériel inséré dans les serveurs. Ce domaine se développe, mais il n’y a pas encore de solution.
Les participants n’étant pas parvenus à se mettre d’accord, aucune conclusion ne sera tirée dans cette partie. Donnons quelques exemples pratiques.
Cas 1. Cybersécurité d’un « méga-régulateur » avec des bases en dehors de Kubera
Dans le cas d’un système de cybersécurité développé, l’utilisation de conteneurs et d’orchestration permet de lutter contre les attaques et les intrusions. Par exemple, dans un méga-régulateur, Denis et son équipe ont mis en œuvre une combinaison d'un orchestrateur avec un service SIEM formé 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 de placement ou d'invasion d'un virus ransomware, celui-ci, via l'orchestrateur, récupère les conteneurs contenant les applications plus rapidement qu'ils ne sont infectés ou plus rapidement que l'attaquant ne les attaque.
Cas 2. Migration partielle des bases de données Booking.com vers Kubernetes
Sur Booking.com, la base de données principale est MySQL avec réplication asynchrone - il existe un maître et toute une hiérarchie d'esclaves. Au moment où Ivan a quitté l'entreprise, un projet avait été lancé pour transférer des esclaves qui pourraient être « abattus » avec certains dégâts.
En plus de la base principale, il existe une installation Cassandra avec une orchestration auto-écrite, qui a été écrite avant même que Kuber n'entre dans le grand public. Il n'y a aucun problème à cet égard, mais cela persiste sur les SSD locaux. Le stockage à distance, même au sein du même centre de données, n'est pas utilisé en raison du problème de latence élevée.
La troisième classe de bases de données est le service de recherche Booking.com, où chaque nœud de service est une base de données. Les tentatives de transfert du service de recherche vers Kuber ont échoué, car chaque nœud représente 60 à 80 Go de stockage local, ce qui est difficile à « soulever » et à « réchauffer ».
En conséquence, 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 de données MySQL a été transférée en deux : uniquement des esclaves, qui n'ont pas peur de se faire « tirer dessus ». Cassandra s'est parfaitement installée.
La sélection de l'infrastructure comme une tâche sans solution générale
Photo par
Disons que nous avons une nouvelle entreprise ou une entreprise dont une partie de l'infrastructure est construite à l'ancienne. Il construit un plan de développement des infrastructures sur des années. Comment est prise la décision de construire ou non une infrastructure sur des conteneurs et Kuber ?
Les entreprises qui se battent pour les nanosecondes sont exclues du débat. Un conservatisme sain est payant en termes de fiabilité, mais certaines entreprises devraient encore envisager de nouvelles approches.
Ivan : « Je créerais certainement une entreprise sur le cloud maintenant, simplement parce que c'est plus rapide », mais pas nécessairement moins cher. Avec le développement du capital-risque, les startups n'ont pas de gros problèmes d'argent et la tâche principale est de conquérir le marché.
Ivan est d'avis que le développement de l'infrastructure actuelle est un critère de sélection. S’il y a eu un investissement sérieux dans le passé et que cela fonctionne, cela ne sert à rien de le refaire. 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 alors logique d'envisager une infrastructure distribuée.
L'impôt devra être payé dans tous les cas, et Ivan paiera celui qui lui permettra de payer moins à l'avenir. "Parce que du simple fait que je voyage dans un train que d'autres conduisent, je voyagerai beaucoup plus loin que si je prenais place dans un autre train, dans lequel je dois moi-même faire le plein de carburant.« dit Ivan. Lorsque l'entreprise est nouvelle et que les exigences de latence sont de plusieurs dizaines de millisecondes, Ivan se tournera alors vers les « opérateurs » dans lesquels les bases de données classiques sont aujourd'hui « enveloppées ». Ils lèvent une chaîne de réplication, qui bascule elle-même en cas de basculement, etc...
Pour une petite entreprise disposant de quelques serveurs, Kubera n'a aucun sens », déclare Andrey. Mais s’il envisage de croître jusqu’à des centaines de serveurs ou plus, il a alors besoin d’automatisation et d’un système de gestion des ressources. 90 % des cas en valent la peine. De plus, quel que soit le niveau de charge et de ressources. Il est logique que tout le monde, des startups aux grandes entreprises comptant des millions de personnes, se tourne progressivement vers les produits d’orchestration de conteneurs. "Oui, c'est vraiment l'avenir", en est sûr Andrey.
Denis a souligné deux critères principaux - évolutivité et stabilité de fonctionnement. Il sélectionnera les outils les mieux adaptés à la tâche. « Il pourrait s'agir d'un noname assemblé sur vos genoux, et il contient Nutanix Community Edition. Cela pourrait être une deuxième ligne sous la forme d'une application sur Kuber avec une base de données sur le backend, qui serait répliquée et aurait spécifié des paramètres RTO et RPO" (objectifs de temps/point de récupération - prim).
Evgeniy a identifié un éventuel problème avec le personnel. À l’heure actuelle, il n’existe pas beaucoup de spécialistes hautement qualifiés sur le marché qui comprennent les « tripes ». En effet, si la technologie choisie est ancienne, alors il est difficile d'embaucher quelqu'un d'autre que des personnes d'âge moyen qui s'ennuient et sont fatiguées de la vie. Bien que 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 Cloud Public avec des bases de données en Amazon RDS ou « on premise » avec des bases de données en Kubernetes, alors malgré quelques défauts, Amazon RDS est devenu le choix des participants.
Puisque la majorité des auditeurs de meetup ne sont pas issus de l’entreprise « sanglante », alors les solutions distribuées sont ce vers quoi nous devrions nous efforcer. Les systèmes de stockage de données doivent être distribués, fiables et créer une latence mesurée en unités de millisecondes, des dizaines au maximum», a résumé Andreï.
Évaluation de l'utilisation de Kubernetes
L'auditeur Anton Zhbankov a posé une question piège aux défenseurs de Kubernetes : comment avez-vous sélectionné et mené une étude de faisabilité ? Pourquoi Kubernetes, pourquoi pas les machines virtuelles par exemple ?
Photo par
Dmitry et Ivan y ont répondu. Dans les deux cas, par essais et erreurs, une séquence de décisions a été prise, à la suite de laquelle les deux participants sont arrivés à Kubernetes. Désormais, les entreprises commencent à développer de manière indépendante des logiciels qu'il est logique de transférer vers Kuber. Nous ne parlons pas de systèmes tiers classiques, comme 1C. Kubernetes est utile lorsque les développeurs ont besoin de publier rapidement des versions, avec une amélioration continue continue.
L'équipe d'Andrey a tenté de créer un cluster évolutif basé sur des machines virtuelles. Les nœuds tombaient comme des dominos, ce qui conduisait parfois à l'effondrement du cluster. « Théoriquement, on peut le terminer et le soutenir avec ses mains, mais c’est fastidieux. Et s’il existe sur le marché une solution qui vous permet de travailler hors des sentiers battus, nous l’accepterons volontiers. Et en conséquence, nous avons changé », explique Andrey.
Il existe des normes pour de telles analyses et calculs, mais personne ne peut dire quelle est leur précision sur le matériel réel en fonctionnement. Pour les calculs, il est également important de comprendre chaque outil et écosystème, mais cela n’est pas possible.
Ce qui nous attend
Photo par
À mesure que la technologie évolue, de plus en plus de pièces disparates apparaissent, puis une transition de phase se produit : un fournisseur apparaît qui a tué suffisamment de pâte pour que tout soit réuni dans un seul outil.
Pensez-vous qu’il viendra un jour où il y aura un outil comme Ubuntu pour le monde Linux ? Peut-être qu'un seul outil de conteneurisation et d'orchestration inclura Kuber. Cela facilitera la création de cloud sur site.
La réponse a été donnée par Ivan : "Google construit actuellement Anthos - il s'agit de leur offre packagée qui déploie le cloud et inclut Kuber, Service Mesh, la surveillance - tout le matériel nécessaire aux microservices sur site." Nous sommes presque dans le futur. »
Denis a également mentionné Nutanix et VMWare avec le produit vRealize Suite, qui peuvent effectuer une tâche similaire sans conteneurisation.
Dmitry a partagé son opinion selon laquelle la réduction de la « souffrance » et la réduction des impôts sont deux domaines dans lesquels nous pouvons nous attendre à des améliorations.
Pour résumer la discussion, nous soulignons les problèmes suivants des infrastructures modernes :
- Trois participants ont immédiatement identifié un problème avec stateful.
- Divers problèmes de prise en charge de la sécurité, notamment la possibilité que Docker se retrouve avec plusieurs versions de Python, de serveurs d'applications et de composants.
Dépenses excessives, qu'il est préférable de discuter lors d'une réunion séparée.
Un défi d’apprentissage car l’orchestration est un écosystème complexe.
Un problème courant dans l’industrie est la mauvaise utilisation des outils.Le reste des conclusions dépend de vous. On a toujours le sentiment qu’il n’est pas facile pour la combinaison Docker+Kubernetes de devenir un élément « central » du système. Par exemple, les systèmes d’exploitation sont d’abord installés sur le matériel, ce qui n’est pas le cas des conteneurs et de l’orchestration. Peut-être qu’à l’avenir, les systèmes d’exploitation et les conteneurs fusionneront avec les logiciels de gestion cloud.
Photo parJ'en profite pour saluer ma mère et vous rappeler que nous avons un groupe Facebook , canaliser avec des publications intéressantes de divers blogs technologiques. Et ma chaîne , où je parle de la gestion du développement dans les entreprises de produits.
Source: habr.com