I slutningen af maj afholdt vi et online-mødet om . Vi talte om containere, Kubernetes og orkestrering generelt, om kriterier til valg af infrastruktur og meget mere. Deltagerne delte erfaringer fra deres egen praksis.
Deltagere:
- Evgeny Potapov, CEO for „ITSumma“. Mere end halvdelen af hans kunder er enten allerede i gang med at overgå eller ønsker at overgå til Kubernetes.
- Dmitry Stolyarov, CTO for „Flant“. Har over 10 års erfaring med containersystemer.
- Denis Remchukov (aka Eric Oldmann), COO for argotech.io, ex-RАО ЕЭС. Lovede at fortælle om erfaringer fra „den blodige“ enterprise.
- Andrei Fedorovsky, CTO for „News360.com“Efter opkøbet af virksomheden af en anden aktør er han ansvarlig for en række ML og AI projekter og infrastrukturen.
- Ivan Kruglov, systemingeniør, ex–Booking.com.Det er ham, der med egne hænder har gjort meget for Kubernetes.
Emner:
- Deltagernes indsigter om containere og orkestrering (Docker, Kubernetes mv.); hvad de har prøvet i praksis eller analyseret.
- Case: I virksomheden bygger de en plan for udviklingen af infrastrukturen over flere år. Hvordan besluttes det, om man skal bygge (eller overføre den nuværende) infrastruktur på containere og Kubernetes eller ej?
- Udfordringer i cloud-native-verdenen, hvad der mangler, lad os fantasere om, hvad der vil ske i morgen.
Der opstod en interessant diskussion, deltagernes meninger var så forskellige og gav så mange kommentarer, at man ønsker at dele dem med dig. Der er , og nedenfor – et resumé af diskussionen.
Er Kubernetes allerede en standard eller en fremragende marketing?
„Vi kom til det (Kubernetes. — Red.) dengang, da ingen endnu kendte til det. Vi kom til det, da det endnu ikke eksisterede. Vi ønskede det før det“ — Dmitry Stolyarov
Foto fra Reddit.com
For 5-10 år siden eksisterede der et væld af værktøjer, og der var ikke nogen fælles standard. Hver sjette måned dukkede der et nyt produkt op, nogle gange endda flere. Først Vagrant, så Salt, Chef, Puppet,… „og du er hver sjette måned nødt til at bygge din infrastruktur om. Du har fem administratorer, der konstant er optaget af at gen skrive konfigurationer“ — husker Andrei Fedorovsky. Han mener, at Docker og Kubernetes „har lagt konkurrenterne i graven“. Docker blev standarden i løbet af de seneste fem år, Kubernetes — i de seneste to år. Og det er godt for industrien..
Dmitrij Stoljarev og hans team elsker Kubernetes. De har ønsket sig et sådant værktøj, før det kom til verden, og de kom til det, da ingen endnu kendte til det. På nuværende tidspunkt tager de ikke kunder, hvis de ikke forventer at implementere Kubernetes. Ifølge Dmitrij har virksomheden "mange enorme successhistorier om omdannelse af skræmmende legacy."
Kubernetes er ikke kun en containerorkestrering, det er et konfigurationsstyringssystem med et veludviklet API, netværkskomponenter, L3 belastningsbalancering og Ingress-controllere, der gør det relativt nemt at administrere ressourcer, skalere og abstrahere fra de underliggende infrastrukturlag.
Desværre skal man i vores liv betale for alt. Og denne skat er høj, især når man taler om overgangen til Kubernetes for virksomheder med en veludviklet infrastruktur, som Ivan Kruglov mener. Han kunne frit arbejde både i en virksomhed med traditionel infrastruktur og med Kubernetes. Det vigtigste er at forstå virksomhedens og markedets karakteristika. Men for eksempel for Evgenij Potapov, der ville generalisere Kubernetes til ethvert containerorkestreringsværktøj, er et sådant spørgsmål ikke aktuelt.
Evgenij trak en parallel til situationen i 1990'erne, da objektorienteret programmering kom frem som en måde at programmere komplekse applikationer på. På det tidspunkt ophørte debatterne ikke, og nye værktøjer, der understøttede OOP, dukkede op. Derefter kom mikrotjenester som en måde at komme væk fra den monolitiske koncept. Dette førte i sin tur til oprettelsen af containere og værktøjer til styring af dem. "Jeg tror, at vi snart vil komme til det punkt, hvor spørgsmålet om, hvorvidt man skal skrive små applikationer som mikrotjenester, ikke engang vil blive stillet, det vil blive skrevet som en mikrotjeneste som standard," mener han. Tilsvarende vil Docker og Kubernetes over tid blive en standardløsning uden behov for valg.
Problemet med databaser er stateless
Foto af
I dag findes der mange opskrifter til at køre databaser i Kubernetes. Selv hvordan man adskiller den del, der arbejder med disk I/O fra den, man kunne kalde applikationsdelen af databasen. Er det muligt, at databaser i fremtiden vil ændre sig så meget, at de vil blive leveret i en pakke, hvor den ene del orkestreres gennem Docker og Kubernetes, mens den anden del af infrastrukturen, gennem separat software, vil levere lagringsdelen? Vil databaser ændre sig som produkt?
Denne beskrivelse ligner queue management, men kravene til pålidelighed og synkronisering af informationer i traditionelle databaser er betydeligt højere, mener Andrey. Cache hit ratio i normale databaser ligger på niveauet 99 %. Hvis en worker fejler, startes en ny, og cachen "opvarmes" fra bunden. Indtil cachen ikke er opvarmet, arbejder workeren langsomt, hvilket betyr, at man ikke kan påføre den brugerbelastning. Så længe der ikke er nogen brugerbelastning, bliver cachen ikke opvarmet. Det er en ond cirkel.
Dmitry er grundlæggende uenig; quorum og sharding løser problemet. Men Andrey insisterer på, at løsningen ikke passer til alle. I nogle situationer kan quorum være passende, men det lægger en ekstra belastning på netværket. NoSQL databasen er ikke altid den rigtige løsning.
Deltagerne i meetuppet delte sig op i to lejre.
Denis og Andrey hævder, at alt, hvad der skrives til disk – databaser og andet – er umuligt at gøre i den nuværende Kuber-økosystem. Det er umuligt at bevare integritet og konsistens af produktionsdata i Kubernetes. Det er en grundlæggende egenskab. Løsning: hybrid infrastruktur.
Selv moderne cloud native databaser som MongoDB og Cassandra, eller beskedkøer som Kafka eller RabbitMQ, kræver vedvarende datalagring uden for Kubernetes.
Evgeny protesterer: "Databaser i Kuber er en overfladisk traume, eller en næsten enterprise-lignende situation, der skyldes, at Cloud Adoption ikke eksisterer i Rusland." Små eller mellemstore virksomheder i Vesten er cloud-baserede. Amazon RDS databaser er enklere at bruge end selv at roote med Kubernetes. I Rusland anvender man Kuber "on-premise" og flytter databaser ind i det, når man forsøger at slippe af med dyreblandingen.
Dmitry var også uenig i udsagnet, at ingen databaser kan opbevares i Kubernetes: "Der er forskel på databaser. Og hvis man propper en kæmpestor relationel database ind, så bør man ikke. Hvis man skubber noget småt og cloud native ind, der er moralsk klar til et semi-æterisk liv, så vil alt være godt." Dmitry nævnte også, at værktøjer til databasehåndtering ikke er klar til hverken Docker eller Kuber, hvilket derfor medfører store vanskeligheder.
Ivan er overbevist om, at selvom man ser bort fra begreberne stateful og stateless, så er økosystemet af virksomhedsløsninger i Kubernetes endnu ikke klar. Det er svært at opfylde kravene fra lovgivningsmæssige og regulerende organer med Kubernetes. For eksempel er det umuligt at lave en identitetsløsning, hvor der kræves strenge garantier for serverens identifikation, helt ned til den hardware, der er installeret i serverne. Dette område er under udvikling, men der er endnu ikke nogen løsning.
Deltagerne kunne ikke nå til enighed, så der vil ikke følge nogen konklusioner i denne del. Lad os i stedet give et par praktiske eksempler.
Case 1. Cybersikkerhed hos 'megaregulatoren' med databaser uden for Kubernetes
I tilfælde af et avanceret cybersikkerhedssystem tillader brugen af containere og orkestrering at afværge angreb og indtrængen. For eksempel implementerede Denis og hans team i en megaregulator en sammenkobling af en orkestrator med en trænet SIEM-tjeneste, som analyserer logs i realtid og identificerer angrebs-, brud- eller fejlprocesser. I tilfælde af et angreb, forsøg på at lægge noget ind, eller ved indtrængen af ransomware, rejser den via orkestratoren containere med applikationer hurtigere, end de bliver inficeret, eller hurtigere end angriberen kan angribe dem.
Case 2. Delvis flytning af databaser fra Booking.com til Kubernetes
I Booking.com er den primære database MySQL med asynkron replikation – der er en master og en komplet hierarki af slaver. På tidspunktet for Ivans afgang fra virksomheden var et projekt blevet startet for at flytte slaver, som kan 'skydes af' med en vis skade.
Udover den primære database er der en installation af Cassandra med en skræddersyet orkestrering, der blev skrevet, før Kubernetes blev mainstream. Der er ingen problemer på den front, men den har persistent på lokale SSD'er. Fjernopbevaring, selv inden for samme datacenter, anvendes ikke på grund af problemet med høj ventetid.
Den tredje klasse af databaser er Booking.coms søgetjeneste, hvor hver node i tjenesten er en database. Forsøg på at flytte søgetjenesten til Kubernetes har været uden held, fordi hver node er 60–80 Gb lokal storage, hvilket er svært at 'løfte' og 'opvarme'.
Som følge heraf blev søgemaskinen ikke flyttet til Kubernetes, og Ivan mener ikke, der vil komme nye forsøg i den nærmeste fremtid. MySQL-databasen blev halvdelen flyttet: kun slaver, som det ikke er skræmmende at 'skyde af'. Cassandra har klaret sig fremragende.
Valg af infrastruktur som en opgave uden en generel løsning
Foto af
Lad os antage, at vi har et nyt firma, eller et firma, hvor en del af infrastrukturen er bygget gammeldags. De skaber en plan for infrastrukturudvikling for årene fremover. Hvordan træffes beslutningen om, hvorvidt infrastrukturen skal bygges på containere og Kubernetes eller ej?
Virksomheder, der kæmper for nanosekunder, er udelukket fra diskussionen. Sund konservatisme betaler sig af hensyn til pålidelighed, men alligevel er der virksomheder, som bør overveje nye tilgange.
Ivan: "Jeg ville uden tvivl starte en virksomhed i cloud i dag, bare fordi det er hurtigere," selvom det ikke nødvendigvis er billigere. Med udviklingen af venturekapital har startups ikke store problemer med penge, og den primære opgave er at erobre markedet.
Ivan mener, at udviklingen af den nuværende infrastruktur er et kriterium for valg. Hvis der i fortiden har været betydelige investeringer, og det fungerer, så giver det ikke mening at ændre det. Men hvis infrastrukturen ikke er udviklet, og der er problemer med værktøjer, sikkerhed og overvågning, så giver det mening at se på distribueret infrastruktur.
Skatten skal betales uanset hvad, og Ivan ville betale den, der tillader ham at betale mindre i fremtiden. "Fordi simpelthen ved at tage en tog, der drives af andre, vil jeg komme meget længere, end hvis jeg tager det andet tog, hvor jeg selv skal fylde brændstof." — siger Ivan. Når firmaet er nyt, og kravene til latency er ti millisekunder, ville Ivan kigge i retning af "operatørerne", som i dag "forpakker" klassiske databaser. De opretter en replikationskæde, der selv skifter ved fejl og så videre...
For et lille firma med et par servere i Kubernetes giver det ingen mening, — hævder Andrei. Men hvis det planlægger at vokse til hundrede servere eller mere, så er der behov for automatisering og ressourcehåndteringssystem. 90 % af tilfældene retfærdiggør omkostningerne. Dette gælder uanset belastningsniveau og ressourcer. Alle, fra startups til store virksomheder med millioner af brugere, bør gradvist se mod produkter til orkestrering af containere. "Ja, det er virkelig fremtiden," er Andrei sikker på.
Denis nævnte to hovedkriterier — skalerbarhed og driftets pålidelighed. Han vil vælge de værktøjer, der passer bedst til opgaven. «Dette kan være en no-name bygget på stedet, der kører Nutanix Community Edition. Det kan være en applikation på Kuber med en database på backend, der replikeres og har definerede RTO og RPO parametre» (recovery time/point objectives — eksempel).
Yevgeny nævnte et muligt problem med arbejdskraften. I øjeblikket er der ikke så mange højt kvalificerede specialister på markedet, der forstår 'indmaden'. Faktisk, hvis den valgte teknologi er gammel, er det svært at ansætte nogen, der ikke er ældre, kede sig og er trætte af livet. Mens andre deltagere mener, at det er et spørgsmål om uddannelse af arbejdsstyrken.
Hvis spørgsmålet skal stilles: skal man starte en lille virksomhed i Public Cloud med databaser i Amazon RDS eller 'on premise' med databaser i Kubernetes, så blev valget blandt deltagerne Amazon RDS på trods af visse ulemper.
Da de fleste lyttere af meetuppet ikke er fra 'den blodige' enterprise, så fordelte løsninger er det, man skal stræbe efter. Lagringssystemer skal være fordelte, pålidelige, og skabe latens målt i millisekunder, maksimalt i tiendedele., - opsummerede Andrei.
Vurdering af brugen af Kubernetes
Lytteren Anton Zhbankov stillede et spørgsmål til tilhængerne af Kubernetes: hvordan valgte og gennemførte man den teknisk-økonomiske begrundelse? Hvorfor Kubernetes, hvorfor ikke virtuelle maskiner, for eksempel?
Foto af
Dmitry og Ivan svarede ham. I begge tilfælde, gennem forsøg og fejl, blev en rækkefølge af beslutninger lavet, hvorved begge deltagere kom til Kubernetes. Nu begynder virksomheder at udvikle software, som giver mening at flytte til Kube. Det drejer sig ikke om klassiske tredjepartssystemer, såsom 1C. Kubernetes hjælper, når udviklerne hurtigt skal lave udgivelser i forbindelse med kontinuerligt forbedring.
Andreis team forsøgte at lave en skalerbar klynge baseret på virtuelle maskiner. Noderne faldt som dominobrikker, hvilket nogle gange førte til, at klyngen faldt. «Teoretisk kan man færdiggøre og vedligeholde det manuelt, men det er besværligt. Og hvis der er en løsning på markedet, der fungerer ud af boksen, så går vi med glæde efter det. Og vi er derfor gået over.» - fortæller Andrei.
Der er standarder for sådan analyse og beregning, men ingen kan sige, hvor nøjagtige de er i realiteten på faktisk udstyr i brug. For beregninger er det også vigtigt at forstå hvert værktøj og økosystem, men det er umuligt.
Hvad venter os
Foto af
Når teknologier udvikler sig, dukker der flere og flere disparate stykker op, og derefter sker der et faseovergang, hvor der kommer en leverandør, som har spildt nok 'boble', så alt kan samles i ét værktøj.
Virker det ikke som om, der vil komme et værktøj, der skal til for verdenen af Linux som Ubuntu? Måske vil et samlet værktøj til containerisering og orkestrering også inkludere Kubernetes. Det vil blive nemt at bygge on-premise clouds.
Ivan gav svaret: 'Google bygger i øjeblikket Anthos - det er deres pakkeløsning, der udrulder cloud og inkluderer Kubernetes, Service Mesh, overvågning - alt det, der er nødvendigt for mikrotjenester i on-premise. Vi er næsten i fremtiden.'
Denis nævnte også Nutanix og VMware med produktet vRealize Suite, som kan håndtere en lignende opgave uden containerisering.
Dmitry delte sin mening om, at reduktion af 'smerte' og faldende skat er to områder, hvor man kan forvente forbedringer.
For at opsummere diskussionen, fremhæver vi følgende problemer med moderne infrastruktur
- Hele tre deltagere pegede på problemet med stateful.
- Diverse sikkerhedssupportproblemer, herunder sandsynligheden for, at der i Docker ender med flere versioner af Python, applikationsservere og komponenter.
Overforbrug, om hvilket det er bedre at lave et separat meetup.
Uddannelsesproblemet, da orkestrering repræsenterer et komplekst økosystem.
En generel brancheproblematik - brug af værktøjer ikke efter hensigten.Det står jer frit for at drage de øvrige konklusioner. Indtil videre er der en følelse af, at kombinationen af Docker+Kubernetes har svært ved at blive en 'central' del af systemet. For eksempel installeres operativsystemer først på maskinen, noget der ikke kan siges om containere og orkestrering. Måske vil operativsystemer og containere med cloud management software smelte sammen i fremtiden.
Foto afJeg vil benytte lejligheden til at sende et hej til min mor, og minde om, at vi har en Facebook-gruppe , kanal med interessante indlæg fra forskellige tech-blogger. Og min kanal , hvor jeg taler om udviklingsledelse i produktvirksomheder.
Kilde: habr.com
