ProHoster > Blogs > Administrācija > Kubernetes pārņems pasauli. Kad un kā?

Kubernetes pārņems pasauli. Kad un kā?

Gaidot DevOpsConf Vitālijs Habarovs intervēts Dmitrijs Stoļarovs (distol), uzņēmuma Flant tehniskais direktors un lÄ«dzdibinātājs. Vitālijs jautāja Dmitrijam par to, ko Flants dara, par Kubernetes, ekosistēmu attÄ«stÄ«bu, atbalstu. Pārrunājām, kāpēc Kubernetes ir vajadzÄ«gas un vai vispār vajag. Un arÄ« par mikropakalpojumiem, Amazon AWS, ā€œMan paveiksiesā€ pieeju DevOps, paÅ”a Kubernetes nākotni, kāpēc, kad un kā tas pārņems pasauli, DevOps izredzes un tam, kam inženieriem bÅ«tu jāsagatavojas gaiŔā un tuvākā nākotne ar vienkārÅ”oÅ”anu un neironu tÄ«kliem.

Oriģinālā intervija klausieties kā aplāde DevOps Deflop - krievu valodas aplāde par DevOps, un zemāk ir teksta versija.

Kubernetes pārņems pasauli. Kad un kā?

Å eit un zemāk viņŔ uzdod jautājumus Vitālijs Habarovs inženieris no Express42.

Par "Flantu"

- Sveiks, Dima. Jūs esat tehniskais direktors"Plakans" un arī tās dibinātājs. Pastāstiet, lūdzu, ar ko uzņēmums nodarbojas un ar ko jūs tajā nodarbojaties?

Kubernetes pārņems pasauli. Kad un kā?Dmitrijs: No malas Ŕķiet, ka mēs esam tie puiÅ”i, kas iet apkārt, instalējot Kubernetes visiem un kaut ko ar to dara. Bet tā nav taisnÄ«ba. Sākām kā uzņēmums, kas nodarbojas ar Linux, taču ļoti ilgu laiku mÅ«su pamatdarbÄ«ba ir bijusi ražoÅ”anas un lielas slodzes pabeigtu projektu apkalpoÅ”ana. Parasti mēs bÅ«vējam visu infrastruktÅ«ru no nulles un pēc tam atbildam par to ilgu, ilgu laiku. Tāpēc galvenais darbs, ko ā€œFlantā€ dara, par ko saņem naudu, ir uzņemties atbildÄ«bu un realizēt gatavu ražoÅ”anu.




Es kā uzņēmuma tehniskais direktors un viens no dibinātājiem visu dienu un nakti cenÅ”os izdomāt, kā palielināt produkcijas pieejamÄ«bu, vienkārÅ”ot tās darbÄ«bu, atvieglot administratoru, bet izstrādātāju ā€“ patÄ«kamāku. .

Par Kubernetes

ā€” Pēdējā laikā esmu redzējis daudz ziņojumu no Flantas un raksti par Kubernetes. Kā tu pie tā nonāci?

Dmitrijs: Es jau esmu par to runājis daudzas reizes, bet es nemaz neiebilstu to atkārtot. Es domāju, ka ir pareizi atkārtot Å”o tēmu, jo pastāv neskaidrÄ«bas starp cēloni un sekām.

Mums tieŔām bija vajadzÄ«gs rÄ«ks. Saskārāmies ar daudzām problēmām, cÄ«nÄ«jāmies, pārvarējām tās ar dažādiem kruÄ·iem un jutām vajadzÄ«bu pēc instrumenta. Mēs izgājām cauri daudzām dažādām iespējām, uzbÅ«vējām savus velosipēdus un guvām pieredzi. Pamazām nonācām lÄ«dz punktam, ka sākām lietot Docker gandrÄ«z tiklÄ«dz tas parādÄ«jās ā€“ ap 2013. gadu. Tās parādÄ«Å”anās brÄ«dÄ« mums jau bija liela pieredze ar konteineriem, mēs jau bijām uzrakstÄ«juÅ”i ā€œDockerā€ analogu - dažus mÅ«su paÅ”u kruÄ·us Python valodā. LÄ«dz ar Docker parādÄ«Å”anos kļuva iespējams izmest kruÄ·us un izmantot uzticamu un sabiedrÄ«bas atbalstÄ«tu risinājumu.

Ar Kubernetes stāsts ir lÄ«dzÄ«gs. Kad tas sāka uzņemt apgriezienus - mums Ŕī ir versija 1.2 - mums jau bija daudz kruÄ·u gan Shell, gan Chef, ko mēs kaut kā mēģinājām orÄ·estrēt ar Docker. Nopietni skatÄ«jāmies uz Rancher un dažādiem citiem risinājumiem, bet tad parādÄ«jās Kubernetes, kurā viss tiek Ä«stenots tieÅ”i tā, kā mēs to bÅ«tu darÄ«juÅ”i vai pat labāk. Nav par ko sÅ«dzēties.

Jā, te ir kaut kāda nepilnÄ«ba, tur ir kaut kāda nepilnÄ«ba - tur ir daudz nepilnÄ«bu, un 1.2 vispār ir briesmÄ«gi, bet... Kubernetes ir kā ēka, kas tiek bÅ«vēta - tu paskaties projektu un saproti. ka bÅ«s forÅ”i. Ja ēkai tagad ir pamati un divi stāvi, tad saproti, ka labāk vēl neievākties, bet ar programmatÅ«ru tādu problēmu nav - to jau var izmantot.

Mums nebija ne brÄ«di, kad mēs domājām par Kubernetes izmantoÅ”anu vai nē. Mēs to gaidÄ«jām ilgi pirms tā parādÄ«Å”anās un mēģinājām paÅ”i radÄ«t analogus.

Par Kubernetes

ā€” Vai esat tieÅ”i iesaistÄ«ts paÅ”as Kubernetes attÄ«stÄ«bā?

Dmitrijs: Viduvēji. Mēs drÄ«zāk piedalāmies ekosistēmas attÄ«stÄ«bā. Mēs nosÅ«tām noteiktu skaitu vilkÅ”anas pieprasÄ«jumu: Prometheus, dažādiem operatoriem, Helm - ekosistēmai. Diemžēl es nevaru izsekot visam, ko darām, un es varētu kļūdÄ«ties, taču nav neviena pūļa no mums lÄ«dz kodolam.

ā€” Tajā paŔā laikā jÅ«s izstrādājat daudzus savus rÄ«kus ap Kubernetes?

Dmitrijs: Stratēģija ir Ŕāda: mēs ejam un piesaistām pieprasÄ«jumus visam, kas jau pastāv. Ja pievilkÅ”anas pieprasÄ«jumi tur netiek pieņemti, mēs vienkārÅ”i paÅ”i tos sadalām un dzÄ«vojam, lÄ«dz tie tiek pieņemti ar mÅ«su bÅ«vēm. Pēc tam, kad tas sasniedz augÅ”teci, mēs atgriežamies pie augÅ”teces versijas.

Piemēram, mums ir Prometheus operators, ar kuru mēs, iespējams, jau 5 reizes pārslēdzāmies uz priekÅ”u un atpakaļ uz mÅ«su montāžas augÅ”pusi. Mums ir vajadzÄ«ga kāda veida funkcija, mēs nosÅ«tÄ«jām izvilkÅ”anas pieprasÄ«jumu, mums tas ir jāizlaiž rÄ«t, taču mēs nevēlamies gaidÄ«t, kad tā tiks izlaista augÅ”pus straumes. AttiecÄ«gi mēs montējam paÅ”i, izplatām mÅ«su komplektu ar mÅ«su funkciju, kas mums kaut kādu iemeslu dēļ ir nepiecieÅ”ama, visiem mÅ«su klasteriem. Tad, piemēram, viņi to nodod mums augÅ”tecē ar vārdiem: ā€œPuiÅ”i, darÄ«sim to vispārÄ«gākā gadÄ«jumā,ā€ mēs vai kāds cits to pabeidzam, un laika gaitā tas atkal saplÅ«st.

Mēs cenÅ”amies attÄ«stÄ«t visu, kas pastāv. Daudzi elementi, kas vēl neeksistē, vēl nav izgudroti vai ir izgudroti, bet nav paspējuÅ”i ieviest ā€“ mēs to darām. Un nevis tāpēc, ka mums patÄ«k process vai velosipēdu bÅ«ve kā nozare, bet vienkārÅ”i tāpēc, ka mums ir vajadzÄ«gs Å”is rÄ«ks. Bieži tiek uzdots jautājums, kāpēc mēs darÄ«jām to vai to? Atbilde ir vienkārÅ”a - jā, jo mums bija jāiet tālāk, jāatrisina kāda praktiska problēma, un mēs to atrisinājām ar Å”o tÅ«lu.

CeļŔ vienmēr ir Ŕāds: ļoti rÅ«pÄ«gi meklējam un, ja neatrodam risinājumu, kā no maizes kukuļa uztaisÄ«t trolejbusu, tad taisām paÅ”i savu klaipu un savu trolejbusu.

