Eind mei hield een online bijeenkomst over dit onderwerp . We hadden het in principe over containers, Kubernetes en orkestratie, criteria voor het kiezen van infrastructuur en nog veel meer. Deelnemers deelden cases uit hun eigen praktijk.
Deelnemers:
- Evgeni Potapov, CEO van ITSumma. Meer dan de helft van de klanten is al verhuisd of wil overstappen naar Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Heeft meer dan 10 jaar ervaring met containersystemen.
- Denis Remchukov (ook bekend als Eric Oldmann), COO argotech.io, ex-RAO UES. Hij beloofde te praten over gevallen in de ‘bloedige’ onderneming.
- Andrej Fedorovsky, CTO “News360.com”Nadat hij het bedrijf door een andere speler heeft overgenomen, is hij verantwoordelijk voor een aantal ML- en AI-projecten en infrastructuur.
- Ivan Kruglov, systeemingenieur, ex-Booking.com.Dezelfde persoon die veel met Kubernetes met zijn eigen handen heeft gedaan.
Thema's:
- Inzichten van deelnemers over containers en orkestratie (Docker, Kubernetes, etc.); wat in de praktijk werd geprobeerd of geanalyseerd.
- Case: Het bedrijf werkt al jaren aan een infrastructuurontwikkelingsplan. Hoe wordt de beslissing genomen of de huidige infrastructuur wel of niet wordt gebouwd (of gemigreerd naar containers en Kuber)?
- Problemen in de cloud-native wereld, wat ontbreekt, laten we ons voorstellen wat er morgen zal gebeuren.
Er ontstond een interessante discussie, de meningen van de deelnemers waren zo verschillend en veroorzaakten zoveel reacties dat ik ze met jullie wil delen. Eten , en hieronder vindt u een samenvatting van de discussie.
Is Kubernetes al een standaard of geweldige marketing?
“We kwamen erbij (Kubernetes. - Vert) toen niemand er nog van wist. We kwamen naar hem toe, zelfs als hij er niet was. We wilden het eerder" - Dmitri Stolyarov
Foto van Reddit.com
5-10 jaar geleden waren er een groot aantal tools en er was geen enkele standaard. Elke zes maanden verscheen er een nieuw product, of zelfs meer dan één. Eerst Vagrant, dan Salt, Chef, Puppet,... “en je bouwt je infrastructuur elke zes maanden opnieuw op. Je hebt vijf beheerders die voortdurend bezig zijn met het herschrijven van configuraties”, herinnert Andrey Fedorovsky zich. Hij is van mening dat Docker en Kubernetes de rest hebben ‘verdrongen’. Docker is de afgelopen vijf jaar een standaard geworden, Kubernetes de afgelopen twee jaar. En dat is goed voor de sector..
Dmitry Stolyarov en zijn team zijn dol op Kuber. Ze wilden zo'n hulpmiddel voordat het verscheen, en kwamen ernaartoe toen niemand er iets van wist. Momenteel nemen ze uit gemakshalve geen klant aan als ze begrijpen dat ze Kubernetes niet bij hem gaan implementeren. Tegelijkertijd heeft het bedrijf volgens Dmitry “veel gigantische succesverhalen over het opnieuw maken van de verschrikkelijke erfenis.”
Kubernetes is niet alleen containerorkestratie, het is een configuratiebeheersysteem met een ontwikkelde API, een netwerkcomponent, L3-balancering en Ingress-controllers, waardoor het relatief eenvoudig is om bronnen te beheren, te schalen en te abstraheren uit de lagere lagen van de infrastructuur.
Helaas moeten we in ons leven voor alles betalen. En deze belasting is groot, vooral als we het hebben over de transitie naar Kubernetes van een bedrijf met een ontwikkelde infrastructuur, zoals Ivan Kruglov gelooft. Hij kon vrijelijk werken, zowel in een bedrijf met een traditionele infrastructuur als bij Kuber. Het belangrijkste is om de kenmerken van het bedrijf en de markt te begrijpen. Maar voor Evgeny Potapov, die Kubernetes zou generaliseren naar welke containerorkestratietool dan ook, rijst een dergelijke vraag niet.
Evgeniy trok een analogie met de situatie in de jaren negentig, toen objectgeoriënteerd programmeren verscheen als een manier om complexe applicaties te programmeren. Destijds werd het debat voortgezet en verschenen er nieuwe instrumenten ter ondersteuning van OOP. Toen kwamen microservices naar voren als een manier om af te stappen van het monolithische concept. Dit leidde op zijn beurt tot de opkomst van containers en containerbeheertools. “Ik denk dat we binnenkort op een moment zullen komen waarin er geen twijfel meer over zal bestaan of het de moeite waard is om een kleine microservice-applicatie te schrijven; deze wordt standaard als microservice geschreven”, meent hij. Op dezelfde manier zullen Docker en Kubernetes uiteindelijk de standaardoplossing worden zonder dat er keuze nodig is.
Het probleem van databases in staatlozen
Foto door
Tegenwoordig zijn er veel recepten voor het draaien van databases in Kubernetes. Zelfs hoe je het gedeelte dat met de I/O-schijf werkt, voorwaardelijk kunt scheiden van het applicatiegedeelte van de database. Is het mogelijk dat databases in de toekomst zo sterk zullen veranderen dat ze in een box worden geleverd, waarbij het ene deel via Docker en Kubernetes wordt georkestreerd, en in een ander deel van de infrastructuur, via aparte software, het opslagdeel wordt geleverd? ? Zullen de bases als product veranderen?
Deze omschrijving lijkt op wachtrijbeheer, maar de eisen voor betrouwbaarheid en synchronisatie van informatie in traditionele databases zijn veel hoger, meent Andrey. De cachehitratio in normale databases blijft 99%. Als een werker uitvalt, wordt er een nieuwe gelanceerd en wordt de cache helemaal opnieuw opgewarmd. Totdat de cache is opgewarmd, werkt de worker langzaam, wat betekent dat deze niet kan worden geladen met gebruikersbelasting. Hoewel er geen gebruikersbelasting is, wordt de cache niet opgewarmd. Het is een vicieuze cirkel.
Dmitry is het daar fundamenteel mee oneens: quorums en sharding lossen het probleem op. Maar Andrey houdt vol dat de oplossing niet voor iedereen geschikt is. In sommige situaties is een quorum geschikt, maar het zorgt voor extra belasting van het netwerk. Een NoSQL-database is niet in alle gevallen geschikt.
De deelnemers aan de meetup waren verdeeld in twee kampen.
Denis en Andrey beweren dat alles wat naar schijf wordt geschreven – databases enzovoort – onmogelijk is in het huidige Kuber-ecosysteem. Het is onmogelijk om de integriteit en consistentie van productiegegevens in Kubernetes te behouden. Dit is een fundamenteel kenmerk. Oplossing: hybride infrastructuur.
Zelfs moderne cloud-native databases zoals MongoDB en Cassandra, of berichtenwachtrijen zoals Kafka of RabbitMQ, vereisen persistente gegevensopslag buiten Kubernetes.
Evgeniy werpt tegen: “De bases in Kubera zijn een bijna-Russische of bijna-ondernemingsschade, die verband houdt met het feit dat er in Rusland geen Cloud Adoption is.” Kleine of middelgrote bedrijven in het Westen zijn Cloud. Amazon RDS-databases zijn gemakkelijker te gebruiken dan zelf aan Kubernetes sleutelen. In Rusland gebruiken ze Kuber ‘on-premise’ en verplaatsen ze bases ernaar wanneer ze proberen de dierentuin kwijt te raken.
Ook Dmitry was het niet eens met de stelling dat er geen databases bijgehouden kunnen worden in Kubernetes: “Base is anders dan base. En als je een gigantische relationele database pusht, dan onder geen beding. Als je iets kleins en cloud-natives pusht, dat mentaal is voorbereid op een semi-efemere leven, komt alles goed.” Dmitry zei ook dat tools voor databasebeheer nog niet klaar zijn voor Docker of Kuber, waardoor er grote problemen ontstaan.
Ivan is er op zijn beurt zeker van dat, zelfs als we abstraheren van de concepten stateful en stateless, het ecosysteem van bedrijfsoplossingen in Kubernetes nog niet klaar is. Met Kuber is het moeilijk om aan wet- en regelgeving te voldoen. Het is bijvoorbeeld onmogelijk om een identiteitsvoorzieningsoplossing te maken waarbij strikte serveridentificatiegaranties vereist zijn, tot en met de hardware die in de servers wordt geplaatst. Dit gebied is in ontwikkeling, maar er is nog geen oplossing.
Omdat de deelnemers het niet eens konden worden, worden er in dit deel geen conclusies getrokken. Laten we een paar praktische voorbeelden geven.
Case 1. Cyberbeveiliging van een “mega-regulator” met bases buiten Kubera
In het geval van een ontwikkeld cyberbeveiligingssysteem maakt het gebruik van containers en orkestratie het mogelijk om aanvallen en inbraken te bestrijden. In één megaregulator implementeerden Denis en zijn team bijvoorbeeld een combinatie van een orkestrator met een getrainde SIEM-service die logs in realtime analyseert en het proces van een aanval, hacking of mislukking bepaalt. Bij een aanval, een poging om iets te plaatsen, of bij een ransomware-virusinvasie, pikt deze via de orkestrator containers met applicaties sneller op dan dat ze geïnfecteerd raken, of sneller dan dat de aanvaller ze aanvalt.
Case 2. Gedeeltelijke migratie van databases van Booking.com naar Kubernetes
Bij Booking.com is de hoofddatabase MySQL met asynchrone replicatie - er is een master en een hele hiërarchie van slaven. Tegen de tijd dat Ivan het bedrijf verliet, werd er een project gelanceerd om slaven over te dragen die met bepaalde schade konden worden ‘neergeschoten’.
Naast de hoofdbasis is er een Cassandra-installatie met zelfgeschreven orkestratie, geschreven nog voordat Kuber de mainstream bereikte. Er zijn in dit opzicht geen problemen, maar het blijft hardnekkig op lokale SSD's. Externe opslag, zelfs binnen hetzelfde datacenter, wordt niet gebruikt vanwege het probleem van hoge latentie.
De derde klasse databases is de zoekservice van Booking.com, waarbij elk serviceknooppunt een database is. Pogingen om de zoekservice naar Kuber over te dragen mislukten, omdat elk knooppunt 60-80 GB lokale opslag heeft, wat moeilijk te 'liften' en 'opwarmen' is.
Als gevolg hiervan werd de zoekmachine niet overgebracht naar Kubernetes en Ivan denkt niet dat er in de nabije toekomst nieuwe pogingen zullen plaatsvinden. De MySQL-database werd in tweeën overgedragen: alleen slaven, die niet bang zijn om "neergeschoten" te worden. Cassandra heeft zich perfect op haar gemak gevoeld.
Infrastructuurselectie als een opgave zonder algemene oplossing
Foto door
Laten we zeggen dat we een nieuw bedrijf hebben, of een bedrijf waar een deel van de infrastructuur op de oude manier is gebouwd. Het bouwt een infrastructuurontwikkelingsplan voor jaren. Hoe wordt de beslissing genomen of er infrastructuur op containers en Kuber moet worden gebouwd of niet?
Bedrijven die vechten voor nanoseconden worden uitgesloten van de discussie. Gezond conservatisme loont in termen van betrouwbaarheid, maar er zijn nog steeds bedrijven die een nieuwe aanpak zouden moeten overwegen.
Ivan: “Ik zou nu zeker een bedrijf in de cloud starten, simpelweg omdat het sneller is”, al hoeft dat niet per se goedkoper te zijn. Met de ontwikkeling van het durfkapitalisme hebben startups geen grote problemen met geld, en de belangrijkste taak is het veroveren van de markt.
Ivan is van mening dat de ontwikkeling van de huidige infrastructuur is een selectiecriterium. Als er in het verleden een serieuze investering is gedaan en het werkt, dan heeft het geen zin om het opnieuw te doen. Als de infrastructuur niet is ontwikkeld en er zijn problemen met tools, beveiliging en monitoring, dan is het zinvol om naar een gedistribueerde infrastructuur te kijken.
De belasting zal hoe dan ook moeten worden betaald, en Ivan zou degene betalen waardoor hij in de toekomst minder zou kunnen betalen. "Want simpelweg omdat ik in een trein zit die anderen voortbewegen, kom ik veel verder dan wanneer ik in een andere trein zit, waarin ik zelf brandstof moet tanken.“zegt Iwan. Als het bedrijf nieuw is en de latentievereisten tientallen milliseconden bedragen, dan zou Ivan kijken naar de ‘operatoren’ waarin klassieke databases tegenwoordig ‘verpakt’ zijn. Ze brengen een replicatieketen op gang, die zichzelf omschakelt in geval van failover, enz...
Voor een klein bedrijf met een paar servers heeft Kubera geen zin”, zegt Andrey. Maar als het van plan is uit te groeien tot honderden servers of meer, dan heeft het automatisering en een systeem voor resourcebeheer nodig. 90% van de gevallen zijn de kosten waard. Bovendien, ongeacht het niveau van belasting en middelen. Het is voor iedereen zinvol, van startups tot grote bedrijven met een miljoenenpubliek, om geleidelijk naar containerorkestratieproducten te kijken. “Ja, dit is echt de toekomst”, weet Andrey zeker.
Denis schetste twee hoofdcriteria: schaalbaarheid en stabiliteit van de werking. Hij selecteert de hulpmiddelen die het meest geschikt zijn voor de taak. “Het zou een noname kunnen zijn die op je knieën zit, en er staat Nutanix Community Edition op. Dit kan een tweede regel zijn in de vorm van een applicatie op Kuber met een database op de backend, die wordt gerepliceerd en die RTO- en RPO-parameters heeft gespecificeerd" (hersteltijd/puntdoelstellingen - ca).
Evgeniy identificeerde een mogelijk probleem met het personeel. Op dit moment zijn er niet veel hooggekwalificeerde specialisten op de markt die het ‘lef’ begrijpen. Als de gekozen technologie oud is, is het inderdaad moeilijk om iemand anders aan te nemen dan mensen van middelbare leeftijd die zich vervelen en het leven beu zijn. Hoewel andere deelnemers denken dat dit een kwestie is van personeelstraining.
Als we de keuzevraag stellen: een klein bedrijf lanceren in de Public Cloud met databases in Amazon RDS of “on premise” met databases in Kubernetes, dan was de keuze van de deelnemers, ondanks enkele tekortkomingen, Amazon RDS.
Omdat de meerderheid van de meetup-luisteraars niet uit de ‘bloedige’ onderneming komt gedistribueerde oplossingen is waar we naar moeten streven. Gegevensopslagsystemen moeten gedistribueerd en betrouwbaar zijn en latentie creëren, gemeten in eenheden van milliseconden, maximaal tientallen“, vatte Andrey samen.
Het beoordelen van Kubernetes-gebruik
Luisteraar Anton Zhbankov stelde een valkuilvraag aan Kubernetes-verdedigers: hoe heb je een haalbaarheidsonderzoek geselecteerd en uitgevoerd? Waarom Kubernetes, waarom geen virtuele machines bijvoorbeeld?
Foto door
Dmitry en Ivan beantwoordden het. In beide gevallen kwam er met vallen en opstaan een reeks beslissingen tot stand, waardoor beide deelnemers bij Kubernetes terechtkwamen. Nu beginnen bedrijven zelfstandig software te ontwikkelen die zinvol is om over te zetten naar Kuber. We hebben het niet over klassieke systemen van derden, zoals 1C. Kubernetes helpt wanneer ontwikkelaars snel releases moeten maken, met non-stop continue verbetering.
Andrey's team probeerde een schaalbaar cluster te creëren op basis van virtuele machines. Knooppunten vielen als dominostenen, wat soms leidde tot de ineenstorting van het cluster. “Theoretisch kun je het afmaken en met je handen ondersteunen, maar het is vervelend. En als er een oplossing op de markt is waarmee je out of the box kunt werken, dan gaan wij daar graag voor. En als gevolg daarvan zijn we overgestapt”, zegt Andrey.
Er zijn normen voor dergelijke analyses en berekeningen, maar niemand kan zeggen hoe nauwkeurig deze zijn op echte hardware die in gebruik is. Voor berekeningen is het ook belangrijk om elk instrument en ecosysteem te begrijpen, maar dit is niet mogelijk.
Wat staat ons te wachten
Foto door
Naarmate de technologie evolueert, verschijnen er steeds meer ongelijksoortige onderdelen, en dan vindt er een faseovergang plaats: er verschijnt een verkoper die genoeg geld heeft gedood om alles samen te laten komen in één enkel hulpmiddel.
Denk je dat er een tijd zal komen dat er een tool als Ubuntu voor de Linux-wereld zal zijn? Misschien zal een enkele containerisatie- en orkestratietool Kuber omvatten. Het maakt het eenvoudig om on-premise clouds te bouwen.
Het antwoord werd gegeven door Ivan: “Google bouwt nu Anthos – dit is hun pakketaanbod dat de cloud inzet en Kuber, Service Mesh, monitoring omvat – alle hardware die nodig is voor on-premise microservices.” We zijn bijna in de toekomst."
Denis noemde ook Nutanix en VMWare met het vRealize Suite-product, dat een soortgelijke taak aankan zonder containerisatie.
Dmitry deelde zijn mening dat het verminderen van de ‘pijn’ en het verlagen van de belastingen twee gebieden zijn waarop we verbeteringen kunnen verwachten.
Om de discussie samen te vatten, benadrukken we de volgende problemen van de moderne infrastructuur:
- Drie deelnemers identificeerden onmiddellijk een probleem met stateful.
- Verschillende problemen met beveiligingsondersteuning, waaronder de mogelijkheid dat Docker uiteindelijk meerdere versies van Python, applicatieservers en componenten krijgt.
Overbestedingen, die beter in een aparte vergadering kunnen worden besproken.
Een leeruitdaging omdat orkestratie een complex ecosysteem is.
Een veelvoorkomend probleem in de sector is het misbruik van gereedschappen.De rest van de conclusies is aan jou. Er heerst nog steeds het gevoel dat het voor de Docker+Kubernetes-combinatie niet eenvoudig is om een “centraal” onderdeel van het systeem te worden. Besturingssystemen worden bijvoorbeeld eerst op hardware geïnstalleerd, wat niet gezegd kan worden over containers en orkestratie. Misschien zullen besturingssystemen en containers in de toekomst samengaan met cloudbeheersoftware.
Foto doorIk wil graag van deze gelegenheid gebruik maken om hallo te zeggen tegen mijn moeder en u eraan te herinneren dat we een Facebook-groep hebben , kanaal met interessante publicaties van verschillende techblogs. En mijn kanaal , waar ik praat over het managen van ontwikkeling in productbedrijven.
Bron: www.habr.com