En antaŭĝojo Vitalij Ĥabarov intervjuita Dmitrij Stolyarov (), teknika direktoro kaj kunfondinto de la kompanio Flant. Vitaly demandis Dmitry pri tio, kion faras Flant, pri Kubernetes, ekosistemevoluo, subteno. Ni diskutis kial Kubernetes estas bezonata kaj ĉu ĝi estas bezonata. Kaj ankaŭ pri mikroservoj, Amazon AWS, la aliro "Mi estos bonŝanca" al DevOps, la estonteco de Kubernetes mem, kial, kiam kaj kiel ĝi transprenos la mondon, la perspektivojn de DevOps kaj por kio inĝenieroj devus prepariĝi en la brila kaj proksima estonteco kun simpligo kaj neŭralaj retoj.
aŭskultu kiel podkaston pri DevOps Deflop - ruslingva podkasto pri DevOps, kaj sube estas la teksta versio.
Ĉi tie kaj sube li faras demandojn inĝeniero de Express42.
Pri "Flant"
- Saluton Dima. Vi estas la teknika direktoro"" kaj ankaŭ ĝia fondinto. Bonvolu diri al ni, kion la kompanio faras kaj kion vi estas en ĝi?
Dmitrio: De ekstere ŝajnas, ke ni estas la uloj kiuj ĉirkaŭiras instalante Kubernetes por ĉiuj kaj farante ion per ĝi. Sed tio ne estas vera. Ni komencis kiel firmao kiu traktas Linukson, sed de tre longa tempo nia ĉefa agado estis priservado de produktado kaj altŝarĝaj ŝlosilaj projektoj. Kutime ni konstruas la tutan infrastrukturon de nulo kaj poste respondecas pri ĝi dum longa, longa tempo. Tial la ĉefa laboro, kiun faras "Flant", por kiu ĝi ricevas monon, estas prenante respondecon kaj efektivigante ŝlosila produktado.
Mi, kiel la teknika direktoro kaj unu el la fondintoj de la kompanio, pasigas la tutan tagon kaj nokton provante eltrovi kiel pliigi la alireblecon de produktado, simpligi ĝian funkciadon, faciligi la vivon de administrantoj kaj pli agrabla la vivon de programistoj. .
Pri Kubernetes
— Lastatempe mi vidis multajn raportojn de Flant kaj pri Kubernetes. Kiel vi venis al ĝi?
Dmitrio: Mi jam multfoje parolis pri tio, sed mi tute ne ĝenas ripeti ĝin. Mi pensas, ke estas ĝuste ripeti ĉi tiun temon ĉar estas konfuzo inter kaŭzo kaj efiko.
Ni vere bezonis ilon. Ni alfrontis multajn problemojn, luktis, venkis ilin per diversaj lambastonoj kaj sentis bezonon de ilo. Ni ekzamenis multajn malsamajn eblojn, konstruis niajn proprajn biciklojn kaj akiris sperton. Iom post iom ni atingis la punkton, kie ni komencis uzi Docker preskaŭ tuj kiam ĝi aperis - ĉirkaŭ 2013. En la momento de ĝia apero, ni jam havis multan sperton pri ujoj, ni jam skribis analogon de "Docker" - iujn niajn proprajn lambastonojn en Python. Kun la apero de Docker, fariĝis eble forĵeti la lambastonojn kaj uzi fidindan kaj komunum-subtenatan solvon.
Kun Kubernetes la historio estas simila. Kiam ĝi ekakiris impulson - por ni ĉi tio estas versio 1.2 - ni jam havis amason da lambastonoj ĉe Shell kaj Chef, kiujn ni iel provis orkestrori per Docker. Ni serioze rigardis al Rancher kaj diversaj aliaj solvoj, sed tiam aperis Kubernetes, en kiu ĉio estas efektivigita ĝuste kiel ni farus ĝin aŭ eĉ pli bone. Estas nenio por plendi.
Jes, estas ia neperfekteco ĉi tie, estas ia neperfekteco tie - estas multaj neperfektaĵoj, kaj 1.2 ĝenerale estas terura, sed... Kubernetes estas kiel konstruaĵo konstruata - oni rigardas la projekton kaj komprenas ke ĝi estos malvarmeta. Se la konstruaĵo nun havas fundamenton kaj du etaĝojn, tiam vi komprenas, ke estas pli bone ankoraŭ ne translokiĝi, sed ne ekzistas tiaj problemoj kun la programaro - vi jam povas uzi ĝin.
Ni ne havis momenton, kie ni pensis pri uzi Kubernetes aŭ ne. Ni atendis ĝin longe antaŭ ol ĝi aperis, kaj provis krei analogojn mem.
Pri Kubernetes
— Ĉu vi rekte okupiĝas pri la evoluo de Kubernetes mem?
Dmitrio: mezbona. Prefere, ni partoprenas en la evoluo de la ekosistemo. Ni sendas certan nombron da tirpetoj: al Prometeo, al diversaj funkciigistoj, al Helm - al la ekosistemo. Bedaŭrinde, mi ne kapablas konservi trakon de ĉio, kion ni faras kaj mi povus erari, sed ne estas eĉ unu naĝejo de ni en la kernon.
— Samtempe, ĉu vi disvolvas multajn el viaj iloj ĉirkaŭ Kubernetes?
Dmitrio: La strategio estas jena: ni iras kaj tiras petojn al ĉio, kio jam ekzistas. Se tiri petoj ne estas akceptitaj tie, ni simple forkos ilin mem kaj vivas ĝis ili estas akceptitaj kun niaj konstruoj. Tiam, kiam ĝi atingas la kontraŭfluan, ni reiras al la kontraŭflua versio.
Ekzemple, ni havas Prometheus-funkciigiston, per kiu ni ŝanĝis tien kaj reen al la kontraŭfluo de nia asembleo verŝajne jam 5 fojojn. Ni bezonas ian funkcion, ni sendis tiran peton, ni devas elŝalti ĝin morgaŭ, sed ni ne volas atendi, ke ĝi estos liberigita kontraŭflue. Sekve, ni arigas por ni mem, disvolvas nian aron kun nia funkcio, kiun ni bezonas ial, al ĉiuj niaj aretoj. Tiam, ekzemple, ili turnas ĝin al ni en la kontraŭfluo kun la vortoj: "Knaboj, ni faru ĝin por pli ĝenerala kazo", ni, aŭ iu alia, finas ĝin, kaj kun la tempo ĝi denove kunfandiĝas.
Ni provas disvolvi ĉion, kio ekzistas. Multaj elementoj, kiuj ankoraŭ ne ekzistas, ankoraŭ ne estas inventitaj, aŭ elpensitaj, sed ne havis tempon por efektivigi – ni faras tion. Kaj ne ĉar ni ŝatas la procezon aŭ biciklokonstruadon kiel industrio, sed simple ĉar ni bezonas ĉi tiun ilon. Ofte oni demandas, kial ni faris tion aŭ alian? La respondo estas simpla - jes, ĉar ni devis iri pluen, solvi iun praktikan problemon, kaj ni solvis ĝin per ĉi tiu tula.
La vojo estas ĉiam tia: ni tre zorge serĉas kaj, se ni ne trovas solvon pri kiel fari trolebuson el pano, tiam ni faras nian propran panon kaj nian propran trolebuson.
Flanta iloj
— Mi scias, ke Flant nun havas aldonajn operatorojn, ŝelajn funkciigistojn kaj dapp/werf-ilojn. Kiel mi komprenas ĝin, ĉi tiu estas la sama instrumento en malsamaj enkarniĝoj. Mi ankaŭ komprenas, ke ekzistas multaj pli malsamaj iloj ene de Flaunt. Ĉi tio estas vera?
Dmitrio: Ni havas multe pli en GitHub. Laŭ tio, kion mi nun memoras, ni havas statusmapon - panelon por Grafana, kiun ĉiuj renkontis. Ĝi estas menciita en preskaŭ ĉiu dua artikolo pri Kubernetes-monitorado sur Medium. Ne eblas mallonge klarigi kio estas statusmapo - ĝi bezonas apartan artikolon, sed ĝi estas tre utila afero por monitori staton laŭlonge de la tempo, ĉar en Kubernetes ni ofte bezonas montri statuson laŭlonge de la tempo. Ni ankaŭ havas LogHouse - ĉi tio estas afero bazita sur ClickHouse kaj nigra magio por kolekti ŝtipojn en Kubernetes.
Multaj utilecoj! Kaj estos eĉ pli, ĉar kelkaj internaj solvoj estos publikigitaj ĉi-jare. El la tre grandaj bazitaj sur la aldon-funkciigisto, ekzistas amaso da aldonaĵoj por Kubernetes, ve kiel ĝuste instali sert-administranton - ilo por administri atestojn, kiel ĝuste instali Prometheus kun amaso da akcesoraĵoj - ĉi tiuj estas ĉirkaŭ dudek malsamaj. binaroj, kiuj eksportas datumojn kaj kolektas ion, al ĉi tiu Prometeo havas la plej mirindajn grafikaĵojn kaj atentigojn. Ĉio ĉi estas nur amaso da aldonaĵoj al Kubernetes, kiuj estas instalitaj en areto, kaj ĝi fariĝas de simpla al malvarmeta, kompleksa, aŭtomata, en kiu multaj problemoj jam estis solvitaj. Jes, ni faras multon.
Ekosistema Disvolviĝo
"Ŝajnas al mi, ke tio estas tre granda kontribuo al la evoluo de ĉi tiu instrumento kaj ĝiaj metodoj de uzo." Ĉu vi povas proksimume taksi kiu alia farus la saman kontribuon al la evoluo de la ekosistemo?
Dmitrio: En Rusio, el la kompanioj, kiuj funkcias en nia merkato, neniu estas eĉ proksima. Kompreneble, ĉi tio estas laŭta deklaro, ĉar ekzistas gravaj ludantoj kiel Mail kaj Yandex - ili ankaŭ faras ion kun Kubernetes, sed eĉ ili ne proksimiĝas al la kontribuo de kompanioj en la tuta mondo, kiuj faras multe pli ol ni. Estas malfacile kompari Flant, kiu havas kunlaborantaron de 80 homoj, kaj Red Hat, kiu havas 300 inĝenierojn per Kubernetes sole, se mi ne eraras. Estas malfacile kompari. Ni havas 6 homojn en la fako RnD, inkluzive de mi, kiuj tranĉis ĉiujn niajn ilojn. 6 homoj kontraŭ 300 Red Hat-inĝenieroj - estas iel malfacile kompari.
— Tamen, kiam eĉ ĉi tiuj 6 homoj povas fari ion vere utilan kaj fremdan, kiam ili alfrontas praktikan problemon kaj donas la solvon al la komunumo — interesa kazo. Mi komprenas, ke en grandaj teknologiaj kompanioj, kie ili havas sian propran disvolvan kaj subtenan teamon de Kubernetes, principe oni povas disvolvi la samajn ilojn. Ĉi tio estas ekzemplo por ili pri tio, kio povas esti evoluigita kaj donita al la komunumo, donante impulson al la tuta komunumo, kiu uzas Kubernetes.
Dmitrio: Ĉi tio verŝajne estas trajto de la integristo, ĝia propreco. Ni havas multajn projektojn kaj ni vidas multajn malsamajn situaciojn. Por ni, la ĉefa maniero krei aldonitan valoron estas analizi ĉi tiujn kazojn, trovi komunecon kaj fari ilin kiel eble plej malmultekostaj por ni. Ni aktive laboras pri tio. Estas malfacile por mi paroli pri Rusio kaj la mondo, sed ni havas ĉirkaŭ 40 DevOps-inĝenierojn en la kompanio, kiuj laboras pri Kubernetes. Mi ne pensas, ke ekzistas multaj kompanioj en Rusio kun komparebla nombro da specialistoj, kiuj komprenas Kubernetes, se entute.
Mi komprenas ĉion pri la labortitolo DevOps-inĝeniero, ĉiuj komprenas ĉion kaj kutimas nomi DevOps-inĝenierojn DevOps-inĝenieroj, ni ne diskutos tion. Ĉiuj ĉi tiuj 40 mirindaj DevOps-inĝenieroj alfrontas kaj solvas problemojn ĉiutage, ni nur analizas ĉi tiun sperton kaj provas ĝeneraligi. Ni komprenas, ke se ĝi restos en ni, tiam post unu aŭ du jaroj la ilo estos senutila, ĉar ie en la komunumo aperos preta Tula. Ne utilas amasigi ĉi tiun sperton interne - ĝi simple malplenigas energion kaj tempon en dev/null. Kaj ni tute ne bedaŭras ĝin. Ni publikigas ĉion kun granda plezuro kaj komprenas, ke ĝi devas esti eldonita, disvolvita, promociita, promociita, por ke homoj uzu ĝin kaj aldonu sian sperton – tiam ĉio kreskas kaj vivu. Tiam post du jaroj la instrumento ne iras en la rubon. Ne estas domaĝe daŭre enverŝi forton, ĉar estas klare, ke iu uzas vian ilon, kaj post du jaroj ĉiuj uzas ĝin.
Ĉi tio estas parto de nia granda strategio kun dapp/werf. Mi ne memoras kiam ni komencis fari ĝin, ŝajnas kiel antaŭ 3 jaroj. Komence, ĝi estis ĝenerale sur la ŝelo. Ĝi estis bonega pruvo de koncepto, ni solvis kelkajn el niaj apartaj problemoj - ĝi funkciis! Sed estas problemoj kun la ŝelo, estas neeble pligrandigi ĝin, programado sur la ŝelo estas alia tasko. Ni havis kutimon skribi en Ruby, sekve, ni refaris ion en Ruby, disvolvis, disvolvis, disvolvis, kaj renkontis la fakton, ke la komunumo, la homamaso, kiu ne diras “ni volas ĝin aŭ ni ne volas ĝin, ” turnas la nazon al Ruby, kiom amuza estas tio? Ni komprenis, ke ni devus skribi ĉiujn ĉi tiujn aferojn en Go nur por renkonti la unuan punkton en la kontrola listo: DevOps-ilo devus esti statika duuma. Esti Go aŭ ne ne tiom gravas, sed statika binaro skribita en Go estas pli bona.
Ni elspezis nian energion, reverkis la dapp en Go kaj nomis ĝin werf. La Dapp ne plu estas subtenata, ne evoluinta, funkcianta en iu plej nova versio, sed ekzistas absoluta ĝisdatigo vojo al la supro, kaj vi povas sekvi ĝin.
Kial la dapp estis kreita?
— Ĉu vi povas mallonge diri al ni kial la dapp estis kreita, kiajn problemojn ĝi solvas?
Dmitrio: La unua kialo estas en la asembleo. Komence, ni havis gravajn problemojn kun la konstruo, kiam Docker ne havis plurfazajn kapablojn, do ni faris plurstadiojn memstare. Tiam ni havis multe pli da problemoj pri purigado de la bildo. Ĉiuj, kiuj faras CI/KD, pli frue ol poste, alfrontas la problemon, ke estas amaso da kolektitaj bildoj, vi devas iel purigi tion, kio ne estas bezonata kaj lasi tion, kio estas bezonata.
La dua kialo estas deplojo. Jes, ekzistas Helm, sed ĝi solvas nur kelkajn el la problemoj. Sufiĉe amuze, estas skribite, ke "Helm estas la Paka Administranto por Kubernetes." Ĝuste kio "la". Estas ankaŭ la vortoj "Pakaĵadministrilo" - kio estas la kutima atendo de Pakaĵadministrilo? Ni diras: "Pakaĵa Administranto - instalu la pakaĵon!" kaj ni atendas ke li diros al ni: "La pakaĵo estas liverita."
Estas interese, ke ni diras: "Helm, instalu la pakaĵon", kaj kiam li respondas, ke li instalis ĝin, rezultas, ke li ĵus komencis la instaladon - li indikis Kubernetes: "Lanĉu ĉi tiun aferon!", kaj ĉu ĝi komenciĝis aŭ ne. , ĉu ĝi funkcias aŭ ne , Helm tute ne solvas ĉi tiun problemon.
Rezultas, ke Helm estas nur teksta antaŭprocesilo, kiu ŝarĝas datumojn en Kubernetes.
Sed kiel parto de iu disfaldiĝo, ni volas scii ĉu la aplikaĵo estis liberigita por produktado aŭ ne? Disvolvita al prod signifas, ke la aplikaĵo moviĝis tien, la nova versio estis deplojita, kaj almenaŭ ĝi ne kraŝas tie kaj respondas ĝuste. Helm neniel solvas ĉi tiun problemon. Por solvi ĝin, vi devas elspezi multe da peno, ĉar vi devas doni al Kubernetes la komandon por elŝalti kaj kontroli tion, kio okazas tie - ĉu ĝi estas deplojita aŭ lanĉita. Kaj estas ankaŭ multaj taskoj rilataj al deplojo, purigado kaj muntado.
Planoj
Ĉi-jare ni komencos lokan disvolviĝon. Ni volas atingi tion, kio antaŭe estis en Vagrant - ni tajpis "vagrant up" kaj ni deplojis virtualajn maŝinojn. Ni volas atingi la punkton kie estas projekto en Git, ni skribas "werf supre" tie, kaj ĝi alportas lokan kopion de ĉi tiu projekto, deplojita en loka mini-Kub, kun ĉiuj dosierujoj konvenaj por disvolviĝo konektitaj. . Depende de la evolulingvo, tio estas farita alimaniere, sed tamen, por ke loka evoluo povu oportune efektivigi sub surmuntitaj dosieroj.
La sekva paŝo por ni estas investu en oportuno por programistoj. Por rapide disfaldi projekton loke per unu ilo, disvolvu ĝin, puŝu ĝin en Git, kaj ĝi ankaŭ eliros al scenejo aŭ provoj, depende de la duktoj, kaj poste uzu la saman ilon por iri al produktado. Ĉi tiu unueco, unuiĝo, reproduktebleco de infrastrukturo de la loka medio ĝis vendo estas tre grava punkto por ni. Sed ĉi tio ankoraŭ ne estas en werf - ni nur planas fari ĝin.
Sed la vojo al dapp/werf ĉiam estis la sama kiel kun Kubernetes en la komenco. Ni renkontis problemojn, solvis ilin per solvoj - ni elpensis iujn solvojn por ni mem sur la ŝelo, pri io ajn. Tiam ili provis iel rektigi ĉi tiujn solvojn, ĝeneraligi kaj solidigi ilin en binarojn en ĉi tiu kazo, kiujn ni simple kundividas.
Estas alia maniero rigardi ĉi tiun tutan historion, kun analogioj.
Kubernetes estas aŭtokadro kun motoro. Ne estas pordoj, vitro, radio, kristnaska arbo – tute nenio. Nur la kadro kaj motoro. Kaj tie estas Helm - jen la stirilo. Bone - estas stirilo, sed vi ankaŭ bezonas stirpinton, stirilon, skatolon kaj radojn, kaj vi ne povas malhavi ilin.
En la kazo de werf, ĉi tio estas alia komponanto de Kubernetes. Nur nun en la alfa versio de werf, ekzemple, Helm estas kompilita ene de werf, ĉar ni estas lacaj fari ĝin mem. Estas multaj kialoj por fari tion, mi rakontos al vi detale pri kial ni kompilis la tutan stirilon kune kun tiller ene werf. .
Nun werf estas pli integra komponanto. Ni ricevas finitan stirilon, stirilon - mi ne tre lertas pri aŭtoj, sed ĉi tio estas granda bloko, kiu jam solvas sufiĉe larĝan gamon da problemoj. Ni ne bezonas mem trarigardi la katalogon, elekti unu parton por alia, pensi pri kiel ŝraŭbi ilin kune. Ni ricevas pretan kombinaĵon, kiu solvas grandan nombron da problemoj samtempe. Sed ene de ĝi estas konstruita el la samaj malfermfontaj komponantoj, ĝi ankoraŭ uzas Docker por kunigo, Helm por iuj el la funkcioj, kaj ekzistas pluraj aliaj bibliotekoj. Ĉi tio estas integra ilo por eligi malvarmeta CI/KD el la skatolo rapide kaj oportune.
Ĉu Kubernetes estas malfacile konservi?
— Vi parolas pri la sperto, ke vi komencis uzi Kubernetes, ĉi tio estas kadro por vi, motoro, kaj ke vi povas pendigi multajn diversajn aferojn sur ĝi: korpo, stirilo, ŝraŭbo sur pedaloj, sidlokoj. La demando ŝprucas - kiom malfacila estas Kubernetes-subteno por vi? Vi havas multan sperton, kiom da tempo kaj rimedoj vi elspezas por subteni Kubernetes izolite de ĉio alia?
Dmitrio: Ĉi tio estas tre malfacila demando kaj por respondi, ni devas kompreni, kio estas subteno kaj kion ni volas de Kubernetes. Eble vi povas malkaŝi?
— Laŭ mia scio kaj kiel mi vidas, nun multaj teamoj volas provi Kubernetes. Ĉiuj jungas sin al ĝi, metas ĝin sur la genuojn. Mi havas la senton, ke homoj ne ĉiam komprenas la kompleksecon de ĉi tiu sistemo.
Dmitrio: Estas tiel.
— Kiom malfacile estas preni kaj instali Kubernetes de nulo por ke ĝi estu preta por produktado?
Dmitrio: Kiom malfacilas laŭ vi transplanti koron? Mi komprenas, ke ĉi tio estas kompromisa demando. Uzi skalpelon kaj ne erari ne estas tiom malfacila. Se ili diras al vi, kie tranĉi kaj kie kudri, tiam la proceduro mem ne estas komplika. Estas malfacile garantii fojon post fojo, ke ĉio funkcios.
Instali Kubernetes kaj ekfunkciigi ĝin estas facile: ido! — instalita, ekzistas multaj instalmetodoj. Sed kio okazas kiam problemoj aperas?
Demandoj ĉiam aperas - kion ni ankoraŭ ne konsideris? Kion ni ankoraŭ ne faris? Kiuj Linukso-kernaj parametroj estis specifitaj malĝuste? Sinjoro, ĉu ni eĉ menciis ilin?! Kiujn komponantojn de Kubernetes ni liveris kaj kiujn ni ne havas? Miloj da demandoj aperas, kaj por respondi ilin, vi devas pasigi 15-20 jarojn en ĉi tiu industrio.
Mi havas lastatempan ekzemplon pri ĉi tiu temo, kiu povas malkaŝi la signifon de la problemo "Ĉu Kubernetes estas malfacile konservi?" Antaŭ iom da tempo ni serioze pripensis ĉu ni devus provi efektivigi Cilium kiel reton en Kubernetes.
Mi klarigu, kio estas Cilium. Kubernetes havas multajn malsamajn efektivigojn de la interkonekta subsistemo, kaj unu el ili estas tre bonega - Cilium. Kio estas ĝia signifo? En la kerno, antaŭ iom da tempo eblis skribi hokojn por la kerno, kiuj iel aŭ alie invadas la retan subsistemon kaj diversajn aliajn subsistemojn, kaj ebligas al vi preterpasi grandajn pecojn en la kerno.
La Linukso-kerno historie havas ip-ruton, trofiltrilon, pontojn kaj multajn malsamajn malnovajn komponantojn, kiuj aĝas 15, 20, 30 jarojn. Ĝenerale ili funkcias, ĉio estas bonega, sed nun ili amasigis ujojn, kaj ĝi aspektas kiel turo el 15 brikoj unu sur la alia, kaj vi staras sur ĝi sur unu kruro - stranga sento. Ĉi tiu sistemo historie disvolviĝis kun multaj nuancoj, kiel la apendico en la korpo. En iuj situacioj estas agado problemoj, ekzemple.
Estas mirinda BPF kaj la kapablo skribi hokojn por la kerno - la uloj skribis siajn proprajn hokojn por la kerno. La pakaĵo venas en la Linuksan kernon, ili elprenas ĝin ĝuste ĉe la enigo, mem prilaboras ĝin kiel ĝi devus sen pontoj, sen TCP, sen IP-stako - mallonge, preterpasante ĉion, kio estas skribita en la Linuksa kerno, kaj poste kraĉas. ĝi eksteren en la ujon.
Kio okazis? Tre bonega agado, bonegaj funkcioj - simple bonega! Sed ni rigardas ĉi tion kaj vidas, ke sur ĉiu maŝino estas programo, kiu konektas al la Kubernetes API kaj, surbaze de la datumoj, kiujn ĝi ricevas de ĉi tiu API, generas C-kodon kaj kompilas binarojn, kiujn ĝi ŝarĝas en la kernon, por ke ĉi tiuj hokoj funkciu. en la kernspaco.
Kio okazas se io misfunkcias? Ni ne scias. Por kompreni ĉi tion, vi devas legi ĉi tiun tutan kodon, kompreni la tutan logikon, kaj estas mirinde kiom malfacila ĝi estas. Sed, aliflanke, ekzistas ĉi tiuj pontoj, retaj filtriloj, ip-ruto - mi ne legis ilian fontkodon, kaj nek la 40 inĝenieroj, kiuj laboras en nia kompanio. Eble nur kelkaj komprenas kelkajn partojn.
Kaj kio estas la diferenco? Montriĝas, ke ekzistas ip-ruto, la Linukso-kerno, kaj estas nova ilo - kian diferencon ĝi faras, ni ne komprenas unu aŭ la alian. Sed ni timas uzi ion novan — kial? Ĉar se la ilo aĝas 30 jarojn, tiam en 30 jaroj ĉiuj cimoj estis trovitaj, ĉiuj eraroj estis surpaŝitaj kaj vi ne bezonas scii pri ĉio - ĝi funkcias kiel nigra skatolo kaj ĉiam funkcias. Ĉiuj scias kiun diagnozan ŝraŭbturnilon alglui en kiu loko, kiu tcpdump ruli en kiu momento. Ĉiuj bone konas diagnozajn ilojn kaj komprenas kiel ĉi tiu aro de komponantoj funkcias en la Linukso-kerno - ne kiel ĝi funkcias, sed kiel uzi ĝin.
Kaj la mirinde malvarmeta Cilium ne aĝas 30 jarojn, ĝi ankoraŭ ne maljuniĝis. Kubernetes havas la saman problemon, kopiu. Ke Cilium estas instalita perfekte, ke Kubernetes estas instalita perfekte, sed kiam io misfunkcias en produktado, ĉu vi kapablas rapide kompreni en kritika situacio kio misfunkciis?
Kiam ni diras, ĉu estas malfacile konservi Kubernetes - ne, ĝi estas tre facila, kaj jes, ĝi estas nekredeble malfacila. Kubernetes funkcias bonege per si mem, sed kun miliardo da nuancoj.
Pri la aliro "Mi estos bonŝanca".
— Ĉu ekzistas kompanioj, kie ĉi tiuj nuancoj preskaŭ garantias aperi? Supozu ke Yandex subite transdonas ĉiujn servojn al Kubernetes, tie estos grandega ŝarĝo.
Dmitrio: Ne, ĉi tio ne estas konversacio pri la ŝarĝo, sed pri la plej simplaj aferoj. Ekzemple, ni havas Kubernetes, ni deplojis la aplikaĵon tie. Kiel vi scias, ke ĝi funkcias? Simple ne ekzistas preta ilo por kompreni, ke la aplikaĵo ne frakasas. Ne ekzistas preta sistemo, kiu sendas atentigojn; vi devas agordi ĉi tiujn atentigojn kaj ĉiun horaron. Kaj ni ĝisdatigas Kubernetes.
Mi havas Ubuntu 16.04. Vi povas diri, ke ĉi tio estas malnova versio, sed ni ankoraŭ estas sur ĝi ĉar ĝi estas LTS. Estas systemd, kies nuanco estas, ke ĝi ne purigas C-grupojn. Kubernetes lanĉas podojn, kreas C-grupojn, poste forigas podojn, kaj iel rezultas - mi ne memoras la detalojn, pardonu - ke systemd tranĉaĵoj restas. Ĉi tio kondukas al la fakto, ke kun la tempo, ajna aŭto komencas forte malrapidiĝi. Ĉi tio eĉ ne estas demando pri alta ŝarĝo. Se permanentaj podoj estas lanĉitaj, ekzemple, se ekzistas Cron Job, kiu konstante generas podojn, tiam la maŝino kun Ubuntu 16.04 komencos malrapidiĝi post semajno. Estos konstante alta ŝarĝa mezumo pro la fakto, ke amaso da C-grupoj estis kreitaj. Ĉi tiu estas la problemo, kiun alfrontos ĉiu persono, kiu simple instalas Ubuntu 16 kaj Kubernetes supre.
Ni diru, ke li iel ĝisdatigas systemd aŭ ion alian, sed en la Linukso-kerno ĝis 4.16 estas eĉ pli amuza - kiam vi forigas C-grupojn, ili likas en la kerno kaj fakte ne estas forigitaj. Tial, post unu monato da laborado pri ĉi tiu maŝino, estos neeble rigardi la memorstatistikojn por la fajrujoj. Ni elprenas dosieron, ruliĝas ĝin en la programo, kaj unu dosiero ruliĝas dum 15 sekundoj, ĉar la kerno bezonas tre longan tempon por kalkuli milionon da C-grupoj en si mem, kiuj ŝajnas esti forigitaj, sed ne - ili likas. .
Estas ankoraŭ multaj tiaj etaj aferoj ĉi tie kaj tie. Ĉi tio ne estas problemo, kiun gigantaj kompanioj foje alfrontas sub tre pezaj ŝarĝoj - ne, temas pri ĉiutagaj aferoj. Homoj povas vivi tiel dum monatoj - ili instalis Kubernetes, deplojis la aplikaĵon - ŝajnas funkcii. Por multaj homoj tio estas normala. Ili eĉ ne scios, ke ĉi tiu aplikaĵo kraŝos ial, ili ne ricevos atentigon, sed por ili ĉi tio estas la normo. Antaŭe, ni vivis sur virtualaj maŝinoj sen monitorado, nun ni translokiĝis al Kubernetes, ankaŭ sen monitorado - kio estas la diferenco?
La demando estas, ke kiam ni marŝas sur glacio, ni neniam scias ĝian dikecon krom se ni mezuras ĝin anticipe. Multaj homoj marŝas kaj ne maltrankviliĝas, ĉar ili jam antaŭe marŝis.
De mia vidpunkto, la nuanco kaj komplekseco de funkciigado de ajna sistemo estas certigi ke la dikeco de la glacio estas ĝuste sufiĉa por solvi niajn problemojn. Jen pri kio ni parolas.
En IT, ŝajnas al mi, estas tro multaj aliroj "Mi estos bonŝanca". Multaj homoj instalas programaron kaj uzas programajn bibliotekojn kun la espero, ke ili havos bonŝancon. Ĝenerale multaj homoj estas bonŝancaj. Pro tio probable ĝi funkcias.
— Laŭ mia pesimisma takso, ĝi aspektas jene: kiam la riskoj estas altaj, kaj la aplikaĵo devas funkcii, tiam necesas subteno de Flaunt, eble de Red Hat, aŭ vi bezonas vian propran internan teamon dediĉitan specife al Kubernetes, kiu estas preta. por detiri ĝin.
Dmitrio: Objektive, ĉi tio estas tiel. Eniri la rakonton de Kubernetes por malgranda teamo memstare implikas kelkajn riskojn.
Ĉu ni bezonas ujojn?
— Ĉu vi povas diri al ni kiom disvastigita Kubernetes estas en Rusio?
Dmitrio: Mi ne havas ĉi tiujn datumojn, kaj mi ne certas ke iu alia havas ĝin. Ni diras: "Kubernetes, Kubernetes", sed estas alia maniero rigardi ĉi tiun aferon. Mi ankaŭ ne scias kiom disvastigitaj estas ujoj, sed mi konas ciferon el raportoj en Interreto, ke 70% de ujoj estas orkestrataj de Kubernetes. Ĝi estis fidinda fonto por sufiĉe granda specimeno tra la mondo.
Tiam alia demando - ĉu ni bezonas ujojn? Mia persona sento kaj la ĝenerala pozicio de la kompanio Flant estas, ke Kubernetes estas fakta normo.
Estos nenio krom Kubernetes.
Ĉi tio estas absoluta ludŝanĝilo en la kampo de infrastruktura administrado. Nur absoluta - jen, ne plu Ansible, Chef, virtualaj maŝinoj, Terraform. Mi ne parolas pri la malnovaj kolektivaj metodoj. Kubernetes estas absoluta ŝanĝanto, kaj nun estos nur tiel.
Estas klare, ke por iuj necesas kelkaj jaroj, kaj por aliaj kelkaj jardekoj, por realigi tion. Mi ne dubas, ke estos nenio krom Kubernetes kaj ĉi tiu nova aspekto: ni ne plu damaĝas la operaciumon, sed uzas infrastrukturo kiel kodo, nur ne per kodo, sed per yml - deklare priskribita infrastrukturo. Mi havas la senton, ke ĉiam estos tiel.
— Tio estas, tiuj kompanioj, kiuj ankoraŭ ne ŝanĝis al Kubernetes, nepre ŝanĝos al ĝi aŭ restos en forgeso. Mi bone komprenis vin?
Dmitrio: Ĉi tio ankaŭ ne estas tute vera. Ekzemple, se ni havas la taskon prizorgi DNS-servilon, tiam ĝi povas ruliĝi sur FreeBSD 4.10 kaj ĝi povas funkcii perfekte dum 20 jaroj. Nur laboru kaj jen. Eble post 20 jaroj io devos esti ĝisdatigita unufoje. Se ni parolas pri programaro en la formato, kiun ni lanĉis kaj ĝi efektive funkcias dum multaj jaroj sen ĝisdatigoj, sen fari ŝanĝojn, tiam, kompreneble, ne estos Kubernetes. Li ne estas bezonata tie.
Ĉio rilata al CI/KD - kie ajn Daŭra Livero estas bezonata, kie vi devas ĝisdatigi versiojn, fari aktivajn ŝanĝojn, kie ajn vi bezonas konstrui misfunkciadon - nur Kubernetes.
Pri mikroservoj
- Jen mi havas etan disonancon. Por labori kun Kubernetes, vi bezonas eksteran aŭ internan subtenon - ĉi tiu estas la unua punkto. Due, kiam ni ĵus komencas disvolviĝon, ni estas malgranda ekentrepreno, ni ankoraŭ havas nenion, disvolviĝo por Kubernetes aŭ mikroserva arkitekturo ĝenerale povas esti kompleksa kaj ne ĉiam ekonomie pravigita. Mi interesiĝas pri via opinio - ĉu noventreprenoj devas tuj ekskribi por Kubernetes de nulo, aŭ ĉu ili povas ankoraŭ skribi monoliton, kaj poste nur veni al Kubernetes?
Dmitrio: Mirinda demando. Mi parolas pri mikroservoj Multfoje mi renkontis homojn, kiuj provas marteli najlojn per mikroskopo. La aliro mem estas ĝusta; ni mem dizajnas nian internan programaron tiel. Sed kiam vi faras tion, vi devas klare kompreni, kion vi faras. La vorto, kiun mi plej malamas pri mikroservoj, estas "mikro." Historie, ĉi tiu vorto originis tie, kaj ial homoj opinias, ke mikro estas tre malgranda, malpli ol milimetro, kiel mikrometro. Ĉi tio estas malĝusta.
Ekzemple, ekzistas monolito, kiu estas skribita de 300 homoj, kaj ĉiuj, kiuj partoprenis en la evoluo, komprenas, ke ekzistas problemoj tie, kaj ĝi devas esti rompita en mikropecojn - ĉirkaŭ 10 pecojn, ĉiu el kiuj estas skribita de 30 homoj. en minimuma versio. Ĉi tio estas grava, necesa kaj malvarmeta. Sed kiam starto venas al ni, kie 3 tre bonegaj kaj talentaj uloj skribis 60 mikroservojn sur siaj genuoj, ĉiufoje mi serĉas Corvalol.
Ŝajnas al mi, ke pri tio oni jam milfoje parolis - ni ricevis distribuitan monoliton en unu aŭ alia formo. Ĉi tio ne estas ekonomie pravigita, ĝi estas tre malfacila ĝenerale en ĉio. Mi ĵus vidis ĉi tion tiom da fojoj, ke ĝi vere doloras min, do mi daŭre parolas pri ĝi.
Al la komenca demando, estas konflikto inter la fakto, ke unuflanke Kubernetes estas timiga uzi, ĉar ne estas klare, kio povus rompi tie aŭ ne funkcios, aliflanke, estas klare, ke ĉio iras tie. kaj nenio krom Kubernetes ekzistos. Respondo - pezu la kvanton de profito kiu venas, la kvanton de taskoj kiujn vi povas solvi. Ĉi tio estas unuflanke de la skalo. Aliflanke, estas riskoj asociitaj kun malfunkcio aŭ kun malkresko en responda tempo, nivelo de havebleco - kun malkresko en rendimentaj indikiloj.
Jen ĝi estas - aŭ ni rapide moviĝas, kaj Kubernetes permesas al ni fari multajn aferojn multe pli rapide kaj pli bone, aŭ ni uzas fidindajn, tempelprovitajn solvojn, sed moviĝas multe pli malrapide. Ĉi tio estas elekto, kiun ĉiu kompanio devas fari. Vi povas pensi pri ĝi kiel vojo en la ĝangalo - kiam vi marŝas la unuan fojon, vi povas renkonti serpenton, tigron aŭ frenezan melon, kaj kiam vi marŝis 10 fojojn, vi paŝis la padon, forigis. la branĉoj kaj marŝas pli facile. Ĉiufoje la vojo iĝas pli larĝa. Poste ĝi estas asfalta vojo, kaj poste bela bulvardo.
Kubernetes ne staras senmove. Demando denove: Kubernetes, unuflanke, estas 4-5 binaroj, aliflanke, ĝi estas la tuta ekosistemo. Ĉi tiu estas la mastruma sistemo, kiun ni havas sur niaj maŝinoj. Kio estas ĉi tio? Ubuntu aŭ kuriozaĵoj? Ĉi tio estas la Linukso-kerno, amaso da pliaj komponantoj. Ĉiuj ĉi aĵoj ĉi tie, unu venena serpento estis ĵetita el la vojo, barilo estis starigita tie. Kubernetes evoluas tre rapide kaj dinamike, kaj la volumo de riskoj, la volumo de la nekonataĵo malpliiĝas ĉiumonate kaj, sekve, ĉi tiuj skaloj rebalanciĝas.
Respondante la demandon pri tio, kion faru ekentrepreno, mi dirus - venu al Flaunt, pagu 150 mil rublojn kaj ricevu facilan servon de DevOps. Se vi estas malgranda ekentrepreno kun kelkaj programistoj, ĉi tio funkcias. Anstataŭ dungi vian propran DevOps, kiu devos lerni kiel solvi viajn problemojn kaj pagi salajron ĉi-momente, vi ricevos ŝlosilan solvon por ĉiuj problemoj. Jes, estas iuj malavantaĝoj. Ni, kiel subkontraktanto, ne povas esti tiel implikitaj kaj respondi rapide al ŝanĝoj. Sed ni havas multajn kompetentecojn kaj pretajn praktikojn. Ni garantias, ke en ajna situacio ni certe rapide eltrovos ĝin kaj levos ajnan Kubernetes el la mortintoj.
Mi forte rekomendas subkontraktadon al noventreprenoj kaj establitaj entreprenoj ĝis grandeco, kie vi povas dediĉi teamon de 10 homoj al operacioj, ĉar alie ne utilas. Sendube havas sencon subkontrakti ĉi tion.
Pri Amazon kaj Guglo
— Ĉu gastiganto de solvo de Amazon aŭ Guglo povas esti konsiderata kiel subkontraktanto?
Dmitrio: Jes, kompreneble, tio solvas kelkajn problemojn. Sed denove estas nuancoj. Vi ankoraŭ bezonas kompreni kiel uzi ĝin. Ekzemple, estas mil etaj aferoj en la laboro de Amazon AWS: la Load Balancer devas esti varmigita aŭ peto devas esti skribita anticipe, ke "uloj, ni ricevos trafikon, varmigu la Load Balancer por ni!" Vi devas scii ĉi tiujn nuancojn.
Kiam vi turnas sin al homoj, kiuj specialiĝas pri tio, vi preskaŭ fermas ĉiujn tipajn aferojn. Ni nun havas 40 inĝenierojn, ĝis la fino de la jaro verŝajne estos 60 - ni certe renkontis ĉiujn ĉi aferojn. Eĉ se ni denove renkontas ĉi tiun problemon en iu projekto, ni rapide demandas unu la alian kaj scias kiel solvi ĝin.
Verŝajne la respondo estas - kompreneble gastigita rakonto faciligas iun parton. La demando estas ĉu vi pretas fidi ĉi tiujn gastigantojn kaj ĉu ili solvos viajn problemojn. Amazon kaj Google faris bone. Por ĉiuj niaj kazoj - ĝuste. Ni ne havas pliajn pozitivajn spertojn. Ĉiuj aliaj nuboj, kun kiuj ni provis labori, kreas multajn problemojn - Ager, kaj ĉio, kio estas en Rusio, kaj ĉiaj OpenStack en malsamaj efektivigoj: Headster, Overage - kion ajn vi volas. Ili ĉiuj kreas problemojn, kiujn vi ne volas solvi.
Sekve, la respondo estas jes, sed, fakte, ne estas tre multaj maturaj gastigitaj solvoj.
Kiu bezonas Kubernetes?
— Kaj tamen, kiu bezonas Kubernetes? Kiu jam devus ŝanĝi al Kubernetes, kiu estas la tipa Flaunt-kliento, kiu venas specife por Kubernetes?
Dmitrio: Ĉi tio estas interesa demando, ĉar ĝuste nun, post Kubernetes, multaj homoj venas al ni: "Knaboj, ni scias, ke vi faras Kubernetes, faru ĝin por ni!" Ni respondas al ili: "Sinjoroj, ni ne faras Kubernetes, ni faras prod kaj ĉion rilatan al ĝi." Ĉar nuntempe estas simple neeble fari produkton sen fari la tutan CI/KD kaj ĉi tiun tutan historion. Ĉiuj malproksimiĝis de la divido, ke ni havas evoluon per evoluo, kaj poste ekspluaton per ekspluatado.
Niaj klientoj atendas malsamajn aferojn, sed ĉiuj atendas iun bonan miraklon, ke ili havas iujn problemojn, kaj nun - hop! — Kubernetes solvos ilin. Homoj kredas je mirakloj. En ilia menso ili komprenas, ke ne estos miraklo, sed en ilia animo ili esperas - kio se ĉi tiu Kubernetes nun solvos ĉion por ni, ili tiom multe parolas pri tio! Subite li nun — ternu! - kaj arĝenta kuglo, ternu! — kaj ni havas 100% da funkciado, ĉiuj programistoj povas liberigi ĉion, kio eniras en produktadon 50 fojojn, kaj ĝi ne kraŝas. Ĝenerale, miraklo!
Kiam tiaj homoj venas al ni, ni diras: "Pardonu, sed ne ekzistas tia afero kiel miraklo." Por esti sana, vi devas bone manĝi kaj ekzerci. Por havi fidindan produkton, ĝi devas esti farita fidinde. Por havi oportunan CI/KD, vi devas fari ĝin tiel. Tio estas multe da laboro, kiun oni devas fari.
Respondante la demandon pri kiu bezonas Kubernetes - neniu bezonas Kubernetes.
Iuj homoj havas la miskomprenon, ke ili bezonas Kubernetes. Homoj bezonas, ili havas profundan bezonon ĉesi pensi, studi kaj interesiĝi pri ĉiuj problemoj de infrastrukturo kaj la problemoj pri funkciado de siaj aplikaĵoj. Ili volas, ke aplikaĵoj nur funkciu kaj nur disfaldu. Por ili, Kubernetes estas la espero, ke ili ĉesos aŭdi la rakonton, ke "ni kuŝis tie", aŭ "ni ne povas eliri", aŭ io alia.
La teknika direktoro kutime venas al ni. Ili demandas al li du aferojn: unuflanke, donu al ni trajtojn, aliflanke, stabilecon. Ni sugestas vin preni ĝin sur vin mem kaj fari ĝin. La arĝenta kuglo, aŭ pli ĝuste arĝentplata, estas, ke vi ĉesos pensi pri ĉi tiuj problemoj kaj perdi tempon. Vi havos specialajn homojn, kiuj fermos ĉi tiun aferon.
La vortumo, ke ni aŭ iu ajn alia bezonas Kubernetes, estas malĝusta.
Administrantoj vere bezonas Kubernetes, ĉar ĝi estas tre interesa ludilo, kun kiu vi povas ludi kaj ludi. Ni estu honestaj - ĉiuj amas ludilojn. Ni ĉiuj estas infanoj ie, kaj kiam ni vidas novan, ni volas ludi ĝin. Por iuj, tio estis malinstigita, ekzemple, en la administrado, ĉar ili jam sufiĉe ludis kaj jam estas lacaj ĝis la punkto ke ili simple ne volas. Sed ĉi tio ne estas tute perdita por iu ajn. Ekzemple, se mi jam longe tedis ludilojn en la kampo de sistema administrado kaj DevOps, tiam mi ankoraŭ amas la ludilojn, mi ankoraŭ aĉetas kelkajn novajn. Ĉiuj homoj, iel aŭ alie, ankoraŭ volas ian ludilojn.
Ne necesas ludi kun produktado. Kion ajn mi kategorie rekomendas ne fari kaj kion mi nun amase vidas: "Ho, nova ludilo!" — ili kuris aĉeti ĝin, aĉetis kaj: "Ni prenu ĝin nun al la lernejo kaj montru ĝin al ĉiuj niaj amikoj." Ne faru ĉi tion. Mi pardonpetas, miaj infanoj nur kreskas, mi konstante vidas ion en infanoj, rimarkas ĝin en mi mem, kaj poste ĝeneraligas al aliaj.
La fina respondo estas: vi ne bezonas Kubernetes. Vi devas solvi viajn problemojn.
Kion vi povas atingi estas:
- prod ne falas;
- eĉ se li provas fali, ni antaŭe scias pri tio, kaj ni povas enmeti ion;
- ni povas ŝanĝi ĝin je la rapideco, je kiu nia komerco postulas ĝin, kaj ni povas fari ĝin oportune; ĝi ne kaŭzas al ni problemojn.
Estas du realaj bezonoj: fidindeco kaj dinamiko/fleksebleco de lanĉo. Ĉiuj, kiuj nuntempe faras ian IT-projektojn, negrave en kia komerco - mola por faciligi la mondon, kaj kiu komprenas tion, devas solvi ĉi tiujn bezonojn. Kubernetes kun la ĝusta aliro, kun la ĝusta kompreno kaj kun sufiĉe da sperto permesas vin solvi ilin.
Pri senservilo
— Se vi rigardas iom pli en la estontecon, tiam provante solvi la problemon de la foresto de kapdoloroj kun infrastrukturo, kun la rapideco de disvolvado kaj la rapideco de aplikaj ŝanĝoj, novaj solvoj aperas, ekzemple, senserviloj. Ĉu vi sentas ian potencialon en ĉi tiu direkto kaj, ni diru, danĝeron por Kubernetes kaj similaj solvoj?
Dmitrio: Ĉi tie ni devas denove fari rimarkon, ke mi ne estas viziulo, kiu rigardas antaŭen kaj diras — estos tiel! Kvankam mi ĵus faris la samon. Mi rigardas miajn piedojn kaj vidas amason da problemoj tie, ekzemple, kiel transistoroj funkcias en komputilo. Estas amuza, ĉu ne? Ni renkontas iujn cimojn en la CPU.
Faru senservila sufiĉe fidinda, malmultekosta, efika kaj oportuna, solvante ĉiujn ekosistemajn problemojn. Ĉi tie mi konsentas kun Elon Musk, ke necesas dua planedo por krei misfunkciadon por la homaro. Kvankam mi ne scias, kion li diras, mi komprenas, ke mi ne estas preta mem flugi al Marso kaj tio ne okazos morgaŭ.
Kun senservilo estas klare klare, ke tio estas ideologie ĝusta afero, kiel kulpotoleremo por la homaro - havi du planedojn estas pli bone ol unu. Sed kiel fari ĝin nun? Sendi unu ekspedicion ne estas problemo se vi koncentras viajn klopodojn sur ĝi. Sendi plurajn ekspediciojn kaj loĝigi plurajn milojn da homoj tie, mi pensas, ankaŭ estas realisma. Sed igi ĝin tute mistolerema por ke duono de la homaro loĝu tie, ŝajnas al mi nun neeble, ne konsiderata.
Kun senservilo unu kontraŭ unu: la afero estas bonega, sed ĝi estas malproksima de la problemoj de 2019. Pli proksime al 2030 - ni vivu por vidi ĝin. Mi ne dubas, ke ni vivos, ni certe vivos (ripeti antaŭ enlitiĝi), sed nun ni devas solvi aliajn problemojn. Estas kiel kredi je la fabelponeo Ĉielarko. Jes, kelkaj procentoj de kazoj estas solvitaj, kaj ili estas solvitaj perfekte, sed subjektive, senservilo estas ĉielarko... Por mi, ĉi tiu temo estas tro malproksima kaj tro nekomprenebla. Mi ne estas preta paroli. En 2019, vi ne povas skribi ununuran aplikaĵon kun senservilo.
Kiel Kubernetes evoluos
— Dum ni iras al ĉi tiu eble mirinda malproksima estonteco, kiel vi pensas, ke Kubernetes kaj la ekosistemo ĉirkaŭ ĝi evoluos?
Dmitrio: Mi multe pensis pri tio kaj mi havas klaran respondon. La unua estas ŝtatplena - finfine, sennacia estas pli facile farebla. Kubernetes komence investis pli en ĉi tio, ĉio komenciĝis per ĝi. Sennacia funkcias preskaŭ perfekte en Kubernetes, estas nur nenio por plendi. Estas ankoraŭ multaj problemoj, aŭ pli ĝuste, nuancoj. Ĉio tie jam funkcias bonege por ni, sed tio estas ni. Necesos almenaŭ kelkaj pliaj jaroj por ke ĉi tio funkciu por ĉiuj. Ĉi tio ne estas kalkulita indikilo, sed mia sento el mia kapo.
Resume, statefull devus - kaj estos - disvolviĝi tre forte, ĉar ĉiuj niaj aplikaĵoj konservas statuson; ne ekzistas sennaciaj aplikoj. Ĉi tio estas iluzio; vi ĉiam bezonas ian datumbazon kaj ion alian. Statefull temas pri rektigi ĉion eblan, ripari ĉiujn cimojn, plibonigante ĉiujn problemojn, kiuj estas nuntempe konfrontitaj - ni nomu ĝin adopto.
La nivelo de la nekonataĵo, la nivelo de nesolvitaj problemoj, la nivelo de probableco renkonti ion grave malpliiĝos. Ĉi tio estas grava rakonto. Kaj funkciigistoj - ĉio rilata al la kodigo de administra logiko, kontrollogiko por akiri facilan servon: MySQL-facila servo, RabbitMQ-facila servo, Memcache-facila servo - ĝenerale, ĉiuj ĉi tiuj komponantoj, kiujn ni devas esti garantiitaj por labori el la skatolo. Ĉi tio nur solvas la doloron, ke ni volas datumbazon, sed ni ne volas administri ĝin, aŭ ni volas Kubernetes, sed ni ne volas administri ĝin.
Ĉi tiu rakonto pri evoluado de funkciigisto en unu aŭ alia formo estos grava en la venontaj du jaroj.
Mi pensas, ke la facileco de uzo devas multe pliiĝi - la skatolo fariĝos pli kaj pli nigra, pli kaj pli fidinda, kun pli kaj pli simplaj teniloj.
Mi iam aŭskultis malnovan intervjuon kun Isaac Asimov el la 80-aj jaroj ĉe Jutubo en Saturday Night Live - programo kiel Urgant, nur interesa. Ili demandis lin pri la estonteco de komputiloj. Li diris, ke la estonteco estas en simpleco, same kiel la radio. La radioricevilo estis origine kompleksa afero. Por kapti ondon, oni devis turni la butonojn dum 15 minutoj, turni la broketojn kaj ĝenerale scii kiel ĉio funkcias, kompreni la fizikon de radioonda dissendo. Kiel rezulto, ekzistis nur unu tenilo forlasita en la radio.
Nun en 2019 kia radio? En la aŭto, la radioricevilo trovas ĉiujn ondojn kaj la nomojn de la stacioj. La fiziko de la procezo ne ŝanĝiĝis en 100 jaroj, sed la facileco de uzo jes. Nun, kaj ne nur nun, jam en 1980, kiam okazis intervjuo kun Azimov, ĉiuj uzis la radion kaj neniu pensis pri kiel ĝi funkcias. Ĝi ĉiam funkciis - tio estas donita.
Azimov tiam diris, ke estos same kun komputiloj - facileco de uzo pliiĝos. Dum en 1980 oni devis esti trejnita por premi butonojn en komputilo, tio ne estos la kazo estonte.
Mi havas la senton, ke kun Kubernetes kaj kun la infrastrukturo ankaŭ estos grandega pliiĝo en facileco de uzado. Ĉi tio, laŭ mi, estas evidenta - ĝi kuŝas sur la surfaco.
Kion fari kun inĝenieroj?
— Kio do okazos al la inĝenieroj kaj sistemaj administrantoj, kiuj subtenas Kubernetes?
Dmitrio: Kio okazis al la librotenisto post la alveno de 1C? Pri la sama. Antaŭ tio, ili kalkulis sur papero – nun en la programo. Laborproduktiveco pliiĝis je grandordoj, sed laboro mem ne malaperis. Se antaŭe necesis 10 inĝenieroj por ŝraŭbi ampolon, nun unu sufiĉos.
La kvanto da programaro kaj la nombro da taskoj, ŝajnas al mi, nun kreskas pli rapide ol novaj DevOps aperas kaj efikeco pliiĝas. Estas specifa manko en la merkato nun kaj ĝi daŭros longe. Poste, ĉio revenos al ia normaleco, en kiu la efikeco de laboro pliiĝos, estos pli kaj pli senservilo, neŭrono estos alfiksita al Kubernetes, kiu elektos ĉiujn rimedojn ĝuste laŭbezone, kaj ĝenerale estos. faru ĉion mem, kiel ĝi devus - la persono nur forpaŝu kaj ne enmiksiĝi.
Sed iu ankoraŭ bezonos fari decidojn. Estas klare, ke la nivelo de kvalifikoj kaj specialiĝo de ĉi tiu persono estas pli alta. Nuntempe, en la kontada fako, oni ne bezonas 10 dungitojn tenantajn librojn, por ke iliaj manoj ne laciĝu. Simple ne necesas. Multaj dokumentoj estas aŭtomate skanitaj kaj rekonitaj de la elektronika dokumenta administra sistemo. Sufiĉas unu saĝa ĉefkontisto, jam kun multe pli grandaj kapabloj, kun bona kompreno.
Ĝenerale, ĉi tiu estas la vojo por iri en ĉiuj industrioj. Estas same kun aŭtoj: antaŭe venis aŭto kun mekanikisto kaj tri ŝoforoj. Nuntempe, veturi aŭton estas simpla procezo, en kiu ni ĉiuj partoprenas ĉiutage. Neniu pensas, ke aŭtomobilo estas io komplika.
DevOps aŭ sistema inĝenierado ne foriros - altnivela laboro kaj efikeco pliiĝos.
— Ankaŭ mi aŭdis interesan ideon, ke la laboro efektive pliiĝos.
Dmitrio: Kompreneble, cent elcentoj! Ĉar la kvanto de programaro, kiun ni skribas, konstante kreskas. La nombro da problemoj, kiujn ni solvas per programaro, konstante kreskas. La kvanto de laboro kreskas. Nun la DevOps-merkato estas terure trovarmigita. Ĉi tio povas esti vidita en salajraj atendoj. En bona maniero, sen eniri detalojn, estu junuloj, kiuj volas X, mezaj, kiuj volas 1,5X, kaj maljunuloj, kiuj volas 2X. Kaj nun, se vi rigardas la salajran merkaton de Moskvo DevOps, junulo volas de X al 3X kaj altrangulo volas de X al 3X.
Neniu scias kiom ĝi kostas. La salajra nivelo estas mezurata per via konfido - kompleta frenezulejo, honeste, terure trovarmigita merkato.
Kompreneble, ĉi tiu situacio ŝanĝiĝos tre baldaŭ - ia saturiĝo devus okazi. Ĉi tio ne okazas kun programaro - malgraŭ tio, ke ĉiuj bezonas programistojn, kaj ĉiuj bezonas bonajn programistojn, la merkato komprenas, kiu valoras kion - la industrio trankviliĝis. Tio ne estas la kazo kun DevOps nuntempe.
— Laŭ tio, kion mi aŭdis, mi konkludis, ke la nuna sistemadministranto ne tro zorgu, sed estas tempo ĝisdatigi siajn kapablojn kaj prepariĝi por tio, ke morgaŭ estos pli da laboro, sed ĝi estos pli altkvalifikita.
Dmitrio: Cent procento. Ĝenerale, ni vivas en 2019 kaj la regulo de vivo estas jena: dumviva lernado - ni lernas dum nia vivo. Ŝajnas al mi, ke nun ĉiuj jam scias kaj sentas tion, sed ne sufiĉas scii - vi devas fari ĝin. Ĉiutage ni devas ŝanĝiĝi. Se ni ne faros tion, tiam pli aŭ malpli frue ni estos faligitaj flanke de la profesio.
Estu preta por akraj 180-gradaj turnoj. Mi ne ekskludas situacion, kie io radikale ŝanĝiĝas, io nova estas inventita - ĝi okazas. Hop! — kaj ni nun agas alimaniere. Gravas esti preta por ĉi tio kaj ne zorgi. Povas okazi, ke morgaŭ ĉio, kion mi faras, estos nenecesa — nenio, mi studis dum mia tuta vivo kaj estas preta lerni ion alian. Ne estas problemo. Ne necesas timi laborsekurecon, sed vi devas esti preta konstante lerni ion novan.
Deziroj kaj minuto da reklamado
- Ĉu vi havas ian deziron?
Dmitrio: Jes, mi havas plurajn dezirojn.
Unue kaj komerca - abonu . Karaj legantoj, iru al Jutubo kaj abonu nian kanalon. Post ĉirkaŭ unu monato ni komencos aktivan ekspansion de la videoservo.Ni havos multe da eduka enhavo pri Kubernetes, malfermita kaj varia: de praktikaj aferoj, ĝis laboratorioj, ĝis profundaj fundamentaj teoriaj aferoj kaj kiel uzi Kubernetes ĉe la nivelo de principoj kaj ŝablonoj.
La dua komerca deziro - iru al kaj metu stelojn, ĉar ni nutras per ili. Se vi ne donos al ni stelojn, ni havos nenion por manĝi. Estas kiel manao en komputila ludo. Ni faras ion, ni faras, ni provas, iu diras, ke ĉi tiuj estas teruraj bicikloj, iu, ke ĉio estas tute malĝusta, sed ni daŭrigas kaj agas absolute honeste. Ni vidas problemon, solvas ĝin kaj dividas nian sperton. Tial donu al ni stelon, ĝi ne foriros de vi, sed ĝi venos al ni, ĉar ni manĝas per ili.
Tria, grava, kaj ne plu komerca deziro - ĉesu kredi je fabeloj. Vi estas profesiuloj. DevOps estas tre serioza kaj respondeca profesio. Ĉesu ludi en la laborejo. Lasu ĝin klaki por vi kaj vi komprenos ĝin. Imagu, ke vi venas al la hospitalo, kaj tie la kuracisto eksperimentas pri vi. Mi komprenas, ke tio eble estas ofenda por iu, sed, plej verŝajne, ĉi tio ne temas pri vi, sed pri iu alia. Diru ankaŭ al aliaj, ke ili ĉesu. Ĉi tio vere ruinigas la vivon por ĉiuj el ni - multaj komencas trakti operaciojn, administrantojn kaj DevOps kiel ulojn kiuj rompis ion denove. Ĉi tio estis "rompita" plej ofte pro tio, ke ni iris ludi, kaj ne rigardis kun malvarma konscio, ke tiel estas, kaj tiel estas.
Ĉi tio ne signifas, ke vi ne devus eksperimenti. Ni devas eksperimenti, ni faras ĝin mem. Verdire, ni mem foje ludas - tio, kompreneble, estas tre malbona, sed nenio homa estas fremda al ni. Ni deklaru 2019 jaro de seriozaj, bone pripensitaj eksperimentoj, kaj ne ludoj pri produktado. Verŝajne tiel.
- Dankegon!
Dmitrio: Dankon, Vitalij, kaj pro la tempo kaj pro la intervjuo. Karaj legantoj, koran dankon, se vi subite atingis ĉi tiun punkton. Mi esperas, ke ni alportis al vi almenaŭ kelkajn pensojn.
En la intervjuo, Dmitry tuŝis la temon de werf. Nun ĉi tio estas universala svisa tranĉilo, kiu solvas preskaŭ ĉiujn problemojn. Sed ne ĉiam estis tiel. On ĉe la festivalo Dmitry Stolyarov rakontos al vi pri ĉi tiu ilo detale. en la raporto estos ĉio: problemoj kaj kaŝitaj nuancoj de Kubernetes, ebloj por solvi ĉi tiujn malfacilaĵojn kaj la nunan efektivigon de werf detale. Aliĝu al ni la 27-an kaj 28-an de majo, ni kreos la perfektajn ilojn.
fonto: www.habr.com