Kubernetes vallutab maailma. Millal ja kuidas?

Eelõhtul DevOpsConf Vitaly Khabarov tegi intervjuu Dmitri Stolyarovile (distol), tehnilise direktoriga ja ettevõtte "Flant" kaasasutajaga. Vitaly küsis Dmitrilt, millega "Flant" tegeleb, Kubernetesest, ökosüsteemi arengust, toetamisest. Arutati, miks on Kubernetes vajalik ja kas see on üldse vajalik. Rääkisime ka mikroteenustest, Amazon AWS-st, lähenemisest "Mul on vedanud" DevOps-is, Kubernetesese tulevikust, miks, millal ja kuidas see maailma vallutab, DevOps-i perspektiividest ja millega insenerid peaksid ette valmistuma heledas ja lähemas tulevikus koos lihtsustamise ja närvivõrkudega.

Intervjuu originaal podcasti vormis kuulake DevOps Defloope — venekeelses podcastis DevOps-ist, ning allpool on tekstiversioon.

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

Flantist

— Dima, tere. Sa oled tehniline direktor "Flant" ja samuti selle asutaja. Räägi palun, millega teie ettevõte tegeleb ja mis on sinu roll seal?

Dmitri: Väliselt näib, et me oleme sellised tüübid, kes käivad ringi, seadistavad kõigile Kuberneteset ja teevad sellega midagi. Aga see ei ole tõsi. Alustasime ettevõttena, mis tegeleb Linuxiga, kuid juba ammu on meie peamine tegevus tootmis- ja high-load projektide võtmed kätte andmine. Tavaliselt ehitame kogu infrastruktuuri nullist ja vastutame selle eest kaua. Seetõttu on peamine töö, mida Flant teeb ja mille eest raha teenib – vastutuse võtmine ja tootmise võtmed kätte andmine.




Mina, kui tehniline direktor ja üks ettevõtte asutajatest, tegelen pidevalt sellega, et välja mõelda, kuidas suurendada tootmise kättesaadavust, lihtsustada selle kasutamist, kergendada adminnide elu ja muuta arendajate elu mugavamaks.

Kubernetesest

— Viimasel ajal olen Flant’i kaudu näinud palju ettekandeid ja artiklites Kubernetesest. Kuidas te selle juurde jõudsite?

Dmitri: Olen sellest juba palju korda rääkinud, aga mul ei ole kahju seda kordamast. Pean õigeks selle teema kordamist, kuna tekib segadus põhjuse ja tagajärje vahel.

Me olime tõeliselt vajanud tööriista. Olime silmitsi paljude probleemidega, võitlesime, ületasime neid erinevate lahendustega ja tundsime tööriista vajadust. Proovisime läbi palju erinevaid variante, ehitasime oma jalgrattaid ja kogume kogemusi. Aja jooksul jõudsime sinna, et hakkasime Dockerit kasutama peaaegu kohe, kui see ilmus, umbes 2013. aastal. Selle ilmumise hetkeks oli meil juba palju kogemusi konteineritega ja olime juba kirjutanud midagi, mis sarnanes „Dockerile” - mingid omatehtud lahendused Pythonis. Dockeri ilmumisega sai võimalikuks lahendustest loobuda ja kasutada usaldusväärset ning kogukonna poolt toetatud lahendust.

Kubernetesega on lugu sarnane. Hetkel, mil see hakkas populaarsust koguma – meie jaoks oli see versioon 1.2, – oli meil juba hunnik lahendusi, mis olid ehitatud Shelli ja Chefiga, millega püüdsime Dockerit orkestreerida. Me vaatasime tõsiselt Rancheri ja erinevate teiste lahenduste poole, kuid siis ilmus Kubernetes, kus on kõik rakendatud täpselt nii, nagu meie oleksime teinud, või isegi paremini. Mitte millegagi ei saa nuriseda.

Jah, siin on mingi lõpetamata töö, seal on mingi lõpetamata töö — palju lõpetamata asju, ja 1.2 on üldse hirmus, aga… Kubernetes on nagu ehitame maja — vaatad projekti ja mõistad, et see saab olema äge. Kui majal on praegu alus ja kaks korrust, siis mõistad, et pole mõtet veel sisse kolida, aga tarkvaraga selliseid probleeme ei ole — seda saab juba kasutada.

Meil ei olnud hetke, kus mõtleksime, kas kasutada Kubernetes või mitte. Me ootasime seda kaua enne, kui see ilmus, ja üritasime ise sarnaseid lahendusi luua.

Umbes Kubernetes

— Kas te osalete otse Kubernetes enda arenduses?

Dmitri: Keskmiselt. Pigem osaleme ökosüsteemi arendamises. Me saadame mingisuguse arvu pull request'e: Prometheusesse, igasugustesse operaatoritesse, Helm'i — ökosüsteemi. Kahjuks ei ole ma võimeline jälgima kõike, mida me teeme, ja võin eksida, aga meie poolt ei ole ühtegi puhastust tuumasse.

— Samal ajal arendate te ka palju oma tööriistu Kubernetes'i ümber?

Dmitri: Meie strateegia on järgmine: me teeme pull-request'e kõiges, mis juba olemas on. Kui sinna pull-request'e ei aktsepteerita, siis forkime need endale ja elame edasi, kuni nad meie ehitustega vastu võetakse. Siis, kui see jõuab upstream'i, naaseme tagasi upstream'i versiooni juurde.

Näiteks, meil on Prometheus-operator, millega oleme juba umbes 5 korda oma versiooni ja upstream'i vahel vahetanud. Kui meil on vaja mingit funktsiooni, saatsime pull-request'i, kuid me ei taha oodata, kuni see upstream'is välja antakse. Seetõttu kogume endale, käivitame oma versiooni koos vajaliku funktsiooniga kõigis oma klastrites. Siis, näiteks, pöördub upstream meie poole, öeldes: „Poisid, teeme seda üldisema juhtumi jaoks”, ja me, või keegi teine, viime selle lõpule, mis lõpuks taas sulandub.

Kõike, mis eksisteerib, püüame arendada.. Paljusid elemente, mis veel puuduvad, pole veel välja mõeldud või on välja mõeldud, kuid pole veel teostatud - meie teeme. Ja mitte sellepärast, et meile meeldib protsess ise või jalgrattatootmine kui valdkond, vaid lihtsalt seetõttu, et meil on seda tööriista vaja. Sageli küsitakse, miks me tegime seda või teist asja? Vastus on lihtne - nii on, sest pidime edasi liikuma, lahendama mõne praktilise probleemi, ja lahendasime selle tööriista abil.

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

Flanta tööriistad

— Ma tean, et Flantal on praegu addon-operatorid, shell-operatorid, dapp/werf tööriistad. Nii 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 nii?