Flanta instrumenti

ā€” Es zinu, ka Flant tagad ir papildinājumu operatori, čaulas operatori un dapp/werf rÄ«ki. Kā es saprotu, tas ir viens un tas pats instruments dažādās inkarnācijās. Es arÄ« saprotu, ka Flaunt ir daudz vairāk dažādu rÄ«ku. Tā ir patiesÄ«ba?

Dmitrijs: Mums ir daudz vairāk vietnē GitHub. Cik es tagad atceros, mums ir statusa karte - Grafana panelis, ar kuru visi ir saskāruÅ”ies. Tas ir minēts gandrÄ«z katrā otrajā rakstā par Kubernetes monitoringu vietnē Medium. Nav iespējams Ä«si izskaidrot, kas ir statusa karte - tai ir nepiecieÅ”ams atseviŔķs raksts, taču tā ir ļoti noderÄ«ga lieta statusa uzraudzÄ«bai laika gaitā, jo Kubernetes mums bieži ir jāparāda statuss laika gaitā. Mums ir arÄ« LogHouse - Ŕī ir lieta, kas balstÄ«ta uz ClickHouse un melno maÄ£iju baļķu vākÅ”anai Kubernetes.

Daudz komunālo pakalpojumu! Un bÅ«s vēl vairāk, jo Å”ogad iznāks vairāki iekŔējie risinājumi. No ļoti lielajiem, kuru pamatā ir pievienojumprogrammas operators, ir virkne papildinājumu priekÅ” Kubernetes, kā pareizi instalēt sert manager - sertifikātu pārvaldÄ«bas rÄ«ku, kā pareizi instalēt Prometheus ar virkni piederumu - tie ir aptuveni divdesmit dažādi binārie faili, kas eksportē datus un kaut ko savāc, Å”im Prometheus ir visbrÄ«niŔķīgākā grafika un brÄ«dinājumi. Tas viss ir tikai virkne Kubernetes papildinājumu, kas ir instalēti klasterÄ«, un tas kļūst no vienkārÅ”as uz forÅ”u, izsmalcinātu, automātisku, kurā daudzas problēmas jau ir atrisinātas. Jā, mēs darām daudz.

Ekosistēmu attīstība

"Man Ŕķiet, ka tas ir ļoti liels ieguldÄ«jums Ŕī instrumenta un tā lietoÅ”anas metožu attÄ«stÄ«bā." Vai varat aptuveni novērtēt, kurÅ” vēl dotu tādu paÅ”u ieguldÄ«jumu ekosistēmas attÄ«stÄ«bā?

Dmitrijs: Krievijā no uzņēmumiem, kas darbojas mÅ«su tirgÅ«, neviens nav pat tuvu. Protams, tas ir skaļŔ paziņojums, jo ir tādi lieli spēlētāji kā Mail un Yandex - arÄ« viņi kaut ko dara ar Kubernetes, taču pat viņi netuvojas to uzņēmumu ieguldÄ«jumam visā pasaulē, kuri dara daudz vairāk nekā mēs. Ir grÅ«ti salÄ«dzināt Flant, kurā strādā 80 cilvēki, un Red Hat, kurā ir 300 inženieri uz vienu Kubernetes, ja nemaldos. GrÅ«ti salÄ«dzināt. Mums RnD nodaļā ir 6 cilvēki, tostarp es, kas sagriež visus mÅ«su instrumentus. 6 cilvēki pret 300 Red Hat inženieriem ā€” kaut kā grÅ«ti salÄ«dzināt.

- Tomēr, kad pat Å”ie 6 cilvēki var izdarÄ«t kaut ko patieŔām noderÄ«gu un atsveÅ”inoÅ”u, kad viņi saskaras ar praktisku problēmu un dod risinājumu sabiedrÄ«bai - interesants gadÄ«jums. Es saprotu, ka lielajos tehnoloÄ£iju uzņēmumos, kur viņiem ir sava Kubernetes izstrādes un atbalsta komanda, principā var izstrādāt tos paÅ”us rÄ«kus. Tas viņiem ir piemērs tam, ko var attÄ«stÄ«t un dot kopienai, dodot impulsu visai kopienai, kas izmanto Kubernetes.

Dmitrijs: Tā laikam ir integratora iezÄ«me, tā Ä«patnÄ«ba. Mums ir daudz projektu, un mēs redzam daudz dažādu situāciju. Mums galvenais veids, kā radÄ«t pievienoto vērtÄ«bu, ir analizēt Å”os gadÄ«jumus, atrast kopÄ«bu un padarÄ«t tos mums pēc iespējas lētākus. Mēs pie tā aktÄ«vi strādājam. Man ir grÅ«ti runāt par Krieviju un pasauli, taču mums uzņēmumā ir aptuveni 40 DevOps inženieri, kuri strādā pie Kubernetes. Es domāju, ka Krievijā nav daudz uzņēmumu ar salÄ«dzināmu speciālistu skaitu, kas saprot Kubernetes, ja vispār ir.

Es saprotu visu par amata nosaukumu DevOps inženieris, visi visu saprot un ir pieraduÅ”i saukt DevOps inženierus par DevOps inženieriem, mēs to neapspriedÄ«sim. Visi Å”ie 40 apbrÄ«nojamie DevOps inženieri katru dienu saskaras un risina problēmas, mēs tikai analizējam Å”o pieredzi un cenÅ”amies vispārināt. Mēs saprotam, ja tas paliks mÅ«sos, tad pēc gada vai diviem instruments bÅ«s bezjēdzÄ«gs, jo kaut kur sabiedrÄ«bā parādÄ«sies gatavs Tula. Nav jēgas uzkrāt Å”o pieredzi iekŔēji - tā vienkārÅ”i iztukÅ”o enerÄ£iju un laiku uz dev/null. Un mums par to nemaz nav žēl. Mēs visu publicējam ar lielu prieku un saprotam, ka tas ir jāpublicē, jāattÄ«sta, jāpopularizē, jāpopularizē, lai cilvēki izmanto un pievieno savu pieredzi - tad viss aug un dzÄ«vo. Tad pēc diviem gadiem instruments miskastē nenonāk. Nav žēl turpināt liet spēkus, jo ir skaidrs, ka kāds izmanto jÅ«su rÄ«ku, un pēc diviem gadiem visi to izmanto.

Tā ir daļa no mÅ«su lielās stratēģijas ar dapp/werf. Es neatceros, kad sākām to gatavot, Ŕķiet, pirms 3 gadiem. Sākotnēji tas parasti bija uz čaumalas. Tas bija lielisks koncepcijas pierādÄ«jums, mēs atrisinājām dažas no mÅ«su Ä«paÅ”ajām problēmām - tas strādāja! Bet ir problēmas ar čaulu, to tālāk paplaÅ”ināt nav iespējams, programmÄ“Å”ana uz čaula ir cits uzdevums. Mums bija ieradums rakstÄ«t rubÄ«nā, attiecÄ«gi, mēs kaut ko pārtaisÄ«jām RubÄ«nā, attÄ«stÄ«jām, attÄ«stÄ«jām, attÄ«stÄ«jām un saskārāmies ar to, ka kopiena, pÅ«lis, kas nesaka ā€œmēs to gribam vai negribam, ā€ pagriež degunu Rubijam, cik tas ir smieklÄ«gi? Mēs sapratām, ka mums ir jāieraksta visas Ŕīs lietas Go, lai izpildÄ«tu pirmo kontrolsaraksta punktu: DevOps rÄ«kam ir jābÅ«t statiskam bināram. BÅ«t Go vai nē, tas nav tik svarÄ«gi, taču labāk ir statisks binārs, kas rakstÄ«ts Go.

Mēs iztērējām savu enerÄ£iju, pārrakstÄ«jām dapp programmā Go un nosaucām to par werf. Dapp vairs netiek atbalstÄ«ts, nav izstrādāts, darbojas kādā jaunākajā versijā, taču ir absolÅ«ts jaunināŔanas ceļŔ uz augÅ”u, un jÅ«s varat tam sekot.

Kāpēc dapp tika izveidots?

ā€” Vai varat Ä«si pastāstÄ«t, kāpēc dapp tika izveidots, kādas problēmas tas risina?

Dmitrijs: Pirmais iemesls ir montāžā. Sākotnēji mums bija nopietnas problēmas ar bÅ«vniecÄ«bu, kad Docker nebija daudzpakāpju iespēju, tāpēc mēs paÅ”i izveidojām daudzpakāpju. Tad mums bija vēl vairākas problēmas ar attēla tÄ«rÄ«Å”anu. Ikviens, kurÅ” nodarbojas ar CI/CD, agri vai vēlu saskaras ar problēmu, ka ir čupiņa savākto attēlu, vajag kaut kā iztÄ«rÄ«t nevajadzÄ«go un atstāt vajadzÄ«go.

