Kubernetes will take over the world. When and how?

I förväg DevOpsConf Vitalij Khabarov gjorde en intervju med Dmitrij Stolyarov (distol), teknisk direktör och medgrundare av företaget "Flant". Vitalij frågade Dmitrij om vad "Flant" gör, om Kubernetes, utvecklingen av ekosystemet och support. De diskuterade varför Kubernetes behövs och om det ens är nödvändigt. Dessutom pratade de om mikrotjänster, Amazon AWS, tillvägagångssättet "Jag har tur" i DevOps, framtiden för Kubernetes, varför, när och hur det kommer att ta över världen, perspektiv på DevOps och vad ingenjörer bör förbereda sig för i en ljus och nära framtid med förenklingar och neurala nätverk.

Den ursprungliga intervjun i form av en podcast kan du lyssna på DevOps Deflope — en rysktalande podcast om DevOps, och nedan är den textbaserade versionen.

Här och framåt ställer frågor Vitalij Khabarov ingenjören från Express42.

Om "Flant"

— Dima, hej. Du är den tekniska direktören för "Flant" och också dess grundare. Berätta gärna vad företaget sysslar med och vilken roll du har där.

Dmitrij: Utifrån verkar det som om vi är sådana killar som går runt och installerar Kubernetes på alla och gör något med det. Men så är det inte. Vi började som ett företag som arbetade med Linux, men sedan länge har vår huvudsakliga verksamhet varit att hantera produktions- och högbelastningsprojekt på nyckelfärdig basis. Vanligtvis bygger vi hela infrastrukturen från grunden och ansvarar för den länge. Så, det huvudsakliga arbete som "Flant" gör, och som de får betalt för, är att ta ansvar och genomföra produktion på nyckelfärdig basis.




Jag, som teknisk direktör och en av företagets grundare, sysslar dygnet runt med att komma på hur vi kan öka tillgängligheten i produktionen, förenkla driften, göra livet lättare för administratörer och skapa en trevligare miljö för utvecklarna.

Om Kubernetes

— På sistone har jag sett många föreläsningar från "Flant" och artiklar om Kubernetes. Hur kom ni in på det?

Dmitrij: Jag har redan berättat om detta många gånger, men jag har inget emot att upprepa mig. Jag anser att det är viktigt att repetera detta ämne, eftersom det uppstår förvirring mellan orsak och verkan.

Vi behövde verkligen ett verktyg. Vi stötte på en massa problem, kämpade och övervann dem på olika ad-hoc-sätt och kände behovet av ett verktyg. Vi utforskade många olika alternativ, byggde våra egna lösningar och samlade erfarenhet. Så småningom kom vi till den punkt där vi började använda Docker nästan så fort det blev tillgängligt - runt 2013. Vid tidpunkten för dess ankomst hade vi redan mycket erfarenhet av containrar och hade skrivit en egen variant av "Docker" - en del egna lösningar i Python. Med ankomsten av Docker blev det möjligt att slänga våra ad-hoc-lösningar och använda en pålitlig och gemenskapsstödd lösning.

Historien med Kubernetes är liknande. Vid den tidpunkten då det började ta fart - för oss var det version 1.2 - hade vi redan en massa ad-hoc-lösningar både i Shell och Chef, som vi på något sätt hade försökt orkestrera Docker med. Vi tittade seriöst på Rancher och olika andra lösningar, men då kom Kubernetes, där allt var implementerat precis så som vi skulle ha gjort det eller till och med bättre. Det var inget att klaga på.

Ja, det finns någon sorts ofärdighet här, det finns något ofärdigt där - mycket ofärdigt, och 1.2 är verkligen hemskt, men.... Kubernetes är som en byggnad under uppförande - man ser på projektet och förstår att det kommer att bli fantastiskt. Om byggnaden nu har en grund och två våningar, då förstår man att det är bättre att inte flytta in än, men med mjukvaran finns det inga sådana problem - den går redan att använda.

Vi hade aldrig en stund där vi funderade på om vi skulle använda Kubernetes eller inte. Vi väntade på det långt innan det kom, och försökte själva bygga upp alternativ.

Om Kubernetes

– Deltar ni direkt i utvecklingen av själva Kubernetes?

Dmitrij: Delvis. Vi bidrar snarare till utvecklingen av ekosystemet. Vi skickar in ett visst antal pull requests: i Prometheus, till olika operators, i Helm – till ekosystemet. Tyvärr kan jag inte hålla koll på allt vi gör och kan göra misstag, men vi har inte skickat in något till kärnan.

– Samtidigt utvecklar ni många egna verktyg omkring Kubernetes?

Dmitrij: Strategin är sådan: vi går och gör pull requests till allt som redan finns. Om pull requests inte accepteras där, forklar vi dem för oss själva och lever tills de accepteras med våra byggen. När detta når upstream, återvänder vi till den upstream-versionen.

Till exempel har vi en Prometheus-operator som vi har växlat mellan i vår uppströmsversion av byggnaden för femte gången, antar jag. Vi behöver någon funktion, vi skickade en pull request, vi måste rulla ut den imorgon och vill inte vänta på att den ska släppas i uppströms. Därför bygger vi vår egen version med den funktion vi behöver på alla våra kluster. Sedan i uppströms förpackar de det med orden: "Killarna, låt oss göra det för en mer generell situation", vi, eller någon annan, färdigställer det, och såsmåningom slås det tillbaka.

Allt som existerar strävar vi efter att utveckla.. Många element som ännu inte finns, antingen är de fortfarande inte uppfunna eller så har de uppfunnits men ännu inte implementerats – vi skapar dem. Och inte för att vi gillar själva processen eller att bygga cyklar som bransch, utan helt enkelt för att vi behöver detta verktyg. Ofta ställs frågan varför vi skapade den eller den saken? Svaret är enkelt – jo, för att vi behövde gå vidare, lösa något praktiskt problem, och vi löste det med det här verktyget.

Vägen är alltid sådan: vi letar mycket noggrant och, om vi inte hittar någon lösning på hur man gör en trolleybus av ett bröd, så gör vi vårt eget bröd och vår egen trolleybus.

Flanta-verktyg