Dmitri: Meil on GitHubis palju muud. Mida ma kohe meenutan, on statusmap — Grafana paneel, mis on kõigile meeldinud. Seda mainitakse pea igas teises artiklis Kubernetes'ese jälgimise kohta Mediumis. Statusmap'i lühidalt kirjeldada on keeruline — selle kohta on vaja eraldi artikkel, kuid see on väga kasulik tööriist aja jooksul statiuse jälgimiseks, kuna Kubernetes'is peame sageli näitama staatust aja jooksul. Meil on ka LogHouse — see on ClickHouse'i ja musta maagia baasil logide kogumise lahendus Kubernetes'es.

Palju utiliite! Ja tuleb veel rohkem, kuna teatud sisemised lahendused avaldatakse sel aastal. Suurte seas addon-operaatorite baasil on hulgaliselt lisandeid Kubernetes'e jaoks, näiteks kuidas õigesti seadistada sertifikaadi haldamise tööriista Sert Manager - see on tööriist sertifikaatide haldamiseks, samuti kuidas õigesti seadistada Prometheus koos hulga lisamahutitega - neid on umbes kakskümmend erinevat binaarfaili, mis ekspordivad andmeid ja koguvad midagi, Prometheusel on suurepärane graafika ja häired. Kõik need on lihtsalt hulgaliselt lisandeid Kubernetes'e jaoks, mis paigaldatakse klastrisse, muutes selle tavalisest millekski ägedaks, keerukaks, automaatseks, kus paljud küsimused on juba lahendatud. Jah, me teeme palju.

Ökosüsteemi areng

— Minu arust on see väga suur panus selle tööriista ja selle kasutusmeetodite arengusse. Kas sa võiksid umbes hinnata, kes veel panustaks nii suurelt ökosüsteemi arendamisse?

Dmitri: Venemaal ei ole mitte ühtegi neist ettevõtetest, kes meie turul tegutsevad — keegi ei ole lähedal.. Loomulikult on see dramaatiline väide, kuna on suured tegijad nagu Mail ja Yandex — nad teevad samuti midagi Kubernetesega, kuid isegi nemad ei ole saavutanud globaalsete ettevõtete investeeringutele lähedale, kes teevad palju rohkem kui meie. „Flant“ on keeruline võrrelda 80 inimese meeskonna ja Red Hatiga, kus ainult ühe Kubernetes'i jaoks on 300 inseneri, kui ma ei eksi. Meie RnD osakonnas on 6 inimest, sealhulgas mina, kes arendavad kõiki meie tööriistu. 6 inimest versus 300 Red Hati inseneri — seda on keeruline võrrelda.

— Sellegipoolest, kui isegi need 6 inimest suudavad teha midagi tõeliselt kasulikku ja jagatavat, kui nad seisavad silmitsi praktilise ülesandega ja annavad lahenduse kogukonnale — see on huvitav juhtum. Mõistan, et suurtes tehnoloogiaettevõtetes, kus on oma arendamine ja Kubernetes'i tugimeeskond, võiksid põhimõtteliselt olla samasugused tööriistade arendamise võimalused. See on neile näide, et saab arendada ja anda kogukonnale, andes tõuke kogu kogukonnale, kes kasutab Kubernetes'e.

Dmitri: Tõenäoliselt on see integreerija omadus, meie eripära. Meil on palju projekte ja näeme erinevaid olukordi. Meie peamine viis, kuidas lisaväärtust luua, on analüüsida neid juhtumeid, leida ühisosad ja maksimaalselt odavdada neid meie jaoks. Sellega tegeleme aktiivselt. Mul on keeruline rääkida Venemaast ja maailmast, aga meil on ettevõttes umbes 40 DevOps-inseneri, kes tegelevad Kubernetesega. Ma ei usu, et Venemaal on palju ettevõtteid, kellel on võrreldav arv spetsialiste, kes oskavad Kubernetesega tegeleda, kui neid üldse on.

Ma mõistan kõike DevOps-inseneri ametinimest. Kõik teavad ja on harjunud neid DevOps-inseneriteks kutsuma, seda ei pea arutama. Need 40 suurepärast DevOps-inseneri seisavad iga päev silmitsi probleemidega ja lahendavad need. Me analüüsime seda kogemust ja proovime seda üldistada. Me teame, et kui see jääb meie sisse, muutub see aasta või kahe pärast kasutuks, kuna kuskil kogukonnas ilmub valmis tööriist. Pole mõtet seda kogemust endas hoida — see on lihtsalt vägivalla ja aja raiskamine dev/null'i. Seega ei ole meil seda kahju jagada. Avaldame selle suure rõõmuga ja mõistame, et seda tuleb avaldada, arendada, reklaamida, edendada, et inimesed kasutaksid seda ja jagaksid oma kogemusi — siis kõik kasvab ja elab. Kaks aastat hiljem ei satu tööriist prügikasti. Pole kahju jätkata jõudude investeerimist, sest on näha, et keegi kasutab sinu tööriista, ja kahe aasta pärast kasutavad seda juba kõik.

See on osa meie suurest strateegiast dapp/werf. Ei mäleta, millal me sellega alustasime, tundub, et umbes kolm aastat tagasi. Alguses oli see täiesti shellis. See oli super proof of concept, lahendasime mõned meie erilised ülesanded — see töötas! Aga shelli puhul on seal probleemid, seda on võimatu edasi arendada, shellis programmeerimine — see on tõeline väljakutse. Meil oli komme kirjutada Ruby's, seega tegime Ruby's midagi ümber, arendasime, arendasime, arendasime ja jõudsime olukorda, kus kogukond, rahvas, kes ei ütlenud „meie tahame või ei taha”, keeras Ruby'lt nina ära, kuigi see ei ole naljakas. Mõistsime, et peame kõik selle kirjutama Go's, et lihtsalt vastata kontrollnimekirja esimesele punktile: DevOps-tööriist peab olema staatiline binaarfail. Go's või mitte Go's ei ole nii oluline, aga parem on, kui see on staatiline binaarfail, kirjutatud Go's.

Panime jõudu, kirjutasime dappi Go's ümber ja nimetasime selle werf'iks. Dapp ei ole enam toetatud, seda ei arendata, see töötab mõnes viimases versioonis, kuid ülespoole on absoluutne uuendusteed, millele on võimalik järgida.

Miks dapp loodi

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

Dmitri: Esimene põhjus on koostamises. Alguses olime kokku puutunud tõsiste koostamisprobleemidega, kui Docker ei osanud multi-stage'i, ja me tegime multi-stage'i ise. Seejärel oli meil veel hulk küsimusi pildi puhastamise osas. Kõik, kes tegelevad CI/CD-ga, seisavad varem või hiljem silmitsi probleemiga, et on palju koostatud pilte, ja neid tuleb mingil viisil puhastada, et jätta alles vajalikud.

Teine põhjus on deploy. Jah, on Helm, kuid see lahendab vaid osa ülesandeid. Kuidas iganes see ka ei kõlaks, on kirjutatud, et "Helm - Kubernetes'e pakihaldur". Just see "the”. Veel on sõnad "Package Manager" - millised ootused tavaliselt pakihaldurilt? Me ütleme: "Package Manager - pane pakett paika!" ja ootame, et ta vastab: "Pakett on paigaldatud."

