{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Kubernetes will take over the world. When and how?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I f\u00f6rv\u00e4g DevOpsConf<\/a><\/noindex> Vitalij Khabarov<\/b> gjorde en intervju med\u00a0Dmitrij Stolyarov<\/b> (distol<\/a><\/noindex>), teknisk direkt\u00f6r och medgrundare av f\u00f6retaget \"Flant\". Vitalij fr\u00e5gade Dmitrij om vad \"Flant\" g\u00f6r, om Kubernetes, utvecklingen av ekosystemet och support. De diskuterade varf\u00f6r Kubernetes beh\u00f6vs och om det ens \u00e4r n\u00f6dv\u00e4ndigt. Dessutom pratade de om mikrotj\u00e4nster, Amazon AWS, tillv\u00e4gag\u00e5ngss\u00e4ttet \"Jag har tur\" i DevOps, framtiden f\u00f6r Kubernetes, varf\u00f6r, n\u00e4r och hur det kommer att ta \u00f6ver v\u00e4rlden, perspektiv p\u00e5 DevOps och vad ingenj\u00f6rer b\u00f6r f\u00f6rbereda sig f\u00f6r i en ljus och n\u00e4ra framtid med f\u00f6renklingar och neurala n\u00e4tverk.<\/p>\n

Den ursprungliga intervjun<\/a><\/noindex> i form av en podcast kan du lyssna p\u00e5 DevOps Deflope \u2014 en rysktalande podcast om DevOps, och nedan \u00e4r den textbaserade versionen. <\/p>\n

\"Kubernetes
\n
\nH\u00e4r och fram\u00e5t st\u00e4ller fr\u00e5gor Vitalij Khabarov<\/a><\/noindex> ingenj\u00f6ren fr\u00e5n Express42.
\n<\/a><\/noindex><\/p>\n

Om \"Flant\"<\/h2>\n

\n\u2014 Dima, hej. Du \u00e4r den tekniska direkt\u00f6ren f\u00f6r \"Flant<\/a><\/noindex>\" och ocks\u00e5 dess grundare. Ber\u00e4tta g\u00e4rna vad f\u00f6retaget sysslar med och vilken roll du har d\u00e4r.<\/b><\/p>\n

\"KubernetesDmitrij<\/b>: Utifr\u00e5n verkar det som om vi \u00e4r s\u00e5dana killar som g\u00e5r runt och installerar Kubernetes p\u00e5 alla och g\u00f6r n\u00e5got med det. Men s\u00e5 \u00e4r det inte. Vi b\u00f6rjade som ett f\u00f6retag som arbetade med Linux, men sedan l\u00e4nge har v\u00e5r huvudsakliga verksamhet varit att hantera produktions- och h\u00f6gbelastningsprojekt p\u00e5 nyckelf\u00e4rdig basis. Vanligtvis bygger vi hela infrastrukturen fr\u00e5n grunden och ansvarar f\u00f6r den l\u00e4nge. S\u00e5, det huvudsakliga arbete som \"Flant\" g\u00f6r, och som de f\u00e5r betalt f\u00f6r, \u00e4r att ta ansvar och genomf\u00f6ra produktion p\u00e5 nyckelf\u00e4rdig basis<\/b>.
\n

\n

\nJag, som teknisk direkt\u00f6r och en av f\u00f6retagets grundare, sysslar dygnet runt med att komma p\u00e5 hur vi kan \u00f6ka tillg\u00e4ngligheten i produktionen, f\u00f6renkla driften, g\u00f6ra livet l\u00e4ttare f\u00f6r administrat\u00f6rer och skapa en trevligare milj\u00f6 f\u00f6r utvecklarna.<\/p>\n

Om Kubernetes<\/h2>\n

\n\u2014 P\u00e5 sistone har jag sett m\u00e5nga f\u00f6rel\u00e4sningar fr\u00e5n \"Flant\" och\u00a0artiklar<\/a><\/noindex> om Kubernetes. Hur kom ni in p\u00e5 det?<\/b><\/p>\n

Dmitrij<\/b>: Jag har redan ber\u00e4ttat om detta m\u00e5nga g\u00e5nger, men jag har inget emot att upprepa mig. Jag anser att det \u00e4r viktigt att repetera detta \u00e4mne, eftersom det uppst\u00e5r f\u00f6rvirring mellan orsak och verkan.<\/p>\n

Vi beh\u00f6vde verkligen ett verktyg. Vi st\u00f6tte p\u00e5 en massa problem, k\u00e4mpade och \u00f6vervann dem p\u00e5 olika ad-hoc-s\u00e4tt och k\u00e4nde behovet av ett verktyg. Vi utforskade m\u00e5nga olika alternativ, byggde v\u00e5ra egna l\u00f6sningar och samlade erfarenhet. S\u00e5 sm\u00e5ningom kom vi till den punkt d\u00e4r vi b\u00f6rjade anv\u00e4nda Docker n\u00e4stan s\u00e5 fort det blev tillg\u00e4ngligt - runt 2013. Vid tidpunkten f\u00f6r dess ankomst hade vi redan mycket erfarenhet av containrar och hade skrivit en egen variant av \"Docker\" - en del egna l\u00f6sningar i Python. Med ankomsten av Docker blev det m\u00f6jligt att sl\u00e4nga v\u00e5ra ad-hoc-l\u00f6sningar och anv\u00e4nda en p\u00e5litlig och gemenskapsst\u00f6dd l\u00f6sning.<\/p>\n

Historien med Kubernetes \u00e4r liknande. Vid den tidpunkten d\u00e5 det b\u00f6rjade ta fart - f\u00f6r oss var det version 1.2 - hade vi redan en massa ad-hoc-l\u00f6sningar b\u00e5de i Shell och Chef, som vi p\u00e5 n\u00e5got s\u00e4tt hade f\u00f6rs\u00f6kt orkestrera Docker med. Vi tittade seri\u00f6st p\u00e5 Rancher och olika andra l\u00f6sningar, men d\u00e5 kom Kubernetes, d\u00e4r allt var implementerat precis s\u00e5 som vi skulle ha gjort det eller till och med b\u00e4ttre. Det var inget att klaga p\u00e5.<\/p>\n

Ja, h\u00e4r finns det olika brister, d\u00e4r en viss brist - mycket brister, och 1.2 \u00e4r verkligen skr\u00e4mmande, men ... Kubernetes \u00e4r som en byggnad under konstruktion - man ser p\u00e5 projektet och f\u00f6rst\u00e5r att det kommer att bli fantastiskt. Om byggnaden just nu har fundament och tv\u00e5 v\u00e5ningar, s\u00e5 f\u00f6rst\u00e5r man att det \u00e4r b\u00e4st att inte flytta in \u00e4n, men med mjukvaran finns det inga s\u00e5dana problem - den g\u00e5r redan att anv\u00e4nda.<\/p>\n

Vi hade aldrig en stund d\u00e4r vi funderade p\u00e5 om vi skulle anv\u00e4nda Kubernetes eller inte. Vi v\u00e4ntade p\u00e5 det l\u00e5ngt innan det kom, och f\u00f6rs\u00f6kte sj\u00e4lva bygga upp alternativ.<\/p><\/blockquote>\n

<\/p>\n

Om Kubernetes<\/h2>\n

\n\u2013 Deltar ni direkt i utvecklingen av sj\u00e4lva Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: Delvis. Vi bidrar snarare till utvecklingen av ekosystemet. Vi skickar in ett visst antal pull requests: i Prometheus, till olika operators, i Helm \u2013 till ekosystemet. Tyv\u00e4rr kan jag inte h\u00e5lla koll p\u00e5 allt vi g\u00f6r och kan g\u00f6ra misstag, men vi har inte skickat in n\u00e5got till k\u00e4rnan.<\/p>\n

\u2013 Samtidigt utvecklar ni m\u00e5nga egna verktyg omkring Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: Strategin \u00e4r s\u00e5dan: vi g\u00e5r och g\u00f6r pull requests till allt som redan finns. Om pull requests inte accepteras d\u00e4r, forklar vi dem f\u00f6r oss sj\u00e4lva och lever tills de accepteras med v\u00e5ra byggen. N\u00e4r detta n\u00e5r upstream, \u00e5terv\u00e4nder vi till den upstream-versionen.<\/p>\n

Till exempel har vi en Prometheus-operator som vi har v\u00e4xlat mellan i v\u00e5r uppstr\u00f6msversion av byggnaden f\u00f6r femte g\u00e5ngen, antar jag. Vi beh\u00f6ver n\u00e5gon funktion, vi skickade en pull request, vi m\u00e5ste rulla ut den imorgon och vill inte v\u00e4nta p\u00e5 att den ska sl\u00e4ppas i uppstr\u00f6ms. D\u00e4rf\u00f6r bygger vi v\u00e5r egen version med den funktion vi beh\u00f6ver p\u00e5 alla v\u00e5ra kluster. Sedan i uppstr\u00f6ms f\u00f6rpackar de det med orden: \"Killarna, l\u00e5t oss g\u00f6ra det f\u00f6r en mer generell situation\", vi, eller n\u00e5gon annan, f\u00e4rdigst\u00e4ller det, och s\u00e5sm\u00e5ningom sl\u00e5s det tillbaka.<\/p>\n

Allt som existerar str\u00e4var vi efter att utveckla.<\/b>. M\u00e5nga element som \u00e4nnu inte finns, antingen \u00e4r de fortfarande inte uppfunna eller s\u00e5 har de uppfunnits men \u00e4nnu inte implementerats \u2013 vi skapar dem. Och inte f\u00f6r att vi gillar sj\u00e4lva processen eller att bygga cyklar som bransch, utan helt enkelt f\u00f6r att vi beh\u00f6ver detta verktyg. Ofta st\u00e4lls fr\u00e5gan varf\u00f6r vi skapade den eller den saken? Svaret \u00e4r enkelt \u2013 jo, f\u00f6r att vi beh\u00f6vde g\u00e5 vidare, l\u00f6sa n\u00e5got praktiskt problem, och vi l\u00f6ste det med det h\u00e4r verktyget.<\/p>\n

V\u00e4gen \u00e4r alltid s\u00e5dan: vi letar mycket noggrant och, om vi inte hittar n\u00e5gon l\u00f6sning p\u00e5 hur man g\u00f6r en trolleybus av ett br\u00f6d, s\u00e5 g\u00f6r vi v\u00e5rt eget br\u00f6d och v\u00e5r egen trolleybus.<\/p><\/blockquote>\n

<\/p>\n

Flanta-verktyg<\/h2>\n

\n\u2013 Jag vet att Flanta just nu har addon-operat\u00f6rer, shell-operat\u00f6rer, dapp\/werf-verktyg. Som jag f\u00f6rst\u00e5r det \u00e4r det samma verktyg i olika inkarnationer. Jag f\u00f6rst\u00e5r ocks\u00e5 att det finns m\u00e5nga olika verktyg inom Flanta. St\u00e4mmer det?<\/b><\/p>\n

Dmitrij<\/b>: Vi har mycket mer p\u00e5 GitHub. Bland det jag nu kommer ih\u00e5g har vi statusmap \u2013 en panel f\u00f6r Grafana som alla gillade. Den n\u00e4mns n\u00e4stan i varje andra artikel om Kubernetes \u00f6vervakning p\u00e5 Medium. Det \u00e4r om\u00f6jligt att kortfattat ber\u00e4tta vad statusmap \u00e4r \u2013 en separat artikel kr\u00e4vs, men det \u00e4r en mycket anv\u00e4ndbar sak f\u00f6r att \u00f6vervaka status \u00f6ver tid, eftersom vi ofta beh\u00f6ver visa status \u00f6ver tid i Kubernetes. Vi har ocks\u00e5 LogHouse \u2013 detta \u00e4r en skapelse baserad p\u00e5 ClickHouse och svart magi f\u00f6r att samla loggar i Kubernetes.<\/p>\n

M\u00e5nga verktyg! Och det kommer att bli \u00e4nnu fler, eftersom ett antal interna l\u00f6sningar kommer att lanseras i \u00e5r. Bland de stora baserat p\u00e5 addon-operat\u00f6ren finns det massor av addons f\u00f6r Kubernetes, som hur man korrekt installerar sert manager - ett verktyg f\u00f6r hantering av certifikat, som hur man installerar Prometheus med massor av till\u00e4gg - det handlar om tjugotal olika bin\u00e4rer som exporterar data och samlar in n\u00e5got, samt att Prometheus erbjuder fantastisk grafik och alerts. Allt detta \u00e4r bara massor av addons till Kubernetes, som installeras i klustret, vilket f\u00f6rvandlar det fr\u00e5n enkelt till avancerat, automatiserat, d\u00e4r m\u00e5nga fr\u00e5gor redan \u00e4r l\u00f6sta. Ja, vi g\u00f6r mycket.<\/p>\n

Utveckling av ekosystemet<\/h2>\n

\n\u2014 Jag tycker att det \u00e4r ett mycket stort bidrag till utvecklingen av detta verktyg och dess anv\u00e4ndningsmetoder. Kan du ungef\u00e4r f\u00f6rest\u00e4lla dig vilka andra som skulle kunna bidra lika mycket till utvecklingen av ekosystemet?<\/b><\/p>\n

Dmitrij<\/b>: I Ryssland, av de f\u00f6retag som verkar p\u00e5 v\u00e5r marknad - ingen i n\u00e4rheten.<\/b>. Sj\u00e4lvklart, det \u00e4r ett starkt uttalande, eftersom det finns stora akt\u00f6rer som Mail och Yandex - de g\u00f6r ocks\u00e5 n\u00e5got med Kubernetes, men \u00e4ven de har inte kommit n\u00e4ra bidraget fr\u00e5n f\u00f6retag runt om i v\u00e4rlden, som g\u00f6r mycket mer \u00e4n vi. Det \u00e4r sv\u00e5rt att j\u00e4mf\u00f6ra \"Flant\" med en personalstyrka p\u00e5 80 personer och Red Hat, d\u00e4r bara inom Kubernetes har de 300 ingenj\u00f6rer, om jag inte minns fel. Det \u00e4r sv\u00e5rt att j\u00e4mf\u00f6ra. Vi har 6 personer i v\u00e5r RnD-avdelning inklusive mig, som arbetar med alla v\u00e5ra verktyg. 6 personer mot 300 ingenj\u00f6rer p\u00e5 Red Hat - det \u00e4r p\u00e5 n\u00e5got s\u00e4tt sv\u00e5rt att j\u00e4mf\u00f6ra.<\/p>\n

\u2014 Trots detta kan \u00e4ven dessa 6 personer g\u00f6ra n\u00e5got verkligt anv\u00e4ndbart och \u00f6verl\u00e5tande n\u00e4r de st\u00e4lls inf\u00f6r en praktisk uppgift och l\u00e4mnar en l\u00f6sning till gemenskapen - en intressant fallstudie. Jag f\u00f6rst\u00e5r att stora teknikf\u00f6retag, d\u00e4r det finns egen utveckling och en supportteam f\u00f6r Kubernetes, i princip kan utveckla liknande verktyg. Det \u00e4r ett exempel f\u00f6r dem att man kan utveckla och ge tillbaka till gemenskapen och ge ett lyft till hela gemenskapen som anv\u00e4nder Kubernetes.<\/b><\/p>\n

Dmitrij<\/b>: Antagligen \u00e4r detta en integratorspecialitet. Vi har m\u00e5nga projekt och ser m\u00e5nga olika situationer. V\u00e5r huvudsakliga metod f\u00f6r att skapa merv\u00e4rde \u00e4r att analysera dessa fall, hitta gemensamma n\u00e4mnare och maximera kostnadsminskningen f\u00f6r oss. Det \u00e4r n\u00e5got vi arbetar aktivt med. Det \u00e4r sv\u00e5rt f\u00f6r mig att uttala mig om Ryssland och v\u00e4rlden, men vi har ungef\u00e4r 40 DevOps-ingenj\u00f6rer i f\u00f6retaget som arbetar med Kubernetes. Jag tror inte att det finns m\u00e5nga f\u00f6retag i Ryssland med en j\u00e4mf\u00f6rbar m\u00e4ngd specialister som faktiskt k\u00e4nner till Kubernetes, om de ens finns.<\/p>\n

Jag f\u00f6rst\u00e5r allt om titeln DevOps-ingenj\u00f6r, alla vet och \u00e4r vana vid att kalla DevOps-ingenj\u00f6rer just f\u00f6r DevOps-ingenj\u00f6rer, vi kommer inte att diskutera det. Alla dessa 40 fantastiska DevOps-ingenj\u00f6rer st\u00e5r varje dag inf\u00f6r problem och l\u00f6ser dem; vi analyserar bara denna erfarenhet och f\u00f6rs\u00f6ker generalisera. Vi inser att om den stannar hos oss, s\u00e5 inom ett \u00e5r eller tv\u00e5 kommer verktyget att bli v\u00e4rdel\u00f6st, eftersom det kommer att dyka upp ett f\u00e4rdigt verktyg n\u00e5gonstans i communityn. Det \u00e4r meningsl\u00f6st att samla p\u00e5 sig denna erfarenhet internt \u2013 det \u00e4r bara en f\u00f6rspilld kraft och tid i dev\/null. S\u00e5 vi \u00e4r verkligen glada \u00f6ver att publicera allt och f\u00f6rst\u00e5r att vi m\u00e5ste publicera, utveckla, marknadsf\u00f6ra f\u00f6r att folk ska anv\u00e4nda det och bidra med sin erfarenhet \u2013 d\u00e5 v\u00e4xer allt och lever. P\u00e5 s\u00e5 s\u00e4tt g\u00e5r verktyget inte till soptippen om tv\u00e5 \u00e5r. Vi har inga problem med att forts\u00e4tta investera energi i det, eftersom vi ser att n\u00e5gon faktiskt anv\u00e4nder v\u00e5rt verktyg, och efter tv\u00e5 \u00e5r anv\u00e4nder alla det.<\/p>\n

Detta \u00e4r en del av v\u00e5r stora strategi med dapp\/werf.<\/b>. Jag minns inte n\u00e4r vi b\u00f6rjade med det, kanske f\u00f6r tre \u00e5r sedan. Ursprungligen var det helt p\u00e5 shell. Det var en super proof of concept, vi l\u00f6ste n\u00e5gra av v\u00e5ra specifika uppgifter \u2013 det fungerade! Men med shell finns det problem, det \u00e4r om\u00f6jligt att bygga ut det l\u00e4ngre, att programmera p\u00e5 shell \u00e4r verkligen en utmaning. Vi hade en vana att skriva i Ruby, och vi har d\u00e4rf\u00f6r omskrivit n\u00e5got i Ruby, utvecklat, utvecklat, utvecklat, och vi n\u00e5dde den punkt d\u00e4r communityn, massan som inte s\u00e4ger \"vi vill eller vi vill inte\", v\u00e4nder n\u00e4san bort fr\u00e5n Ruby, hur osannolikt det \u00e4n kan vara. Vi ins\u00e5g att vi m\u00e5ste skriva allt detta i Go f\u00f6r att helt enkelt uppfylla det f\u00f6rsta villkoret i checklistan: DevOps-verktyget m\u00e5ste vara en statisk bin\u00e4rfil.<\/b>P\u00e5 Go eller inte p\u00e5 Go spelar inte s\u00e5 stor roll, men en statisk bin\u00e4rfil skriven i Go \u00e4r b\u00e4ttre.<\/p>\n

Vi lade ner tid p\u00e5 att skriva om dapp:en i Go och kallade den werf. Dapp:en st\u00f6ds inte l\u00e4ngre, utvecklas inte, fungerar p\u00e5 n\u00e5gon gammal version, men det finns en absolut uppgraderingsv\u00e4g upp\u00e5t, och den kan f\u00f6ljas.<\/p>\n

Varf\u00f6r skapades dapp:en<\/h2>\n

\n\u2014 Kan du kort ber\u00e4tta varf\u00f6r dapp:en skapades, vilka problem den l\u00f6ser?<\/b><\/p>\n

Dmitrij<\/b>: Den f\u00f6rsta anledningen handlar om byggprocessen. Vi hade fr\u00e5n b\u00f6rjan stora problem med bygget, n\u00e4r Docker inte kunde hantera multi-stage, och vi gjorde multi-stage p\u00e5 egen hand. Sedan hade vi flera fr\u00e5gor kring att rensa images. Alla som g\u00f6r CI\/CD st\u00f6ter f\u00f6rr eller senare p\u00e5 problemet att det finns massor av byggda images och man m\u00e5ste p\u00e5 n\u00e5got s\u00e4tt rensa bort det som inte beh\u00f6vs och beh\u00e5lla det som beh\u00f6vs.<\/p>\n

Den andra anledningen handlar om deployment. Ja, det finns Helm, men det l\u00f6ser bara en del av problemen. Ironiskt nog st\u00e5r det skrivet att \"Helm \u00e4r paketchefen f\u00f6r Kubernetes\". Just det, \"paketchefen\". Dessutom \u00e4r det ord som \"Paketchef\" \u2014 vilka f\u00f6rv\u00e4ntningar har man vanligtvis p\u00e5 en paketchef? Vi s\u00e4ger: \"Paketchef, installera paket!\" och f\u00f6rv\u00e4ntar oss att den svarar: \"Paket installerat\". <\/p>\n

Intressant \u00e4r att vi s\u00e4ger: \"Helm, installera paket\", men n\u00e4r den svarar att den har installerat, visar det sig att den bara har p\u00e5b\u00f6rjat installationen \u2014 den sa till Kubernetes: \"Starta den h\u00e4r grejen!\", men om det har startats eller inte, om det fungerar eller inte, s\u00e5 l\u00f6ser Helm den fr\u00e5gan \u00f6verhuvudtaget inte.<\/p>\n

Det visar sig att Helm \u00e4r en enkel textf\u00f6rprocessor som laddar data in i Kubernetes.<\/p><\/blockquote>\n

\nMen inom ramen f\u00f6r varje deployment vill vi veta \u2014 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 \u00e5tminstone inte krascha utan svara korrekt. Helm l\u00f6ser inte den uppgiften. F\u00f6r att l\u00f6sa den m\u00e5ste man l\u00e4gga ner mycket arbete, eftersom det \u00e4r n\u00f6dv\u00e4ndigt att ge Kubernetes kommandot att rulla ut och \u00f6vervaka vad som h\u00e4nder \u2014 om det har rullats ut eller inte. Dessutom finns det m\u00e5nga andra uppgifter relaterade till deployment, rensning och byggen.<\/p>\n

Planer<\/h2>\n

\n\u00c4nnu i \u00e5r ska vi g\u00e5 mot lokal utveckling. Vi vill n\u00e5 ett tillst\u00e5nd d\u00e4r vi tidigare hade i Vagrant \u2013 man skrev 'vagrant up' och v\u00e5ra virtuella maskiner rullades ut. Vi str\u00e4var efter att ha ett projekt i Git d\u00e4r vi skriver 'werf up', och det lyfter en lokal kopia av det projektet, distribuerad i en lokal mini-Kub, med alla kataloger som \u00e4r bekv\u00e4ma f\u00f6r utveckling. Beroende p\u00e5 programmeringsspr\u00e5k utf\u00f6rs detta p\u00e5 olika s\u00e4tt, men vi vill g\u00f6ra det bekv\u00e4mt att hantera lokal utveckling med monterade filer.<\/p>\n

N\u00e4sta steg f\u00f6r oss \u00e4r att kraftigt investera i bekv\u00e4mlighet f\u00f6r utvecklare<\/b>. F\u00f6r att snabbt lokalt kunna rulla ut ett projekt, utveckla det, pusha till Git, och det ska sedan rullas ut p\u00e5 stage eller till tester beroende p\u00e5 pipelines, och sedan kan vi med samma verktyg g\u00e5 till produktion. Den h\u00e4r enheten, standardiseringen, reproducerbarheten av infrastrukturen fr\u00e5n den lokala milj\u00f6n till produktionen \u00e4r en mycket viktig punkt f\u00f6r oss. Men detta finns fortfarande inte i werf \u2013 vi planerar att g\u00f6ra det.<\/p>\n

Men v\u00e4gen till dapp\/werf har alltid varit densamma som med Kubernetes i b\u00f6rjan. Vi st\u00f6tte p\u00e5 problem, l\u00f6ste dem med omv\u00e4gar - hittade p\u00e5 egna l\u00f6sningar med shell eller vad som helst. Sedan f\u00f6rs\u00f6kte vi p\u00e5 n\u00e5got s\u00e4tt att str\u00f6mlinjeforma, generalisera och konsolidera dessa omv\u00e4gar till bin\u00e4rer som vi bara delar med oss av.<\/p>\n

Det finns ocks\u00e5 en annan syn p\u00e5 hela denna historia, med analogier. <\/p>\n

Kubernetes \u00e4r bilens ram med motorn. Det finns inga d\u00f6rrar, f\u00f6nster, radio eller doftgran \u2013 ingenting finns. Bara ramen och motorn. Och det finns Helm \u2013 det \u00e4r ratten. Kul \u2013 ratten finns, men vi beh\u00f6ver ocks\u00e5 styrpinne, styrv\u00e4xel, v\u00e4xell\u00e5da och hjul, utan dem fungerar det inte.<\/p><\/blockquote>\n

\nI fallet med werf \u2013 det \u00e4r ytterligare en komponent till Kubernetes. Just nu, i v\u00e5r alpha-version, \u00e4r till exempel Helm helt kompilerat inuti werf, eftersom vi har tr\u00f6ttnat p\u00e5 att g\u00f6ra det sj\u00e4lva. M\u00e5nga sk\u00e4l till att g\u00f6ra det s\u00e5, detaljer om varf\u00f6r vi kompilerade helm helt tillsammans med tiller inuti werf, kommer jag precis att ber\u00e4tta p\u00e5 f\u00f6redraget p\u00e5 RIT++<\/a><\/noindex>.<\/p>\n

Nu \u00e4r werf en mer integrerad komponent. Vi f\u00e5r en f\u00e4rdig styrning, styrpinne \u2013 jag \u00e4r inte s\u00e5 bra p\u00e5 bilar, men detta \u00e4r en stor enhet som l\u00f6ser ett brett spektrum av uppgifter. Vi beh\u00f6ver inte sj\u00e4lva bl\u00e4ddra i katalogen, plocka en del till en annan, t\u00e4nka p\u00e5 hur vi ska f\u00f6ra dem samman. Vi f\u00e5r en f\u00e4rdig kombination som direkt l\u00f6ser m\u00e5nga problem. Men inv\u00e4ndigt \u00e4r allt konstruerat av samma \u00f6ppen k\u00e4llkods-komponenter, allt anv\u00e4nder Docker f\u00f6r bygg, Helm f\u00f6r vissa funktioner, och det finns n\u00e5gra andra bibliotek ocks\u00e5. Det \u00e4r ett integrerat verktyg f\u00f6r att snabbt och enkelt f\u00e5 en fantastisk CI\/CD direkt ur l\u00e5dan.<\/p>\n

\u00c4r det sv\u00e5rt att underh\u00e5lla Kubernetes?<\/h2>\n

\n\u2013 Du ber\u00e4ttar om erfarenheten av att ha b\u00f6rjat anv\u00e4nda Kubernetes, det \u00e4r er ram, motor, och att man kan s\u00e4tta mycket olika saker p\u00e5 det: kaross, ratt, montera pedaler, s\u00e4ten. Fr\u00e5gan uppst\u00e5r \u2013 hur sv\u00e5rt \u00e4r det f\u00f6r er att underh\u00e5lla Kubernetes? Ni har en rik erfarenhet, hur mycket tid och resurser g\u00e5r \u00e5t till att underh\u00e5lla Kubernetes? I f\u00f6rh\u00e5llande till allt annat?<\/b><\/p>\n

Dmitrij<\/b>: Det \u00e4r en mycket komplex fr\u00e5ga och f\u00f6r att svara beh\u00f6ver vi f\u00f6rst\u00e5 vad som menas med underh\u00e5ll, och vad vi vill ha fr\u00e5n Kubernetes. Kanske du kan f\u00f6rklara?<\/p>\n

\u2013 S\u00e5vitt jag vet och som jag ser det, vill m\u00e5nga team nu prova Kubernetes. Alla hoppar p\u00e5 det, installerar det p\u00e5 nolltid. Jag har en k\u00e4nsla av att m\u00e4nniskor inte alltid f\u00f6rst\u00e5r komplexiteten i detta system.<\/b><\/p>\n

Dmitrij<\/b>: S\u00e5 \u00e4r det.<\/p>\n

\u2013 Hur sv\u00e5rt \u00e4r det att bara ta och installera Kubernetes fr\u00e5n grunden s\u00e5 att det \u00e4r produktionsklart?<\/b><\/p>\n

Dmitrij<\/b>: Hur tror du det \u00e4r att transplantera ett hj\u00e4rta? Jag f\u00f6rst\u00e5r att fr\u00e5gan \u00e4r besv\u00e4rlig. Att anv\u00e4nda en skalpell och inte g\u00f6ra fel \u2013 det \u00e4r inte s\u00e5 sv\u00e5rt. Om n\u00e5gon visar var man ska sk\u00e4ra och var man ska sy, \u00e4r sj\u00e4lva proceduren inte komplicerad. Det \u00e4r sv\u00e5rt att garantera varje g\u00e5ng att allt lyckas.<\/p>\n

Attinstallera Kubernetes och f\u00e5 det att fungera \u00e4r enkelt: plopp! \u2013 installerat, det finns massor av installationsmetoder. Men vad h\u00e4nder n\u00e4r problem uppst\u00e5r?<\/p><\/blockquote>\n

\nFr\u00e5gor dyker alltid upp \u2013 vad har vi missat? Vad har vi inte gjort? Vilka parametrar i Linux-k\u00e4rnan angav vi fel? Herregud, angav vi dem \u00f6verhuvudtaget?! Vilka Kubernetes-komponenter installerade vi, och vilka \u00e4r vi utan? Tusentals fr\u00e5gor dyker upp, och f\u00f6r att svara p\u00e5 dem beh\u00f6vs 15-20 \u00e5rs erfarenhet inom denna industri.<\/p>\n

Jag har ett aktuellt exempel p\u00e5 detta \u00e4mne som kan belysa fr\u00e5gan \"\u00c4r det sv\u00e5rt att underh\u00e5lla Kubernetes?\". F\u00f6r en tid sedan \u00f6verv\u00e4gde vi allvarligt om vi skulle f\u00f6rs\u00f6ka implementera Cilium som n\u00e4tverk i Kubernetes.<\/p>\n

Jag ska f\u00f6rklara vad Cilium \u00e4r. I Kubernetes finns det m\u00e5nga olika implementeringar av n\u00e4tverksunderst\u00f6d, och en av dem \u00e4r riktigt bra \u2013 det \u00e4r Cilium. Vad \u00e4r meningen med detta? I k\u00e4rnan har det f\u00f6r en tid sedan blivit m\u00f6jligt att skriva hooks f\u00f6r k\u00e4rnan, som p\u00e5 olika s\u00e4tt infiltrerar n\u00e4tverksunderst\u00f6det och olika andra subsystem, vilket g\u00f6r att man kan kringg\u00e5 stora delar i k\u00e4rnan.<\/p>\n

I Linux-k\u00e4rnan finns det historiskt sett ip rout, n\u00e4tfilter, bryggor och m\u00e5nga olika gamla komponenter som \u00e4r 15, 20 eller 30 \u00e5r gamla. Generellt fungerar de, allt \u00e4r bra, men nu har vi skapat massor av containrar, och det ser ut som ett torn av 15 tegelstenar staplade p\u00e5 varandra, och du st\u00e5r p\u00e5 dem p\u00e5 ett ben \u2013 en konstig k\u00e4nsla. Det h\u00e4r systemet har historiskt utvecklats med m\u00e5nga nyanser, som ett bilaga i kroppen. I vissa situationer finns det prestandaproblem, till exempel.<\/p>\n

Det finns ett fantastiskt BPF och m\u00f6jlighet att skriva hooks f\u00f6r k\u00e4rnan \u2013 killarna har skrivit sina egna hooks f\u00f6r k\u00e4rnan. Paketet kommer in i Linux-k\u00e4rnan, de tar bort det direkt vid ing\u00e5ngen, bearbetar det som det beh\u00f6vs utan bryggor, utan TCP, utan IP-stack \u2013 kort sagt, kringg\u00e5r allt som \u00e4r skrivet i Linux-k\u00e4rnan, och spottar ut det i containern.<\/p>\n

Vad blev resultatet? Riktigt bra prestanda, fantastiska funktioner \u2013 helt enkelt fantastiskt! Men vi ser att det p\u00e5 varje maskin finns ett program som kopplar upp sig mot Kubernetes API och, baserat p\u00e5 de data som det f\u00e5r fr\u00e5n detta API, genererar C-kod och kompilera bin\u00e4rfiler som laddas in i k\u00e4rnan, s\u00e5 att dessa hooks fungerar i kernel space.<\/p>\n

Vad h\u00e4nder om n\u00e5got g\u00e5r fel? Vi vet inte. F\u00f6r att f\u00f6rst\u00e5 detta beh\u00f6ver man l\u00e4sa hela den koden, f\u00f6rst\u00e5 hela logiken, och det \u00e4r otroligt komplicerat. Men \u00e5 andra sidan finns det dessa bryggor, n\u00e4tfilter, ip rout \u2013 jag har inte l\u00e4st deras k\u00e4llkod, och 40 ingenj\u00f6rer som arbetar p\u00e5 v\u00e5rt f\u00f6retag har inte heller gjort det. Kanske f\u00f6rst\u00e5 n\u00e5gra bitar, men det \u00e4r det.<\/p>\n

Och vad spelar det f\u00f6r roll? Det visar sig att det finns IP-rout, Linux-k\u00e4rnan, och det finns ett nytt verktyg \u2013 vad spelar det f\u00f6r roll, vi f\u00f6rst\u00e5r varken det ena eller det andra. Men vi \u00e4r r\u00e4dda f\u00f6r att anv\u00e4nda det nya \u2013 varf\u00f6r? F\u00f6r att om ett verktyg har funnits i 30 \u00e5r, s\u00e5 har alla buggar hittats, alla fallgropar har trampats p\u00e5 och man beh\u00f6ver inte veta allt \u2013 det fungerar som en svart l\u00e5da och fungerar alltid. Alla vet vilken diagnostikskruvmejsel som ska s\u00e4ttas i vilket st\u00e4lle, vilken tcpdump som ska k\u00f6ras vid vilken tidpunkt. Alla k\u00e4nner v\u00e4l till diagnostiska verktyg och f\u00f6rst\u00e5r hur detta komponentset fungerar i Linux-k\u00e4rnan \u2013 inte hur det \u00e4r uppbyggt, utan hur man anv\u00e4nder det.<\/p>\n

Och det fantastiska Cilium \u00e4r inte 30 \u00e5r gammalt, det \u00e4r fortfarande outvecklat. Med Kubernetes \u00e4r det samma problem, det \u00e4r en kopia. B\u00e5de Cilium och Kubernetes installeras utm\u00e4rkt, men n\u00e4r n\u00e5got g\u00e5r snett i produktion, hur snabbt kan ni f\u00f6rst\u00e5 vad som har g\u00e5tt fel i en kritisk situation? <\/p>\n

N\u00e4r vi pratar om hur sv\u00e5rt det \u00e4r att underh\u00e5lla Kubernetes \u2013 nej, det \u00e4r v\u00e4ldigt enkelt, och ja, det \u00e4r otroligt sv\u00e5rt. Kubernetes fungerar utm\u00e4rkt i sig sj\u00e4lv, men med miljarder nyanser.<\/p><\/blockquote>\n

<\/p>\n

Om tillv\u00e4gag\u00e5ngss\u00e4ttet \"Jag har tur\"<\/h2>\n

\n\u2013 Finns det f\u00f6retag d\u00e4r dessa nyanser n\u00e4stan garanterat kommer att dyka upp? Antag att Yandex pl\u00f6tsligt \u00f6verf\u00f6r alla sina tj\u00e4nster till Kubernetes, d\u00e4r kommer det att bli en enorm belastning.<\/b><\/p>\n

Dmitrij<\/b>: Nej, det handlar inte om belastning, utan om de mest grundl\u00e4ggande sakerna. Till exempel, vi har Kubernetes, vi har deployat en applikation d\u00e4r. Hur kan vi f\u00f6rst\u00e5 att den fungerar? Det finns inget f\u00e4rdigt verktyg f\u00f6r att f\u00f6rst\u00e5 att applikationen inte kraschar, helt enkelt. Det finns inget f\u00e4rdigt system som skickar larm \u2013 nej, vi m\u00e5ste konfigurera dessa larm och varje graf. Och vi h\u00e5ller p\u00e5 att uppdatera Kubernetes.<\/p>\n

Det finns Ubuntu 16.04. Man kan s\u00e4ga att det h\u00e4r \u00e4r en gammal version, men vi anv\u00e4nder den fortfarande eftersom den \u00e4r LTS. Den har systemd, och en detalj \u00e4r att den inte st\u00e4dar C-grupper. Kubernetes startar pods, skapar C-grupper, och sen tar den bort pods, och p\u00e5 n\u00e5got s\u00e4tt s\u00e5 blir det kvar n\u00e5got som jag inte minns detaljerna om, f\u00f6rl\u00e5t, som \u00e4r systemd-slices. Detta leder till att vilken maskin som helst b\u00f6rjar lagga kraftigt \u00f6ver tid. Det handlar inte ens om highload. Om l\u00e4mnas kontinuerliga pods k\u00f6rande, till exempel om det finns en Cron Job som st\u00e4ndigt genererar pods, s\u00e5 b\u00f6rjar en maskin med Ubuntu 16.04 lagga efter en vecka. Det kommer alltid att vara en h\u00f6g load average eftersom det har skapats en massa C-grupper. Detta \u00e4r ett problem som alla som bara installerar Ubuntu 16 och Kubernetes st\u00f6ter p\u00e5.<\/p>\n

L\u00e5t oss s\u00e4ga att han p\u00e5 n\u00e5got s\u00e4tt uppdaterar systemd eller n\u00e5got annat, men i Linux-k\u00e4rnan fram till 4.16 \u00e4r det \u00e4nnu roligare - n\u00e4r C-grupper tas bort s\u00e5 droppas de i k\u00e4rnan och tas faktiskt aldrig bort. D\u00e4rf\u00f6r \u00e4r det efter en m\u00e5nads arbete p\u00e5 den h\u00e4r maskinen om\u00f6jligt att se minnesstatistik f\u00f6r pods. Vi tar fram en fil, k\u00f6r den i programmet, och en fil tar 15 sekunder att bearbeta eftersom k\u00e4rnan tar v\u00e4ldigt l\u00e5ng tid p\u00e5 sig att ber\u00e4kna inuti sig sj\u00e4lv med en miljon C-grupper som verkar vara borttagna, men de droppar fortfarande.<\/p>\n

Det finns fortfarande m\u00e5nga s\u00e5dana detaljer h\u00e4r och d\u00e4r. Det \u00e4r inte en fr\u00e5ga som j\u00e4ttef\u00f6retag ibland kan st\u00f6ta p\u00e5 vid v\u00e4ldigt h\u00f6ga belastningar - nej, det \u00e4r en fr\u00e5ga om dagliga saker. M\u00e4nniskor kan leva med det i m\u00e5nader - de installerade Kubernetes, distribuerade applikationen - det verkar fungera. M\u00e5nga m\u00e5r bra av det. De kommer inte ens att f\u00e5 veta att applikationen n\u00e5gon g\u00e5ng kommer att krascha, alerten kommer inte att komma, men f\u00f6r dem \u00e4r det normalt. Tidigare levde de p\u00e5 virtuella maskiner utan \u00f6vervakning, nu har de flyttat till Kubernetes ocks\u00e5 utan \u00f6vervakning - vad spelar det f\u00f6r roll?<\/p>\n

Fr\u00e5gan \u00e4r att n\u00e4r vi g\u00e5r p\u00e5 is, vet vi aldrig tjockleken om vi inte har m\u00e4tt den i f\u00f6rv\u00e4g. M\u00e5nga g\u00e5r omkring och bryr sig inte, f\u00f6r de har g\u00e5tt tidigare.<\/p>\n

Fr\u00e5n min synvinkel \u00e4r detaljen och sv\u00e5righeten med att underh\u00e5lla vilket system som helst att garantera att tjockleken p\u00e5 isen \u00e4r tillr\u00e4cklig f\u00f6r att hantera v\u00e5ra uppgifter. Det handlar om detta.<\/p><\/blockquote>\n

\nIn 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\u2019s why this works.<\/p>\n

\u2014 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.<\/b><\/p>\n

Dmitrij<\/b>: Objectively, this is true. For a small team, diving into Kubernetes independently involves a certain level of risk.<\/p>\n

Do we need containers?<\/h2>\n

\n\u2014 Can you tell me how widespread Kubernetes is in Russia?<\/b><\/p>\n

Dmitrij<\/b>: I don\u2019t have that data, and I\u2019m not sure if anyone really does. We talk about \u201cKubernetes, Kubernetes,\u201d but there\u2019s another perspective on this issue. I also don\u2019t 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.<\/p>\n

Next question \u2014 do we need containers?<\/b> I have a personal feeling and in general, the position of Flant is that Kubernetes is the de facto standard.<\/p>\n

Nothing but Kubernetes will be left.<\/p><\/blockquote>\n

\nThis is an absolute game changer in the field of infrastructure management. Absolutely \u2014 no more Ansible, Chef, virtual machines, or Terraform. I won\u2019t even mention the old methods. Kubernetes is an absolute changer<\/b>, and it will only be like this from now on.<\/p>\n

It\u2019s 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<\/b>, except not with code, but with YAML \u2014 a declaratively described infrastructure. I feel that this will always be the case.<\/p>\n

\u2014 So the companies that have not yet transitioned to Kubernetes will either definitely transition or fade into obscurity. Did I understand you correctly?<\/b><\/p>\n

Dmitrij<\/b>: Det \u00e4r inte helt korrekt. Om vi till exempel har uppgiften att starta en DNS-server, kan den k\u00f6ras p\u00e5 FreeBSD 4.10 och fungera utm\u00e4rkt i 20 \u00e5r. Den bara fungerar, och that's it. Kanske beh\u00f6ver vi uppdatera n\u00e5got en g\u00e5ng p\u00e5 20 \u00e5r. Om vi pratar om programvara som vi har startat och som faktiskt fungerar i m\u00e5nga \u00e5r utan uppdateringar eller f\u00f6r\u00e4ndringar, d\u00e5 beh\u00f6ver vi definitivt inte Kubernetes. Det \u00e4r on\u00f6digt d\u00e4r.<\/p>\n

Allt som r\u00f6r CI\/CD \u2014 d\u00e4r Continuous Delivery beh\u00f6vs, d\u00e4r versioner m\u00e5ste uppdateras, d\u00e4r aktiva f\u00f6r\u00e4ndringar kr\u00e4vs, d\u00e4r redundans m\u00e5ste byggas \u2014 \u00e4r endast Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Om mikrotj\u00e4nster<\/h2>\n

\n\u2014 H\u00e4r uppst\u00e5r en viss dissonans f\u00f6r mig. F\u00f6r att arbeta med Kubernetes beh\u00f6ver man extern eller intern support \u2014 det \u00e4r den f\u00f6rsta punkten. Den andra \u00e4r \u2014 n\u00e4r vi precis b\u00f6rjar med utvecklingen, vi \u00e4r en liten startup, vi har \u00e4nnu inget, utveckling f\u00f6r Kubernetes eller ens f\u00f6r mikrotj\u00e4nstarkitektur kan vara komplicerat och \u00e4r inte alltid ekonomiskt motiverad. Jag \u00e4r nyfiken p\u00e5 din \u00e5sikt \u2014 beh\u00f6ver startups direkt b\u00f6rja koda f\u00f6r Kubernetes, eller kan de \u00e4nd\u00e5 skriva en monolit och sedan g\u00e5 \u00f6ver till Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: Bra fr\u00e5ga. Jag har en presentation om mikrotj\u00e4nster. \u201cMikrotj\u00e4nster: Storleken spelar roll\u201d.<\/a><\/noindex> Jag har m\u00e5nga g\u00e5nger st\u00f6tt p\u00e5 att folk f\u00f6rs\u00f6ker sl\u00e5 i spikar med ett mikroskop. Sj\u00e4lva tillv\u00e4gag\u00e5ngss\u00e4ttet \u00e4r korrekt, vi designar \u00e4ven v\u00e5r interna programvara p\u00e5 detta s\u00e4tt. Men n\u00e4r man g\u00f6r det \u00e4r det viktigt att tydligt f\u00f6rst\u00e5 vad man g\u00f6r. Det jag hatar mest med mikrotj\u00e4nster \u00e4r ordet \"mikro\". Det har historiskt uppst\u00e5tt, och av n\u00e5gon anledning tror folk att mikro betyder v\u00e4ldigt liten, mindre \u00e4n en millimeter, som en mikrometer. S\u00e5 \u00e4r det inte.<\/p>\n

Till exempel finns det en monolit som skrivs av 300 personer, och alla som deltager i utvecklingen f\u00f6rst\u00e5r att det finns problem, och den m\u00e5ste brytas ner i mikro-bitar \u2014 cirka 10 stycken, varav varje skrivs av 30 personer i minimi-alternativet. Det \u00e4r viktigt, n\u00f6dv\u00e4ndigt och fantastiskt. Men n\u00e4r startups kommer till oss d\u00e4r 3 riktigt duktiga och talangfulla killar har skrivit 60 mikrotj\u00e4nster p\u00e5 kn\u00e4, d\u00e5 b\u00f6rjar jag alltid leta efter Corvalol.<\/p>\n

Jag tror att detta har diskuterats tusentals g\u00e5nger \u2013 vi har f\u00e5tt en distribuerad monolit i n\u00e5gon form. Detta \u00e4r ekonomiskt oh\u00e5llbart, mycket komplicerat \u00f6verlag. Jag har sett detta s\u00e5 m\u00e5nga g\u00e5nger att det faktiskt g\u00f6r ont, och d\u00e4rf\u00f6r forts\u00e4tter jag att prata om det.<\/p>\n

Till den inledande fr\u00e5gan, att det finns en konflikt mellan att Kubernetes \u00e4r skr\u00e4mmande att anv\u00e4nda, eftersom det \u00e4r oklart vad som kan g\u00e5 s\u00f6nder eller inte fungera, och \u00e5 andra sidan, att det \u00e4r uppenbart att allt g\u00e5r dit och ingenting annat \u00e4n Kubernetes kommer att \u00e5terst\u00e5. Svaret \u00e4r - att v\u00e4ga nyttan som kommer, volymen av uppgifter som ni kan l\u00f6sa<\/b>. Detta \u00e4r p\u00e5 en sida av v\u00e5gsk\u00e5len. \u00c5 andra sidan finns riskerna som \u00e4r kopplade till stillest\u00e5nd eller l\u00e5g svarstid, niv\u00e5 av tillg\u00e4nglighet - med s\u00e4nkta prestanda.<\/p>\n

S\u00e5 h\u00e4r ligger det till - antingen m\u00e5ste vi agera snabbt, och Kubernetes m\u00f6jligg\u00f6r att g\u00f6ra m\u00e5nga saker mycket snabbare och b\u00e4ttre, eller anv\u00e4nda p\u00e5litliga, bepr\u00f6vade l\u00f6sningar, men agera mycket l\u00e5ngsammare. Detta val m\u00e5ste varje f\u00f6retag g\u00f6ra. Man kan se detta som en stig i djungeln - f\u00f6rsta g\u00e5ngen man g\u00e5r, kan man m\u00f6ta en orm, en tiger eller en galen gr\u00e4vling, och efter att ha g\u00e5tt tio g\u00e5nger - skapa en stig, rensa bort grenar, och det blir l\u00e4ttare att g\u00e5. F\u00f6r varje g\u00e5ng blir stigen bredare. Sen blir det en asfalterad v\u00e4g, och senare en vacker boulevard.<\/p>\n

Kubernetes st\u00e5r inte still. \u00c5terigen en fr\u00e5ga: p\u00e5 ena sidan \u00e4r Kubernetes 4-5 bin\u00e4rer, p\u00e5 andra sidan \u00e4r det hela ekosystemet. Det \u00e4r operativsystemet som vi har p\u00e5 v\u00e5ra maskiner. Vad \u00e4r det? Ubuntu eller Curios? Det \u00e4r Linux-k\u00e4rnan, massa ytterligare komponenter. Alla dessa saker h\u00e4r har kastat ut en giftig orm fr\u00e5n stigen, d\u00e4r har man satt upp staket. Kubernetes utvecklas mycket snabbt och dynamiskt, och volymen av risker, volymen av det outforskade minskar varje m\u00e5nad, och d\u00e4rmed ombalanseras dessa v\u00e5gar.<\/p>\n

N\u00e4r man svarar p\u00e5 fr\u00e5gan om vad ett startup ska g\u00f6ra, skulle jag s\u00e4ga - kom till \"Flant\", betala 150 000 rubel och f\u00e5 en nyckelf\u00e4rdig DevOps easy service. Om du \u00e4r ett litet startup med n\u00e5gra utvecklare - detta fungerar. Ist\u00e4llet f\u00f6r att anst\u00e4lla din egen DevOps, som m\u00e5ste l\u00e4ra sig att l\u00f6sa dina problem och f\u00e5 l\u00f6n under tiden, f\u00e5r du en nyckelf\u00e4rdig l\u00f6sning f\u00f6r alla fr\u00e5gor. Ja, det finns n\u00e5gra nackdelar. Som outsourcer kan vi inte vara s\u00e5 involverade och snabbt reagera p\u00e5 \u00e4ndringar. Men vi har massor av expertis och f\u00e4rdiga metoder. Vi garanterar att vi i alla situationer kommer att snabbt l\u00f6sa problemen och \u00e5teruppliva vilken Kubernetes som helst. <\/p>\n

Jag rekommenderar kategoriskt outsourcing f\u00f6r startups och etablerade f\u00f6retag tills ni kan avs\u00e4tta ett team p\u00e5 10 personer f\u00f6r drift, f\u00f6r annars \u00e4r det meningsl\u00f6st. Det \u00e4r kategoriskt vettigt att outsourca.<\/p><\/blockquote>\n

<\/p>\n

Om Amazon och Google<\/h2>\n

\n\u2014 Kan man \u00f6verv\u00e4ga att outsourca hosting-l\u00f6sningar fr\u00e5n Amazon eller Google?<\/b><\/p>\n

Dmitrij<\/b>: Ja, absolut, det l\u00f6ser ett antal fr\u00e5gor. Men \u00e5terigen, det finns nyanser. Man m\u00e5ste \u00e4nd\u00e5 f\u00f6rst\u00e5 hur det ska anv\u00e4ndas. Till exempel finns det tusentals sm\u00e5 detaljer i arbetet med Amazon AWS: Load Balancer m\u00e5ste v\u00e4rmas upp eller man m\u00e5ste i f\u00f6rv\u00e4g skicka en beg\u00e4ran om att \"grabbar, vi kommer att f\u00e5 trafik, v\u00e4rm upp v\u00e5r Load Balancer!\" Dessa nyanser m\u00e5ste man k\u00e4nna till.<\/p>\n

N\u00e4r du v\u00e4nder dig till personer som specialiserar sig p\u00e5 detta, f\u00e5r du n\u00e4stan alla standard\u00e4renden l\u00f6sta. Just nu har vi 40 ingenj\u00f6rer, och vid \u00e5rets slut kommer det troligen att vara 60 - vi har definitivt st\u00f6tt p\u00e5 alla dessa fr\u00e5gor. \u00c4ven om vi p\u00e5 n\u00e5got projekt st\u00f6ter p\u00e5 samma problem igen, fr\u00e5gar vi snabbt varandra och vet hur man l\u00f6ser det.<\/p>\n

Sannolikt \u00e4r svaret s\u00e5 h\u00e4r - sj\u00e4lvklart g\u00f6r hosted-l\u00f6sningar en del enklare. Fr\u00e5gan \u00e4r om ni \u00e4r villiga att lita p\u00e5 dessa v\u00e4rdtj\u00e4nster och om de verkligen l\u00f6ser era problem. Amazon och Google har gjort sig k\u00e4nda p\u00e5 ett bra s\u00e4tt. F\u00f6r alla v\u00e5ra fall - definitivt. Vi har inte n\u00e5gra positiva erfarenheter d\u00e4rut\u00f6ver. Alla andra moln som vi f\u00f6rs\u00f6kt arbeta med skapar v\u00e4ldigt m\u00e5nga problem - b\u00e5de 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.<\/p>\n

D\u00e4rf\u00f6r, svaret \u00e4r ja, men i praktiken finns det inte s\u00e5 m\u00e5nga mogna hosted-l\u00f6sningar.<\/p>\n

Vem beh\u00f6ver Kubernetes?<\/h2>\n

\n\u2014 Men vem beh\u00f6ver egentligen Kubernetes? Vem b\u00f6r g\u00e5 \u00f6ver till Kubernetes, vem \u00e4r den typiska kunden hos \"Flant\" som kommer just f\u00f6r Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: Det \u00e4r en intressant fr\u00e5ga, f\u00f6r just nu kommer m\u00e5nga till oss i k\u00f6lvattnet av Kubernetes: \"Grabbar, vi vet att ni g\u00f6r Kubernetes, g\u00f6r det \u00e5t oss!\". Vi svarar: \"Mina damer och herrar, vi g\u00f6r inte Kubernetes, vi g\u00f6r produktion och allt som h\u00f6r till det.\" F\u00f6r att g\u00f6ra produktion utan att ha hela CI\/CD processen och allt det d\u00e4r \u00e4r just nu helt om\u00f6jligt. Alla har \u00f6vergivit uppdelningen mellan utveckling och drift.<\/p>\n

V\u00e5ra kunder f\u00f6rv\u00e4ntar sig olika saker, men alla hoppas p\u00e5 n\u00e5gon slags under som kommer att l\u00f6sa deras problem, att nu \u2014 hux flux! \u2014 Kubernetes ska ta hand om det. M\u00e4nniskor tror p\u00e5 under. De f\u00f6rst\u00e5r rationellt att det inte kommer att ske n\u00e5got mirakel, men de hoppas innerligt \u2014 kanske kommer detta Kubernetes nu att l\u00f6sa allt f\u00f6r oss, det pratas s\u00e5 mycket om det! T\u00e4nk om det nu \u2014 kn\u00e4pp! \u2014 \u00e4r silverkulan som ger oss 100% uptime, och alla utvecklare kan sl\u00e4ppa vad som helst 50 g\u00e5nger i produktion utan att det kraschar. Det \u00e4r i stort sett ett mirakel!<\/p>\n

N\u00e4r s\u00e5dana personer kommer till oss s\u00e4ger vi: \"F\u00f6rl\u00e5t, men mirakel existerar inte\". F\u00f6r att vara frisk beh\u00f6ver man \u00e4ta bra och tr\u00e4na. F\u00f6r att ha en p\u00e5litlig produktion m\u00e5ste man bygga den p\u00e5 ett p\u00e5litligt s\u00e4tt. F\u00f6r att ha en anv\u00e4ndarv\u00e4nlig CI\/CD m\u00e5ste man g\u00f6ra den s\u00e5dan. Det \u00e4r mycket arbete som beh\u00f6ver g\u00f6ras.<\/p>\n

F\u00f6r att svara p\u00e5 fr\u00e5gan om vem som beh\u00f6ver Kubernetes \u2014 ingen beh\u00f6ver Kubernetes.<\/p><\/blockquote>\n

\nVissa m\u00e4nniskor har en felaktig uppfattning om att de beh\u00f6ver Kubernetes. M\u00e4nniskor vill, de har en djupdragen \u00f6nskan att slippa t\u00e4nka p\u00e5, engagera sig i och vara bekymrade \u00f6ver alla infrastrukturproblem och problem med att drifts\u00e4tta sina applikationer. De vill att applikationerna bara ska fungera och enkelt kunna deployeras. F\u00f6r dem \u00e4r Kubernetes ett hopp om att de ska sluta h\u00f6ra historier som \"vi har legat efter\" eller \"vi kan inte deploya\" eller n\u00e5got annat.<\/p>\n

Vanligtvis kommer en teknisk chef till oss. Man st\u00e4ller tv\u00e5 fr\u00e5gor till honom: \u00e5 ena sidan, ge oss funktioner, och \u00e5 andra sidan \u2014 stabilitet. Vi f\u00f6resl\u00e5r att ta detta p\u00e5 oss och g\u00f6ra det. Silverkulan, eller snarare den silverbelagda, \u00e4r att du slutar t\u00e4nka p\u00e5 dessa problem och spara tid. Du kommer att ha specialiserade personer som hanterar dessa fr\u00e5gor.<\/p>\n

Formuleringen att vi eller n\u00e5gon annan beh\u00f6ver Kubernetes \u00e4r felaktig.<\/p><\/blockquote>\n

\nKubernetes \u00e4r mycket viktigt f\u00f6r administrat\u00f6rer, eftersom det \u00e4r en v\u00e4ldigt intressant leksak som man kan experimentera med. L\u00e5t oss vara \u00e4rliga - alla \u00e4lskar leksaker. Vi \u00e4r alla barn p\u00e5 n\u00e5got s\u00e4tt, och n\u00e4r vi ser n\u00e5got nytt vill vi leka med det. Vissa har kanske tr\u00f6ttnat p\u00e5 detta, till exempel inom administration, eftersom de har lekt tillr\u00e4ckligt och nu blivit uttr\u00e5kade p\u00e5 en niv\u00e5 d\u00e4r de helt enkelt inte vill l\u00e4ngre. Men ingen har helt tappat detta. Till exempel, \u00e4ven om jag har tr\u00f6ttnat p\u00e5 leksaker inom systemadministration och DevOps, s\u00e5 \u00e4lskar jag fortfarande leksaker och k\u00f6per fortfarande nya. Alla m\u00e4nniskor vill p\u00e5 ett s\u00e4tt eller annat fortfarande ha sina leksaker.<\/p>\n

Man ska inte leka med produktion. Det som jag kategoriskt inte rekommenderar att g\u00f6ra och som jag ser nu i stor utstr\u00e4ckning \u00e4r: \"\u00c5h, en ny leksak!\" - springer f\u00f6r att k\u00f6pa den, k\u00f6per den och: \"L\u00e5t oss ta med den till skolan och visa alla v\u00e5ra v\u00e4nner.\" G\u00f6r inte s\u00e5. Jag ber om urs\u00e4kt, mina barn v\u00e4xer upp, jag ser st\u00e4ndigt saker hos dem, m\u00e4rker det i mig sj\u00e4lv och generaliserar det sedan till andra.<\/p>\n

Det slutliga svaret: du beh\u00f6ver inte Kubernetes. Du m\u00e5ste l\u00f6sa dina problem.<\/p><\/blockquote>\n

\nDet g\u00e5r att uppn\u00e5 att:<\/p>\n