Kubernetes kommer att ta över världen. När och hur?

I förväntan DevOpsConf Vitaly Khabarov intervjuades Dmitry Stolyarov (distol), teknisk direktör och medgrundare av företaget Flant. Vitaly frågade Dmitry om vad Flant gör, om Kubernetes, ekosystemutveckling, support. Vi diskuterade varför Kubernetes behövs och om det behövs överhuvudtaget. Och även om mikrotjänster, Amazon AWS, "I'll be lucky"-inställningen till DevOps, framtiden för Kubernetes själv, varför, när och hur det kommer att ta över världen, utsikterna för DevOps och vad ingenjörer bör förbereda sig för i ljus och nära framtid med förenkling och neurala nätverk.

Originalintervju lyssna som podcast på DevOps Deflop – en ryskspråkig podcast om DevOps, och nedan finns textversionen.

Här och nedan ställer han frågor Vitaly Khabarov ingenjör från Express42.

Om "Flant"

- Hej Dima. Du är teknisk chef"Flant" och även dess grundare. Berätta för oss vad företaget gör och vad du är i det?

Dmitry: Från utsidan verkar det som att vi är killarna som går runt och installerar Kubernetes för alla och gör något med det. Men det är inte sant. Vi började som ett företag som sysslar med Linux, men under en mycket lång tid har vår huvudsakliga verksamhet varit att betjäna produktion och höglastade nyckelfärdiga projekt. Vanligtvis bygger vi hela infrastrukturen från grunden och ansvarar sedan för den under lång, lång tid. Därför är det huvudsakliga arbetet som "Flant" gör, för vilket den får pengar ta ansvar och genomföra nyckelfärdig produktion.




Jag, som teknisk direktör och en av företagets grundare, tillbringar hela dagen och natten med att försöka ta reda på hur man kan öka tillgängligheten för produktionen, förenkla dess drift, göra livet för administratörer lättare och livet för utvecklarna trevligare .

Om Kubernetes

— Den senaste tiden har jag sett många rapporter från Flant och artiklar om Kubernetes. Hur kom du fram till det?

Dmitry: Jag har redan pratat om det här många gånger, men jag har inget emot att upprepa det alls. Jag tycker att det är rätt att upprepa detta ämne eftersom det finns förvirring mellan orsak och verkan.

Vi behövde verkligen ett verktyg. Vi mötte många problem, kämpade, övervann dem med olika kryckor och kände ett behov av ett verktyg. Vi gick igenom många olika alternativ, byggde våra egna cyklar och fick erfarenhet. Gradvis kom vi till den punkt där vi började använda Docker nästan så fort det dök upp - runt 2013. Vid tiden för dess utseende hade vi redan mycket erfarenhet av behållare, vi hade redan skrivit en analog av "Docker" - några av våra egna kryckor i Python. Med tillkomsten av Docker blev det möjligt att kasta ut kryckorna och använda en pålitlig och community-stödd lösning.

Med Kubernetes är historien liknande. När det började ta fart - för oss är detta version 1.2 - hade vi redan ett gäng kryckor på både Shell och Chef, som vi på något sätt försökte orkestrera med Docker. Vi tittade på allvar mot Rancher och olika andra lösningar, men sedan dök det upp Kubernetes, där allt är implementerat precis som vi skulle ha gjort det eller ännu bättre. Det finns inget att klaga på.

Ja, det finns någon form av ofullkomlighet här, det finns någon form av ofullkomlighet där - det finns många ofullkomligheter, och 1.2 är generellt sett hemskt, men... Kubernetes är som en byggnad under uppbyggnad - du tittar på projektet och förstår att det blir coolt. Om byggnaden nu har en grund och två våningar, då förstår du att det är bättre att inte flytta in ännu, men det finns inga sådana problem med programvaran - du kan redan använda den.

Vi hade inte ett ögonblick där vi tänkte på att använda Kubernetes eller inte. Vi väntade på det länge innan det dök upp och försökte skapa analoger själva.

Om Kubernetes

— Är du direkt involverad i utvecklingen av själva Kubernetes?

Dmitry: Medelmåttig. Snarare deltar vi i utvecklingen av ekosystemet. Vi skickar ett visst antal pull-förfrågningar: till Prometheus, till olika operatörer, till Helm - till ekosystemet. Tyvärr kan jag inte hålla reda på allt vi gör och jag kan ha fel, men det finns inte en enda pool från oss in i kärnan.

— Utvecklar du samtidigt många av dina verktyg kring Kubernetes?

Dmitry: Strategin är denna: vi går och drar förfrågningar till allt som redan finns. Om pull-förfrågningar inte accepteras där, delar vi dem helt enkelt själva och lever tills de accepteras med våra byggen. Sedan, när den når uppströms, går vi tillbaka till uppströmsversionen.

Till exempel har vi en Prometheus-operatör, med vilken vi växlade fram och tillbaka till uppströms vår montering förmodligen 5 gånger redan. Vi behöver någon form av funktion, vi skickade en pull-begäran, vi måste rulla ut den i morgon, men vi vill inte vänta på att den ska släppas uppströms. Följaktligen monterar vi för oss själva, rullar ut vår montering med vår funktion, som vi behöver av någon anledning, till alla våra kluster. Sedan lämnar de till exempel över det till oss i uppströms med orden: "Gubbar, låt oss göra det för ett mer allmänt fall", vi, eller någon annan, avslutar det, och med tiden smälter det samman igen.

Vi försöker utveckla allt som finns. Många element som ännu inte finns, ännu inte uppfunnits, eller som har uppfunnits, men som inte har hunnit implementera – vi gör det. Och inte för att vi gillar processen eller cykelbyggandet som industri, utan helt enkelt för att vi behöver det här verktyget. Frågan ställs ofta, varför gjorde vi det eller det? Svaret är enkelt - ja, eftersom vi var tvungna att gå längre, lösa något praktiskt problem, och vi löste det med denna tula.

Vägen är alltid så här: vi letar mycket noggrant och om vi inte hittar någon lösning på hur man gör en trolleybuss av en brödlimpa, så gör vi vår egen limpa och vår egen trolleybuss.

Flanta verktyg

— Jag vet att Flant nu har tilläggsoperatorer, skaloperatorer och dapp/werf-verktyg. Som jag förstår det är detta samma instrument i olika inkarnationer. Jag förstår också att det finns många fler olika verktyg inom Flaunt. Detta är sant?

