Kubernetes vallutab maailma. Millal ja kuidas?

Eelõhtul DevOpsConf Vitaly Khabarov intervjuu viis Dmitri Stolyaroviga (distol), tehnilise direktori ja ettevõtte „Flant“ kaasasutaja. Vitaly küsis Dmitrilt, millega tegeleb „Flant“, Kubernetesest, ökosüsteemi arengust ja toetamisest. Rääkisime, miks on vajalik Kubernetes ja kas see on üldse vajalik. Samuti puudutasime mikroteenuseid, Amazon AWS-i, lähenemist „Mul on õnne“ DevOpsis, Kubernetes tulevikku, miks, millal ja kuidas see haarab maailma, DevOpsi perspektiivid ja millega peaksid insenerid valmistuma ereda ja lähedase tuleviku jaoks koos lihtsustamise ja närvivõrkudega.

Intervjuu originaal podcastina kuulamiseks DevOps Deflope — Venekeelses DevOps podcastis, ja allpool on tekstiversioon.

Siin ja edaspidi küsib küsimusi Vitaly Khabarov insener Express42-st.

Flantist

— Dima, tere. Sa oled „Flant“ tehniline direktor ja samuti selle asutaja. Räägi palun, millega tegeleb ettevõte ja sina seal?

Dmitri: Välimuselt tundub, et me oleme sellised kutid, kes käivad, paigaldavad kõigile Kubernetes ja teevad sellega midagi. Aga see pole tõsi. Alguses alustasime ettevõttena, mis tegeleb Linuxiga, kuid juba väga kaua on meie peamine tegevus – võtmehoidjaga tootmis- ja highload-projektide teenindamine. Tavaline on see, et ehitame kogu infrastruktuuri nullist ja siis vastutame selle eest kaua aega. Seega, peamine töö, mida „Flant“ teeb, mille eest ka raha küsime – on vastutuse võtmine ja tootmise rakendamine võtmehoidjaga.




Mina, kui tehniline direktor ja üks ettevõtte kaasasutajatest, töötan ööpäevaringselt selle nimel, et leida viise, kuidas suurendada tootmise kättesaadavust, lihtsustada selle kasutamist, kergendada administraatorite elu ja muuta arendajate elu meeldivamaks.

Kubernetesest

— Viimasel ajal olen „Flanti“ poolt näinud palju ettekandeid ja artikleid Kubernetesest. Kuidas te sinna jõudsite?

Dmitri: Olen sellest palju rääkinud, kuid mul ei ole sugugi kahju seda korrata. Pean õigeks seda teemat korrata, kuna tekib segadus põhjuse ja tagajärje vahel.

Meil oli väga vaja tööriista. Me kohtasime mitmeid probleeme, võitlesime nendega, ületades neid erinevate lahendustega ja tundsime tööriista vajadust. Proovisime mitmeid erinevaid variante, ehitasime oma jalgrattaid ja kogusime kogemusi. Aeglaselt jõudsime sinnamaani, et hakkasime Dockerit kasutama peaaegu kohe, kui see ilmus — umbes 2013. aastal. Selle ilmumise hetkel oli meil juba palju kogemusi konteineritega, olime juba kirjutanud oma analooge „Dockerile“ — mingisuguseid meie loomingulisi lahendusi Pythonis. Dockeri ilmumisega saime ära visata meie lahendused ja hakata kasutama usaldusväärset ning kogukonna toetatud lahendust.

Kubernetesega on lugu sarnane. Ajal, mil see hakkas hoogu koguma — meie jaoks on see versioon 1.2 — oli meil juba hulk loomingulisi lahendusi nii Shellis kui ka Chefis, mida me püüdsime Dockerit orkestreerida. Me vaatlesime tõsiselt Rancherit ja erinevaid teisi lahendusi, kuid siis ilmus Kubernetes, milles oli kõik just nii, nagu me oleksime ise teinud, või isegi paremini. Midagi pole viga.

Jah, siin on mingid puudujäägid, seal on mingid puudujäägid — palju puudujääke, ja 1.2 on tõeliselt hull, aga... Kubernetes sarnaneb ehitatavale hoonele — vaatad projekti ja mõistad, et see tuleb äge. Kui hoonel on praegu vundament ja kaks korrust, siis mõistad, et parem on praegu mitte sisse kolida, kuid tarkvaraga pole selliseid probleeme — juba saab kasutada.

Meil ei olnud mingeid kahtlusi, kas kasutada Kubernetesit või mitte. Me ootasime seda palju enne, kui see ilmus, ja püüdsime ise analooge luua.

Kubernetesest

— Kas te osalete otseselt Kubernetes'i arenduses?

Dmitri: Kaudselt. Pigem osaleme ökosüsteemi arenduses. Me saadame teatud arvu pull request'e: Prometheusesse, erinevatesse operaatoritesse, Helmi — ökosüsteemi. Kahjuks ei suuda ma jälgida kõike, mida me teeme, ja võin eksida, kuid meie käest ei ole ühtegi pulka tuuma läinud.

— Samas arendate te palju oma tööriistu ümber Kubernetes'i?

Dmitri: Strateegia on selline: me läheme ja teeme pull request'e kõigesse, mis juba olemas on. Kui seal pull request'eid ei võeta vastu, siis me lihtsalt forkime need endale ja elame edasi, kuni need on meie versioonidega vastu võetud. Siis, kui see jõuab upstream'i, naaseme tagasi upstream'i versioonile.

Näiteks, meil on Prometheus-operator, millega me oleme viis korda juba üles-alla ümber lülitunud meie versioonile. Meil on vaja mingit funktsiooni, me saatsime pull requesti, peame selle homme välja tooma, kuid ei soovi oodata, kuni see upstreamis välja antakse. Seega valmistame endale, paiskame meie versiooni koos meie funktsiooniga, mis on meile vajalik, kõikidele oma klastritele. Siis ütlevad nad näiteks upstreamis: "Kallid, teeme selle palju üldisema juhtumi jaoks," me, või keegi teine, viimistleb selle ja aja jooksul sulandub see jälle tagasi.

Kõike, mis eksisteerib, püüame me edasi arendada.. Paljusid elemente, mida veel ei ole, pole veel välja mõeldud või on välja mõeldud, kuid pole suudetud ellu viia - me teeme. Ja mitte seetõttu, et meile meeldib ise protsess või jalgrattaehitus valdkonnana, vaid lihtsalt seetõttu, et meil on seda tööriista vaja. Tihti küsitakse, miks me tegime selle või teise asja? Vastus on lihtne - sest meil oli vaja edasi liikuda, lahendada mingi praktiline probleem ja me lahendasime selle selle tööriistaga.

Tee on alati selline: me otsime väga hoolikalt ja, kui me ei leia mingit lahendust, kuidas leivapätsist trollibussi teha, siis teeme oma leivapätsi ja oma trollibussi.

Flanta tööriistad

— Ma kuulen, et Flantal on praegu addon-operatorid, shell-operatorid, tööriistad dapp/werf. Nagu ma aru saan, on see sama tööriist erinevates inkarnatsioonides. Samuti mõistan, et Flanta sees on veel palju erinevaid tööriistu. Kas see on tõsi?

