V pričakovanju Vitalij Khabarov intervjuvan Dmitrij Stoljarov (), tehnični direktor in soustanovitelj Flanta. Vitalij je vprašal Dmitrija o tem, kaj Flant počne, o Kubernetesu, razvoju ekosistema in podpori. Razpravljali smo o tem, zakaj je Kubernetes potreben in ali je sploh potreben. In tudi o mikrostoritvah, Amazon AWS, pristopu »I'm lucky« k DevOps, prihodnosti samega Kubernetesa, zakaj, kdaj in kako bo prevzel svet, obetih za DevOps in na kaj naj se inženirji pripravijo v svetlem in bližnjo prihodnost s poenostavitvijo in nevronskimi mrežami.
poslušajte kot podcast na DevOps Deflop - podcast v ruskem jeziku o DevOps in spodaj - besedilna različica.
Tukaj in spodaj so postavljena vprašanja inženir iz Express42.
O "Flant"
- Živjo Dima. Ste tehnični direktorin tudi njen ustanovitelj. Povejte nam, prosim, s čim se podjetje ukvarja in kaj ste v njem?
Dmitry: Od zunaj se zdi, kot da smo tipi tipov, ki gredo okoli, vsem namestijo Kubernetes in z njim nekaj naredijo. Ampak ni. Začeli smo kot Linux podjetje, vendar je že zelo dolgo naša glavna dejavnost servisiranje proizvodnje in visokoobremenjenih projektov na ključ. Običajno celotno infrastrukturo zgradimo iz nič in potem smo zanjo odgovorni dolgo, dolgo časa. Glavno delo, ki ga Flant opravlja in za katerega prejema denar, je torej prevzem odgovornosti in izvedba proizvodnje na ključ.
Jaz kot tehnični direktor in eden od ustanoviteljev podjetja XNUMX ur na dan delam na tem, kako povečati razpoložljivost produkcije, poenostaviti njeno delovanje, olajšati življenje skrbnikom in popestriti življenje razvijalcem.
O Kubernetesu
- V zadnjem času sem videl veliko poročil iz Flanta in o Kubernetesu. Kako ste prišli do njega?
Dmitry: O tem sem že velikokrat govoril, a mi ni nič proti, da to ponovim. Mislim, da je prav, da to temo ponovimo, saj prihaja do zmede med vzrokom in posledico.
Res smo potrebovali orodje. Srečevali smo se s številnimi težavami, se borili, jih premagovali z različnimi berglami in čutili potrebo po orodju. Šli smo skozi veliko različnih možnosti, izdelovali lastna kolesa, nabirali izkušnje. Postopoma smo prišli do točke, ko smo začeli uporabljati Docker skoraj takoj, ko se je pojavil – okoli leta 2013. V času njegovega pojava smo že imeli veliko izkušenj s kontejnerji, že smo napisali analog "Dockerja" - neke vrste naše bergle v Pythonu. S prihodom Dockerja je postalo mogoče opustiti bergle in uporabiti zanesljivo rešitev, ki jo podpira skupnost.
Pri Kubernetesu je zgodba podobna. Ko je začela dobivati zagon - za nas je to različica 1.2 -, smo imeli že kup bergel tako pri Shellu kot Chefu, ki smo ju nekako poskušali orkestrirati Dockerju. Resno smo pogledovali proti Rancherju in raznim drugim rešitvam, potem pa se je pojavil Kubernetes, v katerem je vse implementirano točno tako, kot bi mi ali celo bolje. Nič za očitati.
Da, tukaj je nekakšna nepopolnost, obstaja nekakšna nepopolnost - veliko nepopolnosti in 1.2 je na splošno groza, ampak .... Kubernetes je kot stavba v gradnji - pogledaš projekt in razumeš, da bo kul. Če ima stavba zdaj temelj in dve nadstropji, potem razumete, da je bolje, da se še ne vselite, vendar s programsko opremo ni takšnih težav - jo lahko že uporabljate.
Niti trenutka nismo razmišljali, ali uporabiti Kubernetes ali ne. Čakali smo ga dolgo, preden se je pojavil, in sami poskušali narediti analoge.
O Kubernetesu
- Ste neposredno vključeni v sam razvoj Kubernetesa?
Dmitry: povprečno. Namesto tega sodelujemo pri razvoju ekosistema. Pošljemo določeno število povlečnih zahtevkov: Prometheusu, različnim operaterjem, Helmu - ekosistemu. Na žalost ne morem spremljati vsega, kar počnemo, in lahko se motim, vendar od nas do srži ni niti enega bazena.
Ali hkrati razvijate veliko svojih orodij okoli Kubernetesa?
Dmitry: Strategija je naslednja: gremo in potegnemo-zahtevamo vse, kar je že tam. Če zahteve za vleko tam niso sprejete, jih preprosto razcepimo k sebi in živimo, dokler niso sprejete z našimi zgradbami. Potem, ko doseže navzgor, preklopimo nazaj na različico navzgor.
Na primer, imamo operaterja Prometheus, s katerim smo verjetno že 5-krat preklopili naprej in nazaj na upstream našega sklopa. Potrebujemo nekakšno funkcijo, poslali smo zahtevo za vlečenje, jutri jo moramo uvesti, vendar ne želimo čakati, da bo izdana v zgornjem toku. V skladu s tem sestavimo zase, zvijemo naš sklop z našo funkcijo, ki jo iz nekega razloga potrebujemo, v vse naše grozde. Potem ga na primer zavijejo navzgor z besedami: "Fantje, naredimo to za bolj splošen primer", mi ali kdo drug ga dokončamo in čez čas se spet zlije.
Vse, kar obstaja, poskušamo razvijati. Veliko elementov, ki še ne obstajajo, še niso bili izumljeni ali izumljeni, vendar niso imeli časa za izvedbo - to počnemo. Pa ne zato, ker bi nam bil všeč proces sam ali kolesarjenje kot industrija, ampak preprosto zato, ker potrebujemo to orodje. Pogosto se postavlja vprašanje, zakaj smo naredili to ali ono stvar? Odgovor je preprost - da, ker smo morali iti dlje, rešiti nek praktični problem in s tem orodjem smo ga rešili.
Pot je vedno taka: zelo natančno iščemo in če ne najdemo nobene rešitve, kako iz štruce kruha narediti trolejbus, naredimo svojo štruco in svoj trolejbus.
Ploščata orodja
- Vem, da ima Flant zdaj operatorje dodatkov, operaterje lupine, orodja dapp/werf. Kolikor razumem, je to isti instrument v različnih inkarnacijah. Razumem tudi, da je znotraj Flanta veliko več različnih instrumentov. To je resnica?
Dmitry: Na GitHubu imamo veliko več. Kolikor se zdaj spomnim, imamo statusmap - ploščo za Grafana, ki je šla vsem. Omenjen je v skoraj vsakem drugem članku o spremljanju Kubernetesa na Mediumu. Nemogoče je na kratko opisati, kaj je zemljevid stanja - potrebujemo ločen članek, vendar je to zelo uporabna stvar za spremljanje stanja skozi čas, saj moramo v Kubernetesu pogosto prikazati stanje skozi čas. Imamo tudi LogHouse - to je stvar, ki temelji na ClickHouse in črni magiji za zbiranje dnevnikov v Kubernetesu.
Veliko pripomočkov! In še več jih bo, saj bo letos izdanih kar nekaj internih rešitev. Od zelo velikih, ki temeljijo na addon operaterju, je en kup dodatkov za Kubernetes ala kako pravilno namestiti sert manager - orodje za upravljanje s certifikati, kako pravilno namestiti Prometheus s kupom body kit - to je približno dvajset različnih. binarne datoteke, ki izvažajo podatke in nekaj zbirajo, do te Prometheusove čudovite grafike in opozoril. Vse to je le kup Kubernetesovih dodatkov, ki se dajo v gručo in ta se iz enostavnega spremeni v kul, fensi, samodejnega, v katerem je veliko težav že rešenih. Ja, delamo veliko.
Razvoj ekosistema
— Zdi se mi, da je to zelo velik prispevek k razvoju tega orodja in njegovih načinov uporabe. Ali lahko približno ocenite, kdo bi še enako prispeval k razvoju ekosistema?
Dmitry: V Rusiji od tistih podjetij, ki delujejo na našem trgu, nihče ni niti blizu. Seveda je to velika izjava, saj obstajajo veliki igralci, kot sta Mail in Yandex – tudi oni delajo nekaj s Kubernetesom, vendar se niti oni niso približali prispevku podjetij po vsem svetu, ki delajo veliko več kot mi. Težko primerjam Flant s kadrom 80 ljudi in Red Hat, v katerem je 300 inženirjev samo za en Kubernetes, če se ne motim. Težko je primerjati. V oddelku za raziskave in razvoj imamo 6 ljudi, vključno z mano, ki režemo vsa naša orodja. 6 ljudi proti 300 inženirjem Red Hat – kar težko je primerjati.
»Kljub temu, ko lahko tudi teh 6 ljudi naredi nekaj res koristnega in odtujljivega, ko se soočijo s praktičnim problemom in dajo rešitev skupnosti, je to zanimiv primer. Razumem, da je v velikih tehnoloških podjetjih, ki imajo svoj razvoj in podporno skupino Kubernetes, načeloma mogoče razviti enaka orodja. To je zanje primer, ki ga je mogoče razviti in dati skupnosti, da da zagon celotni skupnosti, ki uporablja Kubernetes.
Dmitry: Verjetno je to lastnost integratorja, njegova posebnost. Imamo veliko projektov in vidimo veliko različnih situacij. Za nas je glavni način ustvarjanja dodane vrednosti ta, da analiziramo te primere, najdemo skupne točke in jih naredimo čim cenejše za nas. To je tisto, kar aktivno počnemo. Težko mi je govoriti o Rusiji in svetu, vendar imamo v podjetju okoli 40 inženirjev DevOps, ki se ukvarjajo s Kubernetesom. Mislim, da v Rusiji ni veliko podjetij s primerljivim številom strokovnjakov, ki razumejo Kubernetes, če sploh obstajajo.
Razumem vse o nazivu delovnega mesta DevOps inženir, vsi vse razumejo in so navajeni inženirje DevOps klicati DevOps inženirji, o tem ne bomo razpravljali. Vseh teh 40 neverjetnih inženirjev DevOps se sooča s težavami in jih rešuje vsak dan, mi samo analiziramo to izkušnjo in poskušamo posplošiti. Razumemo, da če ostane v nas, bo orodje čez leto ali dve neuporabno, ker se bo nekje v skupnosti pojavilo že pripravljeno orodje. Nima smisla kopičiti te izkušnje notri - to je le izguba časa in truda v dev/null. In prav nič nam ni žal. Vse objavljamo z velikim veseljem in razumemo, da je treba to objavljati, razvijati, promovirati, promovirati, da lahko ljudje uporabijo in dodajo svoje izkušnje - potem vse raste in živi. Potem pa po dveh letih orodje ne gre več v smeti. Ni škoda še naprej vlivati moči, saj je jasno, da nekdo uporablja tvoj instrument, čez dve leti pa ga uporabljajo že vsi.
To je del naše velike strategije z dapp/werf. Ne spomnim se, kdaj smo začeli s tem, mislim, da pred približno 3 leti. Sprva je bilo na splošno na lupini. To je bil super dokaz koncepta, rešili smo nekaj naših zasebnih nalog - uspelo je! Toda z lupino so težave, nemogoče je še povečati, programiranje na lupini je drug poklic. Imeli smo navado pisati v Rubyju, zato smo nekaj predelali v Rubyju, razvijali, razvijali, razvijali in naleteli na dejstvo, da se pojavi skupnost, množica, ki ne reče "hočemo ali nočemo". njegov nos proti Ruby, kako ni smešno. Ugotovili smo, da moramo vso to dobroto napisati v Go, da preprosto izpolnimo prvo točko na kontrolnem seznamu: Orodje DevOps mora biti statično binarno. Na Go ali ne na Go, ni pomembno, vendar je statična dvojiška datoteka, napisana v Go, boljša.
Porabili smo svojo energijo, prepisali dapp v Go in ga poimenovali werf. Dapp ni več vzdrževan, ni razvit, deluje na najnovejši različici, vendar obstaja absolutna pot nadgradnje do vrha, ki ji je mogoče slediti.
Zakaj je bil ustvarjen dapp?
— Nam lahko na kratko poveste, zakaj je bil ustvarjen dapp, katere težave rešuje?
Dmitry: Prvi razlog je v montaži. Na začetku smo imeli hude težave pri gradnji, ko Docker ni znal večstopenjskega, zato smo večstopenjsko naredili sami. Potem smo imeli še kup vprašanj o čiščenju slike. Vsak, ki dela CI/CD, se prej kot slej sooči s problemom, da je kup zbranih slik, treba je nekako počistiti, kar ni potrebno, in pustiti tisto, kar je potrebno.
Drugi razlog je uvedba. Da, obstaja Helm, vendar rešuje le del težav. Ironično, piše "Helm - upravitelj paketov za Kubernetes". Točno tisto "the". Obstajajo tudi besede "Upravitelj paketov" - kaj se običajno pričakuje od upravitelja paketov? Pravimo: "Upravitelj paketov - namestite paket!" in pričakujemo, da nam bo rekel: "Paket je bil dostavljen."
Zanimivo je, da rečemo: "Helm, inštaliraj paket," in ko odgovori, da je namestil, se izkaže, da je samo začel namestitev - pokazal je Kubernetes: "Zaženi to stvar!", In ne glede na to, ali se je začelo ali ne, deluje ali ne, Helm te težave sploh ne reši.
Izkazalo se je, da je Helm le predprocesor besedila, ki nalaga podatke v Kubernetes.
Toda v okviru kakršne koli uvedbe želimo vedeti, ali je aplikacija uvedena v produkcijo ali ne? Razgrnilo se je v prod, kar pomeni, da je aplikacija šla tja, nova verzija se je odvila in vsaj ne spada tja in pravilno odgovarja. Helm tega problema nikakor ne reši. Če ga želite rešiti, morate vložiti veliko truda, saj morate Kubernetesu dati ukaz, da se razgrne in spremlja, kaj se tam dogaja - ali se je obrnilo, ali se je razgrnilo. Poleg tega obstaja veliko nalog, povezanih z uvajanjem, čiščenjem in sestavljanjem.
Načrti
Letos bomo šli v lokalni razvoj. Želimo priti do tega, kar je bilo v Vagrantu - vtipkali smo "vagrant up" in naši virtualni stroji so se obrnili. Želimo priti do takšnega stanja, da obstaja projekt v Gitu, tam napišemo "werf up" in ustvari lokalno kopijo tega projekta, razporejeno v lokalnem mini-Kubu, z vključenimi vsemi imeniki, primernimi za razvoj. Odvisno od razvojnega jezika se to naredi na različne načine, a kljub temu tako, da lahko priročno izvajate lokalni razvoj pod nameščenimi datotekami.
Naslednji korak za nas je močan investirajte v prijaznost do razvijalcev. Če želite projekt hitro razmestiti lokalno z enim orodjem, ga razvijte, potisnite v Git in bo tudi uveden v fazo ali teste, odvisno od cevovodov, nato pa z istim orodjem šel v proizvodnjo. Ta enotnost, poenotenje, ponovljivost infrastrukture od lokalnega okolja do prodaje je za nas zelo pomembna točka. Toda to še ni v werfu - to šele načrtujemo.
Toda pot do dapp/werf je bila vedno enaka kot pri Kubernetesu na začetku. Soočali smo se s težavami, jih reševali z rešitvami - našli smo nekaj rešitev zase na lupini, na čemer koli. Nato so poskušali nekako poravnati, posplošiti in konsolidirati te rešitve v binarne datoteke v tem primeru, ki jih preprosto delimo.
Obstaja še en pogled na celotno zgodbo, z analogijami.
Kubernetes je okostje avtomobila z motorjem. Ni vrat, ni oken, ni radia, ni božičnega drevesa - sploh ničesar. Samo okvir in motor. In tu je Helm - to je volan. Kul - obstaja volan, vendar potrebujete tudi volanski zatič, volansko letev, menjalnik in kolesa, vendar brez njih ne gre.
V primeru werfa je to še ena komponenta Kubernetesa. Šele zdaj je v naši alfa različici werfa, na primer, Helm sploh preveden v werf, ker smo že naveličani tega delati sami. Obstaja veliko razlogov za to, podrobno o tem, zakaj smo sestavili celotno krmilo skupaj z krmilnikom znotraj werfa, bom povedal samo .
Zdaj je werf bolj integrirana komponenta. Dobimo končan volan, volanski zatič - ne razumem dobro avtomobilov, vendar je to velika enota, ki že rešuje precej širok spekter nalog. Ni nam treba sami plezati po katalogu, izbirati enega dela za drugim, razmišljati, kako jih priviti skupaj. Dobimo že pripravljen kombajn, ki rešuje velik sveženj nalog hkrati. Toda znotraj je vse zgrajeno iz istih odprtokodnih komponent, vse uporablja tudi Docker za sestavljanje, Helm za nekatere funkcionalnosti in obstaja več drugih knjižnic. Je vgrajeno orodje za hitro in priročno pridobivanje kul CI/CD-jev iz škatle.
Ali je težko vzdrževati Kubernetes?
- Govorite o izkušnjah, da ste začeli uporabljati Kubernetes, to je okvir za vas, motor, in da lahko nanj obesite veliko različnih stvari: karoserijo, volan, pritrdite pedale, sedeže. Postavlja se vprašanje - kako težko je za vas podpirati Kubernetes? Imate bogate izkušnje, koliko časa in virov porabite posebej za podporo Kubernetes ločeno od vsega drugega?
Dmitry: To je zelo zapleteno vprašanje in če želite odgovoriti nanj, morate razumeti, kaj je podpora in kaj želimo od Kubernetesa. Mogoče lahko odpreš?
- Kolikor vem in vidim, želi zdaj veliko ekip preizkusiti Kubernetes. Vsi so vpreženi vanjo, postavljeni na kolena. Občutek imam, da ljudje ne razumejo vedno kompleksnosti tega sistema.
Dmitry: Tako je.
- Kako težko je vzeti in namestiti Kubernetes iz nič, tako da je pripravljen za proizvodnjo?
Dmitry: Kako težko mislite, da je presaditi srce? Razumem, da je vprašanje ogrožajoče. Nositi skalpel in se ne zmotiti ni tako težko. Če vam povedo, kje odrezati in kje zašiti, potem je sam postopek preprost. Težko je od časa do časa zagotoviti, da se bo vse izšlo.
Namestitev Kubernetesa in omogočanje njegovega delovanja je preprosta: punca! - Put, obstaja veliko načinov za namestitev. Toda kaj se zgodi, ko se pojavijo težave?
Vedno se porajajo vprašanja - česa še nismo upoštevali? Česa še nismo naredili? Kateri parametri jedra Linuxa so bili nepravilno podani? Gospod, ali smo jih sploh omenili?! Katere komponente Kubernetes smo poslali in katerih ne? Pojavlja se na tisoče vprašanj in za odgovor nanje morate v tej industriji kuhati 15-20 let.
Imam nedavni primer o tej temi, ki bi lahko imel smisel za problem "Ali je težko vzdrževati Kubernetes?". Pred časom smo resno razmišljali, da bi Cilium implementirali kot omrežje v Kubernetes.
Naj pojasnim, kaj je Cilium. Obstaja veliko različnih izvedb omrežnega podsistema v Kubernetesu in ena od njih je zelo kul - to je Cilium. Kaj je njen pomen? Pred časom je jedro predstavilo možnost pisanja kavljev za jedro, ki na tak ali drugačen način vdrejo v omrežni podsistem in razne druge podsisteme ter vam omogočajo, da obidete velike dele v jedru.
Jedro Linuxa je v preteklosti imelo ip route, overfilter, mostove in veliko različnih starih komponent, ki so stare 15, 20, 30 let. Na splošno delujejo, vse je kul, zdaj pa so nabrali kontejnerje in izgleda kot kupola 15 opek ena na drugi, ti pa stojiš na njej na eni nogi - čuden občutek. Ta sistem se je skozi zgodovino razvil s številnimi odtenki, kot je slepič v telesu. V nekaterih situacijah so težave z zmogljivostjo, npr.
Obstaja čudovit BPF in možnost pisanja kavljev za jedro - fantje so napisali svoje kljuke za jedro. Paket pride v jedro Linuxa, vzamejo ga ven takoj na vhodu, ga sami obdelajo kot je treba brez mostov, brez TCP-ja, brez sklada IP - skratka, mimo vsega, kar piše v jedru Linuxa, in takoj pljunejo ven v posodo.
Kaj se je zgodilo? Zelo kul zmogljivost, kul funkcije - preprosto kul! Toda pogledamo ga in vidimo, da je na vsakem računalniku program, ki se poveže z API-jem Kubernetes in glede na podatke, ki jih prejme od tega API-ja, ustvari C-kodo in prevede binarne datoteke, ki jih naloži v jedro, tako da te kljuke delo v prostoru jedra.
Kaj se zgodi, če gre kaj narobe? Ne vemo. Da bi to razumeli, morate prebrati vso to kodo, razumeti vso logiko in osupljivo je, kako težko je. Toda po drugi strani so tu ti mostovi, mrežni filtri, ip poti - nisem prebral njihove izvorne kode, pa tudi 40 inženirjev, ki delajo v našem podjetju. Mogoče nekateri deli razumejo enote.
In kakšna je razlika? Izkazalo se je, da obstaja ip route, jedro Linuxa in obstaja novo orodje - kakšna je razlika, ne razumemo ne enega ne drugega. Vendar se bojimo uporabljati novo - zakaj? Kajti če je instrument star 30 let, potem so v 30 letih najdeni vsi hrošči, pohodene vse grablje in ni treba vedeti za vse - deluje kot črna skrinjica in vedno deluje. Vsak ve, kateri diagnostični izvijač vtakniti na katero mesto, kateri tcpdump v katerem trenutku zagnati. Vsi dobro poznajo diagnostične pripomočke in razumejo, kako ta niz komponent deluje v jedru Linuxa - ne kako deluje, ampak kako ga uporabljati.
In čudovito kul Cilium ni star 30 let, še ni dozorel. Ista težava s Kubernetesom, kopija. Da je Cilium super, da je Kubernetes super, a ko gre kaj narobe v produkciji, znaš hitro razumeti, kaj je šlo v kritični situaciji?
Ko rečemo, ali je težko vzdrževati Kubernetes – ne, zelo preprosto in da, neverjetno težko. Kubernetes odlično deluje sam, vendar z milijardo odtenkov.
O pristopu "I'm Feeling Lucky".
— Ali obstajajo podjetja, kjer je skoraj zagotovljeno, da se bodo te nianse pojavile? Recimo, da Yandex nenadoma prenese vse storitve v Kubernetes, tam bo velika obremenitev.
Dmitry: Ne, to ni pogovor o obremenitvi, ampak o najpreprostejših stvareh. Na primer, imamo Kubernetes, tam smo razmestili aplikacijo. Kako razumeti, da deluje? Preprosto ni pripravljenega orodja, da bi razumeli, da se aplikacija ne zruši. Ni pripravljenega sistema, ki bi pošiljal opozorila, morate nastaviti ta opozorila in vsak grafikon. In posodabljamo Kubernetes.
Obstaja Ubuntu 16.04. Lahko rečemo, da je to stara različica, vendar smo še vedno na njej, ker obstaja LTS. Obstaja systemd, ki ima to opozorilo, da ne čisti skupin C. Kubernetes zažene pode, ustvari skupine C, nato izbriše pode in nekako se izkaže - ne spomnim se podrobnosti, žal - da ostanejo rezine systemd. To vodi v dejstvo, da se sčasoma vsak avto začne močno upočasnjevati. To sploh ni vprašanje visoke obremenitve. Če se izvajajo vztrajni podi, na primer, če obstaja Cron Job, ki nenehno ustvarja pode, se bo računalnik z Ubuntu 16.04 po enem tednu začel upočasnjevati. Prisotno bo stalno visoko povprečje obremenitve zaradi dejstva, da se ustvari kup C-skupin. To je težava, ki jo ima vsakdo, ki samo postavi Ubuntu 16 in Kubernetes na vrh.
Recimo, da nekako posodobi systemd ali kaj drugega, ampak v jedru Linuxa pred 4.16 je to še bolj smešno - ko brišeš C-skupine, te uhajajo v jedro in se dejansko ne izbrišejo. Zato po enem mesecu dela na tem stroju ne bo mogoče videti statistike pomnilnika za pods. Vzamemo ven datoteko, jo zavrtimo v programu in ena datoteka se vrti 15 sekund, ker jedro potrebuje zelo dolgo časa, da v sebi prešteje na milijone C-skupin, ki se zdijo izbrisane, a ne - puščajo.
Takih malenkosti je tu in tam še ogromno. To ni vprašanje, s katerim se velikanska podjetja včasih soočijo pod zelo velikimi obremenitvami – ne, gre za vsakodnevne stvari. Ljudje lahko tako živijo več mesecev - namestili so Kubernetes, razmestili aplikacijo - zdi se, da deluje. Mnogim je to všeč. Sploh ne bodo vedeli, da se bo nekega dne ta aplikacija iz nekega razloga zrušila, opozorilo ne bo prišlo, a za njih je to norma. Prej so živeli na virtualnih strojih brez nadzora, zdaj so se preselili v Kubernetes tudi brez nadzora - kakšna je razlika?
Težava je v tem, da ko hodimo po ledu, nikoli ne vemo njegove debeline, razen če je predhodno izmerimo. Mnogi gredo in se ne kopajo, ker so hodili.
Z mojega vidika je niansa in kompleksnost delovanja katerega koli sistema zagotoviti, da je debelina ledu ravno tolikšna, da reši naše težave. Gre za to.
Mislim, da je v IT-ju preveč pristopov "I'm Feeling Lucky". Mnogi nameščajo programsko opremo, uporabljajo programske knjižnice v upanju, da bodo imeli srečo. Na splošno ima veliko ljudi srečo. Verjetno zato deluje.
- Po moji pesimistični oceni je videti takole: ko so tveganja velika in bi aplikacija morala delovati, potem potrebujete podporo Flanta, po možnosti Red Hata, ali pa potrebujete lastno interno ekipo, posvečeno posebej Kubernetesu, ki je pripravljena da ga potegnem.
Dmitry: Objektivno je. Vstopiti v zgodbo s Kubernetesom sam z majhno ekipo je določeno tveganje.
Ali potrebujemo posode?
— Nam lahko poveste, kako pogost je Kubernetes v Rusiji?
Dmitry: Teh podatkov nimam in nisem prepričan, če jih kdo ima. Pravimo: "Kubernetes, Kubernetes", vendar obstaja drugačen pogled na to vprašanje. Tudi jaz ne vem, kako razširjeni so vsebniki, vendar poznam podatek iz poročil na internetu, da 70 % vsebnikov orkestrira Kubernetes. Bil je zanesljiv vir za dokaj velik vzorec po vsem svetu.
Potem pa še eno vprašanje - ali potrebujemo kontejnerje? Imam osebni občutek in na splošno je stališče podjetja Flant takšno, da je Kubernetes de facto standard.
Ne bo nič drugega kot Kubernetes.
To je absolutna sprememba pri upravljanju infrastrukture. Samo absolutno - to je to, nič več Ansible, Chef, virtualni stroji, Terraform. Ne govorim o starih kolektivnih metodah. Kubernetes je absolutni spreminjalec, in zdaj bo samo tako.
Jasno je, da nekdo potrebuje nekaj let, nekdo pa nekaj desetletij, da to spozna. Ne dvomim, da ne bo nič drugega kot Kubernetes in ta novi videz: OS ne škodimo več, ampak uporabljamo infrastruktura kot koda, vendar ne s kodo, ampak z yml - deklarativno opisano infrastrukturo. Imam občutek, da bo vedno tako.
- Se pravi, tista podjetja, ki še niso prešla na Kubernetes, bodo zagotovo prešla na to ali pa ostala v pozabi. sem te prav razumel?
DmitryO: Tudi to ni povsem res. Na primer, če imamo nalogo zagnati dns strežnik, ga je mogoče zagnati na FreeBSD 4.10 in lahko dobro deluje 20 let. Samo delo je vse. Morda bo čez 20 let treba enkrat kaj posodobiti. Če govorimo o programski opremi v formatu, ki smo ga lansirali in res deluje več let brez kakršnih koli posodobitev, brez spreminjanja, potem Kubernetesa seveda ne bo. Tam ga ne potrebujejo.
Vse, kar je povezano s CI/CD - povsod, kjer potrebujete Continuous Delivery, kjer morate posodobiti različice, narediti aktivne spremembe, povsod, kjer morate zgraditi toleranco za napake - samo Kubernetes.
O mikrostoritvah
- Tukaj imam rahlo disonanco. Za delo s Kubernetesom potrebujete zunanjo ali notranjo podporo – to je prva točka. Drugi je, ko šele začenjamo z razvojem, smo majhen startup, nimamo še ničesar, razvoj za Kubernetes ali nasploh za mikrostoritveno arhitekturo je lahko težaven in ne vedno ekonomsko upravičen. Zanima me vaše mnenje - ali morajo startupi takoj začeti pisati za Kubernetes iz nič ali lahko še vedno napišejo monolit in šele nato pridejo v Kubernetes?
Dmitry: Kul vprašanje. Govorim o mikrostoritvah Velikokrat sem naletel na to, da ljudje poskušajo zabijati žeblje z mikroskopom. Sam pristop je pravilen, interno programsko opremo sami oblikujemo na ta način. Toda ko to počnete, morate jasno razumeti, kaj počnete. Pri mikrostoritvah najbolj sovražim besedo "mikro". Zgodovinsko gledano se je ta beseda pojavila tam in iz nekega razloga ljudje mislijo, da je mikro zelo majhen, manj kot milimeter, kot mikrometer. To je narobe.
Na primer, obstaja monolit, ki ga piše 300 ljudi, in vsi, ki so sodelovali pri razvoju, razumejo, da so tam težave, in ga je treba razdeliti na mikro koščke - 10 kosov, od katerih vsakega piše 30 ljudi v minimalna različica. To je pomembno, potrebno in kul. Ko pa pride k nam startup, kjer so 3 zelo kul in nadarjeni fantje na kolenih napisali 60 mikroservisov, vsakič, ko iščem Corvalol.
Zdi se mi, da je bilo to že tisočkrat povedano - dobili so porazdeljen monolit v takšni ali drugačni obliki. To ni ekonomsko upravičeno, na splošno je v vsem zelo težko. Samo tolikokrat sem to videla, da me res boli, zato kar naprej govorim o tem.
Na začetno vprašanje, da obstaja konflikt med tem, da je po eni strani Kubernetes strašljiv za uporabo, ker ni jasno, kaj se tam lahko pokvari ali ne deluje, po drugi strani pa je jasno, da vse gre tam in nič drugega kot Kubernetes ne bo. odgovor - pretehtajte količino koristi, ki prihaja, količino nalog, ki jih lahko rešite. To je na eni strani lestvice. Po drugi strani pa obstajajo tveganja, ki so povezana z izpadi ali z zmanjšanjem odzivnega časa, stopnje razpoložljivosti - z zmanjšanjem zmogljivosti.
Tukaj je - ali se premikamo hitro in Kubernetes vam omogoča, da veliko stvari naredite veliko hitreje in bolje, ali pa uporabite zanesljive, časovno preizkušene rešitve, vendar se premikate veliko počasneje. To izbiro mora narediti vsako podjetje. Lahko si jo predstavljaš kot pot v džungli - ko greš prvič na sprehod, lahko srečaš kačo, tigra ali pobesnelega jazbeca, ko si šel 10-krat, si pot zgazil, odstranil veje in hodiš lažje . Vsakič se pot širi. Takrat je že asfaltna cesta, kasneje pa lep bulvar.
Kubernetes ne miruje. Še eno vprašanje: Kubernetes je na eni strani 4-5 binarnih datotek, na drugi strani pa cel ekosistem. To je operacijski sistem, ki ga imamo na strojih. Kaj je to? Ubuntu ali Curios? To je jedro Linuxa, kup dodatkov. Vse te stvari tukaj, eno strupeno kačo so vrgli s poti, tam postavili ograjo. Kubernetes se razvija zelo hitro in dinamično, obseg tveganj, obseg neznanega pa se vsak mesec zmanjšuje in temu primerno se te tehtnice ponovno uravnotežijo.
Na vprašanje, kaj naj počne startup, bi rekel - pridite v Flant, plačajte 150 tisoč rubljev in dobite enostavno storitev DevOps na ključ. Če ste majhen startup z več razvijalci, to deluje. Namesto najemanja lastnega DevOpsa, ki se bo moral naučiti reševati vaše težave in v tem času izplačati plačo, boste prejeli rešitev na ključ za vsa vprašanja. Da, nekaj je slabosti. Kot zunanji izvajalec ne moremo biti tako angažirani in se hitro odzivati na spremembe. Imamo pa veliko strokovnega znanja, pripravljenih praks. Zagotavljamo, da bomo v vsaki situaciji zagotovo hitro ugotovili in dvignili kateri koli Kubernete iz drugega sveta.
Močno priporočam zunanje izvajanje startupom in uveljavljenim podjetjem do velikosti, pri kateri lahko za delovanje dodelite ekipo 10 ljudi, ker sicer nima smisla. Absolutno je smiselno oddati zunanje izvajanje.
O Amazonu in Googlu
- Ali se gostitelj iz rešitve Amazona ali Googla šteje za zunanjega izvajalca?
Dmitry: Ja, seveda, rešuje vrsto vprašanj. Ampak spet nianse. Še vedno morate razumeti, kako ga uporabljati. Na primer, pri delu Amazon AWS je tisoč malenkosti: ogreti morate Load Balancer ali vnaprej napisati zahtevo, da "fantje, dobili bomo promet, ogrejte Load Balancer za nas!" Te nianse morate poznati.
Ko stopite v stik z ljudmi, ki so specializirani za to, zaključite skoraj vse tipične stvari. Zdaj imamo 40 inženirjev, do konca leta jih bo predvidoma 60 - zagotovo smo se srečali z vsem tem. Tudi če na kakšnem projektu spet naletimo na ta problem, se hitro vprašamo in vemo, kako ga rešiti.
Verjetno je odgovor naslednji - seveda, gostujoča zgodba olajša del. Vprašanje je, ali ste tem gostiteljem pripravljeni zaupati in ali bodo rešili vaše težave. Amazon in Google sta se dobro odrezala. Za vse naše primere - zagotovo. Drugih pozitivnih izkušenj nimamo. Vsi drugi oblaki, s katerimi smo poskušali delati, povzročajo veliko težav - in Ager, in vse, kar je v Rusiji, in vse vrste OpenStack v različnih izvedbah: Headster, Overage - karkoli želite. Vsi ustvarjajo težave, ki jih ne želite rešiti.
Zato je odgovor pritrdilen, vendar dejansko ni veliko zrelih gostujočih rešitev.
Kdo potrebuje Kubernetes?
- In vendar, kdo potrebuje Kubernetes? Kdo bi že moral preiti na Kubernetes, kdo je tipičen odjemalec Flanta, ki pride posebej za Kubernetes?
Dmitry: Vprašanje je zanimivo, ker zdaj, ravno na valu Kubernetesa, veliko ljudi pride k nam: "Fantje, vemo, da delate Kubernetes, naredite to za nas!". Odgovorimo jim: "Gospodje, mi ne delamo Kubernetes, mi delamo prod in vse, kar je povezano z njim." Ker narediti produkcijo, ne da bi naredili vse CI / CD in vso to zgodovino, je trenutno preprosto nemogoče. Vsi so se oddaljili od delitve, da imamo razvoj za razvojem, potem pa izkoriščanje za izkoriščanjem.
Naše stranke pričakujejo različne stvari, vsak pa čaka na kakšen čudež, da ima to ali ono težavo in zdaj - hop! - Kubernetes jih bo rešil. Ljudje verjamejo v čudeže. Z razumom razumejo, da čudeža ne bo, z dušo pa upajo - kaj če bo ta Kubernetes zdaj o vsem odločal namesto nas, toliko govorijo o tem! Nenadoma je zdaj - kihanje! — in srebrna krogla, kihni! - in imamo 100% uptime, vsi razvijalci lahko izdajo 50-krat karkoli za proizvodnjo, in to ne pade. Na splošno, čudež!
Ko pridejo taki ljudje k nam, rečemo: "Oprostite, a čudež se ne zgodi." Če želite biti zdravi, morate dobro jesti in telovaditi. Če želite imeti zanesljiv izdelek, ga je treba narediti zanesljivo. Če želite imeti priročen CI / CD, ga morate narediti tako. To je veliko dela, ki ga je treba opraviti.
Odgovor na vprašanje, kdo potrebuje Kubernetes, nihče ne potrebuje Kubernetesa.
Nekateri ljudje imajo zmoten občutek, da potrebujejo Kubernetes. Ljudje potrebujejo, imajo resnično globoko potrebo, da nehajo razmišljati, delati, se zanimati za vse težave infrastrukture in težave pri izvajanju njihovih aplikacij. Želijo, da aplikacije samo delujejo in se uvajajo. Za njih je Kubernetes upanje, da bodo nehali poslušati zgodbo, da »smo ležali tam« ali »ne moremo se razviti« ali kaj tretjega.
K nam običajno pride tehnični direktor. Sprašujejo ga dvoje: po eni strani naj nam da lastnosti, po drugi strani stabilnost. Predlagamo, da to vzamete nase in to storite. Srebrna krogla, bolje rečeno posrebrena, je, da ne boste več razmišljali o teh težavah in izgubljali čas. Imeli boste posebne ljudi, ki bodo zaprli to temo.
Besedilo, da mi ali kdo potrebuje Kubernetes, je napačno.
Kubernetes je zelo potreben za skrbnike, ker je to zelo zanimiva igrača, s katero se lahko igrate, kopljete globlje. Bodimo iskreni – vsi imajo radi igrače. Vsi smo nekje otroci in ko zagledamo novega, si ga želimo igrati. Nekatere to odbija, na primer v upravi, ker so že dovolj igrali in so že utrujeni do te mere, da preprosto nočejo. A tega nikogar ne odbija popolnoma. Na primer, če sem že dolgo naveličan igrač na področju sistemske administracije in DevOps, potem imam še vedno rad igrače, še vedno kupim nekaj novih. Vsi ljudje si nekako še vedno želimo kakšne igrače.
S proizvodnjo se ni treba igrati. Česa kategorično ne priporočam in kar vidim zdaj množično: "Ah, nova igrača!" - tekli so, da bi ga kupili, kupili in: "Odnesimo ga zdaj v šolo, pokažimo ga vsem prijateljem." Ne počni tega. Oprosti, moji otroci šele odraščajo, nenehno nekaj vidim v otrocih, opazim pri sebi, potem pa posplošim na druge.
Končni odgovor: Ne potrebujete Kubernetesa. Morate rešiti svoje težave.
To lahko dosežete:
- prod ne pade;
- tudi če poskuša pasti, za to vemo vnaprej in lahko kaj nataknemo;
- spreminjamo ga lahko s hitrostjo, ki jo potrebujemo za posel, in to naredimo priročno, ne povzroča nam nobenih težav.
Obstajata dve resnični potrebi: zanesljivost in dinamičnost/prilagodljivost uvajanja. Vsi, ki se zdaj ukvarjate z nekakšnimi IT projekti, ne glede na to, kakšen posel - mehko za lajšanje sveta, in ki to razumete, te potrebe je treba nasloviti. Kubernetes jih s pravim pristopom, s pravim razumevanjem in z dovolj izkušnjami lahko reši.
O brezstrežniškem
- Če pogledate malo dlje v prihodnost, potem poskušate rešiti problem pomanjkanja glavobola z infrastrukturo, s hitrostjo uvajanja in hitrostjo spreminjanja aplikacij, se pojavijo nove rešitve, na primer brez strežnika. Ali čutite v tej smeri kakšen potencial in recimo nevarnost za Kubernetes in podobne rešitve?
Dmitry: Tukaj je treba spet pripomniti, da nisem videc, ki gleda naprej in pravi - tako bo! Čeprav sem pravkar naredil isto. Pogledam v svoje noge in tam vidim kup težav, na primer, kako tranzistorji delujejo v računalniku. Smešno, kajne? Soočamo se z nekaterimi napakami v procesorju.
Izdelava brez strežnika je precej zanesljiva, poceni, učinkovita in priročna ter rešuje vsa vprašanja ekosistema. Tu se strinjam z Elonom Muskom, da je potreben drugi planet, da bi človeštvo naredilo toleranco napak. Čeprav ne vem, kaj pravi, razumem, da sam ni pripravljen leteti na Mars in da to ne bo jutri.
Pri brezstrežniškem je jasno, da je to ideološko pravilna stvar, kot je toleranca napak za človeštvo – imeti dva planeta je bolje kot enega. Toda kako to storiti zdaj? Poslati eno odpravo ni problem, če se na to osredotočite. Mislim, da je tudi realno poslati več odprav in tam naseliti več tisoč ljudi. Toda zdaj se mi zdi, da je nemogoče, ne upoštevano, narediti ga popolnoma tolerantnega na napake, tako da bi tam živela polovica človeštva.
Z eno proti ena brez strežnika: kul stvar, vendar je daleč od težav leta 2019. Bližje do leta 2030 - doživimo. Ne dvomim, da bomo živeli, zagotovo bomo živeli (ponovite pred spanjem), zdaj pa je treba rešiti druge probleme. Kot bi verjeli v pravljičnega ponija Rainbow. Da, nekaj odstotkov primerov je rešenih in so rešeni odlično, subjektivno pa je brez strežnika mavrica ... Zame je ta tema predaleč in preveč nerazumljiva. Nisem pripravljena govoriti. V letu 2019 ne morete napisati niti ene aplikacije brez strežnika.
Kako se bo Kubernetes razvijal
- Kako se bosta po vašem mnenju razvijala Kubernetes in ekosistem okoli njega, ko se premikamo proti tej potencialno lepi daljni prihodnosti?
DmitryO: Veliko sem razmišljal o tem in imam jasen odgovor. Prvi - statefull - navsezadnje je brez stanja lažje narediti. Kubernetes je sprva v to vlagal več, s tem se je vse začelo. Stateless deluje v Kubernetesu skoraj popolno, prav nič se mu ne more pritoževati. Glede na statefull je še vedno veliko težav ali bolje rečeno nians. Tam že imamo vse v redu, ampak to smo mi. Trajalo bo vsaj še nekaj let, da bo to delovalo za vse. To ni izračunana številka, ampak moj občutek iz glave.
Skratka, statefull se mora – in se bo – razvijati zelo močno, saj vse aplikacije shranjujejo svoj status, brezdržavnih aplikacij ni. To je iluzija, vedno rabiš neko bazo podatkov in še kaj. Pri Statefullu gre za popravljanje vsega, kar lahko, popravljanje vseh napak, izboljšanje vseh težav, s katerimi se trenutno soočate - recimo temu posvojitev.
Stopnja neznanega, stopnja nerešenih problemov, stopnja verjetnosti, da na nekaj naletimo, se bo dramatično zmanjšala. To je pomembna zgodba. In operaterji – vse, kar je povezano s kodificiranjem skrbniške logike, upravljavske logike, da bi dobili enostavno storitev: preprosta storitev MySQL, enostavna storitev RabbitMQ, enostavna storitev Memcache – na splošno so vse te komponente, ki jih potrebujemo, da zagotovimo, da deluje takoj po zagonu. . To samo reši težavo, da želimo podatkovno bazo, vendar je ne želimo upravljati, ali želimo Kubernetes, vendar je nočemo upravljati.
Ta zgodba z razvojem operaterjev v takšni ali drugačni obliki bo pomembna v naslednjih nekaj letih.
Mislim, da bi se morala enostavnost uporabe zelo povečati - škatla bo vedno bolj črna, vedno bolj zanesljiva, z vedno več preprostimi zavoji.
Nekoč sem poslušal stari intervju Isaaca Asimova iz 80-ih na YouTubu v Saturday Night Live - oddaja tipa Urgant, samo zanimiva. Tam so ga vprašali o prihodnosti računalnikov. Dejal je, da je prihodnost v preprostosti, kot je bilo pri radiu. Radijski sprejemnik je bil prvotno zapletena stvar. Da bi ujeli val, je bilo potrebnih 15 minut, da zavrtite vrtavke, zavrtite vrtavke in na splošno veste, kako vse deluje, razumete fiziko prenosa radijskih valov. Posledično je radio ostal z enim zasukom.
Zdaj v 2019 kateri radio? V avtu radijski sprejemnik najde vse valove, imena postaj. Fizika procesa se v 100 letih ni spremenila, enostavnost uporabe se je. Zdaj in ne samo zdaj, že leta 1980, ko je bil intervju z Azimovom, so vsi uporabljali radio in nihče ni pomislil, kako deluje. Vedno je delovalo – to je samoumevno.
Asimov je nato dejal, da bo z računalniki podobno – enostavnost uporabe se bo povečala. Če je bilo leta 1980 treba pridobiti posebno izobrazbo za pritiskanje gumbov na računalniku, potem v prihodnosti temu ne bo več tako.
Občutek imam, da se bo s Kubernetesom in z infrastrukturo zelo povečala tudi enostavnost uporabe. To je po mojem mnenju očitno - leži na površini.
Kaj storiti z inženirji?
- In kaj se bo potem zgodilo z inženirji, sistemskimi skrbniki, ki podpirajo Kubernetes?
Dmitry: In kaj se je zgodilo z računovodjo po pojavu 1C? Približno enako. Pred tem so računali na list papirja – zdaj v programu. Produktivnost dela se je povečala za rede velikosti, vendar delo samo ni izginilo iz tega. Če je prej za privijanje žarnice potrebovalo 10 inženirjev, bo zdaj dovolj eden.
Zdi se mi, da število programske opreme in število nalog zdaj raste hitreje, kot se pojavljajo novi DevOps in se povečuje učinkovitost. Zdaj je na trgu specifično pomanjkanje in bo trajalo še dolgo. Kasneje bo vse prešlo v neko normo, pri kateri se bo povečala učinkovitost dela, vse več bo brezstrežniških, na Kubernetes bo priključen nevron, ki bo izbral vse vire, kot je treba, in nasploh dela vse. sama od sebe, kot bi morala - oseba se odmakne in se ne vmešava.
A odločitve mora vseeno nekdo sprejemati. Jasno je, da je stopnja usposobljenosti in specializacije te osebe višja. Zdaj v računovodstvu ne rabiš 10 zaposlenih, ki vodijo računovodske knjige, da se jim roka ne utrudi. Samo ni potrebno. Številne dokumente sistem za elektronsko upravljanje dokumentov samodejno skenira in prepozna. En pameten glavni računovodja je dovolj, že z veliko večjimi veščinami, z dobrim razumevanjem.
Na splošno tako v vseh panogah. Enako je z avtomobili: prej so bili avtomobilu pripeti avtomehanik in trije vozniki. Zdaj je vožnja z avtomobilom najpreprostejši proces, v katerem vsak dan sodelujemo vsi. Nihče ne misli, da je avto nekaj zapletenega.
DevOps ali sistemski inženiring ne bo šel nikamor - visoka raven in učinkovitost dela se bosta povečala.
- Slišal sem tudi zanimivo idejo, da se bo delo dejansko povečalo.
Dmitry: Seveda, stoodstotno! Ker količina programske opreme, ki jo pišemo, nenehno narašča. Število težav, ki jih rešujemo s programsko opremo, nenehno narašča. Število delovnih mest narašča. Zdaj je trg DevOps strašno pregret. To se pozna pri pričakovanih plačah. V dobrem smislu, ne da bi se spuščali v podrobnosti, bi morali biti mlajši, ki želijo X, srednji, ki želijo 1,5X, in starejši, ki želijo 2X. In zdaj, če pogledate moskovski trg plač DevOps, mlajši želi od X do 3X, starejši pa od X do 3X.
Nihče ne ve, koliko stane. Višina plače se meri po samozavesti - popolna norišnica, po pravici povedano, strašno pregret trg.
Seveda se bo ta situacija zelo kmalu spremenila - prišlo bi moralo do neke zasičenosti. Pri razvoju programske opreme ni tako – kljub dejstvu, da vsi potrebujejo razvijalce in vsi potrebujejo dobre razvijalce, trg ve, kdo koliko stane – industrija se je ustalila. Z DevOps zdaj ni tako.
- Iz tega, kar sem slišal, sem sklepal, da trenutni sistemski skrbnik ne bi smel veliko skrbeti, vendar je čas, da prenesete znanja in se pripravite na dejstvo, da bo jutri več dela, vendar bo bolj visoko usposobljeno.
Dmitry: Vsekakor. Na splošno živimo v letu 2019 in pravilo življenja je naslednje: vseživljenjsko učenje – učimo se vse življenje. Zdi se mi, da zdaj to že vsi vedo in čutijo, a vedeti ni dovolj - to moraš narediti. Vsak dan se moramo spremeniti. Če tega ne bomo storili, bomo prej ali slej padli na obrobje stroke.
Bodite pripravljeni na ostre zavoje za 180 stopinj. Ne izključujem situacij, ko se nekaj dramatično spremeni, izumi se nekaj novega - to se zgodi. Hop! — in zdaj ravnamo drugače. Pomembno je, da ste na to pripravljeni in se ne znojite. Lahko se zgodi, da se bo jutri vse, kar počnem, izkazalo za nepotrebno – nič, že celo življenje študiram in sem se pripravljen naučiti še česa. To ni problem. Za varnost zaposlitve se ne smete bati, morate pa biti pripravljeni na nenehno učenje česa novega.
Želje in minuta oglašanja
- Imate kakšne želje?
Dmitry: Ja, imam nekaj želja.
Prvi in trgovski - naročite se . Dragi bralci, pojdite na YouTube in se naročite na naš kanal. Nekje čez mesec dni bomo začeli z aktivno širitvijo na video storitev, imeli bomo kup izobraževalnih vsebin o Kubernetesu, odprtih in drugačnih: od praktičnih stvari, do laboratorijev, do globokih temeljnih teoretičnih stvari in kako aplicirati Kubernetes na raven načel in vzorcev.
Druga merkantilna želja - pojdi na in daj zvezdice, ker jih jemo. Če nam ne daš zvezdic, ne bomo imeli kaj jesti. To je kot mana v računalniški igrici. Nekaj delamo, delamo, poskušamo, nekdo pravi, da so to grozna kolesa, nekdo, da je na splošno vse narobe, vendar nadaljujemo in delujemo popolnoma pošteno. Vidimo problem, ga rešujemo in delimo svoje izkušnje. Zato nam dajte zvezdico, od vas se ne bo zmanjšala, ampak bo prišla k nam, ker se hranimo z njimi.
Tretja, pomembna in nič več trgovska želja - nehaj verjeti v pravljice. Vi ste profesionalci. DevOps je zelo resen in odgovoren poklic. Nehajte se igrati na delovnem mestu. Naj vas klikne in razumeli boste. Predstavljajte si, da pridete v bolnišnico in tam zdravnik eksperimentira na vas. Razumem, da je to morda za nekoga žaljivo, vendar najverjetneje ne gre zate, ampak za nekoga drugega. Povejte tudi drugim, naj prenehajo. To nam vsem resnično pokvari življenje - mnogi začnejo obravnavati operacijo, skrbnike in DevOps kot tipe, ki so spet nekaj pokvarili. To se je največkrat »pokvarilo« zaradi dejstva, da smo se šli igrat in nismo hladnokrvno gledali, da je pri nas tako, ampak pri nas je tako.
To ne pomeni, da ne smete eksperimentirati. Moramo eksperimentirati, to počnemo sami. Če sem iskren, tudi sami včasih igramo - to je seveda zelo slabo, a nič človeškega nam ni tuje. Leto 2019 razglasimo za leto resnih premišljenih eksperimentov, ne iger na trgu. Verjetno je tako.
- Najlepša hvala!
Dmitry: Hvala, Vitaly, za čas in za intervju. Dragi bralci, najlepša hvala, če ste nenadoma prišli do te točke. Upam, da smo vam prinesli vsaj nekaj misli.
V intervjuju se je Dmitry dotaknil vprašanja werfa. Zdaj je to univerzalni švicarski nož, ki rešuje skoraj vse naloge. Vendar ni bilo vedno tako. Vklopljeno na festivalu Dmitry Stolyarov bo podrobno govoril o tem orodju. v poročilu tam bo vse: težave in skrite nianse Kubernetesa, rešitve za te težave in podrobna trenutna implementacija werfa. Pridruži se 27. in 28. maja, ustvarili bomo popolna orodja.
Vir: www.habr.com