Dmitry: Vi har mycket mer på GitHub. Vad jag minns nu har vi en statuskarta – en panel för Grafana som alla har gillat. Det nämns i nästan varannan artikel om Kubernetes-övervakning på Medium. Det är omöjligt att kortfattat förklara vad en statuskarta är - den behöver en separat artikel, men det är en mycket användbar sak för att övervaka status över tid, eftersom vi i Kubernetes ofta behöver visa status över tid. Vi har också LogHouse - det här är en sak som bygger på ClickHouse och svart magi för att samla stockar i Kubernetes.

Många verktyg! Och det kommer att bli ännu fler, eftersom ett antal interna lösningar kommer att släppas i år. Av de mycket stora baserade på tilläggsoperatören finns det ett gäng tillägg för Kubernetes, ala hur man korrekt installerar sert manager - ett verktyg för att hantera certifikat, hur man korrekt installerar Prometheus med en massa tillbehör - dessa är ett tjugotal olika binärer som exporterar data och samlar in något, till detta har Prometheus den mest fantastiska grafiken och varningarna. Allt detta är bara ett gäng tillägg till Kubernetes, som är installerade i ett kluster, och det blir från enkelt till coolt, sofistikerat, automatiskt, där många problem redan har lösts. Ja, vi gör mycket.

Ekosystemutveckling

"Det verkar för mig att detta är ett mycket stort bidrag till utvecklingen av detta instrument och dess användningsmetoder." Kan du grovt uppskatta vem mer som skulle ge samma bidrag till ekosystemets utveckling?

Dmitry: I Ryssland, av de företag som verkar på vår marknad, är ingen ens i närheten. Naturligtvis är detta ett högljutt uttalande, eftersom det finns stora aktörer som Mail och Yandex - de gör också något med Kubernetes, men även de kommer inte i närheten av bidraget från företag i hela världen som gör mycket mer än oss. Det är svårt att jämföra Flant, som har en personal på 80 personer, och Red Hat, som har 300 ingenjörer enbart per Kubernetes, om jag inte har fel. Det är svårt att jämföra. Vi har 6 personer på RnD-avdelningen, inklusive jag, som skär alla våra verktyg. 6 personer mot 300 Red Hat-ingenjörer - det är på något sätt svårt att jämföra.

- Men när även dessa 6 personer kan göra något riktigt användbart och alienerande, när de ställs inför ett praktiskt problem och ger lösningen till samhället - ett intressant fall. Jag förstår att i stora teknikföretag, där de har ett eget utvecklings- och supportteam för Kubernetes, kan i princip samma verktyg utvecklas. Detta är ett exempel för dem på vad som kan utvecklas och ges till samhället, vilket ger impulser till hela samhället som använder Kubernetes.

Dmitry: Detta är förmodligen en egenskap hos integratorn, dess egenhet. Vi har många projekt och vi ser många olika situationer. För oss är det främsta sättet att skapa mervärde att analysera dessa fall, hitta gemensamhet och göra dem så billiga som möjligt för oss. Vi arbetar aktivt med detta. Det är svårt för mig att prata om Ryssland och världen, men vi har ett 40-tal DevOps-ingenjörer i företaget som arbetar på Kubernetes. Jag tror inte att det finns många företag i Ryssland med ett jämförbart antal specialister som förstår Kubernetes, om några alls.

Jag förstår allt om jobbtiteln DevOps-ingenjörer, alla förstår allt och är vana vid att kalla DevOps-ingenjörer för DevOps-ingenjörer, vi kommer inte att diskutera detta. Alla dessa 40 fantastiska DevOps-ingenjörer möter och löser problem varje dag, vi analyserar bara den här upplevelsen och försöker generalisera. Vi förstår att om det finns kvar inom oss, kommer verktyget om ett eller två år att vara oanvändbart, för någonstans i samhället kommer en färdig Tula att dyka upp. Det är ingen idé att samla denna erfarenhet internt - det är helt enkelt att dränera energi och tid till dev/null. Och vi tycker inte alls synd om det. Vi publicerar allt med stor glädje och förstår att det behöver publiceras, utvecklas, främjas, främjas, så att folk använder det och lägger till sin erfarenhet – då växer allt och lever. Sedan efter två år hamnar inte instrumentet i papperskorgen. Det är inte synd att fortsätta ösa in styrka, för det är tydligt att någon använder ditt verktyg, och efter två år använder alla det.

Detta är en del av vår stora strategi med dapp/werf. Jag kommer inte ihåg när vi började göra den, det verkar som 3 år sedan. Inledningsvis var det i allmänhet på skalet. Det var ett super proof of concept, vi löste några av våra speciella problem – det fungerade! Men det finns problem med skalet, det är omöjligt att utöka det ytterligare, programmering på skalet är en annan uppgift. Vi hade en vana att skriva i Ruby, därför gjorde vi om något i Ruby, utvecklade, utvecklade, utvecklade och stötte på det faktum att samhället, folkmassan som inte säger "vi vill ha det eller vi vill inte ha det, ” vänder upp näsan mot Ruby, hur roligt är det? Vi insåg att vi borde skriva allt det här i Go bara för att möta den första punkten på checklistan: DevOps-verktyget ska vara ett statiskt binärt. Att vara Go eller inte är inte så viktigt, men en statisk binär skriven i Go är bättre.

Vi spenderade vår energi, skrev om dappen i Go och kallade den werf. Dapp stöds inte längre, inte utvecklad, körs i någon senaste version, men det finns en absolut uppgraderingsväg till toppen, och du kan följa den.

Varför skapades dappen?

— Kan du kort berätta varför dappen skapades, vilka problem den löser?

Dmitry: Den första anledningen är i monteringen. Till en början hade vi allvarliga problem med konstruktionen när Docker inte hade flerstegsfunktioner, så vi gjorde flersteg på egen hand. Sedan hade vi en massa fler problem med att rengöra bilden. Alla som gör CI/CD, förr snarare än senare, ställs inför problemet att det finns ett gäng samlade bilder, man måste på något sätt rensa bort det som inte behövs och lämna det som behövs.

Det andra skälet är utplacering. Ja, det finns Helm, men det löser bara några av problemen. Lustigt nog skrivs det att "Helm är pakethanteraren för Kubernetes." Exakt vad "den". Det finns också orden "Package Manager" - vad är de vanliga förväntningarna från en Package Manager? Vi säger: "Package Manager - installera paketet!" och vi förväntar oss att han säger till oss: "Paketet har levererats."