Dmitri: Meil on GitHubis veel palju asju. Ainuüksi, mis mul praegu meeles on, on statusmap - paneel Grafanale, mis on kõigile sobinud. Seda mainitakse peaaegu igas teises artiklis Kubernetes'i jälgimise kohta Mediumis. On võimatu lühidalt rääkida, mis on statusmap - selleks on vaja eraldi artiklit, kuid see on väga kasulik asi staatuse jälgimiseks ajas, kuna Kubernetesis on meil sageli vaja kuvada staatust ajas. Veel on meil LogHouse - see on asi ClickHouse'is ja musta maagia baasil logide kogumiseks Kubernetesis.

Palju utiliite! Ja tuleb veel rohkem, sest mõni sisemine lahendus on sel aastal vabastamisel. Suurte addon-Operaatorite põhjal on palju addone Kubernetes'i jaoks, nagu näiteks, kuidas õigesti seadistada sertifikaadihaldurit - tööriist sertifikaatide haldamiseks, kuidas õigesti seadistada Prometheust koos palju lisafunktsioonide - seal on umbes kakskümmend erinevat binaarfaili, mis eksportivad andmeid ja koguvad midagi, ning Prometheuse jaoks on suurepärased graafikud ja hoiatuste süsteem. Kõik need on lihtsalt palju addone Kubernetes'ile, mis installitakse klastrisse ja muudetakse see lihtsast keeruliseks ja automaatseks, kus paljusid küsimusi on juba lahendatud. Jah, teeme palju.

Ökosüsteemi areng

— Minu arvates on see väga suur panus selle tööriista ja selle kasutusmeetodite arengusse. Kas sa saaksid enam-vähem hinnata, kes veel teeks nii suurt panust ökosüsteemi arengusse?

Dmitri: Venemaal ei ole ükski ettevõte, mis tegutseb meie turul, lähedal.. Muidugi, see on suur avaldus, sest on suured mängijad, nagu Mail ja Yandex - nad teevad ka midagi Kubernetes'iga, kuid isegi nemad ei ole lähenenud ettevõtete panusele üldiselt maailmas, kes teevad palju rohkem kui meie. Raske on võrrelda "Flant" 80 inimesega ja Red Hat'iga, millel on ainult Kubernetes'e jaoks 300 inseneri, kui ma ei eksi. Raske on võrrelda. Meie RnD osakonnas on 6 inimest, sealhulgas mina, kes arendavad kõik meie tööriistad. 6 inimest versus 300 Red Hat'i inseneri - kuidagi raske võrrelda.

— Siiski, isegi kui need 6 inimest suudavad teha midagi tõeliselt kasulikku ja edasi antavat, kui nad silmitsi seisavad praktilise probleemiga ja annavad lahenduse kogukonnale - huvitav juhtum. Ma mõistan, et suurtes tehnoloogiaettevõtetes, kus on oma arendus ja Kubernetes'i tugimeeskond, võivad sellised tööriistad üldiselt areneda. See on nende jaoks näide, et saab arendada ja anda edasi kogukonnale, andes tõuke kogu kogukonnale, kes kasutab Kubernetes'i.

Dmitri: Tõenäoliselt on see integratsiooni tegija eripära. Meil on palju projekte ja näeme erinevaid olukordi. Meie peamine viis lisaväärtuse loomiseks on analüüsida neid kohti, leida ühiseid jooni ja maksimaalselt odavendada neid meie jaoks. Sellega tegeleme aktiivselt. Mul on raske rääkida Venemaast ja maailmast, kuid meil on firmas umbes 40 DevOps-inseneri, kes tegelevad Kubernetesega. Ma ei usu, et Venemaal on palju ettevõtteid, kus oleks sama palju spetsialiste, kes mõistavad Kuberneteset, kui üldse on.

Ma tean kõik DevOps-inseneri tiitlist, kõik mõistavad ja on harjunud nimetama DevOps-insenerideks, me ei hakka seda arutama. Kõik need 40 suurepärase DevOps-inseneri seisavad iga päev silmitsi probleemidega ja lahendavad neid, me lihtsalt analüüsime seda kogemust ja üritame seda üldistada. Me mõistame, et kui see jääb ainult meie seas, siis aasta või kahe pärast on tööriist kasutu, sest kuskil kogukonnas ilmub valmis lahendus. Pole mõtet seda kogemust enda sees hoida - see on lihtsalt energiate ja aja raiskamine dev/null'i. Nii et me ei kahetse seda. Me avaldame kõik suure hea meelega ja mõistame, et seda tuleb avaldada, arendada, reklaamida, et inimesed kasutaksid ja lisaksid oma kogemust - siis kasvavad ja elavad kõik. Siis kaks aastat hiljem tööriist ei lähe prügimäele. Pole kahju energiat jätkata, sest on näha, et keegi kasutab sinu tööriista ja kahe aasta pärast kasutavad seda kõik.

See on osa meie suurest strateegiast koos dapp/werfiga.. Ma ei mäleta, millal me selle arendamisega alustasime, tundub, et umbes 3 aastat tagasi. Alguses oli see täiesti shell'il. See oli super tõestuskontseptsioon, lahendasime mõned meie erialased probleemid - see toimis! Kuid shell'iga on seal probleeme, seda on edasi arendada võimatu, shell'il programmeerimine on üsna vaevarikas. Meil oli harjumus kirjutada Ruby keeles, seega tegime Ruby's midagi ümber, arendasime, arendasime ja jõudsime sinnamaani, et kogukond, rahvas, kes ei ütle 'me tahame või ei taha', keeras Ruby'le nina, kuigi see ei ole naljakas. Saime aru, et peame kõik selle kirjutama Go keeles, et lihtsalt vastata nimekirja esimesele punktile: DevOps-tööriist peab olema staatiline binaarGo kasutamine ei ole nii oluline, kuid parem on statiline binaar, mis on kirjutatud Go-s.

Kulusid palju ressursse, et kirjutada dapp Go-s ja nimetada see werfiks. Dapp-i ei toetata enam, see ei arene, see töötab mingis vanas versioonis, kuid on täiesti olemas täiustuste tee, mida saab järgida.

Miks dapp loodi

— Kas sa saaksid lühidalt rääkida, miks dapp loodi, milliseid probleeme see lahendab?

Dmitri: Esimene põhjus on ehitamine. Alguses oli meil tõsiseid probleeme ehitamisega, kui Docker ei osanud multi-stage, ja me tegime multi-stage ise. Siis oli meil veel palju küsimusi image'i puhastamisega. Kõik, kes teevad CI/CD-d, satuvad varem või hiljem silmitsi probleemiga, et on palju ehitatud imagesid, mis tuleb kuidagi puhastada, jättes alles need, mis on vajalikud.

