Aurreikuspenean Vitali Khabarov elkarrizketatu Dmitri Stolyarov (), Flant enpresaren zuzendari teknikoa eta kofundatzailea. Vitaly-k Flantek zer egiten duen galdetu zion Dmitryri, Kubernetes, ekosistemen garapenari, laguntzari buruz. Kubernetes zergatik behar den eta behar ote den eztabaidatu genuen. Eta mikrozerbitzuei buruz ere, Amazon AWS, DevOps-en “zortea izango dut” ikuspegia, Kubernetesen beraren etorkizuna, zergatik, noiz eta nola hartuko duen mundua, DevOps-en perspektibak eta zertarako prestatu behar duten ingeniariek. etorkizun distiratsua eta hurbila sinplifikazioarekin eta neurona-sareekin.
entzun podcast gisa DevOps Deflop-en - DevOps-i buruzko errusierazko podcast bat, eta behean testu bertsioa dago.
Hemen eta behean galderak egiten ditu Express42ko ingeniaria.
"Flant"-i buruz
- Kaixo Dima. Zuzendari teknikoa zara""eta bere sortzailea ere bai. Mesedez, esan iezaguzu zer egiten duen enpresak eta zertan zauden?
Dmitry: Kanpotik badirudi guztiontzat Kubernetes instalatzen eta horrekin zerbait egiten ibiltzen garen mutilak garela. Baina hori ez da egia. Linux-ekin lan egiten duen enpresa gisa hasi ginen, baina denbora luzez gure jarduera nagusia produkzioa eta karga handiko proiektuak giltza eskuan ematea izan da. Normalean azpiegitura osoa hutsetik eraikitzen dugu eta gero denbora luzez eta luzez arduratzen gara. Hori dela eta, "Flant"-ek egiten duen lan nagusia, dirua jasotzen duena, hauxe da ardura hartzea eta giltza eskuan produkzioa ezartzea.
Ni, zuzendari teknikoa eta konpainiaren sortzaileetako bat naizen aldetik, egun eta gau osoa ematen dut ekoizpenaren irisgarritasuna nola handitu, bere funtzionamendua erraztu, administratzaileen bizitza errazten eta garatzaileen bizitza atseginagoa egiten saiatzen. .
Kubernetesi buruz
- Azkenaldian Flanten erreportaje asko ikusten ari naiz eta Kubernetes-i buruz. Nola heldu zinen?
Dmitry: Askotan hitz egin dut honetaz dagoeneko, baina ez zait batere axola errepikatzea. Zuzena iruditzen zait gai hau errepikatzea, kausa eta efektuaren artean nahasmena dagoelako.
Benetan tresna bat behar genuen. Arazo askori aurre egin, borrokatu, hainbat makuluekin gainditu eta tresna baten beharra sentitu dugu. Aukera ezberdin asko ezagutu genituen, gure bizikletak eraiki eta esperientzia lortu genuen. Pixkanaka-pixkanaka Docker erabiltzen hasi ginen puntura iritsi ginen ia agertu bezain laster - 2013 inguruan. Agertu zen unean, edukiontziekin esperientzia handia genuen jada, "Docker"-en analogo bat idatzi genuen - gure makulu batzuk Python-en. Dockerren etorrerarekin, makuluak bota eta komunitateak lagundutako irtenbide fidagarri bat erabiltzea posible izan zen.
Kubernetesekin istorioa antzekoa da. Indarra hartzen hasi zenerako -guretzat hau 1.2 bertsioa da- jada bagenituen makulu mordoa bai Shell eta Chef-en, eta nolabait Docker-ekin orkestratzen saiatu ginen. Rancherri eta beste hainbat irtenbideri begira egon ginen serio, baina gero Kubernetes agertu zen, eta bertan dena egingo genukeen bezala edo hobeto inplementatzen da. Ez dago ezer kexatzeko.
Bai, bada hemen nolabaiteko inperfekzioa, bada hor nolabaiteko inperfekzioa - akats asko daude, eta 1.2, oro har, izugarria da, baina... Kubernetes eraikitzen ari den eraikin bat bezalakoa da - proiektua begiratu eta ulertzen duzu freskoa izango dela. Eraikinak orain oinarria eta bi solairu baditu, ulertzen duzu hobe dela oraindik ez mugitzea, baina softwarearekin ez dago horrelako arazorik - dagoeneko erabil dezakezu.
Ez genuen momenturik izan Kubernetes erabiltzea edo ez pentsatzea. Agertu baino askoz lehenago itxaron genuen, eta analogoak geuk sortzen saiatu ginen.
Kubernetes-i buruz
— Zuzenean sartuta al zaude Kubernetesen beraren garapenean?
Dmitry: Erdipurdikoa. Aitzitik, ekosistemaren garapenean parte hartzen dugu. Tira-eskaera kopuru jakin bat bidaltzen dugu: Prometheus-i, hainbat operadorei, Helm-i - ekosistemari. Zoritxarrez, ez naiz gai egiten dugun guztiaren jarraipena egin eta oker egon naiteke, baina ez dago gugandik igerileku bakar bat ere muinean.
— Aldi berean, zure tresna asko garatzen dituzu Kubernetesen inguruan?
Dmitry: Estrategia hau da: lehendik dagoen guztiari eskaerak ateratzen dizkiogu. Hor tira-eskaerak onartzen ez badira, guk geuk bifurkatu eta gure buildekin onartu arte biziko ditugu. Gero, upstreamera iristen denean, upstream bertsiora itzultzen gara.
Esate baterako, Prometheus operadore bat dugu, eta honekin batera eta bestera joan ginen gure muntaiaren gorako aldean ziurrenik 5 aldiz dagoeneko. Ezaugarri motaren bat behar dugu, pull request bat bidali dugu, bihar zabaldu behar dugu, baina ez dugu itxaron nahi ur gora kaleratu arte. Horren arabera, gure kabuz muntatzen dugu, gure muntaia zabaltzen dugu gure funtzioarekin, arrazoiren batengatik behar duguna, gure kluster guztietara. Orduan, adibidez, goranzko bueltan ematen digute hitzekin: “Mutilak, egin dezagun kasu orokorrago baterako”, guk, edo beste batek, bukatzen dugu, eta denborarekin bat egiten du berriro.
Dagoen guztia garatzen saiatzen gara. Elementu asko oraindik existitzen ez direnak, oraindik asmatu ez direnak edo asmatuak direnak, baina gauzatzeko astirik izan ez dutenak –egiten ari gara–. Eta ez prozesua edo bizikletaren eraikuntza industria bezala gustatzen zaigulako, tresna hau behar dugulako baizik. Askotan egiten da galdera, zergatik egin dugu hau edo bestea? Erantzuna erraza da - bai, harago joan behar izan dugulako, arazo praktikoren bat konpondu eta tula honekin konpondu dugu.
Bidea beti honelakoa da: kontu handiz bilatzen dugu eta, ogi-opilarekin trolebus bat egiteko irtenbiderik aurkitzen ez badugu, orduan gure ogia eta trolebusa egiten dugu.
Flanta tresnak
— Badakit orain Flant-ek gehigarrien operadoreak, shell operadoreak eta dapp/werf tresnak dituela. Ulertzen dudanez, hau tresna bera da enkarnazio ezberdinetan. Gainera, ulertzen dut Flaunt-en barruan hainbat tresna gehiago daudela. Hau egia da?
Dmitry: GitHub-en askoz gehiago dugu. Orain gogoratzen dudanaren arabera, egoera-mapa bat dugu: denek topatu duten Grafanaren panela. Ia bigarren artikulu guztietan aipatzen da Kubernetes Medium-en jarraipenari buruz. Ezinezkoa da laburki azaltzea zer den egoera-mapa - aparteko artikulu bat behar du, baina oso baliagarria da egoera denboran zehar kontrolatzeko, Kubernetesen askotan egoera erakutsi behar baitugu denboran zehar. LogHouse ere badugu - ClickHousen eta magia beltzan oinarritutako gauza bat da Kubernetesen erregistroak biltzeko.
Utilitate asko! Eta are gehiago izango da, aurten barne irtenbide ugari kaleratuko direlako. Gehigarrien operadorean oinarritutako oso handietatik, Kubernetesentzako gehigarri mordoa daude, ala nola instalatu behar bezala sert manager - ziurtagiriak kudeatzeko tresna, nola instalatu Prometheus osagarri mordo batekin - hauek hogei bat desberdinak dira. datuak esportatzen eta zerbait biltzen duten bitarrak, Prometheus-ek grafiko eta alerta harrigarrienak ditu. Hau guztia Kubernetes-en gehigarri sorta bat besterik ez da, kluster batean instalatuta daudenak, eta sinple izatetik fresko, sofistikatu eta automatikora bihurtzen da, zeinetan arazo asko dagoeneko konpondu diren. Bai, asko egiten dugu.
Ekosistemen garapena
"Iruditzen zait oso ekarpen handia dela tresna hau eta bere erabilera metodoak garatzeko". Gutxi gorabehera zenbat beste nork egingo luke ekosistemaren garapenean ekarpen bera?
Dmitry: Errusian, gure merkatuan jarduten duten enpresen artean, inor ez dago hurbil. Jakina, adierazpen ozena da hau, Mail eta Yandex bezalako eragile handiak daudelako; Kubernetesekin ere zerbait egiten ari dira, baina gu baino askoz gehiago egiten duten mundu osoko enpresen ekarpenera ez dira hurbiltzen. Zaila da 80 langileko Flant eta Kubernetes bakoitzeko 300 ingeniari dituen Red Hat konparatzea, oker ez banago. Zaila da konparatzea. RnD sailean 6 pertsona ditugu, ni barne, gure tresna guztiak mozten dituztenak. 6 pertsona Red Hat-eko 300 ingeniari versus - nolabait zaila da alderatzea.
- Hala ere, 6 pertsona horiek ere zerbait benetan baliagarria eta alienagarria egin dezaketenean, arazo praktiko baten aurrean daudenean eta komunitateari irtenbidea ematen diotenean - kasu interesgarria. Ulertzen dut teknologia-enpresa handietan, non Kubernetes garapen eta laguntza-talde propioa duten, printzipioz, tresna berdinak garatu daitezkeela. Hau da beraientzat garatu eta komunitateari eman daitekeenaren adibidea, Kubernetes erabiltzen duen komunitate osoari bultzada emanez.
Dmitry: Hau ziurrenik integratzailearen ezaugarri bat da, bere berezitasuna. Proiektu asko ditugu eta hainbat egoera ikusten ditugu. Guretzat balio erantsia sortzeko bide nagusia kasu hauek aztertzea da, komunak aurkitzea eta ahalik eta merkeenak egitea. Horretan aktiboki ari gara lanean. Zaila egiten zait Errusiaz eta munduaz hitz egitea, baina Kubernetesen lan egiten duten 40 DevOps ingeniari inguru ditugu enpresan. Ez dut uste Errusian Kubernetes ulertzen duten espezialista kopuru pareko bat duten enpresa asko daudenik, halakorik bada.
Lanpostuaren DevOps ingeniariari buruzko guztia ulertzen dut, denek ulertzen dute dena eta ohituta dago DevOps ingeniariei DevOps ingeniariei deitzen, ez dugu hau eztabaidatuko. 40 DevOps ingeniari harrigarri hauek egunero arazoei aurre egin eta konpontzen diete, esperientzia hau aztertzen eta orokortzen saiatzen gara. Ulertzen dugu gure barruan geratzen bada, urte batean edo biren buruan tresnak ez duela ezertarako balio, komunitateko nonbait prest egindako Tula agertuko delako. Ez du zentzurik esperientzia hau barnean pilatzea - energia eta denbora dev/null-era xurgatzea besterik ez da. Eta ez dugu batere pena ematen. Dena atsegin handiz argitaratzen dugu eta ulertzen dugu argitaratu, garatu, sustatu, sustatu behar dela, jendeak erabili eta bere esperientzia gehi dezan, gero dena hazten eta bizitzen da. Gero bi urteren buruan tresna ez da zaborrontzira joaten. Ez da pena indarra botatzen jarraitzea, argi baitago norbait zure tresna erabiltzen ari dela, eta bi urteren buruan denek erabiltzen dutela.
Hau dapp/werf-ekin dugun estrategia handiaren parte da. Ez naiz gogoratzen noiz hasi ginen egiten, duela 3 urte dirudi. Hasieran, oro har, maskorrean zegoen. Super kontzeptuaren froga bat izan zen, gure arazo partikular batzuk konpondu genituen - funtzionatu zuen! Baina shell-arekin arazoak daude, ezinezkoa da gehiago zabaltzea, shell-ean programatzea beste zeregin bat da. Ruby-n idazteko ohitura genuen, beraz, Ruby-n zerbait birsortu genuen, garatu, garatu, garatu, eta komunitateak, «nahi dugu edo ez dugu nahi» esaten ez duen jendetzarekin topo egin genuen. ” Rubyri sudurra bueltatzen dio, zein dibertigarria da hori? Gauza hauek guztiak Go-n idatzi behar genituela konturatu ginen egiaztapen-zerrendako lehen puntua betetzeko: DevOps tresnak bitar estatiko bat izan behar du. Go izatea edo ez izatea ez da hain garrantzitsua, baina Go-n idatzitako bitar estatiko bat hobe da.
Energia xahutu dugu, Go-n dapp berridatzi eta werf deitu diogu. Dapp jada ez da onartzen, ez da garatu, azken bertsio batean exekutatzen ari dena, baina erabateko eguneratze-bide bat dago goialdera, eta jarraitu dezakezu.
Zergatik sortu zen dapp?
— Esan al diguzu laburki zergatik sortu den dapp, zein arazo konpontzen dituen?
Dmitry: Lehenengo arrazoia batzarrean dago. Hasieran, eraikuntzarekin arazo larriak izan genituen Docker-ek etapa anitzeko gaitasunik ez zuenean, beraz, etapa anitzekoa egin genuen gure kabuz. Gero, arazo pila bat gehiago izan genituen irudia garbitzeko. CI/CDa egiten duen oro, lehenago baino lehenago, bildutako irudi mordoa dagoelako arazoarekin aurkitzen da, behar ez dena nolabait garbitu eta behar dena utzi behar duzu.
Bigarren arrazoia hedapena da. Bai, Helm dago, baina arazo batzuk bakarrik konpontzen ditu. Bitxia bada ere, "Helm Kubernetes-en paketeen kudeatzailea da" idatzita dago. Zehazki zer "du". "Pakete-kudeatzailea" hitzak ere badaude - zein da pakete-kudeatzaile baten ohiko itxaropena? Esaten dugu: "Pakete kudeatzailea - instalatu paketea!" eta espero dugu esango digula: «Paketea entregatu da».
Interesgarria da esaten dugula: "Helm, instalatu paketea" eta instalatu zuela erantzuten dionean, instalazioa hasi berria dela ematen du - Kubernetes-i adierazi zion: "Abian jarri gauza hau!", eta hasi zen ala ez. , funtzionatzen duen ala ez, Helm-ek ez du arazo hau batere konpontzen.
Helm Kubernetes-en datuak kargatzen dituen testu-aurreprozesadore bat besterik ez dela ematen du.
Baina edozein hedapenaren barruan, aplikazioa produkziorako kaleratu den ala ez jakin nahi dugu? Prod-era zabaldutakoak esan nahi du aplikazioa hara mugitu dela, bertsio berria zabaldu dela eta, gutxienez, ez dela bertan huts egiten eta behar bezala erantzuten duela. Helm-ek ez du arazo hau inola ere konpontzen. Hori konpontzeko, esfortzu handia egin behar duzu, Kubernetesi agindua eman behar diozulako bertan gertatzen dena zabaltzeko eta kontrolatzeko, zabaldu edo zabaldu den. Eta hedapenarekin, garbiketarekin eta muntaketarekin lotutako zeregin asko ere badaude.
Planak
Aurten tokiko garapenari ekingo diogu. Lehen Vagrant-en zegoena lortu nahi dugu: "vagrant up" idatzi genuen eta makina birtualak zabaldu genituen. Git-en proiektu bat dagoen puntura iritsi nahi dugu, hor "werf" idazten dugu, eta proiektu honen kopia lokal bat ekartzen du, tokiko mini-Kub batean zabalduta, garapenerako eroso dauden direktorio guztiak konektatuta daudela. . Garapen-lengoaiaren arabera, hori ezberdin egiten da, baina hala ere, tokiko garapena eroso egin dadin muntatutako fitxategietan.
Guretzat hurrengo urratsa da garatzaileentzako erosotasunean inbertitu. Tresna bakarrarekin proiektu bat lokalean azkar zabaltzeko, garatu, bultzatu Git-era, eta etapa edo probetara ere zabalduko da, kanalizazioen arabera, eta, ondoren, tresna bera erabili produkziora joateko. Azpiegituren batasun, bateratze, erreproduzigarritasun hori tokiko ingurunetik salmentetaraino oso puntu garrantzitsua da guretzat. Baina hau oraindik ez dago werf-ean; besterik ez dugu egiteko asmoa.
Baina dapp/werf-erako bidea beti izan da hasiera batean Kubernetesekin izandako berdina. Arazoak topatu ditugu, konponbideekin konpondu ditugu; guk geuk konponbide batzuk asmatu ditugu shellean, edozertan. Ondoren, konponbide horiek nola edo hala zuzentzen saiatu ziren, orokortu eta bitar bihurtu kasu honetan, besterik gabe partekatzen ditugunak.
Istorio hau guztia ikusteko beste modu bat dago, analogiekin.
Kubernetes motorra duen autoko marko bat da. Ez dago aterik, kristalik, irratirik, Gabonetako zuhaitzik, ezer ez. Markoa eta motorra besterik ez. Eta Helm dago - hau da bolantea. Freskoa - bolantea dago, baina bolantea, cremallera, engranaje-kutxa eta gurpilak ere behar dituzu, eta ezin duzu horiek gabe egin.
Werf-en kasuan, hau Kubernetesen beste osagai bat da. Orain bakarrik werf-en alfa bertsioan, adibidez, Helm werf-en barruan biltzen da, nekatuta gaudelako geuk egiteaz. Arrazoi asko daude horretarako, zehatz-mehatz kontatuko dizut zergatik bildu genuen lema osoa werf barruan tiller batekin. .
Orain werf osagai integratuagoa da. Amaitutako bolantea, bolantea lortzen dugu. Ez naiz oso ona autoetan, baina arazo sorta zabala konpontzen duen bloke handi bat da. Ez dugu guk geuk katalogotik pasatu behar, zati bat beste baterako hautatu, nola izorratu pentsatu. Arazo ugari aldi berean ebazten dituen prest egindako konbinazio bat lortzen dugu. Baina bere barruan kode irekiko osagai berberetatik eraikita dago, oraindik Docker erabiltzen du muntatzeko, Helm funtzionalitate batzuetarako eta beste hainbat liburutegi daude. Tresna integratua da CI/CD freskoak kutxatik azkar eta eroso ateratzeko.
Zaila al da Kubernetes mantentzea?
— Kubernetes erabiltzen hasi zinen esperientziari buruz hitz egiten duzu, hau zuretzat marko bat da, motor bat, eta hainbat gauza zintzilikatu ditzakezula: karrozeria, bolantea, pedalei torlojua, eserlekuak. Galdera sortzen da: zenbat zaila da zuretzat Kubernetes laguntza? Esperientzia handia duzu, zenbat denbora eta baliabide ematen dituzu Kubernetes gainontzeko guztiarengandik isolatuta laguntzeko?
Dmitry: Galdera oso zaila da eta erantzuteko, laguntza zer den eta Kubernetesengandik zer nahi dugun ulertu behar dugu. Agian agerian dezakezu?
— Nik dakidanez eta ikusten dudanez, orain talde askok Kubernetes probatu nahi dute. Bakoitzak bere burua aprobetxatzen du, belauniko jartzen du. Sentsazioa dut jendeak ez duela beti ulertzen sistema honen konplexutasuna.
Dmitry: Hala da.
— Zein zaila da Kubernetes hutsetik hartzea eta instalatzea, produkzio prest egon dadin?
Dmitry: Zein zaila iruditzen zaizu bihotza transplantatzea? Ulertzen dut galdera arriskutsua dela. Bisturia erabiltzea eta akatsik ez egitea ez da hain zaila. Non moztu eta non josi esaten badizute, prozedura bera ez da zaila. Zaila da behin eta berriz bermatzea dena ondo aterako dela.
Kubernetes instalatzea eta funtzionatzea erraza da: txito! — instalatuta, instalazio metodo asko daude. Baina zer gertatzen da arazoak sortzen direnean?
Galderak beti sortzen dira - zer ez dugu oraindik kontuan hartu? Zer ez dugu oraindik egin? Zein Linux kernel-parametro zehaztu ziren gaizki? Jauna, aipatu ere egin al ditugu?! Kubernetesen zein osagai entregatu ditugu eta zein ez? Milaka galdera sortzen dira, eta horiei erantzuteko, 15-20 urte eman behar dituzu industria honetan.
Azken adibide bat daukat gai honi buruz, "Kubernetes mantentzea zaila al da?" arazoaren esanahia agerian utzi dezakeena. Duela denbora pixka bat serio pentsatu genuen Cilium Kubernetesen sare gisa ezartzen saiatu behar ote ginen.
Azal dezadan zer den Cilium. Kubernetes sareko azpisistemaren inplementazio ezberdin asko ditu, eta horietako bat oso polita da: Cilium. Zein da bere esanahia? Nukleoan, duela denbora pixka bat nukleorako kakoak idaztea posible izan zen, zeinak modu batera edo bestera sareko azpisistema eta beste hainbat azpisistema inbaditzen dituztenak, eta nukleoko zati handiak saihesteko aukera ematen dutenak.
Linux kernelak historikoki ip rout bat, gainiragazkia, zubiak eta 15, 20, 30 urte dituzten hainbat osagai zahar ditu. Oro har, funtzionatzen dute, dena bikaina da, baina orain ontziak pilatu dituzte, eta bata bestearen gainean 15 adreiluko dorrea dirudi, eta hanka batean zutik jartzen zara - sentsazio arraroa. Sistema hau historikoki ñabardura askorekin garatu da, gorputzeko eranskina bezala. Zenbait egoeratan errendimendu arazoak daude, adibidez.
BPF zoragarria dago eta nukleorako amuak idazteko gaitasuna dago - mutilek beren kako propioak idatzi zituzten nukleorako. Paketea Linux nukleoan sartzen da, sarreran bertan ateratzen dute, beraiek behar bezala prozesatzen dute zubirik gabe, TCPrik gabe, IP pilarik gabe - laburbilduz, Linux nukleoan idatzitako guztia saihestuz, eta gero tu egin. atera ontzira.
Zer gertatu da? Oso errendimendu polita, ezaugarri politak - polita! Baina honi erreparatzen diogu eta ikusten dugu makina bakoitzean Kubernetes APIarekin konektatzen den programa bat dagoela eta, API horretatik jasotzen dituen datuetan oinarrituta, C kodea sortzen du eta nukleoan kargatzen dituen bitarrak konpilatzen ditu, kako hauek funtziona dezaten. nukleoaren espazioan.
Zer gertatzen da zerbait gaizki ateratzen bada? Ez dakigu. Hau ulertzeko, kode hau guztia irakurri behar duzu, logika guztia ulertu eta harrigarria da zein zaila den. Baina, bestetik, zubi hauek, sare-iragazkiak, ip rout daude - ez dut haien iturburu kodea irakurri, eta gure enpresan lan egiten duten 40 ingeniariek ere ez. Agian gutxi batzuek bakarrik ulertzen dituzte zati batzuk.
Eta zein da aldea? Ematen du ip rout dagoela, Linux nukleoa, eta tresna berri bat dagoela - zer alde egiten duen, ez dugu ulertzen bata edo bestea. Baina zerbait berria erabiltzeko beldur gara - zergatik? Tresnak 30 urte baditu, 30 urtean akats guztiak aurkitu direlako, akats guztiak zapaldu egin dira eta ez duzu dena jakin behar: kutxa beltz bat bezala funtzionatzen du eta beti funtzionatzen du. Denek daki zein diagnostiko bihurkin sartu zein lekutan, zein tcpdump zein momentutan exekutatu. Denek ongi ezagutzen dituzte diagnostiko-utilitateak eta ulertzen dute nola funtzionatzen duen osagai multzo honek Linux nukleoan - ez nola funtzionatzen duen, nola erabili baizik.
Eta Cilium izugarri politak ez ditu 30 urte, oraindik ez da zahartu. Kubernetes-ek arazo bera du, kopiatu. Cilium ezin hobeto instalatuta dagoela, Kubernetes ezin hobeto instalatuta dagoela, baina ekoizpenean zerbait gaizki doanean, gai al zara egoera kritiko batean zer gertatu den gaizki ulertzeko?
Kubernetes mantentzea zaila den esaten dugunean - ez, oso erraza da, eta bai, izugarri zaila da. Kubernetesek bere kabuz bikain funtzionatzen du, baina mila milioi ñabardurarekin.
"Zortea izango dut" ikuspegiari buruz
— Ba al dago ñabardura horiek agertzea ia bermatuta dagoen enpresarik? Demagun Yandex-ek bat-batean zerbitzu guztiak Kubernetesera transferitzen dituela, karga handia egongo da bertan.
Dmitry: Ez, hau ez da kargari buruzko elkarrizketa bat, gauza sinpleenei buruzkoa baizik. Adibidez, Kubernetes dugu, aplikazioa bertan zabaldu dugu. Nola dakizu funtzionatzen ari dela? Ez dago prest egindako tresnarik aplikazioa huts egiten ari ez dela ulertzeko. Ez dago alertak bidaltzen dituen prest egindako sistemarik; alerta hauek eta ordutegi bakoitza konfiguratu behar dituzu. Eta Kubernetes eguneratzen ari gara.
Ubuntu 16.04 dut. Bertsio zaharra dela esan dezakezu, baina oraindik horretan gaude LTS delako. Systemd dago, zeinaren ñabardura ez duela C-taldeak garbitzen. Kubernetes-ek lekak abiarazten ditu, C-taldeak sortzen ditu, gero lekak ezabatzen ditu eta, nolabait, ikusten da - ez ditut xehetasunak gogoratzen, barkatu - systemd xerrak geratzen direla. Horrek denborarekin edozein auto moteltzen hasten dela dakar. Hau ez da karga altuari buruzko galdera bat ere. Leka iraunkorrak abiarazten badira, adibidez, etengabe lekak sortzen dituen Cron Job bat badago, Ubuntu 16.04 duen makina astebeteren buruan moteltzen hasiko da. Etengabe kargaren batez bestekoa izango da C-talde mordo bat sortu delako. Hau da Ubuntu 16 eta Kubernetes gainean instalatu besterik ez duen edozein pertsonak aurre egingo dion arazoa.
Demagun, nolabait, systemd edo beste zerbait eguneratzen duela, baina Linux nukleoan 4.16ra arte are dibertigarriagoa da - C-taldeak ezabatzen dituzunean, nukleoan filtratzen dira eta ez dira benetan ezabatzen. Horregatik, hilabete bat makina honetan lanean aritu ondoren, ezinezkoa izango da sutegietako memoria-estatistikak begiratu. Fitxategi bat ateratzen dugu, programan botatzen dugu eta fitxategi bat 15 segundoz ateratzen da, nukleoak denbora asko behar baitu bere baitan milioi bat C-talde kontatzeko, ezabatu egiten direla dirudite, baina ez - ihes egiten ari dira. .
Oraindik horrelako gauza txiki asko daude han eta hemen. Hau ez da enpresa erraldoiek batzuetan karga astunekin aurre egin dezaketen arazoa - ez, eguneroko gauzen kontua da. Jendea horrela bizi daiteke hilabetez - Kubernetes instalatu zuten, aplikazioa zabaldu zuten - funtzionatzen duela dirudi. Jende askorentzat hau normala da. Aplikazio hau arrazoiren batengatik huts egingo denik ere ez dute jakingo, ez dute alertarik jasoko, baina haientzat hau da normala. Lehen, monitorizaziorik gabe makina birtualetan bizi ginen, orain Kubernetesera joan ginen, monitorizaziorik gabe ere - zein da aldea?
Kontua da izotz gainean ibiltzen garenean ez dugula inoiz haren lodiera ezagutzen aldez aurretik neurtzen ez badugu. Jende asko ibiltzen da eta ez kezkatu, aurretik ibili baita.
Nire ikuspuntutik, edozein sistema ustiatzearen ñabardura eta konplexutasuna izotzaren lodiera gure arazoak konpontzeko zehatz-mehatz nahikoa dela ziurtatzea da. Honetaz ari gara.
IT-n, iruditzen zait, “zortea izango dut” planteamendu gehiegi daudela. Jende askok softwarea instalatzen du eta software liburutegiak erabiltzen ditu zortea izango duten itxaropenarekin. Oro har, jende askok zortea du. Horregatik funtzionatzen du ziurrenik.
— Nire balorazio ezkorren arabera, honela ikusten da: arriskuak handiak direnean eta aplikazioak funtzionatu behar duenean, orduan Flaunt-en laguntza behar da, agian Red Hat-en, edo zure barne-taldea behar duzu Kubernetesera bereziki dedikatuta, prest dagoena. ateratzeko.
Dmitry: Objektiboki, hala da. Kubernetesen istorioan talde txiki baten kabuz sartzeak hainbat arrisku dakartza.
Ontziak behar ditugu?
— Esango al diguzu nola hedatuta dagoen Kubernetes Errusian?
Dmitry: Ez daukat datu hau, eta ez nago ziur beste inork duenik. Guk esaten dugu: “Kubernetes, Kubernetes”, baina badago gai honi begiratzeko beste modu bat. Ez dakit edukiontziak ere zenbateraino hedatuta dauden, baina Interneten dauden txostenen datuen arabera badakit edukiontzien %70 Kubernetesek orkestratzen duela. Mundu osoko lagin nahiko handi baterako iturri fidagarria izan zen.
Orduan beste galdera bat: edukiontziak behar ditugu? Nire sentimendu pertsonala eta Flant konpainiaren posizio orokorra Kubernetes de facto estandarra dela da.
Kubernetes baino ez da egongo.
Hau erabateko aldaketa da azpiegituren kudeaketaren arloan. Absolutua - hori da, ez gehiago Ansible, Chef, makina birtualak, Terraform. Ez naiz baserri kolektiboko metodo zaharrez ari. Kubernetes erabateko aldatzailea da, eta orain horrela bakarrik izango da.
Argi dago batzuentzat urte pare bat behar direla, eta beste batzuentzat, hamarkada pare bat, horretaz jabetzeko. Ez dut zalantzarik Kubernetes eta itxura berri hau baino ez dela egongo: jada ez dugu sistema eragilea kaltetzen, baizik eta azpiegitura kode gisa, bakarrik ez kodearekin, baizik eta ymlrekin - deklaratiboki deskribatutako azpiegitura bat. Sentsazioa dut beti horrela izango dela.
— Hau da, oraindik Kubernetesera aldatu ez diren enpresa horiek behin betiko horretara aldatuko dira edo ahanzturan geratuko dira. Ondo ulertu zaitut?
Dmitry: Hau ere ez da guztiz egia. Adibidez, DNS zerbitzari bat exekutatzeko zeregina badugu, orduan FreeBSD 4.10-n exekutatu daiteke eta 20 urtez primeran funtziona dezake. Lan egin eta kitto. Agian 20 urte barru zerbait eguneratu beharko da behin. Abian jarri genuen formatuan dagoen softwareaz ari bagara eta benetan urte askotan funtzionatzen badu inolako eguneratzerik gabe, aldaketarik egin gabe, orduan, noski, ez da Kubernetesik egongo. Han ez da behar.
CI/CDarekin erlazionatutako guztia - Etengabeko Entrega behar den tokian, bertsioak eguneratu behar dituzun tokietan, aldaketa aktiboak egin behar dituzun tokian, akatsen tolerantzia sortu behar duzun tokian - Kubernetes bakarrik.
Mikrozerbitzuei buruz
- Hemen daukat disonantzia apur bat. Kubernetesekin lan egiteko, kanpoko edo barneko laguntza behar duzu - hau da lehen puntua. Bigarrenik, garatzen hasi berri garenean, startup txiki bat gara, oraindik ez dugu ezer, Kubernetes edo, oro har, mikrozerbitzuen arkitekturaren garapena konplexua izan daiteke eta ez beti ekonomikoki justifikatua. Zure iritzia interesatzen zait: startup-ek berehala hasi behar al dute hutsetik Kubernetes-erako idazten, edo oraindik ere monolito bat idatz dezakete eta gero Kubernetesera bakarrik etorri?
Dmitry: Galdera polita. Mikrozerbitzuei buruz hitz egin dut Askotan topatu izan dut mikroskopioarekin iltzeak mailutzen saiatzen ari den jendea. Planteamendua bera zuzena da; guk geuk diseinatzen dugu gure barne softwarea horrela. Baina hori egiten duzunean, argi ulertu behar duzu zer egiten ari zaren. Mikrozerbitzuei buruz gehien gorroto dudan hitza "mikro" da. Historikoki, hitz hau hor sortu zen, eta arrazoiren batengatik jendeak uste du mikroa oso txikia dela, milimetro bat baino gutxiago, mikrometroa bezalakoa. Hau gaizki dago.
Esate baterako, 300 lagunek idatzitako monolito bat dago, eta garapenean parte hartu duten guztiek ulertzen dute bertan arazoak daudela, eta mikro zatitan zatitu behar da - 10 bat pieza, horietako bakoitza 30 pertsonak idatzita. gutxieneko bertsioan. Hau garrantzitsua, beharrezkoa eta polita da. Baina startup bat etortzen zaigunean, non 3 mutil oso politak eta talentudunak belauniko 60 mikrozerbitzu idatzi zituzten, Corvalol bilatzen dudan bakoitzean.
Iruditzen zait honetaz milaka aldiz hitz egin dela dagoeneko: era batean edo bestean banatutako monolito bat lortu genuen. Hau ez dago ekonomikoki justifikatuta, oro har oso zaila da denetan. Hainbeste aldiz ikusi dut hori benetan min ematen didala, hortaz hitz egiten jarraitzen dut.
Hasierako galderari dagokionez, gatazka bat dago, batetik, Kubernetes erabiltzeko beldurra ematen duelako, ez baitago argi zer apur daitekeen edo ez funtzionatuko duen, bestetik, argi dago dena hor doala. eta Kubernetes baino ez da existituko . Erantzuna - haztatu zenbat onura ateratzen den, ebatzi ditzakezun zereginen kopurua. Hau eskalaren alde batean dago. Bestalde, geldialdi-denborarekin edo erantzun-denbora, erabilgarritasun-maila gutxitzearekin lotutako arriskuak daude, errendimendu-adierazleen jaitsierarekin.
Hona hemen: edo azkar mugitzen gara eta Kubernetes-ek gauza asko askoz azkarrago eta hobeto egiteko aukera ematen digu, edo denboran frogatutako irtenbide fidagarriak erabiltzen ditugu, baina askoz astiroago mugitzen gara. Hau enpresa bakoitzak egin behar duen aukera da. Oihaneko bide bat dela pentsa dezakezu: lehen aldiz ibiltzen zarenean, suge batekin, tigre batekin edo azkonar ero batekin topa zaitezke, eta 10 aldiz ibili zarenean, bidea zapaldu, kendu adarrak eta errazago ibili. Bidea zabaltzen doa bakoitzean. Gero asfaltozko bide bat da, eta gero bulebar ederra.
Kubernetes ez dago geldirik. Galdera berriro: Kubernetes, alde batetik, 4-5 bitar da, bestetik, ekosistema osoa da. Hau da gure makinetan dugun sistema eragilea. Zer da hau? Ubuntu edo Curios? Hau Linux nukleoa da, osagai osagarri mordoa. Hemen gauza hauek guztiak, suge pozoitsu bat errepidetik bota zuten, han hesi bat jarri zuten. Kubernetes oso azkar eta dinamikoki garatzen ari da, eta arriskuen bolumena, ezezagunaren bolumena gutxitzen ari da hilero eta, horren arabera, eskala horiek berriro orekatzen ari dira.
Startup batek zer egin behar duen galderari erantzunez, esango nuke: etorri Flaunt-era, ordaindu 150 mila errublo eta lortu DevOps zerbitzu erraza giltza eskura. Garatzaile gutxi dituen startup txikia bazara, honek funtzionatzen du. Zure DevOps-a kontratatu beharrean, zure arazoak konpontzen eta soldata bat ordaintzen ikasi beharko duena une honetan, arazo guztientzat giltza eskuan konponbidea lortuko duzu. Bai, desabantaila batzuk daude. Gu, azpikontratatzaile gisa, ezin dugu hain inplikatu eta aldaketei azkar erantzun. Baina espezializazio eta praktikak prest ditugu. Edozein egoeratan behin betiko azkar asmatuko dugula eta edozein Kubernetes hilen artetik altxatuko dugula bermatzen dugu.
Biziki gomendatzen dut startup-ei eta enpresa finkatuei azpikontratatzea, non 10 laguneko talde bat operazioetara dedikatu ahal izateko, bestela ez baitu ezertarako balio. Zalantzarik gabe, zentzuzkoa da hau azpikontratatzea.
Amazon eta Googleri buruz
— Amazon edo Google-ren irtenbide bateko ostalari bat azpikontrataziotzat har al daiteke?
Dmitry: Bai, noski, honek hainbat arazo konpontzen ditu. Baina berriro ere ñabardurak daude. Oraindik ulertu behar duzu nola erabili. Esaterako, mila gauza txiki daude Amazon AWSren lanean: Load Balancer berotu egin behar da edo aldez aurretik eskaera bat idatzi behar da: "Mutilak, trafikoa jasoko dugu, berotu Load Balancer guretzat!" ñabardura hauek ezagutu behar dituzu.
Horretan espezializatutako jendearengana jotzen duzunean, ohiko gauza ia guztiak ixten dituzu. Orain 40 ingeniari ditugu, urte amaierarako ziurrenik 60 izango dira, zalantzarik gabe, gauza hauek guztiak topatu ditugu. Proiekturen batean arazo honekin berriro topatzen badugu ere, azkar elkarri galdetzen diogu eta badakigu nola konpondu.
Seguruenik erantzuna da: noski, ostatutako istorio batek zatiren bat errazten du. Kontua da ea prest zauden ostalari hauek fidatzeko eta zure arazoak konponduko dituzten ala ez. Amazonek eta Googlek ondo egin dute. Gure kasu guztietarako - zehazki. Ez dugu esperientzia positibo gehiagorik. Lan egiten saiatu garen beste hodei guztiek arazo asko sortzen dituzte - Ager, eta Errusian dagoen guztia, eta OpenStack mota guztietako inplementazio desberdinetan: Headster, Overage - nahi duzuna. Guztiek konpondu nahi ez dituzun arazoak sortzen dituzte.
Hori dela eta, erantzuna baiezkoa da, baina, egia esan, ez dago ostatatutako irtenbide heldu asko.
Nork behar du Kubernetes?
— Eta hala ere, nork behar du Kubernetes? Nork aldatu beharko luke dagoeneko Kubernetesera, nor da Kubernetes-era bereziki datorren Flaunt bezero tipikoa?
Dmitry: Galdera interesgarria da, oraintxe bertan, Kubernetesen harira, jende asko etortzen baita guregana: "Mutilak, badakigu Kubernetes egiten ari zarela, egin ezazu guregatik!" Guk erantzuten diegu: "Jaunak, ez dugu Kubernetes egiten, prod eta horrekin lotutako guztia egiten dugu". Gaur egun ezinezkoa baita produktu bat egitea CI/CD eta istorio guztia egin gabe. Denek aldendu egin dute garapenaren araberako garapena, eta gero esplotazioan ustiapena, daukagun zatiketatik.
Gure bezeroek gauza desberdinak espero dituzte, baina denek arazo jakin batzuk dituztelako mirari on bat espero dute, eta orain - hop! — Kubernetes-ek konponduko ditu. Jendeak mirarietan sinesten du. Haien buruan ulertzen dute ez dela miraririk izango, baina beren ariman itxaropena dute: zer gertatzen da orain Kubernetes honek dena konponduko badigu, hainbeste hitz egiten dute horretaz! Bat-batean orain - doministiku egin! - eta zilarrezko bala, doministiku! — eta % 100eko funtzionamendua dugu, garatzaile guztiek 50 aldiz askatu dezakete produkzioan sartzen dena, eta ez da huts egiten. Oro har, miraria!
Horrelako pertsonak guregana etortzen direnean, esaten dugu: "Barkatu, baina ez dago miraririk". Osasuntsu egoteko, ondo jan eta ariketa fisikoa egin behar duzu. Produktu fidagarria izateko, fidagarritasunez egin behar da. CI/CD erosoa izateko, honela egin behar duzu. Hori da egin beharreko lan handia.
Kubernetes nork behar duen galderari erantzunez - inork ez du Kubernetes behar.
Batzuek uste okerra dute Kubernetes behar dutela. Jendeak behar du, behar sakona du pentsatzeari, ikasteari eta interesatzeari uzteko azpiegituren arazo eta aplikazioak martxan jartzeko arazo guztietan. Aplikazioak soilik funtzionatzea eta zabaltzea nahi dute. Haientzat, Kubernetes itxaropena da "hor etzanda geunden" edo "ezin dugu zabaldu" edo beste zerbait entzuteari utziko diotela.
Zuzendari teknikoa etortzen zaigu normalean. Bi gauza eskatzen dizkiote: batetik, ezaugarriak ematea, bestetik, egonkortasuna. Zure gain hartzea eta egitea proposatzen dizugu. Zilarrezko bala, edo hobeto esanda, zilarreztatua, arazo hauetan pentsatzeari eta denbora galtzeari utziko diozu. Jende berezia izango duzu gai hau itxiko duena.
Guk edo beste edonork Kubernetes behar dugun hitza ez da zuzena.
Administratzaileek benetan behar dute Kubernetes, oso jostailu interesgarria baita, jolastu eta moldatu dezakezun. Izan gaitezen zintzoak - denek maite dituzte jostailuak. Denok haurrak gara nonbait, eta berri bat ikusten dugunean, jolastu nahi dugu. Batzuentzat hori desanimatu egin da, adibidez, administrazioan, nahikoa jokatu dutelako eta dagoeneko nekatuta daudelako besterik nahi ez duten punturaino. Baina hori ez da inori guztiz galtzen. Adibidez, sistema-administrazioaren eta DevOps-en alorrean jostailuekin nekatuta egon banaiz denbora luzez, orduan oraindik maite ditut jostailuak, oraindik ere berriak erosten ditut. Jende guztiek, nola edo hala, jostailu motaren bat nahi dute oraindik.
Ez dago ekoizpenarekin jolastu beharrik. Ez egitea gomendatzen dudana eta orain masiboki ikusten dudana: "Oh, jostailu berria!" — Korrika erostera, erosi eta: «Eraman dezagun orain eskolara eta erakutsiko diegu gure lagun guztiei». Ez egin hau. Barkamena eskatzen dut, nire seme-alabak hazten ari dira, umeengan etengabe ikusten dut zerbait, neure baitan nabaritzen dut eta gero besteei orokortu egiten diet.
Azken erantzuna hau da: ez duzu Kubernetes behar. Zure arazoak konpondu behar dituzu.
Lor dezakezuna hau da:
- prod ez da erortzen;
- erortzen saiatzen bada ere, aldez aurretik badakigu, eta zerbait jar dezakegu;
- gure negozioak eskatzen duen abiaduran alda dezakegu, eta eroso egin dezakegu; ez digu arazorik sortzen.
Benetako bi behar dira: fidagarritasuna eta hedapenaren dinamismoa/malgutasuna. Gaur egun informatika-proiekturen bat egiten ari diren guztiek, edozein negozio motatan, mundua arintzeko biguna, eta hori ulertzen dutenek, behar horiek konpondu behar dituzte. Ikuspegi egokiarekin, ulermen egokiarekin eta esperientzia nahikoarekin Kubernetes-ek horiek konpontzeko aukera ematen dizu.
Zerbitzaririk gabekoari buruz
— Etorkizunera apur bat gehiago begiratzen baduzu, orduan azpiegiturarekin buruhausterik ezaren arazoa konpontzen saiatuz, zabaltze-abiadurarekin eta aplikazio-aldaketen abiadurarekin, irtenbide berriak agertzen dira, adibidez, zerbitzaririk gabekoak. Norabide horretan potentzial bat sentitzen al duzu eta, demagun, arriskurik Kubernetes eta antzeko irtenbideentzat?
Dmitry: Hemen berriro ohar bat egin behar dugu ez naizela aurrera begiratzen duen igarlea eta esaten duena - horrela izango da! Nik gauza bera egin nuen arren. Oinetara begiratu eta arazo mordoa ikusten dut han, adibidez, transistoreek ordenagailu batean nola funtzionatzen duten. Dibertigarria da, ezta? CPUan akats batzuk aurkitzen ari gara.
Egin zerbitzaririk gabe nahiko fidagarria, merkea, eraginkorra eta erosoa, ekosistemen arazo guztiak konponduz. Hemen ados nago Elon Muskekin bigarren planeta bat behar dela gizateriaren akatsen tolerantzia sortzeko. Zer esaten duen ez dakidan arren, ulertzen dut ez nagoela prest Martera hegan egiteko eta bihar ez dela gertatuko.
Zerbitzaririk gabe argi dago hori ideologikoki zuzena dela, gizateriaren akatsen tolerantzia bezalakoa: bi planeta edukitzea bat baino hobea da. Baina nola egin orain? Espedizio bat bidaltzea ez da arazoa zure ahaleginak horretan kontzentratuz gero. Hainbat espedizio bidaltzea eta hainbat mila lagun bertan finkatzea ere errealista dela uste dut. Baina guztiz erresistentea izan dadin gizateriaren erdia bertan bizi dadin, orain ezinezkoa iruditzen zait, kontuan ez hartzea.
Zerbitzaririk gabeko bat-batean: gauza polita da, baina 2019ko arazoetatik urrun dago. 2030etik gertuago - bizi gaitezen ikusteko. Ez dut dudarik biziko garela, behin betiko biziko gara (errepikatu oheratu aurretik), baina orain beste arazo batzuk konpondu behar ditugu. Rainbow maitagarrien ipuineko ponian sinestea bezalakoa da. Bai, kasuen ehuneko pare bat konpontzen dira, eta primeran konpontzen dira, baina subjektiboki, zerbitzaririk gabeko ortzadarra da... Niretzat gai hau urrunegia eta ulertezina da. Ez nago prest hitz egiteko. 2019an, ezin duzu aplikazio bakar bat idatzi zerbitzaririk gabe.
Kubernetes-ek nola eboluzionatuko duen
— Etorkizun urrun potentzial zoragarri honetara goazen heinean, nola uste duzu garatuko direla Kubernetes eta bere inguruko ekosistema?
Dmitry: Asko pentsatu dut honetan eta argi daukat erantzuna. Lehena egoera osoa da; azken finean, estaturik gabekoa errazagoa da. Kubernetes-ek hasieran gehiago inbertitu zuen honetan, dena hasi zen. Estaturik gabekoak ia ezin hobeto funtzionatzen du Kubernetesen, ez dago ezer kexatzeko. Oraindik arazo asko daude, edo hobeto esanda, ñabardurak. Dagoeneko han dena oso ondo dabil guretzat, baina hori gu gara. Gutxienez urte pare bat gehiago beharko dira guztiontzat funtzionatzeko. Hau ez da kalkulatutako adierazle bat, nire buruaren sentsazioa baizik.
Laburbilduz, statefull-ak oso indartsu garatu beharko luke eta garatuko da, gure aplikazio guztiek egoera gordetzen dutelako; ez dago estaturik gabeko aplikaziorik. Hau ilusio bat da; beti behar duzu datu-base bat eta beste zerbait. Statefull-ek posible den guztia zuzentzea da, akats guztiak konpontzea, gaur egun jasaten ari diren arazo guztiak hobetzea - dei diezaiogun adopzioa.
Ezezagunaren maila, konpondu gabeko arazoen maila, zerbaitekin topo egiteko probabilitatea nabarmen jaitsiko da. Hau istorio garrantzitsua da. Eta operadoreak -administrazio-logikaren kodifikazioarekin zerikusia duen guztia, zerbitzu erraza lortzeko kontrol-logika: MySQL zerbitzu erraza, RabbitMQ zerbitzu erraza, Memcache zerbitzu erraza - oro har, bermatu behar ditugun osagai horiek guztiak. kutxa. Horrek datu-base bat nahi dugun mina konpontzen du, baina ez dugu administratu nahi, edo Kubernetes nahi dugu, baina ez dugu administratu nahi.
Era batean edo bestean operadoreen garapenaren istorio hau garrantzitsua izango da hurrengo urteetan.
Erabilera erraztasuna asko handitu beharko litzatekeela uste dut - kutxa gero eta beltzagoa izango da, gero eta fidagarriagoa, gero eta botoi sinpleagoekin.
80ko hamarkadako Isaac Asimov-i egindako elkarrizketa zahar bat entzun nuen behin YouTube-n Saturday Night Live -n Urgant bezalako programa bat, interesgarria baino ez. Ordenagailuen etorkizunaz galdetu zioten. Etorkizuna sinpletasunean dagoela esan zuen, irratia bezala. Irrati-hargailua hasiera batean gauza konplexua zen. Olatu bat harrapatzeko, 15 minutuz botoiak biratu behar ziren, pintxoei buelta eman eta, oro har, dena nola funtzionatzen duen jakin, irrati-uhinen transmisioaren fisika ulertu. Ondorioz, botoi bakarra geratzen zen irratian.
Orain 2019an zein irrati? Autoan, irrati hartzaileak uhin guztiak eta estazioen izenak aurkitzen ditu. Prozesuaren fisika ez da aldatu 100 urtean, baina erabiltzeko erraztasuna bai. Orain, eta ez orain bakarrik, jada 1980an, Azimov-i elkarrizketa bat zegoenean, denek erabiltzen zuten irratia eta inork ez zuen pentsatu nola funtzionatzen zuen. Beti funtzionatu zuen, hori da.
Orduan Azimovek esan zuen ordenagailuekin berdina izango zela - erabiltzeko erraztasuna areagotu egingo da. 1980an ordenagailu bateko botoiak sakatzen trebatu behar bazinen ere, etorkizunean ez da horrela izango.
Kubernetesekin eta azpiegiturekin ere erabilera-erraztasuna izugarri handituko dela uste dut. Hau, nire ustez, begi-bistakoa da - azalean dago.
Zer egin ingeniariekin?
— Zer gertatuko da orduan Kubernetes onartzen duten ingeniari eta sistema-administratzaileekin?
Dmitry: Zer gertatu zitzaion kontulariari 1C-ren etorreraren ostean? Berdin buruz. Aurretik, paperean kontatzen zuten -orain programan-. Lanaren produktibitatea mailaz handitu da, baina lana bera ez da desagertu. Lehen 10 ingeniari behar baziren bonbilla bat izorratzeko, orain bat nahikoa izango da.
Software-kopurua eta zeregin-kopurua, iruditzen zait, orain DevOps berriak agertzen diren baino abiadura handiagoan hazten ari da eta eraginkortasuna handitzen ari da. Merkatuan gabezia zehatz bat dago orain eta denbora luzez iraungo du. Geroago, dena nolabaiteko normaltasunera itzuliko da, eta bertan lanaren eraginkortasuna handituko da, gero eta zerbitzaririk gabeko gehiago egongo da, Kubernetes-i neurona bat erantsiko zaio, baliabide guztiak behar bezala hautatuko dituena, eta, oro har, egin dena bera, behar den bezala - pertsona aldendu eta ez oztopatu.
Baina oraindik norbaitek erabakiak hartu beharko ditu. Argi dago pertsona horren kualifikazio eta espezializazio maila altuagoa dela. Gaur egun, kontabilitate sailean, ez da behar 10 langile liburuak gordetzea, eskuak nekatu ez daitezen. Besterik gabe, ez da beharrezkoa. Dokumentu asko automatikoki eskaneatu eta aitortzen ditu dokumentu elektronikoen kudeaketa sistemak. Kontulari buru adimendun bat nahikoa da, dagoeneko askoz trebetasun handiagoarekin, ulermen ona duena.
Oro har, hau da industria guztietan egin beharreko bidea. Berdin gertatzen da kotxeekin: lehenago, kotxe bat zetorren mekanikari batekin eta hiru gidarirekin. Gaur egun, autoa gidatzea prozesu sinple bat da, eta denok egunero parte hartzen dugu. Inork ez du uste auto bat zerbait konplikatua denik.
DevOps edo sistemen ingeniaritza ez da desagertuko; goi-mailako lana eta eraginkortasuna handituko dira.
— Ideia interesgarri bat ere entzun nuen lana benetan handituko dela.
Dmitry: Noski, ehuneko ehun! Idazten dugun software kopurua etengabe hazten ari delako. Softwarearekin konpontzen ditugun arazoen kopurua etengabe hazten ari da. Lan kopurua hazten ari da. Orain DevOps merkatua izugarri berotuta dago. Hau soldata itxaropenetan ikus daiteke. Modu onean, xehetasunetan sartu gabe, X nahi duten juniorrak, 1,5X nahi duten ertainak eta 2X nahi duten seniorrak egon beharko lirateke. Eta orain, Moskuko DevOps soldata-merkatuari erreparatuz gero, junior batek X-tik 3X-ra nahi du eta senior batek X-tik 3X-ra.
Inork ez daki zenbat balio duen. Soldata-maila zure konfiantzaren arabera neurtzen da - eroetxe osoa, egia esan, izugarri berotutako merkatua.
Jakina, egoera hau oso laster aldatuko da - saturazio batzuk gertatu beharko lirateke. Hau ez da software garapenaren kasua - denek garatzaileak behar dituzten arren, eta denek garatzaile onak behar dituzten arren, merkatuak ulertzen du nork balio duen zertarako - industria finkatu egin da. Hori ez da DevOps-en kasua egun.
— Entzun dudanaren arabera, ondorioztatu dut egungo sistemaren administratzaileak ez duela gehiegi kezkatu behar, baina bere gaitasunak berritzeko garaia da eta bihar lan gehiago egongo dela prestatzeko, baina kualifikazio handiagokoa izango dela.
Dmitry: ehuneko ehun. Oro har, 2019an bizi gara eta bizi-araua hau da: bizitza osorako ikaskuntza - gure bizitzan zehar ikasten dugu. Iruditzen zait orain denek dakitela eta sentitzen dutela hori, baina ez da nahikoa jakitea - egin behar duzu. Egunero aldatu behar dugu. Hori egiten ez badugu, lehenago edo beranduago lanbidearen alboan utziko gaituzte.
Presta zaitez 180 graduko bira zorrotzetarako. Ez dut baztertzen zerbait errotik aldatzen den egoera bat, zerbait berria asmatzen den - gertatzen da. Hop! - eta orain ezberdin jokatzen dugu. Garrantzitsua da horretarako prestatuta egotea eta ez kezkatzea. Gerta liteke bihar egiten dudan guztia alferrikako bihurtzea, ezer ez, bizitza osoa ikasi dut eta beste zerbait ikasteko prest nago. Ez da arazo bat. Ez dago lan-segurtasunari beldurrik izan behar, baina zerbait berria etengabe ikasteko prest egon behar duzu.
Desioak eta publizitate minutu bat
- Ba al duzu gogorik?
Dmitry: Bai, hainbat nahi ditut.
Lehena eta merkantzia - harpidetu . Irakurle agurgarriak, joan YouTube-ra eta harpidetu gure kanalera. Hilabete inguru barru bideo-zerbitzuaren hedapen aktiboa hasiko dugu.Kubernetes-i buruzko hezkuntza-eduki asko izango ditugu, irekiak eta askotarikoak: gauza praktikoetatik hasi, laborategietaraino, oinarrizko gauza teoriko sakonetara eta Kubernetes nola erabili. printzipioen eta ereduen maila.
Bigarren merkantzia nahia - joan eta jarri izarrak haietaz elikatzen garelako. Ez badiguzu izarrik ematen, ez dugu ezer jatekorik izango. Ordenagailu joko batean mana bezalakoa da. Zerbait egiten dugu, egiten dugu, saiatzen gara, norbaitek esaten du bizikleta ikaragarriak direla, norbaitek dena guztiz gaizki dagoela, baina jarraitzen dugu eta erabat zintzo jokatzen dugu. Arazo bat ikusten dugu, konpondu eta gure esperientzia partekatzen dugu. Horregatik, eman iezaguzu izar bat, ez da zuregandik alde egingo, baina guregana helduko da, haietaz elikatzen garelako.
Hirugarren, garrantzitsua, eta jada ez merkataritza-nahia - utzi maitagarrien ipuinetan sinestea. Profesionalak zarete. DevOps oso lanbide serioa eta arduratsua da. Utzi lantokian jolastea. Utzi klik egin eta ulertuko duzu. Imajinatu ospitalera etortzen zarela, eta han medikua zurekin esperimentatzen ari dela. Ulertzen dut hau norbaitentzat iraingarria izan daitekeela, baina, ziurrenik, hau ez da zuri buruz, beste norbaiti buruz baizik. Esan besteei ere gelditzeko. Horrek bizitza hondatzen digu guztioi - asko hasten dira eragiketak, administratzaileak eta DevOps-ak berriro zerbait hautsi duten tipotzat hartzen. Hau “hautsi” egiten zen gehienetan jolastera joaten ginenagatik, eta ez genuen kontzientzia hotz batekin begiratu horrela dela, eta hala dela.
Horrek ez du esan nahi esperimentatu behar ez duzunik. Esperimentatu behar dugu, guk geuk egiten dugu. Egia esateko, gu geu batzuetan jolasten gara - hau, noski, oso txarra da, baina ez zaigu ezer arrotz gizakirik. Adieraz dezagun 2019a esperimentu serio eta ondo pentsatutako urtea, eta ez ekoizpeneko jokoen urtea. Seguruenik.
- Eskerrik asko!
Dmitry: Eskerrik asko, Vitaly, bai denboragatik eta baita elkarrizketagatik ere. Irakurle agurgarriak, mila esker bat-batean puntu honetara iritsi bazarete. Gutxienez gogoeta pare bat ekarri genizuela espero dut.
Elkarrizketan, Dmitryk werf-aren gaia ukitu zuen. Orain, arazo ia guztiak konpontzen dituen Suitzako labana unibertsala da. Baina ez zen beti horrela izan. On jaialdian Dmitry Stolyarov-ek tresna honi buruz xehetasunez kontatuko dizu. txostenean denetarik egongo da: Kubernetesen arazoak eta ezkutuko ñabardurak, zailtasun horiek konpontzeko aukerak eta werf-en egungo ezarpena zehatz-mehatz. Bat egin gurekin maiatzaren 27 eta 28an, tresna ezin hobeak sortuko ditugu.
Iturria: www.habr.com