{"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\/da\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Kubernetes vil erobre verden. Hvorn\u00e5r og hvordan?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I takt med DevOpsConf<\/a><\/noindex> Vitaliy Khabarov<\/b> har interviewet\u00a0Dmitry Stolyarov<\/b> (distol<\/a><\/noindex>), teknisk direkt\u00f8r og medstifter af firmaet \u00abFlant\u00bb. Vitaliy spurgte Dmitry om, hvad \u00abFlant\u00bb arbejder med, om Kubernetes, udvikling af \u00f8kosystemet, st\u00f8tte. De diskuterede, hvorfor Kubernetes er n\u00f8dvendigt, og om det overhovedet er n\u00f8dvendigt. Og ogs\u00e5 om mikrotjenester, Amazon AWS, tilgang til \u00abJeg er heldig\u00bb i DevOps, fremtiden for Kubernetes, hvorfor, hvorn\u00e5r og hvordan det vil overtage verden, perspektiverne for DevOps og hvad ingeni\u00f8rer skal forberede sig p\u00e5 i en lys og n\u00e6r fremtid med forenkling og neurale netv\u00e6rk.<\/p>\n

Originalen af interviewet<\/a><\/noindex> i form af et podcast kan du lytte til p\u00e5 DevOps Deflope \u2014 en russisk podcast om DevOps, og nedenfor er den tekstlige version. <\/p>\n

\"Kubernetes
\n
\nHer stiller Vitaliy Khabarov<\/a><\/noindex> ingeni\u00f8ren fra Express42.
\n<\/a><\/noindex><\/p>\n

Om \u00abFlant\u00bb<\/h2>\n

\n\u2014 Dima, hej. Du er teknisk direkt\u00f8r for \u00abFlant<\/a><\/noindex>\u00bb og ogs\u00e5 dens grundl\u00e6gger. Fort\u00e6l venligst, hvad firmaet laver, og hvad du laver i det?<\/b><\/p>\n

\"KubernetesDmitry<\/b>: Udefra ser det ud til, at vi er s\u00e5dan nogle fyre, der g\u00e5r rundt, s\u00e6tter Kubernetes op og laver noget med det. Men s\u00e5dan er det ikke. Vi startede som et firma, der arbejder med Linux, men allerede for l\u00e6nge siden blev vores hovedaktivitet at servicere produktions- og highload-projekter fra bunden. Normalt bygger vi hele infrastrukturen fra bunden og tager derefter ansvar for den i lang tid. Derfor er det prim\u00e6re arbejde, som \u00abFlant\u00bb udf\u00f8rer, hvad de f\u00e5r penge for \u2014 det er at p\u00e5tage sig ansvar og implementere produktion fra bunden<\/b>.
\n

\n

\nSom teknisk direkt\u00f8r og en af medstifterne af firmaet bruger jeg hele dagen p\u00e5 at finde ud af, hvordan jeg kan \u00f8ge tilg\u00e6ngeligheden af produktionen, forenkle driften, g\u00f8re livet lettere for administratorerne, og g\u00f8re livet mere behageligt for udviklerne.<\/p>\n

Om Kubernetes<\/h2>\n

\n\u2014 P\u00e5 det seneste har jeg set mange foredrag fra \u00abFlant\u00bb og\u00a0artikler<\/a><\/noindex> om Kubernetes. Hvordan kom I til det?<\/b><\/p>\n

Dmitry<\/b>: Jeg har allerede fortalt om dette mange gange, men jeg har slet ikke noget imod at gentage det. Jeg mener, det er korrekt at gentage dette emne, fordi der opst\u00e5r forvirring mellem \u00e5rsag og virkning.<\/p>\n

Vi havde virkelig brug for et v\u00e6rkt\u00f8j. Vi stod over for en masse problemer, k\u00e6mpede, overvandt dem med forskellige hacks og ledte efter et v\u00e6rkt\u00f8j. Vi gennemgik mange forskellige muligheder, byggede vores egne l\u00f8sninger og akkumulerede erfaring. Gradvist n\u00e5ede vi til det punkt, hvor vi begyndte at bruge Docker n\u00e6sten lige efter, det blev lanceret \u2013 omkring 2013. P\u00e5 tidspunktet for dets introduktion havde vi allerede meget erfaring med containere, og vi havde allerede skrevet vores egen version af 'Docker' \u2013 nogle hacks i Python. Med introduktionen af Docker fik vi muligheden for at kaste vores l\u00f8sninger v\u00e6k og bruge en p\u00e5lidelig og f\u00e6llesskabsunderst\u00f8ttet l\u00f8sning.<\/p>\n

Historien med Kubernetes er tilsvarende. P\u00e5 det tidspunkt, hvor det begyndte at tage fart \u2013 for os var det version 1.2 \u2013 havde vi allerede en masse hacks b\u00e5de i Shell og i Chef, som vi fors\u00f8gte at orkestrere Docker med. Vi kiggede seri\u00f8st p\u00e5 Rancher og forskellige andre l\u00f8sninger, men s\u00e5 kom Kubernetes, som er designet pr\u00e6cist som vi ville have gjort det \u2013 eller endda bedre. Der er ingen kritik her.<\/p>\n

Ja, der er nogle ufuldst\u00e6ndigheder her, der er nogle ufuldst\u00e6ndigheder der \u2014 mange ufuldst\u00e6ndigheder, og 1.2 er virkelig skr\u00e6mmende, men... Kubernetes er som en bygning under opf\u00f8relse \u2014 du kigger p\u00e5 projektet og forst\u00e5r, at det bliver rigtig fedt. Hvis bygningen lige nu har fundament og to etager, s\u00e5 forst\u00e5r man, at det er bedre ikke at flytte ind endnu, men med softwaren er der ikke s\u00e5danne problemer \u2014 den kan allerede bruges.<\/p>\n

Vi havde ikke et \u00f8jeblik, hvor vi overvejede, om vi skulle bruge Kubernetes eller ej. Vi ventede p\u00e5 det l\u00e6nge f\u00f8r det blev lanceret og fors\u00f8gte selv at bygge analoger.<\/p><\/blockquote>\n

<\/p>\n

Om Kubernetes<\/h2>\n

\n\u2014 Deltager I direkte i udviklingen af Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Midt imellem. Vi deltager snarere i udviklingen af \u00f8kosystemet. Vi sender et vist antal pull requests: i Prometheus, i forskellige operat\u00f8rer, i Helm \u2013 ind i \u00f8kosystemet. Desv\u00e6rre kan jeg ikke holde styr p\u00e5 alt, hvad vi g\u00f8r, og jeg kan tage fejl, men der er ikke \u00e9n eneste pull request fra os til kernen.<\/p>\n

\u2014 Samtidig udvikler I ogs\u00e5 mange egne v\u00e6rkt\u00f8jer omkring Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Strategien er s\u00e5dan: Vi g\u00e5r og laver pull requests til alt, hvad der allerede findes. Hvis der ikke accepteres pull requests der, s\u00e5 fork'er vi dem bare til os selv og lever, indtil de bliver accepteret med vores builds. Derefter, n\u00e5r det n\u00e5r upstream, vender vi tilbage til den upstream-version.<\/p>\n

For eksempel har vi Prometheus-operatoren, som vi har skiftet frem og tilbage mellem i vores upstream-implementering allerede omkring fem gange, tror jeg. Vi har brug for en funktion, vi har sendt en pull request, vi skal have den implementeret i morgen, og vi \u00f8nsker ikke at vente p\u00e5, at den bliver udgivet i upstream. S\u00e5ledes samler vi vores egen version og ruller vores opbygning med den funktion, vi har brug for, ud til alle vores klynger. S\u00e5 omdanner de det for os i upstream og siger: \"Hey, lad os g\u00f8re det for en mere generel anvendelse\", s\u00e5 f\u00e6rdigg\u00f8r vi det, eller nogen andre, og p\u00e5 et tidspunkt bliver det igen flettet tilbage.<\/p>\n

Alt, hvad der eksisterer, fors\u00f8ger vi at udvikle.<\/b>. Mange elementer, som endnu ikke findes, enten ikke er blevet opfundet, eller som er blevet opfundet, men ikke implementeret \u2013 det skaber vi. Og ikke fordi vi elsker selve processen eller at konstruere cykler som en branche, men simpelthen fordi vi har brug for dette v\u00e6rkt\u00f8j. Ofte bliver sp\u00f8rgsm\u00e5let stillet, hvorfor vi har lavet den eller den funktion? Svaret er enkelt \u2013 fordi vi m\u00e5tte komme videre, l\u00f8se et praktisk problem, som vi har l\u00f8st med dette v\u00e6rkt\u00f8j.<\/p>\n

Vejen er altid s\u00e5dan: vi s\u00f8ger meget grundigt, og hvis vi ikke finder nogen l\u00f8sning p\u00e5, hvordan man laver en trolleybus ud af et br\u00f8d, s\u00e5 laver vi vores egen br\u00f8d og vores egen trolleybus.<\/p><\/blockquote>\n

<\/p>\n

Flanta-v\u00e6rkt\u00f8jer<\/h2>\n

\n\u2014 Jeg er klar over, at Flanta i \u00f8jeblikket har addon-operat\u00f8rer, shell-operat\u00f8rer, dapp\/werf v\u00e6rkt\u00f8jer. Som jeg forst\u00e5r det, er dette det samme v\u00e6rkt\u00f8j i forskellige inkarnationer. Jeg forst\u00e5r ogs\u00e5, at der inden for Flanta er mange forskellige v\u00e6rkt\u00f8jer. Er det korrekt?<\/b><\/p>\n

Dmitry<\/b>: Vi har meget mere p\u00e5 GitHub. Af det jeg kan huske nu, har vi statusmap \u2013 et panel til Grafana, som alle kan lide. Det n\u00e6vnes n\u00e6sten i hver anden artikel om overv\u00e5gning af Kubernetes p\u00e5 Medium. Det er umuligt at forklare kort, hvad statusmap er \u2013 det kr\u00e6ver en separat artikel, men det er et meget nyttigt v\u00e6rkt\u00f8j til overv\u00e5gning af status over tid, da vi ofte har brug for at vise status over tid i Kubernetes. Vi har ogs\u00e5 LogHouse \u2013 det er en l\u00f8sning baseret p\u00e5 ClickHouse og lidt magi til indsamling af logs i Kubernetes.<\/p>\n

Mange nyttige v\u00e6rkt\u00f8jer! Og der vil komme endnu flere, da en r\u00e6kke interne l\u00f8sninger vil blive udgivet i \u00e5r. Blandt de store p\u00e5 addon-operationsniveauet er der en masse addons til Kubernetes, s\u00e5som hvordan man korrekt installerer sert manager \u2013 et v\u00e6rkt\u00f8j til h\u00e5ndtering af certifikater, hvordan man s\u00e6tter Prometheus op med en masse tilknyttede v\u00e6rkt\u00f8jer \u2013 der er omkring tyve forskellige bin\u00e6re filer, der eksporterer data og samler information; til dette er der en fantastisk grafik og alarmer i Prometheus. Alt dette er blot en m\u00e6ngde addons til Kubernetes, der installeres i klyngen, og som forvandler den fra simpel til en avanceret, automatiseret l\u00f8sning, hvor mange problemer allerede er blevet l\u00f8st. Ja, vi laver meget.<\/p>\n

Udviklingen af \u00f8kosystemet<\/h2>\n

\n\u2014 Jeg mener, at dette er et stort bidrag til udviklingen af dette v\u00e6rkt\u00f8j og dets anvendelsesmetoder. Kan du ansl\u00e5, hvem der ellers ville kunne bidrage p\u00e5 samme m\u00e5de til udviklingen af \u00f8kosystemet?<\/b><\/p>\n

Dmitry<\/b>: Ingeni\u00f8rerne i Rusland, blandt de virksomheder, der opererer p\u00e5 vores marked \u2013 ingen er i n\u00e6rheden.<\/b>. Selvf\u00f8lgelig er dette en dristig p\u00e5stand, fordi der er store spillere som Mail og Yandex \u2013 de laver ogs\u00e5 noget med Kubernetes, men selv de er ikke i n\u00e6rheden af det bidrag, som virksomheder g\u00f8r globalt, der laver meget mere end os. Det er sv\u00e6rt at sammenligne \u00abFlant\u00bb med en stab p\u00e5 80 personer og Red Hat, hvor der kun til \u00e9n Kubernetes er 300 ingeni\u00f8rer, hvis jeg ikke tager fejl. Det er sv\u00e6rt at sammenligne. I vores RnD-afdeling er der 6 personer, inklusive mig, der arbejder p\u00e5 alle vores v\u00e6rkt\u00f8jer. 6 personer mod 300 ingeni\u00f8rer i Red Hat \u2013 det er lidt sv\u00e6rt at sammenligne.<\/p>\n

\u2014 Ikke desto mindre, n\u00e5r selv disse 6 personer kan skabe noget virkelig nyttigt og delbart, n\u00e5r de st\u00e5r over for en praktisk opgave og giver l\u00f8sningen til f\u00e6llesskabet \u2013 det er en interessant sag. Jeg forst\u00e5r, at i store teknologiselskaber, hvor der er egen udvikling og et team, der st\u00f8tter Kubernetes, kan der i princippet ogs\u00e5 udvikles tilsvarende v\u00e6rkt\u00f8jer. Dette er et eksempel for dem p\u00e5, at det er muligt at udvikle og give det videre til f\u00e6llesskabet og give et skub til hele f\u00e6llesskabet, der bruger Kubernetes.<\/b><\/p>\n

Dmitry<\/b>: Det er sikkert en integratorfunktion, en s\u00e6rlig egenskab ved ham. Vi har mange projekter, og vi ser mange forskellige situationer. Den prim\u00e6re m\u00e5de, vi skaber merv\u00e6rdi p\u00e5, er ved at analysere disse cases, finde f\u00e6lles tr\u00e6k og maksimalt reducere omkostningerne for os. Det arbejder vi aktivt med. Det er sv\u00e6rt for mig at sige noget om Rusland og verden, men vi har cirka 40 DevOps-ingeni\u00f8rer i firmaet, der arbejder med Kubernetes. Jeg tror ikke, der er mange virksomheder i Rusland med et sammenligneligt antal specialister, der kender til Kubernetes, hvis de overhovedet findes.<\/p>\n

Jeg forst\u00e5r alt om titlen DevOps-ingeni\u00f8r, alle forst\u00e5r det, og det er blevet en vane at kalde DevOps-ingeni\u00f8rer for DevOps-ingeni\u00f8rer, s\u00e5 det beh\u00f8ver vi ikke at diskutere. Alle de 40 fantastiske DevOps-ingeni\u00f8rer st\u00e5r hver dag over for problemer og l\u00f8ser dem. Vi analyserer blot denne erfaring og pr\u00f8ver at generalisere den. Vi ved, at hvis vi holder denne viden indad, vil v\u00e6rkt\u00f8jet v\u00e6re v\u00e6rdil\u00f8st om et \u00e5r eller to, fordi et f\u00e6rdigt v\u00e6rkt\u00f8j vil dukke op et eller andet sted i communityen. Der er ikke nogen mening i at akkumulere denne erfaring internt \u2013 det er kun spild af kr\u00e6fter og tid i dev\/null. Men s\u00e5 er vi slet ikke kede af at dele. Vi publicerer med stor gl\u00e6de alt dette og forst\u00e5r, at det skal publiceres, udvikles, promoveres, s\u00e5 folk kan bruge det og tilf\u00f8je deres erfaring \u2013 s\u00e5 vokser og lever alt. S\u00e5 om to \u00e5r ender v\u00e6rkt\u00f8jet ikke i skraldespanden. Det er ikke kedeligt at forts\u00e6tte med at investere kr\u00e6fter, fordi det er tydeligt, at nogen bruger dit v\u00e6rkt\u00f8j, og om to \u00e5r bruger alle det.<\/p>\n

Dette er en del af vores store strategi med dapp\/werf<\/b>. Jeg kan ikke huske, hvorn\u00e5r vi begyndte at udvikle det, men det virker som om, det var for tre \u00e5r siden. Oprindeligt var det helt p\u00e5 shell. Det var en super proof of concept, vi l\u00f8ste nogle af vores specifikke opgaver \u2013 det lykkedes! Men der er problemer med shell, det er umuligt at skalere det op, at programmere p\u00e5 shell er en sv\u00e6r opgave. Vi havde en vane med at skrive i Ruby, s\u00e5 vi \u00e6ndrede og udviklede noget i Ruby, men s\u00e5 st\u00f8dte vi ind i, at communityen, den gruppe, der ikke siger \u201cvi \u00f8nsker eller ikke \u00f8nsker\u201d, vender n\u00e6sen v\u00e6k fra Ruby, som det er m\u00e6rkeligt. Vi inds\u00e5, at vi skulle skrive alt dette i Go for simpelthen at opfylde det f\u00f8rste punkt p\u00e5 tjeklisten: DevOps-v\u00e6rkt\u00f8jet skal v\u00e6re en statisk bin\u00e6rfil<\/b>. Uanset om det er Go eller ej, er det ikke s\u00e5 vigtigt, men det er bedre med en statisk bin\u00e6rfil skrevet i Go.<\/p>\n

Vi har brugt kr\u00e6fter p\u00e5 at omskrive dapp'en til Go og kaldt den werf. Dapp'en er ikke l\u00e6ngere vedligeholdt, den udvikles ikke, den fungerer i en eller anden sidste version, men der er en absolut opgraderingsvej opad, som kan f\u00f8lges.<\/p>\n

Hvorfor blev dapp'en oprettet<\/h2>\n

\n\u2014 Kan du kort fort\u00e6lle, hvorfor dapp'en blev oprettet, hvilke problemer den l\u00f8ser?<\/b><\/p>\n

Dmitry<\/b>: Den f\u00f8rste grund er bygning. Oprindeligt havde vi store problemer med bygning, da Docker ikke kunne multi-stage, og vi lavede multi-stage selv. S\u00e5 havde vi en masse andre sp\u00f8rgsm\u00e5l om oprydning af billeder. Alle, der laver CI\/CD, st\u00f8der f\u00f8r eller senere p\u00e5 problemet med en masse opbyggede billeder, der kr\u00e6ver oprydning af det, der ikke er n\u00f8dvendigt, og at bevare det, der er n\u00f8dvendigt.<\/p>\n

Den anden grund er deployment. Ja, der er Helm, men det l\u00f8ser kun en del af problemerne. Uden at skulle joke, st\u00e5r der, at \"Helm er Package Manager for Kubernetes\". Pr\u00e6cis, \"the\". Der er ogs\u00e5 ordene \"Package Manager\" - hvad forventes der typisk af en Package Manager? Vi siger: \"Package Manager - installer pakken!\" og forventer, at den siger: \"Pakken er installeret.\" <\/p>\n

Det er interessant, at vi siger: \"Helm, installer pakken\", men n\u00e5r den svarer, at den har installeret, viser det sig, at den kun har startet installationen - den sagde til Kubernetes: \"Start denne ting!\", og om den er startet eller fungerer, l\u00f8ser Helm slet ikke det sp\u00f8rgsm\u00e5l.<\/p>\n

Det viser sig, at Helm blot er en tekstbehandler, der indl\u00e6ser data i Kubernetes.<\/p><\/blockquote>\n

\nMen inden for enhver deployment \u00f8nsker vi at vide - er applikationen rullet ud til produktion eller ej? At v\u00e6re rullet ud til produktion betyder, at applikationen er sendt derud, den nye version er udrullet, og den faller ikke og svarer korrekt. Helm l\u00f8ser slet ikke denne opgave. For at l\u00f8se den skal der bruges meget kraft, for det kr\u00e6ver, at du giver Kubernetes en kommando om at rulle ud og overv\u00e5ge, hvad der sker - om det er blevet udrullet, om det er rullet ud. Der er ogs\u00e5 mange opgaver relateret til deployment, oprydning, bygning.<\/p>\n

Planer<\/h2>\n

\nAllerede i \u00e5r vil vi g\u00e5 over til lokal udvikling. Vi \u00f8nsker at n\u00e5 det niveau, som tidligere blev gjort i Vagrant \u2014 vi skriver \"vagrant up\", og vores virtuelle maskiner bliver oprettet. Vi vil til det punkt, hvor der er et projekt i Git, og vi skriver \"werf up\", som starter en lokal kopi af dette projekt, der k\u00f8rer i et lokalt mini-Kub, med alle mapper tilsluttet, s\u00e5 det er nemt at udvikle. Afh\u00e6ngig af programmeringssproget udf\u00f8res dette p\u00e5 forskellige m\u00e5der, men vi \u00f8nsker, at det skal v\u00e6re nemt at drive lokal udvikling med monterede filer.<\/p>\n

N\u00e6ste skridt for os er at investere kraftigt i udviklerens bekvemmelighed.<\/b>. For hurtigt at kunne starte et projekt lokalt med \u00e9t v\u00e6rkt\u00f8j, udvikle, pushe til Git, og det skal derefter ogs\u00e5 kunne deployes til staging eller tests afh\u00e6ngigt af pipelines, og s\u00e5 til produktion med det samme v\u00e6rkt\u00f8j. Dette sammenh\u00e6ng, ensartethed, reproducerbarhed af infrastrukturen fra lokal milj\u00f8 til produktion er meget vigtig for os. Men det findes endnu ikke i werf \u2014 vi planl\u00e6gger stadig at g\u00f8re det.<\/p>\n

Men vejen til dapp\/werf har altid v\u00e6ret den samme som med Kubernetes i begyndelsen. Vi st\u00f8dte p\u00e5 problemer, l\u00f8ste dem med omveje \u2014 fandt p\u00e5 nogle l\u00f8sninger i shell eller hvad som helst. Derefter fors\u00f8gte vi at g\u00f8re disse omveje mere lige, generalisere og konsolidere dem i bin\u00e6re filer, som vi blot deler.<\/p>\n

Der er ogs\u00e5 et andet syn p\u00e5 hele denne historie, med analogier. <\/p>\n

Kubernetes er som en bilramme med motor. Der er ingen d\u00f8re, vinduer, radio, luftfrisker \u2014 slet ikke noget. Kun rammen og motoren. Og der er Helm \u2014 det er rettet. Det er dejligt at have et rat, men vi har ogs\u00e5 brug for styrestift, styret\u00f8j, gearkasse og hjul; ellers fungerer det ikke.<\/p><\/blockquote>\n

\nI tilf\u00e6ldet med werf er det endnu en komponent til Kubernetes. Men lige nu har vi i alfa-versionen af werf for eksempel, at Helm er kompileret inden i werf, fordi vi blev tr\u00e6tte af at g\u00f8re det selv. Der er mange grunde til at g\u00f8re det s\u00e5dan, jeg vil grundigt forklare, hvorfor vi har kompilere helm helt sammen med tiller ind i werf p\u00e5 foredraget ved RIT++.<\/a><\/noindex>.<\/p>\n

Nu er werf et mere integreret komponent. Vi f\u00e5r et f\u00e6rdigt styr, styrstang - jeg er ikke s\u00e6rlig god til biler, men det er en stor blok, der l\u00f8ser et ret stort spektrum af opgaver. Vi beh\u00f8ver ikke selv at lede i kataloget, finde en del til en anden, og t\u00e6nke over, hvordan de skal skrues sammen. Vi f\u00e5r en f\u00e6rdig kombination, der straks l\u00f8ser mange opgaver. Men indeni er den lavet af de samme open source-komponenter, bruger stadig Docker til bygning, Helm til dele af funktionaliteten, og der er ogs\u00e5 et par andre biblioteker. Det er et integreret v\u00e6rkt\u00f8j til hurtigt og nemt at f\u00e5 en fantastisk CI\/CD ud af boksen.<\/p>\n

Er det sv\u00e6rt at vedligeholde Kubernetes?<\/h2>\n

\n\u2014 Du taler om erfaringen med at begynde at bruge Kubernetes, det fungerer som ramme, motor, og at du kan tilf\u00f8je meget forskelligt: karrosseri, styret\u00f8j, s\u00e6tte pedaler og s\u00e6der p\u00e5. Sp\u00f8rgsm\u00e5let opst\u00e5r - hvor sv\u00e6rt er det for dig at vedligeholde Kubernetes? I har stor erfaring, hvor meget tid og ressourcer bruger I specifikt p\u00e5 at vedligeholde Kubernetes adskilt fra resten?<\/b><\/p>\n

Dmitry<\/b>: Det er et meget komplekst sp\u00f8rgsm\u00e5l, og for at svare p\u00e5 det, skal vi forst\u00e5, hvad vedligeholdelse er, og hvad vi \u00f8nsker fra Kubernetes. M\u00e5ske kan du uddybe?<\/p>\n

\u2014 Efter hvad jeg ved, og som jeg ser det, \u00f8nsker mange teams nu at pr\u00f8ve Kubernetes. Alle hopper ind i det, s\u00e6tter det op p\u00e5 egen h\u00e5nd. Jeg har en fornemmelse af, at folk ikke altid forst\u00e5r kompleksiteten af dette system.<\/b><\/p>\n

Dmitry<\/b>: Det er korrekt.<\/p>\n

\u2014 Hvor sv\u00e6rt er det at tage og installere Kubernetes fra bunden, s\u00e5 det er produktionsklar?<\/b><\/p>\n

Dmitry<\/b>: Hvad tror du, hvor sv\u00e6rt er det at transplantere et hjerte? Jeg forst\u00e5r, det er et kompromitterende sp\u00f8rgsm\u00e5l. At h\u00e5ndtere en skalpel og ikke lave fejl \u2013 det er ikke s\u00e5 sv\u00e6rt. Hvis de fort\u00e6ller dig, hvor du skal sk\u00e6re og hvor du skal sy, s\u00e5 selve proceduren er ikke kompliceret. Det er sv\u00e6rt at garantere, at det lykkes hver gang.<\/p>\n

At installere Kubernetes og f\u00e5 det til at fungere er let: klik! \u2013 det er installeret, der er mange installationsmetoder. Men hvad sker der, n\u00e5r problemer opst\u00e5r?<\/p><\/blockquote>\n

\nDer opst\u00e5r altid sp\u00f8rgsm\u00e5l - hvad har vi ikke taget h\u00f8jde for? Hvad har vi ikke gjort? Hvilke Linux-kernparametre angav vi forkert? Herregud, angav vi dem overhovedet?! Hvilke Kubernetes-komponenter installerede vi, og hvilke gjorde vi ikke? Tusind sp\u00f8rgsm\u00e5l opst\u00e5r, og for at besvare dem kr\u00e6ver det 15-20 \u00e5rs erfaring i denne branche.<\/p>\n

Jeg har et friskt eksempel p\u00e5 dette emne, som kan belyse sp\u00f8rgsm\u00e5let \"Er det sv\u00e6rt at vedligeholde Kubernetes?\" For nogle tid siden overvejede vi seri\u00f8st, om vi skulle fors\u00f8ge at implementere Cilium som netv\u00e6rket i Kubernetes.<\/p>\n

Lad mig forklare, hvad Cilium er. I Kubernetes er der mange forskellige implementeringer af netv\u00e6rkssystemet, og en af dem er virkelig fed - det er Cilium. Hvad g\u00e5r det ud p\u00e5? For nogle tid siden blev der i kernen introduceret muligheden for at skrive hooks til kernen, der p\u00e5 en eller anden m\u00e5de blander sig i netv\u00e6rkssystemet og forskellige andre systemer, og som tillader at omg\u00e5 store dele af kernen.<\/p>\n

I Linux-kernen er der historisk ip rout, netfilter, broere og mange forskellige gamle komponenter, som har eksisteret i 15, 20, 30 \u00e5r. Generelt fungerer de, det er alt godt, men nu har vi fyldt med containere, og det ligner et t\u00e5rn af 15 mursten oven p\u00e5 hinanden, mens du st\u00e5r p\u00e5 det p\u00e5 \u00e9t ben - en underlig f\u00f8lelse. Dette system er historisk udviklet med mange nuancer, ligesom et appendix i kroppen. I nogle situationer er der problemer med performance, for eksempel.<\/p>\n

Der er fremragende BPF og muligheden for at skrive hooks til kernen - folkene har skrevet deres egne hooks til kernen. Pakken kommer ind i Linux-kernen, de tager den lige ved indgangen, behandler den, som de vil uden broer, uden TCP, uden IP-stak - kort sagt, forbi alt, hvad der er skrevet i Linux-kernen, og spytter den lige ud i containeren.<\/p>\n

Hvad har vi opn\u00e5et? Meget flot performance, fantastiske features - simpelthen klasse! Men vi ser p\u00e5 det og ser, at der p\u00e5 hver maskine k\u00f8rer et program, der tilslutter sig Kubernetes API'et, og baseret p\u00e5 de data, det f\u00e5r fra denne API, genererer det C-kode og kompilerer bin\u00e6re filer, som det loader ind i kernen, s\u00e5 disse hooks fungerer i kernelspace.<\/p>\n

Hvad sker der, hvis noget g\u00e5r galt? Vi ved det ikke. For at finde ud af det skal man l\u00e6se hele denne kode, forst\u00e5 hele logikken, og det er virkelig sv\u00e6rt. Men p\u00e5 den anden side er der disse broer, netfiltre, ip rout - jeg har ikke l\u00e6st deres kildekoder, og 40 ingeni\u00f8rer, der arbejder i vores virksomhed, har det heller ikke. M\u00e5ske er der nogle stykker, der forst\u00e5r visse dele.<\/p>\n

Og hvad g\u00f8r det? Det viser sig, at der er en ip-rout, Linux-kernen, og der er et nyt v\u00e6rkt\u00f8j - hvad g\u00f8r det, vi forst\u00e5r hverken den ene eller den anden. Men vi er bange for at bruge det nye - hvorfor? Fordi hvis v\u00e6rkt\u00f8jet har 30 \u00e5r p\u00e5 bagen, s\u00e5 har man fundet alle fejlene, og man er kommet til at st\u00f8de p\u00e5 alle faldgruberne, s\u00e5 man beh\u00f8ver ikke at vide om alt - det fungerer som en sort boks, og det g\u00f8r det altid. Alle ved, hvilken diagnostisk skrue der skal bruges, og hvilket tcpdump der skal k\u00f8res p\u00e5 hvilket tidspunkt. Alle kender godt diagnostiske v\u00e6rkt\u00f8jer og forst\u00e5r, hvordan dette s\u00e6t komponenter fungerer i Linux-kernen - ikke hvordan det er bygget op, men hvordan man bruger det.<\/p>\n

Men den fantastiske Cilium er ikke 30 \u00e5r gammel, den er ikke engang modnet. Der er det samme problem med Kubernetes, det er en kopi. B\u00e5de Cilium og Kubernetes kan installeres uden problemer, men hvis noget g\u00e5r galt i produktionen, vil I s\u00e5 v\u00e6re i stand til hurtigt at forst\u00e5, hvad der gik galt i en kritisk situation? <\/p>\n

N\u00e5r vi taler om, hvor sv\u00e6rt det er at vedligeholde Kubernetes - nej, det er meget enkelt, og ja, det er utroligt sv\u00e6rt. Kubernetes fungerer fint for sig selv, men med milliarder af nuancer.<\/p><\/blockquote>\n

<\/p>\n

Om tilgangen \"Jeg er heldig\"<\/h2>\n

\n\u2014 Er der virksomheder, hvor disse nuancer n\u00e6sten garanteret vil dukke op? Lad os antage, at Yandex pludselig flytter alle deres tjenester til Kubernetes, s\u00e5 vil der v\u00e6re en betydelig belastning.<\/b><\/p>\n

Dmitry<\/b>: Nej, det handler ikke om belastningen, men om de mest simple ting. For eksempel, vi har Kubernetes, og vi har deployet en applikation der. Hvordan forst\u00e5r vi, at den fungerer? Der er simpelthen ikke et klar v\u00e6rkt\u00f8j til at forst\u00e5, at applikationen ikke falder. Der er ikke et f\u00e6rdigt system, der sender alarmer - man skal ops\u00e6tte disse alarmer og hver graf. Og vi opdaterer Kubernetes.<\/p>\n

Der er Ubuntu 16.04. Man kan sige, at det er en gammel version, men vi bruger stadig den, fordi der er LTS. Den har systemd, hvis detalje er, at den ikke renser C-grupperne. Kubernetes starter pods, opretter C-grupper, fjerner derefter pods, og p\u00e5 en eller anden m\u00e5de sker det - jeg kan ikke huske detaljerne, undskyld - at der forbliver systemd-slices. Dette f\u00f8rer til, at enhver maskine over tid begynder at bremse betydeligt. Det handler ikke engang om highload. Hvis der k\u00f8res vedvarende pods, f.eks. hvis der er et Cron Job, der konstant genererer pods, s\u00e5 vil en maskine med Ubuntu 16.04 begynde at bremse efter en uge. Der vil hele tiden v\u00e6re et h\u00f8jt load average p\u00e5 grund af det store antal C-grupper, der er oprettet. Dette er et problem, som enhver person, der bare installerer Ubuntu 16 og derp\u00e5 Kubernetes, st\u00e5r over for.<\/p>\n

Lad os sige, at han p\u00e5 en eller anden m\u00e5de opdaterer systemd eller noget andet, men i Linux-kernen op til 4.16 er det endnu sjovere - n\u00e5r C-grupperne bliver fjernet, l\u00e6kker de i kernen og bliver faktiske ikke slettet. Derfor vil det efter en m\u00e5neds arbejde p\u00e5 denne maskine v\u00e6re umuligt at se statistikkerne om hukommelsen for pods. Vi henter en fil, k\u00f8rer den i programmet, og den ene fil tager 15 sekunder at k\u00f8re, fordi kernen bruger lang tid p\u00e5 at gennemg\u00e5 millioner af C-grupper, som tilsyneladende er fjernet, men nej - de l\u00e6kker.<\/p>\n

Der er stadig mange s\u00e5danne sm\u00e5 detaljer her og der. Det er ikke noget, som gigantiske virksomheder kun nogle gange kan st\u00f8de p\u00e5 under meget store belastninger - nej, det er et sp\u00f8rgsm\u00e5l om daglige ting. Folk kan leve s\u00e5dan i flere m\u00e5neder - installerede Kubernetes, deployede applikationen - det ser ud til at fungere. Mange har det fint med det. De aner ikke, at applikationen p\u00e5 et tidspunkt vil falde ud af en eller anden grund, alarmerne kommer ikke, men for dem er det normalt. Tidligere levede de p\u00e5 virtuelle maskiner uden overv\u00e5gning, nu er de g\u00e5et over til Kubernetes ogs\u00e5 uden overv\u00e5gning - hvad er forskellen?<\/p>\n

Sp\u00f8rgsm\u00e5let er, at n\u00e5r vi g\u00e5r p\u00e5 isen, ved vi aldrig dens tykkelse, medmindre vi har m\u00e5lt den p\u00e5 forh\u00e5nd. Mange g\u00e5r rundt og bekymrer sig ikke, fordi de ogs\u00e5 gik f\u00f8r.<\/p>\n

Fra mit synspunkt er detaljen og kompleksiteten ved at drifte ethvert system i at garantere, at isens tykkelse helt sikkert er tilstr\u00e6kkelig til at l\u00f8se vores opgaver. Det handler om det.<\/p><\/blockquote>\n

\nI IT-branchen synes jeg, der er for mange tilgange til \"Jeg er heldig.\" Mange installerer software og bruger biblioteker i h\u00e5bet om, at de vil have held. Generelt har mange held. M\u00e5ske er det derfor, det fungerer.<\/p>\n

\u2014 I min pessimistiske vurdering ser det s\u00e5ledes ud: N\u00e5r risikoen er h\u00f8j, og applikationen skal fungere, er der brug for st\u00f8tte fra \"Flant\", muligvis fra Red Hat, eller der kr\u00e6ves et internt team, der er dedikeret til Kubernetes og klar til at h\u00e5ndtere det.<\/b><\/p>\n

Dmitry<\/b>: Objektivt set er det s\u00e5dan. At dykke selv ind i Kubernetes-historien for et lille team er en vis m\u00e6ngde risiko.<\/p>\n

Har vi brug for containere?<\/h2>\n

\n\u2014 Kan du fort\u00e6lle, hvor udbredt Kubernetes faktisk er i Rusland?<\/b><\/p>\n

Dmitry<\/b>: Jeg har ikke disse data, og jeg er ikke sikker p\u00e5, om nogen overhovedet har dem. Vi siger: \"Kubernetes, Kubernetes\", men der er ogs\u00e5 et andet synspunkt p\u00e5 dette sp\u00f8rgsm\u00e5l. Hvor udbredte containere er, ved jeg heller ikke, men jeg kender et tal fra rapporter p\u00e5 internettet, der siger, at 70% af containerne orkestreres af Kubernetes. Det var en p\u00e5lidelig kilde baseret p\u00e5 et ganske stort datas\u00e6t globalt.<\/p>\n

Et andet sp\u00f8rgsm\u00e5l er \u2013 har vi brug for containere?<\/b> Min personlige f\u00f8lelse og generelt positionen for virksomheden \"Flant\" er s\u00e5dan, at Kubernetes er de facto-standarden.<\/p>\n

Ingenting andet end Kubernetes vil v\u00e6re der.<\/p><\/blockquote>\n

\nDet er en absolut game-changer inden for infrastrukturadministration. Absolut \u2013 alt, ikke mere Ansible, Chef, virtuelle maskiner, Terraform. Jeg n\u00e6vner endda ikke de gamle landsbymetoder. Kubernetes er en absolut changer<\/b>, og nu vil det kun v\u00e6re s\u00e5dan.<\/p>\n

Det er klart, at nogle har brug for et par \u00e5r, mens andre har brug for et par \u00e5rtier for at indse dette. Jeg har ingen tvivl om, at der ikke vil v\u00e6re noget andet end Kubernetes og denne nye tilgang: vi g\u00e5r ikke l\u00e6ngere ind i operativsystemet, men bruger infrastruktur som kode<\/b>, bare ikke med kode, men med yml \u2013 en deklarativt beskreven infrastruktur. Jeg har en f\u00f8lelse af, at det altid vil v\u00e6re s\u00e5dan.<\/p>\n

\u2014 S\u00e5 de virksomheder, der endnu ikke er g\u00e5et over til Kubernetes, vil uundg\u00e5eligt komme til at g\u00f8re det eller forsvinde i glemsel. Forstod jeg dig korrekt?<\/b><\/p>\n

Dmitry<\/b>: Det er heller ikke helt rigtigt. For eksempel, hvis vi har til opgave at starte en dns-server, kan den startes p\u00e5 FreeBSD 4.10 og kan fungere fint i 20 \u00e5r. Bare fungere og det er det. M\u00e5ske skal der opdateres noget \u00e9n gang i l\u00f8bet af de 20 \u00e5r. Hvis vi taler om software i formatet, hvor vi har startet det og det faktisk fungerer i mange \u00e5r uden opdateringer, uden \u00e6ndringer, s\u00e5 vil der selvf\u00f8lgelig ikke v\u00e6re Kubernetes. Det er ikke n\u00f8dvendigt der.<\/p>\n

Alt der ang\u00e5r CI\/CD - hvor som helst der er brug for Continuous Delivery, hvor versioner skal opdateres, hvor aktive \u00e6ndringer er n\u00f8dvendige, hvor det er n\u00f8dvendigt at opbygge fejltolerance - kun Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Om mikrotjenester<\/h2>\n

\n\u2014 Her har jeg en lille diskrepans. For at arbejde med Kubernetes kr\u00e6ves der ekstern eller intern support - det er det f\u00f8rste punkt. Det andet - n\u00e5r vi lige er begyndt at udvikle, er vi en lille startup, vi har stadig ikke noget, udvikling til Kubernetes eller overhovedet til mikrotjenestearkitektur kan v\u00e6re besv\u00e6rlig, og det er ikke altid \u00f8konomisk forsvarligt. Jeg er interesseret i din mening - skal startups helt fra bunden begynde at skrive til Kubernetes, eller kan de stadig skrive en monolit, og s\u00e5 derefter komme til Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Godt sp\u00f8rgsm\u00e5l. Jeg har en pr\u00e6sentation om mikrotjenester. \u00abMikrotjenester: st\u00f8rrelse betyder noget\u00bb.<\/a><\/noindex> Jeg har mange gange st\u00f8dt p\u00e5, at mennesker pr\u00f8ver at sl\u00e5 s\u00f8m i med en mikroskop. Selve tilgangen er rigtig, vi designer selv vores interne software p\u00e5 denne m\u00e5de. Men n\u00e5r man g\u00f8r det, skal man klart forst\u00e5, hvad man g\u00f8r. Det jeg hader mest ved mikrotjenester er ordet \u00abmikro\u00bb. Historisk set er ordet opst\u00e5et, og af en eller anden grund mener folk, at mikro er meget lille, mindre end en millimeter, som en mikrometer. Det er ikke s\u00e5dan.<\/p>\n

For eksempel er der en monolit, som 300 personer arbejder p\u00e5, og alle der deltager i udviklingen forst\u00e5r, at der er problemer, og den skal deles op i mikro-stykker - omkring 10 stykker, som hver skrives af 30 personer i minimum. Det er vigtigt, n\u00f8dvendigt og fantastisk. Men n\u00e5r en startup kommer til os, hvor 3 helt fantastiske og talentfulde fyre har skrevet 60 mikrotjenester p\u00e5 kn\u00e6et, s\u00f8ger jeg altid efter corvalol.<\/p>\n

Jeg synes, dette er blevet sagt tusind gange f\u00f8r - vi har f\u00e5et en distribueret monolit i en eller anden form. Det er \u00f8konomisk uholdbart og meget sv\u00e6rt generelt. Jeg har set det s\u00e5 mange gange, at det g\u00f8r mig ondt, derfor forts\u00e6tter jeg med at tale om det.<\/p>\n

Til det oprindelige sp\u00f8rgsm\u00e5l, at der er en konflikt mellem, at Kubernetes er skr\u00e6mmende at bruge, fordi det er uklart, hvad der kan g\u00e5 galt eller ikke fungerer, og p\u00e5 den anden side, at det er klart, at alt g\u00e5r den vej, og at der ikke vil v\u00e6re noget andet end Kubernetes. Svaret er - at veje m\u00e6ngden af \u200b\u200bnytte, der kommer, og m\u00e6ngden af \u200b\u200bopgaver, du kan l\u00f8se.<\/b>. Dette er den ene side af v\u00e6gten. P\u00e5 den anden side er der risici, der er forbundet med nedetid eller neds\u00e6ttelse af svartid, tilg\u00e6ngelighedsniveau - neds\u00e6ttelse af pr\u00e6stationsmetrikker.<\/p>\n

Det er s\u00e5dan - enten skal vi bev\u00e6ge os hurtigt, og Kubernetes g\u00f8r mange ting meget hurtigere og bedre, eller bruge p\u00e5lidelige, tidstestede l\u00f8sninger, men bev\u00e6ge os meget langsommere. Dette valg skal hver virksomhed tr\u00e6ffe. Man kan betragte det som en sti i junglen - f\u00f8rste gang man g\u00e5r, kan man m\u00f8de en slange, en tiger eller en sindssyg surikat, men efter du har v\u00e6ret der 10 gange - har du sl\u00e5et en sti, ryddet grene, og det bliver lettere at g\u00e5. Hver gang bliver stien bredere. Senere bliver det en asfalteret vej, og senere en smuk boulevard.<\/p>\n

Kubernetes st\u00e5r ikke stille. Igen sp\u00f8rgsm\u00e5let: Kubernetes, p\u00e5 den ene side, er det 4-5 bin\u00e6re filer, p\u00e5 den anden side er det hele \u00f8kosystemet. Dette er styresystemet, der k\u00f8rer p\u00e5 vores maskiner. Hvad er det? Ubuntu eller Curios? Det er Linux-kernen, en masse ekstra komponenter. Alle disse ting her, en giftig slange er blevet fjernet fra vejen, der er blevet sat et hegn op der. Kubernetes udvikler sig meget hurtigt og dynamisk, og m\u00e6ngden af \u200b\u200brisici, m\u00e6ngden af \u200b\u200bdet ukendte falder hver m\u00e5ned, og dermed ombalanceres disse v\u00e6gte.<\/p>\n

N\u00e5r det kommer til sp\u00f8rgsm\u00e5let om, hvad en startup skal g\u00f8re, ville jeg sige \u2013 kom til \"Flant\", betal 150.000 rubler og f\u00e5 DevOps easy service leveret n\u00f8glef\u00e6rdigt. Hvis du er en lille startup med et par udviklere \u2013 s\u00e5 fungerer det. I stedet for at ans\u00e6tte din egen DevOps, som skal l\u00e6re at l\u00f8se dine problemer og f\u00e5 l\u00f8n i mellemtiden, f\u00e5r du l\u00f8sning p\u00e5 alle sp\u00f8rgsm\u00e5l n\u00f8glef\u00e6rdigt. Ja, der er nogle ulemper. Som en outsourcer kan vi ikke v\u00e6re s\u00e5 involverede og reagere hurtigt p\u00e5 \u00e6ndringer. Men til geng\u00e6ld har vi masser af ekspertise og klare praktiske l\u00f8sninger. Vi garanterer, at vi i enhver situation hurtigt vil finde ud af det og tage fat om enhver Kubernetes fra det d\u00f8de. <\/p>\n

Jeg anbefaler kategorisk outsourcing til startups og etablerede virksomheder, indtil du kan allokere et driftsteam p\u00e5 10 personer, for ellers giver det ikke mening. Det giver kategorisk mening at outsource.<\/p><\/blockquote>\n

<\/p>\n

Om Amazon og Google<\/h2>\n

\n\u2014 Kan outsourcing fra Amazon eller Google betragtes som en l\u00f8sning?<\/b><\/p>\n

Dmitry<\/b>: Ja, selvf\u00f8lgelig l\u00f8ser det et antal sp\u00f8rgsm\u00e5l. Men igen er der nuancer. Man skal stadig forst\u00e5, hvordan man bruger det. For eksempel er der tusind sm\u00e5ting ved arbejdet med Amazon AWS: Load Balanceren skal opvarmes eller man skal p\u00e5 forh\u00e5nd skrive en foresp\u00f8rgsel om, at \"drengene, vi f\u00e5r trafik, opvarm vores Load Balancer!\" Man skal kende til disse nuancer.<\/p>\n

N\u00e5r du henvender dig til folk, der specialiserer sig i dette, f\u00e5r du n\u00e6sten alle standardtingene d\u00e6kket. Vi har nu 40 ingeni\u00f8rer, ved udgangen af \u00e5ret vil der nok v\u00e6re 60 \u2013 vi har helt sikkert st\u00f8dt p\u00e5 alle disse ting. Selv hvis vi igen st\u00f8der p\u00e5 dette problem i et projekt, sp\u00f8rger vi hurtigt hinanden og ved, hvordan vi l\u00f8ser det.<\/p>\n

Svaret er formentlig s\u00e5dan \u2013 selvf\u00f8lgelig letter en hosted-l\u00f8sning en del. Sp\u00f8rgsm\u00e5let er, om du er klar til at stole p\u00e5 disse hostingudbydere, og om de l\u00f8ser dine problemer. Amazon og Google har bevist deres v\u00e6rd. For alle vores sager \u2013 helt sikkert. Vi har ikke haft nogen positive erfaringer andre steder. Alle andre cloud-l\u00f8sninger, vi har pr\u00f8vet at arbejde med, skaber mange problemer \u2013 b\u00e5de Ager og alt, hvad der findes i Rusland, samt forskellige implementeringer af OpenStack: Headster, Overage \u2013 hvad som helst. De skaber alle problemer, som man ikke gider at l\u00f8se.<\/p>\n

Derfor er svaret \u2013 ja, men i praksis er der ikke mange modne hosted-l\u00f8sninger.<\/p>\n

Hvem har brug for Kubernetes?<\/h2>\n

\n\u2014 Og alligevel, hvem har brug for Kubernetes? Hvem skal allerede skifte til Kubernetes, hvem er den typiske kunde hos \"Flant\", som kommer netop for Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Det er et interessant sp\u00f8rgsm\u00e5l, for lige nu, i b\u00f8lgen af Kubernetes, kommer der mange til os: \"Vi ved, at I laver Kubernetes, g\u00f8r det for os!\" Vi svarer: \"Mine damer og herrer, vi laver ikke Kubernetes, vi laver produktion og alt hvad der har med det at g\u00f8re.\" Fordi det er i \u00f8jeblikket umuligt at lave produktion uden at lave hele CI\/CD og hele den historie. Alle er g\u00e5et v\u00e6k fra at adskille udvikling fra drift.<\/p>\n

Vores kunder forventer forskellige ting, men alle venter p\u00e5 et eller andet godt mirakel, der siger, at de har nogle problemer, og nu \u2014 hop! \u2014 Kubernetes vil l\u00f8se dem. Folk tror p\u00e5 mirakler. De forst\u00e5r fornuftigt, at der ikke vil v\u00e6re noget mirakel, men i deres hjerte h\u00e5ber de \u2014 hvad nu hvis dette Kubernetes lige vil l\u00f8se alt for os, der tales s\u00e5 meget om det! Hvad nu hvis det lige \u2014 nip! \u2014 er s\u00f8lvkuglen, nip! \u2014 og vi har 100% oppetid, alle udviklere kan udgive hvad som helst til produktion 50 gange, og det falder ikke. Generelt, et mirakel!<\/p>\n

N\u00e5r s\u00e5danne mennesker kommer til os, siger vi: \"Undskyld, men der findes ikke noget mirakel.\" For at v\u00e6re sund, skal man spise godt og dyrke sport. For at have en p\u00e5lidelig produktion, skal den laves p\u00e5lideligt. For at have en bekvem CI\/CD, skal den laves s\u00e5dan. Det er meget arbejde, der skal g\u00f8res.<\/p>\n

N\u00e5r man svarer p\u00e5 sp\u00f8rgsm\u00e5let om, hvem der har brug for Kubernetes \u2014 Kubernetes er ikke n\u00f8dvendigt for nogen.<\/p><\/blockquote>\n

\nNogle mennesker har den fejlagtige opfattelse, at de har brug for Kubernetes. Folk \u00f8nsker at slippe for at t\u00e6nke p\u00e5, bes\u00e6tte sig med, eller interessere sig for alle problemer med infrastruktur og problemer med at starte deres applikationer. De vil have, at applikationerne bare skal fungere og blive deployeret simpelthen. For dem er Kubernetes h\u00e5bet om, at de ikke l\u00e6ngere vil h\u00f8re historier som \"vi l\u00e5 der\" eller \"kan ikke udgive\", eller noget andet.<\/p>\n

Normalt kommer den tekniske direkt\u00f8r til os. Der bliver spurgt to ting: p\u00e5 den ene side, giv os funktioner, p\u00e5 den anden side \u2014 stabilitet. Vi foresl\u00e5r at tage dette p\u00e5 os og g\u00f8re det. Den s\u00f8lvkugle, eller rettere sagt, den s\u00f8lvbelagte, er, at du vil stoppe med at t\u00e6nke p\u00e5 disse problemer og spilde tid. Du vil have specialiserede folk, der vil tage sig af dette.<\/p>\n

Formuleringen om, at vi eller nogen har brug for Kubernetes, er forkert.<\/p><\/blockquote>\n

\nKubernetes er meget n\u00f8dvendigt for administratorer, fordi det er en meget interessant legeplads, man kan eksperimentere med. Lad os v\u00e6re \u00e6rlige \u2013 alle elsker legesager. Vi er alle b\u00f8rn et eller andet sted, og n\u00e5r vi ser noget nyt, vil vi lege med det. For nogle er det blevet kedeligt i administrationen, fordi de allerede har leget nok. Men ingen har fuldst\u00e6ndig mistet interessen. For eksempel, selvom jeg er blevet tr\u00e6t af leget\u00f8j inden for systemadministration og DevOps, elsker jeg stadig leget\u00f8j og k\u00f8ber stadig noget nyt.<\/p>\n

Man skal ikke lege med produktionen. Hvad jeg kategorisk ikke anbefaler at g\u00f8re, og hvad jeg ser sker massivt: \"\u00c5h, et nyt leget\u00f8j!\" \u2013 s\u00e5 l\u00f8ber man for at k\u00f8be det, man har k\u00f8bt det og: \"Lad os tage det med i skolen og vise det til alle vennerne.\" G\u00f8r ikke s\u00e5dan. Undskyld, men jeg har bare b\u00f8rn, der vokser op, og jeg ser hele tiden noget i dem, bem\u00e6rker det i mig selv, og s\u00e5 generaliserer jeg det til andre.<\/p>\n

Det endelige svar er: du har ikke brug for Kubernetes. Du skal l\u00f8se dine problemer.<\/p><\/blockquote>\n

\nDet, man kan opn\u00e5, er:<\/p>\n