La société URUS a essayé Kubernetes sous différentes formes : déploiement indépendant sur bare metal, dans Google Cloud, puis a transféré sa plateforme vers le cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin raconte comment ils ont choisi un nouveau fournisseur de cloud et comment ils ont réussi à migrer vers celui-ci en un temps record de deux heures (), administrateur système senior chez URUS.
Que fait l'URUS ?
Il existe de nombreuses façons d’améliorer la qualité de l’environnement urbain, et l’une d’elles consiste à le rendre respectueux de l’environnement. C’est exactement ce sur quoi travaille la société URUS – Smart Digital Services. Ici, ils mettent en œuvre des solutions qui aident les entreprises à surveiller des indicateurs environnementaux importants et à réduire leur impact négatif sur l'environnement. Les capteurs collectent des données sur la composition de l'air, le niveau de bruit et d'autres paramètres, puis les envoient à la plateforme unifiée URUS-Ekomon pour analyse et formulation de recommandations.
Comment fonctionne l'URUS de l'intérieur
Un client typique d’URUS est une entreprise située dans ou à proximité d’une zone résidentielle. Il peut s'agir d'une usine, d'un port, d'un dépôt ferroviaire ou de toute autre installation. Si notre client a déjà reçu un avertissement, a été condamné à une amende pour pollution de l'environnement ou souhaite faire moins de bruit, réduire la quantité d'émissions nocives, il s'adresse à nous et nous lui proposons déjà une solution toute faite pour la surveillance de l'environnement.
Le graphique de surveillance des concentrations de H2S montre les émissions nocturnes régulières d'une usine voisine
Les appareils que nous utilisons chez URUS contiennent plusieurs capteurs qui collectent des informations sur la teneur de certains gaz, les niveaux de bruit et d'autres données pour évaluer la situation environnementale. Le nombre exact de capteurs est toujours déterminé par la tâche spécifique.
Selon les spécificités des mesures, des appareils dotés de capteurs peuvent être situés sur les murs des bâtiments, des poteaux et d'autres endroits arbitraires. Chacun de ces appareils collecte des informations, les regroupe et les envoie à la passerelle de réception de données. Là, nous sauvegardons les données pour un stockage à long terme et les prétraitons pour une analyse ultérieure. L’exemple le plus simple de ce que nous obtenons à la suite d’une analyse est l’indice de qualité de l’air, également connu sous le nom d’IQA.
En parallèle, de nombreux autres services fonctionnent sur notre plateforme, mais ils sont principalement de nature service. Par exemple, le service de notification envoie des notifications aux clients si l'un des paramètres surveillés (par exemple, la teneur en CO2) dépasse la valeur autorisée.
Comment nous stockons les données. L'histoire de Kubernetes sur bare metal
Le projet de surveillance environnementale URUS dispose de plusieurs entrepôts de données. Dans l'un d'entre eux, nous conservons les données « brutes » - celles que nous recevons directement des appareils eux-mêmes. Ce stockage est une bande « magnétique », comme sur les anciennes cassettes, avec un historique de tous les indicateurs. Le deuxième type de stockage est utilisé pour les données prétraitées - données des appareils, enrichies de métadonnées sur les connexions entre les capteurs et les lectures des appareils eux-mêmes, l'affiliation à des organisations, des emplacements, etc. Ces informations vous permettent d'évaluer dynamiquement comment un indicateur particulier a changé au cours d'une certaine période de temps. Nous utilisons le stockage des données « brutes », entre autres, comme sauvegarde et pour restaurer les données prétraitées, si nécessaire.
Lorsque nous cherchions à résoudre notre problème de stockage il y a plusieurs années, nous avions deux choix de plateforme : Kubernetes et OpenStack. Mais comme ce dernier a l’air assez monstrueux (il suffit de regarder son architecture pour s’en convaincre), nous avons opté pour Kubernetes. Un autre argument en sa faveur était le contrôle logiciel relativement simple, la possibilité de couper de manière plus flexible même les nœuds matériels en fonction des ressources.
Parallèlement à la maîtrise de Kubernetes lui-même, nous avons également étudié les moyens de stocker les données, tout en conservant tout notre stockage dans Kubernetes sur notre propre matériel, nous avons acquis une excellente expertise. Tout ce que nous avions alors vécu sur Kubernetes : stockage statefull, système de surveillance, CI/CD. Kubernetes est devenu pour nous une plateforme tout-en-un.
Mais nous voulions travailler avec Kubernetes en tant que service, et non nous engager dans son support et son développement. De plus, nous n’aimions pas combien cela nous coûtait de le maintenir sur du matériel nu, et nous avions constamment besoin de développement ! Par exemple, l'une des premières tâches consistait à intégrer les contrôleurs Kubernetes Ingress dans l'infrastructure réseau de notre organisation. Il s’agit d’une tâche fastidieuse, d’autant plus qu’à cette époque rien n’était prêt pour la gestion programmatique des ressources telles que les enregistrements DNS ou l’attribution d’adresses IP. Plus tard, nous avons commencé à expérimenter le stockage de données externe. Nous n'avons jamais réussi à mettre en œuvre le contrôleur PVC, mais même à ce moment-là, il est devenu clair qu'il s'agissait d'un vaste domaine de travail qui nécessitait des spécialistes dédiés.
Le passage à Google Cloud Platform est une solution temporaire
Nous avons réalisé que cela ne pouvait pas continuer et avons migré nos données du bare metal vers Google Cloud Platform. En fait, à cette époque, il n'y avait pas beaucoup d'options intéressantes pour une entreprise russe : outre Google Cloud Platform, seul Amazon proposait un service similaire, mais nous avons quand même opté pour la solution de Google. Ensuite cela nous a semblé plus rentable économiquement, plus proche de l'Amont, sans compter que Google lui-même est une sorte de PoC Kubernetes en Production.
Le premier problème majeur est apparu à l’horizon à mesure que notre clientèle augmentait. Lorsque nous avons eu besoin de stocker des données personnelles, nous avons été confrontés à un choix : soit nous travaillons avec Google et violons les lois russes, soit nous recherchons une alternative en Fédération de Russie. Le choix, dans l’ensemble, était prévisible. 🙂
Comment nous avons identifié le service cloud idéal
Dès le début de nos recherches, nous savions déjà ce que nous souhaitions obtenir du futur fournisseur de cloud. Quel service recherchions-nous :
- Rapide et flexible. De telle sorte que nous pouvons rapidement ajouter un nouveau nœud ou déployer quelque chose à tout moment.
- Peu coûteux. Nous étions très préoccupés par la question financière, car nos ressources étaient limitées. Nous savions déjà que nous voulions travailler avec Kubernetes, et il s'agissait désormais de minimiser son coût afin d'augmenter ou du moins de maintenir l'efficacité de l'utilisation de cette solution.
- automatique. Nous avions prévu de travailler avec le service via l'API, sans gestionnaires ni appels téléphoniques ni situations où nous devons lever manuellement plusieurs dizaines de nœuds en mode d'urgence. Étant donné que la plupart de nos processus sont automatisés, nous attendions la même chose du service cloud.
- Avec des serveurs en Fédération de Russie. Bien entendu, nous avions prévu de respecter la législation russe et ce même 152-FZ.
À cette époque, il y avait peu de fournisseurs Kubernetes aaS en Russie, et lors du choix d'un fournisseur, il était important pour nous de ne pas compromettre nos priorités. L'équipe Mail.ru Cloud Solutions, avec laquelle nous avons commencé à travailler et collaborons toujours, nous a fourni un service entièrement automatisé, avec prise en charge API et un panneau de contrôle pratique qui inclut Horizon - avec lui, nous pourrions rapidement augmenter un nombre arbitraire de nœuds.
Comment nous avons réussi à migrer vers MCS en deux heures
Dans de telles démarches, de nombreuses entreprises sont confrontées à des difficultés et à des revers, mais dans notre cas, il n’y en a eu aucun. Nous avons eu de la chance : comme nous travaillions déjà sur Kubernetes avant le début de la migration, nous avons simplement corrigé trois fichiers et lancé nos services sur la nouvelle plateforme cloud, MCS. Permettez-moi de vous rappeler qu'à cette époque, nous avions enfin quitté le bare metal et vivions sur Google Cloud Platform. Par conséquent, le déménagement lui-même n'a pas pris plus de deux heures, et un peu plus de temps (environ une heure) a été consacré à la copie des données de nos appareils. À l'époque, nous utilisions déjà Spinnaker (un service de CD multi-cloud pour fournir une livraison continue). Nous l'avons également rapidement ajouté au nouveau cluster et avons continué à travailler comme d'habitude.
Grâce à l'automatisation des processus de développement et au CI/CD, Kubernetes chez URUS est géré par un seul spécialiste (et c'est moi). À un moment donné, un autre administrateur système a travaillé avec moi, mais il s'est ensuite avéré que nous avions déjà automatisé toute la routine principale et qu'il y avait de plus en plus de tâches de la part de notre produit principal et qu'il était logique d'y consacrer des ressources.
Nous avons reçu ce que nous attendions du fournisseur de cloud, puisque nous avons commencé une coopération sans illusions. S'il y a eu des incidents, ils étaient pour la plupart techniques et ceux-ci s'expliquaient facilement par la relative fraîcheur du service. L'essentiel est que l'équipe MCS élimine rapidement les lacunes et réponde rapidement aux questions posées dans les messagers.
Si je compare mon expérience avec Google Cloud Platform, dans leur cas, je ne savais même pas où se trouvait le bouton de commentaires, car il n'était tout simplement pas nécessaire. Et si des problèmes survenaient, Google lui-même envoyait des notifications unilatérales. Mais dans le cas de MCS, je pense que le gros avantage est qu’ils sont aussi proches que possible des clients russes, tant géographiquement que mentalement.
Comment nous envisageons de travailler avec les nuages à l'avenir
Désormais, notre travail est étroitement lié à Kubernetes et cela nous convient parfaitement du point de vue des tâches d'infrastructure. Par conséquent, nous ne prévoyons pas d'en migrer nulle part, même si nous introduisons constamment de nouvelles pratiques et services pour simplifier les tâches de routine et en automatiser de nouvelles, augmenter la stabilité et la fiabilité des services... Nous lançons maintenant le service Chaos Monkey (en particulier , nous utilisons chaoskube, mais cela ne change pas le concept : ), qui a été créé à l'origine par Netflix. Chaos Monkey fait une chose simple : il supprime un pod Kubernetes aléatoire à un moment aléatoire. Ceci est nécessaire pour que notre service vive normalement avec le nombre d'instances n–1, nous nous entraînons donc pour nous préparer à tout problème.
Aujourd'hui, je considère le recours à des solutions tierces - les mêmes plateformes cloud - comme la seule bonne chose pour les jeunes entreprises. Habituellement, au début de leur parcours, leurs ressources, tant humaines que financières, sont limitées, et la construction et la maintenance de leur propre cloud ou centre de données sont trop coûteuses et demandent trop de main d'œuvre. Les fournisseurs de cloud vous permettent de minimiser ces coûts, vous pouvez obtenir rapidement auprès d'eux les ressources nécessaires au fonctionnement des services ici et maintenant, et payer ces ressources après coup. Quant à la société URUS, nous resterons fidèles à Kubernetes dans le cloud pour l'instant. Mais qui sait, il faudra peut-être s’étendre géographiquement ou mettre en œuvre des solutions basées sur certains équipements spécifiques. Ou peut-être que la quantité de ressources consommées justifiera de posséder Kubernetes sur du métal nu, comme au bon vieux temps. 🙂
Ce que nous avons appris en travaillant avec les services cloud
Nous avons commencé à utiliser Kubernetes sur du bare metal, et même là, c'était bien à sa manière. Mais ses atouts se sont révélés précisément en tant que composant aaS dans le cloud. Si vous vous fixez un objectif et automatisez tout autant que possible, vous pourrez éviter le blocage d'un fournisseur et passer d'un fournisseur de cloud à l'autre prendra quelques heures, et les cellules nerveuses resteront avec nous. Nous pouvons conseiller d'autres entreprises : si vous souhaitez lancer votre propre service (cloud), avec des ressources limitées et une vitesse de développement maximale, commencez dès maintenant par louer des ressources cloud et construisez votre centre de données après que Forbes ait écrit à votre sujet.
Source: habr.com