Det är intressant att vi säger: "Hjälp, installera paketet," och när han svarar att han installerade det, visar det sig att han precis startade installationen - han indikerade Kubernetes: "Starta den här saken!", och om den startade eller inte , oavsett om det fungerar eller inte löser Helm inte det här problemet alls.

Det visar sig att Helm bara är en textförbehandlare som laddar data till Kubernetes.

Men som en del av all distribution vill vi veta om applikationen har släppts för produktion eller inte? Utrullad till prod betyder att applikationen har flyttat dit, den nya versionen har distribuerats, och den kraschar åtminstone inte där och svarar korrekt. Helm löser inte detta problem på något sätt. För att lösa det måste du lägga ner mycket ansträngning, eftersom du måste ge Kubernetes kommandot att rulla ut och övervaka vad som händer där - oavsett om det distribueras eller rullas ut. Och det finns också många uppgifter relaterade till driftsättning, rengöring och montering.

planer

I år startar vi lokal utveckling. Vi vill uppnå det som tidigare fanns i Vagrant - vi skrev "vagrant up" och vi distribuerade virtuella maskiner. Vi vill komma till den punkt där det finns ett projekt i Git, vi skriver "werf" där, och det tar upp en lokal kopia av det här projektet, utplacerat i en lokal mini-Kub, med alla kataloger som är bekväma för utveckling anslutna . Beroende på utvecklingsspråket görs detta på olika sätt, men ändå så att lokal utveckling bekvämt kan utföras under monterade filer.

Nästa steg för oss är investera i bekvämlighet för utvecklare. För att snabbt distribuera ett projekt lokalt med ett verktyg, utveckla det, tryck in det i Git, och det kommer också att rulla ut till scenen eller tester, beroende på pipelines, och sedan använda samma verktyg för att gå till produktion. Denna enhet, enande, reproducerbarhet av infrastruktur från den lokala miljön till försäljning är en mycket viktig punkt för oss. Men det här är inte i werf än - vi planerar bara att göra det.

Men vägen till dapp/werf har alltid varit densamma som med Kubernetes i början. Vi stötte på problem, löste dem med lösningar - vi kom på några lösningar för oss själva på skalet, på vad som helst. Sedan försökte de på något sätt räta ut dessa lösningar, generalisera och konsolidera dem till binärer i det här fallet, som vi helt enkelt delar.

Det finns ett annat sätt att se på hela den här historien, med analogier.

Kubernetes är en bilram med motor. Det finns inga dörrar, glas, radio, julgran - ingenting alls. Bara ram och motor. Och det finns Helm - det här är ratten. Coolt - det finns en ratt, men du behöver också en rattstång, rattstång, växellåda och hjul, och du kan inte klara dig utan dem.

När det gäller werf är detta ytterligare en komponent till Kubernetes. Först nu i alfaversionen av werf, till exempel, kompileras Helm inuti werf, eftersom vi är trötta på att göra det själva. Det finns många anledningar till att göra detta, jag ska berätta i detalj om varför vi kompilerade hela rodret tillsammans med rorkulten inuti werf vid en rapport på RIT++.

Nu är werf en mer integrerad komponent. Vi får en färdig ratt, en rattpinne - jag är inte så bra på bilar, men det här är ett stort block som redan löser ett ganska brett spektrum av problem. Vi behöver inte gå igenom katalogen själva, välja en del för en annan, fundera på hur man skruvar ihop dem. Vi får en färdig tröska som löser ett stort antal problem på en gång. Men inuti är den byggd av samma öppen källkodskomponenter, den använder fortfarande Docker för montering, Helm för en del av funktionaliteten och det finns flera andra bibliotek. Detta är ett integrerat verktyg för att få cool CI/CD ur lådan snabbt och bekvämt.

Är Kubernetes svår att underhålla?

— Du berättar om upplevelsen av att du började använda Kubernetes, det här är en ram för dig, en motor, och att du kan hänga många olika saker på den: en kaross, en ratt, skruva på pedaler, säten. Frågan uppstår - hur svårt är Kubernetes-stödet för dig? Du har mycket erfarenhet, hur mycket tid och resurser lägger du på att stödja Kubernetes isolerat från allt annat?

Dmitry: Det här är en mycket svår fråga och för att svara på måste vi förstå vad stöd är och vad vi vill ha från Kubernetes. Kanske kan du avslöja?

— Så vitt jag vet och som jag ser vill nu många lag prova Kubernetes. Alla spänner sig till det, lägger det på sina knän. Jag har en känsla av att folk inte alltid förstår komplexiteten i det här systemet.

Dmitry: Det är så.

— Hur svårt är det att ta och installera Kubernetes från grunden så att den är produktionsklar?

Dmitry: Hur svårt tror du att det är att transplantera ett hjärta? Jag förstår att detta är en kompromissfråga. Att använda en skalpell och inte göra fel är inte så svårt. Om de berättar var du ska klippa och var du ska sy, är själva proceduren inte komplicerad. Det är svårt att garantera gång på gång att allt löser sig.

Att installera Kubernetes och få det att fungera är enkelt: chick! — installerat, det finns många installationsmetoder. Men vad händer när problem uppstår?

Frågor dyker alltid upp – vad har vi inte tagit hänsyn till ännu? Vad har vi inte gjort än? Vilka Linux-kärnparametrar angavs felaktigt? Herre, nämnde vi ens dem?! Vilka Kubernetes-komponenter har vi levererat och vilka har vi inte? Tusentals frågor dyker upp, och för att besvara dem måste du spendera 15-20 år i den här branschen.

Jag har ett färskt exempel på detta ämne som kan avslöja innebörden av problemet "Är Kubernetes svårt att underhålla?" För en tid sedan funderade vi allvarligt på om vi skulle försöka implementera Cilium som ett nätverk i Kubernetes.

Låt mig förklara vad Cilium är. Kubernetes har många olika implementeringar av nätverksundersystemet, och en av dem är väldigt cool - Cilium. Vad är dess betydelse? I kärnan blev det för en tid sedan möjligt att skriva krokar för kärnan, som på ett eller annat sätt invaderar nätverksundersystemet och olika andra delsystem, och låter dig kringgå stora bitar i kärnan.