– Jag vet att Flanta just nu har addon-operatörer, shell-operatörer, dapp/werf-verktyg. Som jag förstår det är det samma verktyg i olika inkarnationer. Jag förstår också att det finns många olika verktyg inom Flanta. Stämmer det?

Dmitrij: Vi har mycket mer på GitHub. Bland det jag nu kommer ihåg har vi statusmap – en panel för Grafana som alla gillade. Den nämns nästan i varje andra artikel om Kubernetes övervakning på Medium. Det är omöjligt att kortfattat berätta vad statusmap är – en separat artikel krävs, men det är en mycket användbar sak för att övervaka status över tid, eftersom vi ofta behöver visa status över tid i Kubernetes. Vi har också LogHouse – detta är en skapelse baserad på ClickHouse och svart magi för att samla loggar i Kubernetes.

Många verktyg! Och det kommer att bli ännu fler, eftersom ett antal interna lösningar kommer att lanseras i år. Bland de stora baserat på addon-operatören finns det massor av addons för Kubernetes, som hur man korrekt installerar sert manager - ett verktyg för hantering av certifikat, som hur man installerar Prometheus med massor av tillägg - det handlar om tjugotal olika binärer som exporterar data och samlar in något, samt att Prometheus erbjuder fantastisk grafik och alerts. Allt detta är bara massor av addons till Kubernetes, som installeras i klustret, vilket förvandlar det från enkelt till avancerat, automatiserat, där många frågor redan är lösta. Ja, vi gör mycket.

Utveckling av ekosystemet

— Jag tycker att det är ett mycket stort bidrag till utvecklingen av detta verktyg och dess användningsmetoder. Kan du ungefär föreställa dig vilka andra som skulle kunna bidra lika mycket till utvecklingen av ekosystemet?

Dmitrij: I Ryssland, av de företag som verkar på vår marknad - ingen i närheten.. Självklart, det är ett starkt uttalande, eftersom det finns stora aktörer som Mail och Yandex - de gör också något med Kubernetes, men även de har inte kommit nära bidraget från företag runt om i världen, som gör mycket mer än vi. Det är svårt att jämföra "Flant" med en personalstyrka på 80 personer och Red Hat, där bara inom Kubernetes har de 300 ingenjörer, om jag inte minns fel. Det är svårt att jämföra. Vi har 6 personer i vår RnD-avdelning inklusive mig, som arbetar med alla våra verktyg. 6 personer mot 300 ingenjörer på Red Hat - det är på något sätt svårt att jämföra.

— Trots detta kan även dessa 6 personer göra något verkligt användbart och överlåtande när de ställs inför en praktisk uppgift och lämnar en lösning till gemenskapen - en intressant fallstudie. Jag förstår att stora teknikföretag, där det finns egen utveckling och en supportteam för Kubernetes, i princip kan utveckla liknande verktyg. Det är ett exempel för dem att man kan utveckla och ge tillbaka till gemenskapen och ge ett lyft till hela gemenskapen som använder Kubernetes.

Dmitrij: Antagligen är detta en integratorspecialitet. Vi har många projekt och ser många olika situationer. Vår huvudsakliga metod för att skapa mervärde är att analysera dessa fall, hitta gemensamma nämnare och maximera kostnadsminskningen för oss. Det är något vi arbetar aktivt med. Det är svårt för mig att uttala mig om Ryssland och världen, men vi har ungefär 40 DevOps-ingenjörer i företaget som arbetar med Kubernetes. Jag tror inte att det finns många företag i Ryssland med en jämförbar mängd specialister som faktiskt känner till Kubernetes, om de ens finns.

Jag förstår allt om titeln DevOps-ingenjör, alla vet och är vana vid att kalla DevOps-ingenjörer just för DevOps-ingenjörer, vi kommer inte att diskutera det. Alla dessa 40 fantastiska DevOps-ingenjörer står varje dag inför problem och löser dem; vi analyserar bara denna erfarenhet och försöker generalisera. Vi inser att om den stannar hos oss, så inom ett år eller två kommer verktyget att bli värdelöst, eftersom det kommer att dyka upp ett färdigt verktyg någonstans i communityn. Det är meningslöst att samla på sig denna erfarenhet internt – det är bara en förspilld kraft och tid i dev/null. Så vi är verkligen glada över att publicera allt och förstår att vi måste publicera, utveckla, marknadsföra för att folk ska använda det och bidra med sin erfarenhet – då växer allt och lever. På så sätt går verktyget inte till soptippen om två år. Vi har inga problem med att fortsätta investera energi i det, eftersom vi ser att någon faktiskt använder vårt verktyg, och efter två år använder alla det.

Detta är en del av vår stora strategi med dapp/werf.. Jag minns inte när vi började med det, kanske för tre år sedan. Ursprungligen var det helt på shell. Det var en super proof of concept, vi löste några av våra specifika uppgifter – det fungerade! Men med shell finns det problem, det är omöjligt att bygga ut det längre, att programmera på shell är verkligen en utmaning. Vi hade en vana att skriva i Ruby, och vi har därför omskrivit något i Ruby, utvecklat, utvecklat, utvecklat, och vi nådde den punkt där communityn, massan som inte säger "vi vill eller vi vill inte", vänder näsan bort från Ruby, hur osannolikt det än kan vara. Vi insåg att vi måste skriva allt detta i Go för att helt enkelt uppfylla det första villkoret i checklistan: DevOps-verktyget måste vara en statisk binärfil.På Go eller inte på Go spelar inte så stor roll, men en statisk binärfil skriven i Go är bättre.

Vi lade ner tid på att skriva om dapp:en i Go och kallade den werf. Dapp:en stöds inte längre, utvecklas inte, fungerar på någon gammal version, men det finns en absolut uppgraderingsväg uppåt, och den kan följas.

Varför skapades dapp:en

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

Dmitrij: Den första anledningen handlar om byggprocessen. Vi hade från början stora problem med bygget, när Docker inte kunde hantera multi-stage, och vi gjorde multi-stage på egen hand. Sedan hade vi flera frågor kring att rensa images. Alla som gör CI/CD stöter förr eller senare på problemet att det finns massor av byggda images och man måste på något sätt rensa bort det som inte behövs och behålla det som behövs.