Huvitav on see, et me ütleme: "Helm, pane paket paika", ja kui ta vastab, et on paigaldanud, siis selgub, et ta vaid alustas installimist - andis Kubernetes'le käsu: "Käivitada see asi!", aga kas see käivitati või mitte, Helm seda küsimust üldse ei lahenda.

Seega on Helm lihtsalt tekstiline eeltöötlus, mis laadib andmed Kubernetes'esse.

Kuid me tahame igas väljundis teada, kas rakendus on tootmisse jõudnud või mitte? Kui see on tootmisse läinud, tähendab see, et rakendus on seal väljastatud, uus versioon on käivitatud ja see ei kuku kokku, vaid vastab korrektselt. Helm ei lahenda seda probleemi. Selle lahendamiseks tuleb kulutada palju vaeva, sest tuleb anda Kubernetes'ile käsk väljastamiseks ja jälgida, mis seal tegelikult toimub — kas see on välja läinud ja käivitatud. Lisaks on palju ülesandeid, mis on seotud väljastamise, puhastamise ja kogumisega.

Tunniplaanid

Sel aastal suundume me kohalikku arendusse. Tahame jõuda olukorda, nagu see oli Vagrant'is — sisestasime "vagrant up" ja meil olid virtuaalmasinad käivitatud. Tahame, et oleks projekt Git'is, kirjutame sinna "werf up" ja see käivitab kohaliku koopia sellest projektist, mis on käivitatud kohalikus mini-Kubes, koos kõikide arendamiseks mugavalt ühendatud kaustadega. Sõltuvalt arenduskeelest toimub see erinevalt, kuid siiski, et oleks mugav viia läbi kohalikke arendusi montaažifailide all.

Meie järgmine samm on tugevalt investeerida arendajate mugavusse. Ühe tööriistaga saab kiiresti kohapeal projekti käivitada, arendada, tõukuda Git-i ja see avaldatakse samamoodi stseenil või testides, sõltuvalt töövoogudest, ning seejärel sama tööriistaga minna tootmisse. See ühtsus, ühtlustamine ja infrastruktuuri reprodutseerimine kohalikust keskkonnast tootmiseni on meie jaoks väga oluline. Kuid werf-is pole seda veel, plaanime seda teha.

Aga tee dapp/werf juurde on alati olnud sama, nagu Kubernetes'i alguses. Oleme pidanud silmitsi seisma probleemidega, lahendades need ringteedega — välja mõtlema lahendused shellis, mis iganes. Siis oleme püüdnud neid ringteid kuidagi sirgendada, üldistada ja konsolideerida binaarideks, mida lihtsalt jagame.

On ka teine vaade kogu sellele loole, analoogiate kaudu.

Kubernetes on autotootmise raam ja mootor. Ei ole uksi, klaase, raadio ega muud — mitte midagi. Ainult raam ja mootor. Ja on Helm — see on rool. Lahe — rool on olemas, kuid vajalikud on ka roolipüsti, roolivõimendi, käigukast ja rattad, muidu ei saa.

werf on Kubernetes on veel üks komponent. Meil on praegu alfa-versioon werf'ist, kus näiteks Helm on täielikult integreeritud werf'i, sest meil on sellest lihtsalt kõrini. On palju põhjus, miks me seda teeme, ja ma räägin muudest aspektidest, miks me Helm'i koos Tiller'iga werf'i sisse integreerisime. dokumendil RIT++.

Praegu on werf palju integreeritum komponent. Meil on valmis süsteem, millega saame juba palju toiminguid teha. Ma ei tea autotest palju, aga see on suur plokk, mis lahendab piisavalt laia ülesannete spektrit. Me ei pea iseseisvalt kataloogis navigeerima, sobitama ühte detaili teisega ja mõtlema, kuidas need omavahel kokku panna. Saime valmis masina, mis lahendab kohe hulga ülesandeid. Kuid see põhineb kõikidel samadel avatud lähtekoodiga komponentidel, kasutab endiselt Docker'it kogumiseks, Helm'i osa funktsionaalsuse jaoks ja seal on veel mõned teised raamatukogud. See on integreeritud tööriist, et kiiresti ja mugavalt saada suurepärane CI/CD välja kastist.

Kas Kubernetes'e toetamine on keeruline?

— Sa räägid oma kogemusest, et hakkasite Kubernetesit kasutama, see on nagu raam, mootor, ja et sellele saab palju erinevat külge panna: kere, rool, pedaalid, istmed. Tuleb küsimus – kui keeruline on teile Kubernetesit toetada? Teil on ulatuslik kogemus, kui palju aega ja ressursse kulub teile just Kubernetes'i toetamiseks teistest asjadest eemal?

Dmitri: See on väga keeruline küsimus ja et vastata, tuleb mõista, mis on tugi ja mida me Kuberneteselt ootame. Kas sa avad selle?

— Niipalju kui mina tean ja kuidas ma näen, tahavad praegu paljud meeskonnad proovida Kubernetesit. Kõik tahavad sellega tegeleda, installeerivad seda enda kodudes. Mul on tunne, et inimesed ei mõista alati selle süsteemi keerukust.

Dmitri: Nii on.

— Kui keeruline on võtta ja paigaldada Kubernetes nullist, et see oleks tootmisvalmis?

Dmitri: Kuidas sa arvad, kui keeruline on südame siirdamine? Ma saan aru, et küsimus on provokatiivne. Skalpelliga sõitmine ja mitte eksimine – see ei ole nii keeruline. Kui sulle öeldakse, kust lõigata ja kuhu õmmelda, siis protseduur ise ei ole keeruline. Raskeks võib osutuda garanteerida igas kord, et kõik õnnestub.

Kubernetesi seadistamine ja töölepanek on lihtne: kliki! — see on valmis, installimiseks on palju viise. Aga mis juhtub, kui tekivad probleemid?

Tekivad alati küsimused — mida me veel ei arvesse võtnud? Mida me veel pole teinud? Milliseid Linuxi kerneliparametreid oleme valesti määranud? Jumal, kas me üldse määrasime need?! Millised Kubernetes'i komponendid me paigaldasime ja millised mitte? Küsimusi tekib tuhat, ja nendele vastamiseks on vaja 15-20 aastat kogemust selles valdkonnas.

Mul on selle teema kohta värske näide, mis võib avada probleemi mõtet: "Kas Kubernetes'e hooldamine on keeruline?" Mõned aega tagasi vaatasime tõsiselt, kas peaksime proovima Cilium'it Kubernetes'e võrgu lahendusena rakendada.

Selgitan, mis on Cilium. Kuberneteses on palju erinevaid võrgu alamsüsteemide rakendusi, ja üks neist on väga äge — see on Cilium. Mis on selle sisu? Aeg tagasi ilmnes kernelis võimalus kirjutada kernelihukke, mis mingil moel sekkuvad võrgu alamsüsteemi ja teistesse alamsüsteemidesse ning võimaldavad mööda minna suurtest osadest kernelis.