Linuxkärnan har historiskt sett en ip-rout, ett överfilter, bryggor och många olika gamla komponenter som är 15, 20, 30 år gamla. I allmänhet fungerar de, allt är toppen, men nu har de staplat upp containrar, och det ser ut som ett torn av 15 tegelstenar ovanpå varandra, och man står på det på ett ben - en konstig känsla. Detta system har historiskt utvecklats med många nyanser, som blindtarmen i kroppen. I vissa situationer finns det till exempel prestationsproblem.

Det finns en underbar BPF och förmågan att skriva krokar för kärnan - killarna skrev sina egna krokar för kärnan. Paketet kommer in i Linux-kärnan, de tar ut det direkt vid ingången, bearbetar det själva som det ska utan bryggor, utan TCP, utan en IP-stack - kort sagt, kringgår allt som skrivs i Linux-kärnan och spottar sedan den ut i behållaren.

Vad hände? Mycket cool prestanda, coola funktioner - bara cool! Men vi tittar på detta och ser att det på varje maskin finns ett program som ansluter till Kubernetes API och, baserat på data som det tar emot från detta API, genererar C-kod och kompilerar binärer som det laddar in i kärnan så att dessa krokar fungerar i kärnutrymmet.

Vad händer om något går fel? Vi vet inte. För att förstå detta måste du läsa all denna kod, förstå all logik, och det är fantastiskt hur svårt det är. Men å andra sidan finns det dessa bryggor, nätfilter, ip-rout - jag har inte läst deras källkod, och inte heller de 40 ingenjörerna som arbetar i vårt företag. Kanske bara ett fåtal förstår vissa delar.

Och vad är skillnaden? Det visar sig att det finns ip-rout, Linux-kärnan och det finns ett nytt verktyg - vilken skillnad gör det, vi förstår inte det ena eller det andra. Men vi är rädda för att använda något nytt – varför? För om verktyget är 30 år gammalt så har alla buggar hittats på 30 år, alla misstag har trampats på och du behöver inte veta om allt - det fungerar som en svart låda och fungerar alltid. Alla vet vilken diagnosskruvmejsel som ska stickas på vilken plats, vilken tcpdump som ska köras i vilket ögonblick. Alla känner till diagnostiska verktyg väl och förstår hur denna uppsättning komponenter fungerar i Linux-kärnan - inte hur det fungerar, utan hur man använder det.

Och den fantastiskt coola Cilium är inte 30 år gammal, den har inte åldrats än. Kubernetes har samma problem, kopiera. Att Cilium är perfekt installerat, att Kubernetes är perfekt installerat, men när något går fel i produktionen, kan du snabbt förstå i en kritisk situation vad som gick fel?

När vi säger är det svårt att underhålla Kubernetes - nej, det är väldigt enkelt, och ja, det är otroligt svårt. Kubernetes fungerar utmärkt på egen hand, men med en miljard nyanser.

Om tillvägagångssättet "I'll be lucky".

— Finns det företag där dessa nyanser nästan garanterat dyker upp? Anta att Yandex plötsligt överför alla tjänster till Kubernetes, det kommer att bli en enorm belastning där.

Dmitry: Nej, det här är inte ett samtal om belastningen, utan om de enklaste sakerna. Till exempel har vi Kubernetes, vi distribuerade applikationen där. Hur vet du att det fungerar? Det finns helt enkelt inget färdigt verktyg för att förstå att applikationen inte kraschar. Det finns inget färdigt system som skickar varningar, du måste konfigurera dessa varningar och varje schema. Och vi uppdaterar Kubernetes.

Jag har Ubuntu 16.04. Man kan säga att det här är en gammal version, men vi är fortfarande på den eftersom det är LTS. Det finns systemd, vars nyans är att det inte rensar upp C-grupper. Kubernetes lanserar pods, skapar C-grupper, tar sedan bort pods, och på något sätt visar det sig - jag kommer inte ihåg detaljerna, förlåt - att systemd skivor finns kvar. Detta leder till det faktum att varje bil med tiden börjar sakta ner kraftigt. Det här är inte ens en fråga om högbelastning. Om permanenta poddar lanseras, till exempel, om det finns ett Cron Job som ständigt genererar pods, så kommer maskinen med Ubuntu 16.04 att börja sakta ner efter en vecka. Det blir ett konstant högt belastningsmedel på grund av att ett gäng C-grupper har skapats. Detta är problemet som varje person som helt enkelt installerar Ubuntu 16 och Kubernetes ovanpå kommer att möta.

Låt oss säga att han på något sätt uppdaterar systemd eller något annat, men i Linux-kärnan upp till 4.16 är det ännu roligare - när du tar bort C-grupper läcker de in i kärnan och raderas faktiskt inte. Därför, efter en månads arbete på den här maskinen, kommer det att vara omöjligt att titta på minnesstatistiken för härdarna. Vi tar ut en fil, rullar in den i programmet, och en fil rullar i 15 sekunder, eftersom kärnan tar väldigt lång tid att räkna en miljon C-grupper inom sig, som verkar vara raderade, men nej - de läcker .

Det finns fortfarande många sådana småsaker här och där. Det här är inte en fråga som jätteföretag ibland kan möta under mycket tung belastning – nej, det är en fråga om vardagliga saker. Människor kan leva så här i månader - de installerade Kubernetes, distribuerade applikationen - det verkar fungera. För många människor är detta normalt. De kommer inte ens veta att den här applikationen kommer att krascha av någon anledning, de kommer inte att få en varning, men för dem är detta normen. Tidigare levde vi på virtuella maskiner utan övervakning, nu flyttade vi till Kubernetes, också utan övervakning – vad är skillnaden?

Frågan är att när vi går på is vet vi aldrig dess tjocklek om vi inte mäter den i förväg. Många människor går och oroar sig inte, för de har gått förut.

Ur min synvinkel är nyansen och komplexiteten i att driva vilket system som helst att säkerställa att isens tjocklek är exakt tillräckligt för att lösa våra problem. Det här är vad vi pratar om.

Inom IT, förefaller det mig, finns det för många "I'll be lucky"-metoder. Många installerar programvara och använder programbibliotek i hopp om att de ska ha tur. I allmänhet har många människor tur. Det är nog därför det fungerar.

— Utifrån min pessimistiska bedömning ser det ut så här: när riskerna är höga, och applikationen måste fungera, då behövs support från Flaunt, kanske från Red Hat, eller så behöver du ditt eget interna team dedikerat specifikt till Kubernetes, som är redo att dra av den.

Dmitry: Objektivt sett är det så. Att komma in i Kubernetes-berättelsen för ett litet team på egen hand innebär ett antal risker.