Teine põhjus on deploy. Jah, olemas on Helm, kuid see lahendab ainult osa ülesannetest. Irooniline, et öeldakse: "Helm – Kubernetes'i pakihaldur". Just see "the" on oluline. Veel on sõnad "pakihaldur" — millised ootused on tavaliselt pakihaldurilt? Ütleme: "Pakihaldur - pane pakett!" ja ootame, et ta ütleb: "Pakett on paigaldatud."

Huvitav, et me räägime: "Helm, pane pakett", aga kui ta vastab, et on paigaldatud, selgub, et ta alles alustas installimist – ta ütleb Kubernetes'ile: "Käivita see asi!", kuid kas see käivitus või mitte, Helm ei käsitle seda küsimust üldse.

Selgub, et Helm on lihtsalt tekstipreprotsessor, mis laadib andmed Kubernetes'i.

Aga me tahame iga deploy'i raames teada – kas rakendus on produktsiooni jõudnud või mitte? Produktsiooni jõudmine tähendab, et rakendus jõudis sinna, uus versioon on üles seatud ja see ei jooksnud vähemalt kokku ning vastab õigesti. Helm ei lahenda seda ülesannet. Selle ülesande täitmiseks tuleb palju vaeva näha, sest tuleb anda Kubernetes'ile käsu välja viia ja jälgida, mis seal toimub – kas see on üles seatud või mitte. Ja on veel palju ülesandeid, mis on seotud deploy'i, puhastamise ja ehitamisega.

Plaane

Sel aastal kavatseme minna kohalikku arendusse. Tahame jõuda selleni, et nagu varem Vagrantis – kirjutasime „vagrant up” ja meil olid virtuaalid üles tõusnud. Tahame jõuda sellisse staadiumisse, kus projekt on Gitis, kirjutame sinna „werf up”, ja see tõstab kohaliku koopia sellest projektist, mis on paigaldatud kohalikku mini-Kubisse, koos kõigi arenduseks vajalike kaustadega. Sõltuvalt arenduskeelest toimub see erinevalt, kuid ikkagi, et saaks mugavalt teha kohalikku arendust monteeritud failide puhul.

Meie järgmine samm on tugevalt investeerida arendajate mugavusse. Et ühe tööriistaga kiiresti kohalikult üles tõsta projekt, arendada seda, pushida Gitisse, ning see käivitub samuti stage'ile või testidele, sõltuvalt wiret', ja siis sama tööriistaga minna tootmisse. See ühtsus, ühtsustamine, infrastruktuuri reprodutseeritavus kohalikust keskkonnast tootmiseni on meie jaoks väga oluline punkt. Kuid seda hetkel werf'is pole – alles plaanime teha.

Aga tee dapp/werf'ini on alati olnud sama, nagu Kubernetesega alguses. Me kohtusime probleemidega, lahendasime need ümbersuunamistega – välja mõtleme endale lahendusi shellis, milles iganes. Siis püüdsime neid ümbersuunamisi kuidagi sirgendada, üldistada ja koondada binaridega, mis me lihtsalt jagame.

On veel teine vaade kogu sellele loole, analoogiate kaudu.

Kubernetes on nagu auto raam koos mootoriga. Pole uksi, klaase, raadiovastuvõtjat, lõhnastajat – absoluutselt mitte midagi. Ainult raam ja mootor. Ja on Helm – see on rool. Lahe, et rool on olemas, aga vaja on ka roolisätet, rooliretke, käigukasti ja rattaid, ilma nendeta ei saa midagi.

Werf'i puhul on see veel üks komponent Kubernetesega. Ainult praegu on meil werf'i alfa-versioonis näiteks Helm sisestatud täielikult werf'i sisse, sest me oleme väsinud seda ise tegema. Palju põhjuseid seda teha, detailselt selle kohta, miks me kompileerisime helm'i koos tilleriga täielikult werf'i sisse, räägin ma just ettekanne RIT++.

Praegu on werf palju integreeritud komponent. Meil on valmis rool, rooli štift – ma ei ole autodes väga pädev, aga see on suur plokk, mis lahendab juba piisavalt laia spektri ülesandeid. Me ei pea ise kataloogis tuhnima, valima ühte detaili teise juurde, mõtlema, kuidas neid omavahel kokku sobitada. Saame valmis kombaini, mis lahendab korraga palju ülesandeid. Kuid sees on kõik endiselt avatud lähtekoodiga koostisosad, kasutatakse Dockerit ehitamiseks, Helmi osa funktsionaalsuse jaoks ja veel mitu muud teeki. See on integreeritud tööriist, et saada kiiresti ja mugavalt kvaliteetne CI/CD kohe välja kastist.

Kas on raske toetada Kuberneteset?

— Sa räägid kogemusest, et hakkasite kasutama Kuberneteset, see on teie raam, mootor, ja sellele saab palju erinevaid asju külge ehitada: kere, rool, kinnitada pedaalid, istmed. Kerkib küsimus – kui keeruline on teil Kuberneteset toetada? Teie kogemus on rikas, kui palju aega ja ressursse kulub just Kuberneteset toetamisele võrreldes kõigega muuga?

Dmitri: See on väga keeruline küsimus ja et vastata, tuleb mõista, mis on toetamine ja mida me Kuberneteselt tahame. Võib-olla sa avad selle?

— Nii palju kui ma tean ja kuidas ma näen, tahab praegu palju meeskondi proovida Kuberneteset. Kõik sukeldavad end sellesse, installivad selle kõiki. Mul on tunne, et inimesed ei mõista alati selle süsteemi keerukust.

Dmitri: Just niimoodi.

— Kui keeruline on võtta ja installida Kubernetes täiesti nullist nii, et see oleks tootmisvalmis?

Dmitri: Kuidas sa arvad, kui keeruline on südant vahetada? Ma mõistan, et küsimus on komplitseeriv. Käepide nuga ja mitte eksida – see ei ole nii keeruline. Kui sulle öeldakse, kus lõigata ja kus õmmelda, siis on protseduur iseenesest lihtne. Raskeks muutub garanteerida, et iga kord kõik õnnestub.

Kuberneteset installimine ja tööle panemine on lihtne: tšik! – see on installitud, on palju installimise viise. Aga mis juhtub, kui tekivad probleemid?

Alati tekivad küsimused – mida me veel ei arvestanud? Mida me veel ei teinud? Millised Linuxi tuuma parameetrid me valesti märkisime? Jumal, kas me üldse märkisime?! Millised Kubernetes komponentid me installisime, aga millised mitte? Tekivad tuhanded küsimused ja neile vastamiseks on vaja 15-20 aastat selle valdkonna kogemust.

Mul on värske näide selle teema kohta, mis võib avada probleemi, kas "Kas Kubernetes'e toetamine on keeruline?" Mõni aeg tagasi mõtlesime tõsiselt, kas proovida Ciliumit rakendada Kubernetes'e võrguna.

Selgitan, mis on Cilium. Kubernetes'es on palju erinevaid võrgusubside rakendusi, ja üks neist on lausa fantastiline - see on Cilium. Mis on selle mõte? Tuuma sees ilmus mõni aeg tagasi võimalus kirjutada tuuma hook'e, mis mingil moel sekkuvad võrgusubside ja erinevate teiste süsteemide toimimisse ning võimaldavad mööda minna suurtest osadest tuumas.

