Înainte de Vitalii Khabarov a realizat un interviu cu Dmitri Stolyarov (), director tehnic și cofondator al companiei „Flant”. Vitalii l-a întrebat pe Dmitri despre ce face „Flant”, despre Kubernetes, dezvoltarea ecosistemului, suport. Au discutat despre de ce este nevoie de Kubernetes și dacă este cu adevărat necesar. De asemenea, au vorbit despre microservicii, Amazon AWS, abordarea „Am noroc” în DevOps, viitorul Kubernetes, de ce, când și cum va cuceri lumea, perspectivele DevOps și la ce trebuie să se pregătească inginerii în viitorul apropiat cu simplificarea și rețelele neuronale.
în forma unui podcast poate fi ascultat pe DevOps Deflope — un podcast în limba rusă despre DevOps, iar mai jos — versiunea textului.
Aici și mai departe întrebările sunt adresate de un inginer de la Express42.
Despre „Flant”
— Dima, salut. Ești directorul tehnic al „” și de asemenea fondator al acesteia. Te rog să ne povestești ce face compania și ce rol ai tu în aceasta?
Dmitri: Din exterior, pare că suntem niște tipuri care merg și pun Kubernetes peste tot și fac ceva cu el. Dar nu este așa. Am început ca o companie care se ocupă cu Linux, dar de mult timp activitatea noastră principală este întreținerea proiectelor de producție și highload de la A la Z. De obicei, construim întreaga infrastructură de la zero și apoi ne asumăm responsabilitatea pe termen lung pentru aceasta. Prin urmare, principala activitate pe care o îndeplinește „Flant”, pentru care primește bani, este asumarea responsabilității și implementarea producției de la A la Z.
Eu, ca director tehnic și unul dintre cofondatori, mă ocup non-stop de găsirea de metode pentru a îmbunătăți disponibilitatea producției, a simplifica exploatarea acesteia, a ușura viața administratorilor și a face viața dezvoltatorilor mai plăcută.
Despre Kubernetes
— În ultima vreme, de la „Flant” observ multe prezentări și despre Kubernetes. Cum ați ajuns la el?
Dmitri: Am mai povestit despre asta de multe ori, dar nu-mi pare rău să repet. Consider că este corect să repet această temă, deoarece apare confuzie între cauză și efect.
Aveam cu adevărat nevoie de un instrument. Ne-am confruntat cu o mulțime de probleme, am luptat, le-am depășit prin diverse soluții improvizate și simțeam nevoia unui instrument. Am examinat multe opțiuni diferite, ne-am construit propriile soluții, acumulând experiență. Treptat, am ajuns la momentul în care am început să folosim Docker aproape imediat după ce a apărut - în jurul anului 2013. La apariția sa, aveam deja multă experiență cu containerele; chiar am scris o variantă asemănătoare cu „Docker” - câteva soluții improvizate pe Python. Odată cu apariția Docker, a apărut posibilitatea de a renunța la improvizații și de a utiliza o soluție fiabilă, susținută de comunitate.
Povestea cu Kubernetes este similară. La momentul în care a început să câștige traction - pentru noi aceasta este versiunea 1.2 - aveam deja o mulțime de soluții improvizate atât pe Shell, cât și pe Chef, pe care încercam cumva să le orchestrăm cu Docker. Ne uitam serios la Rancher și la alte soluții, dar atunci a apărut Kubernetes, în care totul a fost realizat exact așa cum am fi făcut noi sau chiar mai bine. Nu ai ce să reproșezi.
Da, aici există o anumită lipsă, dincolo de o altă lipsă - multe aspecte nesoluționate, iar 1.2 este de-a dreptul terifiant, dar... Kubernetes este ca o clădire în construcție - te uiți la proiect și înțelegi că va fi grozav. Dacă clădirea are deja fundație și două etaje, atunci înțelegi că mai bine să nu te muți încă, dar cu software-ul aceste probleme nu există - poate fi folosit deja.
Nu am avut niciun moment în care ne-am gândit dacă să folosim Kubernetes sau nu. L-am așteptat cu mult înainte de a apărea și încercam să ne facem analogii.
Despre Kubernetes
— Participați direct la dezvoltarea Kubernetes în sine?
Dmitri: Moderat. Mai degrabă participăm la dezvoltarea ecosistemului. Trimitem un anumit număr de pull requests: în Prometheus, în diverse operatoare, în Helm - în ecosistem. Din păcate, nu pot urmări tot ce facem și aș putea greși, dar nu avem niciun pull request în nucleu.
— În același timp, dezvoltați multe dintre propriile instrumente în jurul Kubernetes?
Dmitri: Strategia este aceasta: ne implicăm și trimitem pull request-uri la tot ce există deja. Dacă acolo nu sunt acceptate pull requests, pur și simplu le forckuim pentru noi și trăim, până când ele sunt acceptate cu versiunile noastre. Apoi, când ajunge la upstream, revenim la versiunea upstream.
De exemplu, avem un operator Prometheus, cu care am alternat de câteva ori între upstream-ul versiunii noastre, probabil de 5 ori. Ne trebuie o caracteristică, am trimis un pull request, trebuie să o lansăm mâine și nu dorim să așteptăm să fie lansată în upstream. Astfel, ne construim noi versiunea cu caracteristica de care avem nevoie, pe toate clusterele noastre. Apoi, acest lucru, de exemplu, este adus în upstream cu cuvintele: „Băieți, hai să facem pentru un caz mai general”, iar noi, sau altcineva, finalizăm asta și, în timp, se reîntoarce înapoi.
Tot ce există, încercăm să dezvoltam.. Multe elemente care nu există încă, fie că nu au fost create, fie că au fost concepute dar nu implementate, le facem noi. Și nu pentru că ne place procesul în sine sau construirea de biciclete ca industrie, ci pur și simplu pentru că avem nevoie de acest instrument. Desigur, ni se pune frecvent întrebarea de ce am realizat un anumit lucru? Răspunsul este simplu - pentru că trebuia să mergem mai departe, să rezolvăm o problemă practică, și am rezolvat-o cu acest instrument.
Drumul este întotdeauna astfel: căutăm foarte atent și, dacă nu găsim nicio soluție, cum să transformăm o pâine într-un troleibuz, atunci ne facem propria pâine și propriul troleibuz.
Instrumentele „Flanta”
— Știu că în prezent „Flanta” dispune de operatori addon, operatori shell, instrumente dapp/werf. Așa cum înțeleg, acesta este același instrument în diferite incarnații. De asemenea, înțeleg că în interiorul „Flanta” există multe alte instrumente. Este corect?
Dmitri: Avem multe alte lucruri pe GitHub. Din ceea ce îmi amintesc acum, avem statusmap - un panou pentru Grafana, care a fost bine primit de toată lumea. Acesta este menționat aproape în fiecare a doua articol despre monitorizarea Kubernetes pe Medium. Este imposibil să explic pe scurt ce este statusmap - este nevoie de un articol separat, dar este un lucru foarte util pentru monitorizarea statutului în timp, deoarece în Kubernetes trebuie adesea să arătăm statutul în timp. De asemenea, avem LogHouse - este un instrument bazat pe ClickHouse și magie neagră pentru colectarea de loguri în Kubernetes.
Multe utilitare! Și vor fi și mai multe, deoarece un anumit număr de soluții interne vor fi lansate în acest an. Dintre cele mari, pe baza operatorului addon, există o grămadă de addon-uri pentru Kubernetes, cum ar fi cum să instalăm corect sert manager - un instrument pentru gestionarea certificatelor, cum să instalăm corect Prometheus cu o mulțime de extensii - sunt vreo douăzeci de binare diferite care excelează datele și colectează ceva, iar pentru acest Prometheus avem o grafică fantastică și alerte. Toate acestea sunt doar o grămadă de addon-uri pentru Kubernetes, care se instalează în cluster, iar acesta se transformă dintr-un simplu în unul sofisticat, automatizat, în care multe întrebări sunt deja rezolvate. Da, facem multe.
Dezvoltarea ecosistemului
— Mi se pare că acesta este un aport foarte mare la dezvoltarea acestui instrument și a metodelor sale de utilizare. Poți să-ți dai seama aproximativ cine ar mai contribui la dezvoltarea ecosistemului?
Dmitri: În Rusia, dintre companiile care activează pe piața noastră - nimeni nu se apropie.. Desigur, aceasta este o afirmație îndrăzneață, pentru că există jucători mari, cum ar fi Mail și Yandex - și ei fac ceva cu Kubernetes, dar chiar și ei nu s-au apropiat de contribuția companiilor pe plan mondial, care fac mult mai mult decât noi. Este greu să compari "Flant" cu un personal de 80 de oameni și Red Hat, care are doar pentru un Kubernetes 300 de ingineri, dacă nu greșesc. Este dificil de comparat. La noi în departamentul R&D sunt 6 oameni, inclusiv eu, care dezvoltăm toate uneltele noastre. 6 oameni față de 300 de ingineri de la Red Hat - este cumva greu de comparat.
— Cu toate acestea, atunci când chiar și acești 6 oameni pot să facă ceva cu adevărat util și transferabil, când se confruntă cu o problemă practică și oferă soluția comunității - este un caz interesant. Înțeleg că în companiile tehnologice mari, unde există propria dezvoltare și echipă de suport Kubernetes, pot fi dezvoltate unelte asemănătoare. Acesta este un exemplu pentru ele, că se poate dezvolta și oferi comunității, dând un impuls întregii comunități care folosește Kubernetes.
Dmitri: Probabil că este specificitatea integratorului, caracteristica sa. Avem multe proiecte și vedem multe situații diferite. Pentru noi, principala modalitate de a crea valoare adăugată este să analizăm aceste cazuri, să găsim comunități și să le ieftinim cât mai mult posibil. Ne ocupăm activ de asta. Îmi e greu să vorbesc despre Rusia și lume, dar avem aproximativ 40 de ingineri DevOps în companie care se ocupă cu Kubernetes. Nu cred că în Rusia sunt multe companii cu un număr comparabil de specialiști care înțeleg Kubernetes, dacă există vreodată.
Înteleg tot ce implică denumirea de inginer DevOps, toți înțeleg și s-au obișnuit să numească inginerii DevOps ingineri DevOps, nu vom discuta despre asta. Cei 40 de minunați ingineri DevOps se confruntă zilnic cu probleme și le rezolvă, noi doar analizăm această experiență și încercăm să generalizăm. Înțelegem că dacă va rămâne în interior, în unul sau doi ani instrumentul va fi inutil, deoarece undeva în comunitate va apărea un instrument gata. Nu are sens să acumulăm această experiență în interior — este pur și simplu o risipă de resurse și timp în dev/null. Așa că nu ne pare rău. Publicăm cu mare plăcere și înțelegem că trebuie să publicăm, să dezvoltăm, să promovăm, să facem cunoscut, pentru ca oamenii să-l folosească și să adauge experiența lor — atunci totul crește și trăiește. Astfel, în doi ani instrumentul nu ajunge la gunoi. Nu ne pare rău să continuăm să investim resurse, deoarece vedem că cineva folosește instrumentul tău, iar în doi ani deja îl folosește toată lumea.
Aceasta face parte din strategia noastră mare cu dapp/werf. Nu-mi amintesc când am început să-l facem, pare că acum 3 ani. Inițial, a fost complet pe shell. A fost un super proof of concept, am rezolvat anumite sarcini particulare — a funcționat! Dar cu shell sunt probleme, nu mai poți dezvolta mai departe, a programa pe shell este o ocupație deosebită. Aveam obiceiul să scriem pe Ruby, în consecință, am refăcut ceva pe Ruby, am dezvoltat, dezvoltat, dezvoltat, și ne-am lovit de realitatea că comunitatea, mulțimea, care nu spune "vrem sau nu vrem", se ferește de Ruby, cum nu e amuzant. Am realizat că trebuie să scriem tot acest lucru pe Go, pentru a corespunde pur și simplu primului punct din checklist: Instrumentul DevOps trebuie să fie un binar staticIndiferent dacă este Go sau nu, cel mai bine este un binar static scris în Go.
Am investit resurse, am rescris dapp-ul în Go și l-am numit werf. Dapp-ul nu mai este susținut, nu se dezvoltă, funcționează într-o ultimă versiune, dar există un upgrade absolut pe care îl putem urma.
De ce a fost creat dapp-ul
— Poți să ne spui pe scurt de ce a fost creat dapp-ul, ce probleme rezolvă?
Dmitri: Prima cauză este în procesul de construire. La început, am avut probleme mari cu construirea, când Docker nu suporta multi-stage, și am realizat multi-stage pe cont propriu. Apoi, am avut o mulțime de întrebări legate de curățarea imaginilor. Oricine face CI/CD se confruntă, mai devreme sau mai târziu, cu problema că sunt o mulțime de imagini construite, trebuie cumva să curățăm ce nu mai este necesar și să lăsăm doar ce trebuie.
A doua cauză este în desfășurare. Da, există Helm, dar acesta rezolvă doar o parte din probleme. Deși poate părea amuzant, este scris că „Helm este Managerul de Pachete pentru Kubernetes”. Exact, „the”. Mai sunt și cuvintele „Manager de Pachete” — ce așteptăm de obicei de la un Manager de Pachete? Spunem: „Manager de Pachete — instalează pachetul!” și ne așteptăm să ne spună: „Pachetul a fost instalat”.
Este interesant că spunem: „Helm, instalează pachetul”, iar când el răspunde că l-a instalat, se dovedește că abia a început instalarea — a spus Kubernetes: „Rulează această chestie!”, dar dacă a fost lansată sau nu, dacă funcționează sau nu, Helm nu rezolvă deloc această întrebare.
Rezultă că Helm este doar un preprocesor de text care încarcă date în Kubernetes.
Dar în cadrul oricărei desfășurări vrem să știm — aplicația a fost lansată în producție sau nu? A fost lansată în producție înseamnă că aplicația a ajuns acolo, o nouă versiune a fost desfășurată și funcționează corect. Helm nu rezolvă această problemă. Pentru a o rezolva, trebuie să investim mult efort, deoarece trebuie să dăm lui Kubernetes comanda de desfășurare și să monitorizăm ce se întâmplă — s-a desfășurat sau nu. Și există o mulțime de sarcini legate de desfășurare, curățare și construire.
Planuri
Încă din acest an vom trece la dezvoltarea locală. Vrem să ajungem la ceea ce era odată în Vagrant - am dat „vagrant up” și am avut mașini virtuale pornite. Vrem să ajungem într-o stare în care există un proiect în Git, scriem „werf up” și acesta ridică o copie locală a acestui proiect, desfășurată în mini-Kub local, cu toate directoarele conectate, convenabile pentru dezvoltare. În funcție de limbajul de dezvoltare, acest lucru se execută diferit, însă dorim să putem desfășura confortabil dezvoltarea locală sub fișierele montate.
Următorul pas pentru noi este să investim semnificativ în confortul dezvoltatorilor. Astfel, cu un singur instrument să pornim rapid proiectul local, să dezvoltăm, să trimitem în Git, iar acesta va fi desfășurat la fel pe stage sau în teste, în funcție de pipeline-uri, și apoi să ne putem duce pe producție cu același instrument. Această unitate, unificare, reproducibilitate a infrastructurii, de la mediu local la producție, este un aspect foarte important pentru noi. Dar acest lucru nu este încă disponibil în werf - tocmai plănuim să-l facem.
Însă calea către dapp/werf a fost mereu la fel ca și cu Kubernetes la început. Ne-am confruntat cu probleme, le-am rezolvat pe căi ocolitoare - am inventat soluții pentru noi în Shell, pe orice altceva. Apoi, am încercat să facem aceste soluții ocolitoare mai directe, să le generalizăm și să le consolidăm în binare, cu care pur și simplu ne împărtășim.
Există și o altă perspectivă asupra acestei întregi povești, cu analogii.
Kubernetes este șasiul unei mașini cu motor. Nu are uși, geamuri, receptor radio, aromaterapie - nu are absolut nimic. Doar cadrul și motorul. Și există Helm - acesta este volanul. E grozav că avem volan, dar avem nevoie și de piulița de direcție, de bara de direcție, de cutia de viteze și de roți, fără acestea nu se poate.
În cazul werf - acesta este un component adițional pentru Kubernetes. Acum avem în versiunea alfa werf, de exemplu, Helm este compilat chiar în interiorul werf, deoarece ne-a săturat să o facem singuri. Există multe motive pentru a face asta, despre care voi vorbi detaliat .
Acum, werf este un component mai integrat. Avem un volan gata, un pin de direcție – nu mă pricep foarte bine la mașini, dar este un bloc mare care rezolvă deja un spectru suficient de mare de sarcini. Nu trebuie să căutăm în catalog, să alegem o piesă potrivită pentru alta, să ne gândim cum să le montăm una de cealaltă. Primim un combinezon gata, care rezolvă imediat o mulțime de sarcini. Dar în interior, este construit tot din aceleași componente open source, folosește la fel Docker pentru construcție, Helm pentru o parte din funcționalitate și mai sunt câteva alte biblioteci. Este un instrument integrat, pentru a obține rapid și convenabil un CI/CD grozav din cutie.
Este dificil să susții Kubernetes?
— Tu povestești despre experiența voastră, că ați început să utilizați Kubernetes, acesta este pentru voi cadrul, motorul, și că pe el puteți adăuga multe lucruri diverse: caroserie, volan, să montați pedale, scaune. Întrebarea care apare este – cât de greu vă este să susțineți Kubernetes? Aveți o experiență bogată, cât timp și resurse alocați strict pentru susținerea Kubernetes în afara tuturor celorlalte?
Dmitri: Aceasta este o întrebare foarte complexă și, pentru a răspunde, trebuie să înțelegem ce înseamnă susținerea și ce vrem de la Kubernetes. Poate ne poți lămuri?
— Cât timp știu și cum văd eu, acum multe echipe vor să încerce Kubernetes. Toți se avântă în el, îl instalează pe genunchi. Am senzația că oamenii nu înțeleg întotdeauna complexitatea acestui sistem.
Dmitri: Așa este.
— Cât de greu este să iei și să instalezi Kubernetes de la zero, astfel încât să fie gata pentru producție?
Dmitri: Cum crezi, cât de greu este să transplantezi o inimă? Înțeleg, întrebarea este compromițătoare. Să folosești un bisturiu și să nu greșești – nu este atât de greu. Dacă îți spun unde să tai și unde să coși, atunci procedura în sine nu este complicată. Este greu să garantăm de fiecare dată că va reuși.
Să instalezi Kubernetes și să-l faci să funcționeze este simplu: chic! – s-a instalat, sunt o mulțime de metode de instalare. Dar ce se va întâmpla când apar probleme?
Întotdeauna apar întrebări – ce nu am luat în considerare? Ce nu am făcut? Ce parametri ai kernel-ului Linux am specificat greșit? Doamne, dar chiar i-am specificat?! Ce componente Kubernetes am instalat și ce nu? Apar mii de întrebări, iar pentru a răspunde la ele, trebuie să ai 15-20 de ani de experiență în această industrie.
Am un exemplu recent pe această temă care poate ilustra semnificația problemei „Este greu să întreții Kubernetes?”. Cu ceva vreme în urmă, ne-am gândit serios să vedem dacă nu ar fi util să implementăm Cilium ca rețea în Kubernetes.
O să explic ce este Cilium. În Kubernetes există multe implementări diferite ale subsistemului de rețea, iar una dintre ele este cu adevărat interesantă - este Cilium. Care este ideea sa? În kernelul Linux, a apărut cu ceva timp în urmă posibilitatea de a scrie hook-uri pentru kernel care intervin în subsistemul de rețea și în diferite alte subsisteme, permițând ocolirea unor părți mari din kernel.
În kernelul Linux există istoric ip rout, netfilter, bridge-uri și multe alte componente vechi de 15, 20 sau 30 de ani. În ansamblu, ele funcționează, totul este grozav, dar acum avem o multitudine de containere, iar aceasta arată ca un turn din 15 cărămizi unele peste altele, în timp ce tu stai în picioare pe el pe o singură picior - o senzație ciudată. Acest sistem a evoluat istoric cu multe nuanțe, ca un apendice în organism. În unele situații, există probleme de performanță, de exemplu.
Există un BPF minunat și posibilitatea de a scrie hook-uri pentru kernel - echipa a scris propriile hook-uri pentru kernel. Pachetul ajunge în kernelul Linux, iar ei îl scot imediat la intrare, îl procesează după cum trebuie fără bridge-uri, fără TCP, fără stiva IP - pe scurt, ocolind tot ce este scris în kernelul Linux, și imediat îl redirecționează către container.
Ce a rezultat? O performanță foarte bună, caracteristici grozave - pur și simplu fantastic! Dar ne uităm la asta și vedem că pe fiecare mașină este un program care se conectează la API-ul Kubernetes și, pe baza datelor pe care le obține din acest API, generează cod C și compilează binare pe care le încarcă în kernel pentru ca aceste hook-uri să funcționeze în kernel space.
Ce se va întâmpla dacă ceva nu merge bine? Nu știm. Pentru a înțelege acest lucru, trebuie să citim tot acest cod, să înțelegem toată logica, iar asta este extrem de complicat. Dar, pe de altă parte, există aceste bridge-uri, netfiltere, ip rout - nu am citit sursa lor, iar 40 de ingineri care lucrează în compania noastră la fel. Poate că doar câțiva cunosc unele părți.
Și care e diferența? Se pare că există ip rout, nucleul Linux, și există un nou instrument - care e diferența, nu înțelegem niciunul, nici pe celălalt. Dar ne este frică să folosim noul - de ce? Pentru că, dacă instrumentul are 30 de ani, atunci în 30 de ani toate bug-urile au fost găsite, am trecut peste toate obstacolele și nu trebuie să știm despre toate - funcționează ca o cutie neagră și funcționează mereu. Toată lumea știe ce șurubelniță de diagnostic să bage în ce loc, ce tcpdump să pornească în ce moment. Toată lumea cunoaște bine utilitarele de diagnostic și înțelege cum funcționează acest set de componente în nucleul Linux - nu cum e structurat, ci cum să-l folosești.
Dar Cilium, care este extrem de tare, nu are 30 de ani, el nu a fost rafinat încă. Avem aceeași problemă cu Kubernetes, este o copie. Că Cilium se instalează perfect, că Kubernetes se instalează perfect, dar când ceva nu merge bine în producție, sunteți capabili să înțelegeți rapid ce nu a mers bine în situații critice?
Când vorbim despre cât de greu este să întreții Kubernetes - nu, este foarte simplu, și da, incredibil de complicat. Kubernetes funcționează perfect de unul singur, dar cu un miliard de nuanțe.
Despre abordarea „Îmi va merge bine”
- Există companii unde aceste nuanțe vor apărea aproape garantat? Să presupunem că Yandex își va transfera brusc toate serviciile pe Kubernetes, acolo va fi o încărcare considerabilă.
Dmitri: Nu, nu e vorba despre încărcare, ci despre lucruri simple. De exemplu, avem Kubernetes, am desfășurat acolo o aplicație. Cum să înțelegem că funcționează? Nu există un instrument gata făcut pentru a înțelege că aplicația nu se prăbușește, pur și simplu nu există. Nu există un sistem gata care să trimite alerte - trebuie să configurăm aceste alerte și fiecare grafic. Iar noi actualizăm Kubernetes.
Există Ubuntu 16.04. Poate că este o versiune mai veche, dar noi suntem în continuare pe ea, pentru că este LTS. Are systemd, iar un aspect al acestuia este că nu curăță grupurile C. Kubernetes pornește poduri, creează grupuri C, apoi șterge podurile, și cumva rezultatul este că rămân fragmente de systemd. Asta duce la faptul că, în timp, orice mașină începe să se blocheze. Nu este nici măcar o problemă de highload. Dacă sunt lansate constant poduri, de exemplu, dacă există un Cron Job care generează constant poduri, atunci o mașină cu Ubuntu 16.04 va începe să se blocheze după o săptămână. Va avea în mod constant o medie mare de load din cauza că au fost create multe grupuri C. Aceasta este o problemă cu care se confruntă oricine instalează pur și simplu Ubuntu 16 și adaugă Kubernetes.
Să zicem că cumva el își va actualiza systemd sau altceva, dar în kernelul Linux până la 4.16 este și mai amuzant — la ștergerea grupurilor C, acestea pătrund în kernel și, de fapt, nu sunt șterse. Așa că, după o lună de funcționare pe această mașină, va fi imposibil să verificăm statistica memoriei pe poduri. Scos un fișier, rulează în program, iar un fișier rulează 15 secunde, pentru că kernelul calculează foarte mult timp în interior pe milioane de grupuri C, care par șterse, dar n-așa — ele pătrund.
Sunt foarte multe astfel de detalii și acolo și aici. Nu este o întrebare cu care gigantii să se confrunte uneori, în condiții de suprasolicitare — nu, aceasta este o problemă a lucrurilor de zi cu zi. Oamenii pot trăi așa luni de zile — au instalat Kubernetes, au deployat aplicația — totul pare să funcționeze. Multe persoane sunt mulțumite așa. Despre faptul că, cândva, această aplicație se va prăbuși dintr-un motiv oarecare, nici măcar nu vor aflat, alerta nu va veni, dar pentru ei este normal. În trecut au trăit pe virtualuri fără monitorizare, acum s-au mutat în Kubernetes, de asemenea fără monitorizare — care este diferența?
Problema este că, atunci când mergem pe gheață, niciodată nu știm grosimea ei, dacă nu am măsurat-o dinainte. Mulți merg și nu se îngrijorează, pentru că au mai mers înainte.
Din punctul meu de vedere, nuanța și complexitatea exploatării oricărei sisteme constă în a garanta că grosimea gheții este suficientă pentru a rezolva sarcinile noastre. Despre asta este vorba.
În IT, cred că sunt prea multe abordări de tipul „Am noroc”. Mulți instalează software, folosesc biblioteci software în speranța că le va merge bine. În general, mulți au noroc. Probabil că de aceea funcționează.
— Din perspectiva mea pesimistă, arată cam așa: când riscurile sunt mari, iar aplicația trebuie să funcționeze, atunci este nevoie de suport de la „Flant”, posibil de la Red Hat, sau este nevoie de o echipă internă dedicată exact Kubernetes-ului, care să fie pregătită să-l susțină.
Dmitri: Obiectiv, așa este. A te implica singur în povestea cu Kubernetes pentru o echipă mică este un anumit grad de risc.
Avem nevoie de containere?
— Poți să-mi spui cât de răspândit este Kubernetes în Rusia, de fapt?
Dmitri: Nu am aceste date și nu sunt sigur că le are cineva. Vorbim despre „Kubernetes, Kubernetes”, dar există și un alt punct de vedere asupra acestei probleme. Cât de răspândite sunt containerele, nu știu nici asta, dar știu un număr din rapoartele de pe internet, că 70% din containere sunt orchestrate de Kubernetes. A fost o sursă de încredere pe un eșantion destul de mare din întreaga lume.
Apoi, o altă întrebare — avem nevoie de containere? Am o senzație personală și, în general, poziția companiei „Flant” este că Kubernetes este standardul de facto.
Nu va exista nimic în afară de Kubernetes.
Este un adevărat game-changer în domeniul gestionării infrastructurii. Pur și simplu absolut — nu mai sunt Ansible, Chef, mașini virtuale, Terraform. Nu mai vorbesc despre metodele vechi, fără profesionalism. Kubernetes este un adevărat changer, și acum va fi doar așa.
Este clar că unora le trebuie câțiva ani, iar altora câteva zeci, pentru a-și da seama de asta. Nu am nicio îndoială că nu va exista nimic în afară de Kubernetes și această nouă viziune: nu mai tăiem sistemul de operare, ci folosim infrastructure as code, dar nu cu cod, ci cu yml — infrastructură descrisă declarativ. Am senzația că va fi mereu așa.
— Deci, companiile care nu au trecut încă la Kubernetes vor trebui să facă acest pas sau vor rămâne în uitare. Am înțeles corect?
Dmitri: Asta nu este complet corect. De exemplu, dacă avem sarcina de a lansa un server DNS, acesta poate fi lansat pe FreeBSD 4.10 și poate funcționa perfect timp de 20 de ani. Pur și simplu funcționează și atât. Poate că, după 20 de ani, va fi necesar să actualizăm ceva o singură dată. Dacă vorbim despre software în formatul în care l-am lansat și acesta funcționează cu adevărat timp de mulți ani fără actualizări sau modificări, atunci, desigur, nu va exista Kubernetes. Nu este necesar acolo.
Tot ce ține de CI/CD – oriunde este necesar Continuous Delivery, unde este necesară actualizarea versiunilor, desfășurarea de modificări active, oriunde trebuie să se construiască redundanța – doar Kubernetes.
Despre microservicii
— Aici am un mic disonant. Pentru a lucra cu Kubernetes, este nevoie de suport extern sau intern – acesta este primul punct. Al doilea – atunci când abia începem dezvoltarea, suntem o mică start-up, nu avem încă nimic, dezvoltarea pentru Kubernetes sau chiar pentru o arhitectură de microservicii poate fi complicată și nu este întotdeauna justificată din punct de vedere economic. Mă interesează părerea ta – trebuie oare start-up-urile să înceapă imediat să scrie pentru Kubernetes sau este posibil să scrie mai întâi un monolit și apoi să ajungă la Kubernetes?
Dmitri: O întrebare interesantă. Am o prezentare despre microservicii De multe ori m-am confruntat cu faptul că oamenii încearcă să bată cuie cu un microscop. Abordarea în sine este corectă, noi ne proiectăm software-ul intern exact în acest mod. Dar când faci asta, trebuie să înțelegi clar ce faci. Cel mai mult în microservicii urăsc cuvântul „micro”. A apărut istoric, iar dintr-un motiv oarecare, oamenii cred că micro înseamnă foarte mic, mai puțin de un milimetru, ca un micrometru. Nu este așa.
De exemplu, există un monolit, care este scris de 300 de oameni, iar toți cei care au participat la dezvoltare înțeleg că există probleme și trebuie să fie împărțit în micro-bucăți – cam 10, fiecare dintre care este scris de 30 de oameni în varianta minimă. Este important, necesar și grozav. Dar când vine la noi un start-up unde 3 băieți foarte talentați au scris pe genunchi 60 de microservicii, caut întotdeauna corvalol.
Mi se pare că despre asta s-a vorbit de o mie de ori - am obținut un monolit distribuit în una sau alta din formele sale. Este economic nejustificat, foarte complicat în general. Pur și simplu, am văzut asta de atât de multe ori încât aproape mă doare, așa că continui să vorbesc despre asta.
Referitor la întrebarea inițială, există un conflict între faptul că, pe de o parte, Kubernetes este înfricoșător de utilizat, deoarece nu este clar ce se poate strica sau nu va funcționa, iar pe de altă parte, este clar că toți se îndreaptă în această direcție și nimic, în afară de Kubernetes, nu va exista. Răspunsul este - a cântări volumul de beneficii care vin, volumul de sarcini pe care le puteți rezolva.. Aceasta este o parte a balanței. Cealaltă parte sunt riscurile asociate cu întârzierile sau scăderea timpului de răspuns, a nivelului de disponibilitate - cu scăderea indicatorilor de performanță.
Aici stau lucrurile - fie ne mișcăm repede, iar Kubernetes permite îndeplinirea multor sarcini mult mai rapid și mai bine, fie utilizăm soluții fiabile, testate în timp, dar ne mișcăm mult mai lent. Această alegere trebuie să fie făcută de fiecare companie. Poate fi văzut ca un drum în junglă - când mergi pentru prima dată, poți întâlni o șarpe, un tigru sau un dihor sălbatic, iar când ai mers de 10 ori - ai bătătorit poteca, ai dat la o parte crengile, și merge mai ușor. Cu fiecare dată, poteca devine mai largă. Apoi, devine o șosea asfaltată, iar mai târziu un bulevard frumos.
Kubernetes nu stă pe loc. Din nou, întrebarea: Kubernetes, pe de o parte, sunt 4-5 binare, pe de altă parte, este întreaga ecosistemă. Este un sistem de operare care se află pe mașinile noastre. Ce este asta? Ubuntu sau Curios? Este nucleul Linux, o mulțime de componente suplimentare. Toate aceste lucruri au dat la o parte o șarpe veninos de pe drum, acolo au pus un gard. Kubernetes se dezvoltă foarte rapid și dinamic, iar volumul riscurilor, volumul necunoscutului se diminuează cu fiecare lună și, respectiv, aceste balanțe se reechilibrează.
Răspunzând la întrebarea ce ar trebui să facă un start-up, aș spune - veniți la „Flant”, plătiți 150 de mii de ruble și obțineți serviciul DevOps easy turnkey. Dacă sunteți un start-up mic format din câțiva dezvoltatori, acest lucru funcționează. În loc să angajați propriul vostru DevOps, care trebuie să învețe să rezolve problemele voastre și să-i plătiți un salariu în această perioadă, veți primi o soluție completă la toate problemele. Da, există unele dezavantaje. Noi, ca furnizor extern, nu putem fi la fel de implicați și nu putem reacționa rapid la modificările solicitate. Dar, în schimb, avem o mulțime de expertiză și soluții gata pregătite. Garantăm că, în orice situație, ne vom descurca rapid și vom readuce la viață orice Kubernetes.
Recomand cu tărie externalizarea start-up-urilor și a afacerilor consolidate până la dimensiunea la care puteți aloca o echipă de 10 oameni pentru operare, pentru că altfel nu are sens. Asta are sens categoric de a fi externalizat.
Despre Amazon și Google
— Se poate considera servicii de găzduire de la Amazon sau Google ca externalizare?
Dmitri: Da, desigur, asta rezolvă o serie de probleme. Dar din nou, există nuanțe. Trebuie să înțelegi cum să le folosești. De exemplu, sunt o mie de detalii în funcționarea Amazon AWS: Load Balancer-ul trebuie pregătit sau trebuie să scrieți din timp o solicitare că „băieți, ne va veni trafic, pregătiți-ne Load Balancer-ul!” Aceste nuanțe trebuie cunoscute.
Când apelati la oameni care se specializează în asta, obțineți aproape toate lucrurile tipice rezolvate. Acum avem 40 de ingineri, până la sfârșitul anului vor fi, probabil, 60 - suntem deja familiarizați cu toate aceste lucruri. Chiar dacă pe un anumit proiect ne confruntăm din nou cu această problemă, întrebăm rapid unul de celălalt și știm cum să o rezolvăm.
Probabil, răspunsul este acesta - desigur, soluția cloud reduce o parte din probleme. Întrebarea este dacă sunteți dispuși să aveți încredere în acești furnizori de găzduire și dacă își vor rezolva problemele. Amazon și Google s-au dovedit a fi de încredere. În toate cazurile noastre - cu siguranță. Nu avem alte experiențe pozitive. Toate celelalte cloud-uri cu care am încercat să lucrăm creează foarte multe probleme - și Ager, și tot ce există în Rusia, și toate tipurile de OpenStack în diverse implementări: Headster, Overage - tot ce vreți. Toate acestea creează probleme pe care nu dorim să le rezolvăm.
Așadar, răspunsul este da, dar, de fapt, nu există multe soluții hosted mature.
Cui îi trebuie Kubernetes?
— Și totuși, cui îi trebuie Kubernetes? Cine ar trebui să facă deja trecerea la Kubernetes, cine este clientul tipic „Flant”, care vine tocmai pentru Kubernetes?
Dmitri: Întrebarea este interesantă, pentru că acum, pe valul Kubernetes, mulți vin la noi: „Băieți, știm că faceți Kubernetes, fă-ne și nouă!”. Le răspundem: „Domnilor, noi nu facem Kubernetes, noi facem producție și tot ce ține de ea”. Pentru că a face producție, fără a realiza întreaga CI/CD și toată această poveste, în prezent este pur și simplu imposibil. Toată lumea a renunțat la separarea dintre dezvoltare și operațiuni.
Clienții noștri așteaptă lucruri diferite, dar toți speră la o mică minune, că au anumite probleme, iar acum — hop! — Kubernetes le va rezolva. Oamenii cred în minuni. Cu rațiunea realizează că nu va fi nicio minune, dar cu sufletul speră — dar poate că acest Kubernetes ne va rezolva totul acum, despre el se vorbește atât de mult! Poate că acum — hap! — este glonțul de argint, hap! — și avem 100% uptime, toți dezvoltatorii pot face 50 de release-uri care oricum ajung în producție și nu se strică. În general, o minune!
Când astfel de oameni vin la noi, le spunem: „Ne pare rău, dar minuni nu există”. Ca să fii sănătos, trebuie să te hranești bine și să faci sport. Ca să ai producție fiabilă, trebuie să o construiești cu fiabilitate. Ca să ai un CI/CD convenabil, trebuie să-l faci astfel. Este multă muncă de făcut.
Răspunzând la întrebarea, cui îi trebuie Kubernetes — Kubernetes nu este necesar nimănui.
Unii oameni au o percepție eronată că le trebuie Kubernetes. Oamenii au nevoie, au o nevoie profundă de a înceta să mai gândească, să se ocupe, să se intereseze de toate problemele infrastructurii și problemele de lansare a aplicațiilor lor. Ei doresc ca aplicațiile să funcționeze pur și simplu și să fie pur și simplu implementate. Pentru ei, Kubernetes este speranța că nu vor mai auzi povestea că „am stat acolo”, sau „nu putem să ieșim”, sau ceva asemănător.
De obicei, la noi vine directorul tehnic. De la el se cer două lucruri: pe de o parte, să ne ofere funcționalități, pe de alta parte — stabilitate. Noi propunem să preluăm noi acest lucru și să îl realizăm. Gloanțul de argint, mai degrabă, este că vei înceta să te gândești la aceste probleme și să pierzi timp. Vei avea oameni specializați care se vor ocupa de această problemă.
Formularea că avem nevoie de Kubernetes sau că cineva are nevoie de el este greșită.
Kubernetes este foarte necesar administratorilor, pentru că este o jucărie foarte interesantă cu care poți să te joci, să te ocupi. Să fim sinceri – toată lumea iubește jucăriile. Toți suntem, undeva, copii și când vedem ceva nou – vrem să ne jucăm cu el. Unii dintre noi au renunțat la asta, de exemplu, în administrarea sistemelor, pentru că s-au jucat deja și li s-a făcut deja lehamite de ea. Dar nu este deloc cazul tuturor. De exemplu, chiar dacă mi s-au cam plictisit jucăriile din domeniul administrării sistemelor și DevOps, eu tot iubesc jucăriile și îmi cumpăr în continuare lucruri noi. Toți oamenii, într-un fel sau altul, vor mereu să aibă jucării.
Nu trebuie să te joci cu producția. Ce nu recomand categoric să faci și ce observ acum peste tot este: „A, o jucărie nouă!” – au alergat să o cumpere, au cumpărat-o și: „Hai să o aducem acum la școală, să le arătăm tuturor prietenilor”. Nu faceți așa. Scuză-mă, copiii mei cresc, iar eu observ constant ceva în comportamentul lor, realizez asta în mine și apoi generalizez la ceilalți.
Răspunsul final: nu ai nevoie de Kubernetes. Trebuie să îți rezolvi problemele.
Poți obține că:
- producția nu se oprește;
- chiar și atunci când încearcă să se oprească, știm din timp despre asta și putem să intervenim;
- putem să-l schimbăm cu viteza de care avem nevoie pentru afacere și să facem acest lucru comod, fără să ne provoace probleme.
Există două nevoi reale: fiabilitate și dinamicitate/ flexibilitate în lansare. Oricine face în prezent proiecte IT, nu contează în ce domeniu – software pentru îmbunătățirea lumii, și care înțelege acest lucru, trebuie să-și rezolve aceste nevoi. Kubernetes, cu abordarea corectă, înțelegerea corectă și cu experiența suficientă, permite rezolvarea lor.
Despre serverless
– Dacă privim puțin mai departe în viitor, încercând să rezolvăm problema lipsei de dureri de cap legate de infrastructură, viteza de lansare și viteza de modificare a aplicației, apar noi soluții, de exemplu, serverless. Simți cumva un potențial în această direcție și, să zicem, un pericol pentru Kubernetes și soluții asemănătoare?
Dmitri: Aici trebuie să fac din nou o observație că nu sunt un prezicător care privește înainte și spune - va fi așa! Deși tocmai am făcut același lucru. Privesc în jur și văd o mulțime de probleme, de exemplu, cum funcționează tranzistorii într-un computer. Până la urmă, e amuzant, nu? Ne confruntăm cu diverse bug-uri în CPU.
A face serverless suficient de fiabil, ieftin, eficient și convenabil, rezolvând toate problemele ecosistemului. Aici sunt de acord cu Elon Musk că avem nevoie de o a doua planetă pentru a asigura redundanța pentru umanitate. Deși nu știu exact ce spune, înțeleg că nu sunt pregătit să zbor eu pe Marte și că asta nu se va întâmpla mâine.
Cu serverless este clar că este un lucru ideologic corect, la fel ca redundanța pentru umanitate - a avea două planete este mai bine decât una. Dar cum să facem asta acum? A trimite o expediție nu este o problemă dacă ne concentrăm eforturile. Să trimitem mai multe expediții și să colonizăm acolo câteva mii de oameni, cred că este, de asemenea, realist. Dar a crea o redundanță totală, astfel încât jumătate din umanitate să locuiască acolo, mi se pare acum imposibil, nu se poate lua în considerare.
Cu serverless este exact la fel: e un lucru grozav, dar este departe de problemele anului 2019. Aproape de 2030 - să trăim până atunci. Nu mă îndoiesc că vom trăi, cu siguranță vom trăi (repetați înainte de culcare), dar acum trebuie să rezolvăm alte probleme. E ca și cum ai crede într-un ponei fantastic numit Răsărit. Da, câteva procente din cazuri sunt rezolvate și sunt rezolvate excelent, dar subiectiv, serverless este o nebunie... Pentru mine, acest subiect este prea îndepărtat și prea greu de înțeles. Nu sunt pregătit să vorbesc. În 2019, cu serverless nu poți scrie nicio aplicație.
Cum va evolua Kubernetes
— Pe măsură ce ne îndreptăm spre acest potențial viitor splendid, cum crezi că va evolua Kubernetes și ecosistemul din jurul său?
Dmitri: M-am gândit mult la asta și am un răspuns clar. În primul rând, statefull — este totuși mai ușor de realizat un stateless. Kubernetes a investit mai mult în acest domeniu, de acolo a început totul. Stateless funcționează practic perfect în Kubernetes, nu ai nimic de reproșat. În ceea ce privește statefull, mai sunt o mulțime de probleme, mai bine zis, nuanțe. La noi funcționează deja foarte bine, dar noi suntem. Pentru ca acest lucru să funcționeze pentru toți, mai este nevoie de încă câțiva ani cel puțin. Acesta nu este un indicator calculat, ci o senzație personală.
Pe scurt, statefull trebuie să se dezvolte foarte mult — și o va face — pentru că toate aplicațiile noastre păstrează stare, nu există aplicații stateless. Este o iluzie, întotdeauna este nevoie de o bază de date și de ceva în plus. Statefull este îndreptarea tuturor lucrurilor posibile, corectarea tuturor bug-urilor, îmbunătățirea tuturor problemelor cu care ne confruntăm acum — să numim asta adoptare.
Nivelul necunoscutului, nivelul problemelor nerezolvate, nivelul probabilității de a se confrunta cu ceva, va scădea semnificativ. Aceasta este o poveste importantă. Iar operatorii — tot ce ține de codificarea logicii de administrare, logica de gestionare, pentru a obține un service ușor: MySQL easy service, RabbitMQ easy service, Memcache easy service, — toate aceste componente de care avem nevoie pentru a funcționa garantat din cutie. Acesta rezolvă exact acele dureri, că vrem o bază de date, dar nu vrem să o administrăm, sau vrem Kubernetes, dar nu vrem să-l administrăm.
Această poveste cu dezvoltarea operatorilor într-o formă sau alta va fi importantă în următorii câțiva ani.
Cred că va crește semnificativ simplitatea exploatării — cutia va deveni din ce în ce mai neagră, din ce în ce mai fiabilă, cu din ce în ce mai multe butoane simple.
Am ascultat o dată un interviu vechi cu Isaac Asimov din anii '80 pe YouTube la emisiunea Saturday Night Live — o transmisie de tip Urgant, dar interesantă. L-au întrebat despre viitorul calculatoarelor. A spus că viitorul constă în simplitate, așa cum a fost cu receptorul de radio. Receptorul de radio era inițial un lucru complicat. Pentru a prinde o frecvență, trebuia să învârți butoane timp de 15 minute, să răsuciți manete și să cunoști cum funcționează totul, să înțelegi fizica transmisiei undelor radio. În cele din urmă, în radio a rămas un singur buton.
Ce radio este acum în 2019? În mașină, radioul găsește toate undele, numele stațiilor. Fizica procesului nu s-a schimbat în 100 de ani, dar simplitatea utilizării s-a îmbunătățit. Acum, și nu doar acum, încă din 1980, când a fost un interviu cu Asimov, toată lumea folosea radio și nimeni nu se gândea la cum funcționează. A funcționat întotdeauna — este un dat.
Asimov spunea atunci că la fel se va întâmpla cu computerele — simplitatea utilizării va crește. Dacă în 1980 era necesar un anumit tip de educație pentru a apăsa butoane pe computer, în viitor nu va mai fi așa.
Am impresia că și în cazul Kubernetes și al infrastructurii va crește foarte mult simplitatea utilizării. Este evident — este la suprafață.
Ce se va întâmpla cu inginerii?
— Dar ce se va întâmpla cu inginerii, administratorii de sistem care suportă Kubernetes?
Dmitri: Ce s-a întâmplat cu contabilii după apariția 1C? Cam același lucru. Înainte se calcula pe hârtie — acum în program. Productivitatea muncii a crescut de ordine întregi, iar munca nu a dispărut. Dacă înainte erau necesari 10 ingineri pentru a schimba o bombă, acum va fi suficient un singur inginer.
Numărul de software și numărul de sarcini cred că cresc acum cu o viteză mai mare decât apar noi DevOps și se îmbunătățește eficiența. Acum există o penurie specifică pe piață și aceasta va dura mult. Mai târziu, totul va intra într-o normă în care eficiența muncii va crește, vor fi din ce în ce mai multe soluții serverless, iar Kubernetes va fi asociat cu o rețea neuronală care va aloca toate resursele exact atunci când este nevoie, și va face totul de una singură — oamenii, dați-vă la o parte și nu deranjați.
Dar totuși, soluțiile vor trebui să fie luate de cineva. Este clar că nivelul de calificare și specializarea acelei persoane sunt mai mari. Acum, în departamentul de contabilitate nu ai nevoie de 10 angajați care să țină evidența contabilității, astfel încât mâna lor să nu se obosească. Pur și simplu nu este necesar. Multe documente sunt scanate automat, recunoscute de sistemul de gestionare electronică a documentelor. Este suficient un contabil șef inteligent, deja cu mult mai multe abilități, cu o bună înțelegere.
În general, acest parcurs este prezent în toate industriile. La fel și cu automobilele: înainte, mașina era însoțită de un mecanic auto și de trei șoferi. Acum, conducerea unei mașini este un proces simplu, în care cu toții participăm zi de zi. Nimeni nu se gândește că automobilul este ceva complicat.
DevOps sau ingineria sistemelor nu vor dispărea niciodată - nivelul înalt și eficiența lucrului vor crește.
— Am auzit o idee interesantă că, de fapt, și volumul de muncă va crește.
Dmitri: Desigur, o sută de procente! Pentru că volumul de software pe care îl scriem crește constant. Numărul problemelor pe care le rezolvăm cu software crește constant. Volumul de muncă crește. Acum, piața DevOps este extrem de supraîncălzită. Acest lucru se observă în așteptările salariale. Într-un sens bun, fără a intra în detalii, ar trebui să existe juniori care doresc X, medii care doresc 1,5X și seniori care doresc 2X. Și acum, dacă ne uităm la piața salariilor DevOps din Moscova, un junior vrea de la X până la 3X și un senior vrea de la X până la 3X.
Nimeni nu știe cât costă. Nivelul salariului este măsurat prin încrederea ta - este un adevărat haos, dacă sunt sincer, piața este extrem de supraîncălzită.
Desigur, această situație se va schimba foarte curând - trebuie să apară o oarecare saturație. Cu dezvoltarea software-ului nu este la fel - deși dezvoltatorii sunt necesari tuturor și toată lumea are nevoie de dezvoltatori buni, piața înțelege cât costă fiecare - industria s-a stabilizat. Cu DevOps acum nu este la fel.
— Din ceea ce am auzit, am concluzionat că administratorul de sistem actual nu ar trebui să se îngrijoreze prea mult, dar ar fi timpul să-și dezvolte abilitățile și să se pregătească pentru faptul că mâine va fi mai multă muncă, dar va fi mai calificată.
Dmitri: O sută la sută. În general, trăim în anul 2019, iar regula de bază este: învățarea pe tot parcursul vieții - învățăm toată viața. Mi se pare că acum toți știu și simt acest lucru, dar a ști este insuficient - trebuie să acționăm. În fiecare zi trebuie să ne schimbăm. Dacă nu facem asta, mai devreme sau mai târziu vom fi lăsați pe marginea profesiei.
Fii pregătit pentru întoarceri bruşte de 180 de grade. Nu exclud situații în care ceva se va schimba radical, se va inventa ceva nou - așa se întâmplă. Hop! - și acum acționăm diferit. Este important să fii pregătit pentru asta și să nu te stresezi. S-ar putea întâmpla ca mâine tot ceea ce fac să devină inutil - nu-i nimic, am învățat toată viața și sunt pregătit să învăț ceva nou. Nu este o problemă. Nu trebuie să te temi de securitatea locului de muncă, dar trebuie să fii pregătit să înveți în mod constant ceva nou.
Dorințe și un moment de publicitate
— Ai vreo dorință?
Dmitri: Da, am câteva dorințe.
Prima și mercantilă - abonați-vă la . Stimați cititori, intrati pe YouTube și abonați-vă la canalul nostru. În aproximativ o lună vom începe o expansiune activă pe platforma de video, unde vom avea o mulțime de conținut educațional despre Kubernetes, deschis și divers: de la lucruri practice, până la laboratoare, până la concepte teoretice adânci și cum să aplici Kubernetes la nivel de principii și modele.
A doua dorință mercantilă - vizitați și puneți stele, pentru că ne hrănim cu ele. Dacă nu ne dați stele, nu vom avea ce mânca. Este ca mana într-un joc video. Facem ceva, facem, ne străduim, cineva spune că sunt biciclete groaznice, altcineva că totul este greșit, iar noi continuăm și acționăm absolut corect. Vedem o problemă, o rezolvăm și împărtășim experiența. Așa că puneți-ne o stea, nu pierdeți nimic, dar noi câștigăm, pentru că ne hrănim cu ele.
A treia dorință, importantă și deja nu mercantilă - nu mai credeți în basme. Sunteți profesioniști. DevOps este o profesie foarte serioasă și responsabilă. Nu mai jucați pe locul de muncă. Lăsați-vă să realizați acest lucru. Imaginați-vă că mergeți la spital, iar acolo doctorul experimentează asupra voastră. Înțeleg că asta poate ofensa pe cineva, dar, cel mai probabil, nu se referă la voi, ci la altcineva. Spuneți și altora să înceteze. Acest lucru strică într-adevăr viața tuturor - mulți încep să se raporteze la operare, la administratori și la DevOps-uri ca la tipii care au stricat iar ceva. Acest „stricat” se întâmplă cel mai adesea pentru că am început să ne jucăm, în loc să privim cu mintea rece ce se întâmplă aici și acolo.
Aceasta nu înseamnă că nu trebuie să experimentăm. Trebuie să experimentăm, noi așa facem. Dacă suntem sinceri, uneori ne jucăm și noi — este, desigur, foarte rău, dar nimic uman nu ne este străin. Hai să declarăm anul 2019 anul experimentelor serioase și bine gândite, nu jocuri pe prod. Probabil că așa ar fi.
— Vă mulțumesc mult!
Dmitri: Îți mulțumesc, Vitalie, pentru timp și pentru interviu. Dragi cititori, vă mulțumim foarte mult, dacă ați ajuns până la acest moment. Sper că v-am adus măcar câteva gânduri.
În interviu, Dmitry a atins subiectul werf. Acesta este acum un cuțit elvețian universal, care rezolvă aproape toate problemele. Dar nu a fost întotdeauna așa. la festival Dmitry Stolyarov va vorbi despre acest instrument în detaliu. În prezentarea vor fi discutate toate: problemele și nuanțele ascunse ale Kubernetes, opțiuni de soluționare a acestor dificultăți și implementarea actuală a werf în detalii. Alăturați-vă pe 27 și 28 mai, vom crea instrumente ideale.
Sursa: habr.com