Den andra anledningen handlar om deployment. Ja, det finns Helm, men det löser bara en del av problemen. Ironiskt nog står det skrivet att "Helm är paketchefen för Kubernetes". Just det, "paketchefen". Dessutom är det ord som "Paketchef" — vilka förväntningar har man vanligtvis på en paketchef? Vi säger: "Paketchef, installera paket!" och förväntar oss att den svarar: "Paket installerat".

Intressant är att vi säger: "Helm, installera paket", men när den svarar att den har installerat, visar det sig att den bara har påbörjat installationen — den sa till Kubernetes: "Starta den här grejen!", men om det har startats eller inte, om det fungerar eller inte, så löser Helm den frågan överhuvudtaget inte.

Det visar sig att Helm är en enkel textförprocessor som laddar data in i Kubernetes.

Men inom ramen för varje deployment vill vi veta — har applikationen rullats ut i produktion eller inte? Att rullas ut i produktion betyder att applikationen har blivit distribuerad, en ny version har rullats ut, och den ska åtminstone inte krascha utan svara korrekt. Helm löser inte den uppgiften. För att lösa den måste man lägga ner mycket arbete, eftersom det är nödvändigt att ge Kubernetes kommandot att rulla ut och övervaka vad som händer — om det har rullats ut eller inte. Dessutom finns det många andra uppgifter relaterade till deployment, rensning och byggen.

Planer

Ännu i år ska vi gå mot lokal utveckling. Vi vill nå ett tillstånd där vi tidigare hade i Vagrant – man skrev 'vagrant up' och våra virtuella maskiner rullades ut. Vi strävar efter att ha ett projekt i Git där vi skriver 'werf up', och det lyfter en lokal kopia av det projektet, distribuerad i en lokal mini-Kub, med alla kataloger som är bekväma för utveckling. Beroende på programmeringsspråk utförs detta på olika sätt, men vi vill göra det bekvämt att hantera lokal utveckling med monterade filer.

Nästa steg för oss är att kraftigt investera i bekvämlighet för utvecklare. För att snabbt lokalt kunna rulla ut ett projekt, utveckla det, pusha till Git, och det ska sedan rullas ut på stage eller till tester beroende på pipelines, och sedan kan vi med samma verktyg gå till produktion. Den här enheten, standardiseringen, reproducerbarheten av infrastrukturen från den lokala miljön till produktionen är en mycket viktig punkt för oss. Men detta finns fortfarande inte i werf – vi planerar 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 omvägar - hittade på egna lösningar med shell eller vad som helst. Sedan försökte vi på något sätt att strömlinjeforma, generalisera och konsolidera dessa omvägar till binärer som vi bara delar med oss av.

Det finns också en annan syn på hela denna historia, med analogier.

Kubernetes är bilens ram med motorn. Det finns inga dörrar, fönster, radio eller doftgran – ingenting finns. Bara ramen och motorn. Och det finns Helm – det är ratten. Kul – ratten finns, men vi behöver också styrpinne, styrväxel, växellåda och hjul, utan dem fungerar det inte.

I fallet med werf – det är ytterligare en komponent till Kubernetes. Just nu, i vår alpha-version, är till exempel Helm helt kompilerat inuti werf, eftersom vi har tröttnat på att göra det själva. Många skäl till att göra det så, detaljer om varför vi kompilerade helm helt tillsammans med tiller inuti werf, kommer jag precis att berätta på föredraget på RIT++.

Nu är werf en mer integrerad komponent. Vi får en färdig styrning, styrpinne – jag är inte så bra på bilar, men detta är en stor enhet som löser ett brett spektrum av uppgifter. Vi behöver inte själva bläddra i katalogen, plocka en del till en annan, tänka på hur vi ska föra dem samman. Vi får en färdig kombination som direkt löser många problem. Men invändigt är allt konstruerat av samma öppen källkods-komponenter, allt använder Docker för bygg, Helm för vissa funktioner, och det finns några andra bibliotek också. Det är ett integrerat verktyg för att snabbt och enkelt få en fantastisk CI/CD direkt ur lådan.

Är det svårt att underhålla Kubernetes?

– Du berättar om erfarenheten av att ha börjat använda Kubernetes, det är er ram, motor, och att man kan sätta mycket olika saker på det: kaross, ratt, montera pedaler, säten. Frågan uppstår – hur svårt är det för er att underhålla Kubernetes? Ni har en rik erfarenhet, hur mycket tid och resurser går åt till att underhålla Kubernetes? I förhållande till allt annat?

Dmitrij: Det är en mycket komplex fråga och för att svara behöver vi förstå vad som menas med underhåll, och vad vi vill ha från Kubernetes. Kanske du kan förklara?

– Såvitt jag vet och som jag ser det, vill många team nu prova Kubernetes. Alla hoppar på det, installerar det på nolltid. Jag har en känsla av att människor inte alltid förstår komplexiteten i detta system.

Dmitrij: Så är det.

– Hur svårt är det att bara ta och installera Kubernetes från grunden så att det är produktionsklart?

Dmitrij: Hur tror du det är att transplantera ett hjärta? Jag förstår att frågan är besvärlig. Att använda en skalpell och inte göra fel – det är inte så svårt. Om någon visar var man ska skära och var man ska sy, är själva proceduren inte komplicerad. Det är svårt att garantera varje gång att allt lyckas.

Attinstallera Kubernetes och få det att fungera är enkelt: plopp! – installerat, det finns massor av installationsmetoder. Men vad händer när problem uppstår?

Frågor dyker alltid upp – vad har vi missat? Vad har vi inte gjort? Vilka parametrar i Linux-kärnan angav vi fel? Herregud, angav vi dem överhuvudtaget?! Vilka Kubernetes-komponenter installerade vi, och vilka är vi utan? Tusentals frågor dyker upp, och för att svara på dem behövs 15-20 års erfarenhet inom denna industri.

Jag har ett aktuellt exempel på detta ämne som kan belysa frågan "Är det svårt att underhålla Kubernetes?". För en tid sedan övervägde vi allvarligt om vi skulle försöka implementera Cilium som nätverk i Kubernetes.

Jag ska förklara vad Cilium är. I Kubernetes finns det många olika implementeringar av nätverksunderstöd, och en av dem är riktigt bra – det är Cilium. Vad är meningen med detta? I kärnan har det för en tid sedan blivit möjligt att skriva hooks för kärnan, som på olika sätt infiltrerar nätverksunderstödet och olika andra subsystem, vilket gör att man kan kringgå stora delar i kärnan.