Otrs iemesls ir izvietoÅ”ana. Jā, Helm ir, bet tas atrisina tikai dažas problēmas. SmieklÄ«gi, ka ir rakstÄ«ts, ka ā€œHelms ir Kubernetes pakotņu pārvaldnieksā€. TieÅ”i to, kas "the". Ir arÄ« vārdi ā€œPakeÅ”u pārvaldnieksā€ ā€” ko parasti sagaida no pakotņu pārvaldnieka? Mēs sakām: "Pakotņu pārvaldnieks - instalējiet pakotni!" un mēs sagaidām, ka viņŔ mums pateiks: "Paka ir piegādāta."

Interesanti, ka mēs sakām: "StÅ«re, instalējiet pakotni", un, kad viņŔ atbild, ka instalējis, izrādās, ka viņŔ tikko sācis instalÄ“Å”anu - viņŔ norādÄ«ja Kubernetes: "Palaidiet Å”o lietu!" Un vai tā sākās vai nē. , neatkarÄ«gi no tā, vai tas darbojas vai nē, Helm Å”o problēmu neatrisina vispār.

Izrādās, ka Helm ir tikai teksta priekÅ”apstrādātājs, kas ielādē datus Kubernetes.

Bet kā daļa no jebkuras izvietoÅ”anas mēs vēlamies uzzināt, vai lietojumprogramma ir izlaista ražoÅ”anai vai nē? IzvērÅ”ana uz prod nozÄ«mē, ka lietojumprogramma ir pārvietota uz turieni, jaunā versija ir izvietota un vismaz tā tur neavārē un reaģē pareizi. Helm Å”o problēmu nekādā veidā neatrisina. Lai to atrisinātu, jums ir jāpieliek lielas pÅ«les, jo jums ir jādod Kubernetes komanda izrullēt un pārraudzÄ«t, kas tur notiek - vai tas ir izvietots vai izskrējis. Ir arÄ« daudz uzdevumu, kas saistÄ«ti ar izvietoÅ”anu, tÄ«rÄ«Å”anu un montāžu.

Plāni

Å ogad sāksim vietējo attÄ«stÄ«bu. Mēs vēlamies sasniegt to, kas iepriekÅ” bija Vagrant ā€” mēs ierakstÄ«jām ā€œvagrant upā€ un izvietojām virtuālās maŔīnas. Mēs vēlamies nokļūt lÄ«dz vietai, kur Git ir projekts, mēs tur ierakstām ā€œwerf upā€, un tas parāda Ŕī projekta vietējo kopiju, kas ir izvietota vietējā mini-kubā un ir pievienoti visi izstrādei ērtie direktoriji. . AtkarÄ«bā no izstrādes valodas tas tiek darÄ«ts atŔķirÄ«gi, bet tomēr, lai lokālo izstrādi varētu ērti veikt zem uzstādÄ«tajiem failiem.

Nākamais solis mums ir ieguldÄ«t izstrādātāju ērtÄ«bās. Lai ātri izvietotu projektu lokāli, izmantojot vienu rÄ«ku, izstrādājiet to, ievietojiet to Git, un atkarÄ«bā no konveijera tas tiks izlaists stadijā vai testiem, un pēc tam izmantojiet to paÅ”u rÄ«ku, lai pārietu uz ražoÅ”anu. Å Ä« vienotÄ«ba, apvienoÅ”anās, infrastruktÅ«ras reproducējamÄ«ba no vietējās vides lÄ«dz tirdzniecÄ«bai mums ir ļoti svarÄ«gs punkts. Bet tas vēl nav werf - mēs tikai plānojam to darÄ«t.

Bet ceļŔ uz dapp/werf vienmēr ir bijis tāds pats kā ar Kubernetes sākumā. Mēs saskārāmies ar problēmām, atrisinājām tās, izmantojot risinājumus ā€” mēs izdomājām sev dažus risinājumus uz čaumalas, jebko. Tad viņi mēģināja kaut kā iztaisnot Å”os risinājumus, vispārināt un konsolidēt tos bināros failos Å”ajā gadÄ«jumā, ko mēs vienkārÅ”i kopÄ«gojam.

Ir arī cits veids, kā aplūkot visu Ŕo stāstu, izmantojot analoģijas.

Kubernetes ir automaŔīnas rāmis ar dzinēju. Nav durvju, stikla, radio, Ziemassvētku eglÄ«tes - vispār nekā. Tikai rāmis un dzinējs. Un tur ir Helma - tā ir stÅ«re. ForÅ”i - ir stÅ«re, bet jums ir nepiecieÅ”ama arÄ« stÅ«res tapa, stÅ«res statnis, pārnesumkārba un riteņi, un jÅ«s nevarat iztikt bez tiem.

werf gadÄ«jumā Ŕī ir vēl viena Kubernetes sastāvdaļa. Tikai tagad werf alfa versijā, piemēram, Helm ir kompilēts iekÅ” werf, jo mums paÅ”iem ir apnicis to darÄ«t. Ir daudz iemeslu, kāpēc to darÄ«t, es jums pastāstÄ«Å”u sÄ«kāk par to, kāpēc mēs apkopojām visu stÅ«ri kopā ar stÅ«ri werf iekÅ”pusē ziņojumā RIT++.

Tagad werf ir integrētāks komponents. Mēs iegÅ«stam gatavu stÅ«ri, stÅ«res tapu - es ne pārāk labi pārzinu automaŔīnas, taču tas ir liels bloks, kas jau atrisina diezgan plaÅ”u problēmu loku. Mums paÅ”iem nav jāiet cauri katalogam, jāizvēlas viena detaļa citai, jādomā, kā tās saskrÅ«vēt. Mēs iegÅ«stam gatavu kombainu, kas vienlaikus atrisina lielu skaitu problēmu. Bet iekÅ”pusē tas ir veidots no tiem paÅ”iem atvērtā pirmkoda komponentiem, tā joprojām izmanto Docker montāžai, Helm dažām funkcijām, un ir vairākas citas bibliotēkas. Å is ir integrēts rÄ«ks, lai ātri un ērti izņemtu vēsu CI/CD no kastes.

Vai Kubernetes ir grūti uzturēt?

ā€” JÅ«s runājat par pieredzi, ka sākāt lietot Kubernetes, tas jums ir rāmis, dzinējs, un uz tā var piekārt daudz dažādu lietu: virsbÅ«vi, stÅ«ri, pieskrÅ«vēt pedāļus, sēdekļus. Rodas jautājums ā€“ cik grÅ«ts jums ir Kubernetes atbalsts? Jums ir liela pieredze, cik daudz laika un resursu tērējat Kubernetes atbalstam atrauti no visa pārējā?

Dmitrijs: Šis ir ļoti grūts jautājums un, lai atbildētu, mums ir jāsaprot, kas ir atbalsts un ko mēs vēlamies no Kubernetes. Varbūt vari atklāt?

ā€” Cik zinu un redzu, tagad daudzas komandas vēlas izmēģināt Kubernetes. Ikviens pieķērās pie tā, noliek uz ceļiem. Man ir sajÅ«ta, ka cilvēki ne vienmēr saprot Ŕīs sistēmas sarežģītÄ«bu.

Dmitrijs: Tas ir tā.

ā€” Cik grÅ«ti ir paņemt un uzstādÄ«t Kubernetes no nulles, lai tā bÅ«tu gatava ražoÅ”anai?

Dmitrijs: Cik grÅ«ti, jÅ«suprāt, ir pārstādÄ«t sirdi? Es saprotu, ka tas ir kompromitējoÅ”s jautājums. Izmantot skalpeli un nekļūdÄ«ties nav nemaz tik grÅ«ti. Ja viņi pasaka, kur griezt un kur Ŕūt, tad pati procedÅ«ra nav sarežģīta. GrÅ«ti ik pa laikam garantēt, ka viss izdosies.

Kubernetes instalÄ“Å”ana un iedarbināŔana ir vienkārÅ”a: cāli! ā€” uzstādÄ«ts, ir daudz instalÄ“Å”anas metožu. Bet kas notiek, kad rodas problēmas?

Vienmēr rodas jautājumi ā€“ ko mēs vēl neesam ņēmuÅ”i vērā? Ko mēs vēl neesam izdarÄ«juÅ”i? Kuri Linux kodola parametri tika norādÄ«ti nepareizi? Kungs, vai mēs viņus vispār pieminējām?! Kurus Kubernetes komponentus esam piegādājuÅ”i un kurus nē? Rodas tÅ«kstoÅ”iem jautājumu, un, lai uz tiem atbildētu, Å”ajā nozarē jāpavada 15-20 gadi.

Man ir nesens piemērs par Å”o tēmu, kas var atklāt problēmas ā€œVai Kubernetes ir grÅ«ti uzturēt?ā€ nozÄ«mi? Pirms kāda laika nopietni apsvērām, vai nevajadzētu mēģināt ieviest Cilium kā tÄ«klu Kubernetes.