Linux-iadris on ajaloos ip rout, ülevaatused, sillad ja palju erinevaid vanu komponente, millel on 15, 20 või isegi 30 aastat ajalugu. Üldiselt nad toimivad, kõik on hästi, aga nüüd on konteinerite kiht tehtud ja see näeb välja nagu 15 tellist teineteise peal, samas, kui sa seisad selle peal ühel jalal — kummaline tunne. See süsteem on ajalooliselt arenenud paljude nüanssidega, nagu organi lisand. Mõnes olukorras on jõudlusega muresid, näiteks.

On olemas suurepärane BPF ja võimalus kirjutada tuumahook'e — poisid on teinud oma tuumahook'id. Pakett saab Linux-i tuuma, nad võtavad selle kohe alguses välja, töötlevad ise, kuidas vaja, ilma sildadeta, ilma TCP-ta, ilma IP-kihita — lühidalt, mööda kõigest, mis on Linux-i tuumas kirjutatud, ja siis visatakse kohe konteinerisse.

Mis välja tuli? Väga äge jõudlus, ägedad funktsioonid — lihtsalt fantastiline! Kuid vaatame seda ja näeme, et igas masinas töötab programm, mis ühendub Kubernetes API-ga ja saadud andmete põhjal genereerib C-koodi ja kompileerib binaarfaile, mis laaditakse tuuma, et need hook'id töötaksid kernel space'is.

Mis toimub, kui midagi läheb valesti? Me ei tea. Selle mõistmiseks tuleb kogu see kood läbi lugeda, kõiki loogikaid mõista ja see on üpris keeruline. Teisest küljest on olemas sillad, net-filterid ja ip-route — ma ei ole nende lähtekoodi lugenud, ega ka 40 inseneri, kes meie firmas töötavad. Võib-olla mõistavad mõned osad vähesed.

Ja mis siis? Tuleb välja, et on olemas ip-route, Linuxi tuum ja on uus tööriist — mis vahet seal on, me ei mõista kumbagi. Aga me kardame uut kasutada — miks? Sest kui tööriist on 30 aastat vana, siis 30 aasta jooksul on kõik vead leitud, kõik takistused esiotsa pandud ja kõigest teadmine ei ole vajalik — töötab nagu must kast ja töötab alati. Kõik teavad, kuhu diagnostikapeitli panna, millal tcpdump käivitada. Kõik tunnevad korralikult diagnostikavahendeid ja mõistavad, kuidas see komponentide kogum Linuxi tuumas töötab — mitte kuidas see on üles ehitatud, vaid kuidas seda kasutada.

Kuid suurepärasel Cilium'il ei ole veel 30 aastat, ta pole ka veel küps. Sama probleem on ka Kubernetesega, see on lihtsalt koopia. Et Cilium paigaldub kenasti, ning Kubernetes ka, aga kui midagi läheb tootmises valesti, kas olete suuteline kriitilises olukorras kiiresti mõistma, mis valesti läks?

Kui me räägime Kubernetes'e haldamise keerukusest — ei, see on väga lihtne, ja jah, uskumatult keeruline. Kubernetes töötab suurepäraselt iseenesest, kuid seal on miljard erinevat nüanssi.

Kohustuslik lähenemine ‘Mul võib vedada’

— Kas on olemas ettevõtteid, kus need nüansid peaaegu garanteeritult ilmuvad? Oletame, et Yandex äkki muudetakse kõik teenused Kubernetes'eks, seal on tohutu koormus.

Dmitri: Ei, see pole ju jutt koormusest, vaid kõige lihtsamast. Näiteks meil on Kubernetes, oleme sinna rakenduse välja pannud. Kuidas mõista, et see töötab? Valmis tööriista, et teada saada, et rakendus ei kukku, ei ole lihtsalt olemas. Valmis süsteemi, mis saadab häireid — ei ole, tuleb need häired ja iga graafik seadistada. Ja me värskendame Kubernetes'e.

Ubuntu 16.04 on. Võib öelda, et see on vana versioon, kuid me oleme sellega endiselt, kuna see on LTS. Seal on systemd, mille nüanss on see, et see ei puhasta C-gruppe. Kubernetes käivitab podid, loob C-grupid, seejärel kustutab podid ja mingil moel jäävad systemd lõiked alles. See viib selleni, et aja jooksul hakkab iga masin tugevalt aeglustuma. See ei ole isegi küsimus highloadist. Kui käivitatakse pidevalt podid, näiteks kui on Cron Job, mis pidevalt genereerib pode, siis masin Ubuntu 16.04 peal hakkab nädala pärast aeglustuma. Seal on pidev kõrge load average, kuna on loodud hunnik C-gruppe. See on probleem, millega puutub iga inimene, kes lihtsalt installib Ubuntu 16 ja kuberneeide pealt.

Kujutage ette, et ta kuidagi uuendab systemd-d või midagi muud, kuid Linuxi südamikus kuni 4.16 on veelgi naljakam — C-gruppide kustutamisel lekivad nad südamikus ja tegelikult ei kao. Seetõttu on kuu aja pärast sellel masinal peaaegu võimatu vaadata mälu statistikat podide kaupa. Me võtame väikese faili, töötame programmiga ja üks fail töötleb 15 sekundit, kuna süda loendab endas miljonit C-gruppi, mis justkui oleksid kustutatud, kuid ei ole — need lekivad.

Selliseid pisidetaile on seal ja siin endiselt tohutult palju. See ei ole küsimus, millega hiiglaslikud ettevõtted aeg-ajalt tohutute koormuste all silmitsi seisavad — ei, see on päevapoliitika. Inimesed saavad kuude kaupa elada nii — installisid Kubernetes'i, paigaldasid rakenduse — tundub, et töötab. Paljudele on see normaalne. Et kunagi see rakendus mingil põhjusel kokku kukub, ei kuule nad isegi, alarm ei tule, kuid nende jaoks on see normaalne. Varem elasime virtuaalmasinates ilma jälgimiseta, nüüd oleme kolinud Kubernetes'i ka ilma jälgimiseta — mis vahet seal on?

Küsimus on selles, et kui me käime jääl, ei tea me kunagi selle paksust, kui me seda eelnevalt ei mõõtnud. Paljud käivad ringi ja ei muretse, sest on seda juba varem teinud.

Minu arvates on igasuguste süsteemide kasutamise nüanss ja keerukus selles, et tagada, et jää paksus oleks piisav meie ülesannete täitmiseks. See ongi see, millest räägitakse.

IT-s tundub, et on liiga palju lähenemisi, kus loodetakse lihtsalt õnnele. Paljud paigaldavad tarkvara, kasutavad teeke, lootes, et neil on õnne. Üldiselt on paljudele õnnestunud. Võib-olla seepärast see töötabki.

— Minu pessimistlik hinnang on järgmine: kui riskid on suured ja rakendus peab töötama, siis on vajalik tugi "Flantilt", võib-olla Red Hatilt, või on vajalik oma sisemine meeskond, mis on spetsiaalselt välja pandud Kubernetes'ega töö tegemiseks ja kes on valmis selle jätkamiseks.