I Linux-kärnan finns det historiskt sett ip rout, nätfilter, bryggor och många olika gamla komponenter som är 15, 20 eller 30 år gamla. Generellt fungerar de, allt är bra, men nu har vi skapat massor av containrar, och det ser ut som ett torn av 15 tegelstenar staplade på varandra, och du står på dem på ett ben – en konstig känsla. Det här systemet har historiskt utvecklats med många nyanser, som ett bilaga i kroppen. I vissa situationer finns det prestandaproblem, till exempel.

Det finns ett fantastiskt BPF och möjlighet att skriva hooks för kärnan – killarna har skrivit sina egna hooks för kärnan. Paketet kommer in i Linux-kärnan, de tar bort det direkt vid ingången, bearbetar det som det behövs utan bryggor, utan TCP, utan IP-stack – kort sagt, kringgår allt som är skrivet i Linux-kärnan, och spottar ut det i containern.

Vad blev resultatet? Riktigt bra prestanda, fantastiska funktioner – helt enkelt fantastiskt! Men vi ser att det på varje maskin finns ett program som kopplar upp sig mot Kubernetes API och, baserat på de data som det får från detta API, genererar C-kod och kompilera binärfiler som laddas in i kärnan, så att dessa hooks fungerar i kernel space.

Vad händer om något går fel? Vi vet inte. För att förstå detta behöver man läsa hela den koden, förstå hela logiken, och det är otroligt komplicerat. Men å andra sidan finns det dessa bryggor, nätfilter, ip rout – jag har inte läst deras källkod, och 40 ingenjörer som arbetar på vårt företag har inte heller gjort det. Kanske förstå några bitar, men det är det.

Och vad spelar det för roll? Det visar sig att det finns IP-rout, Linux-kärnan, och det finns ett nytt verktyg – vad spelar det för roll, vi förstår varken det ena eller det andra. Men vi är rädda för att använda det nya – varför? För att om ett verktyg har funnits i 30 år, så har alla buggar hittats, alla fallgropar har trampats på och man behöver inte veta allt – det fungerar som en svart låda och fungerar alltid. Alla vet vilken diagnostikskruvmejsel som ska sättas i vilket ställe, vilken tcpdump som ska köras vid vilken tidpunkt. Alla känner väl till diagnostiska verktyg och förstår hur detta komponentset fungerar i Linux-kärnan – inte hur det är uppbyggt, utan hur man använder det.

Och det fantastiska Cilium är inte 30 år gammalt, det är fortfarande outvecklat. Med Kubernetes är det samma problem, det är en kopia. Både Cilium och Kubernetes installeras utmärkt, men när något går snett i produktion, hur snabbt kan ni förstå vad som har gått fel i en kritisk situation?

När vi pratar om hur svårt det är att underhålla Kubernetes – nej, det är väldigt enkelt, och ja, det är otroligt svårt. Kubernetes fungerar utmärkt i sig själv, men med miljarder nyanser.

Om tillvägagångssättet "Jag har tur"

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

Dmitrij: Nej, det handlar inte om belastning, utan om de mest grundläggande sakerna. Till exempel, vi har Kubernetes, vi har deployat en applikation där. Hur kan vi förstå att den fungerar? Det finns inget färdigt verktyg för att förstå att applikationen inte kraschar, helt enkelt. Det finns inget färdigt system som skickar larm – nej, vi måste konfigurera dessa larm och varje graf. Och vi håller på att uppdatera Kubernetes.

Det finns Ubuntu 16.04. Man kan säga att det här är en gammal version, men vi använder den fortfarande eftersom den är LTS. Den har systemd, och en detalj är att den inte städar C-grupper. Kubernetes startar pods, skapar C-grupper, och sen tar den bort pods, och på något sätt så blir det kvar något som jag inte minns detaljerna om, förlåt, som är systemd-slices. Detta leder till att vilken maskin som helst börjar lagga kraftigt över tid. Det handlar inte ens om highload. Om lämnas kontinuerliga pods körande, till exempel om det finns en Cron Job som ständigt genererar pods, så börjar en maskin med Ubuntu 16.04 lagga efter en vecka. Det kommer alltid att vara en hög load average eftersom det har skapats en massa C-grupper. Detta är ett problem som alla som bara installerar Ubuntu 16 och Kubernetes stöter på.

Låt oss säga att han på något sätt uppdaterar systemd eller något annat, men i Linux-kärnan fram till 4.16 är det ännu roligare - när C-grupper tas bort så droppas de i kärnan och tas faktiskt aldrig bort. Därför är det efter en månads arbete på den här maskinen omöjligt att se minnesstatistik för pods. Vi tar fram en fil, kör den i programmet, och en fil tar 15 sekunder att bearbeta eftersom kärnan tar väldigt lång tid på sig att beräkna inuti sig själv med en miljon C-grupper som verkar vara borttagna, men de droppar fortfarande.

Det finns fortfarande många sådana detaljer här och där. Det är inte en fråga som jätteföretag ibland kan stöta på vid väldigt höga belastningar - nej, det är en fråga om dagliga saker. Människor kan leva med det i månader - de installerade Kubernetes, distribuerade applikationen - det verkar fungera. Många mår bra av det. De kommer inte ens att få veta att applikationen någon gång kommer att krascha, alerten kommer inte att komma, men för dem är det normalt. Tidigare levde de på virtuella maskiner utan övervakning, nu har de flyttat till Kubernetes också utan övervakning - vad spelar det för roll?

Frågan är att när vi går på is, vet vi aldrig tjockleken om vi inte har mätt den i förväg. Många går omkring och bryr sig inte, för de har gått tidigare.

Från min synvinkel är detaljen och svårigheten med att underhålla vilket system som helst att garantera att tjockleken på isen är tillräcklig för att hantera våra uppgifter. Det handlar om detta.

In IT, it seems to me that there are too many approaches based on "I'll get lucky." Many install software and use programming libraries hoping for good luck. Overall, many do get lucky. Perhaps that’s why this works.