Linuxi tuumas on ajalooliselt olemas ip rout, net-filter, sildade ja palju erinevaid vanu komponente, mille igaühel on 15, 20, 30 aastat. Üldiselt nad töötavad, kõik on suurepärane, aga praegu on konteinerite liialdamise tõttu see nagu 15 tellise torn, mille peal seisad ühel jalal - kummaline tunne. See süsteem on ajalooliselt arenenud paljude nüanssidega, nagu appendiksi areng organismis. Teatud olukordades on esinenud sooritusvõime probleeme, näiteks.

On suurepärane BPF ja võimalus kirjutada tuuma hook'e - kutid kirjutasid oma hook'id tuumale. Pakett siseneva Linuxi tuuma, nad võtavad selle kohe sisse, töötlevad selle ise vajalikul viisil, ilma sildadeta, ilma TCP-ta, ilma IP-stekita - lühidalt, mööda kõige, mis on kirjutatud Linuxi tuumas, ja kohe oksendavad konteinerisse.

Mis sai? Väga lahe jõudlus, ägedad funktsioonid - lihtsalt fantastiline! Kuid me vaatame seda ja näeme, et igal masinal on programm, mis ühendub Kubernetes'e API-ga ja saadud andmete põhjal genereerib C-koodi ning kompileerib binaarfailid, mis laaditakse tuuma, et need hook'id töötaksid kernel space'is.

Mis juhtub, kui midagi läheb valesti? Me ei tea. Selle mõistmiseks tuleb lugeda kogu see kood läbi, mõista kogu loogikat, ja see on uskumatult keeruline. Aga teisalt, on need sillad, net-filter'id, ip rout - ma ei ole nende lähtekoodiga tutvunud, ja meie ettevõttes töötavad 40 inseneri samuti. Võib-olla mõistavad mõned osad vähesed.

Ja mis vahet seal on? Tundub, et on olemas ip rout, Linuxi tuum ja uus tööriist - mis vahet seal on, me ei mõista kumbagi. Kuid me kardame uut kasutada - miks? Sest kui tööriist on 30 aastat vana, siis 30 aastaga on kõik vead leitud, kõikidele takistustele astutud ja pole vaja kõigest teada - töötab nagu must kast ja töötab alati. Kõik teavad, kuhu panna diagnostiline kruvikeeraja, millal käivitada tcpdump. Kõik tunnevad diagnostilisi tööriistu ja mõistavad, kuidas see komponentide kogum Linuxi tuumas töötab - mitte kuidas see on üles ehitatud, vaid kuidas seda kasutada.

Aga üliäge Cilium ei ole 30 aastat vana, see ei ole veel valminud. Kubernetesel on sama probleem, koopia. Nii Cilium installitakse suurepäraselt kui ka Kubernetes, aga kui midagi läheb tootmisjärgus valesti, kas te suudate kriitilises olukorras kiiresti aru saada, mis valesti läks?

Kui me küsime, kas Kuberneteset on keeruline hallata - ei, see on väga lihtne, ja jah, uskumatult keeruline. Kubernetes töötab imeliselt iseenesest, aga miljardite nüanssidega.

Mõte "Mul vedas"

- Kas on olemas ettevõtteid, kus need nüansid peaaegu garanteeritult ilmuvad? Oletame, et Yandex üleeestiliselt viib kõik teenused Kubernetesesse, seal on tohutu koormus.

Dmitri: Ei, see ei ole ju jutt koormusest, vaid kõige lihtsamatest asjadest. Näiteks, meil on Kubernetes, me oleme sinna rakenduse paigaldanud. Kuidas mõista, et see töötab? Valmiskujul tööriista, et teada saada, et rakendus ei kokku kuku, lihtsalt pole. Valmiskujul süsteemi, mis saadab häireid - ei ole, tuleb need häired ja iga graafik seadistada. Ja me uuendame Kuberneteset.

Ubuntu 16.04 on enduru. See on vana versioon, kuid me oleme endiselt sellel, kuna seal on LTS. Seal on systemd, mille nüanss on see, et ta ei puhasta C-gruppe. Kubernetes käivitab podid, loob C-gruppe, seejärel kustutab podid ja kuidagi jääb nii, et ma ei mäleta detaile, vabandust, et systemd sildid jäävad alles. See toob kaasa selle, et aja jooksul hakkab iga masin tugevalt tarduma. See pole isegi küsimus highloadi kohta. Kui käivitatakse pidevaid pode, näiteks kui on Cron Job, mis pidevalt genereerib pode, siis masin Ubuntu 16.04 hakkab nädala pärast tarduma. Seal on pidevalt kõrge laadimise keskmine, kuna on loodud hulk C-gruppe. See on probleem, millega silmitsi seisab igaüks, kes lihtsalt installib Ubuntu 16 ja selle peale Kubernetes.

Oletame, et ta kuidagi uuendab systemd või midagi muud, kuid Linuxi tuumas on kuni 4.16 veel naljakam – C-gruppide kustutamisel lekkivad nad tuumas ja tegelikult ei eemaldu. Seetõttu on pärast kuu aega selle masinaga peaaegu võimatu vaadata statistikat mälu osas podide kohta. Me võtame faili, veereme programmis ja üks fail veereb 15 sekundit, kuna tuum vajab väga kaua aega, et arvutada endas miljonit C-gruppi, mis näiliselt on kustutatud, kuid ei ole – nad lekkivad.

Selliseid pisiasju on endiselt väga palju seal ja siin. See ei ole küsimus, millega suurfirmad võivad aeg-ajalt silmitsi seista väga suurte koormuste korral – ei, see on igapäevaste asjade küsimus. Inimesed võivad niimoodi kuude viisi elada – installisid Kubernetes'i, juurutati rakendus – tundub, et töötab. Paljude jaoks on see normaalne. Nad isegi ei saa teada, et rakendus kukub kunagi mingil põhjusel, häire ei jõua, kuid see on nende normaalsus. Varem elasime virtuaalmasinatel ilma jälgimiseta, nüüd kolisime Kubernetes'esse samuti ilma jälgimiseta – mis see muudab?

Küsimus on selles, et kui me käime jää peal, ei tea me kunagi tema paksust, kui me ei ole seda eelnevalt mõõtnud. Paljud käivad ja ei vaeva end, sest nad on varem käinud.

Minu vaatenurgast on nüanss ja keerukus mis tahes süsteemi kasutamisel selles, et tagada, et jää paksus on kindlasti piisav, et meie ülesandeid lahendada. Just sellest on jutt.

IT-sektoris paistab, et liiga palju on lähenemist "Võib-olla õnnestub". Palju inimesi installib tarkvara ja kasutab teeke lootuses, et neil vedada. Üldiselt vedab paljusid. Tõenäoliselt seetõttu see toimib.