Dmitri: Objektiivselt on see tõsi. Väikesel meeskonnal on mõningane risk iseseisvalt Kubernetes'ega tegeleda.

Kas me vajame konteinerite kasutamist?

— Kas sa saaksid rääkida, kui laialdaselt Kubernetes Venemaal üldiselt levinud on?

Dmitri: Mul ei ole neid andmeid, ja ma ei ole kindel, kas neid on üldse kellelgi. Me räägime: „Kubernetes, Kubernetes”, kuid küsimusele on ka teine vaade. Kui laialt on konteinerid levinud, ei tea ma samuti, aga tean, et interneti aruannete kohaselt orkestreerib Kubernetes 70% konteineritest. See oli usaldusväärne allikas piisavalt suure valimi jaoks maailmas.

Siis on veel küsimus — kas me vajame konteinerid? Mul on isiklik tunne ja kogu ettevõtte „Flant” seisukoht on selline, et Kubernetes on de facto standard.

Midagi peale Kubernetes ei tule.

See on absoluutne game-changer infrastruktuuri haldamise valdkonnas. Lihtsalt absoluutne — kõik, rohkem pole Ansible'it, Chefi, virtuaalmasinaid, Terraformi. Ma ei räägi isegi vanadest kemplustest. Kubernetes on absoluutne changer, ja nüüd on asjad ainult nii.

On selge, et kellegil on vaja paar aastat, aga kellegil paar kümmend, et sellele aru saada. Mul ei ole kahtlusi, et midagi muud ei tule peale Kubernetes ja selle uue vaate: me ei riku enam operatsioonisüsteemi, vaid kasutame infrastructure as code, ainult et mitte koodiga, vaid yml — deklaratiivselt kirjeldatud infrastruktuur. Mul on tunne, et nii jääbki igavesti.

— See, those companies that haven't yet transitioned to Kubernetes will inevitably either adopt it or be left behind. Did I understand you correctly?

Dmitri: That’s not entirely correct. For example, if we need to run a DNS server, we can run it on FreeBSD 4.10, and it can function perfectly well for 20 years. Just run and that’s it. Maybe after 20 years, we might need to update something once. If we are talking about software that we launched and that truly works for many years without any updates or changes, then, of course, Kubernetes won’t be necessary there.

When it comes to CI/CD — everywhere Continuous Delivery is needed, where version updates are required, and active changes need to be made, wherever fault tolerance needs to be established — it's only Kubernetes.

About microservices

— Siin tekib mul väike vastuolu. Kubernetesega töötamiseks on vajaliku väline või sisemine toetus — see on esimene punkt. Teiseks, kui me alustame arendust, oleme me väike idufirma, meil pole veel midagi, Kubernetes'e või isegi mikroteenuste arhitektuuri arendamine võib olla keeruline ja mitte alati majanduslikult otstarbekas. Mind huvitab su arvamus — kas idufirmad peaksid kohe alguses Kubernetes'e peale kirjutama või võiksid nad kõigepealt kirjutada monoliidi ja siis alles minna Kubernetes'e juurde?

Dmitri: Äge küsimus. Mul on mikroteenuste kohta ettekand, «Mikroteenused: suurusel on tähtsust». Olen korduvalt kokku puutunud sellega, et inimesed proovivad mikroskoobiga naelu naelda. Lähenemine on iseenesest õige, me kavandame oma sisemist tarkvara just selle meetodiga. Kuid seda tehes tuleb täpselt aru saada, mida sa teed. Kõige rohkem vihkan mikroteenuste juures ma sõna «mikro». Ajalooliselt on see sõna tekkinud, ja mikski tõttu arvavad inimesed, et mikro on väga väike, väiksem kui millimeeter, nagu mikromeeter. See ei ole nii.

Näiteks on olemas monoliit, mille kallal töötab 300 inimest, ja kõik, kes arenduses osalevad, teavad, et seal on probleeme ning see tuleks jagada mikroskoopilisteks tükkideks — umbes 10, millest igaüht kirjutab vähemalt 30 inimest. See on oluline, vajalik ja suurepärane. Kuid kui meile tuleb startup, kus 3 väga nutikat ja andekat kutti on kirja pannud 60 mikroteenust, siis iga kord otsin ma rahuolu.

Tundub, et sellest on juba tuhat korda räägitud — saime jaotatud monoliidi mingis vormis. See on majanduslikult mitteotstarbekas, väga keeruline kõigis aspektides. Lihtsalt olen seda nii mitu korda näinud, et see teeb mind lausa haigeks, seetõttu jätkan sellest rääkimist.

Algse küsimuse juurde, et on konflikt selle vahel, et Kubernetes on hirmutav kasutada, sest ei ole selge, mis seal võib katki minna või mitte töötada, teisalt on selge, et kõik liigub sinna ja mitte midagi peale Kubernetes'i ei ole. Vastus — kaaluda kasu, mis tuleb, ja ülesannete mahtu, mida saate lahendada.Üks kaalupool on see. Teine pool on riskid, mis on seotud seismise või reaktsiooniaja, kättesaadavuse langemisega — töönäitajate halvenemisega.

Siin on asi selline — kas me liigume kiiresti edasi, ja Kubernetes võimaldab paljusid asju teha oluliselt kiiremini ja paremini, või kasutame usaldusväärseid, ajaga proovitud lahendusi, kuid liigume palju aeglasemalt. See valik peab olema igal ettevõttel. Seda võib võrrelda džunglirajaga — kui lähed esimest korda, võid kohtuda mao, tiigri või raevunud mägraga, ja kui oled käinud 10 korda — oled rajale jälje jätnud, oksad eemaldanud ja liigeldes on kerge. Iga korraga muutub rada laiemaks. Siis on see juba asfalttee ja hiljem kaunis bulvar.

Kubernetes aren’t standing still. Once again, the question arises: Kubernetes, on one hand, comprises 4-5 binaries; on the other hand, it’s an entire ecosystem. It’s the operating system that runs on our machines. So, what is it? Ubuntu or Curios? It’s the Linux kernel with a plethora of additional components. All these components have been removed from the road like a venomous snake, and a fence has been put up. Kubernetes evolves rapidly and dynamically, and the level of risks and unknowns decreases every month, leading to a rebalance of these scales.

Vastates küsimusele, mida teha idufirmal, ütleksin, et tulge „Flantu” juurde, makske 150 000 rubla ja saage võtmed kätte DevOps lihtsate teenuste pakkuja. Kui olete väike idufirma, kus on paar arendajat, siis see töötab. Selle asemel, et palgata enda DevOps-i, kellele tuleb õppida teie probleeme lahendama ja samal ajal palka maksta, saate võtmed kätte lahenduse kõikidele küsimustele. Jah, mõningaid miinuseid on. Outsourcina ei saa me olla nii kaasatud ja kiiresti reageerida muudatustele. Kuid meil on küllaga ekspertiisi ja valmis praktikaid. Me garanteerime, et igas olukorras suudame kiiresti toime tulla ning tõstame ellu igasuguseid Kubernetes'eid.

