Laukiant Vitalijus Chabarovas apklaustas Dmitrijus Stoliarovas (), bendrovės „Flant“ techninis direktorius ir vienas iš įkūrėjų. Vitalijus paklausė Dmitrijaus apie tai, ką Flantas veikia, apie Kubernetes, ekosistemų vystymąsi, palaikymą. Aptarėme, kam reikalinga Kubernetes ir ar ji apskritai reikalinga. Taip pat apie mikropaslaugas, „Amazon AWS“, „man pasiseks“ požiūrį į „DevOps“, pačios „Kubernetes“ ateitį, kodėl, kada ir kaip ji užvaldys pasaulį, „DevOps“ perspektyvas ir kam inžinieriai turėtų pasiruošti šviesi ir netolima ateitis su supaprastinimu ir neuroniniais tinklais.
klausytis kaip podcast'o DevOps Deflop – podcast rusų kalba apie DevOps, o žemiau yra tekstinė versija.
Čia ir žemiau jis užduoda klausimus „Express42“ inžinierius.
Apie "Flantą"
- Labas, Dima. Jūs esate techninis direktorius"“, taip pat jos įkūrėjas. Papasakokite, kuo užsiima įmonė ir kuo jūs joje dirbate?
Dmitrijus: Iš išorės atrodo, kad mes esame tie vaikinai, kurie visiems diegiame Kubernetes ir ką nors su ja darome. Bet tai netiesa. Pradėjome kaip įmonė, užsiimanti Linux, tačiau labai ilgą laiką pagrindinė mūsų veikla buvo gamybos ir didelės apkrovos iki raktų projektų aptarnavimas. Dažniausiai visą infrastruktūrą statome nuo nulio, o paskui atsakome už tai ilgai, ilgai. Todėl pagrindinis darbas, kurį atlieka „Flantas“, už kurį gauna pinigų, yra atsakomybės prisiėmimas ir gamybos iki galo įgyvendinimas.
Aš, kaip įmonės technikos direktorius ir vienas iš įkūrėjų, visą dieną ir naktį stengiuosi sugalvoti, kaip padidinti gamybos prieinamumą, supaprastinti jos veikimą, palengvinti administratorių, o kūrėjų – malonesnį. .
Apie Kubernetes
– Pastaruoju metu matau daug pranešimų iš Flanto ir apie Kubernetes. Kaip tu prie to atėjai?
Dmitrijus: Jau daug kartų apie tai kalbėjau, bet visai neprieštarauju kartoti. Manau, teisinga kartoti šią temą, nes yra painiava tarp priežasties ir pasekmės.
Mums tikrai reikėjo įrankio. Susidūrėme su daugybe problemų, grūmėsi, įveikėme jas įvairiais ramentais ir jautėme įrankio poreikį. Išgyvenome daugybę skirtingų variantų, susikūrėme savo dviračius ir įgijome patirties. Palaipsniui pasiekėme tašką, kai pradėjome naudoti „Docker“ beveik iš karto, kai jis pasirodė – apie 2013 m. Jo atsiradimo metu jau turėjome daug patirties su konteineriais, jau buvome parašę „Docker“ analogą - kai kuriuos savo ramentus Python. Atsiradus Docker, tapo įmanoma išmesti ramentus ir naudoti patikimą bei bendruomenės palaikomą sprendimą.
Su Kubernetes istorija panaši. Tuo metu, kai jis pradėjo įsibėgėti – mums tai 1.2 versija – jau turėjome krūvą ramentų ir Shell, ir Chef, kuriuos kažkaip bandėme orkestruoti su Docker. Rimtai žiūrėjome į Rancher ir įvairius kitus sprendimus, bet tada atsirado Kubernetes, kurioje viskas įgyvendinta būtent taip, kaip būtume darę ar net geriau. Nėra ko skųstis.
Taip, čia yra kažkoks netobulumas, yra kažkoks netobulumas - netobulumų yra daug, o 1.2 apskritai yra baisus, bet... Kubernetes yra kaip statomas pastatas - pasižiūri į projektą ir supranti kad bus šaunu. Jei dabar pastatas turi pamatus ir du aukštus, tai supranti, kad geriau kol kas nesikraustyti, bet su programine įranga tokių problemų nėra – jau galima naudotis.
Neturėjome akimirkos, kai pagalvotume, ar naudoti Kubernetes, ar ne. Laukėme jo gerokai prieš pasirodant, ir patys bandėme kurti analogus.
Apie Kubernetes
— Ar tiesiogiai dalyvaujate kuriant pačią „Kubernetes“?
Dmitrijus: Vidutiniškai. Atvirkščiai, mes dalyvaujame ekosistemos vystyme. Siunčiame tam tikrą skaičių traukos užklausų: „Prometheus“, įvairiems operatoriams, „Helm“ – į ekosistemą. Deja, negaliu sekti visko, ką darome, ir galiu klysti, bet nėra nė vieno telkinio nuo mūsų iki branduolio.
– Tuo pačiu ar daug savo įrankių kuriate aplink Kubernetes?
Dmitrijus: Strategija tokia: einame ir traukiame užklausas viskam, kas jau yra. Jei ten nepriimami traukimo prašymai, mes patys juos paprasčiausiai šakuojame ir gyvename tol, kol jie bus priimti su mūsų statiniais. Tada, kai jis pasiekia prieš srovę, grįžtame prie priešsrovės versijos.
Pavyzdžiui, turime „Prometheus“ operatorių, su kuriuo jau turbūt 5 kartus perjungėme pirmyn ir atgal į prieš srovę savo agregatą. Mums reikia tam tikros funkcijos, išsiuntėme užklausą, turime ją išleisti rytoj, bet nenorime laukti, kol ji bus išleista prieš srovę. Atitinkamai, mes surenkame patys, iškeliame savo agregatą su savo funkcija, kurios mums dėl tam tikrų priežasčių reikia, į visas savo grupes. Tada, pavyzdžiui, jie mums atverčia jį prieš srovę su žodžiais: „Vaikinai, padarykime tai bendresniu atveju“, mes arba kas nors kitas užbaigiame ir laikui bėgant jis vėl susilieja.
Stengiamės plėtoti viską, kas egzistuoja. Daug elementų, kurie dar neegzistuoja, dar nėra sugalvoti arba buvo sugalvoti, bet nespėjo įgyvendinti – mes tai darome. Ir ne todėl, kad mums patinka procesas ar dviračių kūrimas kaip pramonė, o tiesiog todėl, kad mums reikia šio įrankio. Dažnai kyla klausimas, kodėl mes padarėme tą ar aną dalyką? Atsakymas paprastas – taip, nes reikėjo eiti toliau, išspręsti kokią nors praktinę problemą, ir mes ją išsprendėme su šiuo tūlu.
Kelias visada yra toks: labai kruopščiai ieškome ir, jei nerandame sprendimo, kaip iš duonos kepalo padaryti troleibusą, tada gaminame savo kepalą ir savo troleibusą.
Flanta įrankiai
— Žinau, kad „Flant“ dabar turi priedų operatorius, apvalkalo operatorius ir dapp/werf įrankius. Kaip suprantu, tai tas pats instrumentas skirtinguose įsikūnijimuose. Taip pat suprantu, kad „Flaunt“ yra daug daugiau skirtingų įrankių. Tai yra tiesa?
Dmitrijus: „GitHub“ turime daug daugiau. Kiek dabar prisimenu, turime statuso žemėlapį – Grafanos skydelį, su kuriuo visi susidūrė. Jis minimas beveik kas antrame straipsnyje apie „Kubernetes“ stebėjimą „Medium“. Neįmanoma trumpai paaiškinti, kas yra statuso žemėlapis – jai reikia atskiro straipsnio, bet tai labai naudingas dalykas stebint būseną laikui bėgant, nes Kubernetes dažnai turime rodyti būseną laikui bėgant. Taip pat turime „LogHouse“ – tai „ClickHouse“ ir juodosios magijos pagrindu sukurtas dalykas, skirtas rąstų rinkimui „Kubernetes“.
Daug komunalinių paslaugų! O jų bus dar daugiau, nes šiais metais bus išleista nemažai vidinių sprendimų. Iš labai didelių, pagrįstų priedų operatoriumi, yra krūva priedų, skirtų Kubernetes, a, kaip tinkamai įdiegti sert manager - sertifikatų valdymo įrankį, kaip teisingai įdiegti Prometheus su krūva priedų - tai apie dvidešimt skirtingų dvejetainiai failai, kurie eksportuoja duomenis ir ką nors renka, šiam Prometheus turi nuostabiausią grafiką ir įspėjimus. Visa tai yra tik krūva Kubernetes priedų, kurie yra įdiegti klasteryje ir iš paprastų virsta šauniais, sudėtingais, automatiniais, kuriuose daugelis problemų jau buvo išspręstos. Taip, mes darome daug.
Ekosistemos vystymasis
„Man atrodo, kad tai labai didelis indėlis kuriant šį instrumentą ir jo naudojimo būdus. Ar galite apytiksliai įvertinti, kas dar taip pat prisidėtų prie ekosistemos vystymosi?
Dmitrijus: Rusijoje iš įmonių, veikiančių mūsų rinkoje, niekas nėra net arti. Žinoma, tai garsus pareiškimas, nes yra tokių pagrindinių žaidėjų kaip „Mail“ ir „Yandex“ – jie taip pat kažką daro su „Kubernetes“, tačiau net ir jie neprilygsta viso pasaulio įmonių, kurios daro daug daugiau nei mes, indėlio. Sunku lyginti „Flant“, kuriame dirba 80 žmonių, ir „Red Hat“, kuriame vien „Kubernetes“ dirba 300 inžinierių, jei neklystu. Sunku lyginti. RnD skyriuje dirbame 6 žmones, įskaitant mane, kurie pjauname visus įrankius. 6 žmonės ir 300 Red Hat inžinierių – kažkaip sunku palyginti.
– Tačiau kai net šie 6 žmonės gali nuveikti ką nors tikrai naudingo ir atstumiančio, kai susiduria su praktine problema ir sprendimą pateikia bendruomenei – įdomus atvejis. Suprantu, kad didelėse technologijų įmonėse, kur turi savo Kubernetes kūrimo ir palaikymo komandą, iš esmės galima kurti tuos pačius įrankius. Tai jiems pavyzdys, ką galima sukurti ir duoti bendruomenei, suteikiant impulsą visai bendruomenei, kuri naudojasi Kubernetes.
Dmitrijus: Tai tikriausiai yra integratoriaus ypatybė, jo ypatumas. Turime daug projektų ir matome daug įvairių situacijų. Mums pagrindinis būdas sukurti pridėtinę vertę yra analizuoti šiuos atvejus, rasti bendrumo ir padaryti juos kuo pigesnius. Šiuo klausimu aktyviai dirbame. Man sunku kalbėti apie Rusiją ir pasaulį, bet įmonėje dirba apie 40 „DevOps“ inžinierių, kurie dirba „Kubernetes“. Nemanau, kad Rusijoje yra daug įmonių, turinčių panašų skaičių specialistų, kurie supranta Kubernetes, jei iš viso yra.
Aš viską suprantu apie pareigų pavadinimą DevOps inžinierius, visi viską supranta ir yra įpratę vadinti DevOps inžinierius DevOps inžinieriais, apie tai nekalbėsime. Visi šie 40 nuostabių „DevOps“ inžinierių kasdien susiduria ir sprendžia problemas, mes tiesiog analizuojame šią patirtį ir bandome apibendrinti. Suprantame, jei jis liks mumyse, tai po metų ar dvejų įrankis bus nenaudingas, nes kažkur bendruomenėje atsiras jau paruoštas tūlas. Nėra prasmės kaupti šią patirtį viduje – tai tiesiog išeikvojama energija ir laikas į dev/null. Ir mes to visai nesigailime. Viską publikuojame su dideliu malonumu ir suprantame, kad tai reikia skelbti, plėtoti, reklamuoti, reklamuoti, kad žmonės tuo naudotųsi ir pridėtų savo patirtį – tada viskas auga ir gyvuoja. Tada po dvejų metų instrumentas nepatenka į šiukšliadėžę. Negaila ir toliau lieti jėgas, nes aišku, kad kažkas naudoja tavo įrankį, o po dvejų metų visi juo naudojasi.
Tai yra mūsų didelės strategijos su dapp/werf dalis. Nepamenu, kada pradėjome gaminti, atrodo, prieš 3 metus. Iš pradžių jis paprastai buvo ant apvalkalo. Tai buvo puikus koncepcijos įrodymas, išsprendėme kai kurias specifines problemas – tai pavyko! Bet yra problemų su apvalkalu, jo neįmanoma išplėsti, programavimas ant apvalkalo yra kita užduotis. Turėjome įprotį rašyti rubinų kalba, atitinkamai kažką perdarėme rubinų kalba, kūrėme, vystėme, vystėme ir susidūrėme su tuo, kad bendruomenė, minia, kuri nesako „mes to norime ar nenorime“, “ pasuka nosį Ruby, kaip tai juokinga? Supratome, kad turėtume visa tai įrašyti į Go, kad atitiktume pirmąjį kontrolinio sąrašo punktą: „DevOps“ įrankis turėtų būti statinis dvejetainis. Būti Go ar ne, nėra taip svarbu, bet statinis dvejetas, parašytas Go, yra geresnis.
Išeikvojome savo energiją, perrašėme dapp į Go ir pavadinome jį werf. „Dapp“ nebepalaikomas, nekuriamas, veikia kai kuriose naujausiose versijose, tačiau yra absoliutus atnaujinimo kelias į viršų, ir jūs galite juo sekti.
Kodėl dapp buvo sukurtas?
— Ar galite trumpai papasakoti, kodėl dapp buvo sukurtas, kokias problemas jis sprendžia?
Dmitrijus: Pirmoji priežastis yra surinkime. Iš pradžių turėjome rimtų problemų su kūrimu, kai „Docker“ neturėjo kelių pakopų galimybių, todėl daugiapakopį sukūrėme patys. Tada turėjome dar daug problemų su vaizdo valymu. Kiekvienas, kuris daro CI/CD, anksčiau ar vėliau susiduria su problema, kad yra krūva surinktų vaizdų, reikia kažkaip išvalyti tai, ko nereikia, ir palikti tai, ko reikia.
Antroji priežastis yra dislokavimas. Taip, Helm yra, bet jis išsprendžia tik kai kurias problemas. Juokinga, kad parašyta, kad „Helmas yra „Kubernetes“ paketų valdytojas. Būtent tai, kas „tai“. Taip pat yra žodžiai „Paketo valdytojas“ – ko įprasta tikėtis iš paketų tvarkytojo? Mes sakome: "Paketų tvarkyklė - įdiekite paketą!" ir tikimės, kad jis mums pasakys: „Paketas pristatytas“.
Įdomu tai, kad sakome: „Helm, install the package“, o jam atsakius, kad įdiegė, paaiškėja, kad jis ką tik pradėjo diegti – nurodė „Kubernetes“: „Paleisk šį dalyką!“ Ir ar jis prasidėjo, ar ne. , nesvarbu, ar tai veikia, ar ne, Helm šios problemos visiškai neišsprendžia.
Pasirodo, „Helm“ yra tik išankstinis teksto apdorojimas, kuris įkelia duomenis į „Kubernetes“.
Bet kaip bet kokio diegimo dalį norime sužinoti, ar programa buvo išleista gamybai, ar ne? Išleistas į prod reiškia, kad programa perkelta ten, nauja versija buvo įdiegta ir bent jau ten nestringa ir tinkamai reaguoja. Helmas šios problemos niekaip neišsprendžia. Norint ją išspręsti, reikia įdėti daug pastangų, nes reikia duoti „Kubernetes“ komandą išriedėti ir stebėti, kas ten vyksta – ar ji įdiegta, ar išleista. Taip pat yra daug užduočių, susijusių su diegimu, valymu ir surinkimu.
Planai
Šiais metais pradėsime vietos plėtrą. Norime pasiekti tai, kas anksčiau buvo „Vagrant“ – įvedėme „vagrant up“ ir įdiegėme virtualias mašinas. Norime pasiekti tašką, kai Git yra projektas, ten rašome „werf up“, ir jis iškelia vietinę šio projekto kopiją, įdiegtą vietiniame mini Kub, su visais patogiais plėtrai katalogais. . Priklausomai nuo kūrimo kalbos, tai daroma skirtingai, tačiau vis dėlto, kad būtų galima patogiai atlikti vietinį vystymą pagal prijungtus failus.
Kitas žingsnis mums yra investuoti į kūrėjų patogumą. Norėdami greitai įdiegti projektą vietoje naudodami vieną įrankį, sukurkite jį, įtraukite jį į „Git“ ir jis taip pat bus paleistas į etapą arba bandymus, atsižvelgiant į konvejerius, ir tada naudokite tą patį įrankį, kad pradėtumėte gaminti. Ši vienybė, susivienijimas, infrastruktūros atkuriamumas nuo vietinės aplinkos iki pardavimų mums yra labai svarbus taškas. Bet to dar nėra werf – mes tik planuojame tai padaryti.
Tačiau kelias į dapp/werf visada buvo toks pat kaip ir Kubernetes pradžioje. Susidūrėme su problemomis, sprendėme jas sprendimais – sugalvojome sau keletą sprendimų ant apvalkalo, bet ko. Tada jie bandė kažkaip ištaisyti šiuos sprendimus, apibendrinti ir šiuo atveju juos sujungti į dvejetainius, kuriais mes tiesiog dalijamės.
Yra ir kitas būdas pažvelgti į visą šią istoriją su analogijomis.
Kubernetes yra automobilio rėmas su varikliu. Nėra durų, stiklo, radijo, eglutės – visai nieko. Tik rėmas ir variklis. Ir yra vairas - tai vairas. Šaunu - vairas yra, bet jums taip pat reikia vairo kaiščio, vairo stovo, pavarų dėžės ir ratų, o be jų neapsieisite.
„Werf“ atveju tai yra dar vienas „Kubernetes“ komponentas. Tik dabar, pavyzdžiui, werf alfa versijoje Helm yra sukompiliuotas werf viduje, nes pavargome tai daryti patiems. Yra daug priežasčių, kodėl tai reikia padaryti. Aš jums išsamiai papasakosiu, kodėl mes sudarėme visą vairą kartu su vairalazde werf viduje .
Dabar werf yra labiau integruotas komponentas. Mes gauname gatavą vairą, vairo kaištį - aš nelabai moku automobilius, tačiau tai yra didelis blokas, kuris jau išsprendžia gana daugybę problemų. Mums nereikia patiems naršyti katalogo, pasirinkti vieną dalį kitai, galvoti, kaip jas susukti. Gauname jau paruoštą kombainą, kuris vienu metu išsprendžia daugybę problemų. Tačiau viduje jis yra sukurtas iš tų pačių atvirojo kodo komponentų, jis vis dar naudoja „Docker“ surinkimui, „Helm“ kai kurioms funkcijoms ir yra keletas kitų bibliotekų. Tai integruotas įrankis, leidžiantis greitai ir patogiai išimti šaunius CI/CD iš dėžutės.
Ar Kubernetes sunku prižiūrėti?
— Kalbate apie patirtį, kad pradėjote naudoti Kubernetes, tai jums yra rėmas, variklis, ant kurio galite pakabinti daug įvairių dalykų: kėbulą, vairą, prisukti pedalus, sėdynes. Kyla klausimas – kiek jums sunku „Kubernetes“ palaikymas? Turite daug patirties, kiek laiko ir išteklių skiriate „Kubernetes“ palaikymui atskirai nuo viso kito?
Dmitrijus: Tai labai sunkus klausimas ir norint atsakyti, turime suprasti, kas yra parama ir ko norime iš Kubernetes. Gal gali atskleisti?
— Kiek žinau ir matau, dabar daugelis komandų nori išbandyti „Kubernetes“. Kiekvienas prisiriša prie jo, pasideda ant kelių. Jaučiu, kad žmonės ne visada supranta šios sistemos sudėtingumą.
Dmitrijus: Taip yra.
— Kaip sunku paimti ir įdiegti „Kubernetes“ nuo nulio, kad jis būtų paruoštas gamybai?
Dmitrijus: Kaip manote, ar sunku persodinti širdį? Suprantu, kad tai kompromituojantis klausimas. Naudotis skalpeliu ir nesuklysti nėra taip sunku. Jei jie jums pasakys, kur kirpti ir kur siūti, tada pati procedūra nėra sudėtinga. Sunku kartas nuo karto garantuoti, kad viskas pavyks.
Įdiegti „Kubernetes“ ir pradėti ją veikti paprasta: vaikelis! - įdiegta, yra daug diegimo būdų. Bet kas atsitinka, kai kyla problemų?
Visada kyla klausimų – į ką dar neatsižvelgėme? Ko mes dar nepadarėme? Kurie Linux branduolio parametrai buvo nurodyti neteisingai? Viešpatie, ar mes juos net paminėjome?! Kokius Kubernetes komponentus pristatėme, o kurių ne? Kyla tūkstančiai klausimų, o norint į juos atsakyti, šioje industrijoje reikia praleisti 15-20 metų.
Turiu naujausią pavyzdį šia tema, kuris gali atskleisti problemos „Ar Kubernetes sunku išlaikyti?“ prasmę. Prieš kurį laiką rimtai svarstėme, ar neturėtume pabandyti įdiegti Cilium kaip tinklą Kubernetes.
Leiskite man paaiškinti, kas yra Cilium. „Kubernetes“ turi daugybę skirtingų tinklo posistemio diegimų, ir vienas iš jų yra labai šaunus – „Cilium“. Kokia jo prasmė? Branduolyje prieš kurį laiką atsirado galimybė rašyti kabliukus branduoliui, kurie vienaip ar kitaip įsiveržia į tinklo posistemį ir įvairius kitus posistemius ir leidžia apeiti didelius branduolio gabalus.
„Linux“ branduolys istoriškai turi IP maršrutą, perfiltrą, tiltus ir daugybę skirtingų senų komponentų, kuriems yra 15, 20, 30 metų. Apskritai jie veikia, viskas puiku, bet dabar jie sukrovė konteinerius, ir atrodo, kad bokštas iš 15 plytų vienas ant kito, o ant jo stovi ant vienos kojos – keistas jausmas. Ši sistema istoriškai susiformavo su daugybe niuansų, pavyzdžiui, apendiksas kūne. Pavyzdžiui, kai kuriose situacijose kyla našumo problemų.
Yra nuostabus BPF ir galimybė rašyti kabliukus branduoliui – vaikinai rašė savo kabliukus branduoliui. Paketas ateina į Linux branduolį, jie jį išima tiesiai prie įvesties, apdoroja patys kaip priklauso be tiltų, be TCP, be IP kamino – trumpai tariant, apeinant viską, kas parašyta Linux branduolyje, ir tada išspjauna. jį išmesti į konteinerį.
Kas nutiko? Labai šaunus veikimas, šaunios funkcijos – tiesiog šaunu! Bet mes žiūrime į tai ir matome, kad kiekviename kompiuteryje yra programa, kuri prisijungia prie Kubernetes API ir, remdamasi iš šios API gautais duomenimis, generuoja C kodą ir sukompiliuoja dvejetainius failus, kuriuos įkelia į branduolį, kad šie kabliukai veiktų. branduolio erdvėje.
Kas atsitiks, jei kas nors negerai? Mes nežinome. Norėdami tai suprasti, turite perskaityti visą šį kodą, suprasti visą logiką ir nuostabu, kaip tai sunku. Bet, kita vertus, yra šie tiltai, tinklo filtrai, ip maršrutas – aš neskaičiau jų šaltinio kodo ir neskaičiau 40 mūsų įmonėje dirbančių inžinierių. Galbūt tik nedaugelis supranta kai kurias dalis.
Ir koks skirtumas? Pasirodo, yra ip rout, Linux branduolys ir naujas įrankis - koks skirtumas, mes nei vieno, nei kito nesuprantame. Bet mes bijome panaudoti ką nors naujo – kodėl? Nes jei įrankiui 30 metų, tai per 30 metų visos klaidos buvo rastos, visos klaidos buvo įveiktos ir nereikia visko žinoti - jis veikia kaip juoda dėžė ir veikia visada. Visi žino, kokį diagnostinį atsuktuvą kurioje vietoje prisegti, kurį tcpdump kurį momentą paleisti. Visi gerai žino diagnostikos priemones ir supranta, kaip šis komponentų rinkinys veikia Linux branduolyje – ne kaip jis veikia, o kaip juo naudotis.
O nuostabiai šauniam Cilium dar nėra 30 metų, jis dar nepasenęs. Kubernetes turi tą pačią problemą, nukopijuokite. Kad Cilium sumontuota idealiai, kad Kubernetes sumontuota puikiai, bet kai gamyboje kas nors nepavyksta, ar kritinėje situacijoje greitai supranti, kas nutiko?
Kai sakome, ar sunku išlaikyti Kubernetes – ne, tai labai lengva ir taip, nepaprastai sunku. „Kubernetes“ puikiai veikia atskirai, tačiau su milijardu niuansų.
Apie požiūrį „Man pasiseks“.
— Ar yra įmonių, kuriose šie niuansai beveik garantuotai atsiras? Tarkime, kad „Yandex“ staiga perkelia visas paslaugas į „Kubernetes“, ten bus didžiulė apkrova.
Dmitrijus: Ne, čia ne apie krūvį pokalbis, o apie paprasčiausius dalykus. Pavyzdžiui, turime Kubernetes, ten įdiegėme programą. Iš kur žinai, kad tai veikia? Paprasčiausiai nėra paruošto įrankio suprasti, kad programa nestringa. Nėra paruoštos sistemos, kuri siunčia įspėjimus; turite sukonfigūruoti šiuos įspėjimus ir kiekvieną tvarkaraštį. Ir mes atnaujiname Kubernetes.
Turiu Ubuntu 16.04. Galima sakyti, kad tai sena versija, bet mes vis dar prie jos, nes tai LTS. Yra systemd, kurio niuansas yra tas, kad jis neišvalo C grupių. „Kubernetes“ paleidžia rinkinius, sukuria „C“ grupes, tada ištrina „pods“ ir kažkaip paaiškėja – neatsimenu detalių, atsiprašau – kad lieka sisteminių skilčių. Tai lemia tai, kad laikui bėgant bet kuris automobilis pradeda stipriai sulėtinti. Tai net ne apie aukštą apkrovą. Jei paleidžiami nuolatiniai blokai, pavyzdžiui, jei yra Cron Job, kuris nuolat generuoja podius, tada mašina su Ubuntu 16.04 po savaitės pradės lėtėti. Nuolat didelis apkrovos vidurkis bus dėl to, kad buvo sukurta krūva C grupių. Tai yra problema, su kuria susidurs bet kuris asmuo, tiesiog įdiegęs Ubuntu 16 ir Kubernetes.
Tarkime, jis kažkaip atnaujina systemd ar dar ką nors, bet Linux branduolyje iki 4.16 tai dar juokingiau - kai ištrinate C grupes, jos nuteka branduolyje ir iš tikrųjų nėra ištrinamos. Todėl po mėnesio darbo prie šios mašinos bus neįmanoma žiūrėti į židinių atminties statistiką. Išimame failą, susukame į programą ir vienas failas sukasi 15 sekundžių, nes branduolys labai ilgai užtrunka, kol suskaičiuoja savyje milijoną C grupių, kurios tarsi ištrintos, bet ne – jos nuteka. .
Dar daug tokių smulkmenų šen bei ten. Tai nėra problema, su kuria kartais gali susidurti milžiniškos įmonės, patiriant labai dideles apkrovas – ne, tai kasdienių dalykų reikalas. Žmonės gali taip gyventi mėnesius – įdiegė „Kubernetes“, įdiegė programą – atrodo, kad ji veikia. Daugeliui žmonių tai yra normalu. Jie net nežinos, kad ši programa dėl kokių nors priežasčių suges, negaus įspėjimo, tačiau jiems tai yra norma. Anksčiau gyvenome virtualiose mašinose be stebėjimo, dabar persikėlėme į Kubernetes, taip pat be stebėjimo – koks skirtumas?
Kyla klausimas, kad eidami ledu niekada nežinome jo storio, nebent iš anksto pamatuotume. Daugelis žmonių vaikšto ir nesijaudina, nes yra vaikščioję anksčiau.
Mano požiūriu, bet kurios sistemos veikimo niuansas ir sudėtingumas yra užtikrinti, kad ledo storis būtų tiksliai pakankamas mūsų problemoms išspręsti. Štai apie ką mes kalbame.
IT srityje, man atrodo, yra per daug „man pasiseks“ metodų. Daugelis žmonių diegia programinę įrangą ir naudojasi programinės įrangos bibliotekomis tikėdamiesi, kad jiems pasiseks. Apskritai daugeliui žmonių pasiseka. Tikriausiai dėl to ir veikia.
– Pagal mano pesimistinį vertinimą atrodo taip: kai rizika didelė, o aplikacija turi veikti, tuomet reikia palaikymo iš Flaunt, galbūt iš Red Hat, arba reikia savo vidinės komandos, skirtos būtent Kubernetes, kuri yra pasiruošusi kad jį nuimtų.
Dmitrijus: Objektyviai taip yra. Pačiam įsitraukti į „Kubernetes“ istoriją nedidelei komandai kyla nemažai rizikos.
Ar mums reikia konteinerių?
— Ar galite pasakyti, kaip „Kubernetes“ paplitimas Rusijoje?
Dmitrijus: Aš neturiu šių duomenų ir nesu tikras, kad kas nors kitas juos turi. Mes sakome: „Kubernetes, Kubernetes“, bet yra ir kitas būdas pažvelgti į šią problemą. Aš taip pat nežinau, kaip plačiai paplitę konteineriai, bet žinau skaičių iš interneto pranešimų, kad 70% konteinerių yra suprojektuoti Kubernetes. Tai buvo patikimas šaltinis gana dideliam mėginiui visame pasaulyje.
Tada kitas klausimas – ar mums reikia konteinerių? Mano asmeninis jausmas ir bendra „Flant“ įmonės pozicija yra ta, kad „Kubernetes“ yra de facto standartas.
Nebus nieko, išskyrus Kubernetes.
Tai yra absoliutus keitimas infrastruktūros valdymo srityje. Tiesiog absoliutus – viskas, nebereikia Ansible, Chef, virtualių mašinų, Terraform. Jau nekalbu apie senuosius kolūkinius metodus. Kubernetes yra absoliutus keitiklis, o dabar bus tik taip.
Aišku, kad vieniems tai suvokti prireikia poros metų, o kitiems – poros dešimtmečių. Neabejoju, kad nieko nebus, tik Kubernetes ir ši nauja išvaizda: nebegadiname operacinės sistemos, o naudojame infrastruktūra kaip kodas, tik ne su kodu, o su yml - deklaratyviai aprašyta infrastruktūra. Jaučiu, kad taip bus visada.
— Tai yra, tos įmonės, kurios dar neperėjo prie „Kubernetes“, tikrai prie jos pereis arba liks užmarštyje. Ar teisingai tave supratau?
Dmitrijus: Tai taip pat nėra visiškai tiesa. Pavyzdžiui, jei turime užduotį paleisti DNS serverį, jis gali būti paleistas FreeBSD 4.10 ir jis gali puikiai veikti 20 metų. Tiesiog dirbk ir viskas. Galbūt po 20 metų vieną kartą reikės ką nors atnaujinti. Jei kalbame apie programinę įrangą tokiu formatu, kokį paleidome ir ji iš tikrųjų veikia daugelį metų be jokių atnaujinimų, neatlikus pakeitimų, tada, žinoma, Kubernetes nebus. Jis ten nereikalingas.
Viskas, kas susiję su CI/CD – visur, kur reikia Continuous Delivery, kur reikia atnaujinti versijas, atlikti aktyvius pakeitimus, visur, kur reikia sukurti atsparumą gedimams – tik Kubernetes.
Apie mikropaslaugas
– Čia turiu nedidelį disonansą. Norėdami dirbti su Kubernetes, jums reikia išorinės arba vidinės paramos – tai pirmas punktas. Antra, kai tik pradedame plėtrą, esame mažas startuolis, dar nieko neturime, Kubernetes ar apskritai mikro paslaugų architektūros kūrimas gali būti sudėtingas ir ne visada ekonomiškai pagrįstas. Man įdomi jūsų nuomonė – ar startuoliai turi iš karto pradėti rašyti „Kubernetes“ nuo nulio, ar vis tiek gali rašyti monolitą, o tik tada ateiti į „Kubernetes“?
Dmitrijus: Šaunus klausimas. Aš kalbu apie mikropaslaugas Daug kartų teko susidurti su žmonėmis, bandančiais įkalti vinis mikroskopu. Pats požiūris yra teisingas; mes patys kuriame savo vidinę programinę įrangą taip. Tačiau kai tai darote, turite aiškiai suprasti, ką darote. Žodis, kurio aš labiausiai nekenčiu apie mikropaslaugas, yra „mikro“. Istoriškai šis žodis atsirado ten, ir kažkodėl žmonės mano, kad mikro yra labai mažas, mažesnis nei milimetras, kaip mikrometras. Tai yra blogai.
Pavyzdžiui, yra monolitas, kurį rašo 300 žmonių, ir visi, kurie dalyvavo kuriant, supranta, kad ten yra problemų, ir jį reikia suskaidyti į mikro gabalus - apie 10 vienetų, kurių kiekvieną parašė 30 žmonių. minimalioje versijoje. Tai svarbu, būtina ir šaunu. Bet kai pas mus ateina startuolis, kuriame 3 labai šaunūs ir talentingi vaikinai ant kelių parašė 60 mikro paslaugų, kiekvieną kartą ieškau Corvalol.
Man atrodo, kad apie tai jau buvo kalbėta tūkstančius kartų – gavome paskirstytą monolitą vienokiu ar kitokiu pavidalu. Tai nėra ekonomiškai pagrįsta, apskritai viskas yra labai sunku. Aš ką tik tai mačiau tiek daug kartų, kad man tai labai skaudu, todėl toliau apie tai kalbu.
Į pradinį klausimą kyla konfliktas tarp to, kad, viena vertus, Kubernetes yra baisu naudoti, nes neaišku, kas ten gali sugesti ar neveikti, kita vertus, aišku, kad viskas ten eina. ir nieko tik Kubernetes egzistuos . Atsakymas - pasverkite gaunamos naudos, užduočių, kurias galite išspręsti, kiekį. Tai yra vienoje skalės pusėje. Kita vertus, yra rizika, susijusi su prastovomis arba sutrumpėjus atsako laikui, pasiekiamumo lygiui – su našumo rodiklių sumažėjimu.
Tai štai – arba judame greitai, o Kubernetes leidžia daug ką atlikti daug greičiau ir geriau, arba naudojame patikimus, laiko patikrintus sprendimus, bet judame daug lėčiau. Tai pasirinkimas, kurį turi padaryti kiekviena įmonė. Galite galvoti apie tai kaip apie taką džiunglėse – eidami pirmą kartą galite sutikti gyvatę, tigrą ar išprotėjusį barsuką, o 10 kartų nuėję taką nužingsniavote, pašalinote. šakas ir vaikščioti lengviau. Kiekvieną kartą kelias tampa platesnis. Tada tai asfaltuotas kelias, o vėliau gražus bulvaras.
Kubernetes nestovi vietoje. Dar kartą klausimas: Kubernetes, viena vertus, yra 4-5 dvejetainiai, kita vertus, tai visa ekosistema. Tai yra operacinė sistema, kurią turime savo įrenginiuose. Kas čia? Ubuntu ar Curios? Tai yra Linux branduolys, daugybė papildomų komponentų. Visa tai čia, viena nuodinga gyvatė buvo išmesta iš kelio, ten buvo pastatyta tvora. „Kubernetes“ vystosi labai greitai ir dinamiškai, o rizikos, nežinomybės apimtys kas mėnesį mažėja ir atitinkamai šios svarstyklės persibalansuoja.
Atsakydamas į klausimą, ką turėtų daryti startuolis, sakyčiau – atvykite į „Flaunt“, sumokėkite 150 tūkstančių rublių ir gaukite „DevOps“ paslaugą iki galo. Jei esate mažas startuolis su keliais kūrėjais, tai veikia. Užuot samdę savo kūrėjus, kuriems šiuo metu reikės išmokti išspręsti jūsų problemas ir mokėti atlyginimą, gausite galutinį visų problemų sprendimą. Taip, yra keletas trūkumų. Mes, kaip užsakovas, negalime taip įsitraukti ir greitai reaguoti į pokyčius. Bet mes turime daug patirties ir paruoštos praktikos. Garantuojame, kad bet kokioje situacijoje tikrai greitai išsiaiškinsime ir prikelsime bet kurį Kubernetes iš numirusių.
Primygtinai rekomenduoju užsakomųjų paslaugų teikimą pradedantiesiems ir įsitvirtinusiems verslams iki tokio dydžio, kad operacijoms galėtumėte skirti 10 žmonių komandą, nes kitaip nėra prasmės. Tikrai prasminga tai perduoti iš išorės.
Apie „Amazon“ ir „Google“.
– Ar „Amazon“ ar „Google“ sprendimo priegloba gali būti laikoma užsakovu?
Dmitrijus: Taip, žinoma, tai išsprendžia daugybę problemų. Bet vėlgi yra niuansų. Jūs vis tiek turite suprasti, kaip jį naudoti. Pavyzdžiui, „Amazon AWS“ darbe yra tūkstantis smulkmenų: reikia apšildyti „Load Balancer“ arba iš anksto parašyti prašymą, kad „vaikinai, sulauksime srauto, apšildykite mums apkrovos balansavimo įrenginį! Jūs turite žinoti šiuos niuansus.
Kai kreipsitės į žmones, kurie specializuojasi šioje srityje, beveik visi tipiniai dalykai užsidaro. Dabar turime 40 inžinierių, iki metų pabaigos turbūt bus 60 – su visais šiais dalykais tikrai susidūrėme. Net jei vėl susiduriame su šia problema kokiame nors projekte, greitai paklausiame vieni kitų ir žinome, kaip ją išspręsti.
Tikriausiai atsakymas yra toks – žinoma, priglobta istorija palengvina kai kurias dalis. Kyla klausimas, ar esate pasirengę pasitikėti šiais šeimininkais ir ar jie išspręs jūsų problemas. „Amazon“ ir „Google“ pasirodė gerai. Visiems mūsų atvejams – tiksliai. Daugiau teigiamos patirties neturime. Visi kiti debesys, su kuriais bandėme dirbti, sukuria daug problemų - Ager, ir viskas, kas yra Rusijoje, ir visokie OpenStack skirtingais diegimais: Headster, Overage - ką tik norite. Jie visi sukuria problemų, kurių nenorite išspręsti.
Todėl atsakymas yra teigiamas, bet iš tikrųjų nėra labai daug brandžių prieglobos sprendimų.
Kam reikia Kubernetes?
— Ir vis dėlto, kam reikia Kubernetes? Kas jau turėtų pereiti prie „Kubernetes“, kas yra tipiškas „Flaunt“ klientas, kuris ateina specialiai „Kubernetes“?
Dmitrijus: Tai įdomus klausimas, nes dabar, po Kubernetes, daug žmonių kreipiasi į mus: „Vaikinai, mes žinome, kad jūs darote Kubernetes, darykite tai už mus! Mes jiems atsakome: „Ponai, mes nedarome Kubernetes, mes darome prod ir viską, kas su tuo susiję“. Nes šiuo metu tiesiog neįmanoma sukurti gaminio neatlikus viso CI/CD ir visos šios istorijos. Visi nutolo nuo skirstymo, kad vystymasis vystosi, o išnaudojimas – išnaudojimas.
Mūsų klientai tikisi įvairių dalykų, bet visi laukia kažkokio gero stebuklo, kad turi tam tikrų problemų, o dabar - hop! — Kubernetes jas išspręs. Žmonės tiki stebuklais. Mintyse jie supranta, kad stebuklo nebus, bet sieloje tikisi – o jeigu šitas Kubernetes dabar viską už mus išspręs, tiek apie tai šneka! Staiga jis dabar - čiaudėti! - ir sidabrinė kulka, čiaudėti! – ir mes turime 100 % veikimo laiką, visi kūrėjai gali išleisti viską, kas patenka į gamybą 50 kartų, ir tai nesugenda. Apskritai, stebuklas!
Kai tokie žmonės ateina pas mus, sakome: „Atsiprašau, bet stebuklo nebūna“. Norėdami būti sveiki, turite gerai maitintis ir sportuoti. Norint turėti patikimą produktą, jis turi būti pagamintas patikimai. Norėdami turėti patogų CI / CD, turite jį padaryti taip. Tai daug darbo, kurį reikia padaryti.
Atsakant į klausimą, kam reikia Kubernetes – niekam nereikia Kubernetes.
Kai kurie žmonės klaidingai mano, kad jiems reikia Kubernetes. Žmonėms reikia, jie turi gilų poreikį nustoti mąstyti, mokytis ir domėtis visomis infrastruktūros problemomis ir jų programų paleidimo problemomis. Jie nori, kad programos tiesiog veiktų ir būtų įdiegtos. Jiems „Kubernetes“ yra viltis, kad jie nustos girdėti pasakojimų, kad „mes ten gulėjome“, „negalime išsiskleisti“ ar dar kažko.
Dažniausiai pas mus ateina techninis direktorius. Jie jo prašo dviejų dalykų: viena vertus, suteikti mums bruožų, kita vertus, stabilumo. Siūlome pasiimti ir padaryti. Sidabrinė kulka, tiksliau, pasidabruota, yra ta, kad nustosite galvoti apie šias problemas ir gaišti laiką. Turėsite ypatingų žmonių, kurie uždarys šį klausimą.
Formuluotė, kad mums ar kam nors kitam reikia „Kubernetes“, yra neteisinga.
„Kubernetes“ administratoriams tikrai reikia, nes tai labai įdomus žaislas, su kuriuo galima žaisti ir pažaisti. Būkime atviri – visi mėgsta žaislus. Visi esame kažkur vaikai, o kai pamatome naują, norime jį žaisti. Kai kuriems tai buvo atgrasoma, pavyzdžiui, administracijoje, nes jie jau pakankamai žaidė ir jau taip pavargę, kad tiesiog nenori. Tačiau tai niekam nėra visiškai prarasta. Pavyzdžiui, jei jau seniai pavargau nuo žaislų sistemų administravimo ir DevOps srityje, tai žaislus vis dar mėgstu, vis dar perku keletą naujų. Visi žmonės vienaip ar kitaip vis tiek nori kažkokių žaislų.
Nereikia žaisti su gamyba. Kad ir ko kategoriškai rekomenduoju nedaryti ir ką dabar matau masiškai: „O, naujas žaislas! — nubėgo pirkti, nupirko ir: „Dabar nuneškime į mokyklą ir parodykime visiems draugams“. Nedaryk to. Atsiprašau, mano vaikai tik auga, aš nuolat kažką matau vaikuose, pastebiu savyje, o paskui apibendrinu kitiems.
Galutinis atsakymas yra: jums nereikia Kubernetes. Turite išspręsti savo problemas.
Tai, ką galite pasiekti, yra:
- prod nenukrenta;
- net jei jis bando nukristi, mes apie tai žinome iš anksto ir galime ką nors įdėti;
- galime tai pakeisti tokiu greičiu, kokiu to reikalauja mūsų verslas, ir galime tai padaryti patogiai; tai nesukelia mums jokių problemų.
Yra du tikri poreikiai: patikimumas ir diegimo dinamiškumas / lankstumas. Kiekvienas, kuris šiuo metu daro kokius nors IT projektus, nesvarbu, kokiame versle - minkštas, skirtas palengvinti pasaulį, ir kas tai supranta, turi šiuos poreikius išspręsti. Kubernetes su tinkamu požiūriu, su tinkamu supratimu ir pakankamai patirtimi leidžia juos išspręsti.
Apie be serverio
- Jei pažvelgsite šiek tiek toliau į ateitį, tada, bandant išspręsti galvos skausmo nebuvimo problemą su infrastruktūra, su diegimo greičiu ir programų pasikeitimų greičiu, atsiranda naujų sprendimų, pavyzdžiui, be serverio. Ar jaučiate potencialą šia kryptimi ir, tarkime, pavojų Kubernetes ir panašiems sprendimams?
Dmitrijus: Čia vėl reikia padaryti pastabą, kad aš ne regėtojas, kuris žiūri į priekį ir sako – bus taip! Nors aš ką tik dariau tą patį. Žiūriu į savo kojas ir matau ten krūvą problemų, pavyzdžiui, kaip kompiuteryje veikia tranzistoriai. Tai juokinga, tiesa? Mes susiduriame su kai kuriomis CPU klaidomis.
Padaryti be serverio gana patikimą, pigų, efektyvų ir patogų, išspręsdamas visas ekosistemos problemas. Čia aš sutinku su Elonu Musku, kad norint sukurti žmonijos gedimų toleranciją, reikia antrosios planetos. Nors nežinau, ką jis sako, suprantu, kad pati nesu pasiruošusi skristi į Marsą ir tai neįvyks rytoj.
Be serverio aiškiai aišku, kad tai yra ideologiškai teisingas dalykas, kaip ir žmonijos tolerancija gedimams – geriau turėti dvi planetas nei vieną. Bet kaip tai padaryti dabar? Vienos ekspedicijos siuntimas nėra problema, jei sutelkiate savo pastangas į ją. Nusiųsti kelias ekspedicijas ir ten įkurdinti kelis tūkstančius žmonių, manau, irgi realu. Tačiau padaryti jį visiškai atsparų gedimams, kad ten gyventų pusė žmonijos, man dabar atrodo neįmanoma, nesvarstoma.
Be serverio vienas prieš vieną: viskas šaunu, bet tai toli nuo 2019 m. problemų. Arčiau 2030 m. – pagyvenkime ir pamatysime. Neabejoju, kad gyvensime, tikrai gyvensime (pakartokite prieš miegą), bet dabar reikia spręsti kitas problemas. Tai tarsi tikėjimas pasakų poniu Vaivorykšte. Taip, porą procentų atvejų išsprendžiama, ir jie puikiai išsprendžiami, bet subjektyviai žiūrint, be serverio yra vaivorykštė... Man ši tema per tolima ir per daug nesuprantama. Aš nesu pasiruošęs kalbėti. 2019 m. negalėsite parašyti vienos programos su be serverio.
Kaip vystysis Kubernetes
— Kaip manote, kaip vystysis „Kubernetes“ ir ją supanti ekosistema, kai judame link šios galimai nuostabios tolimos ateities?
Dmitrijus: Aš daug apie tai galvojau ir turiu aiškų atsakymą. Pirmasis yra statusfull - juk be pilietybės padaryti lengviau. Kubernetes iš pradžių daugiau investavo į tai, viskas prasidėjo nuo to. Kubernetes be pilietybės veikia beveik puikiai, tiesiog nėra kuo skųstis. Vis dar yra daug problemų, tiksliau, niuansų. Viskas ten jau mums puikiai tinka, bet tai mes. Prireiks dar bent poros metų, kad tai veiktų visiems. Tai ne apskaičiuotas rodiklis, o mano jausmas iš galvos.
Trumpai tariant, statusfull turėtų ir vystysis labai stipriai, nes visos mūsų programos išsaugo būseną; nėra programų be būsenos. Tai iliuzija; visada reikia kokios nors duomenų bazės ir dar kažko. „Statefull“ yra ištaisyti viską, kas įmanoma, ištaisyti visas klaidas, pagerinti visas problemas, su kuriomis šiuo metu susiduriama – pavadinkime tai priėmimu.
Žymiai sumažės nežinomybės lygis, neišspręstų problemų lygis, tikimybės, kad su kažkuo susidursite, lygis. Tai svarbi istorija. Ir operatoriai - viskas, kas susiję su administravimo logikos kodifikavimu, valdymo logika, kad būtų lengva paslauga: MySQL lengva paslauga, RabbitMQ lengva paslauga, Memcache lengva paslauga - apskritai visi šie komponentai, kuriuos turime būti garantuoti. dėžė. Tai tik išsprendžia problemą, kad norime duomenų bazės, bet nenorime jos administruoti arba norime Kubernetes, bet nenorime jos administruoti.
Ši vienokia ar kitokia operatoriaus tobulėjimo istorija bus svarbi per ateinančius porą metų.
Manau naudojimo patogumas turėtų labai padidėti – dėžutė taps vis juodesnė, patikimesnė, su vis daugiau paprastų rankenėlių.
Kartą „Youtube“ per „Saturday Night Live“ klausiausi seno interviu su Isaacu Asimovu iš 80-ųjų – tokia programa kaip „Urgant“, tik įdomi. Jie paklausė jo apie kompiuterių ateitį. Jis sakė, kad ateitis yra paprastume, kaip ir radijas. Radijo imtuvas iš pradžių buvo sudėtingas dalykas. Norint pagauti bangą, reikėjo 15 minučių sukti rankenėles, sukti iešmelius ir apskritai žinoti, kaip viskas veikia, suprasti radijo bangų perdavimo fiziką. Dėl to radijuje liko tik viena rankenėlė.
Koks radijas dabar 2019 m.? Automobilyje radijo imtuvas suranda visas bangas ir stočių pavadinimus. Proceso fizika nepasikeitė per 100 metų, tačiau naudojimo paprastumas pasikeitė. Dabar ir ne tik dabar, jau 1980 metais, kai buvo interviu su Azimovu, visi naudojosi radiju ir niekas negalvojo, kaip jis veikia. Visada pavyko – tai duota.
Azimovas tada pasakė, kad taip bus ir su kompiuteriais - naudojimo paprastumas padidės. Nors 1980 metais reikėjo išmokyti paspausti kompiuterio mygtukus, ateityje taip nebus.
Jaučiu, kad su Kubernetes ir infrastruktūra taip pat labai padidės naudojimosi patogumas. Tai, mano nuomone, akivaizdu – tai slypi paviršiuje.
Ką daryti su inžinieriais?
— Kas tada nutiks inžinieriams ir sistemų administratoriams, palaikantiems Kubernetes?
Dmitrijus: Kas atsitiko buhalteriui po 1C atsiradimo? Apie tą patį. Prieš tai jie skaičiavo popieriuje - dabar programoje. Darbo našumas išaugo dydžiu, tačiau pats darbas neišnyko. Jei anksčiau elektros lemputei įsukti prireikdavo 10 inžinierių, tai dabar užteks ir vienos.
Programinės įrangos kiekis ir užduočių skaičius, man atrodo, dabar auga greičiau nei atsiranda naujų DevOps ir didėja efektyvumas. Šiuo metu rinkoje jaučiamas specifinis trūkumas ir jis tęsis ilgai. Vėliau viskas grįš į tam tikrą normą, kurioje didės darbo efektyvumas, bus vis daugiau be serverių, prie Kubernetes bus prijungtas neuronas, kuris parinks visus resursus tiksliai taip, kaip reikia, ir apskritai veiks. viskas savaime, kaip priklauso - žmogus nutols ir nesikiš.
Tačiau kažkas vis tiek turės priimti sprendimus. Akivaizdu, kad šio žmogaus kvalifikacijos ir specializacijos lygis yra aukštesnis. Šiais laikais buhalterijoje nebereikia 10 darbuotojų, vedančių buhalteriją, kad nepavargtų rankos. Tai tiesiog nebūtina. Daugelį dokumentų automatiškai nuskaito ir atpažįsta elektroninė dokumentų valdymo sistema. Užtenka vieno protingo vyriausiojo buhalterio, jau turinčio daug didesnius įgūdžius, turintį gerą supratimą.
Apskritai taip reikia eiti visose pramonės šakose. Taip pat ir su automobiliais: anksčiau mašina buvo su mechaniku ir trimis vairuotojais. Šiais laikais automobilio vairavimas yra paprastas procesas, kuriame visi dalyvaujame kiekvieną dieną. Niekas nemano, kad automobilis yra kažkas sudėtingo.
DevOps ar sistemų inžinerija niekur nedings – augs aukšto lygio darbas ir efektyvumas.
— Išgirdau ir įdomią mintį, kad darbų tikrai daugės.
Dmitrijus: Žinoma, šimtu procentų! Nes mūsų rašomos programinės įrangos kiekis nuolat auga. Problemų, kurias sprendžiame naudodami programinę įrangą, skaičius nuolat auga. Darbų kiekis auga. Dabar DevOps rinka siaubingai perkaitusi. Tai matyti iš atlyginimo lūkesčių. Gerąja prasme, nesigilinant į smulkmenas, turėtų būti jaunieji, kurie nori X, viduriniai, kurie nori 1,5X, ir vyresni, kurie nori 2X. O dabar, jei pažvelgsite į Maskvos „DevOps“ atlyginimų rinką, jaunesnysis nori nuo X iki 3X, o vyresnis – nuo X iki 3X.
Niekas nežino, kiek tai kainuoja. Atlyginimo lygis matuojamas tavo pasitikėjimu – visiškas beprotnamis, tiesą pasakius, siaubingai perkaitusi rinka.
Žinoma, ši situacija labai greitai pasikeis – turėtų atsirasti tam tikras prisotinimas. Su programinės įrangos kūrimu taip nėra – nepaisant to, kad visiems reikia kūrėjų, o visiems reikia gerų kūrėjų, rinka supranta, kas ko vertas – industrija nusistovėjo. Šiomis dienomis „DevOps“ taip nėra.
– Iš to, ką išgirdau, padariau išvadą, kad dabartinis sistemos administratorius neturėtų per daug jaudintis, o pats laikas tobulinti savo įgūdžius ir pasiruošti, kad rytoj darbo bus daugiau, bet jis bus aukštesnės kvalifikacijos.
Dmitrijus: Šimtas procentų. Apskritai, mes gyvename 2019 m., o gyvenimo taisyklė yra tokia: mokymasis visą gyvenimą – mokomės visą gyvenimą. Man atrodo, kad dabar visi tai jau žino ir jaučia, bet neužtenka žinoti - tu turi tai padaryti. Kiekvieną dieną turime keistis. Jei to nepadarysime, anksčiau ar vėliau būsime nustumti į profesijos nuošalę.
Būkite pasirengę staigiems posūkiams 180 laipsnių kampu. Neatmetu situacijos, kai kažkas kardinaliai pasikeičia, išrandama kažkas naujo – taip nutinka. Hop! – Ir dabar elgiamės kitaip. Svarbu tam pasiruošti ir nesijaudinti. Gali atsitikti taip, kad rytoj viskas, ką darau, pasirodys nereikalinga – nieko, visą gyvenimą mokiausi ir esu pasiruošęs išmokti dar kažko. Tai ne problema. Nereikia bijoti darbo saugumo, tačiau reikia būti pasiruošus nuolat išmokti ko nors naujo.
Linkėjimai ir minutė reklamos
- Ar turi kokių pageidavimų?
Dmitrijus: Taip, turiu keletą pageidavimų.
Pirmas ir prekybinis - užsiprenumeruokite . Mieli skaitytojai, eikite į „YouTube“ ir užsiprenumeruokite mūsų kanalą. Maždaug po mėnesio pradėsime aktyviai plėsti vaizdo įrašų paslaugą. Turėsime daug atviro ir įvairaus mokomojo turinio apie Kubernetes: nuo praktinių dalykų, iki laboratorijų, iki gilių pagrindinių teorinių dalykų ir kaip naudotis Kubernetes. principų ir modelių lygis.
Antras prekybinis noras – eik į ir įdėti žvaigždes, nes jomis maitinamės. Jei nedovanosi mums žvaigždžių, neturėsime ką valgyti. Tai kaip mana kompiuteriniame žaidime. Kažką darome, darome, bandome, kažkas sako, kad tai baisūs dviračiai, kažkas, kad viskas yra visiškai negerai, bet mes tęsiame ir elgiamės visiškai sąžiningai. Matome problemą, ją sprendžiame ir dalinamės patirtimi. Todėl duok mums žvaigždę, ji nuo tavęs nepanyks, bet ateis pas mus, nes mes jomis maitinamės.
Trečias, svarbus ir jau nebe prekybinis noras - nustokite tikėti pasakomis. Jūs esate profesionalai. DevOps yra labai rimta ir atsakinga profesija. Nustokite žaisti darbo vietoje. Leiskite jam spustelėti ir jūs tai suprasite. Įsivaizduokite, kad atvykote į ligoninę ir ten gydytojas eksperimentuoja su jumis. Suprantu, kad tai gali ką nors įžeisti, bet greičiausiai tai ne apie jus, o apie ką nors kitą. Papasakok ir kitiems sustoti. Tai tikrai sugriauna mūsų visų gyvenimą – daugelis su operacijomis, administratoriais ir kūrėjais pradeda elgtis kaip su bičiuliais, kurie vėl ką nors sulaužė. Tai dažniausiai „lūžo“ dėl to, kad eidavome žaisti, o ne su šalta sąmone žiūrėjome, kad taip yra, taip yra.
Tai nereiškia, kad neturėtumėte eksperimentuoti. Eksperimentuoti reikia, tai darome patys. Tiesą sakant, mes patys kartais žaidžiame žaidimus - tai, žinoma, yra labai blogai, bet nieko žmogiško mums nėra svetima. 2019-uosius paskelbkime rimtų, gerai apgalvotų eksperimentų, o ne gamybos žaidimų metais. Tikriausiai taip.
- Labai ačiū!
Dmitrijus: Ačiū, Vitalijai, ir už skirtą laiką, ir už interviu. Mieli skaitytojai, labai ačiū, jei staiga pasiekėte šį tašką. Tikiuosi, kad iškėlėme jums bent keletą minčių.
Interviu Dmitrijus palietė werf problemą. Dabar tai yra universalus šveicariškas peilis, kuris išsprendžia beveik visas problemas. Tačiau taip buvo ne visada. Įjungta į festivalius Dmitrijus Stolyarovas išsamiai papasakos apie šį įrankį. pranešime bus visko: problemų ir paslėptų Kubernetes niuansų, šių sunkumų sprendimo variantų ir detalaus dabartinio werf diegimo. Prisijunkite prie mūsų gegužės 27 ir 28 dienomis, sukursime tobulus įrankius.
Šaltinis: www.habr.com