— In my pessimistic assessment, it looks like this: when the risks are high, and the application needs to work, support from Flant, possibly from Red Hat, is needed, or a dedicated internal team focused solely on Kubernetes is required to handle it.

Dmitrij: Objectively, this is true. For a small team, diving into Kubernetes independently involves a certain level of risk.

Do we need containers?

— Can you tell me how widespread Kubernetes is in Russia?

Dmitrij: I don’t have that data, and I’m not sure if anyone really does. We talk about “Kubernetes, Kubernetes,” but there’s another perspective on this issue. I also don’t know how widespread containers are, but I know a figure from reports online stating that 70% of containers are orchestrated by Kubernetes. This information comes from a credible source based on a large sample worldwide.

Next question — do we need containers? I have a personal feeling and in general, the position of Flant is that Kubernetes is the de facto standard.

Nothing but Kubernetes will be left.

This is an absolute game changer in the field of infrastructure management. Absolutely — no more Ansible, Chef, virtual machines, or Terraform. I won’t even mention the old methods. Kubernetes is an absolute changer, and it will only be like this from now on.

It’s clear that some people will need a couple of years, while others may need decades to realize this. I have no doubt that there will be nothing but Kubernetes and this new perspective: we no longer hurt the operating system, but use infrastructure as code, except not with code, but with YAML — a declaratively described infrastructure. I feel that this will always be the case.

— So the companies that have not yet transitioned to Kubernetes will either definitely transition or fade into obscurity. Did I understand you correctly?

Dmitrij: Det är inte helt korrekt. Om vi till exempel har uppgiften att starta en DNS-server, kan den köras på FreeBSD 4.10 och fungera utmärkt i 20 år. Den bara fungerar, och that's it. Kanske behöver vi uppdatera något en gång på 20 år. Om vi pratar om programvara som vi har startat och som faktiskt fungerar i många år utan uppdateringar eller förändringar, då behöver vi definitivt inte Kubernetes. Det är onödigt där.

Allt som rör CI/CD — där Continuous Delivery behövs, där versioner måste uppdateras, där aktiva förändringar krävs, där redundans måste byggas — är endast Kubernetes.

Om mikrotjänster

— Här uppstår en viss dissonans för mig. För att arbeta med Kubernetes behöver man extern eller intern support — det är den första punkten. Den andra är — när vi precis börjar med utvecklingen, vi är en liten startup, vi har ännu inget, utveckling för Kubernetes eller ens för mikrotjänstarkitektur kan vara komplicerat och är inte alltid ekonomiskt motiverad. Jag är nyfiken på din åsikt — behöver startups direkt börja koda för Kubernetes, eller kan de ändå skriva en monolit och sedan gå över till Kubernetes?

Dmitrij: Bra fråga. Jag har en presentation om mikrotjänster. “Mikrotjänster: Storleken spelar roll”. Jag har många gånger stött på att folk försöker slå i spikar med ett mikroskop. Själva tillvägagångssättet är korrekt, vi designar även vår interna programvara på detta sätt. Men när man gör det är det viktigt att tydligt förstå vad man gör. Det jag hatar mest med mikrotjänster är ordet "mikro". Det har historiskt uppstått, och av någon anledning tror folk att mikro betyder väldigt liten, mindre än en millimeter, som en mikrometer. Så är det inte.

Till exempel finns det en monolit som skrivs av 300 personer, och alla som deltager i utvecklingen förstår att det finns problem, och den måste brytas ner i mikro-bitar — cirka 10 stycken, varav varje skrivs av 30 personer i minimi-alternativet. Det är viktigt, nödvändigt och fantastiskt. Men när startups kommer till oss där 3 riktigt duktiga och talangfulla killar har skrivit 60 mikrotjänster på knä, då börjar jag alltid leta efter Corvalol.

Jag tror att detta har diskuterats tusentals gånger – vi har fått en distribuerad monolit i någon form. Detta är ekonomiskt ohållbart, mycket komplicerat överlag. Jag har sett detta så många gånger att det faktiskt gör ont, och därför fortsätter jag att prata om det.

Till den inledande frågan, att det finns en konflikt mellan att Kubernetes är skrämmande att använda, eftersom det är oklart vad som kan gå sönder eller inte fungera, och å andra sidan, att det är uppenbart att allt går dit och ingenting annat än Kubernetes kommer att återstå. Svaret är - att väga nyttan som kommer, volymen av uppgifter som ni kan lösa. Detta är på en sida av vågskålen. Å andra sidan finns riskerna som är kopplade till stillestånd eller låg svarstid, nivå av tillgänglighet - med sänkta prestanda.

Så här ligger det till - antingen måste vi agera snabbt, och Kubernetes möjliggör att göra många saker mycket snabbare och bättre, eller använda pålitliga, beprövade lösningar, men agera mycket långsammare. Detta val måste varje företag göra. Man kan se detta som en stig i djungeln - första gången man går, kan man möta en orm, en tiger eller en galen grävling, och efter att ha gått tio gånger - skapa en stig, rensa bort grenar, och det blir lättare att gå. För varje gång blir stigen bredare. Sen blir det en asfalterad väg, och senare en vacker boulevard.

Kubernetes står inte still. Återigen en fråga: på ena sidan är Kubernetes 4-5 binärer, på andra sidan är det hela ekosystemet. Det är operativsystemet som vi har på våra maskiner. Vad är det? Ubuntu eller Curios? Det är Linux-kärnan, massa ytterligare komponenter. Alla dessa saker här har kastat ut en giftig orm från stigen, där har man satt upp staket. Kubernetes utvecklas mycket snabbt och dynamiskt, och volymen av risker, volymen av det outforskade minskar varje månad, och därmed ombalanseras dessa vågar.

När man svarar på frågan om vad ett startup ska göra, skulle jag säga - kom till "Flant", betala 150 000 rubel och få en nyckelfärdig DevOps easy service. Om du är ett litet startup med några utvecklare - detta fungerar. Istället för att anställa din egen DevOps, som måste lära sig att lösa dina problem och få lön under tiden, får du en nyckelfärdig lösning för alla frågor. Ja, det finns några nackdelar. Som outsourcer kan vi inte vara så involverade och snabbt reagera på ändringar. Men vi har massor av expertis och färdiga metoder. Vi garanterar att vi i alla situationer kommer att snabbt lösa problemen och återuppliva vilken Kubernetes som helst.

