Megelőlegezve Vitalij Habarov interjút készített Dmitrij Sztoljarov (), a Flant cég műszaki igazgatója és társalapítója. Vitalij megkérdezte Dmitrijt a Flant tevékenységéről, a Kubernetesről, az ökoszisztéma fejlesztéséről, támogatásáról. Megbeszéltük, miért van szükség a Kubernetesre, és szükség van-e rá egyáltalán. Valamint a mikroszolgáltatásokról, az Amazon AWS-ről, a DevOps „szerencsés leszek” megközelítéséről, magának a Kubernetes jövőjéről, miért, mikor és hogyan fogja átvenni a világ uralmát, a DevOps kilátásairól és arról, hogy mire kell felkészülniük a mérnököknek a fényes és közeli jövő az egyszerűsítéssel és a neurális hálózatokkal.
hallgasd meg podcastként a DevOps Deflopon – egy orosz nyelvű podcast a DevOps-ról, alább pedig a szöveges változat.
Itt és lent kérdéseket tesz fel mérnök az Express42-től.
A "Flant"-ról
- Szia Dima. Te vagy a műszaki igazgató""és alapítója is. Kérem, mondja el, mivel foglalkozik a cég, és Ön miben dolgozik?
Dmitry: Kívülről úgy tűnik, hogy mi vagyunk azok a srácok, akik a Kubernetes telepítését járják mindenkinek, és csinálnak vele valamit. De ez nem igaz. Linuxszal foglalkozó cégként indultunk, de nagyon régóta fő tevékenységünk a termelés és a nagy terhelésű kulcsrakész projektek kiszolgálása. Általában a teljes infrastruktúrát a nulláról építjük fel, majd hosszú-hosszú ideig felelősek vagyunk érte. Ezért a „Flant” fő munkája, amelyért pénzt kap, az felelősségvállalás és kulcsrakész gyártás megvalósítása.
A cég műszaki igazgatójaként és egyik alapítójaként egész éjjel-nappal azon töprengek, hogyan lehetne a termelés hozzáférhetőségét növelni, egyszerűsíteni a működését, megkönnyíteni az adminisztrátorok életét, kellemesebbé tenni a fejlesztők életét. .
A Kubernetesről
- Az utóbbi időben sok riportot láttam Flant és Kubernetesről. hogy jöttél rá?
Dmitry: Sokszor beszéltem már erről, de egyáltalán nem bánom, hogy megismételjem. Szerintem helyes megismételni ezt a témát, mert összekeverik az okot és az okozatot.
Valóban szükségünk volt egy eszközre. Rengeteg problémával szembesültünk, küszködtünk, különféle mankóval legyőztük és szükségét éreztük egy szerszámnak. Sokféle lehetőségen mentünk keresztül, saját kerékpárokat építettünk, és tapasztalatokat gyűjtöttünk. Fokozatosan eljutottunk odáig, hogy szinte a megjelenése pillanatában elkezdtük használni a Dockert – 2013 körül. Megjelenésekor már sok tapasztalatunk volt a konténerekkel kapcsolatban, már írtunk a „Docker” analógját - néhány saját mankónkat Pythonban. A Docker megjelenésével lehetővé vált a mankók kidobása és egy megbízható és a közösség által támogatott megoldás alkalmazása.
A Kubernetes esetében hasonló a történet. Mire elkezdett lendületbe jönni - nálunk ez az 1.2-es verzió -, már volt egy rakás mankó a Shellen és a Chefön is, amit valahogy a Dockerrel próbáltunk meg hangszerelni. Komolyan kerestük a Ranchert és a különféle egyéb megoldásokat, de aztán megjelent a Kubernetes, amiben minden pontosan úgy van megvalósítva, ahogyan mi tettük volna, vagy még jobban. Nincs mit panaszkodni.
Igen, van itt valami tökéletlenség, van valami tökéletlenség - sok a tökéletlenség, és az 1.2 általában szörnyű, de... A Kubernetes olyan, mint egy épülő épület - megnézed a projektet és megérted hogy menő lesz. Ha az épület most alapozott és kétszintes, akkor megérti, hogy jobb, ha még nem költözik be, de a szoftverrel nincs ilyen probléma - már használhatja.
Egy pillanatig sem gondolkodtunk azon, hogy használjuk-e a Kubernetes-et vagy sem. Már jóval a megjelenése előtt vártunk rá, és magunk próbáltunk analógokat létrehozni.
A Kubernetesről
— Közvetlenül részt vesz magának a Kubernetes fejlesztésében?
Dmitry: Középszerű. Inkább az ökoszisztéma fejlesztésében veszünk részt. Bizonyos számú lehívási kérelmet küldünk: a Prometheusnak, különböző üzemeltetőknek, Helmnek - az ökoszisztémának. Sajnos nem tudom nyomon követni mindent, amit csinálunk, és tévedhetek is, de nincs tőlünk egyetlen medence sem a mag felé.
— Ugyanakkor sok eszközét a Kubernetes környékén fejleszti?
Dmitry: A stratégia a következő: megyünk, és lekérjük mindenre, ami már létezik. Ha ott nem fogadják el a húzási kérelmeket, egyszerűen magunk villájuk őket, és addig élünk, amíg elfogadják őket a buildjeinkkel. Aztán amikor eléri az upstreamet, visszatérünk az upstream változathoz.
Például van egy Prometheus operátorunk, amivel valószínűleg már 5-ször váltottunk oda-vissza a szerelvényünk előtt. Valamilyen funkcióra van szükségünk, lehívási kérelmet küldtünk, holnap ki kell dobnunk, de nem akarjuk megvárni, hogy upstream kiadják. Ennek megfelelően magunknak szereljük össze, minden klaszterünkre kiterítjük szerelvényünket a funkciónkkal, amelyre valamiért szükségünk van. Aztán például felfelé adják nekünk a következő szavakkal: „Srácok, csináljuk egy általánosabb esetre”, mi vagy valaki más befejezzük, és idővel újra összeolvad.
Igyekszünk mindent fejleszteni, ami létezik. Sok olyan elem, amely még nem létezik, még nem találták fel, vagy feltalálták, de még nem volt ideje megvalósítani - megtesszük. És nem azért, mert szeretjük a folyamatot vagy a kerékpárgyártást mint iparágat, hanem egyszerűen azért, mert szükségünk van erre az eszközre. Gyakran felmerül a kérdés, hogy miért csináltuk ezt vagy azt? A válasz egyszerű - igen, mert tovább kellett mennünk, meg kellett oldanunk valamilyen gyakorlati problémát, és ezzel a tula segítségével megoldottuk.
Az út mindig ilyen: nagyon alaposan keresünk, és ha nem találunk megoldást arra, hogyan készítsünk kenyérből trolibuszt, akkor magunk készítjük a cipót és a trolibuszt.
Flanta szerszámok
— Tudom, hogy a Flantban már vannak addon operátorok, shell operátorok és dapp/werf eszközök. Ha jól értem, ez ugyanaz a hangszer különböző inkarnációkban. Azt is megértem, hogy a Flaunton belül sokkal több különböző eszköz található. Ez igaz?
Dmitry: Sokkal több van a GitHubon. Amennyire most emlékszem, van egy állapottérképünk – egy panel a Grafana számára, amellyel mindenki találkozott. Szinte minden második cikkben megemlítik a Kubernetes megfigyeléséről a Mediumon. Lehetetlen röviden elmagyarázni, mi az a statusmap - külön cikk kell hozzá, de nagyon hasznos dolog az állapot időbeli megfigyeléséhez, mivel a Kubernetesben gyakran meg kell mutatnunk az állapotot az idő múlásával. Van LogHouse-unk is – ez egy ClickHouse-on és a fekete mágián alapuló dolog a naplók összegyűjtésére a Kubernetesben.
Rengeteg közmű! És még több is lesz, mert számos belső megoldás fog megjelenni idén. A nagyon nagyok közül, amelyek az addon operátoron alapulnak, van egy csomó kiegészítő a Kuberneteshez, ala, hogyan kell megfelelően telepíteni a sert managert - egy eszköz a tanúsítványok kezelésére, hogyan kell helyesen telepíteni a Prometheust egy csomó tartozékkal - ez körülbelül húsz különböző bináris fájlok, amelyek adatokat exportálnak és gyűjtenek valamit, ehhez a Prometheus rendelkezik a legcsodálatosabb grafikával és riasztásokkal. Mindez csak egy csomó kiegészítő a Kuberneteshez, amelyek egy fürtben vannak telepítve, és az egyszerűből menővé, kifinomulttá, automatikussá válik, amelyben sok probléma már megoldódott. Igen, sokat csinálunk.
Ökoszisztéma fejlesztés
"Számomra úgy tűnik, hogy ez nagyon nagy hozzájárulás ennek a műszernek és használati módszereinek fejlesztéséhez." Meg tudja-e becsülni hozzávetőlegesen, hogy ki más járulna hozzá ugyanilyen módon az ökoszisztéma fejlődéséhez?
Dmitry: Oroszországban a piacunkon működő cégek közül senki sincs a közelben. Ez persze hangos kijelentés, mert vannak olyan jelentős szereplők, mint a Mail és a Yandex – ők is csinálnak valamit a Kubernetes-szel, de még ők sem közelítik meg a nálunk sokkal többet teljesítő cégek hozzájárulását az egész világon. Ha nem tévedek, nehéz összehasonlítani a 80 fős Flantot és a Red Hatet, amelynek csak Kubernetesenként 300 mérnöke van. Nehéz összehasonlítani. Az RnD osztályon 6 emberünk van, köztük én, aki minden szerszámunkat vágja. 6 ember versus 300 Red Hat mérnök – valahogy nehéz összehasonlítani.
- Viszont amikor ez a 6 ember is tud valami igazán hasznosat és elidegenítőt tenni, amikor egy gyakorlati problémával szembesülve a közösségnek adják a megoldást - érdekes eset. Megértem, hogy a nagy technológiai cégeknél, ahol saját Kubernetes fejlesztő és támogató csapatuk van, elvileg ugyanazokat az eszközöket lehet fejleszteni. Ez egy példa számukra, hogy mit lehet fejleszteni és adni a közösségnek, lendületet adva a Kuberneteset használó teljes közösségnek.
Dmitry: Ez valószínűleg az integrátor sajátossága, sajátossága. Sok projektünk van, és sokféle helyzetet látunk. Számunkra a hozzáadott érték létrehozásának fő módja az, hogy ezeket az eseteket elemezzük, megtaláljuk a közösséget, és a lehető legolcsóbbá tesszük a számunkra. Ezen aktívan dolgozunk. Nehéz Oroszországról és a világról beszélni, de körülbelül 40 DevOps mérnök dolgozik a cégben, akik a Kubernetesen dolgoznak. Nem hiszem, hogy sok olyan cég van Oroszországban, ahol hasonló számú szakember értene a Kuberneteshez, ha van egyáltalán.
Mindent értek a DevOps mérnök munkakörhöz, mindenki mindent ért, és hozzászokott, hogy a DevOps mérnököket DevOps mérnököknek hívják, erről nem fogunk beszélni. Ez a 40 csodálatos DevOps mérnök nap mint nap szembesül és megoldja a problémákat, mi csak elemezzük ezt a tapasztalatot, és megpróbálunk általánosítani. Megértjük, hogy ha bennünk marad, akkor egy-két év múlva használhatatlan lesz az eszköz, mert valahol a közösségben megjelenik egy kész Tula. Nincs értelme ezt a tapasztalatot belsőleg felhalmozni – egyszerűen csak energiát és időt vesz fel a dev/null-ba. És egyáltalán nem sajnáljuk. Mindent nagy örömmel teszünk közzé, és megértjük, hogy közzé kell tenni, fejleszteni, népszerűsíteni, népszerűsíteni kell, hogy az emberek használják és hozzáadják tapasztalataikat - akkor minden nő és él. Aztán két év után nem megy a szemétbe a hangszer. Nem kár tovább önteni az erőt, mert egyértelmű, hogy valaki használja a szerszámot, és két év után mindenki használja.
Ez a dapp/werf nagy stratégiánk része. Nem emlékszem, mikor kezdtük el készíteni, úgy tűnik, 3 éve. Kezdetben általában a héjon volt. Ez a koncepció szuper bizonyítéka volt, megoldottunk néhány konkrét problémánkat – működött! De vannak problémák a shell-el, nem lehet tovább bővíteni, a shell-en való programozás egy másik feladat. Szokásunk volt Ruby nyelven írni, ennek megfelelően valamit újrakészítettünk Rubyban, fejlődtünk, fejlesztettünk, fejlesztettünk, és belefutottunk abba, hogy a közösség, a tömeg, amely nem azt mondja, hogy „akarjuk vagy nem akarjuk, ” felkapja az orrát Ruby felé. Hogy ez nem vicces? Rájöttünk, hogy mindezt a Go-ba kell írnunk, csak hogy megfeleljünk az ellenőrzőlista első pontjának: A DevOps eszköznek statikus binárisnak kell lennie. Go-nak lenni vagy sem, nem olyan fontos, de a Go nyelven írt statikus bináris jobb.
Elhasználtuk az energiánkat, átírtuk a dapp-ot a Go-ban, és werf-nek neveztük el. A Dapp már nem támogatott, nem fejlesztve, valamilyen legújabb verzióban fut, de van egy abszolút frissítési út a csúcsra, és azt követheti.
Miért jött létre a dapp?
– Röviden elárulná, miért jött létre a dapp, milyen problémákat old meg?
Dmitry: Az első ok az összeszerelésben van. Kezdetben komoly problémáink voltak a felépítéssel, amikor a Docker nem rendelkezett többlépcsős képességekkel, így magunk készítettük el a többlépcsős verziót. Aztán még egy csomó problémánk volt a kép tisztításával. Mindenki, aki CI/CD-t csinál, előbb-utóbb szembesül azzal a problémával, hogy van egy rakás összegyűjtött kép, valahogy ki kell takarítani, ami nem kell, és otthagyni, ami kell.
A második ok a telepítés. Igen, van Helm, de csak a problémák egy részét oldja meg. Érdekes módon azt írják, hogy „Helm a Kubernetes csomagkezelője”. Pontosan mi „a”. Vannak még a „Csomagkezelő” szavak – mit várnak el egy csomagkezelőtől? Azt mondjuk: "Csomagkezelő - telepítse a csomagot!" és azt várjuk tőle, hogy azt mondja nekünk: „A csomagot kézbesítettük.”
Érdekes, hogy azt mondjuk: "Siker, telepítse a csomagot", és amikor azt válaszolja, hogy telepítette, kiderül, hogy most kezdte el a telepítést - jelezte Kubernetesnek: "Indítsa el ezt a dolgot!", és hogy elindult-e vagy sem. , akár működik, akár nem, a Helm egyáltalán nem oldja meg ezt a problémát.
Kiderült, hogy a Helm csak egy szöveg-előfeldolgozó, amely adatokat tölt be a Kubernetesbe.
De minden telepítés részeként azt szeretnénk tudni, hogy az alkalmazást kiadták-e élesre vagy sem? A prod-be terjesztve azt jelenti, hogy az alkalmazás odaköltözött, az új verziót telepítették, és ott legalább nem omlik össze, és megfelelően reagál. A Helm semmilyen módon nem oldja meg ezt a problémát. Ennek megoldásához sok erőfeszítést kell költenie, mert ki kell adnia a Kubernetes parancsot, hogy kiterjessze, és figyelje, mi történik ott – akár telepítve van, akár ki. És még rengeteg feladat van a telepítéssel, tisztítással és összeszereléssel kapcsolatban.
Tervek
Idén megkezdjük a helyi fejlesztést. Azt akarjuk elérni, ami korábban a Vagrantban volt – beírtuk a „vagrant up” kifejezést, és virtuális gépeket telepítettünk. El akarunk jutni odáig, hogy van egy projekt a Gitben, oda írjuk a „werf up”-ot, és előhozza ennek a projektnek a helyi példányát, egy helyi mini-kub-ban telepítve, a fejlesztéshez szükséges összes könyvtár csatlakoztatásával. . Ez a fejlesztési nyelvtől függően eltérően történik, de azért, hogy a helyi fejlesztés kényelmesen elvégezhető legyen a csatolt fájlok alatt.
A következő lépés számunkra az fektessen be a fejlesztők kényelmébe. Ha gyorsan szeretne helyileg telepíteni egy projektet egyetlen eszközzel, fejleszti azt, tolja be a Gitbe, és a folyamatoktól függően a szakaszba vagy a tesztekbe is kikerül, majd ugyanazt az eszközt használja a termelési folyamathoz. Ez az egység, egységesítés, az infrastruktúra reprodukálhatósága a helyi környezettől az értékesítésig nagyon fontos szempont számunkra. De ez még nincs a werf-ben – csak tervezzük.
De a dapp/werf felé vezető út mindig is ugyanaz volt, mint a Kubernetesnél kezdetben. Problémákkal találkoztunk, azokat megkerülő megoldásokkal megoldottuk – a héjon, bármire kitaláltunk magunknak néhány megoldást. Aztán megpróbálták valahogy kiegyenesíteni ezeket a megoldásokat, általánosítani és jelen esetben binárisokká konszolidálni, amelyeket egyszerűen megosztunk.
Van egy másik módja ennek az egész történetnek, analógiákkal.
A Kubernetes egy motoros autóváz. Nincs ajtó, üveg, rádió, karácsonyfa – semmi. Csak a váz és a motor. És ott van Helm – ez a kormánykerék. Cool - van kormánykerék, de szükség van kormánycsapra, kormányrúdra, sebességváltóra és kerekekre is, és nem nélkülözheti őket.
A werf esetében ez a Kubernetes másik összetevője. Csak most a werf alfa verziójában például a Helm a werf-en belül van fordítva, mert belefáradtunk, hogy magunk csináljuk. Ennek sok oka van, részletesen elmondom, miért állítottuk össze a teljes kormányt a werf belsejében lévő kormányrúddal együtt .
Most a werf egy integráltabb komponens. Kapunk egy kész kormánykereket, egy kormánycsapot - nem vagyok túl jó az autókban, de ez egy nagy blokk, amely már meglehetősen sokféle problémát megold. Nem kell magunknak átnéznünk a katalógust, ki kell választanunk az egyik alkatrészt a másikhoz, nem kell azon gondolkodnunk, hogyan csavarjuk össze őket. Kész kombájnt kapunk, amely egyszerre nagy számú problémát megold. De belül ugyanazokból a nyílt forráskódú komponensekből épül fel, továbbra is a Dockert használja az összeszereléshez, a Helmet bizonyos funkciókhoz, és számos más könyvtár is létezik. Ez egy integrált eszköz, amellyel gyorsan és kényelmesen veheti ki a hűvös CI/CD-t a dobozból.
Nehéz a Kubernetes karbantartása?
— Arról a tapasztalatról beszélsz, hogy elkezdted használni a Kubernetes-t, ez neked egy váz, egy motor, és hogy nagyon sok mindent fel lehet rá akasztani: karosszériát, kormányt, csavaros pedálokat, üléseket. Felmerül a kérdés – mennyire nehéz Önnek a Kubernetes támogatása? Rengeteg tapasztalattal rendelkezik, mennyi időt és erőforrást fordít a Kubernetes támogatására minden mástól elszigetelve?
Dmitry: Ez egy nagyon nehéz kérdés, és megválaszolásához meg kell értenünk, mi az a támogatás, és mit akarunk a Kubernetestől. Esetleg fel tudod fedni?
— Amennyire én tudom és ahogy látom, most sok csapat szeretné kipróbálni a Kuberneteset. Mindenki beköti magát, térdre teszi. Az az érzésem, hogy az emberek nem mindig értik ennek a rendszernek a bonyolultságát.
Dmitry: Ez így van.
— Mennyire nehéz a nulláról átvenni és telepíteni a Kuberneteset, hogy készen álljon a gyártásra?
Dmitry: Ön szerint mennyire nehéz átültetni egy szívet? Megértem, hogy ez egy kompromittáló kérdés. Nem olyan nehéz szikét használni és nem hibázni. Ha megmondják, hol kell vágni és hol varrni, akkor maga az eljárás nem bonyolult. Nehéz időről időre garantálni, hogy minden sikerülni fog.
A Kubernetes telepítése és működése egyszerű: csaj! — telepítve, sok telepítési mód létezik. De mi történik, ha problémák merülnek fel?
Mindig felmerülnek kérdések – mit nem vettünk még figyelembe? Mit nem csináltunk még? Mely Linux kernelparaméterek lettek hibásan megadva? Uram, egyáltalán megemlítettük őket?! Mely Kubernetes alkatrészeket szállítottunk, és melyeket nem? Kérdések ezrei merülnek fel, amelyek megválaszolásához 15-20 évet kell eltölteni ebben az iparágban.
Van egy nemrégiben bemutatott példám ebben a témában, amely felfedheti a „Nehéz karbantartani a Kuberneteset?” probléma jelentését. Egy ideje komolyan fontolgattuk, hogy meg kell-e próbálnunk a Ciliumot hálózatként megvalósítani Kubernetesben.
Hadd magyarázzam el, mi az a Cilium. A Kubernetes a hálózati alrendszer számos különféle megvalósításával rendelkezik, és az egyik nagyon klassz - a Cilium. mi a jelentése? A kernelben egy ideje lehetővé vált hookok írása a kernelhez, amelyek így vagy úgy behatolnak a hálózati alrendszerbe és számos más alrendszerbe, és lehetővé teszik a kernel nagy darabjainak megkerülését.
A Linux kernelnek történelmileg van egy IP-útvonala, egy túlszűrője, hidak és sok különböző régi összetevő, amelyek 15, 20, 30 évesek. Általában működnek, minden nagyszerű, de most konténereket halmoztak fel, és úgy néz ki, mint egy 15 téglából álló torony egymás tetején, és az ember egy lábon áll rajta - furcsa érzés. Ez a rendszer a történelem során számos árnyalattal fejlődött ki, mint például a testben lévő vakbél. Bizonyos helyzetekben például teljesítményproblémák vannak.
Van egy csodálatos BPF, és lehetőség van hook-ok írására a kernelhez - a srácok saját hook-okat írtak a kernelhez. A csomag bejön a Linux kernelbe, rögtön a bemenetnél kiveszik, hidak nélkül, TCP nélkül, IP verem nélkül - egyszóval mindent megkerülve, ami a Linux kernelben írva van, akkor kiköpnek, ahogy kell. ki a tartályba.
Mi történt? Nagyon klassz teljesítmény, klassz funkciók – egyszerűen klassz! De megnézzük ezt, és azt látjuk, hogy minden gépen van egy program, amely csatlakozik a Kubernetes API-hoz, és az ettől az API-tól kapott adatok alapján C kódot generál és binárisokat fordít, amelyeket betölt a kernelbe, hogy ezek a hookok működjenek. a kernel térben.
Mi történik, ha valami elromlik? Nem tudjuk. Ennek megértéséhez el kell olvasnia ezt a kódot, meg kell értenie az összes logikát, és elképesztő, milyen nehéz. De másrészt ott vannak ezek a hidak, netszűrők, ip rout – nem olvastam a forráskódjukat, és a cégünkben dolgozó 40 mérnök sem. Talán csak kevesen értenek meg egyes részeket.
És mi a különbség? Kiderült, hogy van ip rout, a Linux kernel, és van egy új eszköz - mi a különbség, egyiket vagy másikat nem értjük. De félünk valami újat használni – miért? Mert ha az eszköz 30 éves, akkor 30 év alatt minden hibát megtaláltak, minden hibát ráléptek, és nem kell mindenről tudnia - úgy működik, mint egy fekete doboz, és mindig működik. Mindenki tudja, hogy melyik diagnosztikai csavarhúzót melyik helyre kell beszúrni, melyik tcpdump-ot melyik pillanatban kell futtatni. Mindenki jól ismeri a diagnosztikai segédprogramokat, és érti, hogyan működik ez az összetevőkészlet a Linux kernelben – nem a működését, hanem a használatát.
A félelmetesen menő Cilium pedig nem 30 éves, még nem öregedett. A Kubernetesnél ugyanez a probléma, másolj. Hogy a Ciliumot tökéletesen telepítették, a Kuberneteset pedig tökéletesen, de ha valami elromlik a gyártásban, képes vagy gyorsan megérteni egy kritikus helyzetben, hogy mi ment rosszul?
Amikor azt mondjuk, hogy nehéz fenntartani a Kubernetes-t - nem, ez nagyon egyszerű, és igen, hihetetlenül nehéz. A Kubernetes önmagában is remekül működik, de milliárd árnyalattal.
A „szerencsém lesz” megközelítésről
— Vannak olyan cégek, ahol szinte garantáltan megjelennek ezek az árnyalatok? Tegyük fel, hogy a Yandex hirtelen átadja az összes szolgáltatást a Kubernetesnek, ott hatalmas terhelés lesz.
Dmitry: Nem, ez nem a terhelésről szól, hanem a legegyszerűbb dolgokról. Például van Kubernetesünk, ott telepítettük az alkalmazást. Honnan tudod, hogy működik? Egyszerűen nincs kész eszköz annak megértésére, hogy az alkalmazás nem omlik össze. Nincs kész rendszer, amely riasztásokat küldene, ezeket a riasztásokat és minden ütemezést be kell állítani. És frissítjük a Kuberneteset.
Nekem Ubuntu 16.04 van. Mondhatjuk, hogy ez egy régi verzió, de még mindig rajta vagyunk, mert LTS. Van systemd, aminek az az árnyalata, hogy nem takarítja ki a C-csoportokat. A Kubernetes elindítja a podokat, létrehozza a C-csoportokat, majd törli a podokat, és valahogy kiderül – a részletekre nem emlékszem, sajnálom –, hogy a rendszerszeletek maradnak. Ez ahhoz a tényhez vezet, hogy idővel minden autó erősen lelassul. Ez nem is a highload-ról szól. Ha például állandó podokat indítanak el, ha van például egy Cron Job, amely folyamatosan podokat generál, akkor az Ubuntu 16.04-et tartalmazó gép egy hét után lelassul. Folyamatosan magas lesz a terhelési átlag amiatt, hogy egy csomó C-csoport jött létre. Ez az a probléma, amellyel minden olyan személy szembesül, aki egyszerűen telepíti az Ubuntu 16-ot és a Kuberneteset.
Tegyük fel, hogy valahogy frissíti a systemd-t vagy valami mást, de a Linux kernelben 4.16-ig még viccesebb – ha töröljük a C-csoportokat, azok kiszivárognak a kernelbe, és valójában nem törlődnek. Ezért egy hónapos munka után ezen a gépen lehetetlen lesz megnézni a kandallók memóriastatisztikáit. Kiveszünk egy fájlt, begurítjuk a programba, és egy fájl 15 másodpercig gördül, mert a kernelnek nagyon sok időbe telik, amíg megszámol magában egy millió C-csoportot, amelyek mintha törölve lettek volna, de nem - szivárognak .
Itt-ott még mindig sok ilyen apróság van. Ez nem olyan probléma, amellyel az óriáscégek néha nagyon nagy terhelés alatt szembesülhetnek – nem, ez mindennapi dolgokról van szó. Az emberek hónapokig élhetnek így – telepítették a Kubernetes-t, telepítették az alkalmazást – úgy tűnik, működik. Sok ember számára ez normális. Azt sem fogják tudni, hogy ez az alkalmazás valamiért összeomlik, nem kapnak riasztást, de számukra ez a jellemző. Korábban virtuális gépeken éltünk monitorozás nélkül, most Kubernetesre költöztünk, szintén monitorozás nélkül - mi a különbség?
A kérdés az, hogy amikor jégen sétálunk, sosem tudjuk meg a vastagságát, hacsak meg nem mérjük előre. Sokan sétálnak és ne aggódjanak, mert ők már jártak.
Az én szempontom szerint minden rendszer üzemeltetésének árnyalata és bonyolultsága az, hogy a jég vastagsága pontosan elég legyen a problémáink megoldásához. Erről beszélünk.
Számomra úgy tűnik, hogy az IT-ben túl sok a „szerencsém lesz” megközelítés. Sokan telepítenek szoftvereket és használnak szoftverkönyvtárakat abban a reményben, hogy szerencséjük lesz. Általában sok embernek van szerencséje. Valószínűleg ezért működik.
– Pesszimista értékelésem szerint ez így néz ki: amikor nagyok a kockázatok, és az alkalmazásnak működnie kell, akkor a Flaunttól, esetleg a Red Hattől kell támogatás, vagy saját, kifejezetten a Kubernetesnek szentelt belső csapatra van szükség. hogy lehúzza.
Dmitry: Objektíven ez így van. Egy kis csapat számára a Kubernetes-történetbe való önálló bejutás számos kockázattal jár.
Szükségünk van konténerekre?
— Meg tudná mondani, mennyire elterjedt a Kubernetes Oroszországban?
Dmitry: Nem rendelkezem ezekkel az adatokkal, és nem vagyok benne biztos, hogy másnak is. Azt mondjuk: „Kubernetes, Kubernetes”, de van egy másik módja is ennek a kérdésnek. Azt sem tudom, hogy a konténerek mennyire elterjedtek, de ismerek egy adatot az interneten megjelent jelentésekből, hogy a konténerek 70%-át a Kubernetes hangszereli. Megbízható forrás volt egy meglehetősen nagy minta számára szerte a világon.
Aztán egy másik kérdés - szükségünk van-e konténerekre? Személyes érzésem és a Flant cég általános álláspontja az, hogy a Kubernetes de facto szabvány.
Nem lesz más, csak Kubernetes.
Ez abszolút változást jelent az infrastruktúra menedzsment területén. Csak abszolút – ez az, nincs több Ansible, Chef, virtuális gépek, Terraform. Nem a régi kolhozos módszerekről beszélek. A Kubernetes abszolút megváltoztató, és most már csak ilyen lesz.
Nyilvánvaló, hogy egyeseknek néhány évbe, másoknak néhány évtizedbe telik, hogy ezt felismerjék. Nincs kétségem afelől, hogy nem lesz más, mint a Kubernetes és ez az új megjelenés: már nem rontjuk az operációs rendszert, hanem használjuk infrastruktúra kódként, csak nem kóddal, hanem yml-lel - deklaratívan leírt infrastruktúra. Van egy olyan érzésem, hogy ez mindig így lesz.
— Vagyis azok a cégek, amelyek még nem tértek át a Kubernetesre, biztosan áttérnek rá, vagy a feledés homályában maradnak. jól értettem?
Dmitry: Ez sem teljesen igaz. Például, ha egy DNS szerver futtatása a feladatunk, akkor az a FreeBSD 4.10-en is futtatható, és 20 évig tökéletesen működik. Csak dolgozz és ennyi. Talán 20 év múlva egyszer valamit frissíteni kell. Ha az általunk elindított formátumú szoftverekről beszélünk, és az valóban hosszú évekig működik minden frissítés nélkül, változtatások nélkül, akkor természetesen nem lesz Kubernetes. Ott nincs rá szükség.
Minden, ami CI/CD-vel kapcsolatos – ahol folyamatos kézbesítésre van szükség, ahol frissíteni kell a verziókat, aktív változtatásokat kell végrehajtani, ahol hibatűrést kell kiépíteni – csak a Kubernetes.
A mikroszolgáltatásokról
- Itt van egy kis disszonanciám. A Kubernetes használatához külső vagy belső támogatásra van szüksége - ez az első pont. Másodszor, amikor még csak most kezdjük a fejlesztést, kis startup vagyunk, még nincs semmink, a Kubernetes vagy általában a mikroszolgáltatási architektúra fejlesztése bonyolult lehet, és nem mindig gazdaságilag indokolt. Érdekel a véleménye - az induló vállalkozásoknak azonnal el kell kezdeniük az írást a Kubernetes számára, vagy továbbra is írhatnak monolitot, és csak ezután jönnek a Kuberneteshez?
Dmitry: Jó kérdés. Beszélek a mikroszolgáltatásokról Sokszor találkoztam olyan emberekkel, akik mikroszkóppal próbáltak szöget verni. Maga a megközelítés helyes, mi magunk tervezzük így a belső szoftverünket. De amikor ezt teszi, világosan meg kell értenie, mit csinál. Az a szó, amit a legjobban utálok a mikroszolgáltatásokkal kapcsolatban, a „mikro”. Történelmileg ez a szó onnan származik, és valamiért az emberek azt hiszik, hogy a mikro nagyon kicsi, kevesebb, mint egy milliméter, mint egy mikrométer. Ez rossz.
Például van egy monolit, amit 300-an írnak, és mindenki, aki részt vett a fejlesztésben, megérti, hogy ott problémák vannak, és ezt mikrodarabokra kellene feldarabolni - kb 10 darabra, mindegyiket 30 ember írja. minimum verzióban. Ez fontos, szükséges és menő. De amikor egy startup érkezik hozzánk, ahol 3 nagyon menő és tehetséges srác 60 mikroszolgáltatást írt a térdére, minden alkalommal, amikor a Corvalolt keresem.
Nekem úgy tűnik, hogy erről már több ezerszer beszéltek - ilyen vagy olyan formában kaptunk elosztott monolitot. Ez gazdaságilag nem indokolt, nagyon nehéz általában mindenben. Annyiszor láttam ezt, hogy nagyon fáj, ezért tovább beszélek róla.
A kiinduló kérdésre ellentmondás van aközött, hogy egyrészt a Kubernetes használata félelmetes, mert nem világos, hogy ott mi törhet el vagy nem működik, másrészt egyértelmű, hogy minden megy oda. és Kubernetesen kívül semmi más nem fog létezni . Válasz - mérlegelje az érkező haszon mennyiségét, a megoldható feladatok mennyiségét. Ez a skála egyik oldalán található. Másrészt kockázatok állnak fenn az állásidővel vagy a válaszidő, a rendelkezésre állás csökkenésével - a teljesítménymutatók csökkenésével.
Itt van – vagy gyorsan haladunk, és a Kubernetes sok dolgot sokkal gyorsabban és jobban tesz lehetővé, vagy megbízható, jól bevált megoldásokat használunk, de sokkal lassabban haladunk. Ezt a döntést minden cégnek meg kell hoznia. Úgy képzelheted el, mint egy ösvényt a dzsungelben – amikor először sétálsz, találkozhatsz egy kígyóval, egy tigrissel vagy egy veszett borzsal, és ha már 10-szer jártál, már kitaposod az ösvényt, eltávolodtál. az ágakat és könnyebben járni. Minden alkalommal, amikor az út szélesebb lesz. Aztán ez egy aszfaltút, később egy szép körút.
Kubernetes nem áll meg. Újra kérdés: a Kubernetes egyrészt 4-5 bináris, másrészt a teljes ökoszisztéma. Ez az operációs rendszer, amely a gépeinken van. Mi ez? Ubuntu vagy Curios? Ez a Linux kernel, egy csomó további összetevő. Mindezek itt, egy mérges kígyót kidobtak az útról, kerítést emeltek oda. A Kubernetes nagyon gyorsan és dinamikusan fejlődik, a kockázatok, az ismeretlenek mennyisége pedig hónapról hónapra csökken, és ennek megfelelően ezek a skálák kiegyensúlyozódnak.
Arra a kérdésre válaszolva, hogy mit kell tennie egy startupnak, azt mondanám: jöjjön a Flauntba, fizessen 150 ezer rubelt, és kapjon kulcsrakész DevOps egyszerű szolgáltatást. Ha Ön egy kis startup néhány fejlesztővel, ez működik. Ahelyett, hogy saját DevOp-okat bérelne fel, akiknek meg kell tanulniuk megoldani a problémáit, és jelenleg fizetést kell fizetniük, kulcsrakész megoldást kap minden kérdésre. Igen, van néhány hátránya. Kiszervezésként nem tudunk ennyire bevonódni és gyorsan reagálni a változásokra. De sok szaktudásunk és kész gyakorlatunk van. Garantáljuk, hogy minden helyzetben gyorsan kitaláljuk, és feltámasztjuk a halálból a Kuberneteseket.
Nyomatékosan javaslom az outsourcingot startupoknak és bejáratott vállalkozásoknak olyan méretig, hogy egy 10 fős csapatot lehessen az üzemeltetésre szentelni, mert különben nincs értelme. Ennek mindenképpen van értelme kiszervezni.
Az Amazonról és a Google-ról
— Az Amazon vagy a Google megoldásából származó gazdagép tekinthető outsource-nak?
Dmitry: Igen, természetesen ez számos problémát megold. De ismét vannak árnyalatok. Még mindig meg kell értened, hogyan kell használni. Például ezer apróság van az Amazon AWS munkájában: be kell melegíteni a Load Balancert, vagy előre meg kell írni egy kérést, hogy „srácok, fogadjuk a forgalmat, melegítsétek be nekünk a Load Balancert!” Ismernie kell ezeket az árnyalatokat.
Ha az erre szakosodott emberekhez fordul, szinte minden tipikus dolgot lezár. Jelenleg 40 mérnökünk van, az év végére valószínűleg 60 lesz – ezekkel a dolgokkal biztosan találkoztunk. Még ha újra találkozunk ezzel a problémával valamelyik projektben, gyorsan megkérdezzük egymást, és tudjuk, hogyan oldjuk meg.
Valószínűleg az a válasz – természetesen, hogy a tárolt történet egyes részeit könnyebbé teszi. A kérdés az, hogy készen áll-e megbízni ezekben a házigazdákban, és megoldják-e a problémáit. Az Amazon és a Google jól teljesített. Minden esetünkre – pontosan. Nincsenek több pozitív tapasztalatunk. Az összes többi felhő, amellyel megpróbáltunk dolgozni, sok problémát okoz - az Ager és minden, ami Oroszországban van, és mindenféle OpenStack különböző megvalósításokban: Headster, Overage - amit akarsz. Ezek mind olyan problémákat okoznak, amelyeket nem akarsz megoldani.
Ezért a válasz igen, de valójában nem sok kiforrott hosztolt megoldás létezik.
Kinek van szüksége Kubernetesre?
— És mégis, kinek van szüksége Kubernetesre? Kinek kellene már Kubernetesre váltania, ki az a tipikus Flaunt kliens, aki kifejezetten Kubernetesre érkezik?
Dmitry: Ez egy érdekes kérdés, mert most, a Kubernetes nyomán sokan betérnek hozzánk: "Srácok, tudjuk, hogy Kubernetes-t csináltok, tegyétek meg nekünk!" Azt válaszoljuk nekik: "Uraim, mi nem Kuberneteset csinálunk, hanem prod-ot és mindent, ami ezzel kapcsolatos." Mert jelenleg egyszerűen lehetetlen terméket készíteni anélkül, hogy megcsinálná az összes CI/CD-t és ezt az egész történetet. Mindenki eltávolodott attól a felosztástól, hogy nálunk a fejlődés fejlesztésről, majd a kizsákmányolás a kizsákmányolásról van szó.
Ügyfeleink mást várnak el, de mindenki valami jó csodát vár, hogy valami problémája van, és most - hopp! — Kubernetes megoldja őket. Az emberek hisznek a csodákban. Lelkükben megértik, hogy nem lesz csoda, de lelkükben reménykednek - mi lesz, ha ez a Kubernetes most mindent megold helyettünk, annyit beszélnek róla! Hirtelen most - tüsszents! - és egy ezüstgolyót, tüsszents! - és 100%-os rendelkezésre állásunk van, minden fejlesztő 50-szer kiadhatja azt, ami a termelésbe kerül, és nem omlik össze. Általában egy csoda!
Amikor ilyen emberek jönnek hozzánk, azt mondjuk: "Sajnálom, de nincs olyan, hogy csoda." Ahhoz, hogy egészséges legyen, jól kell étkezni és mozogni. Ahhoz, hogy megbízható termékünk legyen, azt megbízhatóan kell elkészíteni. Ahhoz, hogy kényelmes CI/CD legyen, ilyennek kell elkészítenie. Ez nagyon sok munka, amit el kell végezni.
Arra a kérdésre válaszolva, hogy kinek van szüksége Kubernetesre - senkinek sem kell Kubernetes.
Vannak, akiknek az a tévhitük, hogy Kubernetesre van szükségük. Az embereknek szükségük van arra, hogy ne gondolkodjanak, tanuljanak és érdeklődjenek az infrastruktúra minden problémája és alkalmazásaik futtatásával kapcsolatos problémák iránt. Azt akarják, hogy az alkalmazások csak működjenek, és csak telepítsenek. Számukra a Kubernetes a remény, hogy többé nem hallják azt a történetet, hogy „ott feküdtünk”, „nem tudunk kigurulni”, vagy valami mást.
Általában hozzánk jön a műszaki igazgató. Két dolgot kérnek tőle: egyrészt adjon vonásokat, másrészt stabilitást. Azt javasoljuk, hogy vegye magára, és tegye meg. Az ezüstgolyó, vagy inkább ezüstözött, az, hogy többé nem gondolsz ezekre a problémákra és nem vesztegeti az időt. Különleges emberei lesznek, akik lezárják ezt a kérdést.
Az a megfogalmazás, hogy nekünk vagy bárki másnak szüksége van a Kubernetesre, helytelen.
Az adminisztrátoroknak nagy szükségük van a Kubernetesre, mert ez egy nagyon érdekes játék, amivel lehet játszani és bütykölni. Legyünk őszinték – mindenki szereti a játékokat. Valahol mindannyian gyerekek vagyunk, és ha újat látunk, azt szeretnénk játszani. Egyesek ezt elvetették, például az adminisztrációban, mert már eleget játszottak, és már annyira elfáradtak, hogy egyszerűen nem akarnak. De ez nincs teljesen elveszve senki számára. Például, ha már régóta elegem van a játékokból a rendszeradminisztráció és a DevOps terén, akkor továbbra is szeretem a játékokat, még mindig veszek néhány újat. Minden ember, így vagy úgy, mégis szeretne valamilyen játékot.
Nem kell játszani a produkcióval. Bármit is kategorikusan ajánlok, hogy ne tegye meg, és amit most tömegesen látok: "Ó, egy új játék!" – futottak megvenni, megvették és: „Most vigyük el az iskolába, és mutassuk meg minden barátunknak.” Ne csináld ezt. Elnézést kérek, a gyerekeim még csak felnőnek, folyamatosan látok valamit a gyerekekben, észreveszem magamon, aztán általánosítok másokra.
A végső válasz: nincs szüksége Kubernetesre. Meg kell oldanod a problémáidat.
Amit el tudsz érni:
- prod nem esik;
- ha meg is próbál esni, előre tudunk róla, és tehetünk bele valamit;
- olyan sebességgel tudjuk változtatni, amilyen sebességgel a vállalkozásunk megkívánja, és kényelmesen megtehetjük, nem okoz gondot.
Két valós igény van: a megbízhatóság és a dinamizmus/rugalmasság. Mindenkinek, aki éppen valamilyen informatikai projekttel foglalkozik, mindegy, hogy milyen üzletben – puha a világ könnyítésére, és aki ezt megérti, annak meg kell oldania ezeket az igényeket. A Kubernetes a megfelelő megközelítéssel, megfelelő megértéssel és kellő tapasztalattal lehetővé teszi ezek megoldását.
A szerver nélküliről
— Ha kicsit távolabbra tekintünk a jövőbe, akkor a fejfájás hiányának problémáját infrastruktúrával próbáljuk megoldani, a kiterjesztés gyorsaságával és az alkalmazásváltások gyorsaságával új megoldások jelennek meg, például szerver nélküli. Érez ebben az irányban potenciált, és mondjuk veszélyt a Kubernetes és hasonló megoldások számára?
Dmitry: Itt megint egy megjegyzést kell tennünk, hogy nem vagyok látó, aki előre néz és azt mondja - így lesz! Bár én pont ugyanezt csináltam. A lábamra nézek, és egy csomó problémát látok ott, például a tranzisztorok működését egy számítógépben. Vicces, igaz? Néhány hibával találkozunk a CPU-ban.
Tedd a szerver nélküli megoldást meglehetősen megbízhatóvá, olcsóvá, hatékonysá és kényelmessé, megoldva az összes ökoszisztéma-problémát. Itt egyetértek Elon Muskkal, hogy szükség van egy második bolygóra az emberiség hibatűrésének megteremtéséhez. Bár nem tudom, mit mond, megértem, hogy nem állok készen arra, hogy magam repüljek a Marsra, és ez nem holnap fog megtörténni.
A szerver nélkülinél egyértelműen világos, hogy ez egy ideológiailag helyes dolog, mint az emberiség hibatűrése – jobb két bolygó, mint egy. De most hogyan kell csinálni? Egy expedíció elküldése nem jelent problémát, ha erre összpontosítja az erőfeszítéseit. Több expedíció kiküldése és több ezer ember odatelepítése szerintem is reális. De teljesen hibatűrővé tenni, hogy az emberiség fele ott éljen, számomra most lehetetlennek tűnik, nem gondolva.
Szerver nélküli egy az egyben: a dolog menő, de messze van a 2019-es problémáktól. Közelebb 2030-hoz – éljük meg, és lássuk. Nincs kétségem afelől, hogy élni fogunk, biztosan élni fogunk (ismételjük lefekvés előtt), de most más problémákat kell megoldanunk. Mintha hinnénk a mesebeli Rainbow póniban. Igen, az esetek pár százaléka megoldódik, és tökéletesen megoldódik, de szubjektíven a szerver nélküli szivárvány... Számomra ez a téma túl távoli és túl érthetetlen. Nem állok készen a beszélgetésre. 2019-ben nem írhat egyetlen alkalmazást sem szerver nélkül.
Hogyan fog fejlődni a Kubernetes
— Ön szerint hogyan fog fejlődni a Kubernetes és a körülötte lévő ökoszisztéma, ahogy haladunk e potenciálisan csodálatos távoli jövő felé?
Dmitry: Sokat gondolkodtam ezen, és egyértelmű válaszom van. Az első a statefull – elvégre a hontalanságot könnyebb megcsinálni. A Kubernetes kezdetben többet fektetett ebbe, minden ezzel kezdődött. A Stateless szinte tökéletesen működik Kubernetesben, csak nincs okunk panaszra. Még mindig sok probléma van, vagy inkább árnyalatok. Ott már minden remekül működik nálunk, de mi vagyunk. Még legalább pár évnek kell eltelnie ahhoz, hogy ez mindenkinél működjön. Ez nem számított mutató, hanem az én fejemből fakadó érzésem.
Röviden, a statefull-nak nagyon erősen kell fejlődnie - és fog is - fejlődni, mert minden alkalmazásunk tárolja az állapotot, nincsenek állapot nélküli alkalmazások. Ez egy illúzió, mindig szüksége van valamiféle adatbázisra és valami másra. A Statefull arról szól, hogy mindent ki kell javítani, ami csak lehetséges, kijavítani az összes hibát, javítani az összes jelenlegi problémán – nevezzük ezt elfogadásnak.
Az ismeretlen szintje, a megoldatlan problémák szintje, a valamivel való találkozás valószínűsége jelentősen csökkenni fog. Ez egy fontos történet. És az operátorok - minden, ami az adminisztrációs logika kodifikálásával kapcsolatos, a vezérlési logika a könnyű szolgáltatás elérése érdekében: MySQL egyszerű szerviz, RabbitMQ egyszerű szerviz, Memcache egyszerű szolgáltatás - általában ezek az összetevők, amelyekből garantáltan ki kell dolgozni a doboz. Ez csak azt a fájdalmat oldja meg, hogy szeretnénk egy adatbázist, de nem akarjuk adminisztrálni, vagy szeretnénk a Kubernetes-et, de nem akarjuk kezelni.
Az operátorok ilyen vagy olyan formában történő fejlődésének története fontos lesz a következő néhány évben.
Szerintem a könnyű kezelhetőségnek nagyban kellene növekednie - a doboz egyre feketébb, egyre megbízhatóbb lesz, egyre egyszerűbb gombokkal.
Egyszer meghallgattam egy régi interjút Isaac Asimov-val a 80-as évekből a YouTube-on a Saturday Night Live-on – egy olyan program, mint az Urgant, csak érdekes. A számítógépek jövőjéről kérdezték. Azt mondta, hogy a jövő az egyszerűségben van, akárcsak a rádióban. A rádióvevő eredetileg egy összetett dolog volt. A hullám elkapásához 15 percig forgatni kellett a gombokat, forgatni a nyársakat, és általában tudni kellett, hogyan működik minden, megérteni a rádióhullám-átvitel fizikáját. Ennek eredményeként csak egy gomb maradt a rádióban.
Most 2019-ben milyen rádió? Az autóban a rádióvevő megtalálja az összes hullámot és az állomások nevét. A folyamat fizikája nem változott 100 év alatt, de a könnyű használhatóság igen. Most, és nem csak most, már 1980-ban, amikor volt egy interjú Azimovval, mindenki használta a rádiót, és senki sem gondolt arra, hogyan működik. Mindig működött – ez adott.
Azimov ezután azt mondta, hogy ez a számítógépekkel is így lesz. a használat egyszerűsége nőni fog. Míg 1980-ban meg kellett tanítani a számítógép gombjainak megnyomására, ez a jövőben nem lesz így.
Az az érzésem, hogy a Kubernetes és az infrastruktúra segítségével a használhatóság is hatalmasat fog növekedni. Ez véleményem szerint nyilvánvaló - a felszínen fekszik.
Mit kezdjünk a mérnökökkel?
— Mi lesz ezután a Kuberneteset támogató mérnökökkel és rendszergazdákkal?
Dmitry: Mi történt a könyvelővel az 1C megjelenése után? Ugyanarról. Előtte papíron számoltak – most a programban. A munka termelékenysége nagyságrendekkel nőtt, de maga a munka nem tűnt el. Ha korábban 10 mérnök kellett egy izzó becsavarásához, most egy is elég lesz.
Számomra úgy tűnik, hogy a szoftverek és a feladatok száma gyorsabban növekszik, mint ahogy az új DevOp-ok megjelennek, és a hatékonyság nő. Jelenleg konkrét hiány van a piacon, és ez sokáig fog tartani. Később minden visszaáll egy bizonyos normához, amelyben a munka hatékonysága nő, egyre több lesz a szerver nélküliség, a Kuberneteshez egy neuron kapcsolódik, amely pontosan kiválasztja az összes erőforrást, és általában megteszi. mindent maga, ahogy kell - a személy elköltözik, és nem avatkozik bele.
De valakinek akkor is döntéseket kell hoznia. Nyilvánvaló, hogy ennek a személynek a képzettségi szintje és a specializációja magasabb. Manapság a könyvelésen nem kell 10 alkalmazott könyvet vezetni, hogy ne fáradjon el a keze. Egyszerűen nem szükséges. Sok dokumentumot automatikusan beszkennel és felismer az elektronikus dokumentumkezelő rendszer. Elég egy okos főkönyvelő, már sokkal nagyobb tudással, jó megértéssel.
Általában minden iparágban ez az út. Ugyanez a helyzet az autókkal: korábban egy autó szerelővel és három sofőrrel érkezett. Manapság az autóvezetés egy egyszerű folyamat, amelyben mindannyian nap mint nap részt veszünk. Senki sem gondolja, hogy az autó bonyolult dolog.
A DevOps vagy a rendszertervezés nem szűnik meg – a magas szintű munka és a hatékonyság nő.
— Hallottam egy érdekes ötletet is, hogy a munka valóban növekedni fog.
Dmitry: Persze, száz százalék! Mert az általunk írt szoftverek mennyisége folyamatosan növekszik. Folyamatosan nő a szoftverekkel megoldandó problémák száma. A munka mennyisége nő. Most a DevOps piac rettenetesen túlfűtött. Ez a fizetési elvárásokon is meglátszik. Jó értelemben, anélkül, hogy belemennénk a részletekbe, legyenek juniorok, akik X-et, középsők, akik 1,5X-et, és idősebbek 2X-et akarnak. És most, ha megnézzük a moszkvai DevOps fizetési piacot, egy junior X-től 3X-ig, egy idősebb pedig X-től 3X-ig.
Senki sem tudja, mennyibe kerül. A fizetési szintet az önbizalmad méri – egy komplett őrültek háza, hogy őszinte legyek, egy borzasztóan túlfűtött piac.
Természetesen ez a helyzet hamarosan megváltozik - némi telítettségnek kell bekövetkeznie. A szoftverfejlesztésnél nem ez a helyzet - hiába kell mindenkinek fejlesztő, és mindenkinek jó fejlesztő kell, a piac érti, ki mit ér -, az iparág letelepedett. Manapság ez nem így van a DevOps esetében.
– A hallottak alapján arra a következtetésre jutottam, hogy a jelenlegi rendszergazdának nem kell sokat aggódnia, de ideje továbbfejlesztenie tudását, és felkészülni arra, hogy holnap több munka lesz, de magasabban képzett.
Dmitry: Száz százalék. Általában 2019-ben élünk, és az élet szabálya a következő: élethosszig tartó tanulás – életünk során tanulunk. Számomra úgy tűnik, hogy ezt már mindenki tudja és érzi, de nem elég tudni - meg kell tennie. Minden nap változnunk kell. Ha ezt nem tesszük meg, akkor előbb-utóbb a szakma szélére kerülünk.
Készüljön fel az éles, 180 fokos fordulatokra. Nem zárom ki azt a helyzetet, amikor valami gyökeresen megváltozik, valami újat találnak ki – megtörténik. Komló! - és most másképp cselekszünk. Fontos, hogy felkészüljünk erre, és ne aggódjunk. Előfordulhat, hogy holnap minden, amit csinálok, feleslegesnek bizonyul - semmi, egész életemben tanultam, és készen állok valami mást tanulni. Nem probléma. Nem kell félni a munkahely biztonságától, de fel kell készülni arra, hogy folyamatosan tanulj valami újat.
Kívánság és egy perc reklám
- Van valami kívánságod?
Dmitry: Igen, több kívánságom is van.
Első és kereskedelmi - iratkozzon fel . Kedves olvasók, menjetek a YouTube-ra és iratkozzatok fel csatornánkra. Körülbelül egy hónapon belül megkezdjük a videószolgáltatás aktív bővítését, sok, nyílt és változatos oktatási tartalommal fogunk rendelkezni a Kubernetesről: a gyakorlati dolgoktól kezdve egészen a laboratóriumokig, a mélyreható elméleti dolgokig és a Kubernetes használatáig. elvek és minták szintje.
A második kereskedő kívánság - menj és tegyen csillagokat, mert azokból táplálkozunk. Ha nem adsz nekünk csillagokat, nem lesz mit ennünk. Olyan, mint a mana egy számítógépes játékban. Csinálunk valamit, csinálunk, próbálkozunk, valaki azt mondja, hogy ezek szörnyű kerékpárok, valaki azt, hogy minden teljesen rossz, de folytatjuk és teljesen őszintén cselekszünk. Látunk egy problémát, megoldjuk és megosztjuk tapasztalatainkat. Ezért adj nekünk egy csillagot, nem megy el tőled, de eljön hozzánk, mert belőlük táplálkozunk.
Harmadszor, fontos és már nem kereskedelmi kívánság - ne higgy a mesékben. Profik vagytok. A DevOps egy nagyon komoly és felelősségteljes szakma. Hagyja abba a játékot a munkahelyen. Hadd kattanjon helyetted, és meg fogod érteni. Képzeld el, hogy bejössz a kórházba, és ott az orvos kísérletez veled. Megértem, hogy ez valakit sértő lehet, de valószínűleg ez nem rólad szól, hanem valaki másról. Mondd meg másoknak is, hogy hagyják abba. Ez valóban tönkreteszi mindannyiunk életét – sokan kezdik úgy kezelni a műveleteket, az adminisztrátorokat és a DevOp-okat, mint a haverokat, akik megint elrontottak valamit. Ez leggyakrabban annak volt „törve”, hogy elmentünk játszani, és nem néztük hideg tudattal, hogy mi van itt és mi van itt.
Ez nem azt jelenti, hogy nem szabad kísérletezni. Kísérletezni kell, mi magunk csináljuk. Őszintén szólva, mi magunk is játszunk néha - ez persze nagyon rossz, de semmi emberi nem idegen tőlünk. 2019-et nyilvánítsuk a komoly, átgondolt kísérletek évének, és ne a gyártás alatt álló játékok évének. Valószínűleg így van.
- Nagyon szépen köszönjük!
Dmitry: Köszönöm, Vitalij, az időt és az interjút is. Kedves olvasók, nagyon köszönöm, ha hirtelen idáig jutottatok. Remélem, legalább néhány gondolatot elhoztunk.
Az interjúban Dmitrij érintette a werf kérdését. Most ez egy univerzális svájci kés, amely szinte minden problémát megold. De nem mindig volt így. Tovább fesztiválokra Dmitrij Stolyarov részletesen elmondja Önnek ezt az eszközt. a jelentésben minden lesz: a Kubernetes problémái és rejtett árnyalatai, ezek a nehézségek megoldásának lehetőségei és a werf jelenlegi megvalósítása részletesen. Csatlakozz hozzánk május 27-én és 28-án, mi elkészítjük a tökéletes eszközöket.
Forrás: will.com