Soovitan kategooriliselt outsourcerimist idufirmadele ja juba stabiilsetele ettevõtetele, kuni te ei suuda eraldada 10 inime meeskonda oma hoolduseks, sest vastasel juhul pole see mõttekas. See on absoluutne mõte outsourcerida.

Amazonist ja Google'ist

— Kas saab pidada outsourcerimiseks Amazonilt või Google'ilt pakutavat hostimist?

Dmitri: Jah, muidugi, see lahendab teatud küsimusi. Kuid on jälle nüansse. Peame ikkagi mõistma, kuidas seda kasutada. Näiteks, Amazon AWS töötab tuhandete pisiasjadega: Load Balancerit tuleb soojendada või esitada eelnevalt taotlus, et „poisid, meile tuleb liiklus, soojendage meie Load Balancer!” Need nüansid tuleb teada.

Kui pöördute inimeste poole, kes on sellel alal spetsialiseerunud, saate peaaegu kõik tüüpilised asjad kaetud. Meil on hetkel 40 inseneri, aasta lõpuks on neid ilmselt 60 — me oleme kindlasti kõikide nende asjadega kokku puutunud. Isegi kui mõnes projektis seisame silmitsi sama probleemiga, küsime kiiresti üksteiselt ja teame, kuidas lahendada.

Tõenäoliselt on vastus selline – jah, hosted-lahendused lihtsustavad mingit osa. Küsimus on selles, kas olete valmis nende hostijate usaldamiseks ja kas nad lahendavad teie probleemid. Amazon ja Google on end hästi tõestanud. Meie kõigis projektides – kindlasti. Meil ei ole rohkem positiivseid kogemusi. Kõik teised pilved, millega oleme proovinud töötada, tekitavad väga palju probleeme – nii Ager kui kõik, mis Venemaal olemas on, ning igasugused OpenStack'i erinevad realiseeringud: Headster, Overage – kõik, mida soovite. Kõik nad tekitavad probleeme, mida ei taha lahendada.

Seetõttu on vastus jah, kuid tegelikult pole küpsed hosted-lahendused just palju.

Kellele on Kubernetes vajalik?

— Ja ikkagi, kellele on Kubernetes vajalik? Kes peaks juba Kubernetes'e peale minema, kes on tüüpiline «Flanta» klient, kes tuleks just Kubernetes'e pärast?

Dmitri: Küsimus on huvitav, sest praegu on Kubernetes tõeliselt populaarsust kogumas: “Rebavad, me teame, et te teete Kubernetes'e, tehke meile ka!” Me vastame neile: “Härra, me ei tee Kubernetes'e, me teeme tootmis- ja kõik sellekõigega seonduvat.” Sest produtseerimine ilma kogu CI/CD ja muu sellise tegemiseta on praegusel ajal lihtsalt võimatu. Kõik on loobunud sellest arusaamast, et meil on arendus omaette ja peale selle operatsioon sõltumatu.

Meie kliendid ootavad erinevat, kuid kõik loodavad mingisugusele headusele, et nad saavad lahenduse oma probleemidele ja nüüd – hop! – Kubernetes lahendab need. Inimesed usuvad imedesse. Nad mõistavad, et imet ei tule, kuid südames loodavad – äkki see Kubernetes lahendab meie jaoks kõik, sellest räägitakse nii palju! Äkki see on nüüd – tšik! – ja hõbedane kuul, tšik! – ja meil on 100% uptime, kõik arendajad saavad 50 korda releasida, mida tahes tootmisse, ja see ei kuku maha. Ühesõnaga, ime!

Kui sellised inimesed meie juurde tulevad, ütleme: «Kahjuks ime ei eksisteeri». Tervislikuks jäämiseks on oluline süüa hästi ja sporti teha. Usaldusväärse serveri jaoks tuleb see korralikult seadistada. Mugava CI/CD jaoks peab see olema õigesti üles ehitatud. See on palju tööd, mida tuleb teha.

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

Mõnede inimeste jaoks on vale arusaam, et neile on vajalik Kubernetes. Inimestele on vajalik, et nad lõpetaksid muretsemise, tegelemise ja huvi tundmise igasuguste infrastruktuuri ja rakenduste käivitamise probleemide üle. Nad soovivad, et rakendused töötaksid lihtsalt ja nende juurutamine toimuks sujuvalt. Kubernetes on nende jaoks lootus, et nad lõpetavad lugemise lugusid sellest, et «me seal segaduses olime» või «me ei saa välja minna», või midagi muud.

Meie juurde tuleb tavaliselt tehniline direktor. Temalt küsitakse kahte asja: ühelt poolt, andke meile uusi funktsioone, teiselt poolt - stabiilsust. Pakume seda ise teha. Hõbedane kuul, täpsemalt hõbedane, seisneb selles, et sa lõpetad nende probleemide üle mõtlema ja aega raiskama. Sul on spetsiaalsed inimesed, kes selle küsimuse lahendavad.

Küsimus, kas meil või kellelgi muul on vaja Kubernetesit, on vale.

Kubernetes on adminnidele tõeliselt vajalik, sest see on huvitav mänguasi, millega saab mängida ja nokitseda. Olgem ausad - kõik armastavad mänguasju. Me kõik oleme kuskil lapsed ja kui me näeme midagi uut, tahame sellega mängida. Mõnel on see juba maha surutud, näiteks adminnina, sest on juba mängitud ja on tühi, et isegi enam ei viitsi. Kuid see ei ole täielikult kadunud kellelgi. Näiteks, kui mulle juba ammu ei meeldi mänguasjad süsteemi haldamise ja DevOpsi valdkonnas, siis ma siiski armastan mänguasju ja ostan ikka uusi.

Ärge mängige tootmisprotsessiga. Millest ma kategooriliselt ei soovitaks rääkida ja mida ma praegu palju näen: "Ah, uus mänguasi!" — jookseme seda ostma, ostsime ja: "Võtame selle nüüd kooli, näitame kõigile sõpradele." Ärge nii tehke. Palun vabandust, mul on lihtsalt lapsed, ma näen pidevalt laste kaudu midagi, märkan seda endas ja üldistan siis ka teistele.

Lõplik vastus: Kubernetes ei ole teile vajalik. Peate lahendama oma probleemid.

Saavutada on võimalik, et:

• toode ei lange;
• isegi kui ta püüab langeda, teame me sellest ette ja saame midagi lisada;
• saame seda muuta sellise kiirusel, nagu meie äri vajab, ja teha seda mugavalt, see ei tekita meile probleeme.

Reaalsed vajadused on kaks: usaldusväärsus ja dünaamilisus/paindlikkus. Kõik, kes praegu teevad mõnda IT-projekti, pole oluline, mis äris — tarkvara, mis lihtsustab maailma, ja kes seda mõistab, peab need vajadused lahendama. Kubernetes õige lähenemise, õige arusaama ja piisava kogemusega võimaldab neid lahendada.

Serverless