- Minu pessimistlikul hinnangul näeb see välja nii: kui riskid on suured ja rakendus peab töötama, siis on vajalik toetus "Flantilt", võib-olla Red Hatilt, või vajame oma sisemist meeskonda, mis on spetsiaalselt Kubernetes'ega tegelemiseks, kes on valmis seda juhtima.

Dmitri: Objektiivselt on see tõsi. Väikesel meeskonnal on riske ise Kubernetes'esse siseneda.

Kas me vajame konteinerite kasutust?

- Kas sa saad rääkida, kui laialdaselt Kubernetes Venemaal üldiselt levinud on?

Dmitri: Mul ei ole neid andmeid ja ma ei ole kindel, kas kellelgi need üldse olemas on. Me räägime: "Kubernetes, Kubernetes", kuid on ka teine vaatenurk sellele küsimusele. Kui laialdaselt konteinerid levivad, ma ei tea, kuid tean ühte numbrit internetis olevatest raportitest, et 70% konteineritest orkestreeritakse Kubernetes'ega. See oli usaldusväärne allikas piisavalt suure valimi kohta globaalses mastaabis.

Järgmiseks küsimus - kas me vajame konteinerite kasutust? Minu isiklik tunne ja üldine seisukoht ettevõtte "Flant" osas on see, et Kubernetes on de facto standard.

Mitte midagi peale Kubernetes'e ei tule.

See on absoluutne mängumuutus infrastruktuuri haldamise valdkonnas. Lihtsalt absoluutne - enam ei ole Ansible'i, Chefi, virtuaalmachinesid, Terraform'i. Ma ei hakka rääkima vanadest käsitöömeetoditest. Kubernetes on absoluutne muutja, ja nüüd jääb ainult nii.

Selge, et mõnedel kulub paar aastat, teistel paar aastakümmet, et seda mõista. Mul ei ole kahtlusi, et ei tule midagi muud peale Kubernetes'e ja selle uue vaate: me ei häiri enam operatsioonisüsteemi, vaid kasutame infrastructure as code, ainult et mitte koodiga, vaid yml-ga - deklareeritud infrastruktuuri. Mul on tunne, et nii jääb alati.

- Ehk siis ettevõtted, kes ei ole veel Kubernetes'ele üle läinud, peavad kindlasti sellele üle minema, või jäävad unustusse. Kas ma sain sind õigesti aru?

Dmitri: See, that's not entirely correct. For instance, if we need to launch a DNS server, it can run on FreeBSD 4.10 and work perfectly for 20 years. Just operate and that's it. Perhaps after 20 years, we might need to upgrade something once. If we're talking about software in the format that we launched and it actually works for many years without any updates, without any changes, then, of course, Kubernetes won't be there. It's simply not needed.

Everything related to CI/CD—anywhere Continuous Delivery is required, where version updates are needed, where active changes are necessary, anywhere where resilience must be established—only Kubernetes fits here.

About microservices

— Here I have a slight dissonance. To work with Kubernetes, both external and internal support are needed—that's the first point. The second is that when we're just starting development, we're a small startup, we have nothing yet, developing for Kubernetes or even for a microservice architecture can be challenging, and it's not always justified economically. I'm curious about your opinion—should startups right from the start begin writing for Kubernetes or should they first create a monolith and then transition to Kubernetes?

Dmitri: Great question. I have a presentation about microservices. “Microservices: size matters.” I've encountered many times that people try to hammer nails with a microscope. The approach itself is correct; we design our internal software projects precisely this way. But when doing so, one must clearly understand what they are doing. Most of all in microservices, I dislike the term “micro.” It historically emerged, and for some reason, people think that micro means very small, smaller than a millimeter, like a micrometer. That's not the case.

For example, there's a monolith that 300 people write, and everyone involved in the development understands that there are issues, and it needs to be broken down into micro-pieces—about 10, with each being written by at least 30 people. This is important, necessary, and cool. However, when a startup approaches us with 3 very cool and talented guys having written 60 microservices on a whim, I invariably look for some calming medicine.

Minu arvates on sellest juba räägitud tuhanded kordi — oleme saanud hajutatud monoliidi ühes või teises vormis. See pole majanduslikult mõttekas, see on üldiselt väga keeruline. Lihtsalt olen seda nii palju kordi näinud, et mul on tõeliselt valus, seetõttu jätkan sellest rääkimist.

Algsesse küsimusse, et konflikt eksisteerib selle vahel, et Kubernetes on hirmutav kasutada, sest pole selge, mis seal võib puruneda või mitte töötada, ja teisest küljest on selge, et kõik liigub sinna ja midagi muud ei saa olema. Vastus on kaaluda kasu, mis tuleb, ja ülesannete mahtu, mille te suudate lahendada. See on ühe kaalu poole. Teiselt poolt on riskid, mis on seotud seiskamise või reageerimisaega, kättesaadavuse taset — töö näitajate vähenemisega.

Siin on asi nii — kas me liigume kiiresti edasi ja Kubernetes võimaldab paljusid asju teha palju kiiremini ja paremini, või kasutame usaldusväärseid, ajaga tõestatud lahendusi, kuid liigume palju aeglasemalt. Selle valiku teeb iga ettevõte. Seda võib vaadelda nagu radade hulgas — kui lähed esmakordselt, võid kohata madu, tiigrit või raevu täis mägra, ja kui oled käinud 10 korda — oled raja läbi jalutanud, oksad eemal viinud ning on lihtsam käia. Iga korraga muutub rada laiemaks. Hiljem on see asfalttee, ja veel hiljem ilus bulvar.

Kubernetes ei seisa paigal. Jälle küsimus: Kubernetes, ühelt poolt, on 4-5 binaarfaili, teiselt poolt — see on kogu ökosüsteem. See on opsüsteem, mis meil masinates töötab. Mis see on? Ubuntu või Curios? See on Linuxi kernel, hunnik lisakomponente. Kõik need asjad on siin ühe mürkmaoga tee pealt eemaldatud, seal on aed pandud. Kubernetes areneb väga kiiresti ja dünaamiliselt ning riskide maht, avastamata ala iga kuuga väheneb ja seega need kaalud saavad tasakaalu.

Vastates küsimusele, mida teha idufirmaga, ütleksin, et tulge Flantele, makske 150 000 rubla ja saage võtmed kätte DevOps teenus. Kui olete väike idufirma, kus tegutseb paar arendajat, siis see toimib. Selle asemel, et palgata oma DevOps, kellele tuleb õpetada, kuidas teie probleeme lahendada ja maksta selle aja eest palka, saate võtmed kätte lahenduse kõikidele küsimustele. Jah, on mõned miinused. Meie, kui väline teenusepakkuja, ei saa olla nii kaasatud ja kiiresti reageerida muudatuste tegemisele. Kuid meil on tohutult kogemusi, valmis praktikaid. Me garanteerime, et igas olukorras mõistame me kiirelt ja lahendame iga Kubernetes'e küsimuse.

Ma soovitan kategooriliselt idufirmadele ja juba välja kujunenud äridele välistada seni, kuni suudate eraldada vähemalt 10-mehelise tegevusmeeskonna, sest muidu pole sellel mõtet. See on kategooriliselt mõistlik äri väljastada.