Ä»aujiet man paskaidrot, kas ir Cilium. Kubernetes ir daudz dažādu tÄ«klu apakÅ”sistēmas implementāciju, un viena no tām ir ļoti forÅ”a - Cilium. Kāda ir tā nozÄ«me? Kodolā pirms kāda laika radās iespēja uzrakstÄ«t āķus kodolam, kas tādā vai citādā veidā iebrÅ«k tÄ«kla apakÅ”sistēmā un dažādās citās apakÅ”sistēmās un ļauj apiet lielus kodola gabalus.

Linux kodolam vēsturiski ir ip marÅ”ruts, pārfiltrs, tilti un daudz dažādu vecu komponentu, kas ir 15, 20, 30 gadus veci. Kopumā viņi strādā, viss ir lieliski, bet tagad viņi ir sakrāvuÅ”i konteinerus, un izskatās, ka tornis no 15 Ä·ieÄ£eļiem viens otram virsÅ«, un tu stāvi uz tā uz vienas kājas - dÄ«vaina sajÅ«ta. Å Ä« sistēma vēsturiski ir izveidojusies ar daudzām niansēm, piemēram, aklās zarnas Ä·ermenÄ«. Dažās situācijās, piemēram, ir darbÄ«bas problēmas.

Ir brÄ«niŔķīgs BPF un iespēja rakstÄ«t āķus kodolam - puiÅ”i rakstÄ«ja paÅ”i savus āķus kodolam. Pakete nonāk Linux kodolā, viņi to izņem tieÅ”i pie ievades, paÅ”i apstrādā kā nākas bez tiltiem, bez TCP, bez IP steka - Ä«si sakot, apejot visu, kas rakstÄ«ts Linux kodolā, un pēc tam nospļauties. to ārā konteinerā.

Kas notika? Ä»oti forÅ”s sniegums, forÅ”as funkcijas - vienkārÅ”i forÅ”i! Bet mēs paskatāmies uz Å”o un redzam, ka katrā maŔīnā ir programma, kas savienojas ar Kubernetes API un, pamatojoties uz datiem, ko tā saņem no Ŕīs API, Ä£enerē C kodu un kompilē bināros failus, kurus tas ielādē kodolā, lai Å”ie āķi darbotos. kodola telpā.

Kas notiek, ja kaut kas noiet greizi? Mēs nezinām. Lai to saprastu, jums ir jāizlasa viss kods, jāsaprot visa loÄ£ika, un tas ir pārsteidzoÅ”i, cik tas ir grÅ«ti. Bet, no otras puses, ir Å”ie tilti, tÄ«kla filtri, ip marÅ”ruts ā€” es neesmu lasÄ«jis to avota kodu, un nav arÄ« tie 40 inženieri, kas strādā mÅ«su uzņēmumā. VarbÅ«t tikai daži saprot dažas daļas.

Un kāda starpÄ«ba? Izrādās, ka ir ip rout, Linux kodols, un ir jauns rÄ«ks - kāda starpÄ«ba, mēs nesaprotam ne vienu, ne otru. Bet mēs baidāmies izmantot kaut ko jaunu ā€“ kāpēc? Jo, ja instruments ir 30 gadus vecs, tad 30 gadu laikā visas kļūdas ir atrastas, visas kļūdas ir uzkāptas un par visu nav jāzina - tas darbojas kā melnā kaste un darbojas vienmēr. Visi zina, kuru diagnostikas skrÅ«vgriezi kurā vietā iebāzt, kuru tcpdump kurā brÄ«dÄ« palaist. Ikviens labi zina diagnostikas utilÄ«tas un saprot, kā Ŕī komponentu kopa darbojas Linux kodolā ā€“ nevis kā tā darbojas, bet gan kā to izmantot.

Un satriecoÅ”i forÅ”ajam Ciliumam nav 30 gadu, tas vēl nav novecojis. Kubernetes ir tāda pati problēma, kopējiet. Ka Cilium ir uzstādÄ«ts perfekti, ka Kubernetes ir uzstādÄ«ts ideāli, bet, kad ražoÅ”anā kaut kas noiet greizi, vai kritiskā situācijā ātri spējat saprast, kas nogāja greizi?

Kad mēs sakām, vai ir grÅ«ti uzturēt Kubernetes - nē, tas ir ļoti viegli, un jā, tas ir neticami grÅ«ti. Kubernetes lieliski darbojas atseviŔķi, bet ar miljardu niansēm.

Par pieeju ā€œMan paveiksiesā€.

ā€” Vai ir uzņēmumi, kur Ŕīs nianses ir gandrÄ«z garantētas? Pieņemsim, ka Yandex pēkŔņi nodod visus pakalpojumus Kubernetes, tur bÅ«s milzÄ«ga slodze.

Dmitrijs: Nē, Ŕī nav saruna par slodzi, bet par visvienkārŔākajām lietām. Piemēram, mums ir Kubernetes, mēs tur izvietojām lietojumprogrammu. Kā jÅ«s zināt, ka tas darbojas? VienkārÅ”i nav gatavu rÄ«ku, lai saprastu, ka lietojumprogramma nedarbojas. Nav gatavas sistēmas, kas sÅ«ta brÄ«dinājumus; jums ir jākonfigurē Å”ie brÄ«dinājumi un katrs grafiks. Un mēs atjauninām Kubernetes.

Man ir Ubuntu 16.04. Var teikt, ka Ŕī ir veca versija, bet mēs joprojām to izmantojam, jo ā€‹ā€‹tā ir LTS. Ir systemd, kura nianse ir tāda, ka neattÄ«ra C grupas. Kubernetes palaiž aplikumus, izveido C grupas, pēc tam izdzÄ“Å” aplikumus, un kaut kā izrādās - es neatceros detaļas, atvainojiet -, ka sistēmas Ŕķēles paliek. Tas noved pie tā, ka laika gaitā jebkura automaŔīna sāk stipri palēnināties. Tas pat nav jautājums par augstu slodzi. Ja tiek palaisti pastāvÄ«gi podi, piemēram, ja ir Cron Job, kas pastāvÄ«gi Ä£enerē podi, tad maŔīna ar Ubuntu 16.04 sāks palēnināties pēc nedēļas. PastāvÄ«gi bÅ«s augsta vidējā slodze sakarā ar to, ka ir izveidots daudz C-grupu. Å Ä« ir problēma, ar kuru saskarsies ikviens, kurÅ” vienkārÅ”i instalē Ubuntu 16 un Kubernetes.

Pieņemsim, ka viņŔ kaut kā atjaunina systemd vai kaut ko citu, bet Linux kodolā lÄ«dz pat 4.16 tas ir vēl jocÄ«gāk - dzÄ“Å”ot C grupas, tās noplÅ«st kodolā un faktiski netiek izdzēstas. Tāpēc pēc mēneÅ”a darba pie Ŕīs maŔīnas pavardu atmiņas statistiku skatÄ«ties nebÅ«s iespējams. Izņemam failu, rullējam programmā, un viens fails rullē 15 sekundes, jo kodols ļoti ilgi saskaita sevÄ« miljonu C-grupas, kuras it kā ir izdzēstas, bet nē - tās noplÅ«st .

Å ur tur vēl ir daudz tādu sÄ«kumu. Tā nav problēma, ar ko milzu uzņēmumi dažkārt var saskarties ļoti lielas slodzes apstākļos ā€“ nē, tas ir ikdienas lietu jautājums. Cilvēki var tā dzÄ«vot mēneÅ”iem ilgi ā€“ uzinstalēja Kubernetes, izvietoja aplikāciju ā€“ Ŕķiet, ka strādā. Daudziem cilvēkiem tas ir normāli. Viņi pat nezinās, ka Ŕī lietojumprogramma kāda iemesla dēļ avarēs, viņi nesaņems brÄ«dinājumu, taču viņiem tā ir norma. IepriekÅ” dzÄ«vojām uz virtuālajām maŔīnām bez uzraudzÄ«bas, tagad esam pārgājuÅ”i uz Kubernetes, arÄ« bez monitoringa - kāda starpÄ«ba?

Jautājums ir tāds, ka, ejot pa ledu, mēs nekad nezinām tā biezumu, ja vien to iepriekÅ” neizmērām. Daudzi cilvēki staigā un neuztraucas, jo viņi jau ir staigājuÅ”i.

Manā skatÄ«jumā jebkuras sistēmas darbÄ«bas nianse un sarežģītÄ«ba ir nodroÅ”ināt, lai ledus biezums bÅ«tu tieÅ”i pietiekams, lai atrisinātu mÅ«su problēmas. Tas ir tas, par ko mēs runājam.

Man Ŕķiet, ka IT jomā ir pārāk daudz pieeju ā€œman paveiksiesā€. Daudzi cilvēki instalē programmatÅ«ru un izmanto programmatÅ«ras bibliotēkas, cerot, ka viņiem veiksies. Kopumā daudziem ir paveicies. Iespējams, tāpēc tas darbojas.