— Kui vaadata natuke kaugemale tulevikku, siis püüdes lahendada probleemide puudumist infrastruktuuris, rakenduste tootmiskiirus ja muutumise kiirus, tulevad esile uued lahendused, nagu serveriteta. Kas sa tunned selles suunas mingit potentsiaali ja ütleme, et ka ohtu Kubernetes'e ja sarnaste lahenduste jaoks?

Dmitri: Siin tuleb jälle märkida, et ma ei ole nägija, kes vaatab ette ja ütleb - see läheb nii! Kuigi ma just tegin sama asja. Vaatan jalgu ning näen seal hulga probleeme, näiteks kuidas arvutites töötavad transistorid. Kummaline, eks? Meil on teatud vigadega CPU's.

Serveriteta lahenduse tegemiseks on vaja piisavalt usaldusväärselt, odavalt, tõhusalt ja mugavalt lahendada kõik ökosüsteemi küsimused. Siin olen nõus Elon Muskiga, et on vaja teist planeeti, et tagada inimkonnale hädakorralisuse. Kuigi ma ei tea, mida ta ütleb, aga ma saan aru, et ei ole valmis Marsile lendama ja see ei toimu homme.

Serverless on selgelt mõistetav mõisted, nagu käitunud usaldusväärsus inimkonnale - kaks planeeti on parem kui üks. Kuid kuidas seda praegu teostada? Ühe ekspeditsiooni saatmine - ei ole probleem, kui sellele keskenduda. Saata mitu ekspeditsiooni ja asustada seal paar tuhat inimest, arvan, et see on ka realistlik. Aga täieliku usaldusväärsuse saavutamine, et pool inimkonnast seal elaks, tundub mulle praegu võimatu, mitte kaaluda.

Serverless on sama asi: tore asi, kuid see on kaugel 2019. aasta probleemidest. Kaugemal 2030 - elame sinna välja. Ma ei kahtle, et me elame, kindlasti elame (korrake enne magamaminekut), kuid praegu tuleb lahendada teisi probleeme. See on justkui usk muinasjuttudesse poni Rõõmus. Jah, paar protsenti juhtudest lahendatakse, ja need lahendatakse suurepäraselt, kuid subjektiivselt on serverless - see on vikerkaare... Minu jaoks on see teema liiga kaugel ja liiga arusaamatu. Ma ei ole valmis rääkima. 2019. aastal ei saa serverlessiga ühtegi rakendust kirjutada.

Kuidas Kubernetes areneb

— Kuidas sa arvad, kuidas Kubernetes ja selle ümber olev ökosüsteem tulevikus areneb, kui me liigume selle potentsiaalselt hämmastava kauge tuleviku suunas?

Dmitri: Olen selle üle palju mõelnud ja mul on selge vastus. Esiteks – statefull – stateless'i tegemine on ikkagi lihtsam. Kubernetes panustas alguses rohkem sellesse, tema ümber kõik algas. Stateless töötab Kuberneteses praktiliselt ideaalselt, seal pole lihtsalt millegi üle nuriseda. Statefulli puhul on aga veel palju probleeme, või pigem nüansse. Meil töötab seal juba kõik suurepäraselt, kuid see oleme meie. Selleks, et see töötaks kõigil, on vaja veel paar aastat, vähemalt. See pole mõõdetud näitaja, vaid minu tunne.

Lühidalt, statefull peab kindlasti – ja tuleb – arenema, sest kõik meie rakendused hoiavad olekut, stateless-rakendusi ei eksisteeri. See on illusioon, alati on vajalik mingi andmebaas ja midagi veel. Statefull on kõike, mida võimalik, sirgendamine, kõikide vigade korrigeerimine, kõigi probleemide lahendamine, millega me praegu silmitsi seisame – nimetame seda vastuvõtuks.

Uurimise tase, lahendamata probleemide tase, tõenäosus millegagi silmitsi seista, väheneb oluliselt. See on oluline teema. Ja operaatorite kõik, mis on seotud haldussüsteemi loogika, haldusteenuse loogika, et saavutada lihtne teenus: MySQL lihtne teenus, RabbitMQ lihtne teenus, Memcache lihtne teenus — need on kõik komponendid, mida vajame, et garantii saaks kastist töötama. See lahendabki need mured, mis meil on, et soovime andmebaasi, kuid ei soovi selle haldamisega tegeleda, või soovime Kubernetes't, kuid ei soovi selle haldamisega tegeleda.

See lugu operaatorite arendamisest oma eri vormides on edaspidistel aastatel oluline.

Ma arvan, et kasutusmugavus peab oluliselt suurenema — kast muutub järjest mustamaks, usaldusväärsemaks, koos üha lihtsamate reguleerimise seadistustega.

Kordagi mõtlesin ma, et kuulsin YouTube'is vanast 80-ndate aastate Isaac Asimovi intervjuust Saturday Night Live'is — see on nagu Urgant, aga huvitavam. Seal küsiti temalt arvutite tuleviku kohta. Ta ütles, et tulevik peitub lihtsuses, nagu see oli raadio vastuvõtja puhul. Raadio vastuvõtja oli algselt keeruline masin. Kuni signaali püüdmise nimel tuli 15 minutit nuppusid keerata, osata rampida ja tegelikult mõista, kuidas kõik töötab, mõista raadiosignaalide edastamise füüsikat. Lõppkokkuvõttes jäi raadiole üks nupp.

Mis raadio 2019. aastal? Autos raadio vastuvõtja leiab kõik signaalid, jaama nimed. Protsessi füüsika ei ole 100 aastaga muutunud, on muutunud kasutamise lihtsus. Täna, ja see ei ole ainult tänane, juba 1980. aastal, mil Asimoviga intervjuu tehti, kasutasid kõik raadiot ja keegi ei mõelnud sellele, kuidas see töötab. See töötas alati — see on lihtsalt alati nii.

Asimov ütles siis, et arvutitega on sarnane — kasutamise lihtsus suureneb. Kui 1980. aastal oli vajalik erikoolitus, et arvutis nuppe vajutada, siis tulevikus ei ole see enam nii.

Mul on tunne, et Kubernetes'i ja infrastruktuuri kasutusmugavus muutub oluliselt lihtsamaks. See on minu arvates ilmne – see on pinnal.

Mida teha inseneridega?

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

Dmitri: Mis juhtus raamatupidajaga pärast 1C ilmumist? Umbes sama. Enne loeti paberil – nüüd programmis. Töö efektiivsus on kasvanud kordades, kuid töö sellest siiski ei kadunud. Kui varem vajasime 10 inseneri, et lampi vahetada, siis nüüd piisab ühest.

Tarkvara ja ülesannete arv, minu arvates, kasvab praegu kiiremini kui ilmuvad uued DevOps'd ja suurenevad efektiivsused. Praegu on turul konkreetne puudus ja see kestab kaua. Hiljem jõuab kõik teatud normi, kus töö efektiivsus suureneb, serverless lahendusi tuleb järjest rohkem, Kubernetes'ile ühendatakse tehisintellekt, mis määrab kõik ressursid täpselt nagu vaja, ja kõik teeb ise, nagu peab – inimene astu kõrvale ja ära sega.