Amazonist ja Google'ist

— Kas saab Amazonilt või Googlest pakutavat lahendust välisteenuse osutajana käsitleda?

Dmitri: Jah, loomulikult, see lahendab teatavad küsimused. Kuid on nüansse. Sa pead ikkagi aru saama, kuidas seda kasutada. Näiteks on Amazon AWS töökorralduses tuhandeid pisiasju: Load Balancer tuleb eelnevalt ette valmistada või paluda, et „meie juurde tuleb liiklust, palun valmistage Load Balancer ette!” Need nüansid tuleb teada.

Kui pöördute inimeste poole, kes sellega tegelevad, saate kohe näiliselt kõik tüüpilised asjad kaetud. Praegu on meil 40 inseneri, aastaks lõpus on neid tõenäoliselt 60 — me oleme kõigi nende asjadega juba kokku puutunud. Isegi kui mõnel projektil seisame silmitsi uue probleemiga, küsime me juba kiirelt üksteiselt, et teada, kuidas lahendada.

Tõenäoliselt on vastus selline — jah, hosted-ajalugu lihtsustab mingi osa. Küsimus on selles, kas olete valmis nende hostide usaldama ja kas nad lahendavad teie probleemid. Amazon ja Google on hästi tõestanud oma võimeid. Kõikide meie juhtumite puhul — kindlasti. Meil pole rohkem positiivseid kogemusi. Kõik teised pilved, millega me oleme proovinud töötada, loovad väga palju probleeme — ja Ager, ja kõik, mis on Venemaal, ja kõikvõimalikud OpenStack erinevates elluviimistes: Headster, Overage — kõik, mida soovite. Need kõik loovad probleeme, mida ei taha lahendada.

Seega, vastus on jah, kuid tegelikult ei ole küpsed hosted-lahendused kuigi palju.

Kelle on Kubernetes vajalik?

— Aga kellele on Kubernetes vajalik? Kes peaks juba Kubernetesile üle minema, kes on tüüpiline klient, kes tuleb just Kubernetes'i pärast?

Dmitri: Küsimus on huvitav, sest praegu just Kubernetes'e lainel tulevad meile paljud: "Me teame, et teil on Kubernetes, tehke meile!". Vastame neile: "Härrad, me ei tegele Kubernetes'ega, me tegeleme tootmise ja kõikide sellega seotud asjadega". Sest tootmise tegemine ilma kogu CI/CD ja selle looga on praegu lihtsalt võimatu. Kõik on loobunud eristamisest, et meil on arendamine arendamine ja seejärel opereerimine opereerimine.

Meie kliendid ootavad erinevaid asju, kuid kõik ootavad mingit head imet, et neil on mingid probleemid ja praegu – hop! – Kubernetes lahendab need. Inimesed usuvad imedesse. Nad mõistavad mõistusega, et imet ei toimu, kuid hingega loodavad – äkki see Kubernetes lahendab kõik, temast räägitakse nii palju! Äkki ta nüüd – tšah! – ja hõbedane kuul, tšah! – ja meil on 100% tööaeg, kõik arendajad saavad 50 korda välja lasta, mis iganes tootmisse ja see ei kuku. Kokkuvõttes, ime!

Kui sellised inimesed meile tulevad, ütlemme: "Vabandage, kuid imet ei juhtu". Terve olema, tuleb hästi toituda ja spordiga tegeleda. Usaldusväärse tootmise jaoks tuleb see usaldusväärselt ära teha. Mugava CI/CD jaoks tuleb see selliseks teha. See on palju tööd, mida tuleb teha.

Vastates küsimusele, kellele on Kubernetes vajalik – Kubernetes ei ole kellelegi vajalik.

Mõnedel inimestel on vale arusaam, et neil on Kubernetes vajalik. Inimestel on vaja, neil on sügavalt juurdunud vajadus lõpetada mõtlemine, tegelemine ja huvitamine kõikide infrastruktuuri probleemidega ja nende rakenduste käitamise probleemidega. Nad tahavad, et rakendused lihtsalt töötaksid ja lihtsalt deploy'itakse. Nende jaoks on Kubernetes lootus, et nad lõpetavad kuulmast lugusid, et "me olime seal lagunemas", või "me ei saa välja minna", või midagi muud.

Meile tuleb tavaliselt tehniline direktor. Temalt küsitakse kahte asja: ühelt poolt, andke meile funktsioonid, teiselt poolt – stabiilsus. Me pakume seda enda peale võtta ja teha. Hõbedane kuul, täpsemalt hõbetatud, on see, et sa lõpetad nende probleemide üle mõtlemise ja aja raiskamise. Sul on spetsiaalsed inimesed, kes selle küsimuse lahendavad.

Vormulatsioon, et meil või kellelgi on vaja Kubernetes't - on vale.

Kubernetes on adminnidele väga vajalik, sest see on tõeliselt huvitav mänguasi, millega saab mängida, nokitseda. Olgem ausad - kõik armastavad mänguasju. Me kõik oleme kuskil lapsed, ja kui me näeme uut, tahame sellega mängida. Mõnel on see juba välja lülitatud, näiteks adminni töös, sest on juba mänginud ja on nii tüdinud, et ei taha enam. Kuid see ei ole kellelgi täielikult välja lülitatud. Näiteks, kui mulle mänguasjad süsteemiadministreerimise ja DevOpsi valdkonnas juba ammu ei meeldi, siis armastan ma ikkagi mänguasju, ostan ikka uusi. Kõik inimesed tahavad mingil viisil ikka mingeid mänguasju.

Ärge mängige tootmisprotsessiga. Midagi, mida ma kategooriliselt ei soovita teha ja mida ma praegu massiliselt näen: 'Ah, uus mänguasi!' - kiirustame seda ostma, ostsime ja: 'Võtame selle nüüd kooli, näitame kõikidele sõpradele'. Ärge tehke nii. Vabandan, mul on lihtsalt lapsed, nad kasvavad, ma märkasin pidevalt midagi lastest, tajun seda enda juures ja üldistan seejärel ka teistel.

Lõplik vastus: Kubernetes't ei ole teil vaja. Teil tuleb lahendada oma probleemid.

Saame saavutada seda, et:

• toode ei kuku;
• isegi kui ta püüab kukkuda, teame me sellest eelnevalt ja saame midagi alusele panna;
• saame seda muuta nii kiiresti, kui me vajame vastavalt äri vajadustele, ja teha seda mugavalt, see ei tekita meile probleeme.

Reaalseid vajadusi on kaks: usaldusväärsus ja dünaamilisus/paindlikkus rakenduste juurutamisel. Kõik, kes praegu teevad mingisuguseid IT-projekte, olenemata ettevõtte tüübist - tarkvara maailma lihtsustamiseks, ja kes seda mõistavad, peavad lahendama need vajadused. Kubernetes õigesti lähenedes, õige arusaamise ja piisava kogemusega võimaldab neid lahendada.

Serverless'i kohta