Jag rekommenderar kategoriskt outsourcing för startups och etablerade företag tills ni kan avsätta ett team på 10 personer för drift, för annars är det meningslöst. Det är kategoriskt vettigt att outsourca.

Om Amazon och Google

— Kan man överväga att outsourca hosting-lösningar från Amazon eller Google?

Dmitrij: Ja, absolut, det löser ett antal frågor. Men återigen, det finns nyanser. Man måste ändå förstå hur det ska användas. Till exempel finns det tusentals små detaljer i arbetet med Amazon AWS: Load Balancer måste värmas upp eller man måste i förväg skicka en begäran om att "grabbar, vi kommer att få trafik, värm upp vår Load Balancer!" Dessa nyanser måste man känna till.

När du vänder dig till personer som specialiserar sig på detta, får du nästan alla standardärenden lösta. Just nu har vi 40 ingenjörer, och vid årets slut kommer det troligen att vara 60 - vi har definitivt stött på alla dessa frågor. Även om vi på något projekt stöter på samma problem igen, frågar vi snabbt varandra och vet hur man löser det.

Sannolikt är svaret så här - självklart gör hosted-lösningar en del enklare. Frågan är om ni är villiga att lita på dessa värdtjänster och om de verkligen löser era problem. Amazon och Google har gjort sig kända på ett bra sätt. För alla våra fall - definitivt. Vi har inte några positiva erfarenheter därutöver. Alla andra moln som vi försökt arbeta med skapar väldigt många problem - både Ager och allt som finns i Ryssland, samt olika implementationer av OpenStack: Headster, Overage - allt ni vill. De skapar alla problem som man helst inte vill hantera.

Därför, svaret är ja, men i praktiken finns det inte så många mogna hosted-lösningar.

Vem behöver Kubernetes?

— Men vem behöver egentligen Kubernetes? Vem bör gå över till Kubernetes, vem är den typiska kunden hos "Flant" som kommer just för Kubernetes?

Dmitrij: Det är en intressant fråga, för just nu kommer många till oss i kölvattnet av Kubernetes: "Grabbar, vi vet att ni gör Kubernetes, gör det åt oss!". Vi svarar: "Mina damer och herrar, vi gör inte Kubernetes, vi gör produktion och allt som hör till det." För att göra produktion utan att ha hela CI/CD processen och allt det där är just nu helt omöjligt. Alla har övergivit uppdelningen mellan utveckling och drift.

Våra kunder förväntar sig olika saker, men alla hoppas på någon slags under som kommer att lösa deras problem, att nu — hux flux! — Kubernetes ska ta hand om det. Människor tror på under. De förstår rationellt att det inte kommer att ske något mirakel, men de hoppas innerligt — kanske kommer detta Kubernetes nu att lösa allt för oss, det pratas så mycket om det! Tänk om det nu — knäpp! — är silverkulan som ger oss 100% uptime, och alla utvecklare kan släppa vad som helst 50 gånger i produktion utan att det kraschar. Det är i stort sett ett mirakel!

När sådana personer kommer till oss säger vi: "Förlåt, men mirakel existerar inte". För att vara frisk behöver man äta bra och träna. För att ha en pålitlig produktion måste man bygga den på ett pålitligt sätt. För att ha en användarvänlig CI/CD måste man göra den sådan. Det är mycket arbete som behöver göras.

För att svara på frågan om vem som behöver Kubernetes — ingen behöver Kubernetes.

Vissa människor har en felaktig uppfattning om att de behöver Kubernetes. Människor vill, de har en djupdragen önskan att slippa tänka på, engagera sig i och vara bekymrade över alla infrastrukturproblem och problem med att driftsätta sina applikationer. De vill att applikationerna bara ska fungera och enkelt kunna deployeras. För dem är Kubernetes ett hopp om att de ska sluta höra historier som "vi har legat efter" eller "vi kan inte deploya" eller något annat.

Vanligtvis kommer en teknisk chef till oss. Man ställer två frågor till honom: å ena sidan, ge oss funktioner, och å andra sidan — stabilitet. Vi föreslår att ta detta på oss och göra det. Silverkulan, eller snarare den silverbelagda, är att du slutar tänka på dessa problem och spara tid. Du kommer att ha specialiserade personer som hanterar dessa frågor.

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

Kubernetes är mycket viktigt för administratörer, eftersom det är en väldigt intressant leksak som man kan experimentera med. Låt oss vara ärliga - alla älskar leksaker. Vi är alla barn på något sätt, och när vi ser något nytt vill vi leka med det. Vissa har kanske tröttnat på detta, till exempel inom administration, eftersom de har lekt tillräckligt och nu blivit uttråkade på en nivå där de helt enkelt inte vill längre. Men ingen har helt tappat detta. Till exempel, även om jag har tröttnat på leksaker inom systemadministration och DevOps, så älskar jag fortfarande leksaker och köper fortfarande nya. Alla människor vill på ett sätt eller annat fortfarande ha sina leksaker.

Man ska inte leka med produktion. Det som jag kategoriskt inte rekommenderar att göra och som jag ser nu i stor utsträckning är: "Åh, en ny leksak!" - springer för att köpa den, köper den och: "Låt oss ta med den till skolan och visa alla våra vänner." Gör inte så. Jag ber om ursäkt, mina barn växer upp, jag ser ständigt saker hos dem, märker det i mig själv och generaliserar det sedan till andra.

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

Det går att uppnå att:

• produktion inte faller;
• även om den försöker falla, så vet vi om det i förväg och kan göra något åt det;
• vi kan ändra den i den takt som vi behöver för verksamheten, och göra det smidigt, vilket inte orsakar några problem för oss.

De verkliga behoven är två: tillförlitlighet och dynamik/flexibilitet i implementeringen. Alla som just nu arbetar med IT-projekt, oavsett vilken bransch - mjukvara för att förenkla världen, och som förstår detta, behöver lösa dessa behov. Med rätt tillvägagångssätt, rätt förståelse och tillräcklig erfarenhet gör Kubernetes det möjligt att lösa dem.

Om serverless

