Aan het einde van mei hebben we een online meetup gehouden over . We hebben gesproken over containers, Kubernetes en orkestratie in het algemeen, over de criteria voor het kiezen van infrastructuur en nog veel meer. De deelnemers deelden casestudies uit hun eigen praktijk.
Deelnemers:
- Evgeny Potapov, CEO van „ITSumma“. Meer dan de helft van zijn klanten is al overgestapt of wil overstappen naar Kubernetes.
- Dmitry Stolyarov, CTO van „Flant“. Heeft meer dan 10 jaar ervaring met containersystemen.
- Denis Remchukov (aka Eric Oldmann), COO van argotech.io, ex-RAO EEU. Heeft beloofd casestudies te delen uit de „bloederige“ onderneming.
- Andrey Fedorovskiy, CTO van „News360.com“. Verantwoordelijk voor verschillende ML- en AI-projecten en de infrastructuur na de overname van het bedrijf door een andere speler.
- Ivan Kruglov, systeemingenieur, ex–Booking.com.Diezelfde persoon heeft veel gedaan met Kubernetes.
Onderwerpen:
- Inzichten van deelnemers over containers en orkestratie (Docker, Kubernetes en meer); wat ze in de praktijk hebben geprobeerd of geanalyseerd.
- Casus: Het bedrijf heeft een ontwikkelingsplan voor infrastructuur voor jaren. Hoe wordt de beslissing genomen om infrastructuur op containers en Kubernetes te bouwen (of over te zetten)?
- Problemen in de cloud-native wereld, wat ontbreekt, laten we fantaseren over wat er morgen gaat gebeuren.
Er ontstond een interessante discussie, de meningen van de deelnemers waren zo verschillend en leidden tot zoveel opmerkingen dat we die met jullie willen delen. Er is , en hieronder – een samenvatting van de discussie.
Is Kubernetes al een standaard of gewoon uitstekende marketing?
„Wij kwamen erbij (Kubernetes — Red.) toen nog niemand ervan hoorde. We kwamen erbij voordat het er was. We wilden het al eerder“ — Dmitry Stolyarov
Foto van Reddit.com
Vijf tot tien jaar geleden waren er enorm veel tools, en er was geen enkele standaard. Elke zes maanden verscheen er een nieuw product, of soms meerdere. Eerst Vagrant, dan Salt, Chef, Puppet,… „en je herziet elke zes maanden je infrastructuur. Je hebt vijf admins die voortdurend bezig zijn met het herschrijven van configuraties“ — herinnert Andrey Fedorovskiy zich. Hij gelooft dat Docker en Kubernetes de anderen hebben „verpletterd“. Docker is de afgelopen vijf jaar de standaard geworden, Kubernetes in de afgelopen twee jaar. En dat is goed voor de industrie..
Dmitry Stolyarov en zijn team zijn dol op Kubernetes. Ze wilden zo'n hulpmiddel voordat het bestond en kwamen erbij toen niemand het nog kende. Op dit moment nemen ze naar eigen zeggen geen klanten aan als ze voelen dat ze geen Kubernetes zullen implementeren. Echter, volgens Dmitry heeft het bedrijf 'tal van gigantische successverhalen over het omvormen van verschrikkelijke legacy systemen.'
Kubernetes is niet alleen containerorkestratie, het is een configuratiebeheersysteem met een ontwikkelde API, netwerkcomponenten, L3-loadbalancing en Ingress-controllers, waarmee relatief eenvoudig middelen kunnen worden beheerd, geschaald en abstractie van de onderliggende infrastructuur kan worden gerealiseerd.
Helaas moet je in ons leven voor alles betalen. En deze belasting is groot, vooral als we het hebben over de overstap naar Kubernetes voor bedrijven met een geavanceerde infrastructuur, zoals Ivan Kruglov het ziet. Hij zou net zo goed kunnen werken voor een bedrijf met een traditionele infrastructuur als voor een met Kubernetes. Het belangrijkste is om de kenmerken van het bedrijf en de markt te begrijpen. Maar voor Evgeny Potapov, die Kubernetes zou samenvatten als elk hulpmiddel voor containerorkestratie, is die vraag niet aan de orde.
Evgeny trok een vergelijking met de situatie in de jaren '90, toen objectgeoriënteerd programmeren opkwam als een manier om complexe applicaties te programmeren. Destijds gingen de debatten door en kwamen er nieuwe tools die OOP ondersteunden. Vervolgens kwamen microservices als een manier om van de monolithische benadering af te komen. Dit leidde op zijn beurt tot de opkomst van containers en tools voor hun beheer. "Ik denk dat we binnenkort in een tijd zullen komen waarin de vraag niet meer zal zijn of het de moeite waard is om een klein applicatie microservicesmatig te schrijven, dat zal standaard zijn," stelt hij. Evenzo zullen Docker en Kubernetes na verloop van tijd de standaardoplossing worden zonder dat er een keuze gemaakt hoeft te worden.
Het probleem van databases is stateless.
Foto door
Tegenwoordig zijn er veel recepten voor het draaien van databases in Kubernetes. Zelfs hoe je de I/O-werkzaamheden van de schijf kan scheiden van, zeg maar, de applicatiekant van de database. Is it possible that in the future databases will evolve to the point where they are supplied in a box, with one part orchestrated through Docker and Kubernetes, while another part of the infrastructure, via separate software, provides the storage portion? Will databases change as a product?
This description resembles queue management, but the requirements for reliability and synchronization of information in traditional databases are much higher, according to Andrey. The cache hit ratio in normal databases remains at around 99%. If a worker fails, a new one is launched, and the cache is 'warmed up' from scratch. As long as the cache isn't warmed up, the worker operates slowly, meaning it can't handle user load. Without user load, the cache doesn't warm up. It's a vicious circle.
Dmitry fundamentally disagrees, stating that quorums and sharding solve the problem. But Andrey insists that the solution is not suitable for everyone. In some situations, a quorum may work, but it adds additional load on the network. NoSQL databases are not suitable in all cases.
The participants of the meetup split into two camps.
Denis and Andrey assert that everything written to disk — databases and others — is currently impossible to achieve in the Kubernetes ecosystem. It is impossible to maintain the integrity and consistency of production data in Kubernetes. This is a fundamental characteristic. Solution: hybrid infrastructure.
Even modern cloud-native databases like MongoDB and Cassandra, or message queues such as Kafka or RabbitMQ, require persistent data storage outside of Kubernetes.
Evgeny argues: 'Databases in Kuber are a trauma related to Russia, or related to enterprise, which is associated with the lack of Cloud Adoption in Russia.' Small or medium companies in the West are all about Cloud. Using Amazon RDS is easier than dealing with Kubernetes yourself. In Russia, they use Kuber 'on-premise' and transfer databases into it when trying to eliminate the zoo of technologies.
Dmitry also disagreed with the statement that no databases can be held in Kubernetes: 'Not all databases are the same. And if you shove a giant relational database in there — absolutely not. If you put in something small and cloud-native, that is morally ready for a semi-ephemeral life, everything will be fine.' Dmitry also mentioned that database management tools are not ready for either Docker or Kuber, which causes significant difficulties.
Ivan is in turn confident that, even if one abstracts from the concepts of stateful and stateless, the ecosystem of enterprise solutions in Kubernetes is still not ready. It is challenging to meet the requirements of legal and regulatory bodies with Kuber. For example, it is impossible to create an identity provision solution where strict guarantees of server identification are required, down to the hardware inserted into the servers. This area is developing, but there is currently no solution.
The participants could not reach an agreement, so there will be no conclusions in this part. Instead, let’s provide a couple of practical examples.
Case 1. Cybersecurity of the 'mega-regulator' with databases outside of Kuber
In the case of an advanced cybersecurity system, using containers and orchestration helps defend against attacks and intrusions. For instance, in one mega-regulator, Denis and his team implemented a combination of an orchestrator with a trained SIEM service that analyzes logs in real-time and detects the process of attack, hacking, or failure. In the event of an attack, an attempt to input something, or in the case of a ransomware intrusion, it quickly brings up containers with applications faster than they can be infected, or faster than an attacker can strike.
Case 2. Partial migration of Booking.com's databases to Kubernetes
In Booking.com, the main database is MySQL with asynchronous replication—there is a master and a whole hierarchy of slaves. By the time Ivan left the company, a project had been launched to migrate slaves that could be 'taken out' with a certain loss.
In addition to the main database, there is a Cassandra installation with custom orchestration that was created even before Kuber entered the mainstream. There are no problems in this regard, but it is persistent on local SSDs. Remote storage, even within the same data center, is not used due to high latency issues.
The third class of databases is the search service of Booking.com, where each node of the service acts as a database. Attempts to migrate the search service to Kuber failed because each node requires 60–80 GB of local storage, which is difficult to 'bring up' and 'warm up.'
As a result, the search engine was not migrated to Kubernetes, and Ivan does not believe there will be new attempts in the near future. The MySQL database was partially migrated: only the slaves, which are not scary to 'take out.' Cassandra has 'settled in' excellently.
Keuze van infrastructuur als een probleem zonder algemene oplossing
Foto door
Stel dat we een nieuw bedrijf hebben, of een bedrijf waar een deel van de infrastructuur ouderwets is. Daar wordt een infrastructuurontwikkelingsplan voor jaren opgesteld. Hoe wordt de beslissing genomen om al dan niet infrastructuur op containers en Kubernetes te bouwen?
Bedrijven die strijden om nanoseconden zijn uitgesloten van de discussie. Gezond conservatisme betaalt zich uit voor de betrouwbaarheid, maar er zijn bedrijven die het waard zijn om nieuwe benaderingen te overwegen.
Ivan: "Ik zou nu zeker een bedrijf in de cloud starten, gewoon omdat het sneller is," hoewel het niet noodzakelijkerwijs goedkoper is. Met de ontwikkeling van durfkapitaal hebben startups geen grote problemen met geld, en de belangrijkste taak is om de markt te veroveren.
Ivan is van mening dat de staat van de huidige infrastructuur een criterium is voor de keuze. Als er in het verleden aanzienlijke investeringen zijn gedaan en het werkt, heeft het geen zin om het opnieuw te doen. Maar als de infrastructuur niet ontwikkeld is en er problemen zijn met tools, veiligheid en monitoring, dan is het de moeite waard om naar gedistribueerde infrastructuur te kijken.
De belasting moet in ieder geval worden betaald, en Ivan zou degene betalen die hem in de toekomst minder zou laten betalen. "Omdat ik gewoon veel verder kan komen door in een trein te rijden die door anderen wordt getrokken dan wanneer ik in een andere trein stap die ik zelf van brandstof moet voorzien." zegt Ivan. Wanneer een bedrijf nieuw is en de eisen aan latency enkele tientallen milliseconden zijn, zou Ivan naar 'operators' kijken waar klassieke databases nu worden 'omgebouwd'. Ze zetten de replicatieketen op, die automatisch overschakelt bij een failover en dergelijke...
Voor een klein bedrijf met een paar servers in Kubernetes heeft het geen zin, - stelt Andrei. Maar als ze van plan zijn om te groeien naar honderd servers of meer, is automatisering en een resource management systeem nodig. In 90% van de gevallen rechtvaardigen de kosten de uitgaven. Dit geldt ongeacht het niveau van belasting en middelen. Voor iedereen, van startups tot grote bedrijven met een miljoenenpubliek, is het de moeite waard om geleidelijk naar producten voor containerorkestratie te kijken. "Ja, dat is echt de toekomst," is Andrei overtuigd.
Denis benoemde twee hoofdcriteria - schaalbaarheid en bedrijfscontinuïteit. Hij zal de tools kiezen die het beste voor deze taak passen. 'Dit kan een onbenoembare oplossing zijn die bij elkaar is geknutseld, met Nutanix Community Edition. Het kan ook een tweede lijn zijn in de vorm van een applicatie op Kubernetes met een database aan de achterkant, die gerepliceerd wordt en gedefinieerde RTO en RPO parameters heeft' (herstel tijd/punt doelstellingen — voorbeeld).
Yevgeny wees op een mogelijk probleem met de kadering. Momenteel zijn er niet veel hooggekwalificeerde specialisten op de markt die verstand hebben van de 'inners'. Inderdaad, als de gekozen technologie verouderd is, is het moeilijk om iemand aan te nemen, behalve oudere, verveelde en levensmoe mensen. Hoewel andere deelnemers van mening zijn dat dit een kwestie is van opleidingen.
Als we de keuze moeten maken: een klein bedrijf starten in de Public Cloud met databases in Amazon RDS of 'on-premise' met databases in Kubernetes, dan, ondanks enkele nadelen, werd de keuze van de deelnemers Amazon RDS.
Aangezien de meeste deelnemers aan de meetup niet uit het 'bloederige' enterprise-omgeving komen, zijn gedistribueerde oplossingen waar naar gestreefd moet worden. Dataopslagsystemen moeten gedistribueerd, betrouwbaar zijn en latencies creëren die gemeten worden in milliseconden, maximaal in tientallen., concludeerde Andrei.
Beoordeling van het gebruik van Kubernetes
De deelnemer Anton Zhbankov stelde een vangvraag aan de apologisten van Kubernetes: hoe hebben jullie de technische en economische onderbouwing uitgevoerd? Waarom Kubernetes, waarom geen virtual machines bijvoorbeeld?
Foto door
Dmitry en Ivan gaven antwoord. In beide gevallen werd door middel van vallen en opstaan een reeks oplossingen ontwikkeld, waardoor beide deelnemers bij Kubernetes uitkwamen. Nu begint het bedrijf zelfstandig software te ontwikkelen die het waard is om naar Kubernetes te migreren. Het gaat niet over klassieke externe systemen, zoals 1C. Kubernetes helpt wanneer ontwikkelaars snel releases moeten maken, bij ononderbroken Continuous Improvement.
Andrei's team heeft geprobeerd een schaalbaar cluster op basis van virtuele machines te maken. Nodes vielen als dominostenen, wat soms leidde tot het falen van het cluster. 'Theoretisch gezien is het mogelijk om het handmatig af te maken en te onderhouden, maar het is vervelend. En als er een oplossing op de markt is die 'out of the box' werkt, dan gaan we daar met plezier naartoe. En dat hebben we uiteindelijk gedaan.', zegt Andrei.
Er zijn standaarden voor een dergelijke analyse en berekening, maar niemand kan zeggen hoe juist ze zijn op echte hardware in de praktijk. Voor de berekeningen is het ook belangrijk om elk hulpmiddel en ecosysteem te begrijpen, maar dat is onmogelijk.
Wat staat ons te wachten
Foto door
Wanneer technologieën zich ontwikkelen, verschijnen er steeds meer losse stukjes, en dan gebeurt er een faseovergang waarbij er een leverancier komt die genoeg 'kapitaal' heeft vergaard om alles samen te voegen in één hulpmiddel.
Lijkt het je niet dat er een moment zal komen waarop er een hulpmiddel verschijnt dat zoals Ubuntu is voor de wereld van Linux? Misschien zal één enkel hulpmiddel voor containerisatie en orchestratie ook Kubernetes omvatten. Het zal eenvoudig zijn om on-premise clouds te bouwen.
Ivan gaf het volgende antwoord: "Google bouwt momenteel Anthos — dit is hun pakketaanbieding die de cloud uitrolt en Kubernetes, Service Mesh, monitoring omvat — alles wat nodig is voor microservices in 'on-premise'. We bevinden ons bijna in de toekomst."
Denis noemde ook Nutanix en VMWare met het product vRealize Suite, die in staat zijn om een vergelijkbare taak zonder containerisatie uit te voeren.
Dmitry deelde zijn mening dat het verminderen van 'pijn' en het verlagen van de belasting twee richtingen zijn waarin verbeteringen te verwachten zijn.
Samenvattend de discussie, laten we de volgende problemen van de moderne infrastructuur benadrukken
- Drie deelnemers gaven meteen het probleem aan met stateful.
- Van verschillende soorten beveiligingsproblemen, inclusief de kans dat er uiteindelijk verschillende versies van Python, applicatieservers en componenten in Docker zullen zijn.
Overmatige uitgaven, waarover het beter is om een aparte meetup te organiseren.
Het probleem van training, aangezien orchestratie een complexe ecosysteem vormt.
Een algemeen probleem in de sector is het gebruik van hulpmiddelen niet volgens hun bestemming.Het is aan jou om de overige conclusies te trekken. Voorlopig blijft de indruk bestaan dat de combinatie van Docker en Kubernetes het moeilijk heeft om een 'centrale' rol in het systeem te worden. Bijvoorbeeld, besturingssystemen worden eerst op hardware geïnstalleerd, wat niet gezegd kan worden over containers en orchestratie. Misschien zullen in de toekomst besturingssystemen en containers fuseren met cloud management software.
Foto doorBij deze wil ik mijn moeder groeten en herinneren dat we een Facebook-groep hebben , kanaal met interessante publicaties uit verschillende techblogs. En mijn kanaal , waar ik vertel over het beheer van ontwikkeling in productbedrijven.
Bron: habr.com