ā€” Pēc mana pesimistiskā vērtējuma izskatās Ŕādi: kad riski ir lieli un aplikācijai ir jādarbojas, tad nepiecieÅ”ams atbalsts no Flaunt, varbÅ«t no Red Hat, vai arÄ« vajag savu iekŔējo, tieÅ”i Kubernetes veltÄ«tu komandu, kas ir gatava. lai to novilktu.

Dmitrijs: Objektīvi, tas tā ir. Patstāvīga iesaistīŔanās Kubernetes stāstā nelielai komandai ir saistīta ar vairākiem riskiem.

Vai mums vajag konteinerus?

ā€” Vai varat pastāstÄ«t, cik plaÅ”i Kubernetes ir izplatÄ«tas Krievijā?

Dmitrijs: Man nav Å”o datu, un es neesmu pārliecināts, ka kādam citam tie ir. Mēs sakām: ā€œKubernetes, Kubernetesā€, bet ir arÄ« cits veids, kā aplÅ«kot Å”o jautājumu. Es arÄ« nezinu, cik plaÅ”i ir konteineri, bet es zinu skaitli no ziņojumiem internetā, ka 70% konteineru ir orÄ·estrējis Kubernetes. Tas bija uzticams avots diezgan lielai izlasei visā pasaulē.

Tad vēl jautājums - vai mums vajag konteinerus? Mana personīgā sajūta un uzņēmuma Flant kopējā nostāja ir tāda, ka Kubernetes ir de facto standarts.

Nebūs nekas cits kā Kubernetes.

InfrastruktÅ«ras pārvaldÄ«bas jomā tas ir absolÅ«ts pārmaiņas. VienkārÅ”i absolÅ«ts ā€” tas ir, vairs nav Ansible, Chef, virtuālās maŔīnas, Terraform. Es nerunāju par vecajām kolhozu metodēm. Kubernetes ir absolÅ«ts mainÄ«tājs, un tagad tas bÅ«s tikai Ŕādi.

Skaidrs, ka kādam ir vajadzÄ«gi pāris gadi, bet citam pāris gadu desmiti, lai to saprastu. Es neÅ”aubos, ka nebÅ«s nekas cits kā Kubernetes un Å”is jaunais izskats: mēs vairs nebojājam operētājsistēmu, bet izmantojam infrastruktÅ«ra kā kods, tikai ne ar kodu, bet ar yml - deklaratÄ«vi aprakstÄ«ta infrastruktÅ«ra. Man ir sajÅ«ta, ka tā bÅ«s vienmēr.

ā€” Tas ir, tie uzņēmumi, kas vēl nav pārgājuÅ”i uz Kubernetes, noteikti pāries uz to vai paliks aizmirstÄ«bā. Es tevi pareizi sapratu?

Dmitrijs: Tas arÄ« nav pilnÄ«gi taisnÄ«ba. Piemēram, ja mums ir uzdevums palaist DNS serveri, tad to var palaist uz FreeBSD 4.10 un tas var darboties nevainojami 20 gadus. VienkārÅ”i strādājiet un viss. VarbÅ«t pēc 20 gadiem kaut kas vienreiz bÅ«s jāatjaunina. Ja mēs runājam par programmatÅ«ru tādā formātā, kādu mēs palaidām, un tā faktiski darbojas daudzus gadus bez jebkādiem atjauninājumiem, bez izmaiņām, tad, protams, Kubernetes nebÅ«s. ViņŔ tur nav vajadzÄ«gs.

Viss, kas saistÄ«ts ar CI/CD ā€“ visur, kur nepiecieÅ”ama nepārtraukta piegāde, kur jāatjaunina versijas, jāveic aktÄ«vas izmaiņas, visur, kur jāveido kļūdu tolerance ā€“ tikai Kubernetes.

Par mikropakalpojumiem

ā€“ Å eit man ir neliela disonanse. Lai strādātu ar Kubernetes, jums ir nepiecieÅ”ams ārējs vai iekŔējs atbalsts - tas ir pirmais punkts. Otrkārt, kad mēs tikai sākam attÄ«stÄ«bu, mēs esam mazs startup, mums vēl nekā nav, attÄ«stÄ«ba Kubernetes vai mikropakalpojumu arhitektÅ«rai kopumā var bÅ«t sarežģīta un ne vienmēr ekonomiski pamatota. Mani interesē tavs viedoklis - vai iesācējiem ir nekavējoties jāsāk rakstÄ«t Kubernetes no nulles, vai tomēr var uzrakstÄ«t monolÄ«tu un tikai tad nākt uz Kubernetes?

Dmitrijs: ForÅ”s jautājums. Es runāju par mikropakalpojumiem "Mikropakalpojumi: izmēram ir nozÄ«me." Daudzas reizes esmu sastapies ar cilvēkiem, kuri mēģina ar mikroskopu iesist naglas. Pati pieeja ir pareiza; mēs paÅ”i veidojam savu iekŔējo programmatÅ«ru Ŕādā veidā. Bet, kad jÅ«s to darāt, jums ir skaidri jāsaprot, ko jÅ«s darāt. Vārds, ko es visvairāk ienÄ«stu attiecÄ«bā uz mikropakalpojumiem, ir ā€œmikroā€. Vēsturiski Å”is vārds ir radies tur, un nez kāpēc cilvēki domā, ka mikro ir ļoti mazs, mazāks par milimetru, piemēram, mikrometrs. Tas ir nepareizi.

Piemēram, ir monolÄ«ts, kuru raksta 300 cilvēki, un visi, kas piedalÄ«jās izstrādē, saprot, ka tur ir problēmas, un tas ir jāsadala mikrogabalos - apmēram 10 gabali, no kuriem katru raksta 30 cilvēki. minimālajā versijā. Tas ir svarÄ«gi, nepiecieÅ”ams un forÅ”i. Bet, kad pie mums ierodas startup, kur 3 ļoti forÅ”i un talantÄ«gi puiÅ”i uz ceļiem uzrakstÄ«ja 60 mikropakalpojumus, katru reizi, kad meklēju Corvalol.

Man Ŕķiet, ka par to jau ir runāts tÅ«kstoÅ”iem reižu - mēs dabÅ«jām izdalÄ«tu monolÄ«tu tādā vai citādā veidā. Tas nav ekonomiski pamatoti, tas ir ļoti grÅ«ti kopumā visā. Es tikko esmu to redzējis tik daudz reižu, ka tas man patieŔām sāp, tāpēc es turpinu par to runāt.

Uz sākotnējo jautājumu ir konflikts starp to, ka, no vienas puses, Kubernetes ir baisi lietot, jo nav skaidrs, kas tur var saplÄ«st vai nedarboties, no otras puses, ir skaidrs, ka tur viss iet un nekas cits kā Kubernetes nepastāvēs . Atbilde - nosveriet saņemtā ieguvuma apjomu, uzdevumu apjomu, ko varat atrisināt. Tas atrodas vienā skalas pusē. No otras puses, pastāv riski, kas saistÄ«ti ar dÄ«kstāvi vai ar reakcijas laika samazināŔanos, pieejamÄ«bas lÄ«meni - ar darbÄ«bas rādÄ«tāju samazināŔanos.

LÅ«k, vai nu mēs pārvietojamies ātri, un Kubernetes ļauj daudzas lietas paveikt daudz ātrāk un labāk, vai arÄ« izmantojam uzticamus, laika pārbaudÄ«tus risinājumus, bet kustamies daudz lēnāk. Tā ir izvēle, kas jāizdara katram uzņēmumam. To var uzskatÄ«t par taku džungļos - pirmo reizi ejot, jÅ«s varat satikt čūsku, tÄ«Ä£eri vai traku āpsi, un, kad esat staigājis 10 reizes, esat izstaigājis taku, aizvācies. zarus un staigāt vieglāk. Katru reizi ceļŔ kļūst platāks. Tad tas ir asfaltēts ceļŔ, vēlāk skaists bulvāris.

Kubernetes nestāv uz vietas. Jautājums vēlreiz: Kubernetes, no vienas puses, ir 4-5 binārie faili, no otras puses, tā ir visa ekosistēma. Å Ä« ir operētājsistēma, kas ir mÅ«su iekārtās. Kas tas ir? Ubuntu vai Curios? Å is ir Linux kodols, virkne papildu komponentu. Visas Ŕīs lietas Å”eit, vienu indÄ«gu čūsku izmeta no ceļa, tur uzcēla sētu. Kubernetes attÄ«stās ļoti ātri un dinamiski, un risku apjoms, nezināmā apjoms ar katru mēnesi samazinās un attiecÄ«gi Å”ie svari lÄ«dzsvarojas.

