Në pritje Vitaly Khabarov intervistuar Dmitry Stolyarov (), drejtor teknik dhe bashkëthemelues i kompanisë Flant. Vitaly e pyeti Dmitrin për atë që bën Flant, për Kubernetes, zhvillimin e ekosistemit, mbështetjen. Ne diskutuam pse Kubernetes është i nevojshëm dhe nëse është i nevojshëm fare. Dhe gjithashtu në lidhje me mikroshërbimet, Amazon AWS, qasjen "Unë do të jem me fat" për DevOps, të ardhmen e vetë Kubernetes, pse, kur dhe si do të pushtojë botën, perspektivat e DevOps dhe për çfarë inxhinierët duhet të përgatiten në e ardhme e ndritur dhe e afërt me thjeshtim dhe rrjete nervore.
dëgjoni si një podcast në DevOps Deflop - një podcast në gjuhën ruse për DevOps, dhe më poshtë është versioni me tekst.
Këtu dhe më poshtë ai bën pyetje inxhinier nga Express42.
Rreth "Flant"
- Përshëndetje Dima. Ju jeni drejtor teknik”" dhe gjithashtu themeluesi i saj. Ju lutemi na tregoni se çfarë bën kompania dhe çfarë jeni në të?
Dmitry: Nga jashtë duket sikur ne jemi djemtë që qarkullojmë duke instaluar Kubernetes për të gjithë dhe duke bërë diçka me të. Por kjo nuk është e vërtetë. Ne filluam si një kompani që merret me Linux, por për një kohë shumë të gjatë aktiviteti ynë kryesor ka qenë shërbimi i prodhimit dhe projekteve me ngarkesë të lartë në dorë. Zakonisht ne e ndërtojmë të gjithë infrastrukturën nga e para dhe më pas jemi përgjegjës për të për një kohë të gjatë e të gjatë. Prandaj, puna kryesore që bën “Flant” dhe për të cilën merr para është marrjen e përgjegjësisë dhe zbatimin e prodhimit me çelës në dorë.
Unë, si drejtor teknik dhe një nga themeluesit e kompanisë, kaloj gjithë ditën dhe natën duke u përpjekur të kuptoj se si të rris aksesin e prodhimit, të thjeshtoj funksionimin e tij, ta bëjë jetën e administratorëve më të lehtë dhe jetën e zhvilluesve më të këndshëm. .
Rreth Kubernetes
— Kohët e fundit kam parë shumë raporte nga Flant dhe rreth Kubernetes. Si erdhët tek ajo?
Dmitry: E kam folur tashmë shumë herë për këtë, por nuk e kam problem ta përsëris fare. Mendoj se është e drejtë të përsëritet kjo temë sepse ka një konfuzion midis shkakut dhe pasojës.
Na duhej vërtet një mjet. U përballëm me shumë probleme, u munduam, i tejkaluam me paterica të ndryshme dhe ndjemë nevojën për një mjet. Ne kaluam nëpër shumë opsione të ndryshme, ndërtuam biçikletat tona dhe fituam përvojë. Gradualisht arritëm në pikën ku filluam të përdorim Docker pothuajse sapo u shfaq - rreth vitit 2013. Në kohën e shfaqjes së tij, ne tashmë kishim shumë përvojë me kontejnerët, ne kishim shkruar tashmë një analog të "Docker" - disa nga patericat tona në Python. Me ardhjen e Docker, u bë e mundur të hidheshin patericat dhe të përdornin një zgjidhje të besueshme dhe të mbështetur nga komuniteti.
Me Kubernetes historia është e ngjashme. Në kohën kur filloi të fitonte vrull - për ne ky është versioni 1.2 - ne kishim tashmë një tufë patericash si në Shell ashtu edhe në Chef, të cilat u përpoqëm disi t'i orkestronim me Docker. Ne po shikonim seriozisht drejt Rancher-it dhe zgjidhjeve të tjera të ndryshme, por më pas u shfaq Kubernetes, në të cilin gjithçka zbatohet saktësisht siç do të kishim bërë ose edhe më mirë. Nuk ka asgjë për t'u ankuar.
Po, ka një lloj papërsosmërie këtu, ka një lloj papërsosmërie atje - ka shumë papërsosmëri, dhe 1.2 është përgjithësisht e tmerrshme, por... Kubernetes është si një ndërtesë në ndërtim - ju shikoni projektin dhe kuptoni se do të jetë e freskët. Nëse ndërtesa tani ka një themel dhe dy kate, atëherë e kuptoni që është më mirë të mos hyni ende, por nuk ka probleme të tilla me softuerin - tashmë mund ta përdorni.
Nuk kishim një moment ku mendonim të përdornim apo jo Kubernetes. Ne e prisnim shumë përpara se të shfaqej dhe u përpoqëm të krijonim analoge vetë.
Rreth Kubernetes
— A jeni i përfshirë drejtpërdrejt në zhvillimin e vetë Kubernetes?
Dmitry: Mediokër. Përkundrazi, ne marrim pjesë në zhvillimin e ekosistemit. Ne dërgojmë një numër të caktuar kërkesash për tërheqje: tek Prometeu, tek operatorët e ndryshëm, tek Helm - tek ekosistem. Fatkeqësisht, nuk jam në gjendje të mbaj gjurmët e gjithçkaje që bëjmë dhe mund të gaboj, por nuk ka asnjë grup të vetëm nga ne në thelb.
— Në të njëjtën kohë, a zhvilloni shumë nga mjetet tuaja rreth Kubernetes?
Dmitry: Strategjia është kjo: ne shkojmë dhe tërheqim kërkesa për gjithçka që ekziston. Nëse kërkesat për tërheqje nuk pranohen atje, ne thjesht i presim ato vetë dhe jetojmë derisa të pranohen me ndërtimet tona. Më pas, kur të arrijë në rrjedhën e sipërme, ne kthehemi në versionin e sipërm.
Për shembull, ne kemi një operator Prometheus, me të cilin kemi kaluar mbrapa dhe me radhë në rrjedhën e sipërme të asamblesë sonë ndoshta 5 herë tashmë. Ne kemi nevojë për një lloj veçorie, kemi dërguar një kërkesë për tërheqje, duhet ta nxjerrim atë nesër, por nuk duam të presim që të lëshohet në rrjedhën e sipërme. Në përputhje me rrethanat, ne mbledhim për veten tonë, hapim asamblenë tonë me veçorinë tonë, e cila na nevojitet për disa arsye, në të gjitha grupimet tona. Pastaj, për shembull, na e kthejnë në rrjedhën e sipërme me fjalët: "Djema, le ta bëjmë për një rast më të përgjithshëm", ne ose dikush tjetër e mbarojmë dhe me kalimin e kohës ajo bashkohet përsëri.
Ne përpiqemi të zhvillojmë gjithçka që ekziston. Shumë elementë që ende nuk ekzistojnë, nuk janë shpikur ende, ose janë shpikur, por nuk kanë pasur kohë t'i zbatojnë - ne po e bëjmë. Dhe jo sepse na pëlqen procesi apo ndërtimi i biçikletave si industri, por thjesht sepse na duhet ky mjet. Shpesh shtrohet pyetja, pse e bëmë këtë apo atë gjë? Përgjigja është e thjeshtë - po, sepse duhej të shkonim më tej, të zgjidhnim një problem praktik dhe e zgjidhëm me këtë tulë.
Rruga është gjithmonë e tillë: ne kërkojmë me shumë kujdes dhe, nëse nuk gjejmë ndonjë zgjidhje se si të bëjmë një trolejbus nga një copë bukë, atëherë bëjmë bukën tonë dhe trolejbusin tonë.
Vegla Flanta
— E di që Flant tani ka operatorë shtesë, operatorë guaskë dhe vegla dapp/werf. Siç e kuptoj unë, ky është i njëjti instrument në mishërime të ndryshme. Unë gjithashtu e kuptoj se ka shumë më tepër mjete të ndryshme brenda Flaunt. Kjo eshte e vertetë?
Dmitry: Kemi shumë më tepër në GitHub. Nga sa mbaj mend tani, ne kemi një status - një panel për Grafanën që të gjithë e kanë hasur. Përmendet pothuajse në çdo artikull të dytë në lidhje me monitorimin e Kubernetes në Medium. Është e pamundur të shpjegohet shkurtimisht se çfarë është harta e statusit - kërkon një artikull të veçantë, por është një gjë shumë e dobishme për monitorimin e statusit me kalimin e kohës, pasi në Kubernetes shpesh na duhet të tregojmë statusin me kalimin e kohës. Ne gjithashtu kemi LogHouse - kjo është një gjë e bazuar në ClickHouse dhe magjinë e zezë për mbledhjen e regjistrave në Kubernetes.
Shumë shërbime! Dhe do të ketë edhe më shumë, sepse një sërë zgjidhjesh të brendshme do të dalin këtë vit. Nga ato shumë të mëdha të bazuara në operatorin e shtesave, ka një mori shtesash për Kubernetes, ala se si të instaloni siç duhet menaxherin sert - një mjet për menaxhimin e certifikatave, si të instaloni saktë Prometheus me një mori pajisje shtesë - këto janë rreth njëzet të ndryshme binare që eksportojnë të dhëna dhe mbledhin diçka, tek ky Prometeu ka grafikat dhe sinjalizimet më të mahnitshme. E gjithë kjo është vetëm një grumbull shtesash për Kubernetes, të cilat janë instaluar në një grup, dhe kthehet nga e thjeshtë në e ftohtë, e sofistikuar, automatike, në të cilën tashmë janë zgjidhur shumë çështje. Po, ne bëjmë shumë.
Zhvillimi i Ekosistemit
“Më duket se ky është një kontribut shumë i madh në zhvillimin e këtij instrumenti dhe metodave të përdorimit të tij.” A mund të vlerësoni përafërsisht se kush tjetër do të jepte të njëjtin kontribut në zhvillimin e ekosistemit?
Dmitry: Në Rusi, nga kompanitë që operojnë në tregun tonë, askush nuk është as afër. Sigurisht, kjo është një deklaratë me zë të lartë, sepse ka lojtarë të mëdhenj si Mail dhe Yandex - ata gjithashtu po bëjnë diçka me Kubernetes, por edhe ata nuk i afrohen kontributit të kompanive në të gjithë botën që bëjnë shumë më tepër se ne. Është e vështirë të krahasosh Flantin, i cili ka një staf prej 80 personash, dhe Red Hat, i cili ka 300 inxhinierë vetëm për Kubernetes, nëse nuk gaboj. Është e vështirë të krahasosh. Ne kemi 6 persona në departamentin e RnD, duke përfshirë edhe mua, që presim të gjitha mjetet tona. 6 persona kundrejt 300 inxhinierëve Red Hat - është disi e vështirë të krahasosh.
- Megjithatë, kur edhe këta 6 persona mund të bëjnë diçka vërtet të dobishme dhe tjetërsuese, kur përballen me një problem praktik dhe i japin zgjidhje komunitetit - një rast interesant. Unë e kuptoj që në kompanitë e mëdha të teknologjisë, ku ata kanë ekipin e tyre të zhvillimit dhe mbështetjes Kubernetes, në parim, të njëjtat mjete mund të zhvillohen. Ky është një shembull për ta se çfarë mund të zhvillohet dhe t'i jepet komunitetit, duke i dhënë shtysë të gjithë komunitetit që përdor Kubernetes.
Dmitry: Kjo është ndoshta një veçori e integratorit, veçantia e tij. Kemi shumë projekte dhe shohim situata të ndryshme. Për ne, mënyra kryesore për të krijuar vlerë të shtuar është analizimi i këtyre rasteve, gjetja e të përbashkëtave dhe bërja sa më e lirë për ne. Ne jemi duke punuar në mënyrë aktive për këtë. Është e vështirë për mua të flas për Rusinë dhe botën, por ne kemi rreth 40 inxhinierë DevOps në kompani që punojnë në Kubernetes. Nuk mendoj se ka shumë kompani në Rusi me një numër të krahasueshëm specialistësh që kuptojnë Kubernetes, nëse ka fare.
Unë kuptoj gjithçka për titullin e punës inxhinier DevOps, të gjithë kuptojnë gjithçka dhe janë mësuar t'i quajnë inxhinierët DevOps inxhinierë DevOps, ne nuk do ta diskutojmë këtë. Të gjithë këta 40 inxhinierë të mahnitshëm DevOps përballen dhe zgjidhin probleme çdo ditë, ne thjesht e analizojmë këtë përvojë dhe përpiqemi ta përgjithësojmë. Ne e kuptojmë që nëse mbetet brenda nesh, atëherë në një ose dy vit mjeti do të jetë i padobishëm, sepse diku në komunitet do të shfaqet një Tula e gatshme. Nuk ka kuptim ta grumbullosh këtë përvojë brenda vetes - thjesht po shpenzon energji dhe kohë në dev/null. Dhe nuk na vjen aspak keq për këtë. Ne publikojmë gjithçka me kënaqësi të madhe dhe kuptojmë se ajo duhet të publikohet, zhvillohet, promovohet, promovohet, në mënyrë që njerëzit ta përdorin atë dhe të shtojnë përvojën e tyre - atëherë gjithçka rritet dhe jeton. Pastaj pas dy vjetësh instrumenti nuk shkon në plehra. Nuk është për të ardhur keq të vazhdosh me forcë, sepse është e qartë se dikush po përdor mjetin tënd dhe pas dy vjetësh të gjithë po e përdorin atë.
Kjo është pjesë e strategjisë sonë të madhe me dapp/werf. Nuk e mbaj mend kur kemi filluar ta bëjmë, më duket para 3 vitesh. Fillimisht, ajo ishte përgjithësisht në guaskë. Ishte një super provë e konceptit, ne zgjidhëm disa nga problemet tona të veçanta - funksionoi! Por ka probleme me guaskën, është e pamundur ta zgjerosh më tej, programimi në guaskë është një detyrë tjetër. Ne kishim një zakon të shkruanim në Ruby, në përputhje me rrethanat, ne ribërëm diçka në Ruby, zhvilluam, zhvilluam, zhvilluam dhe u përballëm me faktin se komuniteti, turma që nuk thotë "e duam ose nuk e duam", ” ia kthen hundën Ruby, sa qesharake është kjo? Kuptuam se duhet t'i shkruanim të gjitha këto gjëra në Go vetëm për të përmbushur pikën e parë në listën e kontrollit: Mjeti DevOps duhet të jetë një binar statik. Të jesh Go apo jo nuk është aq e rëndësishme, por një binar statik i shkruar në Go është më mirë.
Ne harxhuam energjinë tonë, e rishkruam dapp-in në Go dhe e quajtëm werf. Dapp nuk mbështetet më, nuk është zhvilluar, funksionon në disa versione më të fundit, por ekziston një rrugë absolute përmirësimi deri në krye dhe mund ta ndiqni.
Pse u krijua dapp?
— Mund të na thoni shkurtimisht pse u krijua dapp, çfarë problemesh zgjidh?
Dmitry: Arsyeja e parë është në kuvend. Fillimisht, ne patëm probleme serioze me ndërtimin kur Docker nuk kishte aftësi me shumë faza, kështu që ne bëmë vetë disa faza. Pastaj patëm shumë probleme të tjera me pastrimin e imazhit. Të gjithë ata që bëjnë CI/CD, herët sesa vonë, përballen me problemin se ka një mori imazhesh të mbledhura, ju duhet të pastroni disi atë që nuk është e nevojshme dhe të lini atë që nevojitet.
Arsyeja e dytë është vendosja. Po, ka Helm, por zgjidh vetëm disa nga problemet. Mjaft qesharake, është shkruar se "Helm është Menaxheri i Paketave për Kubernetes". Pikërisht çfarë "the". Ka edhe fjalët "Menaxheri i Paketave" - cila është pritshmëria e zakonshme nga një Menaxher i Paketave? Ne themi: "Menaxheri i paketës - instaloni paketën!" dhe presim që ai të na thotë: “Pakoja është dorëzuar”.
Është interesante që ne themi: "Helm, instalo paketën" dhe kur ai përgjigjet se e instaloi, rezulton se ai sapo filloi instalimin - ai tregoi Kubernetes: "Nisni këtë gjë!", dhe nëse filloi apo jo , nëse funksionon apo jo, Helm nuk e zgjidh fare këtë çështje.
Rezulton se Helm është vetëm një paraprocesor teksti që ngarkon të dhënat në Kubernetes.
Por si pjesë e çdo vendosjeje, ne duam të dimë nëse aplikacioni është lëshuar për prodhim apo jo? I hapur në prod do të thotë që aplikacioni është zhvendosur atje, versioni i ri është vendosur dhe të paktën nuk rrëzohet atje dhe përgjigjet saktë. Helm nuk e zgjidh këtë problem në asnjë mënyrë. Për ta zgjidhur atë, ju duhet të shpenzoni shumë përpjekje, sepse ju duhet t'i jepni Kubernetes komandën që të hapet dhe të monitorojë atë që po ndodh atje - nëse është vendosur apo shpërndahet. Dhe ka gjithashtu shumë detyra që lidhen me vendosjen, pastrimin dhe montimin.
Planet
Këtë vit do të fillojmë zhvillimin lokal. Ne duam të arrijmë atë që ishte më parë në Vagrant - ne shtypëm "vagrant up" dhe vendosëm makina virtuale. Ne duam të arrijmë në pikën ku ka një projekt në Git, ne shkruajmë "werf up" atje dhe ai sjell një kopje lokale të këtij projekti, të vendosur në një mini-Kub lokal, me të gjitha drejtoritë e përshtatshme për zhvillim të lidhura. . Në varësi të gjuhës së zhvillimit, kjo bëhet ndryshe, por megjithatë, në mënyrë që zhvillimi lokal të mund të kryhet me lehtësi nën skedarët e montuar.
Hapi tjetër për ne është investoni në komoditetin për zhvilluesit. Për të vendosur shpejt një projekt në nivel lokal me një mjet, zhvilloni atë, shtyjeni atë në Git dhe gjithashtu do të shpërndahet në skenë ose teste, në varësi të tubacioneve, dhe më pas përdorni të njëjtin mjet për të shkuar në prodhim. Ky unitet, bashkim, riprodhueshmëri e infrastrukturës nga mjedisi lokal deri te shitjet është një pikë shumë e rëndësishme për ne. Por kjo nuk është ende në punë - ne thjesht po planifikojmë ta bëjmë atë.
Por rruga drejt dapp/werf ka qenë gjithmonë e njëjtë si me Kubernetes në fillim. Ne hasëm probleme, i zgjidhëm ato me zgjidhje - ne dolëm me disa zgjidhje për veten tonë në guaskë, për çdo gjë. Pastaj ata u përpoqën t'i drejtojnë disi këto zgjidhje, t'i përgjithësojnë dhe konsolidojnë ato në binare në këtë rast, të cilat ne thjesht i ndajmë.
Ka një mënyrë tjetër për ta parë gjithë këtë histori, me analogji.
Kubernetes është një kornizë makine me një motor. Nuk ka dyer, xhami, radio, pemë e Krishtlindjes - asgjë fare. Vetëm korniza dhe motori. Dhe ka Helm - ky është timoni. E ftohtë - ka një timon, por ju duhet gjithashtu një kunj drejtues, raft drejtues, kuti ingranazhi dhe rrota, dhe nuk mund të bëni pa to.
Në rastin e werf, ky është një komponent tjetër për Kubernetes. Vetëm tani në versionin alfa të werf-it, për shembull, Helm është përpiluar brenda werf-it, sepse jemi lodhur ta bëjmë vetë. Ka shumë arsye për ta bërë këtë, unë do t'ju tregoj në detaje se përse kemi përpiluar të gjithë timonin së bashku me mbajtësen brenda werf-it .
Tani werf është një komponent më i integruar. Ne marrim një timon të përfunduar, një kunj timoni - Unë nuk jam shumë i mirë në makina, por ky është një bllok i madh që tashmë zgjidh një gamë mjaft të gjerë problemesh. Ne nuk kemi nevojë të kalojmë vetë katalogun, të zgjedhim një pjesë për një tjetër, të mendojmë se si t'i lidhim ato së bashku. Marrim një kombinat të gatshëm që zgjidh një numër të madh problemesh menjëherë. Por brenda tij është ndërtuar nga të njëjtët komponentë me burim të hapur, ai ende përdor Docker për montim, Helm për disa nga funksionet dhe ka disa biblioteka të tjera. Ky është një mjet i integruar për të nxjerrë CI/CD të ftohtë nga kutia shpejt dhe me lehtësi.
A është e vështirë për t'u mirëmbajtur Kubernetes?
— Ju flisni për përvojën që keni filluar të përdorni Kubernetes, kjo është një kornizë për ju, një motor dhe që mund të varni shumë gjëra të ndryshme në të: një trup, një timon, vidhos në pedale, sedilje. Shtrohet pyetja - sa e vështirë është mbështetja e Kubernetes për ju? Ju keni shumë përvojë, sa kohë dhe burime shpenzoni për të mbështetur Kubernetes të izoluar nga gjithçka tjetër?
Dmitry: Kjo është një pyetje shumë e vështirë dhe për t'iu përgjigjur, duhet të kuptojmë se çfarë është mbështetja dhe çfarë duam nga Kubernetes. Ndoshta mund të zbuloni?
— Me sa di dhe siç shoh, tani shumë ekipe duan të provojnë Kubernetes. Të gjithë mbërthehen në të, e vënë në gjunjë. Kam një ndjenjë që njerëzit jo gjithmonë e kuptojnë kompleksitetin e këtij sistemi.
Dmitry: Kështu është.
— Sa e vështirë është të marrësh dhe instalosh Kubernetes nga e para në mënyrë që të jetë gati prodhimi?
Dmitry: Sa e vështirë mendoni se është transplantimi i një zemre? E kuptoj që kjo është një pyetje komprometuese. Të përdorësh një bisturi dhe të mos bësh gabim nuk është aq e vështirë. Nëse ata ju tregojnë se ku të prisni dhe ku të qepni, atëherë vetë procedura nuk është e ndërlikuar. Është e vështirë të garantosh herë pas here se gjithçka do të funksionojë.
Instalimi i Kubernetes dhe vënia në punë e tij është e lehtë: zogth! — instaluar, ka shumë metoda instalimi. Por çfarë ndodh kur shfaqen probleme?
Gjithmonë lindin pyetje - çfarë nuk kemi marrë ende parasysh? Çfarë nuk kemi bërë akoma? Cilat parametra të kernelit Linux u specifikuan gabimisht? Zot, a i përmendëm edhe ne?! Cilët komponentë të Kubernetes kemi dorëzuar dhe cilët jo? Ngrihen mijëra pyetje dhe për t'iu përgjigjur atyre duhet të kaloni 15-20 vjet në këtë industri.
Unë kam një shembull të fundit mbi këtë temë që mund të zbulojë kuptimin e problemit "A është Kubernetes i vështirë për t'u mbajtur?" Pak kohë më parë kemi menduar seriozisht nëse duhet të përpiqemi të implementojmë Cilium si një rrjet në Kubernetes.
Më lejoni të shpjegoj se çfarë është Ciliium. Kubernetes ka shumë zbatime të ndryshme të nënsistemit të rrjetit, dhe një prej tyre është shumë i lezetshëm - Cilium. Cili është kuptimi i tij? Në kernel, disa kohë më parë u bë e mundur të shkruani grepa për kernel, të cilat në një mënyrë ose në një tjetër pushtojnë nënsistemin e rrjetit dhe nënsistemet e tjera të ndryshme dhe ju lejojnë të anashkaloni copa të mëdha në kernel.
Kerneli Linux historikisht ka një rrugëtim IP, një mbifiltër, ura dhe shumë komponentë të ndryshëm të vjetër që janë 15, 20, 30 vjeç. Në përgjithësi, ata punojnë, gjithçka është e shkëlqyeshme, por tani ata kanë grumbulluar kontejnerë, dhe duket si një kullë me 15 tulla mbi njëra-tjetrën, dhe ju qëndroni mbi të në njërën këmbë - një ndjenjë e çuditshme. Ky sistem historikisht është zhvilluar me shumë nuanca, si apendiksi në trup. Në disa situata ka probleme të performancës, për shembull.
Ekziston një BPF e mrekullueshme dhe aftësia për të shkruar grepa për kernelin - djemtë shkruan grepa për kernelin. Paketa hyn në kernel Linux, ata e nxjerrin atë pikërisht në hyrje, e përpunojnë vetë siç duhet pa urë, pa TCP, pa një pirg IP - me pak fjalë, duke anashkaluar gjithçka që është shkruar në kernel Linux, dhe më pas pështyjnë e nxjerr në enë.
Cfare ndodhi? Performancë shumë e lezetshme, veçori fantastike - thjesht interesante! Por ne e shikojmë këtë dhe shohim se në çdo makinë ka një program që lidhet me API-në Kubernetes dhe, bazuar në të dhënat që merr nga kjo API, gjeneron kodin C dhe përpilon binare që ngarkon në kernel në mënyrë që këto grepa të funksionojnë. në hapësirën e kernelit.
Çfarë ndodh nëse diçka shkon keq? Ne nuk e dimë. Për ta kuptuar këtë, ju duhet të lexoni të gjithë këtë kod, të kuptoni të gjithë logjikën dhe është e mahnitshme se sa e vështirë është. Por, nga ana tjetër, ka këto ura, filtra rrjeti, ip rut - nuk e kam lexuar kodin burimor të tyre dhe as 40 inxhinierët që punojnë në kompaninë tonë. Ndoshta vetëm pak i kuptojnë disa pjesë.
Dhe cili është ndryshimi? Rezulton se ka ip ruut, kernel Linux dhe ka një mjet të ri - çfarë ndryshimi bën, ne nuk e kuptojmë njërën apo tjetrën. Por ne kemi frikë të përdorim diçka të re - pse? Sepse nëse mjeti është 30 vjeç, atëherë në 30 vjet janë gjetur të gjitha gabimet, të gjitha gabimet janë shkelur dhe nuk keni nevojë të dini për gjithçka - funksionon si një kuti e zezë dhe funksionon gjithmonë. Të gjithë e dinë se cilën kaçavidë diagnostikuese të ngjitet në cilin vend, cili tcpdump të funksionojë në cilin moment. Të gjithë i njohin mirë shërbimet diagnostikuese dhe e kuptojnë se si funksionon ky grup përbërësish në kernelin Linux - jo si funksionon, por si ta përdorin atë.
Dhe Ciliium jashtëzakonisht i lezetshëm nuk është 30 vjeç, nuk është ende i vjetër. Kubernetes ka të njëjtin problem, kopjoni. Që Cilium është instaluar në mënyrë perfekte, se Kubernetes është instaluar në mënyrë të përsosur, por kur diçka shkon keq në prodhim, a jeni në gjendje të kuptoni shpejt në një situatë kritike se çfarë shkoi keq?
Kur themi a është e vështirë të mirëmbash Kubernetes - jo, është shumë e lehtë dhe po, është tepër e vështirë. Kubernetes funksionon mirë më vete, por me një miliardë nuanca.
Rreth qasjes "Unë do të jem me fat".
— A ka kompani ku këto nuanca janë pothuajse të garantuara të shfaqen? Supozoni se Yandex papritmas transferon të gjitha shërbimet në Kubernetes, do të ketë një ngarkesë të madhe atje.
Dmitry: Jo, kjo nuk është një bisedë për ngarkesën, por për gjërat më të thjeshta. Për shembull, ne kemi Kubernetes, ne vendosëm aplikacionin atje. Si e dini se po funksionon? Thjesht nuk ka asnjë mjet të gatshëm për të kuptuar që aplikacioni nuk po rrëzohet. Nuk ka asnjë sistem të gatshëm që dërgon sinjalizime; ju duhet t'i konfiguroni këto sinjalizime dhe çdo orar. Dhe ne po përditësojmë Kubernetes.
Unë kam Ubuntu 16.04. Mund të thuash që ky është një version i vjetër, por ne jemi ende në të sepse është LTS. Ka systemd, nuanca e së cilës është se nuk pastron grupet C. Kubernetes lëshon pods, krijon grupe C, më pas fshin pods dhe disi rezulton - nuk i mbaj mend detajet, më falni - se feta të sistemuara mbeten. Kjo çon në faktin se me kalimin e kohës, çdo makinë fillon të ngadalësohet fuqishëm. Kjo nuk është as një pyetje për ngarkesën e lartë. Nëse hapen pods të përhershëm, për shembull, nëse ka një Cron Job që gjeneron vazhdimisht pods, atëherë makina me Ubuntu 16.04 do të fillojë të ngadalësohet pas një jave. Do të ketë një mesatare të ngarkesës vazhdimisht të lartë për shkak të faktit se janë krijuar një mori grupesh C. Ky është problemi me të cilin do të përballet çdo person që thjesht instalon Ubuntu 16 dhe Kubernetes në krye.
Le të themi se ai përditëson disi systemd ose diçka tjetër, por në kernelin Linux deri në 4.16 është edhe më qesharake - kur fshini grupet C, ato rrjedhin në kernel dhe në fakt nuk fshihen. Prandaj, pas një muaji punë në këtë makinë, do të jetë e pamundur të shikosh statistikat e kujtesës për vatrat. Ne nxjerrim një skedar, e hedhim në program dhe një skedar rrotullohet për 15 sekonda, sepse kernelit i duhet një kohë shumë e gjatë për të numëruar një milion grupe C brenda vetes, të cilat duket se janë fshirë, por jo - po rrjedhin. .
Ka ende shumë gjëra të tilla të vogla aty-këtu. Kjo nuk është një çështje me të cilën kompanitë gjigante ndonjëherë mund të përballen nën ngarkesa shumë të rënda - jo, është çështje e gjërave të përditshme. Njerëzit mund të jetojnë kështu me muaj - ata instaluan Kubernetes, vendosën aplikacionin - duket se funksionon. Për shumë njerëz kjo është normale. Ata as nuk do ta dinë që ky aplikacion do të rrëzohet për ndonjë arsye, nuk do të marrin një alarm, por për ta kjo është normë. Më parë, ne jetonim në makina virtuale pa monitorim, tani u transferuam në Kubernetes, gjithashtu pa monitorim - cili është ndryshimi?
Pyetja është se kur ecim mbi akull, nuk e dimë kurrë trashësinë e tij nëse nuk e masim paraprakisht. Shumë njerëz ecin dhe mos u shqetësoni, sepse kanë ecur më parë.
Nga këndvështrimi im, nuanca dhe kompleksiteti i funksionimit të çdo sistemi është të sigurohet që trashësia e akullit të jetë saktësisht e mjaftueshme për të zgjidhur problemet tona. Kjo është ajo që ne po flasim.
Në IT, më duket, ka shumë qasje "Unë do të jem me fat". Shumë njerëz instalojnë softuer dhe përdorin biblioteka softuerësh me shpresën se do të kenë fat. Në përgjithësi, shumë njerëz janë me fat. Kjo është ndoshta arsyeja pse funksionon.
— Nga vlerësimi im pesimist, duket kështu: kur rreziqet janë të larta dhe aplikacioni duhet të funksionojë, atëherë nevojitet mbështetje nga Flaunt, ndoshta nga Red Hat, ose keni nevojë për ekipin tuaj të brendshëm të dedikuar posaçërisht për Kubernetes, i cili është gati. për ta nxjerrë atë.
Dmitry: Objektivisht, kjo është kështu. Hyrja në historinë e Kubernetes për një ekip të vogël vetë përfshin një sërë rreziqesh.
A kemi nevojë për kontejnerë?
— A mund të na thoni sa i përhapur është Kubernetes në Rusi?
Dmitry: Unë nuk i kam këto të dhëna dhe nuk jam i sigurt që i ka dikush tjetër. Ne themi: "Kubernetes, Kubernetes", por ka një mënyrë tjetër për ta parë këtë çështje. Unë gjithashtu nuk e di se sa të përhapur janë kontejnerët, por di një shifër nga raportet në internet që 70% e kontejnerëve janë të orkestruar nga Kubernetes. Ishte një burim i besueshëm për një mostër mjaft të madhe në mbarë botën.
Pastaj një pyetje tjetër - a kemi nevojë për kontejnerë? Ndjenja ime personale dhe pozicioni i përgjithshëm i kompanisë Flant është se Kubernetes është një standard de facto.
Nuk do të ketë asgjë përveç Kubernetes.
Ky është një ndryshim absolut i lojës në fushën e menaxhimit të infrastrukturës. Thjesht absolute - kjo është ajo, jo më Ansible, Shef, makina virtuale, Terraform. Nuk po flas për metodat e vjetra të fermave kolektive. Kubernetes është një ndryshues absolut, dhe tani do të jetë vetëm kështu.
Është e qartë se disave iu duhen nja dy vite, e të tjerëve nja dy dekada për ta kuptuar këtë. Nuk kam dyshim se nuk do të ketë asgjë tjetër përveç Kubernetes dhe kësaj pamjeje të re: ne nuk e dëmtojmë më sistemin operativ, por përdorim infrastruktura si kod, vetëm jo me kod, por me yml - një infrastrukturë e përshkruar në mënyrë deklarative. Kam një ndjenjë që do të jetë gjithmonë kështu.
— Kjo do të thotë, ato kompani që nuk kanë kaluar ende në Kubernetes do të kalojnë patjetër në të ose do të mbeten në harresë. te kuptova drejt?
Dmitry: Kjo gjithashtu nuk është plotësisht e vërtetë. Për shembull, nëse kemi detyrën të ekzekutojmë një server DNS, atëherë ai mund të ekzekutohet në FreeBSD 4.10 dhe mund të funksionojë në mënyrë perfekte për 20 vjet. Vetëm punoni dhe kaq. Ndoshta në 20 vjet diçka do të duhet të përditësohet një herë. Nëse po flasim për softuer në formatin që kemi nisur dhe ai në të vërtetë funksionon për shumë vite pa ndonjë përditësim, pa bërë ndryshime, atëherë, natyrisht, nuk do të ketë Kubernetes. Ai nuk është i nevojshëm atje.
Gjithçka që lidhet me CI/CD - kudo që nevojitet Dorëzimi i vazhdueshëm, ku duhet të përditësoni versionet, të bëni ndryshime aktive, kudo që keni nevojë të krijoni tolerancë ndaj gabimeve - vetëm Kubernetes.
Rreth mikroshërbimeve
- Këtu kam një disonancë të lehtë. Për të punuar me Kubernetes, keni nevojë për mbështetje të jashtme ose të brendshme - kjo është pika e parë. Së dyti, kur sapo po fillojmë zhvillimin, jemi një startup i vogël, nuk kemi ende asgjë, zhvillimi për Kubernetes ose arkitektura e mikroservisit në përgjithësi mund të jetë kompleks dhe jo gjithmonë i justifikuar ekonomikisht. Unë jam i interesuar për mendimin tuaj - a duhet që startup-et të fillojnë menjëherë të shkruajnë për Kubernetes nga e para, apo mund të shkruajnë akoma një monolit, dhe pastaj të vijnë vetëm në Kubernetes?
Dmitry: Pyetje e bukur. Unë kam një bisedë për mikroshërbimet Shumë herë kam takuar njerëz që përpiqen të godasin gozhdët me një mikroskop. Vetë qasja është e saktë; ne vetë e dizajnojmë softuerin tonë të brendshëm në këtë mënyrë. Por kur e bëni këtë, duhet të kuptoni qartë se çfarë po bëni. Fjala që urrej më shumë për mikroshërbimet është "mikro". Historikisht, kjo fjalë e ka origjinën atje, dhe për disa arsye njerëzit mendojnë se mikro është shumë i vogël, më pak se një milimetër, si një mikrometër. Kjo eshte e gabuar.
Për shembull, ekziston një monolit që është shkruar nga 300 njerëz, dhe të gjithë ata që morën pjesë në zhvillim e kuptojnë se atje ka probleme dhe duhet të ndahet në mikro-copa - rreth 10 pjesë, secila prej të cilave është shkruar nga 30 persona. në një version minimal. Kjo është e rëndësishme, e nevojshme dhe e lezetshme. Por kur na vjen një startup, ku 3 djem shumë të lezetshëm dhe të talentuar shkruanin 60 mikroshërbime në gjunjë, sa herë kërkoj Corvalol.
Më duket se për këtë është folur tashmë mijëra herë - kemi marrë një monolit të shpërndarë në një formë ose në një tjetër. Kjo nuk justifikohet ekonomikisht, është shumë e vështirë në përgjithësi në çdo gjë. Sapo e kam parë këtë kaq shumë herë sa më lëndon vërtet, kështu që vazhdoj të flas për të.
Në pyetjen fillestare, ka një konflikt midis faktit se, nga njëra anë, Kubernetes është e frikshme për t'u përdorur, sepse nuk është e qartë se çfarë mund të prishet atje ose të mos funksionojë, nga ana tjetër, është e qartë se gjithçka shkon atje. dhe asgjë përveç Kubernetes nuk do të ekzistojë. pergjigje - peshoni sasinë e përfitimit që vjen, sasinë e detyrave që mund të zgjidhni. Kjo është në njërën anë të peshores. Nga ana tjetër, ka rreziqe që lidhen me kohën e ndërprerjes ose me një ulje të kohës së përgjigjes, nivelit të disponueshmërisë - me një ulje të treguesve të performancës.
Këtu është - ose ne lëvizim shpejt, dhe Kubernetes na lejon të bëjmë shumë gjëra shumë më shpejt dhe më mirë, ose përdorim zgjidhje të besueshme, të testuara me kohë, por lëvizim shumë më ngadalë. Kjo është një zgjedhje që çdo kompani duhet të bëjë. Mund ta mendoni si një shteg në xhungël - kur ecni për herë të parë, mund të takoni një gjarpër, një tigër ose një baldo të çmendur, dhe kur keni ecur 10 herë, keni shkelur shtegun, të hequr degët dhe ecni më lehtë. Sa herë që rruga bëhet më e gjerë. Pastaj është një rrugë e asfaltuar, e më vonë një bulevard i bukur.
Kubernetes nuk qëndron ende. Pyetje përsëri: Kubernetes, nga njëra anë, është 4-5 binare, nga ana tjetër, është i gjithë ekosistemi. Ky është sistemi operativ që ne kemi në makinat tona. Çfarë është kjo? Ubuntu apo Curios? Ky është kerneli Linux, një grup komponentësh shtesë. Të gjitha këto këtu, një gjarpër helmues u hodh nga rruga, u ngrit një gardh. Kubernetes po zhvillohet shumë shpejt dhe dinamikisht, dhe vëllimi i rreziqeve, vëllimi i të panjohurës po zvogëlohet çdo muaj dhe, në përputhje me rrethanat, këto peshore po ribalancohen.
Duke iu përgjigjur pyetjes se çfarë duhet të bëjë një startup, unë do të thoja - ejani në Flaunt, paguani 150 mijë rubla dhe merrni një shërbim të lehtë DevOps me çelës në dorë. Nëse jeni një startup i vogël me pak zhvillues, kjo funksionon. Në vend që të punësoni DevOps-in tuaj, të cilët do të duhet të mësojnë se si t'i zgjidhin problemet tuaja dhe të paguajnë një pagë në këtë kohë, ju do të merrni një zgjidhje me çelës në dorë për të gjitha çështjet. Po, ka disa disavantazhe. Ne, si kontraktues, nuk mund të përfshihemi kaq shumë dhe t'u përgjigjemi shpejt ndryshimeve. Por ne kemi shumë ekspertizë dhe praktika të gatshme. Ne garantojmë që në çdo situatë ne patjetër do ta kuptojmë shpejt dhe do të ngremë çdo Kubernetes nga të vdekurit.
Unë rekomandoj fuqimisht kontraktimin e startup-eve dhe bizneseve të krijuara deri në një madhësi ku mund t'i kushtoni një ekip prej 10 personash në operacione, sepse përndryshe nuk ka asnjë pikë. Është padyshim kuptim për të transferuar këtë.
Rreth Amazon dhe Google
— A mund të konsiderohet një host nga një zgjidhje nga Amazon ose Google si një burim i jashtëm?
Dmitry: Po, sigurisht, kjo zgjidh një sërë çështjesh. Por përsëri ka nuanca. Ju ende duhet të kuptoni se si ta përdorni atë. Për shembull, ka një mijë gjëra të vogla në punën e Amazon AWS: Load Balancer duhet të ngrohet ose duhet të shkruhet paraprakisht një kërkesë që "djema, ne do të marrim trafik, ngrohni Load Balancer për ne!" Ju duhet të dini këto nuanca.
Kur ju drejtoheni njerëzve që janë të specializuar për këtë, pothuajse të gjitha gjërat tipike mbyllen. Tani kemi 40 inxhinierë, deri në fund të vitit ndoshta do të jenë 60 - patjetër i kemi hasur të gjitha këto gjëra. Edhe nëse e hasim përsëri këtë problem në ndonjë projekt, ne pyesim shpejt njëri-tjetrin dhe dimë ta zgjidhim atë.
Ndoshta përgjigjja është - sigurisht, një histori e organizuar e bën një pjesë më të lehtë. Pyetja është nëse jeni gati t'u besoni këtyre pritësve dhe nëse ata do t'i zgjidhin problemet tuaja. Amazon dhe Google kanë bërë mirë. Për të gjitha rastet tona - saktësisht. Nuk kemi më eksperienca pozitive. Të gjitha retë e tjera me të cilat u përpoqëm të punonim krijojnë shumë probleme - Ager, dhe gjithçka që është në Rusi, dhe të gjitha llojet e OpenStack në zbatime të ndryshme: Headster, Overage - çfarëdo që dëshironi. Të gjithë krijojnë probleme që ju nuk dëshironi t'i zgjidhni.
Prandaj, përgjigjja është po, por, në fakt, nuk ka shumë zgjidhje të pritura të pjekura.
Kush ka nevojë për Kubernetes?
- E megjithatë, kujt i duhet Kubernetes? Kush duhet të kalojë tashmë në Kubernetes, kush është klienti tipik Flaunt që vjen posaçërisht për Kubernetes?
Dmitry: Kjo është një pyetje interesante, sepse pikërisht tani, pas Kubernetes, shumë njerëz vijnë tek ne: "Djema, ne e dimë që po bëni Kubernetes, bëjeni për ne!" Ne u përgjigjemi atyre: "Zotërinj, ne nuk bëjmë Kubernetes, ne bëjmë nxitje dhe gjithçka që lidhet me të." Sepse aktualisht është thjesht e pamundur të bësh një produkt pa bërë të gjithë CI/CD dhe gjithë këtë histori. Të gjithë janë larguar nga ndarja që kemi zhvillim me zhvillim, e më pas shfrytëzim me shfrytëzim.
Klientët tanë presin gjëra të ndryshme, por të gjithë presin një mrekulli të mirë që kanë probleme të caktuara, dhe tani - hop! — Kubernetes do t'i zgjidhë ato. Njerëzit besojnë në mrekulli. Në mendjet e tyre ata e kuptojnë se nuk do të ketë mrekulli, por në shpirtrat e tyre ata shpresojnë - po sikur ky Kubernetes tani të zgjidhë gjithçka për ne, ata flasin aq shumë për këtë! Papritur ai tani - teshtin! - dhe një plumb argjendi, teshtin! — dhe ne kemi 100% kohë pune, të gjithë zhvilluesit mund të lëshojnë çdo gjë që hyn në prodhim 50 herë dhe nuk prishet. Në përgjithësi, një mrekulli!
Kur njerëz të tillë vijnë tek ne, ne themi: "Më falni, por nuk ka gjë të tillë si një mrekulli". Për të qenë të shëndetshëm, duhet të ushqeheni mirë dhe të ushtroheni. Për të pasur një produkt të besueshëm, ai duhet të bëhet me besueshmëri. Për të pasur një CI/CD të përshtatshme, duhet ta bëni si kjo. Kjo është shumë punë që duhet bërë.
Duke iu përgjigjur pyetjes se kujt i duhet Kubernetes - askush nuk ka nevojë për Kubernetes.
Disa njerëz kanë keqkuptimin se kanë nevojë për Kubernetes. Njerëzit kanë nevojë, ata kanë një nevojë të thellë që të ndalojnë së menduari, studimin dhe interesimin për të gjitha problemet e infrastrukturës dhe problemet e ekzekutimit të aplikacioneve të tyre. Ata duan që aplikacionet thjesht të funksionojnë dhe thjesht të vendosen. Për ta, Kubernetes është shpresa se ata do të ndalojnë së dëgjuari historinë se "ne ishim shtrirë atje", ose "nuk mund të shpërndahemi", ose diçka tjetër.
Drejtori teknik zakonisht vjen tek ne. I kërkojnë dy gjëra: nga njëra anë, na jep veçori, nga ana tjetër, stabilitet. Ne ju sugjerojmë ta merrni përsipër dhe ta bëni. Plumbi i argjendtë, ose më mirë i veshur me argjend, është se do të ndaloni së menduari për këto probleme dhe të humbni kohë. Do të keni njerëz të veçantë që do ta mbyllin këtë çështje.
Formulimi se ne ose dikush tjetër ka nevojë për Kubernetes është i pasaktë.
Administratorët kanë shumë nevojë për Kubernetes, sepse është një lodër shumë interesante me të cilën mund të luani dhe të ngatërroni. Le të jemi të sinqertë - të gjithë i pëlqejnë lodrat. Ne jemi të gjithë fëmijë diku dhe kur shohim një të re, duam ta luajmë. Për disa, kjo është dekurajuar, për shembull, në administratë, sepse ata tashmë kanë luajtur mjaftueshëm dhe tashmë janë të lodhur deri në atë pikë sa thjesht nuk duan. Por kjo nuk është plotësisht e humbur për askënd. Për shembull, nëse jam lodhur nga lodrat në fushën e administrimit të sistemit dhe DevOps për një kohë të gjatë, atëherë unë ende i dua lodrat, unë ende blej disa të reja. Të gjithë njerëzit, në një mënyrë ose në një tjetër, ende duan disa lloj lodrash.
Nuk ka nevojë të luash me prodhimin. Çfarëdo që unë rekomandoj kategorikisht të mos bëni dhe çfarë shoh tani masivisht: "Oh, një lodër e re!" — vrapuan për ta blerë, e blenë dhe: “Le ta çojmë në shkollë tani dhe t’ua tregojmë të gjithë miqve tanë”. Mos e bëj këtë. Kërkoj falje, fëmijët e mi sapo po rriten, vazhdimisht shoh diçka tek fëmijët, e vërej tek vetja dhe pastaj e përgjithësoj tek të tjerët.
Përgjigja përfundimtare është: ju nuk keni nevojë për Kubernetes. Ju duhet të zgjidhni problemet tuaja.
Ajo që mund të arrini është:
- prod nuk bie;
- edhe nëse ai përpiqet të bjerë, ne e dimë paraprakisht për këtë dhe mund të vendosim diçka në të;
- ne mund ta ndryshojmë atë me shpejtësinë me të cilën e kërkon biznesi ynë dhe mund ta bëjmë me lehtësi; nuk na shkakton asnjë problem.
Ekzistojnë dy nevoja reale: besueshmëria dhe dinamizmi/fleksibiliteti i paraqitjes. Të gjithë ata që aktualisht janë duke bërë disa lloj projektesh IT, pavarësisht se në çfarë lloj biznesi - i butë për lehtësimin e botës, dhe që e kuptojnë këtë, duhet t'i zgjidhin këto nevoja. Kubernetes me qasjen e duhur, me kuptimin e duhur dhe me përvojë të mjaftueshme ju lejon t'i zgjidhni ato.
Rreth pa server
— Nëse shikoni pak më tej në të ardhmen, atëherë duke u përpjekur të zgjidhni problemin e mungesës së dhimbjeve të kokës me infrastrukturë, me shpejtësinë e paraqitjes dhe shpejtësinë e ndryshimeve të aplikacionit, shfaqen zgjidhje të reja, për shembull, pa server. A ndjeni ndonjë potencial në këtë drejtim dhe, le të themi, një rrezik për Kubernetes dhe zgjidhje të ngjashme?
Dmitry: Këtu duhet të bëjmë përsëri një vërejtje se unë nuk jam një shikues që shikoj përpara dhe thotë - do të jetë kështu! Edhe pse thjesht bëra të njëjtën gjë. Shikoj këmbët e mia dhe shoh një sërë problemesh atje, për shembull, si funksionojnë transistorët në një kompjuter. Është qesharake, apo jo? Ne po hasim disa gabime në CPU.
Bëni pa server mjaft të besueshëm, të lirë, efikas dhe të përshtatshëm, duke zgjidhur të gjitha çështjet e ekosistemit. Këtu jam dakord me Elon Musk se nevojitet një planet i dytë për të krijuar tolerancë ndaj gabimeve për njerëzimin. Edhe pse nuk e di se çfarë thotë, e kuptoj që nuk jam gati të fluturoj vetë në Mars dhe nuk do të ndodhë nesër.
Me pa server është qartë e qartë se kjo është një gjë ideologjikisht e saktë, si toleranca e fajit për njerëzimin - të kesh dy planetë është më mirë se një. Por si ta bëjmë tani? Dërgimi i një ekspedite nuk është problem nëse i përqendroni përpjekjet tuaja në të. Dërgimi i disa ekspeditave dhe vendosja e disa mijëra njerëzve atje, mendoj se është gjithashtu realiste. Por ta bësh atë plotësisht tolerante ndaj gabimeve në mënyrë që gjysma e njerëzimit të jetojë atje, tani më duket e pamundur, duke mos u konsideruar.
Me një për një pa server: gjëja është e lezetshme, por është larg problemeve të 2019-ës. Më afër vitit 2030 - le të jetojmë për ta parë atë. Nuk kam dyshim se do të jetojmë, do të jetojmë patjetër (përsërisni para se të shkoni në shtrat), por tani duhet të zgjidhim probleme të tjera. Është si të besosh në kalin e përrallave Rainbow. Po, nja dy për qind e rasteve zgjidhen dhe zgjidhen në mënyrë perfekte, por subjektivisht, pa server është një ylber... Për mua kjo temë është shumë e largët dhe shumë e pakuptueshme. Nuk jam gati të flas. Në vitin 2019, nuk mund të shkruani një aplikacion të vetëm pa server.
Si do të evoluojë Kubernetes
— Ndërsa shkojmë drejt kësaj të ardhmeje të largët potencialisht të mrekullueshme, si mendoni se do të zhvillohen Kubernetes dhe ekosistemi përreth tij?
Dmitry: E kam menduar shumë këtë dhe e kam një përgjigje të qartë. E para është pa shtetësi - në fund të fundit, pa shtetësi është më e lehtë për t'u bërë. Kubernetes fillimisht investoi më shumë në këtë, gjithçka filloi me të. Pa shtetësi funksionon pothuajse në mënyrë të përsosur në Kubernetes, thjesht nuk ka asgjë për t'u ankuar. Ka ende shumë probleme, ose më saktë, nuanca. Gjithçka atje tashmë funksionon mirë për ne, por jemi ne. Do të duhen të paktën edhe disa vite që kjo të funksionojë për të gjithë. Ky nuk është një tregues i llogaritur, por ndjenja ime nga koka ime.
Shkurtimisht, statusfull duhet - dhe do - të zhvillohet shumë fuqishëm, sepse të gjitha aplikacionet tona ruajnë statusin; nuk ka aplikacione pa shtetësi. Ky është një iluzion; ju gjithmonë keni nevojë për një lloj databaze dhe diçka tjetër. Statefull ka të bëjë me ndreqjen e gjithçkaje që është e mundur, rregullimin e të gjitha gabimeve, përmirësimin e të gjitha problemeve që po përballen aktualisht - le ta quajmë atë adoptim.
Niveli i të panjohurës, niveli i problemeve të pazgjidhura, niveli i probabilitetit për të hasur diçka do të ulet ndjeshëm. Kjo është një histori e rëndësishme. Dhe operatorët - gjithçka që lidhet me kodifikimin e logjikës së administrimit, logjikën e kontrollit për të marrë një shërbim të lehtë: shërbimi i lehtë MySQL, shërbimi i lehtë RabbitMQ, shërbimi i lehtë Memcache - në përgjithësi, të gjithë këta komponentë që na duhen garantuar për t'i dalë jashtë kutia. Kjo thjesht zgjidh dhimbjen që duam një bazë të dhënash, por nuk duam ta administrojmë atë, ose duam Kubernetes, por nuk duam ta administrojmë atë.
Kjo histori e zhvillimit të operatorit në një formë ose në një tjetër do të jetë e rëndësishme në dy vitet e ardhshme.
Unë mendoj se lehtësia e përdorimit duhet të rritet shumë - kutia do të bëhet gjithnjë e më e zezë, gjithnjë e më e besueshme, me gjithnjë e më shumë pulla të thjeshta.
Një herë dëgjova një intervistë të vjetër me Isaac Asimov nga vitet '80 në YouTube në Saturday Night Live - një program si Urgant, vetëm interesant. E pyetën për të ardhmen e kompjuterëve. Ai tha se e ardhmja është në thjeshtësi, ashtu si radioja. Marrësi i radios ishte fillimisht një gjë komplekse. Për të kapur një valë, duhej të rrotulloje pullat për 15 minuta, të ktheje hellet dhe në përgjithësi të dish se si funksionon gjithçka, të kuptosh fizikën e transmetimit të valëve të radios. Si rezultat, mbeti vetëm një çelës në radio.
Tani në 2019 çfarë radio? Në makinë, marrësi i radios gjen të gjitha valët dhe emrat e stacioneve. Fizika e procesit nuk ka ndryshuar në 100 vjet, por lehtësia e përdorimit ka ndryshuar. Tani, dhe jo vetëm tani, tashmë në vitin 1980, kur kishte një intervistë me Azimov, të gjithë përdornin radion dhe askush nuk mendonte se si funksiononte. Gjithmonë ka funksionuar - kjo është e dhënë.
Azimov më pas tha se do të ishte e njëjta gjë me kompjuterët - lehtësia e përdorimit do të rritet. Ndërsa në vitin 1980 ju duhej të trajnoheni për të shtypur butonat në një kompjuter, kjo nuk do të jetë kështu në të ardhmen.
Kam një ndjenjë që me Kubernetes dhe me infrastrukturën do të ketë gjithashtu një rritje të madhe në lehtësinë e përdorimit. Kjo, për mendimin tim, është e qartë - qëndron në sipërfaqe.
Çfarë të bëni me inxhinierët?
— Çfarë do të ndodhë atëherë me inxhinierët dhe administratorët e sistemit që mbështesin Kubernetes?
Dmitry: Çfarë ndodhi me llogaritarin pas ardhjes së 1C? Per te njejten. Para kësaj, ata numëruan në letër - tani në program. Produktiviteti i punës është rritur me rend të madhësisë, por vetë puna nuk është zhdukur. Nëse më parë duheshin 10 inxhinierë për të futur një llambë, tani një do të mjaftojë.
Sasia e softuerit dhe numri i detyrave, më duket, tani po rritet me një ritëm më të shpejtë sesa po shfaqen DevOps të rinj dhe efikasiteti po rritet. Aktualisht ka një mungesë specifike në treg dhe do të zgjasë shumë. Më vonë, gjithçka do të kthehet në një lloj normaliteti, në të cilin efikasiteti i punës do të rritet, do të ketë gjithnjë e më shumë pa server, një neuron do t'i bashkëngjitet Kubernetes, i cili do të zgjedhë të gjitha burimet saktësisht sipas nevojës dhe në përgjithësi do bëni gjithçka vetë, siç duhet - personi thjesht largohuni dhe mos ndërhyni.
Por dikujt do t'i duhet ende të marrë vendime. Është e qartë se niveli i kualifikimeve dhe specializimit të këtij personi është më i lartë. Ne ditet e sotme ne kontabilitet nuk duhen 10 punonjes qe te mbajne libra qe te mos u lodhen duart. Thjesht nuk është e nevojshme. Shumë dokumente skanohen automatikisht dhe njihen nga sistemi elektronik i menaxhimit të dokumenteve. Mjafton një kryekontabilist i zgjuar, tashmë me aftësi shumë më të mëdha, me mirëkuptim.
Në përgjithësi, kjo është mënyra për të shkuar në të gjitha industritë. Është e njëjta gjë me makinat: më parë vinte një makinë me një mekanik dhe tre shoferë. Në ditët e sotme, drejtimi i një makine është një proces i thjeshtë në të cilin ne të gjithë marrim pjesë çdo ditë. Askush nuk mendon se një makinë është diçka e ndërlikuar.
Inxhinieria e DevOps ose e sistemeve nuk do të largohet - puna dhe efikasiteti i nivelit të lartë do të rriten.
— Kam dëgjuar edhe një ide interesante që puna realisht do të rritet.
Dmitry: Sigurisht, njëqind për qind! Sepse sasia e softuerit që shkruajmë po rritet vazhdimisht. Numri i çështjeve që ne zgjidhim me softuer po rritet vazhdimisht. Sasia e punës po rritet. Tani tregu i DevOps është jashtëzakonisht i mbinxehur. Kjo mund të shihet në pritjet e pagave. Në një mënyrë të mirë, pa hyrë në detaje, duhet të ketë të rinj që duan X, të mesëm që duan 1,5X dhe të moshuar që duan 2X. Dhe tani, nëse shikoni tregun e pagave të Moskës DevOps, një i ri dëshiron nga X në 3X dhe një i moshuar dëshiron nga X në 3X.
Askush nuk e di se sa kushton. Niveli i pagës matet me besimin tuaj - një çmendinë e plotë, për të qenë i sinqertë, një treg tmerrësisht i mbinxehur.
Sigurisht, kjo situatë do të ndryshojë shumë shpejt - duhet të ndodhë një ngopje. Ky nuk është rasti me zhvillimin e softuerit - përkundër faktit se të gjithë kanë nevojë për zhvillues, dhe të gjithë kanë nevojë për zhvillues të mirë, tregu e kupton se kush ia vlen - industria është qetësuar. Ky nuk është rasti me DevOps këto ditë.
— Nga sa dëgjova, arrita në përfundimin se administratori aktual i sistemit nuk duhet të shqetësohet shumë, por është koha të përmirësojë aftësitë e tij dhe të përgatitet për faktin se nesër do të ketë më shumë punë, por do të jetë më i kualifikuar.
Dmitry: Njeqind per qind. Në përgjithësi, ne jetojmë në 2019 dhe rregulli i jetës është ky: mësimi gjatë gjithë jetës - ne mësojmë gjatë gjithë jetës sonë. Më duket se tani të gjithë tashmë e dinë dhe e ndjejnë këtë, por nuk mjafton ta dish - duhet ta bësh. Çdo ditë ne duhet të ndryshojmë. Nëse nuk e bëjmë këtë, atëherë herët a vonë do të na lënë mënjanë profesionit.
Jini të përgatitur për kthesa të mprehta 180 gradë. Unë nuk e përjashtoj një situatë ku diçka ndryshon rrënjësisht, shpiket diçka e re - ndodh. Hop! - dhe ne tani veprojmë ndryshe. Është e rëndësishme të jeni të përgatitur për këtë dhe të mos shqetësoheni. Mund të ndodhë që nesër gjithçka që bëj do të jetë e panevojshme - asgjë, kam studiuar gjithë jetën dhe jam gati të mësoj diçka tjetër. Nuk është problem. Nuk ka pse të keni frikë nga siguria e punës, por duhet të jeni të përgatitur për të mësuar vazhdimisht diçka të re.
Urime dhe një minutë reklamë
- Keni ndonjë dëshirë?
Dmitry: Po, kam disa dëshira.
E para dhe tregtare - abonohuni në . Të nderuar lexues, shkoni në YouTube dhe abonohuni në kanalin tonë. Për rreth një muaj do të fillojmë zgjerimin aktiv të shërbimit video. Do të kemi shumë përmbajtje edukative rreth Kubernetes, të hapura dhe të ndryshme: nga gjërat praktike, deri te laboratorët, te gjërat e thella themelore teorike dhe si të përdorim Kubernetes në niveli i parimeve dhe modeleve.
Dëshira e dytë tregtare - shkoni te dhe vendosni yje sepse ne ushqehemi me to. Nëse nuk na jepni yje, nuk do të kemi asgjë për të ngrënë. Është si mana në një lojë kompjuterike. Ne bëjmë diçka, bëjmë, përpiqemi, dikush thotë se këto janë biçikleta të tmerrshme, dikush që gjithçka është krejtësisht e gabuar, por ne vazhdojmë dhe veprojmë absolutisht me ndershmëri. Ne shohim një problem, e zgjidhim atë dhe ndajmë përvojën tonë. Prandaj, na jep një yll, ai nuk do të largohet prej teje, por do të vijë tek ne, sepse ne ushqehemi me ta.
Dëshira e tretë, e rëndësishme dhe jo më tregtare - ndaloni së besuari në përralla. Ju jeni profesionistë. DevOps është një profesion shumë serioz dhe i përgjegjshëm. Ndaloni së luajturi në vendin e punës. Lëreni të klikojë për ju dhe do ta kuptoni. Imagjinoni që vini në spital dhe atje mjeku po eksperimenton me ju. Unë e kuptoj që kjo mund të jetë fyese për dikë, por, ka shumë të ngjarë, kjo nuk ka të bëjë me ju, por për dikë tjetër. Thuaju edhe të tjerëve të ndalojnë. Kjo me të vërtetë shkatërron jetën për të gjithë ne - shumë njerëz fillojnë t'i trajtojnë operacionet, administratorët dhe DevOps si tipa që kanë thyer diçka përsëri. Kjo “thyehej” më shpesh për faktin se ne shkonim të luanim dhe nuk shikonim me vetëdije të ftohtë se kështu është dhe kështu është.
Kjo nuk do të thotë që ju nuk duhet të eksperimentoni. Ne duhet të eksperimentojmë, e bëjmë vetë. Për të qenë i sinqertë, ne vetë ndonjëherë luajmë lojëra - kjo, natyrisht, është shumë e keqe, por asgjë njerëzore nuk është e huaj për ne. Le ta shpallim vitin 2019 një vit eksperimentesh serioze, të mirëmenduara dhe jo lojërash në prodhim. Ndoshta kështu.
- Faleminderit shumë!
Dmitry: Faleminderit, Vitaly, si për kohën ashtu edhe për intervistën. Të nderuar lexues, faleminderit shumë nëse keni arritur papritur në këtë pikë. Shpresoj që t'ju kemi sjellë të paktën disa mendime.
Në intervistë, Dmitry preku çështjen e werf. Tani kjo është një thikë universale zvicerane që zgjidh pothuajse të gjitha problemet. Por nuk ishte gjithmonë kështu. Aktiv në festival Dmitry Stolyarov do t'ju tregojë për këtë mjet në detaje. në raport do të ketë gjithçka: problemet dhe nuancat e fshehura të Kubernetes, opsionet për zgjidhjen e këtyre vështirësive dhe zbatimin aktual të werf në detaje. Bashkohuni me ne në 27 dhe 28 maj, ne do të krijojmë mjetet perfekte.
Burimi: www.habr.com