— Om man ser lite längre fram i framtiden, försöker lösa problemet med att slippa huvudvärk med infrastruktur, hastighet på implementering och hastighet på förändring av applikationer, dyker nya lösningar upp, till exempel serverless. Känner du någon potential i denna riktning och, låt oss säga, en risk för Kubernetes och liknande lösningar?

Dmitrij: Här måste jag återigen påpeka att jag inte är en sierska som ser in i framtiden och säger – så här kommer det att bli! Även om jag precis gjorde samma sak. Jag ser på marken och ser massor av problem, till exempel hur transistorer fungerar i en dator. Låt bli, eller hur? Vi står inför olika problem med CPU:n.

Att göra serverless tillräckligt pålitligt, billigt, effektivt och bekvämt, samtidigt som man löser alla ekosystemproblem. Här är jag överens med Elon Musk om att vi behöver en andra planet för att säkerställa mänsklighetens redundans. Även om jag inte vet vad han säger, förstår jag att jag inte är redo att åka till Mars och att det inte kommer att hända imorgon.

Med serverless är det tydligt att det är en ideologiskt riktig väg, precis som redundantitet för mänskligheten – att ha två planeter är bättre än en. Men hur ska vi göra detta nu? Att skicka en expedition är inga problem om man fokuserar sina ansträngningar. Att skicka flera expeditioner och bosätta tusentals människor där gör jag också realistiskt. Men att realisera total redundans så att hälften av mänskligheten bor där verkar för mig just nu omöjligt, något som vi inte ens kan överväga.

Med serverless är det en och samma sak: det är en fantastisk idé, men den är långt ifrån de problem som finns 2019. Närmare 2030 – låt oss överleva fram till dess. Jag tvivlar inte på att vi kommer att överleva, vi kommer definitivt att överleva (upprepa det innan du somnar), men just nu måste vi lösa andra problem. Det är som att tro på en magisk ponny Regnbåge. Ja, flera procent av fallen löses, och de löses alldeles utmärkt, men subjektivt sett är serverless en regnbåge... För mig är detta ämne alltför avlägset och för oklart. Jag är inte redo att prata om det. 2019 kunde inget program skrivas med serverless.

Hur kommer Kubernetes att utvecklas

— Medan vi går mot denna potentiellt fantastiska framtid, vad tror du om hur Kubernetes och ekosystemet kring det kommer att utvecklas?

Dmitrij: Jag har tänkt mycket på detta och jag har ett klart svar. För det första är statefull—att göra stateless är faktiskt lättare. Kubernetes investerade ursprungligen mer i detta, det var där allt började. Stateless fungerar nästan perfekt i Kubernetes, det finns helt enkelt inget att klaga på. Det finns fortfarande många problem, snarare nyanser, med statefull. För oss fungerar allt utmärkt där, men det är vi. För att detta ska fungera för alla, behövs det minst ett par år till. Detta är ingen beräknad siffra, utan min känsla.

Kort sagt, statefull måste—och kommer att—utvecklas mycket, eftersom alla våra applikationer lagrar status, det finns inga stateless-applikationer. Det är en illusion, man behöver alltid någon typ av databas och något annat. Statefull är förkortning av allt som är möjligt, fixering av alla buggar, förbättring av alla problem som vi står inför just nu—låt oss kalla det adoption.

Nivån av det okända, nivån av olösta problem, nivån av sannolikhet att stöta på något, kommer att minska avsevärt. Detta är en viktig aspekt. Och operatörer—allt som har att göra med kodifiering av administrationslogik, styrlogik, för att få en enkel tjänst: MySQL enkel tjänst, RabbitMQ enkel tjänst, Memcache enkel tjänst—alla dessa komponenter vi behöver för att få något att fungera från start utan problem. Detta löser just de svårigheter vi har, att vi vill ha en databas men inte vill administrera den, eller vill ha Kubernetes men inte vill administrera det.

Denna utveckling av operatörer i något av sina uttryck kommer att vara viktig under de kommande åren.

Jag tror att enkelheten i drift starkt kommer att öka—asken kommer att bli allt mer och mer svart, allt mer och mer pålitlig, med allt mer och mer enkla kontroller.

Jag lyssnade någon gång på en gammal intervju med Isaac Asimov från 80-talet på YouTube i programmet Saturday Night Live—en liknande show som Urgant, men intressantare. De frågade honom om framtiden för datorer. Han sa att framtiden ligger i enkelheten, precis som med en radio. Radion var från början en komplicerad grej. För att fånga en signal behövde man vrida på reglagen i 15 minuter, snurra på kontrollerna och överhuvudtaget veta hur allt var konstruerat, förstå fysiken bakom radiovågor. Till slut återstod bara en kontroll på radion.

Vad är radion nu, 2019? I bilen hittar radion alla stationer och deras namn. Fysiken i processen har inte förändrats på 100 år, men användarvänligheten har förbättrats. Nu, även redan 1980 när det gjordes en intervju med Asimov, använde alla radio utan att tänka på hur den fungerade. Den har alltid fungerat – det är en givenhet.

Asimov sa då att det skulle vara likadant med datorerna - användarvänligheten kommer att öka. Om du 1980 behövde en specialutbildning för att trycka på knapparna på en dator, så kommer det inte att vara så i framtiden.

Jag har en känsla av att med Kubernetes och infrastrukturen kommer även användarvänligheten att öka kraftigt. Det är uppenbart – det ligger på ytan.

Vad ska man göra med ingenjörerna?

— Men vad kommer att hända med ingenjörerna och systemadministratörerna som underhåller Kubernetes?

Dmitrij: Vad hände med bokföraren efter att 1C kom? Ungefär samma sak. Tidigare räknade man på papper – nu görs det i ett program. Produktiviteten har ökat många gånger, och arbetet försvann inte därmed. Om det förr behövdes 10 ingenjörer för att skruva i en glödlampa, så räcker det nu med en.

Mängden mjukvara och mängden uppgifter verkar nu växa snabbare än nya DevOps dyker upp och effektiviteten ökar. Just nu råder det en specifik brist på marknaden och den kommer att pågå länge. Senare kommer allt att stabiliseras till en normal nivå där arbetseffektiviteten ökar, det kommer att bli mer serverless, och Kubernetes kommer att kopplas ihop med neurala nätverk som kommer att optimera resurserna precis som det behövs, och allt görs automatiskt – människan kan dra sig tillbaka och inte störa.