Atbildot uz jautājumu, ko darÄ«t startup, es teiktu - nāc uz Flaunt, samaksā 150 tÅ«kstoÅ”us rubļu un saņem DevOps vieglo servisu. Ja esat mazs iesācējs ar dažiem izstrādātājiem, tas darbojas. Tā vietā, lai nolÄ«gtu savus izstrādātājus, kuriem Å”obrÄ«d bÅ«s jāiemācās atrisināt jÅ«su problēmas un maksāt algu, jÅ«s iegÅ«sit visu problēmu risinājumu. Jā, ir daži trÅ«kumi. Mēs kā ārpakalpojumu sniedzējs nevaram bÅ«t tik iesaistÄ«ti un ātri reaģēt uz izmaiņām. Bet mums ir daudz zināŔanu un gatavas prakses. Mēs garantējam, ka jebkurā situācijā mēs to noteikti ātri izdomāsim un uzcelsim no nāves jebkuru Kubernetes.

Stingri iesaku izmantot ārpakalpojumus jaunizveidotiem un jau izveidotiem uzņēmumiem līdz tādam izmēram, lai darbībai varētu veltīt 10 cilvēku komandu, jo citādi nav jēgas. Noteikti ir jēga to izmantot ārpakalpojumu sniedzējiem.

Par Amazon un Google

ā€” Vai resursdatoru no Amazon vai Google risinājuma var uzskatÄ«t par ārpakalpojumu?

Dmitrijs: Jā, protams, tas atrisina vairākas problēmas. Bet atkal ir nianses. Jums joprojām ir jāsaprot, kā to izmantot. Piemēram, Amazon AWS darbā ir tÅ«kstoÅ” sÄ«kumu: jāuzsilda Load Balancer vai iepriekÅ” jāuzraksta pieprasÄ«jums, ka "puiÅ”i, mēs saņemsim satiksmi, iesildiet mums slodzes balansētāju!" Jums jāzina Ŕīs nianses.

VērÅ”oties pie cilvēkiem, kuri specializējas Å”ajā jomā, gandrÄ«z visas tipiskās lietas tiek aizvērtas. Mums tagad ir 40 inženieri, lÄ«dz gada beigām, iespējams, bÅ«s 60 - mēs noteikti esam saskāruÅ”ies ar visām Ŕīm lietām. Pat ja mēs atkal saskaramies ar Å”o problēmu kādā projektā, mēs ātri jautājam viens otram un zinām, kā to atrisināt.

DroÅ”i vien atbilde ir ā€“ protams, viesots stāsts kādu daļu atvieglo. Jautājums ir par to, vai esat gatavs uzticēties Å”iem saimniekiem un vai viņi atrisinās jÅ«su problēmas. Amazon un Google ir pastrādājuÅ”i labi. Visiem mÅ«su gadÄ«jumiem ā€“ tieÅ”i tā. Mums vairs nav pozitÄ«vas pieredzes. Visi pārējie mākoņi, ar kuriem mēģinājām strādāt, rada daudz problēmu - Ager, un viss, kas ir Krievijā, un visādi OpenStack dažādās implementācijās: Headster, Overage - ko vien vēlaties. Tie visi rada problēmas, kuras jÅ«s nevēlaties atrisināt.

Tāpēc atbilde ir jā, taču patiesÄ«bā nav ļoti daudz nobrieduÅ”u mitinātu risinājumu.

Kam ir vajadzīgas Kubernetes?

ā€” Un tomēr, kam vajadzÄ«ga Kubernetes? Kuram jau vajadzētu pāriet uz Kubernetes, kurÅ” ir tipiskais Flaunt klients, kurÅ” nāk tieÅ”i Kubernetes?

Dmitrijs: Tas ir interesants jautājums, jo tieÅ”i tagad, pēc Kubernetes, pie mums nāk daudzi cilvēki: "PuiÅ”i, mēs zinām, ka jÅ«s darāt Kubernetes, dariet to mÅ«su vietā!" Mēs viņiem atbildam: "Kungi, mēs nedarām Kubernetes, mēs darām prod un visu, kas ar to saistÄ«ts." Jo paÅ”laik ir vienkārÅ”i neiespējami izveidot produktu, neveicot visu CI/CD un visu Å”o stāstu. Ikviens ir attālinājies no sadalÄ«juma, ka mums ir attÄ«stÄ«ba ar attÄ«stÄ«bu un pēc tam ekspluatācija ar ekspluatāciju.

MÅ«su klienti sagaida dažādas lietas, bet katrs gaida kādu labu brÄ«numu, ka viņiem ir kādas problēmas, un tagad - hop! ā€” Kubernetes tos atrisinās. Cilvēki tic brÄ«numiem. Domās saprot, ka brÄ«numa nebÅ«s, bet dvēselē cer - ja nu Ŕī Kubernetes tagad visu atrisinās mÅ«su vietā, tik daudz par to runā! PēkŔņi viņŔ tagad - ŔķaudÄ«t! - un sudraba lode, ŔķaudÄ«t! ā€” un mums ir 100% darbspējas laiks, visi izstrādātāji var izlaist visu, kas nonāk ražoÅ”anā 50 reizes, un tas neavārē. Vispār brÄ«nums!

Kad Ŕādi cilvēki nāk pie mums, mēs sakām: "Atvainojiet, bet nav tāda lietas kā brÄ«nums." Lai bÅ«tu vesels, jums labi jāēd un jāvingro. Lai produkts bÅ«tu uzticams, tas ir jāizgatavo uzticami. Lai iegÅ«tu ērtu CI/CD, tas ir jāizveido Ŕādi. Tas ir liels darbs, kas jāpaveic.

Atbildot uz jautājumu, kam Kubernetes ir vajadzīgas - Kubernetes nevienam nav vajadzīgas.

Dažiem cilvēkiem ir nepareizs priekÅ”stats, ka viņiem ir vajadzÄ«gas Kubernetes. Cilvēkiem ir nepiecieÅ”ams, viņiem ir dziļa vajadzÄ«ba pārstāt domāt, mācÄ«ties un interesēties par visām infrastruktÅ«ras problēmām un viņu lietojumprogrammu palaiÅ”anas problēmām. Viņi vēlas, lai lietojumprogrammas vienkārÅ”i darbotos un vienkārÅ”i izvietotu. Viņiem Kubernetes ir cerÄ«ba, ka viņi pārstās dzirdēt stāstu par to, ka ā€œmēs tur gulējāmā€, ā€œmēs nevaram izkustētiesā€ vai kaut ko citu.

Pie mums parasti ierodas tehniskais direktors. Viņi viņam jautā divas lietas: no vienas puses, pieŔķiriet mums iezÄ«mes, no otras puses, stabilitāti. Mēs iesakām jums to uzņemties un darÄ«t. Sudraba lode vai drÄ«zāk apsudrabota ir tāda, ka jÅ«s pārstāsit domāt par Ŕīm problēmām un tērēt laiku. Jums bÅ«s Ä«paÅ”i cilvēki, kas slēgs Å”o jautājumu.

Formulējums, ka mums vai kādam citam ir vajadzīgas Kubernetes, ir nepareizs.

Adminiem ļoti vajag Kubernetes, jo tā ir ļoti interesanta rotaļlieta, ar kuru var spēlēties un čakarēt. BÅ«sim godÄ«gi ā€“ visiem patÄ«k rotaļlietas. Mēs visi kaut kur esam bērni, un, ieraugot jaunu, gribas to uzspēlēt. Dažiem tas ir atturēts, piemēram, administrācijā, jo viņi jau ir pietiekami spēlējuÅ”i un jau ir tik noguruÅ”i, ka vienkārÅ”i negrib. Bet tas nevienam nav pilnÄ«bā zaudēts. Piemēram, ja man jau sen ir apnikuÅ”as rotaļlietas sistēmu administrÄ“Å”anas un DevOps jomā, tad man tās rotaļlietas joprojām patÄ«k, tomēr pērku jaunas. Visi cilvēki tā vai citādi vēlas kaut kādas rotaļlietas.

Nav jāspēlējas ar ražoÅ”anu. Lai ko es kategoriski iesaku nedarÄ«t un ko tagad masveidā redzu: ā€œAk, jauna rotaļlieta!ā€ ā€” viņi skrēja to pirkt, nopirka un: "Tagad aizvedÄ«sim uz skolu un parādÄ«sim visiem draugiem." Nedari tā. Es atvainojos, mani bērni tikai aug, es pastāvÄ«gi kaut ko redzu bērnos, pamanu to sevÄ« un tad vispārinu citiem.

Galīgā atbilde ir: jums nav vajadzīgas Kubernetes. Jums ir jāatrisina savas problēmas.

Tas, ko jūs varat sasniegt, ir:

  • prod nekrÄ«t;
  • pat ja viņŔ mēģina nokrist, mēs par to zinām iepriekÅ” un varam tajā kaut ko ielikt;
  • mēs varam to mainÄ«t tādā ātrumā, kādā tas nepiecieÅ”ams mÅ«su biznesam, un varam to izdarÄ«t ērti; tas mums nesagādā nekādas problēmas.

