I slutningen af maj holdt et onlinemøde om emnet . Vi talte om containere, Kubernetes og orkestrering i princippet, kriterier for valg af infrastruktur og meget mere. Deltagerne delte cases fra deres egen praksis.
Deltagere:
- Evgeniy Potapov, administrerende direktør for ITSumma. Mere end halvdelen af deres kunder flytter enten allerede eller ønsker at skifte til Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Har 10+ års erfaring med at arbejde med containersystemer.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, ex-RAO UES. Han lovede at tale om sager i den "blodige" virksomhed.
- Andrey Fedorovsky, CTO "News360.com"Efter at have købt virksomheden af en anden spiller, er han ansvarlig for en række ML- og AI-projekter og infrastruktur.
- Ivan Kruglov, systemingeniør, ex-Booking.com.Den samme person, der gjorde meget med Kubernetes med sine egne hænder.
Temaer:
- Deltagernes indsigt om containere og orkestrering (Docker, Kubernetes osv.); hvad der blev prøvet i praksis eller analyseret.
- Case: Virksomheden bygger en infrastrukturudviklingsplan i årevis. Hvordan træffes beslutningen, om der skal bygges (eller migreres den nuværende) infrastruktur til containere og Kuber eller ej?
- Problemer i den cloud-native verden, hvad der mangler, lad os forestille os, hvad der vil ske i morgen.
En interessant diskussion fulgte, deltagernes meninger var så forskellige og forårsagede så mange kommentarer, at jeg gerne vil dele dem med jer. Spise , og nedenfor er et resumé af diskussionen.
Er Kubernetes allerede en standard eller god markedsføring?
“Vi kom til det (Kubernetes. - Red.), da ingen vidste om det endnu. Vi kom til ham, selv når han ikke var der. Vi ønskede det før" - Dmitry Stolyarov
Foto fra Reddit.com
For 5-10 år siden var der enormt mange værktøjer, og der var ikke en enkelt standard. Hvert halve år dukkede et nyt produkt op, eller endda mere end et. Først Vagrant, derefter Salt, Chef, Puppet, ... "og du genopbygger din infrastruktur hver sjette måned. Du har fem administratorer, som konstant har travlt med at omskrive konfigurationer,” husker Andrey Fedorovsky. Han mener, at Docker og Kubernetes har "overfyldt" resten. Docker er blevet en standard i de sidste fem år, Kubernetes i de sidste to år. Og det er godt for branchen..
Dmitry Stolyarov og hans team elsker Kuber. De ville have sådan et værktøj, før det dukkede op, og kom til det, da ingen vidste om det. I øjeblikket tager de af bekvemmelighedsgrunde ikke en klient, hvis de forstår, at de ikke vil implementere Kubernetes med ham. Samtidig har virksomheden ifølge Dmitry "mange gigantiske succeshistorier om at genskabe den forfærdelige arv."
Kubernetes er ikke kun containerorkestrering, det er et konfigurationsstyringssystem med en udviklet API, en netværkskomponent, L3-balancering og Ingress-controllere, som gør det relativt nemt at administrere ressourcer, skalere og abstrahere fra de nederste lag af infrastrukturen.
Desværre skal vi i vores liv betale for alt. Og denne skat er stor, især hvis vi taler om overgangen til Kubernetes af en virksomhed med en udviklet infrastruktur, som Ivan Kruglov mener. Han kunne frit arbejde både i en virksomhed med en traditionel infrastruktur og med Kuber. Det vigtigste er at forstå virksomhedens og markedets egenskaber. Men for eksempel for Evgeny Potapov, som ville generalisere Kubernetes til ethvert containerorkestreringsværktøj, opstår et sådant spørgsmål ikke.
Evgeniy tegnede en analogi med situationen i 1990'erne, hvor objektorienteret programmering dukkede op som en måde at programmere komplekse applikationer på. På det tidspunkt fortsatte debatten, og nye værktøjer dukkede op til at understøtte OOP. Så opstod mikrotjenester som en måde at bevæge sig væk fra det monolitiske koncept. Dette førte igen til fremkomsten af containere og containerstyringsværktøjer. "Jeg tror, at vi snart kommer til et tidspunkt, hvor der ikke vil være nogen tvivl om, hvorvidt det er værd at skrive en lille mikroserviceapplikation, den bliver skrevet som en mikroservice som standard," mener han. Ligeledes vil Docker og Kubernetes med tiden blive standardløsningen uden behov for valg.
Problemet med databaser i statsløse
Photo by
I dag er der mange opskrifter til at køre databaser i Kubernetes. Selv hvordan man adskiller den del, der fungerer med I/O-disken, fra, betinget, applikationsdelen af databasen. Er det muligt, at databaser i fremtiden vil ændre sig så meget, at de vil blive leveret i en boks, hvor en del vil blive orkestreret gennem Docker og Kubernetes, og i en anden del af infrastrukturen, gennem separat software, vil lagerdelen blive leveret ? Vil baserne ændre sig som et produkt?
Denne beskrivelse ligner køstyring, men kravene til pålidelighed og synkronisering af information i traditionelle databaser er meget højere, mener Andrey. Cache hit ratio i normale databaser forbliver på 99 %. Hvis en arbejder går ned, lanceres en ny, og cachen "varmes op" fra bunden. Indtil cachen er varmet op, arbejder arbejderen langsomt, hvilket betyder, at den ikke kan indlæses med brugerbelastning. Selvom der ikke er nogen brugerindlæsning, varmes cachen ikke op. Det er en ond cirkel.
Dmitry er grundlæggende uenig - kvorummer og sønderdeling løser problemet. Men Andrey insisterer på, at løsningen ikke er egnet for alle. I nogle situationer er quorum velegnet, men det lægger yderligere belastning på netværket. En NoSQL-database er ikke egnet i alle tilfælde.
Meetup-deltagerne blev delt op i to lejre.
Denis og Andrey hævder, at alt, hvad der er skrevet til disk - databaser og så videre - er umuligt at gøre i det nuværende Kuber-økosystem. Det er umuligt at opretholde integriteten og konsistensen af produktionsdata i Kubernetes. Dette er et grundlæggende træk. Løsning: hybrid infrastruktur.
Selv moderne cloud-baserede databaser som MongoDB og Cassandra eller beskedkøer som Kafka eller RabbitMQ kræver vedvarende datalagre uden for Kubernetes.
Evgeniy indvender: "Baserne i Kubera er en næsten russisk eller næsten virksomhedsskade, som er forbundet med det faktum, at der ikke er nogen skyadoption i Rusland." Små eller mellemstore virksomheder i Vesten er Cloud. Amazon RDS-databaser er nemmere at bruge end selv at pille ved Kubernetes. I Rusland bruger de Kuber "on-premise" og overfører baser til den, når de forsøger at slippe af med zoologisk have.
Dmitry var også uenig i udsagnet om, at ingen databaser kan opbevares i Kubernetes: "Base er forskellig fra base. Og hvis du pusher en kæmpe relationel database, så under ingen omstændigheder. Hvis du skubber til noget småt og cloud native, som er mentalt forberedt til semi-flyktigt liv, vil alt være godt.” Dmitry nævnte også, at databasestyringsværktøjer ikke er klar til hverken Docker eller Kuber, så der opstår store vanskeligheder.
Ivan er til gengæld sikker på, at selvom vi abstraherer fra begreberne statslig og statsløs, er økosystemet af virksomhedsløsninger i Kubernetes endnu ikke klar. Med Kuber er det svært at opretholde lovgivningsmæssige og regulatoriske krav. Eksempelvis er det umuligt at lave en identitetsbestemmelsesløsning, hvor der kræves strenge serveridentifikationsgarantier, helt ned til den hardware, der indsættes i serverne. Dette område er under udvikling, men der er endnu ingen løsning.
Deltagerne kunne ikke blive enige, så der vil ikke blive draget konklusioner i denne del. Lad os give et par praktiske eksempler.
Case 1. Cybersikkerhed af en "mega-regulator" med baser uden for Kubera
I tilfælde af et udviklet cybersikkerhedssystem gør brugen af containere og orkestrering det muligt at bekæmpe angreb og indtrængen. For eksempel implementerede Denis og hans team i en megaregulator en kombination af en orkestrator med en trænet SIEM-tjeneste, der analyserer logfiler i realtid og bestemmer processen med et angreb, hacking eller fejl. I tilfælde af et angreb, et forsøg på at placere noget, eller i tilfælde af en ransomware-virusinvasion, opfanger den via orkestratoren containere med applikationer hurtigere end de bliver inficeret, eller hurtigere end angriberen angriber dem.
Case 2. Delvis migrering af Booking.com-databaser til Kubernetes
I Booking.com er hoveddatabasen MySQL med asynkron replikering – der er en master og et helt hierarki af slaver. Da Ivan forlod virksomheden, blev et projekt iværksat for at overføre slaver, der kunne "skydes" med visse skader.
Ud over hovedbasen er der en Cassandra-installation med selvskrevet orkestrering, som er skrevet allerede før Kuber kom ind i mainstream. Der er ingen problemer i denne henseende, men det er vedvarende på lokale SSD'er. Fjernlagring, selv inden for det samme datacenter, bruges ikke på grund af problemet med høj latenstid.
Den tredje klasse af databaser er Booking.com-søgetjenesten, hvor hver serviceknude er en database. Forsøg på at overføre søgetjenesten til Kuber mislykkedes, fordi hver node har 60-80 GB lokal lagerplads, hvilket er svært at "løfte" og "varme op".
Som følge heraf blev søgemaskinen ikke overført til Kubernetes, og Ivan tror ikke, at der vil komme nye forsøg i den nærmeste fremtid. MySQL-databasen blev overført til halvdelen: kun slaver, som ikke er bange for at blive "skudt". Cassandra er faldet perfekt til.
Infrastrukturvalg som en opgave uden en generel løsning
Photo by
Lad os sige, at vi har en ny virksomhed, eller en virksomhed, hvor en del af infrastrukturen er bygget på den gamle måde. Det bygger en infrastrukturudviklingsplan i årevis. Hvordan træffes beslutningen, om der skal bygges infrastruktur på containere og Kuber eller ej?
Virksomheder, der kæmper i nanosekunder, er udelukket fra diskussionen. Sund konservatisme betaler sig i forhold til pålidelighed, men der er stadig virksomheder, der bør overveje nye tilgange.
Ivan: "Jeg ville helt klart starte et firma på cloud nu, simpelthen fordi det er hurtigere," selvom det ikke nødvendigvis er billigere. Med udviklingen af venturekapitalisme har startups ingen store problemer med penge, og hovedopgaven er at erobre markedet.
Det er Ivan af den opfattelse udviklingen af den nuværende infrastruktur er et udvælgelseskriterium. Hvis der tidligere har været en seriøs investering, og den virker, så nytter det ikke noget at lave det om. Hvis infrastrukturen ikke er udviklet, og der er problemer med værktøjer, sikkerhed og overvågning, så giver det mening at se på en distribueret infrastruktur.
Skatten skal under alle omstændigheder betales, og Ivan ville betale den, der gav ham mulighed for at betale mindre i fremtiden. "For simpelthen i kraft af, at jeg kører i et tog, som andre flytter, vil jeg rejse meget længere, end hvis jeg sætter mig på et andet tog, som jeg selv skal putte brændstof i." siger Ivan. Når virksomheden er ny, og latenskravene er titusvis af millisekunder, så ville Ivan se mod de "operatører", som klassiske databaser er "indpakket" i i dag. De rejser en replikeringskæde, som skifter sig selv i tilfælde af failover osv.
For en lille virksomhed med et par servere giver Kubera ingen mening,” siger Andrey. Men hvis det planlægger at vokse til hundredvis af servere eller flere, så har det brug for automatisering og et ressourcestyringssystem. 90% af tilfældene er prisen værd. Desuden uanset belastningsniveau og ressourcer. Det giver mening for alle, fra startups til store virksomheder med et publikum på millioner, gradvist at se mod containerorkestreringsprodukter. "Ja, det er virkelig fremtiden," er Andrey sikker.
Denis skitserede to hovedkriterier - skalerbarhed og driftsstabilitet. Han vil udvælge de værktøjer, der er bedst egnede til opgaven. "Det kunne være et noname samlet på dine knæ, og det har Nutanix Community Edition på sig. Dette kunne være en anden linje i form af en applikation på Kuber med en database på backend, som er replikeret og har specificerede RTO- og RPO-parametre" (gendannelsestid/punktmål - ca.).
Evgeniy identificerede et muligt problem med personalet. I øjeblikket er der ikke mange højt kvalificerede specialister på markedet, der forstår "moden". Faktisk, hvis den valgte teknologi er gammel, så er det svært at ansætte andre end midaldrende mennesker, der keder sig og er trætte af livet. Selvom andre deltagere mener, at der er tale om uddannelse af personale.
Hvis vi stiller spørgsmålet om valg: at lancere en lille virksomhed i Public Cloud med databaser i Amazon RDS eller "on premise" med databaser i Kubernetes, så blev Amazon RDS på trods af nogle mangler deltagernes valg.
Da størstedelen af meetup-lytterne ikke er fra den "blodige" virksomhed, altså distribuerede løsninger er det, vi bør stræbe efter. Datalagringssystemer skal være distribuerede, pålidelige og skabe latens målt i enheder af millisekunder, højst tiere“, opsummerede Andrey.
Vurdering af Kubernetes-brug
Lytteren Anton Zhbankov stillede et fældespørgsmål til Kubernetes apologeter: hvordan valgte og gennemførte du en forundersøgelse? Hvorfor Kubernetes, hvorfor ikke virtuelle maskiner, for eksempel?
Photo by
Dmitry og Ivan svarede på det. I begge tilfælde blev der gennem forsøg og fejl truffet en række beslutninger, som resulterede i, at begge deltagere ankom til Kubernetes. Nu begynder virksomheder selvstændigt at udvikle software, der giver mening at overføre til Kuber. Vi taler ikke om klassiske tredjepartssystemer, såsom 1C. Kubernetes hjælper, når udviklere hurtigt skal lave udgivelser, med konstant kontinuerlig forbedring.
Andreys team forsøgte at skabe en skalerbar klynge baseret på virtuelle maskiner. Noder faldt som dominobrikker, hvilket nogle gange førte til sammenbruddet af klyngen. »Teoretisk set kan man gøre det færdigt og støtte det med hænderne, men det er kedeligt. Og hvis der er en løsning på markedet, der giver dig mulighed for at arbejde ud af boksen, så går vi gerne efter det. Og vi skiftede som et resultat,” siger Andrey.
Der er standarder for sådan analyse og beregning, men ingen kan sige, hvor nøjagtige de er på rigtig hardware i drift. Til beregninger er det også vigtigt at forstå hvert værktøj og økosystem, men det er ikke muligt.
Hvad venter os
Photo by
Efterhånden som teknologien udvikler sig, dukker flere og flere uensartede stykker op, og så sker der en faseovergang, en leverandør dukker op, som har dræbt nok dej til, at alt kan samles i et enkelt værktøj.
Tror du, at der kommer et tidspunkt, hvor der vil være et værktøj som Ubuntu til Linux-verdenen? Måske vil et enkelt containeriserings- og orkestreringsværktøj omfatte Kuber. Det vil gøre det nemt at bygge on-premise clouds.
Svaret blev givet af Ivan: "Google bygger nu Anthos - dette er deres pakketilbud, der implementerer skyen og inkluderer Kuber, Service Mesh, overvågning - al den hardware, der er nødvendig for lokale mikrotjenester." Vi er næsten i fremtiden."
Denis nævnte også Nutanix og VMWare med vRealize Suite-produktet, som kan klare en lignende opgave uden containerisering.
Dmitry delte sin mening om, at reduktion af "smerten" og reduktion af skatter er to områder, hvor vi kan forvente forbedringer.
For at opsummere diskussionen fremhæver vi følgende problemer med moderne infrastruktur:
- Tre deltagere identificerede straks et problem med stateful.
- Forskellige sikkerhedssupportproblemer, herunder muligheden for, at Docker ender med flere versioner af Python, applikationsservere og komponenter.
Overforbrug, hvilket er bedre at diskutere på et separat møde.
En læringsudfordring, da orkestrering er et komplekst økosystem.
Et almindeligt problem i branchen er misbrug af værktøjer.Resten af konklusionerne er op til dig. Der er stadig en følelse af, at det ikke er let for Docker+Kubernetes-kombinationen at blive en "central" del af systemet. For eksempel installeres operativsystemer på hardware først, hvilket ikke kan siges om containere og orkestrering. Måske i fremtiden vil operativsystemer og containere smelte sammen med cloud management software.
Photo byJeg vil gerne benytte lejligheden til at sige hej til min mor og minde om, at vi har en Facebook-gruppe , kanal med interessante publikationer fra forskellige tech-blogs. Og min kanal , hvor jeg taler om at styre udvikling i produktvirksomheder.
Kilde: www.habr.com