Behöver vi containrar?

— Kan du berätta hur utbrett Kubernetes är i Ryssland?

Dmitry: Jag har inte den här informationen och jag är inte säker på att någon annan har den. Vi säger: "Kubernetes, Kubernetes", men det finns ett annat sätt att se på den här frågan. Jag vet inte heller hur utbredda containrar är, men jag vet en siffra från rapporter på Internet att 70 % av containrarna är orkestrerade av Kubernetes. Det var en pålitlig källa för ett ganska stort urval runt om i världen.

Sedan en annan fråga - behöver vi containrar? Min personliga känsla och Flant-företagets övergripande ställning är att Kubernetes är en de facto standard.

Det blir inget annat än Kubernetes.

Detta är en absolut spelförändring inom området för infrastrukturhantering. Bara absolut - det är det, inte mer Ansible, Chef, virtuella maskiner, Terraform. Jag pratar inte om de gamla kollektivbruksmetoderna. Kubernetes är en absolut förändring, och nu blir det bara så här.

Det är klart att det för vissa tar ett par år, och för andra ett par decennier, att inse detta. Jag tvivlar inte på att det inte kommer att finnas något annat än Kubernetes och detta nya utseende: vi skadar inte längre operativsystemet, utan använder infrastruktur som kod, bara inte med kod, utan med yml - en deklarativt beskriven infrastruktur. Jag har en känsla av att det alltid kommer att vara så här.

— Det vill säga, de företag som ännu inte har bytt till Kubernetes kommer definitivt att byta till det eller förbli i glömska. Jag förstod dig rätt?

Dmitry: Detta är inte heller helt sant. Om vi ​​till exempel har till uppgift att köra en DNS-server så kan den köras på FreeBSD 4.10 och den kan fungera perfekt i 20 år. Bara jobba och det är det. Om 20 år kanske något behöver uppdateras en gång. Om vi ​​pratar om programvara i det format som vi lanserade och den faktiskt fungerar i många år utan några uppdateringar, utan att göra ändringar, så kommer det naturligtvis inte att finnas några Kubernetes. Han behövs inte där.

Allt relaterat till CI/CD - varhelst Continuous Delivery behövs, där du behöver uppdatera versioner, göra aktiva ändringar, var du än behöver bygga feltolerans - bara Kubernetes.

Om mikrotjänster

– Här har jag en liten dissonans. För att arbeta med Kubernetes behöver du extern eller intern support - det här är den första punkten. För det andra, när vi precis har börjat utveckla, är vi en liten startup, vi har inget ännu, utveckling för Kubernetes eller mikrotjänstarkitektur i allmänhet kan vara komplex och inte alltid ekonomiskt motiverad. Jag är intresserad av din åsikt - måste startups omedelbart börja skriva för Kubernetes från början, eller kan de fortfarande skriva en monolit och sedan bara komma till Kubernetes?

Dmitry: Cool fråga. Jag har ett snack om mikrotjänster "Microservices: Size Matters." Många gånger har jag stött på människor som försöker slå spikar med ett mikroskop. Själva tillvägagångssättet är korrekt, vi designar själva vår interna mjukvara på detta sätt. Men när du gör detta måste du tydligt förstå vad du gör. Ordet jag hatar mest med mikrotjänster är "mikro". Historiskt sett har detta ord sitt ursprung där, och av någon anledning tror folk att mikro är väldigt litet, mindre än en millimeter, som en mikrometer. Detta är fel.

Till exempel finns det en monolit som är skriven av 300 personer, och alla som deltagit i utvecklingen förstår att det finns problem där, och den bör delas upp i mikrobitar - cirka 10 stycken, som var och en är skriven av 30 personer i en minimiversion. Detta är viktigt, nödvändigt och coolt. Men när en startup kommer till oss, där 3 väldigt coola och begåvade killar skrev 60 mikrotjänster på sina knän, varje gång jag letar efter Corvalol.

Det verkar för mig att det redan har pratats om detta tusentals gånger - vi fick en distribuerad monolit i en eller annan form. Detta är inte ekonomiskt motiverat, det är väldigt svårt i allmänhet i allt. Jag har precis sett det här så många gånger att det gör mig riktigt ont, så jag fortsätter att prata om det.

Till den inledande frågan finns det en konflikt mellan det faktum att Kubernetes å ena sidan är läskigt att använda, eftersom det inte är klart vad som kan gå sönder där eller inte fungerar, å andra sidan är det klart att allt går där och ingenting annat än Kubernetes kommer att existera. Svara - väga mängden nytta som kommer, mängden uppgifter som du kan lösa. Detta är på ena sidan av skalan. Å andra sidan finns det risker förknippade med driftstopp eller med en minskning av svarstid, tillgänglighetsnivå - med en minskning av prestationsindikatorer.

Här är det – antingen rör vi oss snabbt och Kubernetes låter oss göra många saker mycket snabbare och bättre, eller så använder vi pålitliga, beprövade lösningar, men går mycket långsammare. Detta är ett val varje företag måste göra. Du kan tänka på det som en stig i djungeln - när du går för första gången kan du möta en orm, en tiger eller en galen grävling, och när du har gått 10 gånger har du trampat stigen, tagit bort grenarna och gå lättare. För varje gång blir vägen bredare. Sedan är det en asfalterad väg, och senare en vacker boulevard.

Kubernetes står inte stilla. Fråga igen: Kubernetes är å ena sidan 4-5 binärer, å andra sidan är det hela ekosystemet. Det här är operativsystemet som vi har på våra maskiner. Vad är detta? Ubuntu eller Curios? Detta är Linux-kärnan, ett gäng ytterligare komponenter. Alla dessa saker här, en giftig orm kastades ut från vägen, ett staket restes där. Kubernetes utvecklas mycket snabbt och dynamiskt, och volymen av risker, volymen av det okända minskar varje månad och följaktligen återbalanserar dessa skalor.

Som svar på frågan om vad en startup ska göra, skulle jag säga - kom till Flaunt, betala 150 tusen rubel och få en nyckelfärdig DevOps enkel tjänst. Om du är en liten startup med ett fåtal utvecklare fungerar detta. Istället för att anställa egna DevOps, som kommer att behöva lära sig att lösa dina problem och betala en lön vid det här laget, får du en nyckelfärdig lösning på alla frågor. Ja, det finns några nackdelar. Vi som uppdragsgivare kan inte vara så involverade och reagera snabbt på förändringar. Men vi har mycket expertis och färdiga rutiner. Vi garanterar att vi i alla situationer definitivt snabbt kommer att ta reda på det och uppväcka eventuella Kubernetes från de döda.