Ir divas reālas vajadzības: uzticamība un ievieŔanas dinamisms/elastība. Katram, kurŔ Ŕobrīd veic kaut kādus IT projektus, vienalga kādā biznesā - mīksto pasaules atviegloŔanai un kas to saprot, ir jārisina Ŕīs vajadzības. Kubernetes ar pareizo pieeju, ar pareizu izpratni un pietiekamu pieredzi ļauj tās atrisināt.

Par bez servera

ā€” Ja paskatās nedaudz tālākā nākotnē, tad, mēģinot risināt galvassāpju neesamÄ«bas problēmu ar infrastruktÅ«ru, ar izlaiÅ”anas ātrumu un aplikāciju maiņas ātrumu parādās jauni risinājumi, piemēram, bez servera. Vai jÅ«tat kādu potenciālu Å”ajā virzienā un, teiksim, bÄ«stamÄ«bu Kubernetes un tamlÄ«dzÄ«giem risinājumiem?

Dmitrijs: Te atkal vajag izteikt piebildi, ka es neesmu gaiÅ”reÄ£is, kas skatās uz priekÅ”u un saka - bÅ«s tā! Lai gan es tikko darÄ«ju to paÅ”u. Skatos uz savām kājām un redzu tur daudz problēmu, piemēram, kā datorā darbojas tranzistori. Tas ir smieklÄ«gi, vai ne? Mēs saskaramies ar dažām kļūdām CPU.

Padariet bezservera diezgan uzticamu, lētu, efektÄ«vu un ērtu, atrisinot visas ekosistēmas problēmas. Å eit es piekrÄ«tu Elonam Muskam, ka ir vajadzÄ«ga otra planēta, lai radÄ«tu cilvēces kļūdu toleranci. Lai gan es nezinu, ko viņŔ saka, es saprotu, ka pats neesmu gatavs lidot uz Marsu un tas nenotiks rÄ«t.

Izmantojot bez servera, ir skaidrs, ka tā ir ideoloÄ£iski pareiza lieta, piemēram, defektu tolerance pret cilvēci - divas planētas ir labākas nekā viena. Bet kā to izdarÄ«t tagad? Vienas ekspedÄ«cijas nosÅ«tÄ«Å”ana nav problēma, ja koncentrējat savus spēkus uz to. Vairāku ekspedÄ«ciju nosÅ«tÄ«Å”ana un vairāku tÅ«kstoÅ”u cilvēku turp izmitināŔana, manuprāt, arÄ« ir reāli. Bet padarÄ«t to pilnÄ«gi izturÄ«gu pret defektiem, lai tur dzÄ«votu puse cilvēces, man Ŕķiet, ka tagad nav iespējams, nedomājot.

Ar bezserveriem viens pret vienu: lieta ir forÅ”a, taču tā ir tālu no 2019. gada problēmām. Tuvāk 2030. gadam ā€” dzÄ«vosim, lai to redzētu. NeÅ”aubos, ka dzÄ«vosim, noteikti dzÄ«vosim (atkārtojiet pirms gulētieÅ”anas), bet tagad jārisina citas problēmas. Tas ir kā ticēt pasaku ponijam VaravÄ«ksne. Jā, pāris procenti gadÄ«jumu tiek atrisināti, un tie tiek atrisināti lieliski, bet subjektÄ«vi bez servera ir varavÄ«ksne... Man Ŕī tēma ir pārāk tāla un pārāk nesaprotama. Es neesmu gatavs runāt. 2019. gadā jÅ«s nevarat uzrakstÄ«t vienu lietojumprogrammu bez servera.

Kā Kubernetes attīstīsies

ā€” Kā, jÅ«suprāt, attÄ«stÄ«sies Kubernetes un tai apkārt esoŔā ekosistēma, virzoties uz Å”o potenciāli brÄ«niŔķīgo tālo nākotni?

Dmitrijs: Esmu par to daudz domājis, un man ir skaidra atbilde. Pirmais ir statusfull - galu galā bezvalstnieku ir vieglāk izdarÄ«t. Kubernetes sākotnēji ieguldÄ«ja vairāk, viss sākās ar to. Bezvalstnieks darbojas gandrÄ«z ideāli Kubernetes, vienkārÅ”i nav par ko sÅ«dzēties. Joprojām ir daudz problēmu, pareizāk sakot, nianses. Tur jau viss mums darbojas lieliski, bet tie esam mēs. Paies vēl vismaz pāris gadi, lai tas darbotos visiem. Tas nav aprēķināts rādÄ«tājs, bet gan mana sajÅ«ta no galvas.

ÄŖsāk sakot, statusfull vajadzētu attÄ«stÄ«ties un attÄ«stÄ«ties ļoti spēcÄ«gi, jo visas mÅ«su lietojumprogrammas saglabā statusu; nav bezvalstnieku lietojumprogrammu. Tā ir ilÅ«zija; jums vienmēr ir nepiecieÅ”ama kāda veida datubāze un kaut kas cits. Statefull ir par visu iespējamo iztaisnoÅ”anu, visu kļūdu laboÅ”anu, visu to problēmu uzlaboÅ”anu, ar kurām paÅ”laik nākas saskarties ā€“ sauksim to par adopciju.

Ievērojami pazemināsies nezināmā lÄ«menis, neatrisināto problēmu lÄ«menis, iespējamÄ«bas lÄ«menis ar kaut ko saskarties. Å is ir svarÄ«gs stāsts. Un operatori - viss, kas saistÄ«ts ar administrÄ“Å”anas loÄ£ikas kodifikāciju, vadÄ«bas loÄ£iku, lai iegÅ«tu vieglu servisu: MySQL vieglais serviss, RabbitMQ vieglais serviss, Memcache vieglais serviss - kopumā visi Å”ie komponenti, no kuriem mums ir jāgarantē strādāt kaste. Tas vienkārÅ”i atrisina problēmu, ka mēs vēlamies datubāzi, bet nevēlamies to administrēt, vai arÄ« mēs vēlamies Kubernetes, bet nevēlamies to administrēt.

Šis operatoru attīstības stāsts vienā vai otrā veidā būs nozīmīgs tuvāko pāris gadu laikā.

Manuprāt lietoÅ”anas ērtumam vajadzētu stipri palielināties - kaste kļūs arvien melnāka, arvien uzticamāka, ar vienkārŔākām kloÄ·Ä«Å”iem.

Reiz sestdienas vakara tieÅ”raidē klausÄ«jos senu interviju ar ÄŖzaku Asimovu no 80. gadiem YouTube - tāda programma kā Urgant, tikai interesanti. Viņi jautāja viņam par datoru nākotni. ViņŔ teica, ka nākotne ir vienkārŔībā, tāpat kā radio. Radio uztvērējs sākotnēji bija sarežģīta lieta. Lai noÄ·ertu vilni, vajadzēja 15 minÅ«tes griezt kloÄ·us, griezt iesmus un vispār zināt, kā viss darbojas, saprast radioviļņu pārraides fiziku. Rezultātā radio bija palicis tikai viens kloÄ·is.

Kāds radio tagad 2019. gadā? AutomaŔīnā radio uztvērējs atrod visus viļņus un staciju nosaukumus. Procesa fizika 100 gadu laikā nav mainÄ«jusies, bet lietoÅ”anas ērtums gan. Tagad, un ne tikai tagad, jau 1980. gadā, kad bija intervija ar Azimovu, visi izmantoja radio un neviens nedomāja, kā tas darbojas. Tas vienmēr darbojās ā€“ tas ir paÅ”saprotami.

Pēc tam Azimovs teica, ka tas pats bÅ«s ar datoriem - lietoÅ”anas vienkārŔība palielināsies. Ja 1980. gadā bija jāapmāca spiest datora pogas, nākotnē tā vairs nebÅ«s.

Man ir sajÅ«ta, ka ar Kubernetes un ar infrastruktÅ«ru bÅ«s arÄ« milzÄ«gs lietoÅ”anas ērtuma pieaugums. Tas, manuprāt, ir acÄ«mredzami ā€“ tas slēpjas virspusē.

Ko darīt ar inženieriem?

ā€” Kas tad notiks ar inženieriem un sistēmu administratoriem, kuri atbalsta Kubernetes?

Dmitrijs: Kas notika ar grāmatvedi pēc 1C parādÄ«Å”anās? Apmēram tāpat. Pirms tam viņi skaitÄ«ja uz papÄ«ra - tagad programmā. Darba ražīgums ir palielinājies par lielumu kārtām, bet pats darbaspēks nav pazudis. Ja iepriekÅ” spuldzes ieskrÅ«vÄ“Å”anai bija nepiecieÅ”ami 10 inženieri, tad tagad pietiks ar vienu.

ProgrammatÅ«ras apjoms un uzdevumu skaits, man Ŕķiet, tagad pieaug straujāk nekā parādās jauni DevOps un palielinās efektivitāte. Å obrÄ«d tirgÅ« ir Ä«paÅ”s deficÄ«ts, un tas ilgs ilgu laiku. Vēlāk viss atgriezÄ«sies kaut kādā normālā stāvoklÄ«, kurā paaugstināsies darba efektivitāte, bÅ«s arvien vairāk bezserveru, pie Kubernetes tiks pievienots neirons, kas atlasÄ«s visus resursus tieÅ”i pēc vajadzÄ«bas un vispār dari visu pats, kā nākas - cilvēks vienkārÅ”i atkāpjas un netraucē.

