Az elkövetkező időszakban Vitalij Habrov interjút készített Dmitrij Stoljárovval (), a "Flant" cég műszaki igazgatójával és társ-alapítójával. Vitalij megkérdezte Dmitrijt, mivel foglalkozik a "Flant", a Kubernetesről, az ökoszisztéma fejlődéséről és támogatásáról. Beszélgettek arról, miért van szükség Kubernetesre és valóban szükség van-e rá. Emellett szó esett a mikroszolgáltatásokról, az Amazon AWS-ről, a DevOps „Szerencsés leszek” megközelítéséről, Kubernetes jövőjéről, arról, miért, mikor és hogyan fogja meghódítani a világot, a DevOps kilátásairól és arról, mire készüljenek a mérnökök a közeljövőben, a leegyszerűsítés és a neurális hálózatok fényében.
podcast formájában hallgatható a DevOps Deflopon — orosz nyelvű podcast a DevOps-ról, alább pedig a szöveges változat.
Itt és itt a kérdéseket felteszi az Express42 mérnöke.
A "Flant"-ról
— Dima, üdvözöllek. Te vagy a "" műszaki igazgatója és alapítója. Kérlek, mesélj arról, mivel foglalkozik a cég és te ebben milyen szerepet játszol?
Dmitrij: Külső szemmel úgy tűnik, hogy mi olyan srácok vagyunk, akik mindenkinek telepítik a Kubernetes-t és valamit csinálnak vele. De ez nem igaz. Mi Linuxszal foglalkozó cékként indultunk, de már régóta a fő tevékenységünk a production és high-load projektek kulcsrakész üzemeltetése. Általában az egész infrastruktúrát nulláról építjük fel, majd hosszú ideig felelősek vagyunk érte. Ezért a "Flant" alapvető munkája, amivel pénzt keres, a felelősségvállalás és a kulcsrakész production megvalósítása.
Én, mint műszaki igazgató és a cég egyik alapítója, éjjel-nappal azon dolgozom, hogy kitaláljam, hogyan lehetne növelni a production elérhetőségét, egyszerűsíteni a működtetését, megkönnyíteni az adminok életét, és a fejlesztők életét kellemesebbé tenni.
A Kubernetesről
— Az utóbbi időben sok előadást látok a "Flant"-tól Kubernetesről. Hogyan jutottatok el hozzá?
Dmitrij: Már sokszor meséltem erről, de egyáltalán nem sajnálom, hogy megismétlem. Úgy vélem, fontos ezt a témát újra és újra felhozni, mert zűrzavar alakulhat ki az ok és okozat között.
Szükségünk volt egy eszközre. Számos problémával szembesültünk, küzdöttünk, és különböző megoldásokkal próbáltuk túllépni őket. Sok lehetőséget átnéztünk, saját megoldásokat alakítottunk ki, tapasztalatokat gyűjtöttünk. Fokozatosan oda jutottunk, hogy a Docker-t majdnem azonnal elkezdtük használni, amint megjelent - körülbelül 2013 körül. Amikor megjelent, már volt sok tapasztalatunk a tárolókkal, már írtunk egy Docker-hez hasonló megoldást - saját kis javításokat Pythonban. A Docker megjelenésével lehetővé vált, hogy ezeket a javításokat félretegyük, és egy megbízható, a közösség által támogatott megoldást használjunk.
A Kubernetes esetében hasonló a helyzet. Amikor elkezdett valóban terjedni - számunkra ez az 1.2-es verzió -, már volt egy csomó javításunk Shell-ben és Chef-ben, amikkel próbáltuk orchestrálni a Docker-t. Komolyan néztük a Ranchert és más megoldásokat, de megjelent a Kubernetes, ami pontosan úgy van megvalósítva, ahogy mi csinálnánk, vagy még annál is jobban. Semmi kivetnivaló nincs rajta.
Igen, itt van néhány hiányosság, ott valami hiányzik - sok a befejezetlen dolog, és az 1.2-es verzió igazán rémes, de... A Kubernetes egy építkező épület - nézed a projektet és látod, hogy ez klassz lesz. Ha az épületnek már van alapja és két szintje, akkor tudod, hogy jobb, ha még nem költözöl be, de a szoftvereknél ilyen problémáink nincsenek - már használható.
Soha nem volt olyan pillanat, amikor azon gondolkodtunk, hogy használjuk-e a Kubernetest, vagy sem. Már régóta vártuk, mielőtt megjelent, és próbáltunk saját alternatívákat megalkotni.
Kubernetes körül
- Közvetlenül részt vesznek a Kubernetes fejlesztésében?
Dmitrij: Közvetve. Inkább az ökoszisztéma fejlődésében veszünk részt. Küldünk egy bizonyos számú pull requestet: a Prometheus-ba, különböző operátorokhoz, a Helm-be - az ökoszisztémába. Sajnos nem vagyok abban a helyzetben, hogy mindent nyomon kövessek, amit csinálunk, és tévedhetek, de tőlünk nincs egyetlen pull sem a kernelben.
- Ekközben sok saját eszközt is fejlesztenek a Kubernetes körül?
Dmitrij: A stratégia az, hogy megyünk, és pull requestelünk mindenbe, ami már létezik. Ha ott nem fogadják el a pull requesteket, egyszerűen fork-oljuk magunknak, és élünk, amíg el nem fogadják a buildjeinket. Aztán, amikor ez eljut a upstream-hez, visszatérünk az upstream verzióhoz.
Például van egy Prometheus-operatorunk, amellyel már ötször váltogattunk az upstream verziónk között. Szükségünk van egy funkcióra, küldtünk egy pull requestet, ezt holnap szeretnénk kiadni, de nem akarjuk megvárni, amíg az upstreamben megjelenik. Ezért saját magunknak összerakjuk, kiadjuk a saját verziónkat a szükséges funkcióval, minden kluszterünkre. Aztán ez például az upstreamben visszaérkezik hozzánk azzal, hogy: „Srácok, csináljuk meg általánosabb esetben”, amit mi, vagy valaki más befejezünk, és idővel ismét integráljuk.
Minden, ami létezik, fejlesztésre vár.Sok olyan elem van, amely még nincs, még nem találták ki, vagy kigondolták, de nem valósították meg – mi ezeket elkészítjük. Nem azért, mert szeretjük a folyamatot vagy a kerék újra feltalálását 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, miért készítettük el ezt vagy azt? A válasz egyszerű – mert előre akartunk lépni, megoldani egy gyakorlati problémát, és ezt az eszközt használtuk a megoldására.
Az út mindig ilyen: nagyon alaposan keresünk, és ha nem találunk megoldást arra, hogyan lehet a kenyérszeletből troli buszt készíteni, akkor megcsináljuk a saját kenyérszeletünket és saját troli buszunkat.
A Flant eszközei
Tudomásom szerint a Flant-nak vannak addon-operatorai, shell-operatorai és dapp/werf eszközei. Ahogy értem, ezek ugyanaz az eszköz különböző megvalósításokban. Azt is értem, hogy a Flanton belül sok különböző eszköz létezik. Ez így van?
Dmitrij: A GitHubunkon még sok más dolog is van. Amit most fel tudok idézni, az a statusmap – egy Grafana panel, amely mindenkinek tetszik. Majdnem minden második cikkben említik a Kubernetes monitorozásáról a Mediumon. Röviden lehetetlen elmagyarázni, hogy mi a statusmap – ehhez külön cikk kell, de ez nagyon hasznos dolog az időbeli státusz monitorozásához, mivel a Kubernetesben gyakran szükségünk van az időbeli státusz megjelenítésére. Továbbá van egy LogHouse-unk – ez egy ClickHouse-alapú eszköz, ami fekete mágiával gyűjti a Kubernetes naplókat.
Sok segédprogram! És még több jön, mert idén néhány belső megoldást fogunk kiadni. Az addon-üzemeltetők alapján rengeteg addon van a Kuberneteshez, például, hogyan állítsuk be helyesen a sert manager-t – egy tanúsítványkezelő eszközt, hogyan állítsuk be a Prometheust sok kiegészítővel – ez húsz különböző bináris, amelyek adatokat exportálnak és valamit gyűjtenek, ehhez a Prometheushoz pedig csodálatos grafika és riasztások kapcsolódnak. Ez mind rengeteg addon a Kuberneteshez, amelyek a klaszterbe telepíthetők, és így egyszerűből egy menő, automatikus megoldás válik, ahol sok kérdés már meg van oldva. Igen, sok mindent csinálunk.
Az ökoszisztéma fejlődése
– Számomra úgy tűnik, hogy ez egy nagyon nagy hozzájárulás ennek az eszköznek és a használati módszereinek fejlesztéséhez. Meg tudnád becsülni, ki lenne még, aki hasonlóan hozzá tudna járulni az ökoszisztéma fejlődéséhez?
Dmitrij: Oroszországban a piacon működő cégek közül – senki sem közelít. Természetesen, ez egy hangzatos kijelentés, mert vannak nagy szereplők, mint a Mail és a Yandex – ők is foglalkoznak a Kubernetes-szel, de még ők sem közelítettek meg a világban működő cégek hozzájárulásának szintjét, amelyek sokkal többet csinálnak, mint mi. Nehéz összehasonlítani a "Flant"-ot, egy 80 fős létszámú csapatot a Red Hat-tel, ahol csak egy Kubernetesre 300 mérnök dolgozik, ha nem tévedek. Nehéz az összehasonlítás. Az RnD osztályunkban 6 ember van, beleértve engem is, akik kidolgozzák az összes eszközünket. 6 ember 300 Red Hat mérnök ellen – ez elég nehezen összehasonlítható.
– Mégis, amikor ezek a 6 ember valóban hasznos és átadható dolgot tudnak létrehozni, amikor szembesülnek egy gyakorlati feladattal, és megoldást adnak a közösségnek – ez egy érdekes eset. Megértem, hogy a nagy technológiai cégekben, ahol saját fejlesztéssel és Kubernetes támogató csapattal rendelkeznek, hasonló eszközöket fejleszthetnek. Ez példa a számukra arra, hogy mit lehet kifejleszteni és a közösségnek adni, hogy lendületet adjanak az egész Kubernetes közösségnek.
Dmitrij: Valószínűleg ez az integrátor trükkje, a sajátossága. Sok projektünk van, és sok különböző helyzettel találkozunk. Számunkra a hozzáadott érték létrehozásának fő módja az, hogy elemezzük ezeket az eseteket, megkeressük a közös pontokat, és a lehető legolcsóbban megoldjuk őket. Ezt aktívan csináljuk. Nehéz beszélni Oroszországról és a világról, de körülbelül 40 DevOps mérnökünk van a cégben, akik Kubernetes-szel foglalkoznak. Nem hiszem, hogy Oroszországban sok olyan cég lenne, amely összehasonlítható számú szakemberrel rendelkezik, akik értik a Kubernetes-t, ha egyáltalán vannak ilyenek.
Tudom, hogy mi a DevOps mérnök név értelme, mindenki tudja, és megszokták hívni a DevOps mérnököket DevOps mérnököknek, ezt nem fogjuk megvitatni. Ezek a 40 csodálatos DevOps mérnök minden nap problémákkal találkoznak és megoldják őket, mi csak elemezzük ezt a tapasztalatot, és próbálunk általánosítani. Tudjuk, hogy ha ez benne marad nálunk, akkor egy éven vagy két éven belül az eszköz haszontalanná válik, mert valahol a közösségben megjelenik egy kész eszköz. Nincs értelme ezt a tapasztalatot bent felhalmozni - ez csak az erőink és időnk lefolyása a dev/null-ba. Így hát számunkra ez egyáltalán nem fáj. Nagy örömmel publikálunk mindent, és tudjuk, hogy ezt közzé kell tenni, fejleszteni, népszerűsíteni, hogy az emberek használják és hozzáadják a saját tapasztalataikat - akkor minden növekszik és él. Akkor két év múlva az eszköz nem megy a szemétbe. Nem sajnálom tovább invesztálni az erőinket, mert látom, hogy valaki használja az eszközünket, és két év múlva már mindenki használja.
Ez a nagy stratégiánk része a dapp/werf kapcsán.. Nem emlékszem, mikor kezdtük el csinálni, talán három éve. Eredetileg teljesen shellen volt. Ez egy szuper proof of concept volt, megoldottuk néhány saját problémánkat - sikerült! De a shell-lel ott vannak a problémák, ezt tovább növelni lehetetlen, shellen programozni - az egy igazi feladat. Szokásunk volt Ruby-ban írni, így aztán Ruby-ban valamit átírtunk, fejlesztettük, fejlesztettük, fejlesztettük, és eljutottunk oda, hogy a közösség, a tömeg, aki nem mondja, hogy „mi akarjuk vagy nem akarjuk”, elutasítja a Ruby-t, bármennyire is vicces. Rájöttünk, hogy ezt a jó dolgot Go-ban kell írni, hogy megfeleljünk az ellenőrző lista első pontjának: A DevOps eszköznek statikus binárisnak kell lennie.. A Go-val vagy anélkül nem annyira fontos, de jobb egy statikus bináris, ami Go-ban készült.
Erőfeszítéseket tettünk, újraírtuk a dapp-ot Go-ban, és named werf-nak. A dapp már nem támogatott, nem fejlesztették, csak egy régebbi verzióban működik, de van abszolút frissítési út felfelé, amit követni lehet.
Miért készült a dapp
— El tudnád mondani röviden, miért készült a dapp, milyen problémákat old meg?
Dmitrij: Az első ok a build. Kezdetben komoly problémáink voltak a buildeléssel, amikor a Docker még nem tudott multi-stage-et, és mi saját erőnkből készítettük el a multi-stage-et. Aztán sok kérdés merült fel a képek tisztításával kapcsolatban. Mindenki, aki CI/CD-t végez, előbb-utóbb szembesül azzal a problémával, hogy rengeteg összegyűjtött kép van, és valahogy meg kell tisztítani azt, amire nincs szükség, és megtartani azt, amire szükség van.
A második ok a deploy. Igen, van Helm, de ez csak részben oldja meg a feladatokat. Hihetetlen, de le van írva, hogy "Helm – a csomagkezelő Kuberneteshez”. Pontosan, hogy „a”. Vannak még a „csomagkezelő” szavak – milyen elvárásunk van általában a csomagkezelőtől? Azt mondjuk: „Csomagkezelő – állítsd be a csomagot!” és elvárjuk, hogy azt mondja: „A csomagot beállították”.
Érdekes, hogy azt mondjuk: „Helm, állítsd be a csomagot”, de amikor válaszol, hogy beállította, kiderül, hogy csak az installálást kezdte el – megmondta a Kubernetesnek: „Ezt a dolgot futtasd!”, és hogy ez elindult-e vagy sem, működik-e vagy nem, a Helm ezt a kérdést egyáltalán nem oldja meg.
Tehát kiderül, hogy a Helm csak egy szöveges előfeldolgozó, ami adatokat tölt be a Kubernetesbe.
De bármilyen deploy keretében szeretnénk tudni – a alkalmazás kikerült a produkcióba vagy sem? A produkcióba való kikerülés azt jelenti, hogy az alkalmazás ott van, települt egy új verzió, és legalább nem omlik össze és helyesen válaszol. A Helm ezt a feladatot egyáltalán nem oldja meg. Ennek megoldásához sok energiát kell fordítani, mivel utasítanunk kell a Kubernest, hogy telepítse a dolgot és figyeljük, hogy mi történik – települt-e vagy sem. És még sok feladat van, ami a deploy-hoz, tisztításhoz és buildeléshez kapcsolódik.
Tervek
Még ebben az évben áttérünk a helyi fejlesztésre. A célunk az, hogy elérjük azt az állapotot, amit korábban a Vagrant-tel tapasztaltunk — beírtuk a «vagrant up» parancsot, és azonnal elindultak a virtuális gépek. Azt szeretnénk, hogy legyen egy projekt a Git-ben, ahol csak annyit írunk, hogy «werf up», és ez felállítja a projekt helyi másolatát, amely egy helyi mini-Kubban fut, és minden fejlesztéshez szükséges mappa csatlakozik. A fejlesztési nyelvtől függően ez különböző módon történik, ugyanakkor fontos, hogy kényelmesen tudjuk végezni a helyi fejlesztést a csatolt fájlokkal.
A következő lépés számunkra az, hogy komolyan befektessünk a fejlesztők kényelmébe. Olyan eszközre van szükségünk, amellyel gyorsan elindítható a projekt helyben, lehet fejleszteni, majd Git-be tolni, és pontosan ugyanazzal az eszközzel kerül a stage-re vagy a teszteléshez, a pipeline-oknak megfelelően, majd ugyanezzel az eszközzel végül élesbe megy. Ez az egység, egységesítés és a helyi környezettől az éles környezetig terjedő infrastruktúra reprodukálhatósága számunkra nagyon fontos szempont. De ezt egyelőre nem tudjuk megvalósítani a werf-ben — ezt most tervezzük.
De a dapp/werf útja mindig is olyan volt, mint a Kubernetes esetében az elején. Problémákkal szembesültünk, megoldásokat kerestünk — kitaláltunk magunknak valamilyen shell megoldásokat, bármin is. Aztán ezeket a megoldásokat próbáltuk valahogy racionalizálni, általánosítani és konszolidálni bináris állományokba, amelyeket egyszerűen megosztunk.
Van egy másik nézőpont is az egész történetre, analógiákkal.
A Kubernetes olyan, mint egy autó váza motorral. Nincsenek ajtók, üvegek, rádió, fenyőfa — tényleg semmi. Csak a keret és a motor. És van a Helm — ez a kormány. Jó, van kormány, de szükség van még a kormánytengelyre, a kormányoszlopra, a váltóra és a kerekekre, és ezek nélkül nem működik.
A werf esetében ez még egy komponens a Kuberneteshez. Mostanra a legújabb werf alfa verzióban például a Helm teljes mértékben be van építve a werf-be, mert elegünk lett abból, hogy ezt magunknak kell megoldani. Számos okunk van erre, részletesen elmondom, miért építettük be a helm-et teljes egészében a tiller-rel együtt a werf-be a .
Most recently, werf has become a more integrated component. We now have a ready-made helm, a steering pin—I'm not very knowledgeable about cars, but this is a large block that addresses quite a wide range of tasks. We don't have to dig through the catalog to find one part to match another or think about how to screw them together. We get a complete unit that solves a large set of issues right away. However, it’s built from the same open-source components; it still uses Docker for builds, Helm for part of the functionality, and there are a few other libraries involved. It's an integrated tool to quickly and easily obtain a great CI/CD right out of the box.
Is it difficult to maintain Kubernetes?
— You talk about your experience that you started using Kubernetes; it's like a frame, an engine, and you can attach many different things to it: a body, a steering wheel, pedals, seats. The question arises—how difficult is it for you to maintain Kubernetes? You have extensive experience; how much time and resources do you spend specifically on maintaining Kubernetes apart from everything else?
Dmitrij: This is a very complex question, and to answer it, we need to understand what support means and what we want from Kubernetes. Could you elaborate?
— As far as I know and as I see, many teams want to try Kubernetes now. Everyone is jumping into it and setting it up on their knees. I have the feeling that people do not always understand the complexity of this system.
Dmitrij: That's true.
— How difficult is it to install Kubernetes from scratch to make it production ready?
Dmitrij: What do you think, how hard is it to perform a heart transplant? I understand, it’s a compromising question. Using a scalpel and not making a mistake isn't that difficult. If you are told where to cut and where to sew, the procedure itself isn’t challenging. The difficulty lies in ensuring that it succeeds every time.
Installing Kubernetes and getting it to work is easy: boom!—it’s installed, there are plenty of installation methods. But what happens when issues arise?
Questions always come up—what have we not taken into account? What have we not done? What parameters of the Linux kernel did we specify incorrectly? Oh dear, did we even specify them at all?! What Kubernetes components did we install and which ones did we miss? Thousands of questions arise, and to answer them, you need 15-20 years of immersion in this industry.
Van egy friss példám erről a témáról, amely átfogóbbá teheti a kérdést: "Mennyire nehéz Kubernetes-t fenntartani?" Néhány hónappal ezelőtt komolyan fontolgattuk, hogy érdemes lenne-e bevezetni a Cilium-ot mint hálózatot Kubernetes-ben.
Elmagyarázom, mi is az a Cilium. A Kubernetes-ben számos különböző hálózati alrendszer megvalósítás létezik, és az egyik legmenőbb a Cilium. Mi a lényege? A kernelben nemrég lehetőség nyílt arra, hogy hook-okat írjunk, amelyek valamilyen módon beavatkoznak a hálózati alrendszerbe és különböző más alrendszerekbe, és lehetővé teszik, hogy megkerüljük a kernel nagy részeit.
A Linux kernel történelmileg rendelkezik ip rout-tal, netfilter-rel, bridge-ekkel és sok más régi komponenssel, amelyek 15, 20, 30 évesek. Összességében működnek, minden rendben van, de manapság túl sok konténert hoztak létre, és ez olyan, mint egy 15 téglából álló torony, amelyen egy lábon állsz – furcsa érzés. Ez a rendszer történelmileg sok finomsággal fejlődött, mint egy vak appendikx a szervezetben. Néhány helyzetben teljesítmény problémák merülnek fel.
Van egy csodálatos BPF és a lehetőség, hogy hook-okat írjunk a kernelhez – a srácok írtak saját hook-jaikat a kernelhez. A csomag beérkezik a Linux kernelbe, ők a belépési ponton kiemelik, úgy dolgozzák fel, ahogy akarják, bridge-ek, TCP, IP stack nélkül – röviden, megkerülve mindent, ami a Linux kernelben van, és azonnal kiadja a konténernek.
Mi az eredmény? Nagyon jó teljesítmény, szuper funkciók – egyszerűen fantasztikus! De nézzük ezt, és azt látjuk, hogy minden gépen van egy program, amely csatlakozik a Kubernetes API-jához, és az API-ból kapott adatok alapján C kódot generál és binárisokat fordít, amelyeket a kernelbe tölt be, hogy ezek a hook-ok a kernel space-ben működjenek.
Mi lesz, ha valami elromlik? Nem tudjuk. Ahhoz, hogy ezt megértsük, el kell olvasnunk az összes kódot, és át kell látnunk az egész logikát, ami iszonyúan bonyolult. De másrészt ott vannak ezek a bridge-ek, netfilter-ek, ip rout-ok – én nem olvastam az eredeti forrást, és a vállalatunkban dolgozó 40 mérnök sem. Talán néhány részletet néhányan értenek.
És mi a különbség? Úgy tűnik, hogy van IP route, Linux kernel, és van egy új eszköz - mi a különbség, egyikünket sem érti. De félünk használni az újat - miért? Mert ha az eszköz 30 éves, akkor 30 év alatt minden hibát megtaláltak, minden csapdába beleléptek és nem kell mindent tudni - működik, mint egy fekete doboz, és mindig működik. Mindenki tudja, hogy milyen diagnosztikai csavarhúzót hova dugjon, mikor indítson TCP dump-ot. Mindenki jól ismeri a diagnosztikai segédprogramokat és érti, hogyan működik ez az alkatrészhalmaz a Linux kernelen - nem, hogy hogyan van felépítve, hanem hogyan kell használni.
Az állati klassz Cilium nem 30 éves, még nem érett meg. A Kubernetes-szel ugyanaz a probléma, egy másolat. Akár a Cilium, akár a Kubernetes, mindkettő tökéletesen telepíthető, de amikor valami nem megy jól a termelésben, képesek leszünk kritikus helyzetben gyorsan megérteni, hogy mi ment rosszul?
Amikor arról beszélünk, hogy bonyolult-e karbantartani a Kubernetest - nem, nagyon egyszerű, és igen, hihetetlenül nehéz. A Kubernetes remekül működik önmagában, de egy milliárd nüansszal.
A "Szerencsém lesz" megközelítésről
- Vannak olyan cégek, ahol ezek a nüanszok szinte garantáltan felmerülnek? Tegyük fel, hogy a Yandex hirtelen minden szolgáltatását átkonfigurálja Kubernetesre, ott óriási terhelés lesz.
Dmitrij: Nem, ez nem a terhelésről szól, hanem a legegyszerűbb dolgokról. Például, van Kubernetesünk, telepítettük oda az alkalmazást. Hogyan tudjuk, hogy működik? Kész eszköz, amivel megérthetjük, hogy az alkalmazás nem esik össze, egyszerűen nincs. Kész rendszer, ami figyelmeztetéseket küld - nincs, ezeket a figyelmeztetéseket és minden grafikont be kell állítani. És mi frissítjük a Kubernetest.
Van egy Ubuntu 16.04. Mondhatjuk, hogy ez egy régi verzió, de még mindig azt használjuk, mert LTS. Ott van systemd, aminek az a sajátossága, hogy nem tisztítja meg a C-csoportokat. A Kubernetes indítja a podokat, létrehozza a C-csoportokat, majd eltávolítja a podokat, és valahogy így alakul ki – nem emlékszem a részletekre, elnézést – hogy a systemd szeletek maradnak. Ez idővel ahhoz vezet, hogy bármelyik gép elkezd lassulni. Ez még csak nem is a highload kérdése. Ha folyamatosan futnak podok, például, ha van egy cron feladat, ami folyamatosan podokat generál, akkor az Ubuntu 16.04-es gép egy hét után lassulni kezd. Folyamatosan magas load average lesz a sok létrehozott C-csoport miatt. Ez egy probléma, amivel bárki szembesül, aki csak telepít egy Ubuntu 16-ot, és arra felmegy a Kubernetes.
Tegyük fel, hogy valahogy frissíti a systemd-t vagy valami mást, de a Linux kernelben a 4.16-ig még viccesebb a helyzet – a C-csoportok eltávolításakor a kernelben szivárognak, és valójában nem távolítják el őket. Ezért egy hónap működés után szinte lehetetlenné válik a statisztikák megtekintése a podok memóriájáról. Kiveszünk egy fájlt, futtatjuk a programban, és egy fájl feldolgozása 15 másodpercig tart, mert a kernel nagyon sokáig számolja a magában lévő millió C-csoportot, amelyek látszólag eltávolításra kerültek, de valójában nem – szivárognak.
Ilyen kis apróságokból még mindig nagyon sok van itt-ott. Ez nem olyan kérdés, amivel a nagy cégek néha szembesülhetnek nagyon nagy terhelés alatt – nem, ez napi problémák kérdése. Az emberek hónapokig élhetnek így – telepítették a Kubernetest, deployálták az alkalmazást – látszólag működik. Sokan így érzik jól magukat. Arról, hogy ez az alkalmazás egyszer csak valamiért le fog állni, egyáltalán nem értesülnek, az értesítés nem érkezik, de ez számukra normális. Régebben virtuális gépeken éltek monitorozás nélkül, most a Kubernetestre költöztek, szintén monitorozás nélkül – mi a különbség?
A kérdés az, hogy amikor a jégen sétálunk, soha nem tudjuk, milyen vastag, ha nem mértük meg előre. Sokan sétálnak, és nem aggódnak, mert korábban is sétáltak.
Az én véleményem szerint a bármilyen rendszer üzemeltetésének árnyalata és nehézsége abban rejlik, hogy garantálni tudjuk, hogy a jég vastagsága pontosan elegendő lesz a feladataink megoldásához. Erről van szó.
Az IT világában úgy érzem, túl sok "szerencsés" megközelítés van. Sokak szoftvert telepítenek, programkönyvtárakat használnak a reménykedés reményében, hogy szerencséjük lesz. Összességében sokaknak szerencséje van. Valószínűleg ez az oka annak, hogy működik.
— A pesszimista véleményem szerint ezt így látom: amikor a kockázatok nagyok, és az alkalmazásnak működnie kell, akkor támogatásra van szükség a "Flant"-tól, esetleg a Red Hat-től, vagy egy belső csapatra van szükség, amely kifejezetten a Kubernetesre van kijelölve, és készen áll arra, hogy fenntartsa azt.
Dmitrij: Objektíven igaz ez. Egy kis csapatnak önállóan belemerülni a Kubernetes történetébe bizonyos kockázatokkal jár.
Szükségünk van konténerekre?
— Tudnál mesélni arról, hogy mennyire elterjedt a Kubernetes Oroszországban?
Dmitrij: Nincsenek adataim erről, és nem vagyok biztos benne, hogy bárkinek is vannak. Azt mondjuk: "Kubernetes, Kubernetes", de más nézőpont is létezik erre a kérdésre. A konténerek elterjedtségéről sem tudom, de tudom, hogy van egy szám az internetes jelentésekben, miszerint a konténerek 70%-át a Kubernetes irányítja. Ez egy megbízható forrás volt, elég nagy mintával a világban.
A következő kérdés az, hogy szükségünk van-e konténerekre? Személyes érzésem és a "Flant" vállalat általános véleménye az, hogy a Kubernetes a de facto szabvány.
Semmi más nem lesz, csak Kubernetes.
Ez egy abszolút game-changer az infrastruktúra kezelés területén. Egyszerűen abszolút — vége a többi Ansible, Chef, virtuális gép és Terraform; már nem is beszélek a régi, elavult módszerekről. A Kubernetes abszolút changer, és mostantól ez lesz.
Nyilvánvaló, hogy valakinek pár évre, másoknak meg akár évtizedekre van szüksége, hogy ezt tudomásul vegye. Nincs kétségem afelől, hogy nem lesz más, csak Kubernetes és ez az új nézőpont: nem bántjuk tovább az operációs rendszert, hanem felhasználjuk infrastructure as code, csak nem kódként, hanem yml formátumban — deklaratívan leírt infrastruktúrával. Úgy érzem, hogy ez mindig így lesz.
— Tehát azok a cégek, amelyek még nem váltottak Kubernetesre, biztosan áttérnek rá, vagy elfeledésbe merülnek. Jól értelek?
Dmitrij: Ez sem teljesen helyes. Például, ha az a feladatunk, hogy elindítsunk egy dns-szervert, azt FreeBSD 4.10-en tudjuk futtatni, és akár 20 évig is tökéletesen működhet. Csak működni fog, semmi más. Lehet, hogy 20 év alatt egyszer lesz szükség valami frissítésre. Ha a szoftverről beszélünk úgy, hogy elindítottuk, és valójában sok éven át működik frissítések, változtatások nélkül, akkor természetesen ott nem lesz Kubernetes. Nincs rá szükség.
Minden, ami a CI/CD-vel kapcsolatos - mindenhol, ahol folyamatos szállítás szükséges, ahol verziót kell frissíteni, aktív változtatásokra van szükség, ahol ki kell alakítani a hibatűrést - csak Kubernetes.
A mikroszolgáltatásokról
– Itt nekem egy kis disszonancia merül fel. A Kubernetes működtetéséhez külső vagy belső támogatás szükséges - ez az első szempont. A második - amikor csak most kezdjük a fejlesztést, mi egy kis startup vagyunk, még semmink sincs, a Kubernetes alatti fejlesztés vagy egyáltalán a mikroszolgáltatás-architektúra használata nehéz lehet, és nem mindig indokolt gazdaságilag. Érdekel a véleményed - szükséges-e a startupoknak az elejétől fogva a Kubernetesre írni, vagy lehet-e először monolitot írni, és csak utána áttérni a Kubernetesre?
Dmitrij: Nagyszerű kérdés. Van egy előadásom a mikroszolgáltatásokról. Sokszor találkoztam azzal, hogy az emberek mikroszkóppal próbálnak szöget beverni. Maga a megközelítés helyes, mi is pontosan így tervezzük a belső szoftverünket. De amikor ezt csinálod, pontosan tudnod kell, mit csinálsz. A mikroszolgáltatásokban legjobban a «mikro» szót utálom. Történelmileg alakult így, hogy ez a kifejezés létrejött, és valamiért az emberek azt hiszik, hogy a mikro - ez nagyon kicsi, egy milliméternél is kisebb, mint a mikrométer. Ez nem így van.
Például van egy monolit, amelyet 300 ember ír, és mindenki, aki részt vett a fejlesztésben, érti, hogy ott problémák vannak, és ezt fel kellene darabolni mikroszeletekre - körülbelül 10 darabra, amit legalább 30 ember ír. Ez fontos, szükséges és klassz. De amikor egy startup jön hozzánk, ahol 3 nagyon ügyes és tehetséges srác írt a térdén 60 mikroszolgáltatást, minden alkalommal keresem a korvalolt.
Úgy tűnik, hogy erről már ezerszer beszéltek – megkaptuk a megosztott monolitot ilyen-olyan formában. Ez gazdaságilag nem indokolt, és nagyon nehéz mindent átlátni. Egyszerűen annyiszor láttam ezt, hogy már fáj, ezért továbbra is beszélek róla.
A kezdeti kérdéshez, miszerint van egy konfliktus aközött, hogy egyrészt a Kubernetes borzalmas használni, mert nem világos, hogy mi romolhat el vagy nem működhet, másrészt pedig világos, hogy minden arra megy, és semmi más, csak a Kubernetes nem lesz. A válasz – a haszon mennyiségének és a megoldható feladatok mennyiségének mérlegelése.Ez az egyik mérleg serpenyője. A másik serpenyőn pedig a leállással vagy a válaszidő, elérhetőség csökkentésével kapcsolatos kockázatok – a teljesítménymutatók csökkenése.
Itt arról van szó – vagy gyorsan haladunk, és a Kubernetes sok dolgot gyorsabban és jobban végez, vagy használjuk a megbízható, idővel bevált megoldásokat, de sokkal lassabban haladunk. Ezt a választ minden cégnek meg kell hoznia. Tekinthetjük ezt úgy, mint egy ösvényt a dzsungelben – amikor először jársz arra, találkozhatsz egy kígyóval, tigrissel vagy dühös borzzal, de amikor már 10-szer jártál arra, utat tapostál, eltávolítottad az ágakat, és könnyebben járhatsz. Minden alkalommal szélesedik az ösvény. Aztán már aszfaltozott út, később szép sugárút lesz belőle.
A Kubernetes nem áll meg. Ismét egy kérdés: a Kubernetes, egyrészt, 4-5 bináris, másrészt ez az egész ökoszisztéma. Ez az operációs rendszer, ami a gépeinken fut. Mi ez? Ubuntu vagy Curios? Ez a Linux kernel, rengeteg további komponenssel. Ezek a dolgok itt egy mérgező kígyót eltüntettek az útról, ott kerítést állítottak. A Kubernetes nagyon gyorsan és dinamikusan fejlődik, és a kockázatok mennyisége, az ismeretlen mértéke hónapról hónapra csökken, és ennek megfelelően ezek a mérlegek újra kiegyensúlyozódnak.
Ha azt kérdezed, mit tegyen egy startup, azt mondanám – gyere a „Flant”-hoz, fizesd ki a 150 ezer rubelt és kapj egy DevOps easy service-t kulcsrakész formában. Ha te egy kis startup vagy néhány fejlesztővel – működik. Ahelyett, hogy saját DevOps-ot alkalmaznál, akinek meg kell tanulnia a problémáid megoldását és közben fizetned kellene neki, te minden kérdésre kulcsrakész megoldást kapsz. Igen, vannak hátrányai is. Mint outsourcer, nem tudunk annyira belemerülni és gyorsan reagálni a változtatásokra. De cserébe rengeteg szakértelemmel rendelkezünk, felkészült gyakorlataink vannak. Garantáljuk, hogy bármilyen helyzetben mi gyorsan rájövünk mindenre és felemelünk bármilyen Kubernetes-t onnan, ahonnan csak kell.
Kategórikusan ajánlom az outsourcingot a startupoknak és a bejáratott vállalkozásoknak addig, amíg el nem érik azt a méretet, amikor már tudnak egy 10 fős csapatot fenntartani az üzemeltetésre, mert különben nincs értelme. Kategórikusan érdemes outsourcolni.
Amazonról és Googleról
– Lehetséges-e az Amazon vagy a Google megoldásait outsourcingként értékelni?
Dmitrij: Igen, természetesen, ez megold néhány kérdést. De újra vannak nuanszok. Mindig is érteni kell, hogyan kell ezt használni. Például az Amazon AWS működésében számos apróság van: a Load Balancer-t elő kell melegíteni vagy előzetesen be kell nyújtani a kérelmet, hogy „haverok, fogunk kapni forgalmat, melegítsétek be a Load Balancer-t!” Ezeket a részleteket tudni kell.
Amikor szakemberekhez fordulsz, szinte minden tipikus ügyet gyorsan megoldasz. Jelenleg 40 mérnökünk van, év végére valószínűleg 60 lesz – ezekkel a dolgokkal biztosan szembesültünk már. Még ha egy projekt keretében újra bátran szembesülünk is ezzel a problémával, már gyorsan kérdezünk egymástól és tudjuk, hogyan kell megoldani.
Valószínűleg a válasz az, hogy természetesen a hosztolt történetek megkönnyítik a dolgok egy részét. A kérdés az, hogy készen állsz-e bízni ezekben a hoszterekben, és megoldják-e a problémáidat. Az Amazon és a Google jól teljesítettek. Minden esetünkben – ez biztos. További pozitív tapasztalataink nincsenek. Az összes többi felhőszolgáltatás, amellyel próbáltunk dolgozni, rengeteg problémát okozott – és az Ager, valamint minden, ami Oroszországban létezik, és mindenféle OpenStack különböző megvalósításai: Headster, Overage – mind, amit akarsz. Ezek mind problémákat okoznak, amelyekkel nem akarunk foglalkozni.
Ezért a válasz – igen, de valójában érett hosztolt megoldásból nem sok van.
Kinek szükséges a Kubernetes?
— De kinek is szükséges a Kubernetes? Ki az, aki már át kellene álljon a Kubernetesre, ki az a tipikus "Flant" ügyfél, aki éppen a Kubernetes miatt jön hozzánk?
Dmitrij: Érdekes kérdés, mert jelenleg, amikor a Kubernetes népszerűsége éppen felfelé ível, sokan érkeznek hozzánk: "Fiúk, tudjuk, hogy Kubernetes-t csináltok, készítsetek nekünk!". Mi azt válaszoljuk: "Uraim, mi nem készítjük a Kubernetes-t, mi produkcióban dolgozunk, és minden, ami ezzel kapcsolatos." Mert a produkció megvalósítása anélkül, hogy az egész CI/CD-t megcsinálnánk, manapság egyszerűen lehetetlen. Mindenki elhagyta azt a felosztást, hogy a fejlesztés fejlesztés, és az üzemeltetés üzemeltetés.
Ügyfeleink különböző dolgokat várnak, de mindenki valamilyen jó csodára is vár, hogy vannak bizonyos problémáik, és most hopp! — a Kubernetes megoldja ezeket. Az emberek hisznek a csodákban. Ésszel értik, hogy csoda nem létezik, de a lelkük mélyén reménykednek — hátha ez a Kubernetes most mindent megold számunkra, annyit beszélnek róla! Hát, hátha most — pff! — az ezüst golyó, pff! — és 100% uptime-ot kapunk, minden fejlesztő akár 50-szer is kiadhat bármilyen frissítést a produkcióra, és az nem fog leállni. Összességében, csoda!
Amikor ilyen emberek jönnek hozzánk, azt mondjuk: "Sajnálom, de csoda nem létezik." Ahhoz, hogy egészséges legyél, jól kell táplálkoznod és sportolnod. Ahhoz, hogy megbízható produkciót kapj, azt megbízhatóan kell elkészíteni. Ahhoz, hogy kényelmes CI/CD-t kapj, azt ilyenné kell tenni. Ez egy csomó munka, amit el kell végezni.
Válaszolva a kérdésre, kinek szükséges a Kubernetes — a Kubernetes senkinek sem szükséges.
Néhány embernek téves érzése van, hogy szüksége van a Kubernetesre. Az embereknek szükségük van arra, hogy teljesen megszabaduljanak az infrastruktúra és az alkalmazásaik indításával kapcsolatos problémáik gondolkodásától, foglalkozásától, érdeklődésétől. Azt akarják, hogy az alkalmazások egyszerűen működjenek és egyszerűen telepíthetők legyenek. Számukra a Kubernetes a remény, hogy véget ér a beszéd arról, hogy "ott heverésztünk", vagy "nem tudunk kiadni", vagy valami hasonló.
Általában a technikai igazgató érkezik hozzánk. Két dolgot kérdeznek tőle: egyrészt, hogy adjon nekik funkciókat, másrészt pedig, hogy biztosítsa a stabilitást. Mi azt javasoljuk, hogy vegyék át tőlünk ezt a terhet és végezzük el. Az ezüst golyó, pontosabban az ezüsttel bevont, az, hogy többé nem kell gondolkodnod ezekről a problémákról és időt pazarolnod. Lesznek speciális emberek, akik ezt a kérdést rendezni fogják.
Az a megfogalmazás, hogy nekünk vagy másnak szüksége van Kubernetesre, helytelen.
A Kubernetesre az adminisztrátoroknak nagy szüksége van, mert ez egy nagyon érdekes játékszer, amivel lehet játszani, kutatni. Legyünk őszinték – mindenki szereti a játékokat. Mindannyian valahol gyerekek vagyunk, és amikor meglátunk egy újat – játszani akarunk vele. Van, akit ez elriaszt, például az adminisztráció terén, mert már játszott vele és unalmassá vált, hogy egyszerűen nem akar többet. De ez senkinél sincs teljesen elfeledve. Például, ha a rendszergazdálkodás és a DevOps terén már rég unom a játékokat, akkor is szeretem őket, és újakat azért még mindig veszek. Az emberek valamilyen módon mindannyian szeretnek játékokat.
Ne játssz a produkcióval. Amit kategorikusan nem ajánlok, és amit most látok a tömegekben: „Ó, új játék!” – elkezdtek sietni megvenni, megvették és: „Most vigyük be a suliba, mutassuk meg mindenkinek”. Ne csináld ezt. Elnézést, a gyermekeim nőnek, folyamatosan látok valamit a gyerekekben, és ezt észreveszem magamban, majd ezt általánosítom másokra is.
A végső válasz: nem szükséged van Kubernetesre. Meg kell oldanod a problémáidat.
Elérhető, hogy:
- a produkció nem omlik össze;
- még ha meg is próbálna összedőlni, ezt előre tudjuk, és tudunk neki valamit alárakni;
- meg tudjuk változtatni a sebességet, ahogy a vállalkozásunk igényei megkívánják, és ezt kényelmesen tudjuk megtenni, ez nem okoz problémát számunkra.
Két valós szükséglet van: megbízhatóság és dinamikusság / rugalmasság a kiadásban. Mindazoknak, akik most IT projektekkel foglalkoznak, mindegy, melyik iparágban – a világ megkönnyítése érdekében, és akik ezt értik, meg kell oldaniuk ezeket a szükségleteket. A Kubernetes a megfelelő megközelítéssel, a megfelelő megértéssel és elegendő tapasztalattal lehetővé teszi ezek megoldását.
A serverlessről
Ha egy kicsit előre nézünk, akkor a fejfájás nélkülözésének, az infrastruktúra gyors kiadásának és az alkalmazás gyors változásának problémáit próbálva új megoldások, például a serverless is megjelenik. Érzel valamilyen potenciált ebben az irányban és, mondjuk, veszélyt a Kubernetesre és hasonló megoldásokra?
Dmitrij: Itt megint meg kell jegyezni, hogy nem vagyok jós, aki előre lát és mondja - így lesz! Pedig éppen ugyanezt csináltam. A lábam előtt nézve rengeteg problémát látok, például, hogy hogyan működnek a tranzisztorok a számítógépben. Mennyire vicces, igaz? Valamilyen hibákkal találkozunk a CPU-val.
A serverless megvalósítása elég megbízhatóan, olcsón, hatékonyan és kényelmesen megoldhatja az ökoszisztémás kérdéseket. Ebben egyetértek Elon Musk-kal, hogy szükség van egy második bolygóra, hogy biztosítsuk az emberiség hibamentességét. Bár nem tudom, mit mond, de azt értem, hogy nem vagyok kész repülni Marsra, és ez nem holnap lesz.
A serverless-ről egyértelmű, hogy ideológiailag helyes dolog, mint a hibamentesség az emberiség számára - jobb két bolygóval rendelkezni, mint egyel. De hogyan lehet ezt most megvalósítani? Egy expedíció indítása - nem probléma, ha koncentrálunk rá. Több expedíciót küldeni és több ezer embert letelepíteni, szerintem az is reális. De a teljes hibamentesség megteremtése, hogy az emberiség fele ott éljen, nekem most lehetetlennek tűnik, nem megvalósíthatónak.
A serverless éppen ilyen: klassz dolog, de távol áll a 2019-es problémáktól. Közelebb a 2030-hoz - éljünk el oda. Nem kételkedem benne, hogy el fogunk élni, mindenképpen el fogunk élni (ismételd este, mielőtt lefekszel), de most más problémákat kell megoldani. Ez olyan, mint hinni a mesebeli póniban, Rózsaszín. Igen, néhány százaléknyi eset megoldódik, és remekül megoldódik, de szubjektíven a serverless - ez egy szivárvány… Számomra ez a téma túl távoli és túl érthetetlen. Nem vagyok kész beszélni róla. 2019-ben a serverless-szel nem lehet egyetlen alkalmazást sem írni.
Hogyan fog fejlődni a Kubernetes
— Miközben elindulunk ebbe a potenciálisan csodálatos távoli jövőbe, te hogy gondolod, hogyan fog fejlődni a Kubernetes és a körülötte lévő ökoszisztéma?
DmitrijSokat gondolkodtam ezen, és egyértelmű válaszom van. Az első, hogy a stateful - a stateless számításhoz képest könnyebben megvalósítható. A Kubernetes kezdetben sok energiát fektetett ebbe, ez volt a kezdet. A stateless szinte tökéletesen működik Kubernetesben, ráadásul nem is lehet belekötni. A stateful azonban még rengeteg problémával, pontosabban részlettel küzd. Nálunk már minden tökéletesen működik, de mi vagyunk azok. Ahhoz, hogy mindenki számára működjön, még legalább pár év szükséges. Ez nem számított mutató, hanem a saját érzésem.
Röviden, a stateful nagyon jelentős fejlődés előtt áll - és fog is - mivel minden alkalmazásunk tárolja az állapotot, nem léteznek stateless alkalmazások. Ez egy illúzió, mindig szükség van valamilyen adatbázisra és még valamire. A stateful - ez az összes lehetséges javítás, a hibák helyrehozatala, az összes probléma megoldása, amivel most szembesülünk - nevezzük ezt elfogadásnak.
Az ismeretlen szintje, a megoldatlan problémák szintje, annak valószínűsége, hogy valami problémával találkozunk, jelentősen csökkenni fog. Ez egy fontos történet. És az üzemeltetők - minden, ami kapcsolódik az adminisztrációs logika kódolásához, a kezelési logikához, hogy könnyű szolgáltatást kapjunk: MySQL könnyű szolgáltatás, RabbitMQ könnyű szolgáltatás, Memcache könnyű szolgáltatás - gyakorlatilag minden olyan összetevő, amire szükségünk van, hogy garantáltan működjön a dobozból. Ez éppen azokat a fájdalmakat oldja meg, hogy szeretnénk egy adatbázist, de nem akarjuk azt adminisztrálni, vagy szeretnénk Kubernetes-t, de nem akarjuk azt adminisztrálni.
Ez a történet az üzemeltetők fejlődéséről bármely formájában fontos lesz a következő néhány évben.
Azt gondolom, hogy jelentősen növekednie kellene az üzemeltetés egyszerűségének - a doboz egyre inkább fekete lesz, egyre megbízhatóbb, egyre egyszerűbb kezelőfelületekkel.
Egyszer hallgattam egy régi interjút Isaac Asimov-val az 1980-as évekből a YouTube-on a Saturday Night Live műsorban - ez egy érdekes show, egyfajta Urgant, de érdekes. Ott kérdezték tőle a számítógépek jövőjéről. Azt mondta, hogy a jövő a egyszerűségben rejlik, ahogy ez a rádiókészülékek esetében is volt. A rádiókészülékek eredetileg bonyolult dolgok voltak. Ahhoz, hogy elkapjunk egy hullámot, 15 percig kellett tekerni a gombokat, forgatni az eszközöket, és értelmezni, hogyan működik az összes, a rádióhullámok átvitelének fizikáját. A végén a rádióban csak egy gomb maradt.
Mostanra, 2019-ben, milyen rádió van? Az autó rádiója megtalálja az összes frekvenciát és az állomások nevét. A folyamat fizikája 100 éve változatlan, de a használhatóság egyszerűsége megváltozott. Most, és nem csak most, már 1980-ban, amikor Asimov interjút adott, mindenki rádiózott és senki sem gondolkodott el azon, hogyan működik. Mindig működött – ez egy tény.
Asimov akkor azt mondta, hogy a számítógépekkel hasonlóan lesz – a használhatóság egyszerűsége növekedni fog.. Ha 1980-ban speciális képzésre volt szükség ahhoz, hogy gombokat nyomjunk a számítógépen, a jövőben ez nem így lesz.
Úgy érzem, hogy a Kubernetes és az infrastruktúra használhatósága is jelentősen növekedni fog. Ez, véleményem szerint, nyilvánvaló – a felszínen van.
Mit fognak csinálni az mérnökök?
– És mi lesz akkor az mérnökökkel, rendszergazdákkal, akik a Kubernetist karbantartják?
Dmitrij: Mi történt a könyvelőkkel az 1C megjelenése után? Körülbelül ugyanez. Korábban papíron számoltak – most már a programban. A munka termelékenysége nagyságrendekkel megnőtt, de a munka ettől még nem tűnt el. Ha régen 10 mérnök kellett egy izzó bekapcsolásához, most már elég egy.
A szoftverek és a feladatok száma, úgy érzem, jelenleg gyorsabban nő, mint ahogy új DevOps-ok jelennek meg és nő a hatékonyság. Jelenleg a piacon konkrét hiány van, ami hosszú ideig fenn fog állni. Később minden egyfajta normába fog kerülni, amelyben a munkahatékonyság növekedni fog, egyre több serverless megoldás lesz, a Kuberneteshez pedig neuralis hálózatok csatlakoznak, amelyek automatikusan kiválasztják az összes szükséges erőforrást, és mindent maguktól végeznek el, ahogy kell – az ember meg elhúzódik és nem zavar.
De a döntéseket még mindig valakinek meg kell hoznia. Nyilvánvaló, hogy ennek az embernek a szakképzettsége és szaktudása magasabb. Jelenleg a könyvelői osztályban nincs szükség 10 munkatársra, akik könyvelték a könyveket, hogy ne fáradjon el a kezük. Ez egyszerűen nem szükséges. Sok dokumentum automatikusan be van szkennelve, a elektronikus dokumentumkezelő rendszer felismeri. Elegendő egy okos főkönyvelő, aki már sokkal nagyobb készségekkel rendelkezik, és jó megértése van.
Összességében ilyen az út minden iparágban. Az autókkal is hasonló a helyzet: régen az autóhoz hozzátartozott egy autószerelő és három sofőr. Most az autóvezetés egy nagyon egyszerű folyamat, amelyben minden nap részt veszünk. Senki sem gondolkodik azon, hogy az autó valami bonyolult.
A DevOps vagy a rendszermérnökség nem tűnik el — a magas szintű hatékonyság és a munka hatékonysága növekedni fog.
— Még hallottam egy érdekes ötletet, miszerint valójában a munka mennyisége is növekedni fog.
Dmitrij: Természetesen, száz százalék! Mert a szoftver mennyisége, amit írunk, folyamatosan nő. Azok a kérdések, amelyeket a szoftver segítségével megoldunk, folyamatosan nőnek. A munka mennyisége is növekszik. Most a DevOps piaca borzasztóan túlfűtött. Ez látható a fizetési várakozásokban. Jól lenne, ha nem merülnénk a részletekbe, lennének juniorok, akik X-et akarnak, middlek, akik 1,5X-et akarnak, és szeniorok, akik 2X-et akarnak. Most azonban, ha megnézzük a moszkvai DevOps fizetéseket, a junior 1X-től 3X-ig szeretne, míg a szenior 1X-től 3X-ig.
Senki sem tudja, mennyibe kerül. A fizetések szintjét a magabiztosságod méri — teljes káosz, ha őszinte akarok lenni, borzasztóan túlfűtött piac.
Természetesen ez a helyzet nagyon hamar megváltozik — be kell következnie egy bizonyos telítettségnek. A szoftverfejlesztéssel ez nem így van — annak ellenére, hogy a fejlesztőkre szükség van, és jó fejlesztőkre is szükség van, a piac már érti, hogy ki mennyit ér — az iparág stabilizálódott. A DevOps esetében ez most nem így van.
— Az alapján, amit hallottam, arra a következtetésre jutottam, hogy a jelenlegi rendszergazdának nem kell túlzottan aggódnia, de itt az ideje fejleszteni a készségeket és felkészülni arra, hogy holnap több munka lesz, de az magasabb szaktudást fog igényelni.
Dmitrij: Száz százalék. Összességében 2019-ben élünk, és a szabály a következő: életen át tartó tanulás — egész életünkben tanulunk. Azt hiszem, mostanra ezt már mindenki tudja és érzi, de kevés a tudás — cselekedni is kell. Minden nap változnunk kell. Ha ezt nem tesszük, előbb-utóbb minket is kirúgnak a szakmánkból.
Készen kell állnod a 180 fokos hirtelen fordulatokra. Nem zárhatom ki az olyan helyzeteket, amikor valami radikálisan megváltozik, valami újat találnak ki - ilyen néha előfordul. Hopp! - és mostantól másképp cselekszünk. Fontos, hogy készen állj erre, és ne aggódj. Lehet, hogy holnap minden, amit csinálok, feleslegessé válik - semmi gond, egész életemben tanultam és készen állok valami más tanulására. Ez nem probléma. Nem érdemes félned a munkahelyi biztonságtól, de készen kell állnod arra, hogy folyamatosan új dolgokat tanulj.
Kívánságok és egy kis reklám
— Van valamilyen kívánságod?
Dmitrij: Igen, van néhány kívánságom.
Az első és anyagi jellegű - iratkozz fel . Kedves olvasók, látogassatok el a YouTube-ra és iratkozzatok fel a csatornánkra. Körülbelül egy hónap múlva aktív terjeszkedésbe kezdünk a videószolgáltatón, sok tananyagunk lesz Kubernetes-ről, nyílt és különféle: a gyakorlati dolgoktól kezdve a laboratóriumi gyakorlatokig, a mély elméleti alapelvekig és arról, hogyan alkalmazzuk a Kubernetes-t alapelvek és minták szintjén.
A második anyagi jellegű kívánság - látogassatok el a -ra és adjatok csillagokat, mert ezekből táplálkozunk. Ha nem adtok csillagokat, nem lesz mit ennünk. Ez olyan, mint a manna egy számítógépes játékban. Valamit csinálunk, csinálunk, igyekszünk, valaki azt mondja, hogy ezek szörnyű biciklik, valaki meg azt, hogy minden alapvetően helytelen, mi pedig folytatjuk, és teljesen őszintén cselekszünk. Látjuk a problémát, megoldjuk, és megosztjuk a tapasztalatainkat. Ezért adjatok nekünk csillagot, nektek nem lesz belőle hátrányotok, nekünk pedig lesz, mert ezekből élünk.
A harmadik, fontos, és már nem anyagi jellegű kívánság - ne higgyetek a mesékben. Ti profik vagytok. A DevOps egy nagyon komoly és felelősségteljes szakma. Ne játsszatok a munkahelyen. Ébredjetek rá, és meg fogjátok érteni. Képzeljétek el, hogy bemenjetek egy kórházba, és ott az orvos kísérletezik veletek. Megértem, hogy ez sokaknak fájdalmas lehet, de valószínűleg ez nem rólatok szól, hanem valaki másról. Mondjátok meg másoknak is, hogy ők is hagyják abba. Ez tényleg tönkreteszi az életünket - sokan úgy kezdik el kezelni a rendszergazdákat és a DevOps-okat, mint akiket megint elrontottak. Az a „rosszul működik” legtöbbször azért van, mert játszani kezdtünk, ahelyett, hogy hideg fejjel néztük volna, hogy itt ez van, ott meg az.
Ez nem jelenti azt, hogy ne kéne kísérletezni. Kísérletezni kell, mi is így csináljuk. Ha őszinték akarunk lenni, néha még játszunk is — ez persze nagyon rossz, de semmi emberi nem idegen számunkra. Jelentsük be, hogy 2019 a komoly, átgondolt kísérletek éve legyen, és ne a játék a produckcióban. Valószínűleg így van.
— Nagyon köszönöm!
Dmitrij: Köszönöm neked is, Vitalij, az idődet és az interjút. Kedves olvasók, nektek is köszönöm, ha egyáltalán eljutottatok eddig a pontig. Remélem, legalább pár gondolatot tudtunk nektek átadni.
Az interjúban Dmitrij a werf kérdésével foglalkozott. Most ez egy univerzális svájci bicska, amely szinte minden problémát megold. De ez nem mindig volt így. A fesztiválon Dmitrij Sztojlarov részletesen beszél erről az eszközről. A prezentációban mindenről lesz szó: a Kubernetes problémáiról és rejtett árnyoldalairól, ezek megoldásairól és a werf aktuális megvalósításáról részletesen. Csatlakozzatok május 27-én és 28-án, tökéletes eszközöket fogunk létrehozni.
Forrás: habr.com
