V očakávaní Vitalij Chabarov rozhovor Dmitrij Stolyarov (), technický riaditeľ a spoluzakladateľ spoločnosti Flant. Vitaly sa spýtal Dmitrija na to, čo Flant robí, na Kubernetes, rozvoj ekosystému, podporu. Diskutovali sme o tom, prečo je Kubernetes potrebný a či je vôbec potrebný. A tiež o mikroslužbách, Amazon AWS, prístupe k DevOps „budem mať šťastie“, o budúcnosti samotného Kubernetes, prečo, kedy a ako prevezme svet, o perspektívach DevOps a na čo by sa mali inžinieri pripraviť v svetlá a blízka budúcnosť so zjednodušením a neurónovými sieťami.
počúvať ako podcast na DevOps Deflop - ruskom jazyku podcast o DevOps a nižšie je textová verzia.
Tu a nižšie kladie otázky inžinier z Express42.
O "Flant"
- Ahoj Dima. Ste technický riaditeľ"“ a tiež jeho zakladateľ. Povedzte nám, prosím, čím sa spoločnosť zaoberá a čím ste v nej?
Dmitry: Zvonku sa zdá, že my sme chlapi, ktorí chodia dookola inštalovať Kubernetes pre všetkých a niečo s tým robiť. Ale to nie je pravda. Začínali sme ako firma, ktorá sa zaoberá Linuxom, no už veľmi dlho je našou hlavnou činnosťou servis výroby a veľkoobjemových projektov na kľúč. Obyčajne celú infraštruktúru budujeme od nuly a potom sme za ňu dlho, dlho zodpovední. Preto hlavnou prácou, ktorú „Flant“ robí, za ktorú dostáva peniaze, je prevziať zodpovednosť a realizovať výrobu na kľúč.
Ja ako technický riaditeľ a jeden zo zakladateľov spoločnosti sa celé dni a noci snažím vymyslieť, ako zvýšiť dostupnosť výroby, zjednodušiť jej obsluhu, uľahčiť život administrátorom a spríjemniť život vývojárom. .
O Kubernetes
— V poslednej dobe som videl veľa správ od Flata a o Kubernetes. Ako si na to prišiel?
Dmitry: Už som o tom hovoril veľakrát, ale vôbec mi nevadí, že to zopakujem. Myslím si, že je správne opakovať túto tému, pretože dochádza k zámene medzi príčinou a následkom.
Naozaj sme potrebovali nástroj. Čelili sme mnohým problémom, zápasili, prekonávali ich rôznymi barlami a cítili potrebu nástroja. Prešli sme mnohými rôznymi možnosťami, postavili si vlastné bicykle a získali skúsenosti. Postupne sme sa dostali do bodu, keď sme Docker začali používať takmer hneď, ako sa objavil – okolo roku 2013. V čase jeho objavenia sme už mali veľa skúseností s kontajnermi, už sme napísali analóg „Docker“ - niektoré z našich vlastných barlí v Pythone. S príchodom Dockeru bolo možné zahodiť barličky a použiť spoľahlivé a komunitou podporované riešenie.
S Kubernetesom je príbeh podobný. V čase, keď to začalo naberať na obrátkach – pre nás je to verzia 1.2 – sme už mali na Shell aj Chef veľa barlí, ktoré sme sa nejakým spôsobom snažili zorganizovať s Dockerom. Vážne sme hľadeli na Rancher a rôzne iné riešenia, no potom sa objavil Kubernetes, v ktorom je všetko implementované presne tak, ako by sme to urobili alebo ešte lepšie. Niet sa na čo sťažovať.
Áno, je tu nejaká nedokonalosť, je tam nejaká nedokonalosť - je tam veľa nedokonalostí a 1.2 je vo všeobecnosti hrozná, ale... Kubernetes je ako budova vo výstavbe - pozriete sa na projekt a pochopíte že to bude v pohode. Ak má budova teraz základ a dve poschodia, potom chápete, že je lepšie sa ešte nenasťahovať, ale so softvérom nie sú žiadne také problémy - už ho môžete používať.
Nemali sme ani chvíľu, kedy by sme rozmýšľali nad tým, či Kubernetes použijeme alebo nie. Čakali sme na to dlho predtým, ako sa objavil, a sami sme sa pokúsili vytvoriť analógy.
O Kubernetes
— Podieľate sa priamo na vývoji samotného Kubernetes?
Dmitry: Priemerný. Skôr sa podieľame na rozvoji ekosystému. Posielame určitý počet žiadostí o stiahnutie: spoločnosti Prometheus, rôznym operátorom, spoločnosti Helm - do ekosystému. Bohužiaľ, nie som schopný sledovať všetko, čo robíme a môžem sa mýliť, ale do jadra od nás nie je ani jeden fond.
— Zároveň vyvíjate veľa svojich nástrojov okolo Kubernetes?
Dmitry: Stratégia je takáto: ideme a stiahneme požiadavky na všetko, čo už existuje. Ak tam nie sú akceptované požiadavky na stiahnutie, jednoducho ich sami rozdelíme a žijeme, kým nie sú akceptované našimi zostavami. Potom, keď dosiahne upstream, vrátime sa späť k upstream verzii.
Napríklad máme operátor Prometheus, s ktorým sme sa už asi 5-krát prepínali tam a späť na protiprúd našej zostavy. Potrebujeme nejakú funkciu, poslali sme žiadosť o stiahnutie, musíme ju spustiť zajtra, ale nechceme čakať na jej uvoľnenie. V súlade s tým zostavujeme pre seba, zavádzame našu zostavu s našou funkciou, ktorú z nejakého dôvodu potrebujeme, do všetkých našich klastrov. Potom nám to napríklad otočia v protiprúde so slovami: „Chalani, poďme na nejaký všeobecnejší prípad,“ dokončíme to my alebo niekto iný a po čase sa to zase spojí.
Snažíme sa rozvíjať všetko, čo existuje. Mnohé prvky, ktoré ešte neexistujú, ešte neboli vynájdené, alebo boli vynájdené, no nestihli sme ich zrealizovať – robíme to. A nie preto, že by sa nám páčil proces alebo výroba bicyklov ako odvetvie, ale jednoducho preto, že tento nástroj potrebujeme. Často sa kladie otázka, prečo sme urobili to alebo ono? Odpoveď je jednoduchá - áno, pretože sme museli ísť ďalej, vyriešiť nejaký praktický problém a vyriešili sme ho touto tulou.
Cesta je vždy takáto: veľmi pozorne hľadáme a ak nenájdeme riešenie, ako vyrobiť trolejbus z bochníka chleba, tak si vyrobíme vlastný bochník a vlastný trolejbus.
Nástroje Flata
— Viem, že Flant má teraz operátorov doplnkov, operátorov shellu a nástroje dapp/werf. Ako tomu rozumiem, toto je ten istý nástroj v rôznych inkarnáciách. Tiež chápem, že v rámci Flaunt je oveľa viac rôznych nástrojov. Toto je pravda?
Dmitry: Na GitHub máme oveľa viac. Z toho, čo si teraz pamätám, máme statusmapu – panel pre Grafana, s ktorým sa už stretol každý. Spomína sa takmer v každom druhom článku o monitorovaní Kubernetes na médiu. Nie je možné stručne vysvetliť, čo je to statusmap - potrebuje samostatný článok, ale je to veľmi užitočná vec na sledovanie stavu v čase, keďže v Kubernetes často potrebujeme zobrazovať stav v čase. Máme aj LogHouse – to je vec založená na ClickHouse a čiernej mágii na zbieranie logov v Kubernetes.
Veľa nástrojov! A bude ich ešte viac, pretože tento rok vyjde množstvo interných riešení. Z tých veľmi veľkých založených na operátorovi addonov existuje kopa doplnkov pre Kubernetes, ala ako správne nainštalovať sert manager - nástroj na správu certifikátov, ako správne nainštalovať Prometheus s kopou príslušenstva - je ich asi dvadsať rôznych binárne súbory, ktoré exportujú dáta a niečo zbierajú, k tomu má Prometheus najúžasnejšiu grafiku a upozornenia. To všetko je len kopa doplnkov do Kubernetes, ktoré sú nainštalované v klastri a mení sa to z jednoduchých na cool, sofistikované, automatické, v ktorých je už veľa problémov vyriešených. Áno, robíme veľa.
Vývoj ekosystému
"Zdá sa mi, že je to veľmi veľký príspevok k rozvoju tohto nástroja a jeho metód použitia." Viete zhruba odhadnúť, kto iný by rovnako prispel k rozvoju ekosystému?
Dmitry: V Rusku sa z firiem, ktoré pôsobia na našom trhu, nikto ani len nepribližuje. Samozrejme, je to hlasné vyhlásenie, pretože existujú významní hráči ako Mail a Yandex – aj oni niečo robia s Kubernetes, ale ani oni sa nepribližujú k prínosu spoločností na celom svete, ktoré robia oveľa viac ako my. Je ťažké porovnávať Flant, ktorý má 80 zamestnancov, a Red Hat, ktorý má 300 inžinierov na Kubernetes, ak sa nemýlim. Ťažko to porovnávať. Na oddelení RnD máme 6 ľudí vrátane mňa, ktorí nám strihajú všetky nástroje. 6 ľudí verzus 300 inžinierov Red Hat – je to nejako ťažké porovnávať.
- Keď však aj týchto 6 ľudí dokáže urobiť niečo skutočne užitočné a odcudzujúce, keď stoja pred praktickým problémom a dajú riešenie komunite - zaujímavý prípad. Chápem, že vo veľkých technologických firmách, kde majú vlastný vývojový a podporný tím Kubernetes, sa v princípe dajú vyvinúť rovnaké nástroje. Toto je pre nich príklad toho, čo sa dá vyvinúť a dať komunite, čo dáva impulz celej komunite, ktorá používa Kubernetes.
Dmitry: To je asi vlastnosť integrátora, jeho zvláštnosť. Máme veľa projektov a vidíme veľa rôznych situácií. Hlavným spôsobom vytvárania pridanej hodnoty je pre nás analyzovať tieto prípady, nájsť spoločné znaky a urobiť ich pre nás čo najlacnejšie. Aktívne na tom pracujeme. Je pre mňa ťažké hovoriť o Rusku a svete, ale v spoločnosti máme asi 40 inžinierov DevOps, ktorí pracujú na Kubernetes. Nemyslím si, že v Rusku je veľa spoločností s porovnateľným počtom špecialistov, ktorí rozumejú Kubernetes, ak vôbec nejakí.
Rozumiem všetkému o pracovnej názve DevOps engineer, každý rozumie všetkému a je zvyknutý nazývať DevOps engineers DevOps engineermi, o tom sa nebudeme baviť. Všetkých týchto 40 úžasných inžinierov DevOps čelí a rieši problémy každý deň, my len analyzujeme túto skúsenosť a snažíme sa zovšeobecniť. Chápeme, že ak to v nás zostane, tak o rok či dva bude nástroj zbytočný, pretože niekde v komunite sa objaví hotová Tula. Nemá zmysel hromadiť tieto skúsenosti vnútorne - jednoducho to vysáva energiu a čas do dev/null. A vôbec nám to nie je ľúto. Všetko zverejňujeme s veľkou radosťou a chápeme, že to treba publikovať, rozvíjať, propagovať, propagovať, aby to ľudia využívali a pridávali svoje skúsenosti – potom všetko rastie a žije. Potom po dvoch rokoch nástroj nejde do koša. Nie je škoda pokračovať v nalievaní sily, pretože je jasné, že niekto používa váš nástroj a po dvoch rokoch ho používajú všetci.
Toto je súčasť našej veľkej stratégie s dapp/werf. Nepamätám si, kedy sme to začali vyrábať, pripadá mi to ako pred 3 rokmi. Spočiatku to bolo všeobecne na škrupine. Bol to super dôkaz koncepcie, vyriešili sme niektoré z našich konkrétnych problémov - fungovalo to! Ale s shellom sú problémy, nie je možné ho ďalej rozširovať, programovanie na shelli je ďalšia úloha. Mali sme vo zvyku písať v Ruby, podľa toho sme niečo prerobili v Ruby, vyvinuli, vyvinuli, vyvinuli a narazili sme na to, že komunita, dav, ktorý nehovorí „chceme to alebo to nechceme, “ ohŕňa nos nad Ruby, aké smiešne je to? Uvedomili sme si, že všetky tieto veci by sme mali napísať do Go, len aby sme splnili prvý bod na kontrolnom zozname: Nástroj DevOps by mal byť statický binárny súbor. Byť Go alebo nie nie je také dôležité, ale statický binárny súbor napísaný v Go je lepší.
Minuli sme našu energiu, prepísali dapp v Go a nazvali sme to werf. Dapp už nie je podporovaný, nie je vyvinutý, beží v nejakej najnovšej verzii, ale existuje absolútna cesta inovácie na vrchol a môžete ju nasledovať.
Prečo bola vytvorená dapp?
— Môžete nám stručne povedať, prečo dapp vznikol, aké problémy rieši?
Dmitry: Prvý dôvod je v zhromaždení. Spočiatku sme mali vážne problémy so zostavením, keď Docker nemal viacstupňové možnosti, takže sme si viacstupňový urobili sami. Potom sme mali veľa ďalších problémov s čistením obrazu. Každý, kto robí CI/CD, sa skôr či neskôr stretáva s problémom, že je tam kopa zozbieraných obrázkov, treba nejako upratať nepotrebné a nechať to, čo treba.
Druhým dôvodom je nasadenie. Áno, existuje Helm, ale rieši len niektoré problémy. Je zábavné, že je napísané, že „Helm je správca balíkov pre Kubernetes“. Presne to „to“. Sú tam aj slová „Správca balíkov“ – aké sú obvyklé očakávania od správcu balíkov? Hovoríme: "Správca balíkov - nainštalujte balík!" a očakávame, že nám povie: "Balík bol doručený."
Je zaujímavé, že hovoríme: „Kormidlo, nainštalujte balík,“ a keď odpovie, že ho nainštaloval, ukázalo sa, že práve spustil inštaláciu - naznačil Kubernetesovi: „Spustite túto vec!“ a či sa to začalo alebo nie , či to funguje alebo nie, Helm tento problém vôbec nerieši.
Ukazuje sa, že Helm je len textový preprocesor, ktorý načítava dáta do Kubernetes.
Ale v rámci akéhokoľvek nasadenia chceme vedieť, či bola aplikácia uvoľnená do produkcie alebo nie? Rolled to prod znamená, že aplikácia sa tam presunula, nová verzia bola nasadená a aspoň tam nepadá a reaguje správne. Helm tento problém nijako nerieši. Aby ste to vyriešili, musíte vynaložiť veľa úsilia, pretože musíte dať Kubernetes príkaz na zavedenie a sledovanie toho, čo sa tam deje – či už je nasadený alebo spustený. A je tu tiež veľa úloh súvisiacich s nasadením, čistením a montážou.
Plány
Tento rok odštartujeme miestny rozvoj. Chceme dosiahnuť to, čo bolo predtým vo Vagrant – napísali sme „vagrant up“ a nasadili sme virtuálne stroje. Chceme sa dostať do bodu, keď je v Gite projekt, napíšeme tam „werf up“ a zobrazí sa lokálna kópia tohto projektu, nasadená v miestnom mini-Kub, so všetkými adresármi vhodnými pre vývoj pripojených . V závislosti od vývojového jazyka sa to robí odlišne, ale napriek tomu tak, aby sa lokálny vývoj mohol pohodlne vykonávať pod pripojenými súbormi.
Ďalším krokom pre nás je investovať do pohodlia pre vývojárov. Ak chcete rýchlo nasadiť projekt lokálne pomocou jedného nástroja, vyviňte ho, vložte ho do systému Git a v závislosti od postupov sa spustí aj do štádia alebo testov a potom pomocou rovnakého nástroja prejdete do produkcie. Táto jednota, zjednotenie, reprodukovateľnosť infraštruktúry od lokálneho prostredia až po predaj je pre nás veľmi dôležitý bod. Ale toto ešte nie je vo werf - len to plánujeme urobiť.
Ale cesta k dapp/werf bola vždy rovnaká ako pri Kubernetes na začiatku. Stretli sme sa s problémami, vyriešili sme ich pomocou riešení – prišli sme na nejaké riešenia pre seba na shell, na čokoľvek. Potom sa pokúsili tieto riešenia nejako napraviť, zovšeobecniť a skonsolidovať v tomto prípade do binárnych súborov, ktoré jednoducho zdieľame.
Existuje iný spôsob, ako sa na celý tento príbeh pozrieť s analógiami.
Kubernetes je rám auta s motorom. Nie sú tam žiadne dvere, sklo, rádio, vianočný stromček – vôbec nič. Len rám a motor. A je tu Helm - toto je volant. Cool - je tu volant, ale potrebujete aj čap riadenia, hrebeň riadenia, prevodovku a kolesá a bez nich sa nezaobídete.
V prípade werf je to ďalší komponent pre Kubernetes. Len teraz v alfa verzii werf je napríklad Helm kompilovaný vnútri werf, pretože sme unavení z toho, že to robíme sami. Existuje veľa dôvodov, prečo to urobiť, poviem vám podrobne o tom, prečo sme zostavili celú kormidlo spolu s kormidlom vo vnútri werf .
Teraz je werf integrovanejšou súčasťou. Dostávame hotový volant, čap - nie som veľmi dobrý v autách, ale toto je veľký blok, ktorý už rieši pomerne širokú škálu problémov. Nemusíme sami prechádzať katalógom, vyberať jeden diel za druhý, premýšľať o tom, ako ich zoskrutkovať. Dostávame hotový kombajn, ktorý rieši veľké množstvo problémov naraz. Ale vo vnútri je postavený z rovnakých open source komponentov, stále používa Docker na zostavenie, Helm na niektoré funkcie a existuje niekoľko ďalších knižníc. Ide o integrovaný nástroj na rýchle a pohodlné vytiahnutie chladného CI/CD z krabice.
Je náročné udržiavať Kubernetes?
— Hovoríte o skúsenosti, že ste začali používať Kubernetes, toto je pre vás rám, motor a že naň môžete zavesiť veľa rôznych vecí: telo, volant, priskrutkovať pedále, sedadlá. Vynára sa otázka – ako náročná je pre vás podpora Kubernetes? Máte veľa skúseností, koľko času a zdrojov venujete podpore Kubernetes izolovane od všetkého ostatného?
Dmitry: Toto je veľmi ťažká otázka a na zodpovedanie musíme pochopiť, čo je podpora a čo od Kubernetes chceme. Možno môžete odhaliť?
— Pokiaľ viem a ako vidím, veľa tímov chce teraz vyskúšať Kubernetes. Každý sa naň zapriahne, položí si ho na kolená. Mám pocit, že ľudia nie vždy chápu zložitosť tohto systému.
Dmitry: Je to tak.
— Aké ťažké je prevziať a nainštalovať Kubernetes od začiatku, aby bol pripravený na výrobu?
Dmitry: Aké ťažké je podľa vás transplantovať srdce? Chápem, že toto je kompromisná otázka. Použiť skalpel a nepomýliť sa nie je až také ťažké. Ak vám povedia, kde strihať a kde šiť, tak samotný postup nie je zložitý. Z času na čas je ťažké zaručiť, že všetko bude fungovať.
Inštalácia Kubernetes a uvedenie do prevádzky je jednoduché: mačiatko! — nainštalovaný, existuje veľa spôsobov inštalácie. Čo sa však stane, keď nastanú problémy?
Vždy sa vynárajú otázky – čo sme ešte nezohľadnili? Čo sme ešte neurobili? Ktoré parametre jadra Linuxu boli zadané nesprávne? Pane, spomenuli sme ich vôbec?! Ktoré komponenty Kubernetes sme dodali a ktoré nie? Vynárajú sa tisíce otázok a na ich zodpovedanie musíte v tomto odvetví stráviť 15-20 rokov.
Mám nedávny príklad na túto tému, ktorý môže odhaliť význam problému „Je ťažké udržiavať Kubernetes?“ Pred časom sme vážne uvažovali, či by sme nemali skúsiť implementovať Cilium ako sieť v Kubernetes.
Dovoľte mi vysvetliť, čo je Cilium. Kubernetes má veľa rôznych implementácií sieťového subsystému a jedna z nich je veľmi cool - Cilium. Aký je jeho význam? V jadre bolo pred časom možné písať háčiky pre jadro, ktoré tak či onak napadnú sieťový subsystém a rôzne iné subsystémy a umožnia vám obísť veľké kusy v jadre.
Linuxové jadro má historicky ip rout, overfilter, mosty a mnoho rôznych starých komponentov, ktoré majú 15, 20, 30 rokov. Vo všeobecnosti fungujú, všetko je skvelé, ale teraz nahromadili kontajnery a vyzerá to ako veža z 15 tehál na sebe a stojíte na nej na jednej nohe - zvláštny pocit. Tento systém sa historicky vyvinul s mnohými nuansami, ako napríklad slepé črevo v tele. V niektorých situáciách sú problémy s výkonom, napr.
Je tu nádherný BPF a možnosť písať háčiky pre jadro - chalani si pre jadro napísali vlastné háčiky. Balíček príde do linuxového jadra, vyberú ho hneď na vstupe, sami ho spracujú ako sa patrí bez mostov, bez TCP, bez IP stacku - skrátka obídu všetko, čo je napísané v linuxovom jadre, a potom vypľúvajú to von do kontajnera.
Čo sa stalo? Veľmi skvelý výkon, skvelé funkcie - jednoducho skvelé! Ale pozrieme sa na to a vidíme, že na každom počítači je program, ktorý sa pripája k Kubernetes API a na základe údajov, ktoré dostáva z tohto API, generuje C kód a kompiluje binárne súbory, ktoré načíta do jadra, aby tieto háčiky fungovali. v priestore jadra .
Čo sa stane, ak sa niečo pokazí? Nevieme. Aby ste to pochopili, musíte si prečítať celý tento kód, pochopiť všetku logiku a je úžasné, aké je to ťažké. Ale na druhej strane sú tu tieto mosty, sieťové filtre, ip rout – nečítal som ich zdrojový kód a ani 40 inžinierov, ktorí pracujú v našej spoločnosti. Možno len málokto rozumie niektorým častiam.
A aký je v tom rozdiel? Ukazuje sa, že existuje smerovanie IP, jadro Linuxu a nový nástroj - aký je v tom rozdiel, nerozumieme jednému alebo druhému. Ale bojíme sa použiť niečo nové – prečo? Pretože ak má nástroj 30 rokov, potom za 30 rokov boli všetky chyby nájdené, všetky chyby boli vyšliapnuté a nemusíte vedieť o všetkom - funguje to ako čierna skrinka a vždy funguje. Každý vie, ktorý diagnostický skrutkovač prilepiť na ktoré miesto, ktorý tcpdump spustiť v ktorom momente. Každý dobre pozná diagnostické nástroje a chápe, ako táto sada komponentov funguje v jadre Linuxu – nie ako to funguje, ale ako to používať.
A úžasne cool Cilium nemá 30 rokov, ešte nezostarlo. Kubernetes má rovnaký problém, skopírujte. Že Cilium je nainštalované perfektne, že Kubernetes je nainštalovaný perfektne, ale keď sa niečo pokazí vo výrobe, dokážete v kritickej situácii rýchlo pochopiť, čo sa pokazilo?
Keď hovoríme, že je ťažké udržiavať Kubernetes - nie, je to veľmi jednoduché a áno, je to neuveriteľne ťažké. Kubernetes funguje skvele sám o sebe, ale s miliardou odtieňov.
O prístupe „budem mať šťastie“.
— Existujú spoločnosti, kde sa tieto nuansy takmer zaručene objavia? Predpokladajme, že Yandex náhle prenesie všetky služby do Kubernetes, bude tam obrovské zaťaženie.
Dmitry: Nie, toto nie je rozhovor o náklade, ale o tých najjednoduchších veciach. Máme napríklad Kubernetes, tam sme aplikáciu nasadili. Ako vieš, že to funguje? Jednoducho neexistuje žiadny hotový nástroj na pochopenie toho, že aplikácia nepadá. Neexistuje žiadny hotový systém, ktorý by odosielal upozornenia, musíte tieto upozornenia a každý plán nakonfigurovať. A aktualizujeme Kubernetes.
Mám Ubuntu 16.04. Môžete povedať, že ide o starú verziu, ale stále sme na nej, pretože ide o LTS. Existuje systemd, ktorého nuansou je, že nečistí C-skupiny. Kubernetes spustí moduly, vytvorí skupiny C, potom vymaže moduly a nejako sa ukáže – nepamätám si podrobnosti, prepáč – že segmenty systemd zostávajú. To vedie k tomu, že v priebehu času každé auto začne silne spomaľovať. To nie je ani otázka vysokej záťaže. Ak sú spustené permanentné moduly, napríklad ak existuje Cron Job, ktorá neustále generuje moduly, potom sa stroj s Ubuntu 16.04 začne spomaľovať po týždni. Vďaka tomu, že sa vytvorila kopa C-skupín, bude neustále vysoký priemer zaťaženia. Toto je problém, ktorému bude čeliť každá osoba, ktorá jednoducho nainštaluje Ubuntu 16 a Kubernetes.
Povedzme, že nejakým spôsobom aktualizuje systemd alebo niečo iné, ale v linuxovom jadre do 4.16 je to ešte zábavnejšie – keď odstránite C-skupiny, uniknú do jadra a v skutočnosti sa neodstránia. Preto po mesiaci práce na tomto stroji nebude možné pozrieť sa na štatistiky pamäte pre ohniská. Vyberieme súbor, spustíme ho v programe a jeden súbor sa otáča 15 sekúnd, pretože jadru trvá veľmi dlho, kým v sebe spočíta milión C-skupín, ktoré sa zdajú byť vymazané, ale nie - unikajú .
Takýchto drobností je tu a tam ešte veľa. Toto nie je problém, ktorému môžu niekedy obrovské spoločnosti čeliť pri veľmi veľkom zaťažení – nie, ide o každodenné veci. Ľudia môžu takto žiť mesiace – nainštalovali Kubernetes, nasadili aplikáciu – zdá sa, že to funguje. Pre mnohých ľudí je to normálne. Nebudú ani vedieť, že táto aplikácia z nejakého dôvodu spadne, nedostanú upozornenie, ale pre nich je to norma. Predtým sme žili na virtuálnych strojoch bez monitorovania, teraz sme prešli na Kubernetes, tiež bez monitorovania - aký je rozdiel?
Otázkou je, že keď kráčame po ľade, nikdy nepoznáme jeho hrúbku, pokiaľ si to vopred nezmeriame. Mnoho ľudí chodí a nebojte sa, pretože už kráčali.
Z môjho pohľadu je nuansou a zložitosťou ovládania akéhokoľvek systému zabezpečiť, aby hrúbka ľadu bola presne dostatočná na vyriešenie našich problémov. To je to, o čom hovoríme.
Zdá sa mi, že v IT existuje príliš veľa prístupov typu „budem mať šťastie“. Mnoho ľudí si inštaluje softvér a používa softvérové knižnice v nádeji, že budú mať šťastie. Vo všeobecnosti má veľa ľudí šťastie. Asi preto to funguje.
— Z môjho pesimistického hodnotenia to vyzerá takto: keď sú riziká vysoké a aplikácia musí fungovať, potom je potrebná podpora od Flaunta, možno od Red Hatu, alebo potrebujete vlastný interný tím venovaný špeciálne Kubernetes, ktorý je pripravený aby som to stiahol.
Dmitry: Objektívne je to tak. Dostať sa do príbehu Kubernetes pre malý tím na vlastnú päsť zahŕňa množstvo rizík.
Potrebujeme kontajnery?
— Môžete nám povedať, ako rozšírený je Kubernetes v Rusku?
Dmitry: Nemám tieto údaje a nie som si istý, či ich má niekto iný. Hovoríme: „Kubernetes, Kubernetes“, ale existuje aj iný spôsob, ako sa na tento problém pozrieť. Tiež neviem, aké sú rozšírené kontajnery, ale poznám údaj zo správ na internete, že 70 % kontajnerov riadi Kubernetes. Bol to spoľahlivý zdroj pre pomerne veľkú vzorku z celého sveta.
Potom ďalšia otázka - potrebujeme kontajnery? Môj osobný pocit a celkový postoj firmy Flant je taký, že Kubernetes je de facto štandard.
Nebude nič iné ako Kubernetes.
Toto je absolútna zmena hry v oblasti riadenia infraštruktúry. Len absolútna – to je ono, už žiadne Ansible, Chef, virtuálne stroje, Terraform. Nehovorím o starých metódach JZD. Kubernetes je absolútny menič, a teraz to bude len takto.
Je jasné, že niekomu to trvá niekoľko rokov a niekomu niekoľko desaťročí, kým si to uvedomí. Nepochybujem, že nebude nič iné ako Kubernetes a tento nový vzhľad: už nepoškodzujeme operačný systém, ale používame infraštruktúru ako kód, len nie s kódom, ale s yml - deklaratívne popísaná infraštruktúra. Mám pocit, že to tak bude vždy.
— To znamená, že tie spoločnosti, ktoré ešte neprešli na Kubernetes, naň určite prejdú alebo zostanú v zabudnutí. pochopil som ťa správne?
Dmitry: To tiež nie je celkom pravda. Napríklad, ak máme za úlohu spustiť DNS server, potom môže byť spustený na FreeBSD 4.10 a môže perfektne fungovať 20 rokov. Stačí pracovať a je to. Možno o 20 rokov bude treba raz niečo aktualizovať. Ak hovoríme o softvéri vo formáte, ktorý sme uviedli na trh a ktorý v skutočnosti funguje dlhé roky bez akýchkoľvek aktualizácií, bez vykonávania zmien, potom, samozrejme, nebudú existovať žiadne Kubernetes. Nie je tam potrebný.
Všetko, čo súvisí s CI/CD – všade tam, kde je potrebné nepretržité doručovanie, kde potrebujete aktualizovať verzie, vykonávať aktívne zmeny, všade tam, kde potrebujete vybudovať odolnosť proti chybám – iba Kubernetes.
O mikroslužbách
- Tu mám mierny nesúlad. Na prácu s Kubernetes potrebujete externú alebo internú podporu - to je prvý bod. Po druhé, keď ešte len začíname s vývojom, sme malý startup, zatiaľ nič nemáme, vývoj pre Kubernetes alebo architektúru mikroslužieb vo všeobecnosti môže byť zložitý a nie vždy ekonomicky opodstatnený. Zaujíma ma váš názor – musia startupy okamžite začať písať pre Kubernetes od nuly, alebo môžu stále napísať monolit a potom prísť len na Kubernetes?
Dmitry: Skvelá otázka. Hovorím o mikroslužbách Veľakrát som sa stretol s tým, že ľudia sa pokúšali zatĺcť klince mikroskopom. Samotný prístup je správny, sami si takto navrhujeme interný softvér. Ale keď to urobíte, musíte jasne pochopiť, čo robíte. Slovo, ktoré na mikroslužbách nenávidím najviac, je „mikro“. Historicky toto slovo vzniklo tam a z nejakého dôvodu si ľudia myslia, že mikro je veľmi malý, menej ako milimeter, ako mikrometer. Toto je nesprávne.
Napríklad existuje monolit, ktorý píše 300 ľudí a každý, kto sa podieľal na vývoji, chápe, že sú tam problémy a mal by byť rozbitý na mikrokúsky - asi 10 dielov, z ktorých každý píše 30 ľudí. v minimálnej verzii. To je dôležité, potrebné a cool. Ale keď k nám príde startup, kde 3 veľmi cool a talentovaní chalani napísali na kolene 60 mikroslužieb, zakaždým, keď hľadám Corvalol.
Zdá sa mi, že sa o tom už hovorilo tisíckrát - dostali sme distribuovaný monolit v tej či onej podobe. To nie je ekonomicky opodstatnené, je to vo všeobecnosti veľmi ťažké vo všetkom. Práve som to videl toľkokrát, že ma to naozaj bolí, takže o tom pokračujem.
Na úvodnú otázku je konflikt medzi tým, že na jednej strane je Kubernetes strašidelný používať, pretože nie je jasné, čo sa tam môže pokaziť alebo nefunguje, na druhej strane je jasné, že tam ide všetko a nebude existovať nič iné ako Kubernetes . odpoveď - zvážte množstvo výhod, ktoré prichádza, množstvo úloh, ktoré môžete vyriešiť. Toto je na jednej strane stupnice. Na druhej strane existujú riziká spojené s prestojmi alebo so znížením doby odozvy, úrovne dostupnosti - s poklesom ukazovateľov výkonnosti.
Tu to je – buď sa pohybujeme rýchlo a Kubernetes nám umožňuje robiť veľa vecí oveľa rýchlejšie a lepšie, alebo používame spoľahlivé, rokmi overené riešenia, no pohybujeme sa oveľa pomalšie. Toto je voľba, ktorú musí urobiť každá spoločnosť. Môžete si to predstaviť ako cestu v džungli - keď idete prvýkrát, môžete stretnúť hada, tigra alebo šialeného jazveca, a keď ste išli 10-krát, cestu ste vyšliapali, odstránili konáre a chodiť ľahšie. Zakaždým sa cesta rozšíri. Potom je to asfaltka, neskôr krásny bulvár.
Kubernetes nestojí na mieste. Opäť otázka: Kubernetes je na jednej strane 4-5 binárnych súborov, na druhej strane je to celý ekosystém. Toto je operačný systém, ktorý máme na našich strojoch. Čo to je? Ubuntu alebo Curios? Toto je jadro Linuxu, veľa ďalších komponentov. Všetky tieto veci tu, jeden jedovatý had bol vyhodený z cesty, bol tam postavený plot. Kubernetes sa vyvíja veľmi rýchlo a dynamicky a objem rizík, objem neznámeho sa každým mesiacom zmenšuje a podľa toho sa tieto váhy opäť vyvažujú.
Pri odpovedi na otázku, čo by mal startup robiť, by som povedal – príďte na Flaunt, zaplaťte 150 XNUMX rubľov a získajte jednoduchú službu DevOps na kľúč. Ak ste malý startup s niekoľkými vývojármi, funguje to. Namiesto toho, aby ste si najímali vlastných DevOps, ktorí sa budú musieť naučiť, ako riešiť vaše problémy a platiť plat v tomto čase, získate riešenie všetkých problémov na kľúč. Áno, existujú určité nevýhody. My ako outsourcing nemôžeme byť tak zapojení a rýchlo reagovať na zmeny. Máme však veľa odborných znalostí a hotových postupov. Garantujeme, že v každej situácii na to určite rýchlo prídeme a každého Kubernetesa vzkriesime z mŕtvych.
Vrelo odporúčam outsourcing startupom a zabehnutým firmám až do veľkosti, kde môžete prevádzke venovať tím 10 ľudí, pretože inak to nemá zmysel. Určite má zmysel to outsourcovať.
O spoločnostiach Amazon a Google
— Môže byť hostiteľ z riešenia od Amazonu alebo Google považovaný za outsourcing?
Dmitry: Áno, samozrejme, toto rieši množstvo problémov. Ale opäť sú tu nuansy. Stále musíte pochopiť, ako ho používať. Napríklad v práci Amazon AWS je tisíc malých vecí: Load Balancer je potrebné zahriať alebo vopred napísať požiadavku, že „chalani, dostaneme premávku, zohrejte nám Load Balancer!“ Musíte poznať tieto nuansy.
Keď sa obrátite na ľudí, ktorí sa na to špecializujú, dostanete takmer všetky typické veci uzavreté. Teraz máme 40 inžinierov, do konca roka ich bude pravdepodobne 60 – so všetkými týmito vecami sme sa už určite stretli. Aj keď sa na nejakom projekte opäť stretneme s týmto problémom, rýchlo sa spýtame jeden druhého a vieme ho vyriešiť.
Zrejme odpoveď znie – samozrejme, hostený príbeh nejakú časť uľahčuje. Otázkou je, či ste pripravení dôverovať týmto hostiteľom a či vyriešia vaše problémy. Amazon a Google urobili dobre. Pre všetky naše prípady - presne tak. Pozitívnejšie skúsenosti nemáme. Všetky ostatné cloudy, s ktorými sme sa snažili pracovať, vytvárajú veľa problémov - Ager a všetko, čo je v Rusku, a všetky druhy OpenStack v rôznych implementáciách: Headster, Overage - čokoľvek chcete. Všetky vytvárajú problémy, ktoré nechcete riešiť.
Preto je odpoveď áno, ale v skutočnosti nie je príliš veľa vyspelých hostovaných riešení.
Kto potrebuje Kubernetes?
— A predsa, kto potrebuje Kubernetes? Kto by už mal prejsť na Kubernetes, kto je typický klient Flaunt, ktorý prichádza špeciálne pre Kubernetes?
Dmitry: Toto je zaujímavá otázka, pretože práve teraz, po Kubernetes, k nám prichádza veľa ľudí: "Chlapci, vieme, že robíte Kubernetes, urobte to pre nás!" Odpovedáme im: „Páni, nerobíme Kubernetes, robíme prod a všetko, čo s tým súvisí.“ Pretože v súčasnosti je jednoducho nemožné vyrobiť produkt bez toho, aby ste urobili všetko CI/CD a celý tento príbeh. Všetci sa vzdialili od rozdelenia, že máme vývoj za vývojom a potom vykorisťovanie vykorisťovaním.
Naši klienti očakávajú rôzne veci, ale každý čaká na nejaký dobrý zázrak, že má isté problémy a teraz - hop! — Kubernetes ich vyrieši. Ľudia veria v zázraky. V duchu chápu, že žiadny zázrak sa nekoná, no v duši dúfajú – čo ak tento Kubernetes teraz všetko vyrieši za nás, toľko o tom rozprávajú! Zrazu on teraz - kýchať! - a strieborná guľka, kýchni! — a máme 100 % dostupnosť, všetci vývojári môžu vydať čokoľvek, čo sa dostane do produkcie, 50-krát a nezlyhá to. Vo všeobecnosti, zázrak!
Keď k nám takíto ľudia prídu, povieme: „Prepáčte, ale nič také ako zázrak neexistuje.“ Aby ste boli zdraví, musíte sa dobre stravovať a cvičiť. Aby bol produkt spoľahlivý, musí byť vyrobený spoľahlivo. Ak chcete mať pohodlný CI/CD, musíte ho urobiť takto. To je veľa práce, ktorú treba urobiť.
Odpoveď na otázku, kto potrebuje Kubernetes - nikto nepotrebuje Kubernetes.
Niektorí ľudia majú mylnú predstavu, že potrebujú Kubernetes. Ľudia potrebujú, majú hlbokú potrebu prestať myslieť, študovať a zaujímať sa o všetky problémy infraštruktúry a problémy s prevádzkou svojich aplikácií. Chcú, aby aplikácie len fungovali a len sa nasadzovali. Pre nich je Kubernetes nádejou, že prestanú počuť príbeh, že „ležali sme tam“, „nemôžeme sa rozbehnúť“ alebo niečo iné.
Väčšinou k nám chodí technický riaditeľ. Pýtajú sa ho na dve veci: na jednej strane nám daj vlastnosti, na druhej strane stabilitu. Odporúčame vám vziať to na seba a urobiť to. Strieborné, či skôr postriebrené, je v tom, že prestanete myslieť na tieto problémy a strácať čas. Budete mať špeciálnych ľudí, ktorí tento problém uzavrú.
Formulácia, že my alebo ktokoľvek iný potrebuje Kubernetes, je nesprávna.
Správcovia skutočne potrebujú Kubernetes, pretože je to veľmi zaujímavá hračka, s ktorou sa môžete hrať a hrať. Povedzme si úprimne – každý má rád hračky. Všetci sme niekde deti a keď vidíme nové, chceme sa naň hrať. Niektorých to odradilo napríklad v administrácii, pretože už majú toho dosť odohraného a sú už unavení do takej miery, že sa im jednoducho nechce. Ale toto nie je nikomu úplne stratené. Napríklad, ak ma už dávno omrzia hračky v oblasti správy systému a DevOps, tak tie hračky stále milujem, stále si kupujem nejaké nové. Všetci ľudia, tak či onak, stále chcú nejaké hračky.
Netreba sa hrať s produkciou. Čokoľvek kategoricky odporúčam nerobiť a čo teraz hromadne vidím: „Ach, nová hračka!“ — bežali si to kúpiť, kúpili a: „Vezmime to teraz do školy a ukážme to všetkým našim priateľom.“ Nerob to. Ospravedlňujem sa, moje deti ešte len vyrastajú, neustále na deťoch niečo vidím, všímam si to na sebe a potom to zovšeobecňujem na iných.
Konečná odpoveď je: nepotrebujete Kubernetes. Potrebujete vyriešiť svoje problémy.
Čo môžete dosiahnuť, je:
- prod nespadne;
- aj keď sa pokúsi spadnúť, vieme o tom vopred a môžeme do toho niečo vložiť;
- môžeme to zmeniť rýchlosťou, akou to vyžaduje náš podnik, a môžeme to urobiť pohodlne; nespôsobuje nám to žiadne problémy.
Existujú dve skutočné potreby: spoľahlivosť a dynamika/flexibilita zavádzania. Každý, kto v súčasnosti robí nejaké IT projekty, bez ohľadu na to, v akom biznise - soft pre uľahčenie sveta, a kto tomu rozumie, potrebuje tieto potreby vyriešiť. Kubernetes so správnym prístupom, so správnym pochopením a s dostatkom skúseností ich umožňuje riešiť.
O bez servera
— Ak sa pozriete trochu ďalej do budúcnosti, potom sa pokúsite vyriešiť problém absencie bolesti hlavy s infraštruktúrou, s rýchlosťou zavádzania a rýchlosťou zmien aplikácií sa objavujú nové riešenia, napríklad bez servera. Cítite v tomto smere nejaký potenciál a povedzme nebezpečenstvo pre Kubernetes a podobné riešenia?
Dmitry: Tu treba opäť poznamenať, že nie som veštec, ktorý sa pozerá dopredu a hovorí – bude to takto! Aj keď som urobil to isté. Pozerám na svoje nohy a vidím tam kopu problémov, napríklad ako fungujú tranzistory v počítači. Je to smiešne, však? Stretávame sa s niekoľkými chybami v CPU.
Urobte bez serverov celkom spoľahlivý, lacný, efektívny a pohodlný, ktorý vyrieši všetky problémy s ekosystémom. Tu súhlasím s Elonom Muskom, že na vytvorenie tolerancie voči chybám pre ľudstvo je potrebná druhá planéta. Aj keď neviem, čo hovorí, chápem, že nie som pripravený letieť na Mars a zajtra sa to nestane.
Pri bezserverovom serveri je jasne jasné, že ide o ideologicky správnu vec, napríklad toleranciu chýb pre ľudstvo – mať dve planéty je lepšie ako jednu. Ale ako to urobiť teraz? Vyslanie jednej expedície nie je problém, ak na ňu sústredíte svoje úsilie. Vyslať niekoľko expedícií a usadiť tam niekoľko tisíc ľudí, si myslím, je tiež reálne. Ale urobiť to úplne odolné voči chybám, aby tam žila polovica ľudstva, sa mi teraz zdá nemožné, keď sa na to neberie ohľad.
S bezservermi jeden na jedného: vec je skvelá, ale má ďaleko od problémov roku 2019. Bližšie k roku 2030 – dožime sa toho. Nepochybujem, že budeme žiť, určite budeme žiť (opakovať pred spaním), ale teraz treba riešiť iné problémy. Je to ako veriť v rozprávkového poníka Rainbow. Áno, pár percent prípadov je vyriešených a sú vyriešené perfektne, ale subjektívne je serverless dúha... Pre mňa je táto téma príliš vzdialená a príliš nezrozumiteľná. Nie som pripravený hovoriť. V roku 2019 nemôžete napísať jednu aplikáciu bez servera.
Ako sa bude Kubernetes vyvíjať
— Ako sa podľa vás bude vyvíjať Kubernetes a ekosystém okolo neho, keď smerujeme k tejto potenciálne nádhernej vzdialenej budúcnosti?
Dmitry: Veľa som nad tým premýšľal a mám jasnú odpoveď. Prvý je stavový – koniec koncov, bez štátnej príslušnosti sa ľahšie robí. Kubernetes do toho spočiatku investoval viac, tým to všetko začalo. Stateless funguje v Kubernetes takmer dokonale, jednoducho nie je čo vytknúť. Stále existuje veľa problémov, alebo skôr nuancií. Všetko tam už pre nás funguje skvele, ale to sme my. Bude to trvať ešte aspoň pár rokov, kým to bude fungovať pre všetkých. Toto nie je vypočítaný ukazovateľ, ale môj pocit z hlavy.
Stručne povedané, statefull by sa mal - a bude - vyvíjať veľmi silno, pretože všetky naše aplikácie ukladajú stav, neexistujú žiadne aplikácie bez stavu. Toto je ilúzia; vždy potrebujete nejakú databázu a niečo iné. Statefull je o náprave všetkého možného, oprave všetkých chýb, zlepšení všetkých problémov, s ktorými sa momentálne stretávame – nazvime to adopcia.
Výrazne klesne úroveň neznámeho, úroveň nevyriešených problémov, úroveň pravdepodobnosti, že sa s niečím stretnete. Toto je dôležitý príbeh. A operátori – všetko, čo súvisí s kodifikáciou logiky správy, logiky ovládania, aby sme získali jednoduchú službu: jednoduchá služba MySQL, jednoduchá služba RabbitMQ, ľahká služba Memcache – vo všeobecnosti všetky tieto komponenty, ktoré musíme zaručene vypracovať box. To len rieši bolesť, že chceme databázu, ale nechceme ju spravovať, alebo chceme Kubernetes, ale nechceme ju spravovať.
Tento príbeh vývoja operátorov v tej či onej podobe bude dôležitý v nasledujúcich niekoľkých rokoch.
Myslím si, že jednoduchosť používania by sa mala výrazne zvýšiť - krabica bude čoraz viac čierna, spoľahlivejšia a čoraz viac jednoduchých gombíkov.
Raz som na YouTube v Saturday Night Live počúval starý rozhovor s Isaacom Asimovom z 80. rokov – program ako Urgant, len zaujímavý. Pýtali sa ho na budúcnosť počítačov. Povedal, že budúcnosť je v jednoduchosti, rovnako ako rádio. Rádiový prijímač bol pôvodne zložitá vec. Aby ste chytili vlnu, museli ste 15 minút otáčať gombíkmi, otáčať ražňami a vo všeobecnosti vedieť, ako všetko funguje, pochopiť fyziku prenosu rádiových vĺn. Výsledkom bolo, že v rádiu zostal len jeden gombík.
Aké rádio teraz v roku 2019? V aute rádioprijímač nájde všetky vlny a názvy staníc. Fyzika procesu sa za 100 rokov nezmenila, ale jednoduchosť použitia áno. Teraz, a nielen teraz, už v roku 1980, keď bol rozhovor s Azimovom, všetci používali rádio a nikto sa nezamýšľal nad tým, ako to funguje. Vždy to fungovalo – to je dané.
Azimov potom povedal, že to bude rovnaké s počítačmi - jednoduchosť používania sa zvýši. Kým v roku 1980 ste museli byť naučení stláčať tlačidlá na počítači, v budúcnosti to tak nebude.
Mám pocit, že s Kubernetes a s infraštruktúrou dôjde aj k obrovskému zvýšeniu jednoduchosti používania. To je podľa mňa zrejmé – leží to na povrchu.
Čo robiť s inžiniermi?
— Čo sa potom stane s inžiniermi a správcami systému, ktorí podporujú Kubernetes?
Dmitry: Čo sa stalo s účtovníkom po príchode 1C? O tom istom. Predtým počítali na papieri - teraz v programe. Produktivita práce sa zvýšila rádovo, ale samotná práca nezmizla. Ak predtým potrebovalo na zaskrutkovanie žiarovky 10 inžinierov, teraz bude stačiť jeden.
Zdá sa mi, že množstvo softvéru a počet úloh teraz rastie rýchlejším tempom, ako sa objavujú nové DevOps, a zvyšuje sa efektívnosť. Na trhu je momentálne špecifický nedostatok a bude trvať dlho. Neskôr sa všetko vráti do akéhosi normálu, v ktorom sa zvýši efektivita práce, bude stále viac bez serverov, ku Kubernetes sa pripojí neurón, ktorý si vyberie všetky zdroje presne podľa potreby a celkovo bude rob všetko sám, tak ako má - človek len odstúpi a nezasahuje.
Niekto sa však stále bude musieť rozhodnúť. Je zrejmé, že úroveň kvalifikácie a špecializácie tohto človeka je vyššia. V dnešnej dobe na účtovníctve nepotrebujete, aby 10 zamestnancov viedlo účtovníctvo, aby sa im neunavili ruky. Jednoducho to nie je potrebné. Mnohé dokumenty sú automaticky naskenované a rozpoznané systémom elektronickej správy dokumentov. Stačí jeden šikovný hlavný účtovník, už s oveľa väčšími schopnosťami, s dobrým porozumením.
Vo všeobecnosti je to cesta vo všetkých odvetviach. S autami je to rovnaké: predtým bolo auto s mechanikom a tromi vodičmi. V dnešnej dobe je riadenie auta jednoduchý proces, na ktorom sa každý deň zúčastňujeme všetci. Nikto si nemyslí, že auto je niečo zložité.
DevOps alebo systémové inžinierstvo nezmizne – zvýši sa práca na vysokej úrovni a efektivita.
— Počul som aj zaujímavú myšlienku, že práce skutočne pribudne.
Dmitry: Samozrejme, na sto percent! Pretože množstvo softvéru, ktorý píšeme, neustále rastie. Počet problémov, ktoré riešime softvérom, neustále rastie. Množstvo práce rastie. Teraz je trh DevOps strašne prehriaty. Vidno to na platových očakávaniach. V dobrom slova zmysle, bez zachádzania do detailov, by mali byť juniori, ktorí chcú X, strední, ktorí chcú 1,5X, a seniori, ktorí chcú 2X. A teraz, keď sa pozriete na moskovský platový trh DevOps, junior chce od X do 3X a senior chce od X do 3X.
Nikto nevie, koľko to stojí. Výška platu sa meria podľa vášho sebavedomia – úplný blázinec, úprimne povedané, strašne prehriaty trh.
Samozrejme, táto situácia sa veľmi skoro zmení – mala by nastať určitá saturácia. To nie je prípad vývoja softvéru - napriek tomu, že každý potrebuje vývojárov a každý potrebuje dobrých vývojárov, trh chápe, kto za čo stojí - priemysel sa usadil. To v súčasnosti nie je prípad DevOps.
— Z toho, čo som počul, som dospel k záveru, že súčasný správca systému by sa nemal príliš obávať, ale je čas zdokonaliť svoje zručnosti a pripraviť sa na skutočnosť, že zajtra bude viac práce, ale bude viac kvalifikovaná.
Dmitry: Sto percent. Vo všeobecnosti žijeme v roku 2019 a pravidlom života je toto: celoživotné vzdelávanie – učíme sa celý život. Zdá sa mi, že teraz to už každý vie a cíti, ale nestačí vedieť - musíte to urobiť. Každý deň sa musíme zmeniť. Ak to neurobíme, tak skôr či neskôr odídeme na okraj tejto profesie.
Pripravte sa na ostré zákruty o 180 stupňov. Nevylučujem situáciu, keď sa niečo radikálne zmení, vynájde sa niečo nové - stane sa to. Hop! - a teraz konáme inak. Je dôležité byť na to pripravený a nebáť sa. Môže sa stať, že zajtra sa všetko, čo robím, ukáže ako zbytočné – nič, celý život som študoval a som pripravený naučiť sa niečo iné. To nie je problém. Istoty zamestnania sa netreba báť, ale treba byť pripravený neustále sa učiť niečo nové.
Priania a minúta reklamy
- Máš nejaké želanie?
Dmitry: Áno, mám niekoľko želaní.
Prvý a obchodný - prihláste sa na odber . Vážení čitatelia, prejdite na YouTube a prihláste sa na odber nášho kanála. Približne o mesiac začneme aktívne rozširovať video službu. Budeme mať veľa vzdelávacieho obsahu o Kubernetes, otvoreného a rozmanitého: od praktických vecí, až po laboratóriá, až po hlboké základné teoretické veci a ako používať Kubernetes na úroveň princípov a vzorov.
Druhé obchodné želanie - choď do a dať hviezdy, pretože sa nimi živíme. Ak nám nedáte hviezdičky, nebudeme mať čo jesť. Je to ako mana v počítačovej hre. Niečo robíme, robíme, skúšame, niekto hovorí, že sú to hrozné bicykle, niekto, že je všetko úplne zle, ale my pokračujeme a konáme absolútne čestne. Vidíme problém, riešime ho a zdieľame svoje skúsenosti. Preto nám daj hviezdu, neodíde od teba, ale príde k nám, lebo sa nimi živíme.
Tretie, dôležité a už nie obchodné želanie - prestaň veriť na rozprávky. Ste profesionáli. DevOps je veľmi vážna a zodpovedná profesia. Prestaňte sa hrať na pracovisku. Nech ti to klikne a pochopíš to. Predstavte si, že prídete do nemocnice a tam na vás lekár experimentuje. Chápem, že to môže byť pre niekoho urážlivé, ale s najväčšou pravdepodobnosťou to nie je o vás, ale o niekom inom. Povedz aj ostatným, aby prestali. Toto nám všetkým skutočne ničí život – mnohí sa začnú správať k operáciám, správcom a DevOps ako k chlapom, ktorí opäť niečo pokazili. Toto sa „zlomilo“ najčastejšie tým, že sme išli hrať a nehľadeli s chladným vedomím, že to tak je a je to tak.
To neznamená, že by ste nemali experimentovať. Musíme experimentovať, robíme to sami. Úprimne povedané, aj my sami niekedy hráme hry - to je, samozrejme, veľmi zlé, ale nič ľudské nám nie je cudzie. Vyhlásme rok 2019 za rok serióznych, dobre premyslených experimentov a nie hier na produkciu. Asi áno.
- Ďakujem mnohokrát!
Dmitry: Ďakujem, Vitaly, za čas aj za rozhovor. Vážení čitatelia, veľmi pekne vám ďakujem, ak ste sa zrazu dostali do tohto bodu. Dúfam, že sme vám priniesli aspoň pár myšlienok.
V rozhovore sa Dmitrij dotkol otázky werf. Teraz je to univerzálny švajčiarsky nôž, ktorý rieši takmer všetky problémy. Ale nebolo to tak vždy. Zapnuté na festivale Dmitrij Stolyarov vám o tomto nástroji podrobne povie. v správe bude tam všetko: problémy a skryté nuansy Kubernetes, možnosti riešenia týchto ťažkostí a súčasná implementácia werf podrobne. Pridajte sa k nám 27. a 28. mája, vytvoríme dokonalé nástroje.
Zdroj: hab.com