Jag rekommenderar starkt att outsourca till startups och etablerade företag upp till en storlek där man kan ägna ett team på 10 personer till verksamheten, för annars är det ingen mening. Det är definitivt vettigt att lägga ut detta på entreprenad.

Om Amazon och Google

— Kan en värd från en lösning från Amazon eller Google betraktas som en outsourcing?

Dmitry: Ja, självklart, det här löser ett antal problem. Men återigen finns det nyanser. Du måste fortfarande förstå hur du använder den. Till exempel finns det tusen små saker i Amazon AWS:s arbete: Load Balancer måste värmas upp eller så måste en begäran skrivas i förväg om att "killar, vi kommer att ta emot trafik, värm upp Load Balancer för oss!" Du måste känna till dessa nyanser.

När man vänder sig till personer som är specialiserade på detta får man nästan alla typiska saker stängda. Vi har nu 40 ingenjörer, i slutet av året kommer det förmodligen att vara 60 - vi har definitivt stött på alla dessa saker. Även om vi stöter på det här problemet igen i något projekt, frågar vi snabbt varandra och vet hur vi ska lösa det.

Förmodligen är svaret - naturligtvis gör en värdberättelse en del enklare. Frågan är om du är redo att lita på dessa värdar och om de kommer att lösa dina problem. Amazon och Google har gjort det bra. För alla våra fall – exakt. Vi har inga fler positiva erfarenheter. Alla andra moln som vi försökte arbeta med skapar en massa problem - Ager, och allt som finns i Ryssland, och alla typer av OpenStack i olika implementeringar: Headster, Overage - vad du vill. De skapar alla problem som du inte vill lösa.

Därför är svaret ja, men i själva verket finns det inte särskilt många mogna värdbaserade lösningar.

Vem behöver Kubernetes?

— Och ändå, vem behöver Kubernetes? Vem borde redan byta till Kubernetes, vem är den typiska Flaunt-klienten som kommer specifikt för Kubernetes?

Dmitry: Det här är en intressant fråga, för just nu, i kölvattnet av Kubernetes, kommer många människor till oss: "Grabbar, vi vet att ni gör Kubernetes, gör det åt oss!" Vi svarar dem: "Mine herrar, vi gör inte Kubernetes, vi gör prod och allt som är kopplat till det." För det är för närvarande helt enkelt omöjligt att göra en produkt utan att göra alla CI/CD och hela denna historia. Alla har gått bort från uppdelningen att vi har utveckling genom utveckling, och sedan exploatering genom exploatering.

Våra kunder förväntar sig olika saker, men alla väntar på något bra mirakel att de har vissa problem, och nu - hopp! — Kubernetes kommer att lösa dem. Människor tror på mirakel. I sina sinnen förstår de att det inte kommer att ske något mirakel, men i sina själar hoppas de - tänk om denna Kubernetes nu kommer att lösa allt för oss, de pratar så mycket om det! Plötsligt han nu - nys! - och en silverkula, nys! — och vi har 100 % drifttid, alla utvecklare kan släppa allt som kommer i produktion 50 gånger, och det kraschar inte. I allmänhet ett mirakel!

När sådana människor kommer till oss säger vi: "Förlåt, men det finns inget som heter ett mirakel." För att vara frisk måste du äta bra och träna. För att ha en pålitlig produkt måste den tillverkas pålitligt. För att ha en bekväm CI/CD måste du göra den så här. Det är mycket arbete som måste göras.

Att svara på frågan om vem som behöver Kubernetes - ingen behöver Kubernetes.

Vissa människor har missuppfattningen att de behöver Kubernetes. Människor behöver, de har ett djupt behov av att sluta tänka, studera och vara intresserade av alla problem med infrastruktur och problemen med att köra sina applikationer. De vill att applikationer bara ska fungera och bara distribuera. För dem är Kubernetes förhoppningen att de ska sluta höra historien om att "vi låg där" eller "vi kan inte rulla ut" eller något annat.

Den tekniska chefen brukar komma till oss. De frågar honom två saker: å ena sidan, ge oss egenskaper, å andra sidan, stabilitet. Vi föreslår att du tar på dig det och gör det. Silverkulan, eller snarare silverpläterad, är att du kommer att sluta tänka på dessa problem och slösa tid. Du kommer att ha speciella personer som kommer att avsluta det här problemet.

Formuleringen att vi eller någon annan behöver Kubernetes är felaktig.

Administratörer behöver verkligen Kubernetes, för det är en väldigt intressant leksak som du kan leka med och mixtra med. Låt oss vara ärliga - alla älskar leksaker. Vi är alla barn någonstans, och när vi ser en ny vill vi leka den. För vissa har detta avskräckts, till exempel inom administrationen, eftersom de redan har spelat tillräckligt och redan är trötta till den grad att de helt enkelt inte vill. Men detta är inte helt förlorat för någon. Om jag till exempel har tröttnat på leksaker inom systemadministration och DevOps länge, så älskar jag fortfarande leksakerna, jag köper fortfarande några nya. Alla människor, på ett eller annat sätt, vill fortfarande ha någon form av leksaker.

Du behöver inte leka med produktionen. Vad jag än kategoriskt rekommenderar att inte göra och vad jag ser nu i massor: "Åh, en ny leksak!" — de sprang för att köpa den, köpte den och: "Låt oss ta den till skolan nu och visa den för alla våra vänner." Gör inte det. Jag ber om ursäkt, mina barn växer bara upp, jag ser hela tiden något hos barn, märker det på mig själv och generaliserar det sedan till andra.

Det slutliga svaret är: du behöver inte Kubernetes. Du måste lösa dina problem.

Det du kan uppnå är:

• prod faller inte;
• även om han försöker falla, vet vi om det i förväg, och vi kan lägga något i det;
• vi kan ändra det i den hastighet med vilken vår verksamhet kräver det, och vi kan göra det bekvämt; det orsakar oss inga problem.

Det finns två verkliga behov: tillförlitlighet och dynamik/flexibilitet i utbyggnaden. Alla som just nu håller på med någon form av IT-projekt, oavsett i vilken typ av verksamhet – mjuk för att underlätta världen, och som förstår detta, behöver lösa dessa behov. Kubernetes med rätt tillvägagångssätt, med rätt förståelse och med tillräcklig erfarenhet gör att du kan lösa dem.

