I slutet av maj höll ett onlinemöte om ämnet . Vi pratade om containrar, Kubernetes och orkestrering i princip, kriterier för val av infrastruktur och mycket mer. Deltagarna delade fall från sin egen praktik.
Deltagarna:
- Evgeniy Potapov, VD för ITSumma. Mer än hälften av deras kunder flyttar antingen redan eller vill byta till Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Har 10+ års erfarenhet av att arbeta med containersystem.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, ex-RAO UES. Han lovade att prata om fall i det "blodiga" företaget.
- Andrey Fedorovsky, CTO "News360.com"Efter att ha köpt företaget av en annan aktör ansvarar han för ett antal ML- och AI-projekt och infrastruktur.
- Ivan Kruglov, systemingenjör, ex-Booking.com.Samma person som gjorde mycket med Kubernetes med sina egna händer.
Teman:
- Deltagarnas insikter om containrar och orkestrering (Docker, Kubernetes, etc.); vad som prövats i praktiken eller analyserats.
- Fall: Företaget bygger en utvecklingsplan för infrastruktur i flera år. Hur fattas beslutet om man ska bygga (eller migrera den nuvarande) infrastrukturen till containrar och Kuber eller inte?
- Problem i den molnbaserade världen, vad som saknas, låt oss föreställa oss vad som kommer att hända imorgon.
En intressant diskussion följde, deltagarnas åsikter var så olika och orsakade så många kommentarer att jag vill dela dem med er. Äta , och nedan är en sammanfattning av diskussionen.
Är Kubernetes redan en standard eller bra marknadsföring?
”Vi kom till det (Kubernetes. - Red.) när ingen visste om det ännu. Vi kom till honom även när han inte var där. Vi ville ha det förut" - Dmitry Stolyarov
Foto från Reddit.com
För 5-10 år sedan fanns det ett stort antal verktyg, och det fanns ingen enskild standard. Var sjätte månad dök en ny produkt upp, eller till och med mer än en. Först Vagrant, sedan Salt, Chef, Puppet, ... "och du bygger om din infrastruktur var sjätte månad. Du har fem administratörer som ständigt är upptagna med att skriva om konfigurationer”, minns Andrey Fedorovsky. Han tror att Docker och Kubernetes har "trängt ut" resten. Docker har blivit en standard under de senaste fem åren, Kubernetes under de senaste två åren. Och det är bra för branschen.
Dmitry Stolyarov och hans team älskar Kuber. De ville ha ett sådant verktyg innan det dök upp, och kom till det när ingen visste om det. För närvarande, av bekvämlighetsskäl, tar de inte an en klient om de förstår att de inte kommer att implementera Kubernetes med honom. Samtidigt, enligt Dmitry, har företaget "många gigantiska framgångshistorier om att återskapa det fruktansvärda arvet."
Kubernetes är inte bara containerorkestrering, det är ett konfigurationshanteringssystem med ett utvecklat API, en nätverkskomponent, L3-balansering och Ingress-kontroller, vilket gör det relativt enkelt att hantera resurser, skala och abstrahera från de lägre skikten av infrastrukturen.
Tyvärr måste vi i vårt liv betala för allt. Och denna skatt är stor, särskilt om vi talar om övergången till Kubernetes för ett företag med en utvecklad infrastruktur, som Ivan Kruglov tror. Han kunde fritt arbeta både i ett företag med en traditionell infrastruktur och med Kuber. Det viktigaste är att förstå företagets och marknadens egenskaper. Men, till exempel, för Evgeny Potapov, som skulle generalisera Kubernetes till vilket verktyg som helst för orkestrering av containers, uppstår inte en sådan fråga.
Evgeniy drog en analogi med situationen på 1990-talet, då objektorienterad programmering dök upp som ett sätt att programmera komplexa applikationer. Vid den tiden fortsatte debatten och nya verktyg dök upp för att stödja OOP. Sedan uppstod mikrotjänster som ett sätt att gå bort från det monolitiska konceptet. Detta ledde i sin tur till framväxten av containrar och containerhanteringsverktyg. "Jag tror att vi snart kommer till en tid då det inte kommer att råda några frågor om det är värt att skriva en liten mikrotjänstapplikation, den kommer att skrivas som en mikrotjänst som standard", tror han. På samma sätt kommer Docker och Kubernetes så småningom att bli standardlösningen utan behov av val.
Problemet med databaser i statslösa
Foto:
Nuförtiden finns det många recept för att köra databaser i Kubernetes. Till och med hur man separerar den del som fungerar med I/O-disken från, villkorligt, applikationsdelen av databasen. Är det möjligt att databaser i framtiden kommer att förändras så mycket att de kommer att levereras i en låda, där en del kommer att orkestreras genom Docker och Kubernetes, och i en annan del av infrastrukturen, genom separat mjukvara, kommer lagringsdelen att tillhandahållas ? Kommer baserna att förändras som en produkt?
Den här beskrivningen liknar köhantering, men kraven på tillförlitlighet och synkronisering av information i traditionella databaser är mycket högre, anser Andrey. Cacheträffförhållandet i normala databaser ligger kvar på 99 %. Om en arbetare går ner, startas en ny och cachen "värms upp" från grunden. Tills cachen har värmts upp arbetar arbetaren långsamt, vilket innebär att den inte kan laddas med användarbelastning. Även om det inte finns någon användarbelastning, värms inte cachen upp. Det är en ond cirkel.
Dmitry håller i grunden inte med - kvorum och sönderdelning löser problemet. Men Andrey insisterar på att lösningen inte passar alla. I vissa situationer är kvorum lämpligt, men det belastar nätverket ytterligare. En NoSQL-databas är inte lämplig i alla fall.
Meeup-deltagarna var uppdelade i två läger.
Denis och Andrey hävdar att allt som skrivs till disk - databaser och så vidare - är omöjligt att göra i det nuvarande Kuber-ekosystemet. Det är omöjligt att upprätthålla integriteten och konsistensen av produktionsdata i Kubernetes. Detta är en grundläggande egenskap. Lösning: hybrid infrastruktur.
Även moderna molnbaserade databaser som MongoDB och Cassandra, eller meddelandeköer som Kafka eller RabbitMQ, kräver beständiga datalager utanför Kubernetes.
Evgeniy invänder: "Baserna i Kubera är en nästan rysk, eller nästan företagsskada, som är förknippad med det faktum att det inte finns någon molnadoption i Ryssland." Små eller medelstora företag i väst är Cloud. Amazon RDS-databaser är lättare att använda än att mixtra med Kubernetes själv. I Ryssland använder de Kuber "on-premise" och överför baser till det när de försöker bli av med djurparken.
Dmitry höll också med påståendet att inga databaser kan hållas i Kubernetes: "Basen är annorlunda än basen. Och om du driver en gigantisk relationsdatabas, så under inga omständigheter. Om du trycker på något litet och molnnativt, som är mentalt förberett för ett halvflyktigt liv, kommer allt att bli bra.” Dmitry nämnde också att databashanteringsverktyg inte är redo för varken Docker eller Kuber, så stora svårigheter uppstår.
Ivan är i sin tur säker på att även om vi abstraherar från begreppen tillståndslös och statslös, är ekosystemet av företagslösningar i Kubernetes ännu inte klart. Med Kuber är det svårt att upprätthålla lag- och myndighetskrav. Det är till exempel omöjligt att göra en identitetsförsörjningslösning där det krävs strikta serveridentifikationsgarantier, ända ner till hårdvaran som sätts in i servrarna. Detta område utvecklas, men det finns ingen lösning ännu.
Deltagarna kunde inte komma överens, så inga slutsatser kommer att dras i denna del. Låt oss ge ett par praktiska exempel.
Fall 1. Cybersäkerhet av en "megaregulator" med baser utanför Kubera
När det gäller ett utvecklat cybersäkerhetssystem gör användningen av containrar och orkestrering det möjligt att bekämpa attacker och intrång. Till exempel, i en megaregulator, implementerade Denis och hans team en kombination av en orkestrator med en utbildad SIEM-tjänst som analyserar loggar i realtid och bestämmer processen för en attack, hacking eller misslyckande. I händelse av en attack, ett försök att placera något, eller i händelse av en ransomware-virusinvasion, plockar den, genom orkestratorn, upp containrar med applikationer snabbare än de blir infekterade, eller snabbare än angriparen attackerar dem.
Fall 2. Partiell migrering av Booking.com-databaser till Kubernetes
I Booking.com är huvuddatabasen MySQL med asynkron replikering – det finns en master och en hel hierarki av slavar. När Ivan lämnade företaget lanserades ett projekt för att överföra slavar som kunde "skjutas" med viss skada.
Utöver huvudbasen finns en Cassandra-installation med egenskriven orkestrering, som skrevs redan innan Kuber kom in i mainstream. Det finns inga problem i detta avseende, men det är beständigt på lokala SSD:er. Fjärrlagring, även inom samma datacenter, används inte på grund av problemet med hög latens.
Den tredje klassen av databaser är söktjänsten Booking.com, där varje tjänstenod är en databas. Försök att överföra söktjänsten till Kuber misslyckades, eftersom varje nod har 60-80 GB lokal lagring, vilket är svårt att "lyfta" och "värma upp".
Som ett resultat av detta överfördes inte sökmotorn till Kubernetes, och Ivan tror inte att det kommer att göras nya försök inom en snar framtid. MySQL-databasen överfördes till hälften: bara slavar, som inte är rädda för att bli "skjutna". Cassandra har satt sig in perfekt.
Infrastrukturval som en uppgift utan en generell lösning
Foto:
Låt oss säga att vi har ett nytt företag, eller ett företag där en del av infrastrukturen är uppbyggd på det gamla sättet. Den bygger en infrastrukturutvecklingsplan för åratal. Hur tas beslutet om man ska bygga infrastruktur på containrar och Kuber eller inte?
Företag som slåss i nanosekunder är uteslutna från diskussionen. Sund konservatism lönar sig när det gäller tillförlitlighet, men det finns fortfarande företag som bör överväga nya tillvägagångssätt.
Ivan: "Jag skulle definitivt starta ett företag på molnet nu, helt enkelt för att det är snabbare", även om det inte nödvändigtvis är billigare. Med utvecklingen av riskkapitalismen har startups inga stora problem med pengar, och huvuduppgiften är att erövra marknaden.
Det är Ivan av åsikten utvecklingen av den nuvarande infrastrukturen är ett urvalskriterium. Om det fanns en seriös investering tidigare, och den fungerar, så är det ingen idé att göra om den. Om infrastrukturen inte är utvecklad, och det finns problem med verktyg, säkerhet och övervakning, så är det vettigt att titta på en distribuerad infrastruktur.
Skatten måste betalas i alla fall, och Ivan skulle betala den som gjorde att han kunde betala mindre i framtiden. "För helt enkelt på grund av att jag åker på ett tåg som andra flyttar, kommer jag att resa mycket längre än om jag sitter på ett annat tåg, som jag själv måste fylla på.säger Ivan. När företaget är nytt, och fördröjningskraven är tiotals millisekunder, skulle Ivan se till de "operatörer" där klassiska databaser är "inpackade" idag. De skapar en replikeringskedja, som byter sig själv vid failover, etc...
För ett litet företag med ett par servrar är Kubera ingen mening”, säger Andrey. Men om den planerar att växa till hundratals servrar eller fler, behöver den automatisering och ett resurshanteringssystem. 90% av fallen är värda kostnaden. Dessutom, oavsett belastningsnivå och resurser. Det är vettigt för alla, från nystartade företag till stora företag med en publik på miljoner, att gradvis se till produkter för orkestrering av containers. "Ja, det här är verkligen framtiden," är Andrey säker.
Denis beskrev två huvudkriterier - skalbarhet och driftstabilitet. Han kommer att välja de verktyg som är bäst lämpade för uppgiften. "Det kan vara ett noname monterat på dina knän, och det har Nutanix Community Edition på sig. Detta kan vara en andra rad i form av en applikation på Kuber med en databas på backend, som är replikerad och har specificerade RTO- och RPO-parametrar" (återhämtningstid/punktmål - cirka).
Evgeniy identifierade ett möjligt problem med personalen. För tillfället finns det inte många högt kvalificerade specialister på marknaden som förstår "magen". Faktum är att om den valda tekniken är gammal är det svårt att anställa någon annan än medelålders människor som är uttråkade och trötta på livet. Även om andra deltagare anser att det handlar om personalutbildning.
Om vi ställer frågan om val: att lansera ett litet företag i det offentliga molnet med databaser i Amazon RDS eller "on premise" med databaser i Kubernetes, så blev Amazon RDS, trots vissa brister, deltagarnas val.
Eftersom majoriteten av meetup-lyssnarna inte kommer från det "blodiga" företaget, alltså distribuerade lösningar är vad vi bör sträva efter. Datalagringssystem måste vara distribuerade, tillförlitliga och skapa latens mätt i enheter av millisekunder, högst tiotals", sammanfattade Andrey.
Bedömning av Kubernetes-användning
Lyssnaren Anton Zhbankov ställde en fällfråga till Kubernetes apologeter: hur valde och genomförde ni en förstudie? Varför Kubernetes, varför inte virtuella maskiner, till exempel?
Foto:
Dmitry och Ivan svarade på det. I båda fallen, genom försök och misstag, togs en sekvens av beslut, vilket resulterade i att båda deltagarna anlände till Kubernetes. Nu börjar företag att självständigt utveckla programvara som är vettig att överföra till Kuber. Vi pratar inte om klassiska tredjepartssystem, som 1C. Kubernetes hjälper till när utvecklare snabbt behöver göra releaser, med kontinuerliga förbättringar.
Andreys team försökte skapa ett skalbart kluster baserat på virtuella maskiner. Noder föll som dominobrickor, vilket ibland ledde till att klustret kollapsade. "Teoretiskt sett kan du avsluta det och stödja det med händerna, men det är tråkigt. Och om det finns en lösning på marknaden som gör att du kan arbeta out of the box, då går vi gärna för det. Och vi bytte som ett resultat, säger Andrey.
Det finns standarder för sådan analys och beräkning, men ingen kan säga hur exakta de är på riktig hårdvara i drift. För beräkningar är det också viktigt att förstå varje verktyg och ekosystem, men det är inte möjligt.
Vad som väntar oss
Foto:
Allt eftersom tekniken utvecklas, dyker det upp fler och fler olika delar, och sedan sker en fasövergång, en försäljare dyker upp som har dödat tillräckligt med deg för att allt ska kunna samlas i ett enda verktyg.
Tror du att det kommer en tid då det kommer att finnas ett verktyg som Ubuntu för Linux-världen? Kanske kommer ett enda containeriserings- och orkestreringsverktyg att inkludera Kuber. Det kommer att göra det enkelt att bygga on-premise moln.
Svaret gavs av Ivan: "Google bygger nu Anthos - det här är deras paketerade erbjudande som distribuerar molnet och inkluderar Kuber, Service Mesh, övervakning - all hårdvara som behövs för mikrotjänster på plats." Vi är nästan i framtiden."
Denis nämnde också Nutanix och VMWare med vRealize Suite-produkten, som kan klara en liknande uppgift utan containerisering.
Dmitry delade sin åsikt att att minska "smärtan" och sänka skatterna är två områden där vi kan förvänta oss förbättringar.
För att sammanfatta diskussionen lyfter vi fram följande problem med modern infrastruktur:
- Tre deltagare identifierade omedelbart ett problem med stateful.
- Olika säkerhetssupportproblem, inklusive möjligheten att Docker kommer att sluta med flera versioner av Python, applikationsservrar och komponenter.
Överutgifter, om vilket det är bättre att hålla ett separat möte.
En inlärningsutmaning eftersom orkestrering är ett komplext ekosystem.
Ett vanligt problem i branschen är missbruk av verktyg.Resten av slutsatserna är upp till dig. Det finns fortfarande en känsla av att det inte är lätt för kombinationen Docker+Kubernetes att bli en "central" del av systemet. Till exempel installeras operativsystem på hårdvara först, vilket inte kan sägas om containrar och orkestrering. Kanske kommer operativsystem och behållare i framtiden att smälta samman med mjukvara för molnhantering.
Foto:Jag vill passa på att hälsa min mamma och påminna om att vi har en Facebookgrupp , kanal med intressanta publikationer från olika teknikbloggar. Och min kanal , där jag pratar om att hantera utveckling i produktbolag.
Källa: will.com