Bet kādam tomēr bÅ«s jāpieņem lēmumi. Skaidrs, ka Ŕīs personas kvalifikācijas un specializācijas lÄ«menis ir augstāks. MÅ«sdienās grāmatvedÄ«bā nevajag 10 darbiniekus, kas kārto grāmatiņas, lai rokas nenogurst. Tas vienkārÅ”i nav nepiecieÅ”ams. Daudzus dokumentus automātiski skenē un atpazÄ«st elektroniskā dokumentu pārvaldÄ«bas sistēma. Pietiek ar vienu gudru galveno grāmatvedi, jau ar daudz lielākām prasmēm, ar labu izpratni.

Kopumā tas ir veids, kā iet visās nozarēs. Tāpat ir ar automaŔīnām: iepriekÅ” automaŔīna bija aprÄ«kota ar mehāniÄ·i un trim vadÄ«tājiem. MÅ«sdienās braukÅ”ana ar automaŔīnu ir vienkārÅ”s process, kurā mēs visi piedalāmies katru dienu. Neviens nedomā, ka automaŔīna ir kaut kas sarežģīts.

DevOps jeb sistēmu inženierija nepazudÄ«s ā€“ augs augsta lÄ«meņa darbs un efektivitāte.

ā€” Dzirdēju arÄ« interesantu domu, ka darbs tieŔām pieaugs.

Dmitrijs: Protams, simtprocentÄ«gi! Jo mÅ«su rakstÄ«tās programmatÅ«ras apjoms nepārtraukti pieaug. Ar programmatÅ«ru risināmo problēmu skaits nepārtraukti pieaug. Darba apjoms pieaug. Tagad DevOps tirgus ir Å”ausmÄ«gi pārkarsēts. To var redzēt algu gaidās. Labā nozÄ«mē, neiedziļinoties detaļās, vajadzētu bÅ«t junioriem, kas vēlas X, vidus, kas vēlas 1,5X, un senioriem, kas vēlas 2X. Un tagad, ja paskatās uz Maskavas DevOps algu tirgu, juniors vēlas no X uz 3X un vecākais no X lÄ«dz 3X.

Neviens nezina, cik tas maksā. Algu lÄ«meni mēra pēc tavas pārliecÄ«bas - pilnÄ«gs trako nams, godÄ«gi sakot, Å”ausmÄ«gi pārkarsēts tirgus.

Protams, Ŕī situācija ļoti drÄ«z mainÄ«sies ā€“ vajadzētu notikt zināmam piesātinājumam. ProgrammatÅ«ras izstrādes gadÄ«jumā tā nav - neskatoties uz to, ka visiem ir vajadzÄ«gi izstrādātāji, un visiem vajag labus izstrādātājus, tirgus saprot, kurÅ” ir ko vērts - nozare ir iekārtojusies. MÅ«sdienās tas tā nav ar DevOps.

ā€” No dzirdētā secinu, ka esoÅ”ajam sistēmas administratoram nevajadzētu pārlieku uztraukties, bet ir laiks papildināt savas prasmes un sagatavoties tam, ka rÄ«t darba bÅ«s vairāk, bet tas bÅ«s augstāk kvalificēts.

Dmitrijs: Simts procenti. Kopumā mēs dzÄ«vojam 2019. gadā, un dzÄ«ves noteikums ir Ŕāds: mūža mācÄ«Å”anās ā€“ mēs mācāmies visas dzÄ«ves garumā. Man Ŕķiet, ka tagad visi to jau zina un jÅ«t, bet ar to vien nepietiek, ka zināt - jums tas ir jādara. Katru dienu mums ir jāmainās. Ja mēs to nedarÄ«sim, tad agri vai vēlu tiksim nomesti profesijas malā.

Esiet gatavi asiem 180 grādu pagriezieniem. Es neizslēdzu situāciju, kad kaut kas radikāli mainās, tiek izdomāts kaut kas jauns - tas notiek. Hop! - un tagad mēs rÄ«kojamies savādāk. Ir svarÄ«gi tam sagatavoties un neuztraukties. Var gadÄ«ties, ka rÄ«t viss, ko daru, izrādÄ«sies lieks - nekas, visu mūžu esmu mācÄ«jies un gatavs mācÄ«ties vēl kaut ko. Tā nav problēma. Nav jābaidās no darba droŔības, taču jābÅ«t gatavam pastāvÄ«gi apgÅ«t ko jaunu.

Novēlējumi un minūte reklāmas

- Vai jums ir kāda vēlÄ“Å”anās?

Dmitrijs: Jā, man ir vairākas vēlÄ“Å”anās.

Pirmais un merkantils - abonējiet YouTube. CienÄ«jamie lasÄ«tāji, dodieties uz YouTube un abonējiet mÅ«su kanālu. Apmēram pēc mēneÅ”a sāksim aktÄ«vu video pakalpojuma paplaÅ”ināŔanu. Mums bÅ«s daudz izglÄ«tojoÅ”a satura par Kubernetes, atvērtu un daudzveidÄ«gu: no praktiskām lietām, lÄ«dz pat laboratorijām, lÄ«dz dziļi fundamentālām teorētiskām lietām un kā lietot Kubernetes. principu un modeļu lÄ«menis.

Otra merkantilā vēlme ā€“ ej uz GitHub un likt zvaigznes, jo mēs ar tām barojam. Ja nedosi mums zvaigznes, mums nebÅ«s ko ēst. Tas ir kā mana datorspēlē. Kaut ko darām, darām, cenÅ”amies, kāds saka, ka tie ir baigie velosipēdi, kāds, ka viss ir galÄ«gi nepareizi, bet mēs turpinām un rÄ«kojamies absolÅ«ti godÄ«gi. Mēs redzam problēmu, risinām to un dalāmies pieredzē. Tāpēc uzdāvini mums zvaigzni, tā no tevis nepazudÄ«s, bet atnāks pie mums, jo mēs no tām barojam.

TreŔā, svarÄ«ga un vairs ne merkantila vēlme - beidz ticēt pasakām. JÅ«s esat profesionāļi. DevOps ir ļoti nopietna un atbildÄ«ga profesija. Pārtrauciet spēlēt darba vietā. Ä»aujiet tai noklikŔķināt jÅ«su vietā, un jÅ«s to sapratÄ«sit. Iedomājieties, ka jÅ«s ierodaties slimnÄ«cā, un tur ārsts ar jums eksperimentē. Es saprotu, ka tas kādam var bÅ«t aizskaroÅ”i, bet, visticamāk, tas nav par jums, bet gan par kādu citu. Pastāstiet arÄ« citiem apstāties. Tas patieŔām sabojā mÅ«su visu dzÄ«vi ā€” daudzi sāk izturēties pret operācijām, administratoriem un izstrādātājiem kā pret čaļiem, kuri atkal kaut ko ir sabojājuÅ”i. Visbiežāk tas tika ā€œsalauztsā€ tāpēc, ka gājām spēlēt, nevis ar aukstu apziņu skatÄ«jāmies, ka tā tas ir, un tā tas ir.

Tas nenozÄ«mē, ka jums nevajadzētu eksperimentēt. Mums ir jāeksperimentē, mēs to darām paÅ”i. GodÄ«gi sakot, mēs paÅ”i dažreiz spēlējam spēles - tas, protams, ir ļoti slikti, bet nekas cilvēcisks mums nav sveÅ”s. Pasludināsim 2019. gadu par nopietnu, pārdomātu eksperimentu, nevis sērijveida spēļu gadu. Laikam tā.

- Liels paldies!

Dmitrijs: Paldies, Vitālij, gan par laiku, gan par interviju. CienÄ«jamie lasÄ«tāji, liels paldies, ja pēkŔņi esat sasnieguÅ”i Å”o punktu. Es ceru, ka mēs jums radÄ«jām vismaz pāris domas.

Intervijā Dmitrijs pieskārās werf jautājumam. Tagad Å”is ir universāls Å veices nazis, kas atrisina gandrÄ«z visas problēmas. Bet ne vienmēr tā bija. Ieslēgts DevOpsConf  festivālā RIT++ Dmitrijs Stoļarovs detalizēti pastāstÄ«s par Å”o rÄ«ku. ziņojumā "werf ir mÅ«su rÄ«ks CI/CD darbam Kubernetes" bÅ«s viss: Kubernetes problēmas un slēptās nianses, Å”o grÅ«tÄ«bu risināŔanas iespējas un paÅ”reizējā werf ievieÅ”ana sÄ«kāk. Pievienojieties mums 27. un 28. maijā, mēs izveidosim ideālus rÄ«kus.

Avots: www.habr.com

Pievieno komentāru