Men beslut måste fortfarande fattas av någon. Det är uppenbart att denna persons kompetens och specialisering är högre. Nu i bokföringsavdelningen behövs inte 10 anställda som håller koll på böckerna för att deras händer inte ska bli trötta. Det behövs helt enkelt inte. Många dokument skannas automatiskt och känns igen av systemet för elektronisk dokumenthantering. Det räcker med en smart huvudbokförare, med mycket bättre färdigheter och en god förståelse.

Överlag ser utvecklingen ut på samma sätt i alla branscher. Med bilar är det likadant: tidigare fanns det alltid en bilmekaniker och tre förare kopplade till bilen. Nu är bilkörning en så enkel process att vi alla deltar i den varje dag. Ingen tänker på att bilen är något komplicerat.

DevOps eller systemteknik kommer inte att försvinna — högre nivåer och effektivitet kommer att öka.

– Jag har också hört en intressant idé, att faktiskt även jobbet kommer att öka.

Dmitrij: Självklart, hundra procent! För mängden mjukvara vi skriver växer ständigt. Antalet frågor vi löser med mjukvara växer ständigt. Arbetsmängden ökar. Just nu är DevOps-marknaden extremt överhettad. Detta märks på löneförväntningarna. Egentligen, utan att gå in på detaljer, borde det finnas juniorer som vill ha X, mellanliggande som vill ha 1,5X och seniorer som vill ha 2X. Men nu, om man ser på den moskovitiska DevOps-löneövergripande, önskar en junior mellan X och 3X och en senior mellan X och 3X.

Ingen vet vad det kostar. Lönens nivå mäts av din självförtroende — rena galenskapen, ärligt talat, en extremt överhettad marknad.

Självklart kommer denna situation att förändras mycket snart — det måste bli en viss mättnad. Med mjukvaruutveckling är det inte så — trots att utvecklare alltid behövs, och alla behöver bra utvecklare, vet marknaden vad folk är värda — branschen har stabiliserats. Så är det inte med DevOps nu.

– Av det jag har hört drar jag slutsatsen att den nuvarande systemadministratören inte behöver oroa sig alltför mycket, men det är dags att förbättra sina färdigheter och förbereda sig för att det i morgon kommer att finnas mer arbete, men det kommer att vara mer kvalificerat.

Dmitrij: Helt korrekt. Överlag lever vi år 2019 och livets regel är: lifelong learning — vi lär oss hela livet. Jag tror att alla vet och känner detta nu, men det räcker inte att bara veta — man måste agera. Varje dag måste vi förändras. Om vi inte gör det kommer vi förr eller senare att hamna vid vägrenen av yrket.

Var beredd på snabba vändningar på 180 grader. Jag utesluter inte situationer där något radikalt förändras, att man hittar på något nytt — sånt händer. Hoppsan! — och nu agerar vi annorlunda. Det är viktigt att vara beredd på detta och inte stressa. Det kan hända att allt jag gör imorgon visar sig vara onödigt — inget problem, jag har lärt mig hela mitt liv och är redo att lära mig något annat. Det är ingen big deal. Det är ingen idé att vara rädd för anställningstrygghet, men man måste vara beredd att ständigt lära sig något nytt.

Önskningar och en minut reklam

— Har du något önskemål?

Dmitrij: Ja, jag har några önskemål.

Det första och mer kommersiella — prenumerera på YouTube. Kära läsare, gå in på YouTube och prenumerera på vår kanal. Om ungefär en månad kommer vi att inleda en aktiv expansion på videoservice och vi kommer att ha massor av utbildningsinnehåll om Kubernetes, allt från praktiska saker, inklusive labbar, till djupgående teoretiska principer och hur man tillämpar Kubernetes utifrån principer och mönster.

Det andra kommersiella önskemålet — gå in på GitHub och sätt stjärnor, för vi lever på dem. Om ni inte ger oss stjärnor kommer vi att ha svårt att klara oss. Det är som manna i ett datorspel. Vi gör något, gör något, försöker, någon säger att det är hemska cyklar, någon annat säger att allt är helt fel, och vi fortsätter och agerar helt ärligt. Vi ser ett problem, löser det och delar erfarenhet. Så sätt en stjärna till oss, för er kostar det inget, men vi blir rikare på det, för vi lever på dessa stjärnor.

Det tredje, viktiga, och inte längre kommersiella önskemålet — sluta tro på sagor. Ni är professionella. DevOps är ett väldigt seriöst och ansvarsfullt yrke. Sluta spela på arbetsplatsen. Låt det slå gnistor och ni kommer att förstå detta. Tänk er att ni kommer till ett sjukhus, och där experimenterar läkaren med er. Jag förstår att det kan vara sårande för vissa, men det handlar förmodligen inte om er, utan om någon annan. Säg till andra att de också ska sluta. Det förstör verkligen livet för oss alla — många börjar se på drift, administratörer och DevOps:are som killar som har förstört något igen. Det där «förstörandet» beror oftast på att vi gick in för att leka, istället för att se klart och förstå att det här är så här, och det där så där.

Det betyder inte att vi inte ska experimentera. Vi måste experimentera, vi gör det själva. Om vi är ärliga, så leker vi ibland också - det är förstås mycket dåligt, men inget mänskligt är oss främmande. Låt oss utropa 2019 till året för seriösa genomtänkta experiment, istället för lekar på produktion. Kanske så.

— Stort tack!

Dmitrij: Tack till dig, Vitaliy, både för din tid och för intervjun. Kära läsare, stort tack till er om ni har nått hit. Jag hoppas att vi har erbjudit åtminstone några tankar.

I intervjun berörde Dmitrij frågan om werf. Just nu är det en universell schweizisk armékniv som löser nästan alla problem. Men så har det inte alltid varit. På DevOpsConf  festivalen RIT++ kommer Dmitrij Stolyarov att berätta mer om detta verktyg. I hans föreläsning «werf - vårt verktyg för CI/CD i Kubernetes» kommer allt att tas upp: problem och dolda nyanser i Kubernetes, lösningsalternativ för dessa svårigheter samt den aktuella implementationen av werf i detalj. Anslut er den 27:e och 28:e maj, vi kommer att skapa perfekta verktyg.

Källa: habr.com