Kuid mingid otsused tuleb ikkagi kellelgi vastu võtta. Selge on see, et selle inimese kvalifikatsioon ja spetsialiseeritus on kõrgem. Praegu ei vaja raamatupidamisosakond 10 töötajat, kes peavad raamatupidamisdokumente, et nende käed ei väsi. See ei ole lihtsalt vajalik. Paljusid dokumente skaneeritakse automaatselt ja tuvastatakse elektroonilise dokumentide haldamise süsteemi kaudu. Piisab ühest nutikast pea-raamatupidajast, kellel on juba palju suuremad oskused ja hea arusaam.

Üldiselt on selline tee kõigis valdkondades. Autodega on sama: varem kuulus autole mehhaanik ja kolm juhtijat. Praegu on auto juhtimine kõige lihtsam protsess, milles me kõik igapäevaselt osaleme. Keegi ei mõtle, et auto on midagi keerulist.

DevOps või süsteemiinseneritus ei kao kuhugi – töö taseme ja efektiivsus suurenevad.

– Olen veel kuulnud huvitavat ideed, et tegelikult töö maht suureneb.

Dmitri: Loomulikult, sada protsenti! Sest tarkvara kogus, mida me kirjutame, kasvab pidevalt. Küsimuste arv, mida me tarkvaraga lahendame, kasvab pidevalt. Töömaht suureneb. Praegu on DevOpsi turg jubedalt ülekuumenenud. Seda saab näha palgaootustes. Üldiselt, mitte detailidesse laskudes, peaks olema algajaid, kes tahavad X, keskaste spetsiifiliste ootustega 1,5X ja kogenud, kes soovivad 2X. Aga praegu, kui vaadata Moskva DevOpsi palgaturgu, tahab algaja X kuni 3X ja kogenud X kuni 3X.

Keegi ei tea, kui palju see maksab. Palgataset mõõdab sinu enesekindlus — täielik segadus, kui aus olla, turg on kohutavalt üle kuumenud.

Loomulikult see olukord muutub väga kiiresti — peab toimuma teatud küllastus. Tarkvara arendamisega ei ole see nii — vaatamata sellele, et arendajad on alati vajalikud ja kõigile on vaja häid arendajaid, mõistab turg, kui palju keegi väärt on — valdkond on stabiliseerunud. DevOpsiga ei ole see praegu nii.

— Kuuldust järeldan, et praegune süsteemiadministraator ei peaks liialt muretsema, aga on aeg oma oskusi täiendada ja valmistuda selleks, et homme tuleb rohkem tööd, kuid see on keerulisem ja nõuab rohkem kvalifikatsiooni.

Dmitri: Absoluutselt. Üldiselt elame me 2019. aastas ja elureegel on järgmine: elu jooksul õppimine — me õpime kogu elu. Tundub, et hetkel teavad ja tunnevad seda juba kõik, kuid vähe on lihtsalt teada — tuleb ka tegutseda. Iga päev peame muutuma. Kui me seda ei tee, visatakse meid professionaalsest tõukest välja varem või hiljem.

Olge valmis järskudeks pöördeks 180 kraadi. Ma ei välista olukordi, kus midagi radikaalselt muutub, leiutatakse midagi uut — seda juhtub. Hüpp! — ja nüüd tegutseme teistmoodi. Oluline on selliseks olukorraks valmis olla ja mitte ärevustada. Võib juhtuda, et homme osutub kõik, mida ma teen, tarbetuks — pole hullu, olen terve elu õppinud ja olen valmis õppima midagi muud. See ei ole probleem. Töökindluse pärast ei tasu muretseda, aga tuleb olla valmis pidevalt uudist õppima.

Soovid ja reklaamikäik

— Kas sul on mõni soov?

Dmitri: Jah, mul on mitmeid soove.

Esimene ja materjalne soov – tellige YouTube. Austatud lugejad, minge YouTube'i ja tellige meie kanal. Umbes kuu pärast alustame aktiivset laienemist videoteenusesse, kus on palju õppeaineid Kubernetes'ist, avatud ja erinevatest: praktilistest asjadest, sealhulgas laboritest, kuni sügavate põhimõtteliste teoreetiliste asjadeni ja kuidas rakendada Kubernetes'e põhimõtete ja mustrite tasemel.

Teine materjalne soov – minge GitHub ja paneme tähtedega hinnanguid, kuna me toitume neist. Kui te meid ei hinda, jääme nälga. See on nagu mana arvutimängus. Me teeme midagi, teeme, püüame, keegi ütleb, et need on kohutavad jalgrattad, keegi ütleb, et kõik on täiesti vale, aga me jätkame ja tegutseme täiesti ausalt. Me näeme probleemi, lahendame selle ja jagame kogemusi. Seega andke meile täht, teilt ei kulu midagi, aga me saame, sest me toitume neist.

Kolmas, oluline ja mitte enam materjalne soov – lõpetage muinasjuttudesse uskumine. Te olete professionaalid. DevOps on väga tõsine ja vastutustundlik amet. Lõpetage mängimine töökohal. Las see teile kohale jõuab ja mõistate seda. Kujutage ette, et lähete haiglasse, ja seal katsetab arst teiega. Ma mõistan, et see võib kellelegi haiget teha, aga tõenäoliselt ei käi see teie kohta, vaid kellegi teise. Öelge teistele, et nad ka lõpetaksid. See rikub tegelikult kõigi meie elu — paljud hakkavad suhtuma operatsioonidesse, adminnidesse ja DevOps’idesse kui tüüpidessse, kes jälle midagi ära rikkusid. See „ära rikkumine“ juhtub enamasti seetõttu, et me läksime mängima, mitte ei vaadanud asjadele külma peaga.

See ei tähenda, et ei pea eksperimenteerima. Eksperimenteerida tuleb, me ise teeme seda. Kui olla aus, siis me ise ikka vahel mängime — see on muidugi väga halb, aga miski inimlik ei ole meile võõras. Las 2019. aasta olema tõsiste hoolikalt mõeldud katsete aasta, mitte mängud prod's. Arvatavasti nii.

— Suur aitäh!

Dmitri: Aitäh, Vitali, ka aja ja intervjuu eest. Kallid lugejad, suur tänu teile, kui olete selles punktis ära käinud. Loodan, et oleme teile vähemalt paar mõtet edastanud.

Intervjuus puudutas Dmitri werf küsimust. Praegu on see universaalne Šveitsi armee nuga, mis lahendab peaaegu kõik ülesanded. Kuid see ei olnud alati nii. DevOpsConf  festivali RIT++ Dmitri Stoljarov räägib sellest tööriistast detailselt. Ettekandes «werf – meie CI/CD tööriist Kuberneteses» oleb kõik: probleemid ja salajased nüansid Kubernetesest, lahenduste variandid nende raskuste lahendamiseks ja praegune werfi rakendamine üksikasjalikult. Liituge 27. ja 28. mail, loome ideaalseid vahendeid.

Allikas: habr.com