Het bedrijf «УРУС» heeft Kubernetes in verschillende vormen uitgeprobeerd: op zichzelf staande implementatie op bare metal, in Google Cloud, en heeft vervolgens zijn platform verhuisd naar de Mail.ru Cloud Solutions (MCS). Hoe ze een nieuwe cloudprovider hebben gekozen en hoe het gelukt is om in recordtijd van twee uur naar hen te migreren, vertelt Igor Shishkin (), senior systeembeheerder bij «УРУС».
Wat doet «УРУС»
Er zijn veel manieren om de kwaliteit van de stedelijke omgeving te verbeteren, en een daarvan is om deze ecologisch veilig te maken. Daar zijn ze precies bezig bij het bedrijf «УРУС — Slimme digitale diensten». Hier worden oplossingen geïmplementeerd die bedrijven helpen om belangrijke ecologische indicatoren te controleren en de negatieve impact op het milieu te verminderen. Sensoren verzamelen data over de luchtkwaliteit, het geluidsniveau en andere parameters, en sturen deze vervolgens naar het uniforme platform «УРУС — Ecomon» voor analyse en aanbevelingen.
Hoe de werking van «УРУС» van binnenuit is georganiseerd
Een typische klant van «УРУС» is een bedrijf dat zich in een woongebied of daar vlakbij bevindt. Dit kan een fabriek, haven, treindepot of een ander object zijn. Als onze klant al een waarschuwing heeft ontvangen, gestraft is voor milieuschade of zelf minder geluid wil produceren en het aantal schadelijke uitstoot wil verlagen, komt hij naar ons, en wij bieden hem een kant-en-klaar oplossing voor ecologisch monitoring.
Op de grafiek van de monitoring van de H2S-concentratie zijn regelmatige nachtelijke uitstoten van het nabijgelegen bedrijf zichtbaar.
De apparaten die we in «УРУС» gebruiken bevatten meerdere sensoren die informatie over de concentratie van bepaalde gassen, het geluidsniveau en andere gegevens verzamelen voor het beoordelen van de ecologische situatie. Het exacte aantal sensoren wordt altijd bepaald door de specifieke taak.
Afhankelijk van de aard van de metingen kunnen de apparaten met sensoren zich bevinden op muren van gebouwen, op palen en op andere willekeurige plaatsen. Elk van deze apparaten verzamelt informatie, aggregeert deze en stuurt deze naar een gegevensontvangstgateway. Daar bewaren we de gegevens voor langdurige opslag en bewerken ze voor verdere analyse. Een eenvoudig voorbeeld van wat we als output ontvangen na analyse is de luchtkwaliteitsindex, ook wel AQI genoemd.
Parallel werken er veel andere diensten op ons platform, maar over het algemeen hebben ze een ondersteunend karakter. Bijvoorbeeld, de notificatieservice verstuurt meldingen naar klanten als een van de gecontroleerde parameters (zoals CO2-inhoud) de toegestane waarde overschrijdt.
Hoe we gegevens opslaan. Het verhaal van Kubernetes op bare metal
Het ecomonitoringproject "URUS" heeft verschillende datastorage. In één daarvan bewaren we de "rauwe" gegevens - wat we direct van de apparaten hebben ontvangen. Deze opslag fungeert als een "magnetische" tape, zoals in oude cassettebandjes, met een geschiedenis van alle metingen. Het tweede type opslag wordt gebruikt voor voorbewerkte gegevens - gegevens van apparaten aangevuld met metadata over de relaties tussen sensoren en de metingen van de apparaten zelf, relaties met organisaties, locaties, enz. Deze informatie stelt ons in staat om dynamisch te beoordelen hoe een bepaalde maatstaf in de loop van de tijd is veranderd. We gebruiken de opslag van "rauwe" gegevens ook als een back-up en voor het herstellen van voorbewerkte gegevens, indien nodig.
Toen we een paar jaar geleden zochten naar een oplossing voor ons opslageprobleem, hadden we twee opties voor de keuze van een platform: Kubernetes en OpenStack. Maar omdat de laatste er nogal monsterlijk uitziet (kijk gewoon naar zijn architectuur om dit te bevestigen), hebben we toch voor Kubernetes gekozen. Een ander argument voor Kubernetes was het relatief eenvoudige programmatische beheer en de mogelijkheid om zelfs fysieke nodes flexibeler te splitsen op basis van middelen.
Tegelijkertijd met het leren van Kubernetes, bestudeerden we ook de manieren van gegevensopslag. Terwijl we al onze opslag in Kubernetes op ons eigen hardware hielden, hebben we uitstekende expertise opgedaan. Alles wat we destijds hadden, draaide op Kubernetes: stateful storage, monitoring systeem, CI/CD. Kubernetes werd voor ons een all-in-one platform.
Maar we wilden met Kubernetes werken als een service, in plaats van het te ondersteunen en ontwikkelen. Bovendien waren we niet blij met de kosten van hosting op bare metal, en we hadden voortdurend ontwikkelwerk nodig! Een van de eerste taken was om Kubernetes Ingress-controllers in de netwerkinfrastructuur van onze organisatie te integreren. Dit is een complexe taak, vooral als je bedenkt dat er op dat moment niets gereed was voor softwarematige resourcebeheer zoals DNS-records of toewijzing. IP-adressen. Later zijn we gaan experimenteren met externe gegevensopslag. We hebben de implementatie van de PVC-controller niet gehaald, maar het was al duidelijk dat dit een grote werkbelasting met zich meebracht waarvoor aparte specialisten nodig waren.
De overstap naar Google Cloud Platform was een tijdelijke oplossing.
We realiseerden ons dat het zo niet verder kon, en we hebben onze gegevens van bare metal naar Google Cloud Platform verhuisd. Voor een Russisch bedrijf waren er destijds niet zo veel interessante opties: naast Google Cloud Platform bood alleen Amazon een vergelijkbare service, maar we kozen uiteindelijk voor de oplossing van Google. Toen leek het ons economisch voordeliger en dichter bij Upstream, om nog maar te zwijgen over het feit dat Google op zichzelf een soort PoC Kubernetes in productie is.
Het eerste serieuze probleem deed zich voor naarmate onze klantenbasis groeide. Toen we behoefte kregen aan het opslaan van persoonlijke gegevens, stonden we voor de keuze: of we werken met Google en schenden we Russische wetten, of we zoeken een alternatief in Rusland. De keuze was, in het algemeen, voorspelbaar. 🙂
Hoe wij de ideale cloudservice zagen.
Aan het begin van onze zoektocht wisten we al wat we van de toekomstige cloudprovider wilden. Welke service zochten we:
- Snel en flexibel.. Een service waarmee we op elk moment snel een nieuwe node konden toevoegen of iets konden implementeren.
- Betaalbaar.. We waren erg bezorgd over financiële kwesties, omdat we beperkt waren in middelen. We wisten al dat we met Kubernetes wilden werken, en nu was de uitdaging om de kosten te minimaliseren om de efficiëntie van deze oplossing te vergroten of in ieder geval te behouden.
- Geautomatiseerd.. We had planned to work with the service through the API, without managers and phone calls or situations where we needed to manually spin up dozens of nodes in emergency mode. Since most of our processes are automated, we expected the same from the cloud service.
- With servers in the Netherlands. Of course, we planned to comply with Dutch legislation and the relevant GDPR.
At that time, there were few Kubernetes providers operating under aaS models in the Netherlands, and when choosing a provider, it was important for us not to compromise our priorities. The team at Mail.ru Cloud Solutions, with whom we started working and still collaborate, provided us with a fully automated service, with API support and a user-friendly control panel, featuring Horizon — allowing us to quickly spin up an arbitrary number of nodes.
How we managed to migrate to MCS in two hours
In such migrations, many companies face difficulties and setbacks, but in our case, there were none. We were fortunate: since we had already been working on Kubernetes before the migration, we just adjusted three files and launched our services on the new cloud platform, MCS. I remind you that by that time, we had completely moved away from bare metal and were living on Google Cloud Platform. Therefore, the migration itself took no more than two hours, plus a bit more time (about an hour) was spent on copying data from our devices. By then, we were already using Spinnaker (a multi-cloud CD service for ensuring Continuous Delivery). We also quickly added it to the new cluster and continued to work as usual.
Thanks to the automation of development processes and CI/CD, Kubernetes in 'URUS' is managed by one specialist (that's me). At some point, another system administrator worked with me, but it turned out that we had already automated all the main routine tasks, while the demands from our main product were increasing, making it more sensible to direct resources toward that.
We received from the cloud provider what we expected, as we began our collaboration without illusions. If there were any incidents, they were mainly technical and easily explained by the relative novelty of the service. The main thing is that the MCS team promptly addresses issues and quickly responds to questions in messaging apps.
Als ik mijn ervaring met Google Cloud Platform vergelijk, wist ik zelfs niet waar de feedbackknop zich bevond, omdat er gewoon geen behoefte aan was. Als er problemen optraden, verstuurde Google eenzijdig meldingen. Bij MCS vind ik echter als groot pluspunt dat ze maximaal dichtbij Russische klanten zijn - zowel geografisch als mentaal.
Hoe we de toekomst van cloudwerk zien
Op dit moment is ons werk sterk afhankelijk van Kubernetes, en het voldoet volledig aan onze infrastructuurbehoeften. Daarom zijn we niet van plan om ergens anders naartoe te migreren, hoewel we voortdurend nieuwe praktijken en services implementeren om routinetaken te vereenvoudigen en nieuwe te automatiseren, evenals om de stabiliteit en betrouwbaarheid van onze services te verhogen... We lanceren nu de Chaos Monkey-service (specifiek gebruiken we chaoskube, maar dat verandert het concept niet :), die oorspronkelijk door Netflix is ontwikkeld. Chaos Monkey doet één eenvoudige zaak: het verwijdert op willekeurige momenten een willekeurige pod in Kubernetes. Dit is nodig zodat onze service normaal functioneert met n–1 instanties, zodat we onszelf trainen om voorbereid te zijn op eventuele storingen.
Op dit moment zie ik het gebruik van externe oplossingen - dezelfde cloudplatforms - als de enige juiste keuze voor jonge bedrijven. Gewoonlijk zijn ze in het begin beperkt in middelen, zowel qua personeel als qua financiën, en het bouwen en onderhouden van een eigen cloud of datacentrum is te duur en arbeidsintensief. Cloudproviders stellen hen in staat deze kosten te minimaliseren; ze kunnen snel toegang krijgen tot de middelen die nodig zijn om hun services hier en nu te laten functioneren, en bovendien betalen ze deze middelen pas achteraf. Wat betreft het bedrijf 'УРУС', blijven we voorlopig trouw aan Kubernetes in de cloud. Maar wie weet, misschien zullen we ons geografisch moeten uitbreiden of oplossingen implementeren op basis van specifieke hardware. Of misschien rechtvaardigt de hoeveelheid verbruikte middelen een eigen Kubernetes op bare-metal, zoals in de goede oude tijd. 🙂
Wat we hebben geleerd van onze ervaring met cloudservices
Wij zijn begonnen met het gebruiken van Kubernetes op bare metal, en zelfs daar was het op zijn manier goed. Maar de sterke punten kwamen pas echt tot hun recht als aaS-component in de cloud. Als je een doel stelt en alles maximaal automatiseert, kun je vendor lock-in vermijden en zal een migratie tussen cloudproviders enkele uren duren, terwijl je zenuwcellen intact blijven. We kunnen andere bedrijven adviseren: wil je jouw (cloud) service lanceren met beperkte middelen en maximale snelheid voor ontwikkeling — begin dan nu met het huren van cloudresources, en bouw je datacenter pas nadat Forbes over je schrijft.
Bron: habr.com
