Het URUS-bedrijf probeerde Kubernetes in verschillende vormen: onafhankelijke implementatie op bare metal, in Google Cloud, en bracht vervolgens zijn platform over naar de Mail.ru Cloud Solutions (MCS)-cloud. Igor Shishkin vertelt hoe ze een nieuwe cloudprovider kozen en hoe ze erin slaagden om daar in een recordtijd van twee uur naartoe te migreren (), senior systeembeheerder bij URUS.
Wat doet URUS?
Er zijn veel manieren om de kwaliteit van de stedelijke omgeving te verbeteren, en één daarvan is het milieuvriendelijk maken ervan. Dit is precies waar het bedrijf URUS - Smart Digital Services aan werkt. Hier implementeren ze oplossingen die bedrijven helpen belangrijke milieu-indicatoren te monitoren en hun negatieve impact op het milieu te verminderen. Sensoren verzamelen gegevens over de luchtsamenstelling, het geluidsniveau en andere parameters en sturen deze vervolgens naar het uniforme URUS-Ekomon-platform voor analyse en het doen van aanbevelingen.
Hoe URUS van binnenuit werkt
Een typische klant van URUS is een bedrijf gevestigd in of nabij een woonwijk. Dit kan een fabriek, haven, spoorwegdepot of een andere faciliteit zijn. Als onze klant al een waarschuwing heeft gekregen, een boete heeft gekregen voor milieuvervuiling, of minder geluid wil maken, de hoeveelheid schadelijke uitstoot wil terugdringen, dan komt hij naar ons toe en bieden wij hem al een kant-en-klare oplossing voor milieumonitoring.
De grafiek voor het monitoren van de H2S-concentratie toont de reguliere nachtelijke emissies van een nabijgelegen fabriek
De apparaten die wij bij URUS gebruiken bevatten verschillende sensoren die informatie verzamelen over de inhoud van bepaalde gassen, geluidsniveaus en andere gegevens om de milieusituatie te beoordelen. Het exacte aantal sensoren wordt altijd bepaald door de specifieke taak.
Afhankelijk van de specifieke kenmerken van de metingen kunnen apparaten met sensoren op de muren van gebouwen, palen en andere willekeurige plaatsen worden geplaatst. Elk dergelijk apparaat verzamelt informatie, voegt deze samen en verzendt deze naar de gegevensontvangstgateway. Daar slaan we de gegevens op voor langdurige opslag en voorbewerken voor latere analyse. Het eenvoudigste voorbeeld van wat we als resultaat van de analyse krijgen, is de luchtkwaliteitsindex, ook bekend als AQI.
Parallel daaraan draaien er nog veel meer diensten op ons platform, maar deze zijn vooral dienstverlenend. De notificatiedienst stuurt bijvoorbeeld notificaties naar klanten als een van de bewaakte parameters (bijvoorbeeld het CO2-gehalte) de toegestane waarde overschrijdt.
Hoe wij gegevens opslaan. Het verhaal van Kubernetes op bare metal
Het URUS-milieumonitoringproject beschikt over verschillende datawarehouses. In één bewaren we ‘ruwe’ gegevens: wat we rechtstreeks van de apparaten zelf hebben ontvangen. Deze opslag is een “magnetische” tape, zoals op oude cassettebandjes, met een geschiedenis van alle indicatoren. Het tweede type opslag wordt gebruikt voor voorbewerkte gegevens: gegevens van apparaten, verrijkt met metadata over verbindingen tussen sensoren en de metingen van de apparaten zelf, aansluiting bij organisaties, locaties, enz. Met deze informatie kunt u dynamisch beoordelen hoe een bepaalde indicator zich heeft ontwikkeld gedurende een bepaalde periode veranderd. De ‘ruwe’ dataopslag gebruiken wij onder meer als back-up en voor het herstellen van voorbewerkte data, mocht daar behoefte aan zijn.
Toen we ons opslagprobleem enkele jaren geleden wilden oplossen, hadden we twee platformkeuzes: Kubernetes en OpenStack. Maar omdat dat laatste er behoorlijk monsterlijk uitziet (kijk maar naar de architectuur om hiervan overtuigd te zijn), hebben we voor Kubernetes gekozen. Een ander argument in het voordeel was de relatief eenvoudige softwarecontrole, de mogelijkheid om zelfs hardwareknooppunten flexibeler in te delen op basis van bronnen.
Parallel aan het beheersen van Kubernetes zelf hebben we ook manieren onderzocht om data op te slaan, terwijl we al onze opslag in Kubernetes op onze eigen hardware behielden, kregen we uitstekende expertise. Alles wat we toen hadden leefde op Kubernetes: statefull storage, monitoringsysteem, CI/CD. Kubernetes is voor ons een alles-in-één platform geworden.
Maar we wilden met Kubernetes als een service werken en ons niet bezighouden met de ondersteuning en ontwikkeling ervan. Bovendien vonden we het niet leuk hoeveel het ons kostte om het op blank metaal te onderhouden, en we hadden voortdurend ontwikkeling nodig! Eén van de eerste taken was bijvoorbeeld het integreren van Kubernetes Ingress-controllers in de netwerkinfrastructuur van onze organisatie. Dit is een omslachtige taak, vooral gezien het feit dat er op dat moment nog niets klaar was voor programmatisch resourcebeheer zoals DNS-records of de toewijzing van IP-adressen. Later zijn we gaan experimenteren met externe dataopslag. Aan de implementatie van de PVC-controller zijn we nooit toegekomen, maar toen al werd duidelijk dat dit een groot werkgebied was waarvoor toegewijde specialisten nodig waren.
Overstappen naar Google Cloud Platform is een tijdelijke oplossing
We realiseerden ons dat dit niet zo kon doorgaan en verplaatsten onze gegevens van bare metal naar Google Cloud Platform. Eigenlijk waren er op dat moment niet veel interessante opties voor een Russisch bedrijf: naast Google Cloud Platform bood alleen Amazon een soortgelijke dienst aan, maar we kozen toch voor de oplossing van Google. Toen leek het ons economisch winstgevender, dichter bij Upstream, om nog maar te zwijgen van het feit dat Google zelf een soort PoC Kubernetes in Production is.
Het eerste grote probleem verscheen aan de horizon toen ons klantenbestand groeide. Toen we persoonlijke gegevens moesten opslaan, stonden we voor de keuze: óf we werken samen met Google en overtreden de Russische wetten, óf we zoeken een alternatief in de Russische Federatie. De keuze was over het algemeen voorspelbaar. 🙂
Hoe wij de ideale clouddienst zagen
Aan het begin van de zoektocht wisten we al wat we wilden krijgen van de toekomstige cloudprovider. Welke dienst zochten wij:
- Snel en flexibel. Zodanig dat we op ieder moment snel een nieuwe node kunnen toevoegen of iets kunnen inzetten.
- Goedkoop. We waren erg bezorgd over de financiële kwestie, omdat we beperkt waren in de middelen. We wisten al dat we met Kubernetes wilden werken, en nu was het de taak om de kosten ervan te minimaliseren om de efficiëntie van het gebruik van deze oplossing te vergroten of op zijn minst te behouden.
- geautomatiseerd. We waren van plan om met de service via de API te werken, zonder managers en telefoontjes of situaties waarin we handmatig enkele tientallen knooppunten in de noodmodus moeten activeren. Omdat de meeste van onze processen geautomatiseerd zijn, verwachtten we hetzelfde van de clouddienst.
- Met servers in de Russische Federatie. Natuurlijk waren we van plan om te voldoen aan de Russische wetgeving en diezelfde 152-FZ.
Destijds waren er weinig Kubernetes aaS-providers in Rusland, en bij het kiezen van een provider was het belangrijk dat we onze prioriteiten niet in gevaar brachten. Het Mail.ru Cloud Solutions-team, met wie we begonnen te werken en nog steeds samenwerken, voorzag ons van een volledig geautomatiseerde service, met API-ondersteuning en een handig controlepaneel met Horizon - daarmee konden we snel een willekeurig aantal knooppunten verhogen.
Hoe we erin slaagden om binnen twee uur naar MCS te migreren
Bij dergelijke stappen worden veel bedrijven geconfronteerd met moeilijkheden en tegenslagen, maar in ons geval waren die er niet. We hadden geluk: omdat we al aan Kubernetes werkten voordat de migratie begon, hebben we eenvoudigweg drie bestanden gecorrigeerd en onze diensten gelanceerd op het nieuwe cloudplatform MCS. Laat me je eraan herinneren dat we tegen die tijd eindelijk het bare metal hadden verlaten en op het Google Cloud Platform woonden. Daarom duurde de verhuizing zelf niet meer dan twee uur, en werd er iets meer tijd (ongeveer een uur) besteed aan het kopiëren van gegevens van onze apparaten. Destijds gebruikten we al Spinnaker (een multi-cloud cd-service voor continue levering). We hebben het ook snel toegevoegd aan het nieuwe cluster en zijn gewoon blijven werken.
Dankzij de automatisering van ontwikkelprocessen en CI/CD wordt Kubernetes bij URUS door één specialist afgehandeld (en dat ben ik). Op een gegeven moment werkte een andere systeembeheerder met mij samen, maar toen bleek dat we alle hoofdroutines al hadden geautomatiseerd en dat er steeds meer taken waren aan de kant van ons hoofdproduct en het was logisch om hier middelen voor te gebruiken.
We kregen wat we van de cloudprovider verwachtten, sinds we zonder illusies begonnen met samenwerken. Als er al incidenten waren, waren deze meestal van technische aard en konden ze gemakkelijk worden verklaard door de relatieve frisheid van de dienst. Het belangrijkste is dat het MCS-team tekortkomingen snel elimineert en snel reageert op vragen in messengers.
Als ik mijn ervaring met Google Cloud Platform vergelijk, wist ik in hun geval niet eens waar de feedbackknop zat, omdat die simpelweg niet nodig was. En als er zich toch problemen voordeden, verzond Google zelf eenzijdig meldingen. Maar in het geval van MCS denk ik dat het grote voordeel is dat ze zo dicht mogelijk bij de Russische klanten staan – zowel geografisch als mentaal.
Hoe wij het werken met wolken in de toekomst zien
Nu is ons werk nauw verbonden met Kubernetes, en het past helemaal bij ons vanuit het oogpunt van infrastructuurtaken. Daarom zijn we niet van plan om er ergens vandaan te migreren, hoewel we voortdurend nieuwe praktijken en diensten introduceren om routinetaken te vereenvoudigen en nieuwe te automatiseren, de stabiliteit en betrouwbaarheid van diensten te vergroten... We lanceren nu de Chaos Monkey-service (specifiek , gebruiken we chaoskube, maar dit verandert niets aan het concept: ), dat oorspronkelijk door Netflix is gemaakt. Chaos Monkey doet één simpel ding: het verwijdert op een willekeurig tijdstip een willekeurige Kubernetes-pod. Dit is nodig om ervoor te zorgen dat onze service normaal kan functioneren met het aantal instanties n–1, dus trainen we onszelf om voorbereid te zijn op eventuele problemen.
Nu zie ik het gebruik van oplossingen van derden – dezelfde cloudplatforms – als het enige juiste voor jonge bedrijven. Meestal zijn ze aan het begin van hun reis beperkt in de middelen, zowel menselijk als financieel, en het bouwen en onderhouden van hun eigen cloud of datacenter is te duur en arbeidsintensief. Met cloudproviders kunt u deze kosten minimaliseren; u kunt bij hen snel de middelen verkrijgen die nodig zijn voor de werking van diensten hier en nu, en deze middelen achteraf betalen. Wat het bedrijf URUS betreft, blijven we voorlopig trouw aan Kubernetes in de cloud. Maar wie weet moeten we geografisch uitbreiden of oplossingen implementeren op basis van specifieke apparatuur. Of misschien rechtvaardigt de hoeveelheid verbruikte bronnen eigen Kubernetes op bare-metal, zoals in de goede oude tijd. 🙂
Wat we hebben geleerd van het werken met clouddiensten
We zijn Kubernetes op bare metal gaan gebruiken, en zelfs daar was het op zijn eigen manier goed. Maar de sterke punten kwamen juist aan het licht als een aaS-component in de cloud. Als je een doel stelt en alles zoveel mogelijk automatiseert, kun je de lock-in van een leverancier vermijden. Het wisselen tussen cloudproviders duurt een paar uur en de zenuwcellen blijven bij ons. Wij kunnen andere bedrijven adviseren: als u uw eigen (cloud)dienst wilt lanceren, met beperkte middelen en maximale ontwikkelingssnelheid, begin dan nu met het huren van cloudbronnen en bouw uw datacenter nadat Forbes over u heeft geschreven.
Bron: www.habr.com