Om serverlöst

— Om man tittar lite längre in i framtiden, försöker lösa problemet med frånvaron av huvudvärk med infrastruktur, med hastigheten på utrullningen och hastigheten på applikationsförändringar, nya lösningar dyker upp, till exempel serverlösa. Känner du någon potential i denna riktning och, låt oss säga, en fara för Kubernetes och liknande lösningar?

Dmitry: Här behöver vi göra en anmärkning igen om att jag inte är en seare som blickar framåt och säger – det blir så här! Fast jag gjorde precis samma sak. Jag tittar på mina fötter och ser en massa problem där, till exempel hur transistorer fungerar i en dator. Det är roligt, eller hur? Vi stöter på några buggar i CPU:n.

Gör serverlös ganska tillförlitlig, billig, effektiv och bekväm och löser alla ekosystemproblem. Här håller jag med Elon Musk om att det behövs en andra planet för att skapa feltolerans för mänskligheten. Även om jag inte vet vad han säger, förstår jag att jag inte är redo att flyga till Mars själv och att det inte kommer att hända i morgon.

Med serverless är det tydligt klart att detta är en ideologiskt korrekt sak, som feltolerans för mänskligheten - att ha två planeter är bättre än en. Men hur gör man nu? Att skicka en expedition är inte ett problem om du koncentrerar dina ansträngningar på det. Att skicka flera expeditioner och bosätta flera tusen människor där tror jag också är realistiskt. Men att göra det helt feltåligt så att hälften av mänskligheten bor där, det förefaller mig nu omöjligt, om man inte beaktar det.

Med serverlös en mot en: saken är cool, men det är långt ifrån problemen för 2019. Närmare 2030 - låt oss leva för att se det. Jag tvivlar inte på att vi kommer att leva, vi kommer definitivt att leva (upprepa innan vi går och lägger oss), men nu måste vi lösa andra problem. Det är som att tro på sagoponnyn Rainbow. Ja, ett par procent av fallen är lösta, och de är lösta perfekt, men subjektivt sett är serverlöst en regnbåge... För mig är det här ämnet för avlägset och för obegripligt. Jag är inte redo att prata. Under 2019 kan du inte skriva en enda applikation med serverlös.

Hur Kubernetes kommer att utvecklas

— När vi går mot denna potentiellt underbara avlägsna framtid, hur tror du att Kubernetes och ekosystemet runt det kommer att utvecklas?

Dmitry: Jag har funderat mycket på det här och jag har ett tydligt svar. Den första är statefull - trots allt är statslös lättare att göra. Kubernetes satsade initialt mer på detta, allt började med det. Stateless fungerar nästan perfekt i Kubernetes, det finns bara inget att klaga på. Det finns fortfarande många problem, eller snarare nyanser. Allt där fungerar redan bra för oss, men det är vi. Det kommer att ta minst ett par år till innan detta fungerar för alla. Detta är inte en beräknad indikator, utan min känsla från mitt huvud.

Kort sagt, statefull bör - och kommer - att utvecklas mycket starkt, eftersom alla våra applikationer lagrar status, det finns inga statslösa applikationer. Detta är en illusion, du behöver alltid någon form av databas och något annat. Statefull handlar om att räta ut allt som är möjligt, fixa alla buggar, förbättra alla problem som just nu står inför – låt oss kalla det adoption.

Nivån på det okända, nivån på olösta problem, nivån på sannolikheten att stöta på något kommer att sjunka avsevärt. Det här är en viktig historia. Och operatörer - allt relaterat till kodifiering av administrationslogik, kontrolllogik för att få en enkel tjänst: MySQL enkel service, RabbitMQ enkel service, Memcache enkel service - i allmänhet alla dessa komponenter som vi måste garanteras fungera ur lådan. Detta löser bara smärtan att vi vill ha en databas, men vi vill inte administrera den, eller vi vill ha Kubernetes, men vi vill inte administrera den.

Den här historien om operatörsutveckling i en eller annan form kommer att vara viktig under de kommande åren.

Jag tror att användarvänligheten borde öka rejält – lådan blir mer och mer svart, mer och mer pålitlig, med fler och fler enkla knoppar.

Jag lyssnade en gång på en gammal intervju med Isaac Asimov från 80-talet på YouTube på Saturday Night Live – ett program som Urgant, bara intressant. De frågade honom om framtiden för datorer. Han sa att framtiden är i enkelhet, precis som radion. Radiomottagaren var ursprungligen en komplex sak. För att fånga en våg var man tvungen att vrida på rattarna i 15 minuter, vrida på spetten och allmänt veta hur allt fungerar, förstå fysiken för radiovågsöverföring. Det gjorde att det bara fanns en ratt kvar i radion.

Vilken radio nu 2019? I bilen hittar radiomottagaren alla vågor och namnen på stationerna. Processens fysik har inte förändrats på 100 år, men användarvänligheten har gjort det. Nu, och inte bara nu, redan 1980, när det var en intervju med Azimov, använde alla radion och ingen tänkte på hur det fungerade. Det har alltid fungerat – det är givet.

Azimov sa då att det skulle vara samma sak med datorer - användarvänligheten kommer att öka. Medan man 1980 var tvungen att utbildas för att trycka på knappar på en dator, så kommer det inte att vara fallet i framtiden.

Jag har en känsla av att med Kubernetes och med infrastrukturen kommer det också att bli en enorm ökning av användarvänligheten. Detta är enligt min mening uppenbart - det ligger på ytan.

Vad ska man göra med ingenjörer?

— Vad händer då med ingenjörerna och systemadministratörerna som stödjer Kubernetes?

Dmitry: Vad hände med revisorn efter tillkomsten av 1C? Ungefär samma. Innan detta räknade man på papper – nu i programmet. Arbetsproduktiviteten har ökat i storleksordningar, men själva arbetet har inte försvunnit. Om det tidigare krävdes 10 ingenjörer för att skruva i en glödlampa, nu räcker det med en.

Mängden mjukvara och antalet uppgifter, verkar det för mig, växer nu i snabbare takt än vad nya DevOps dyker upp och effektiviteten ökar. Det råder en specifik brist på marknaden just nu och den kommer att pågå länge. Senare kommer allt att återgå till någon form av normalitet, där effektiviteten i arbetet kommer att öka, det kommer att bli mer och mer serverlöst, en neuron kommer att kopplas till Kubernetes, som kommer att välja alla resurser exakt efter behov, och i allmänhet kommer att gör allt själv, som det ska - personen går bara undan och stör inte.