- Kui vaadata tulevikku, siis püüdes lahendada probleem infrastruktuuri peavaludest, juurutamise kiirusest ja rakenduse muutmise kiirusest, ilmuvad uued lahendused, näiteks serverless. Kas tunned sa mingit potentsiaali selle suuna osas ja ütleme, et ohtu Kubernetes'ele ja sarnastele lahendustele?

Dmitri: Siin tuleb jälle märkida, et ma ei ole ennustaja, kes vaatab ette ja ütleb — nii läheb! Kuigi ma just tegin sama. Vaatan jalge ette ja näen seal hulgaliselt probleeme, näiteks kuidas transistore arvutites kasutatakse. Naljakas, eks? Me kohtame mingeid vigu CPU-s.

Serverless'i tegemine peab olema piisavalt usaldusväärne, odav, efektiivne ja mugav, lahendades kõik ökosüsteemiga seotud küsimused. Siin olen nõus Elon Muskiga, et inimkonna jaoks on vajalik teine planeet, et tagada töökindlus. Kuigi ma ei tea, mida ta ütleb, saan aru, et ma ei ole valmis Marsile reisima ja see ei juhtu homme.

Serverless on ideoloogiliselt õige asi, nagu inimkonna jaoks töökindlus — kaks planeeti on parem kui üks. Aga kuidas seda praegu teha? Ühe ekspeditsiooni saatmine ei ole probleem, kui sellele keskenduda. Saata mitu ekspeditsiooni ja asustada sinna mitu tuhat inimest tundub ka reaalne. Ent täieliku töökindluse saavutamine, et pool inimkonnast seal elaks, tundub praegu võimatu ja arutlemise alt väljas.

Serverless on sama asi: see on äge, kuid kaugel 2019. aasta probleemidest. Ligikaudu 2030 — elame selle ajani. Ma ei kahtle, et elame, kindlasti elame (korrake seda enne magamaminekut), aga praegu tuleb lahendada teisi probleeme. See on nagu usk muinasjutu poni Rainbow'sse. Jah, paar protsenti juhtumitest lahendatakse ja lahendatakse suurepäraselt, kuid subjektiivselt on serverless nagu vikerkaar… Minu jaoks on see teema liiga kaugel ja liiga arusaamatu. Ma ei ole valmis rääkima. 2019. aastal ei saa ühegi rakenduse serverless'iga kirjutada.

Kuidas arendatakse Kubernetes't

— Seni kui me liikume selle potentsiaalselt suurepärase tuleviku suunas, kuidas sa arvad, kuidas Kubernetes ja selle ümber olev ökosüsteem arenevad?

Dmitri: Ma olen sellele palju mõelnud ja mul on selge vastus. Esiteks – statefull – stateless’it on kergem teha. Kubernetes investeeris alguses rohkem sellesse, sealt kõik algas. Stateless töötab Kubernetes'is praktiliselt ideaalselt, lihtsalt pole millegi kallal norida. Statefulliga on veel palju probleeme, tegelikult peensusi. Meil töötab seal juba kõik ideaalselt, aga see oleme meie. Selleks, et see toimiks kõigil, on vaja veel vähemalt paar aastat. See ei ole arvutatud näitaja, vaid minu tunne peast.

Lühidalt, statefull peab väga tugevasti – ja tuleb – arenema, sest kõik meie rakendused säilitavad staatust, stateless-rakendusi ei eksisteeri. See on illusioon, alati on vajalik mingi andmebaas ja midagi veel. Statefull on kõikvõimalike asjade sirgendamine, kõikide bugide parandamine, kõikide probleemide lahendamine, millega praegu silmitsi seisame – nimetame seda vastuvõtmiseks.

Uurimata taseme, lahendamata probleemide taseme, tõenäosuse taseme millegagi kokku puutuda, hakkab oluliselt vähenema. See on oluline lugu. Ja operaatorid – kõik, mis on seotud haldustoimekuse, juhtimisloogika kodeerimisega, et saavutada lihtne teenus: MySQL lihtne teenus, RabbitMQ lihtne teenus, Memcache lihtne teenus, – kõik need komponendid, mis meil on vajalikud, et saada kõike karbist garanteeritult toimima. See lahendab just neid muresid, et me tahame andmebaasi, aga ei taha seda hallata, või tahame Kubernetes't, aga ei taha seda hallata.

See lugu operaatorite arengust mingis vormis on lähiaastatel oluline.

Ma arvan, et töö lihtsus peaks oluliselt tõusma – kast hakkab muutuma üha mustemaks, üha usaldusväärsemaks, koos üha lihtsamate reguleerimisvõimalustega.

Ma kuulasin kunagi YouTube'is 80ndate vana intervjuud Isaac Asimoviga show’s Saturday Night Live – saade, mis on nagu Urgant, aga huvitavam. Teda küsiti arvutite tuleviku kohta. Ta ütles, et tulevik on lihtsuses, nagu see oli raadioaparaadi puhul. Raadioaparaat oli alguses keeruline asi. Et signaali kinni püüda, pidi 15 minutit nuppude keeramist tegema, keerama nuppusid ja tegelikult teadma, kuidas kõik töötab, mõistma raadiolainete edastamise füüsikat. Lõpuks jäi raadiole vaid üks nupp.

Praegu, 2019. aastal, milline raadio on? Autotasku raadio leiab kõik sagedused, jaamade nimed. Protsessi füüsika pole 100 aasta jooksul muutunud, kuid kasutusmugavus on muutunud. Praegu, ja mitte ainult praegu, juba 1980. aastal, kui toimus intervjuu Asimoviga, kasutasid kõik raadiot ja keegi ei mõelnud sellele, kuidas see töötab. See lihtsalt töötas — see on fakt.

Asimov ütles siis, et arvutitega on sama — kasutusmugavus tõuseb. Kui 1980. aastal pidi arvuti nuppude vajamiseks omama erilist haridust, siis tulevikus see nii ei ole.

Mul on tunne, et Kubernetesega ja infrastruktuuriga juhtub samuti, et kasutusmugavus tõuseb oluliselt. See on, minu arvates, ilmne — see on silmnähtav.

Mis saab inseneridest?

— Aga mis saab inseneridest, süsteemiadministraatoritest, kes toetavad Kubernetes’i?

Dmitri: Mis juhtus raamatupidajaga pärast 1C ilmumist? Umbes sama asi. Enne arvutati paberil — nüüd programmis. Tootlikkus on tõusnud kordades, kuigi töö ei ole kadunud. Kui varem oli pirni vahetamiseks vaja 10 inseneri, siis nüüd piisab ühest.

Tarkvara ja ülesannete hulk kasvab praegu kiiresti, rohkem kui uusi DevOps’e ilmub ja efektiivsus tõuseb. Praegu on turul konkreetne puudus ja see kestab kaua. Hiljem jõuab kõik teatud normaalsusesse, kus töö efektiivsus tõuseb, tuleb järjest rohkem serveriteta lahendusi, Kubernetes’esse ühendatakse neuronvõrk, mis valib kõik ressursid just nagu vaja, ja teeb kõik ise, just nagu peab — inimene seisma ja mitte segada.

Kuid lahendusi peab keegi ikka tegema. On selge, et selle isiku kvalifikatsioon on kõrgem. Praegu ei vaja raamatupidamisosakonnas enam 10 töötajat, kes raamatupidamisraamatuid peavad, et nende käsi ei väsiks. See on lihtsalt üleliigne. Paljusid dokumente skaneeritakse automaatselt, need tuvastatakse elektroonilise dokumendihalduse süsteemi poolt. Piisab ühest nutikast pea raamatupidajast, kellel on palju suuremad oskused ja hea arusaamine.

Üldiselt on selline teekond kõigis valdkondades. Autode puhul on see sama: varem kuulus autoga alati kaasa autojuht ja kolm juhti. Nüüd on auto juhtimine kõige lihtsam protsess, milles me kõik osaleme iga päev. Keegi ei mõtle, et auto on midagi keerulist.

DevOps või süsteemi inseneria ei kao kuskile – töö kõrgtase ja efektiivsus tõuseb.

– Olen kuulnud huvitavat ideed, et tegelikult tööd arv liitub.

Dmitri: Muidugi, sada protsenti! Sest tarkvara, mida me kirjutame, kasvab pidevalt. Küsimuste arv, mida me tarkvaraga lahendame, kasvab pidevalt. Töö hulk suureneb. Praegu on DevOps turg kohutavalt ülekuumenenud. See on nähtav palgakeerukuse järgi. Tegelikult, detailidesse minemata, peaks olema noori, kes tahavad X, keskmisi, kes tahavad 1,5X, ja vanemaid, kes tahavad 2X. Aga praegu, kui vaadata Moskva DevOps palkade turgu, siis noor tahab X-st kuni 3X ja vanem tahab X-st kuni 3X.

Keegi ei tea, kui palju see maksab. Palga tase mõõdetakse sinu enesekindlusega – täielik kaos, kui aus olla, turgu on kohutavalt üle kuumenenud.

Muidugi, see olukord muutub väga varsti – teatud küllastumine peab saabuma. Tarkvara arendamine ei ole aga selline – hoolimata sellest, et arendajaid vajatakse kõigil ja kõigile häid arendajaid, turul mõistetakse, kui palju keegi maksab – tööstus on stabiliseerunud. DevOps ei ole praegu nii.

– Selles, mida ma olen kuulnud, järeldasin, et praegusel süsteemi administreerijal ei tasu liiga palju muretseda, aga on aeg oskusi arendada ja valmistuda sellele, et homme tööd on rohkem, aga see on kõrgema kvalifikatsiooniga.

Dmitri: Sadaprotsendiliselt. Üldiselt elame 2019. aastal ja elu reegel on selline: elukestev õppimine – me õpime kogu elu. Minu arvates teavad ja tunnevad seda kõik juba, aga vähe знать – tuleb teha. Igal päeval peame muutuma. Kui me seda ei tee, siis varem või hiljem visatakse meid ametidest kõrvale.

Olge valmis järskudeks 180-kraadisteks pöördeks. Ma ei välista olukordi, kus midagi kardinaalselt muutub, mõeldakse välja midagi uut - selliseid asju juhtub. Hüppa! - ja nüüd tegutseme me teisiti. Oluline on sellele valmis olla ja mitte muretseda. Võib juhtuda, et homme osutub kõik, mida ma teen, tarbetuks - pole hullu, ma olen terve elu õppinud ja olen valmis õppima midagi uut. See ei ole probleem. Töökoha turvalisuse pärast ei tasu muretseda, aga tuleb olla valmis pidevalt uute asjade õppimiseks.

Soovid ja minut reklaami

- Kas sul on mingi soov?

Dmitri: Jah, mul on mitu soovi.

Esimene ja materiaalsem - tulge ja subsribeerige YouTube. Kallid lugejad, minge YouTube'i ja subscribeerige meie kanalile. Umbes kuu aja pärast alustame aktiivset ekspansiooni videoteenuses, meil on tulemas hulk hariduslikku sisu Kubernetesest, avatud ja erinevat: põhilistest praktilistest asjadest laborite juurde, sügavate teoreetiliste asjadeni ning kuidas rakendada Kuberneteset põhimõtete ja mustrite tasandil.

Teine materiaalsem soov - minge GitHub ja pange meile tähti, sest me toitume neist. Kui te ei pane meile tähti, siis me ei saa süüa. See on nagu mana arvutimängus. Me teeme midagi, teeme, pingutame, keegi ütleb, et need on kohutavad jalgrattad, keegi, et kõik on üldse vale, aga me jätkame ja tegutseme täiesti ausalt. Me näeme probleemi, lahendame selle ja jagame kogemusi. Seetõttu palun pange meile täht, teilt ei kulu midagi, aga me saame juurde, sest me toitume neist.

Kolmas, oluline ja mitte enam materiaalsem soov - lopetage uskumine muinasjuttudesse. Te olete spetsialistid. DevOps on väga tõsine ja vastutustundlik amet. Lõpetage mängimine töökohal. Kujutage ette, et astute haiglasse ja seal arst eksperimentib teie peal. Ma saan aru, et see võib kellelegi haiget teha, aga tõenäoliselt ei käi see teie kohta, vaid kellegi teise. Ütlege teistele, et nad ka lõpetaksid. See tõesti rikub elu meile kõigile - paljud hakkavad suhtuma infrastruktuuri haldusesse, adminnidesse ja DevOps'i, kui vendadesse, kes jälle midagi rikkusid. See 'rikkujad' juhtub enamasti seetõttu, et me hakkasime mängima, mitte ei vaadanud külma meele jaoks, et siin on nii ja seal on naa.

See ei tähenda, et eksperimenteerimine pole vajalik. Eksperimenteerimine on vajalik, me teeme seda ise. Ausalt öeldes, me mõnikord mängime ka — see on muidugi väga halb, aga miski inimsuhetes ei ole meile võõras. kuulutame 2019. aasta tõsiste läbimõeldud katsete aastaks, mitte mängudeks tootmises. Tõenäoliselt nii.

— Suur tänu!

Dmitri: Aitäh sulle, Vitali, nii aja kui ka intervjuu eest. Kallid lugejad, suur aitäh teile, kui te juhuslikult selle hetkeni jõudsite. Loodan, et vähemalt paar mõtet oleme teile edastanud.

Intervjuus puudutas Dmitri werfi küsimust. Praegu on see universaalne Šveitsi arm, mis lahendab peaaegu kõik probleemid. Kuid nii ei olnud alati. F DevOpsConf  estivalil RIT++ Dmitri Stolyarov räägib sellest tööriistast üksikasjalikult. Ettekandes „werf — meie CI/CD tööriist Kuberneteses“ on kõik: probleemid ja varjatud nüansid Kuberneteses, nende raskuste lahendamise võimalused ja werfi praegune rakendamine üksikasjalikult. Liituge 27. ja 28. mail, loome ideaalseid tööriistu.

Allikas: habr.com