Men någon kommer fortfarande att behöva fatta beslut. Det är tydligt att denna persons kvalifikationsnivå och specialisering är högre. Numera på redovisningsavdelningen behöver man inte 10 anställda som bokför så att händerna inte blir trötta. Det är helt enkelt inte nödvändigt. Många dokument skannas automatiskt och känns igen av det elektroniska dokumenthanteringssystemet. Det räcker med en smart revisor, redan med mycket större kompetens, med god förståelse.

Generellt sett är det rätt väg att gå inom alla branscher. Det är samma sak med bilar: tidigare kom en bil med en mekaniker och tre förare. Nuförtiden är bilkörning en enkel process som vi alla deltar i varje dag. Ingen tycker att en bil är något komplicerat.

DevOps eller systemteknik kommer inte att försvinna - arbete på hög nivå och effektivitet kommer att öka.

— Jag hörde också en intressant idé om att arbetet faktiskt kommer att öka.

Dmitry: Självklart, hundra procent! För mängden mjukvara vi skriver växer hela tiden. Antalet problem som vi löser med mjukvara växer ständigt. Mängden arbete växer. Nu är DevOps-marknaden fruktansvärt överhettad. Det syns i löneförväntningarna. På ett bra sätt, utan att gå in på detaljer, borde det finnas juniorer som vill ha X, mitten som vill ha 1,5X, och seniorer som vill ha 2X. Och nu, om du tittar på Moscow DevOps lönemarknad, vill en junior ha från X till 3X och en senior vill ha från X till 3X.

Ingen vet hur mycket det kostar. Lönenivån mäts av ditt självförtroende – ett komplett dårhus, om jag ska vara ärlig, en fruktansvärt överhettad marknad.

Naturligtvis kommer denna situation att förändras mycket snart - en viss mättnad bör inträffa. Så är det inte med mjukvaruutveckling – trots att alla behöver utvecklare, och alla behöver bra utvecklare, förstår marknaden vem som är värd vad – har branschen satt sig. Så är inte fallet med DevOps nuförtiden.

— Av vad jag hörde drog jag slutsatsen att den nuvarande systemadministratören inte borde oroa sig för mycket, men det är dags att uppgradera sina färdigheter och förbereda sig på att det imorgon kommer att bli mer arbete, men det kommer att vara mer kvalificerat.

Dmitry: Ett hundra procent. Generellt sett lever vi 2019 och levnadsregeln är denna: livstidsinlärning – vi lär oss hela livet. Det verkar för mig att nu alla redan vet och känner detta, men det räcker inte att veta - du måste göra det. Varje dag måste vi förändras. Om vi ​​inte gör detta kommer vi förr eller senare att släppas vid yrkets sida.

Var beredd på skarpa 180-graders svängar. Jag utesluter inte en situation där något förändras radikalt, något nytt uppfinns - det händer. Hopp! – och nu agerar vi annorlunda. Det är viktigt att vara förberedd på detta och inte oroa sig. Det kan hända att allt jag gör imorgon visar sig vara onödigt - ingenting, jag har pluggat hela mitt liv och är redo att lära mig något annat. Det är inte ett problem. Du behöver inte vara rädd för anställningstryggheten, utan du måste vara beredd på att hela tiden lära dig något nytt.

Önskar och en minuts reklam

- Har du någon önskan?

Dmitry: Ja, jag har flera önskemål.

Första och merkantilt - prenumerera på Youtube. Kära läsare, gå till YouTube och prenumerera på vår kanal. Om ungefär en månad kommer vi att påbörja en aktiv expansion av videotjänsten. Vi kommer att ha mycket pedagogiskt innehåll om Kubernetes, öppet och varierat: från praktiska saker, ända ner till laboratorier, till djupa grundläggande teoretiska saker och hur man använder Kubernetes på nivå av principer och mönster.

Den andra merkantila önskan - gå till GitHub och sätta stjärnor eftersom vi livnär oss på dem. Om du inte ger oss stjärnor har vi inget att äta. Det är som mana i ett datorspel. Vi gör något, vi gör, vi försöker, någon säger att det här är hemska cyklar, någon att allt är helt fel, men vi fortsätter och agerar helt ärligt. Vi ser ett problem, löser det och delar med oss ​​av vår erfarenhet. Därför, ge oss en stjärna, den kommer inte att försvinna från dig, men den kommer till oss, eftersom vi livnär oss på dem.

Tredje, viktig och inte längre merkantil önskan - sluta tro på sagor. Ni är proffs. DevOps är ett mycket seriöst och ansvarsfullt yrke. Sluta leka på arbetsplatsen. Låt det klicka åt dig så förstår du det. Föreställ dig att du kommer till sjukhuset och där experimenterar läkaren med dig. Jag förstår att detta kan vara stötande för någon, men troligen handlar det inte om dig utan om någon annan. Säg åt andra att också sluta. Detta förstör verkligen livet för oss alla – många börjar behandla operationer, administratörer och DevOps som snubbar som har brutit något igen. Detta "bröts" oftast på grund av att vi gick och lekte, och såg inte med kallt medvetande ut att det är så här det är, och så är det.

Det betyder inte att du inte ska experimentera. Vi måste experimentera, vi gör det själva. För att vara ärlig så spelar vi själva ibland spel - det här är naturligtvis väldigt dåligt, men inget mänskligt är oss främmande. Låt oss förklara att 2019 är ett år av seriösa, genomtänkta experiment, och inte spel i produktion. Förmodligen så.

- Tack så mycket!

Dmitry: Tack, Vitaly, både för tiden och för intervjun. Kära läsare, tack så mycket om ni plötsligt har nått denna punkt. Jag hoppas att vi tog med dig åtminstone ett par tankar.

I intervjun berörde Dmitry frågan om werf. Nu är detta en universal schweizisk kniv som löser nästan alla problem. Men det var inte alltid så. På DevOpsConf  på festivalen RIT++ Dmitry Stolyarov kommer att berätta om detta verktyg i detalj. i rapporten "werf är vårt verktyg för CI/CD i Kubernetes" det kommer att finnas allt: problem och dolda nyanser av Kubernetes, alternativ för att lösa dessa svårigheter och den nuvarande implementeringen av werf i detalj. Följ med oss ​​den 27 och 28 maj, vi skapar de perfekta verktygen.

Källa: will.com