In afwagting Vitaly Khabarov onderhoude gevoer Dmitri Stolyarov (), tegniese direkteur en medestigter van Flant. Vitaly het Dmitry gevra oor wat Flant doen, oor Kubernetes, ekosisteemontwikkeling en ondersteuning. Ons het bespreek waarom Kubernetes nodig is en of dit hoegenaamd nodig is. En ook oor mikrodienste, Amazon AWS, die “Ek is gelukkig”-benadering tot DevOps, die toekoms van Kubernetes self, hoekom, wanneer en hoe dit die wêreld gaan oorneem, die vooruitsigte vir DevOps en waarvoor ingenieurs moet voorberei in die blink en nabye toekoms met vereenvoudiging en neurale netwerke.
luister as 'n podcast op DevOps Deflop - 'n Russiestalige podcast oor DevOps, en hieronder - 'n teksweergawe.
Hier en onder word vrae gevra ingenieur van Express42.
Oor "Flant"
- Hallo Dima. Jy is die tegniese direkteuren ook die stigter daarvan. Vertel ons asseblief, wat doen die maatskappy en wat is jy daarin?
Dmitri: Van buite lyk dit of ons die soort ouens is wat rondgaan, Kubernetes vir almal installeer en iets daarmee doen. Maar dit is nie. Ons het begin as 'n Linux-maatskappy, maar vir 'n baie lang tyd was ons hoofaktiwiteit die diens van produksie- en sleutel-hoogladingsprojekte. Gewoonlik bou ons die hele infrastruktuur van nuuts af en dan is ons vir lank, lank daarvoor verantwoordelik. Daarom is die hoofwerk wat Flant verrig, waarvoor hy geld ontvang verantwoordelikheid te neem en sleutelproduksie te implementeer.
Ek, as 'n tegniese direkteur en een van die stigters van die maatskappy, werk die hele dag om uit te vind hoe om die beskikbaarheid van produksie te verhoog, die werking daarvan te vereenvoudig, die lewe vir admins makliker te maak en die lewe vir ontwikkelaars lekkerder te maak.
Oor Kubernetes
- Die afgelope tyd het ek baie berigte van Flant en oor Kubernetes. Hoe het jy na hom gekom?
Dmitri: Ek het al baie keer hieroor gepraat, maar ek gee glad nie om om dit te herhaal nie. Ek dink dat dit reg is om hierdie onderwerp te herhaal, want daar is 'n verwarring tussen oorsaak en gevolg.
Ons het regtig 'n hulpmiddel nodig gehad. Ons het baie probleme in die gesig gestaar, gesukkel, dit met verskillende krukke oorkom en die behoefte aan 'n gereedskap gevoel. Ons het deur baie verskillende opsies gegaan, ons eie fietse gebou, ervaring opgedoen. Geleidelik het ons by die punt gekom waar ons Docker begin gebruik het byna sodra dit verskyn het – rondom 2013. Ten tyde van sy verskyning het ons reeds baie ondervinding met houers gehad, ons het reeds 'n analoog van "Docker" geskryf - 'n soort van ons krukke in Python. Met die koms van Docker het dit moontlik geword om die krukke uit te gooi en 'n betroubare en gemeenskapsondersteunde oplossing te gebruik.
Met Kubernetes is die storie soortgelyk. Teen die tyd dat dit momentum begin kry het - vir ons is dit weergawe 1.2 - het ons reeds 'n klomp krukke op beide Shell en Chef gehad, wat ons op een of ander manier vir Docker probeer orkestreer het. Ons het ernstig gekyk na Rancher en verskeie ander oplossings, maar toe verskyn Kubernetes, waarin alles geïmplementeer word presies soos ons sou gedoen het of selfs beter. Niks om oor te kla nie.
Ja, daar is een of ander onvolmaaktheid hier, daar is een of ander onvolmaaktheid - baie onvolmaakthede, en 1.2 is oor die algemeen gruwel, maar .... Kubernetes is soos 'n gebou in aanbou - jy kyk na die projek en verstaan dat dit gaaf sal wees. As die gebou nou 'n fondament en twee verdiepings het, dan verstaan jy dat dit beter is om nog nie in te trek nie, maar daar is nie sulke probleme met die sagteware nie - jy kan dit reeds gebruik.
Ons het nie 'n oomblik gehad dat ons gedink het of ons Kubernetes moet gebruik of nie. Ons het lank voor hy verskyn het vir hom gewag en self analoë probeer maak.
Oor Kubernetes
- Is jy direk betrokke by die ontwikkeling van Kubernetes self?
Dmitri: Middelmatig. Ons neem eerder deel aan die ontwikkeling van die ekosisteem. Ons stuur 'n sekere aantal trekversoeke: aan Prometheus, aan allerhande operateurs, na Helm - na die ekosisteem. Ongelukkig is ek nie in staat om alles wat ons doen te volg nie en ek kan verkeerd wees, maar daar is nie 'n enkele poel van ons tot in die kern nie.
Ontwikkel jy terselfdertyd baie van jou gereedskap rondom Kubernetes?
Dmitri: Die strategie is dit: ons gaan trek-versoek alles wat reeds daar is. As trekversoeke nie daar aanvaar word nie, vurk ons dit eenvoudig aan onsself en leef totdat dit met ons geboue aanvaar word. Wanneer dit dan stroomop bereik, skakel ons terug na die stroomop-weergawe.
Ons het byvoorbeeld 'n Prometheus-operateur, waarmee ons waarskynlik al 5 keer heen en weer na die stroomop van ons vergadering oorgeskakel het. Ons het 'n soort kenmerk nodig, ons het 'n trekversoek gestuur, ons moet dit môre uitrol, maar ons wil nie wag totdat dit na die stroomop vrygestel word nie. Gevolglik maak ons vir onsself bymekaar, rol ons samestelling met ons kenmerk, wat ons om een of ander rede nodig het, na al ons groepe. Dan draai hulle dit byvoorbeeld stroomop toe met die woorde: “Ouens, kom ons doen dit vir ’n meer algemene saak”, ons, of iemand anders, maak dit klaar, en mettertyd smelt dit weer saam.
Alles wat bestaan, probeer ons ontwikkel. Baie elemente wat nog nie bestaan nie, nog nie uitgevind of uitgevind is nie, maar nie tyd gehad het om te implementeer nie – ons doen dit. En nie omdat ons van die proses self of fietsry as 'n bedryf hou nie, maar bloot omdat ons hierdie hulpmiddel nodig het. Die vraag word dikwels gevra, hoekom het ons hierdie of daardie ding gedoen? Die antwoord is eenvoudig - ja, want ons moes verder gaan, een of ander praktiese probleem oplos, en ons het dit met hierdie hulpmiddel opgelos.
Die manier is altyd so: ons soek baie versigtig en as ons geen oplossing kry oor hoe om 'n trolliebus van 'n brood te maak nie, dan maak ons ons eie brood en ons eie trolliebus.
Vlak gereedskap
- Ek weet dat Flant nou addon-operateurs, dopoperateurs, dapp / werf-gereedskap het. Soos ek dit verstaan, is dit dieselfde instrument in verskillende inkarnasies. Ek verstaan ook dat daar baie meer verskillende instrumente binne Flant is. Dit is waar?
Dmitri: Ons het baie meer op GitHub. Van wat ek nou onthou, het ons 'n statuskaart - 'n paneel vir Grafana, wat aan almal gegaan het. Dit word in byna elke tweede artikel genoem oor die monitering van Kubernetes op Medium. Dit is onmoontlik om kortliks te beskryf wat 'n statuskaart is - ons het 'n aparte artikel nodig, maar dit is 'n baie nuttige ding om status oor tyd te monitor, aangesien ons in Kubernetes dikwels status oor tyd moet wys. Ons het ook LogHouse - dit is 'n ding wat gebaseer is op ClickHouse en swart magie vir die versameling van logs in Kubernetes.
Baie hulpmiddels! En daar sal selfs meer wees, want 'n aantal interne oplossings sal vanjaar vrygestel word. Van die baie groots wat gebaseer is op die addon-operateur, is daar 'n klomp addons vir Kubernetes ala hoe om sert-bestuurder korrek te installeer - 'n instrument om sertifikate te bestuur, hoe om Prometheus behoorlik te installeer met 'n klomp body kits - dit is ongeveer twintig verskillende binaries wat data uitvoer en iets insamel, daarom het Prometheus die pragtigste grafika en mooiste grafika. Dit alles is net 'n klomp Kubernetes-byvoegings wat in die groep geplaas word, en dit verander van eenvoudig na koel, fancy, outomaties, waarin baie probleme reeds opgelos is. Ja, ons doen baie.
Ekosisteem ontwikkeling
— Dit lyk vir my of dit 'n baie groot bydrae is tot die ontwikkeling van hierdie instrument en sy gebruiksmetodes. Kan jy rofweg skat wie anders dieselfde bydrae tot die ontwikkeling van die ekosisteem sou maak?
Dmitri: In Rusland, van die maatskappye wat in ons mark werk, is niemand eens naby nie. Dit is natuurlik ’n groot stelling, want daar is groot spelers soos Mail en Yandex – hulle doen ook iets met Kubernetes, maar selfs hulle het nie naby gekom aan die bydrae van maatskappye in die hele wêreld wat veel meer as ons doen nie. Dit is moeilik om Flant te vergelyk met 'n personeel van 80 mense en Red Hat, waarin daar 300 ingenieurs is vir slegs een Kubernetes, as ek my nie misgis nie. Dit is moeilik om te vergelyk. Ons het 6 mense in die R&D-afdeling, ek ingesluit, wat al ons gereedskap sny. 6 mense teenoor 300 Red Hat-ingenieurs - dit is nogal moeilik om te vergelyk.
“Nietemin, wanneer selfs hierdie 6 mense iets werklik nuttig en vervreembaar kan doen, wanneer hulle 'n praktiese probleem in die gesig staar en die oplossing aan die gemeenskap gee, is dit 'n interessante geval. Ek verstaan dat in groot tegnologiemaatskappye wat hul eie ontwikkeling- en Kubernetes-ondersteuningspan het, in beginsel dieselfde gereedskap ontwikkel kan word. Dit is 'n voorbeeld vir hulle wat ontwikkel en aan die gemeenskap gegee kan word, om stukrag te gee aan die hele gemeenskap wat Kubernetes gebruik.
Dmitri: Waarskynlik, dit is die kenmerk van die integreerder, sy eienaardigheid. Ons het baie projekte en ons sien baie verskillende situasies. Vir ons is die belangrikste manier om toegevoegde waarde te skep om hierdie sake te ontleed, gemeenskaplike grond te vind en dit so goedkoop as moontlik vir ons te maak. Dit is waarmee ons aktief besig is. Dit is vir my moeilik om oor Rusland en die wêreld te praat, maar ons het ongeveer 40 DevOps-ingenieurs in die maatskappy wat by Kubernetes betrokke is. Ek dink nie daar is baie maatskappye in Rusland met 'n vergelykbare aantal spesialiste wat Kubernetes verstaan, as hulle enigsins bestaan nie.
Ek verstaan alles oor die titel van die pos DevOps-ingenieur, almal verstaan alles en is gewoond daaraan om DevOps-ingenieurs DevOps-ingenieurs te noem, ons sal dit nie bespreek nie. Al hierdie 40 ongelooflike DevOps-ingenieurs staar probleme in die gesig en los dit elke dag op, ons ontleed net hierdie ervaring en probeer veralgemeen. Ons verstaan dat as dit binne-in ons bly, dan sal die instrument oor 'n jaar of twee nutteloos wees, want iewers in die gemeenskap sal 'n klaargemaakte hulpmiddel verskyn. Dit maak geen sin om hierdie ervaring binne te versamel nie - dit is net 'n mors van tyd en moeite in dev/nul. En ons kry glad nie jammer daaroor nie. Ons publiseer alles met groot plesier en verstaan dat dit gepubliseer, ontwikkel, bevorder, bevorder moet word sodat mense hul ervaring kan gebruik en byvoeg – dan groei en lewe alles. Dan na twee jaar gaan die gereedskap nie na die asblik nie. Dit is nie jammer om voort te gaan om krag in te blaas nie, want dit is duidelik dat iemand jou instrument gebruik, en oor twee jaar gebruik almal dit reeds.
Dit is deel van ons groot strategie met dapp/werf. Ek onthou nie wanneer ons dit begin doen het nie, ek dink so 3 jaar gelede. Aanvanklik was dit oor die algemeen op die dop. Dit was 'n super proof of concept, ons het van ons privaat take opgelos - dit het gewerk! Maar daar is probleme met die dop, dit is onmoontlik om dit verder te vergroot, programmering op die dop is 'n ander beroep. Ons het 'n gewoonte gehad om in Ruby te skryf, so ons het iets in Ruby oorgedoen, ontwikkel, ontwikkel, ontwikkel, en het in die feit vasgeloop dat die gemeenskap, die skare wat nie sê "ons wil of wil nie", hul neuse optrek vir Ruby, hoe snaaks dit is. Ons het besef dat ons al hierdie goedheid in Go moet skryf om eenvoudig aan die eerste item in die kontrolelys te voldoen: DevOps-instrument moet 'n statiese binêre wees. Op Go of nie op Go, dit maak nie regtig saak nie, maar 'n statiese binêre geskryf in Go is beter.
Ons het ons energie spandeer, dapp in Go herskryf en dit werf genoem. Dapp word nie meer onderhou, nie ontwikkel nie, loop op een of ander nuutste weergawe, maar daar is 'n absolute opgraderingspad na bo wat gevolg kan word.
Hoekom is dapp geskep?
— Kan jy ons kortliks vertel hoekom dapp geskep is, watter probleme los dit op?
Dmitri: Die eerste rede is in die vergadering. Aanvanklik het ons ernstige bouprobleme gehad toe Docker nie geweet het hoe om multi-stadium te maak nie, en ons het multi-stadium op ons eie gemaak. Toe het ons nog 'n klomp vrae oor beeldskoonmaak gehad. Almal wat CI / CD doen, vroeër eerder as later, staar die probleem in die gesig dat daar 'n klomp versamelde beelde is, jy moet op een of ander manier skoonmaak wat nie nodig is nie, en los wat nodig is.
Die tweede rede is ontplooiing. Ja, daar is Helm, maar dit los net 'n deel van die probleme op. Ironies genoeg staan daar "Helm - die Pakketbestuurder vir Kubernetes". Presies wat "die". Daar is ook die woorde "Pakketbestuurder" - wat is die gewone verwagting van die Pakketbestuurder? Ons sê: "Pakketbestuurder - installeer die pakket!" en ons verwag dat hy vir ons sal sê: "Die pakkie is afgelewer."
Interessant genoeg sê ons: "Helm, installeer die pakket", en wanneer hy antwoord dat hy dit geïnstalleer het, blyk dit dat hy pas die installasie begin het - hy het Kubernetes aangedui: "Run this thing!", En of dit begin het of nie, werk of nie, Helm los hierdie probleem glad nie op nie.
Dit blyk dat Helm net 'n teksvoorverwerker is wat data in Kubernetes laai.
Maar binne die raamwerk van enige ontplooiing wil ons weet of die toepassing na produksie uitgerol het of nie? Dit het uitgerol na die prod, wat beteken dat die toepassing daarheen gegaan het, die nuwe weergawe het ontvou, en dit val ten minste nie daar nie en antwoord korrek. Helm los hierdie probleem op geen manier op nie. Om dit op te los, moet jy baie moeite spandeer, want jy moet Kubernetes 'n opdrag gee om uit te rol en te monitor wat daar gebeur - of dit omgedraai het, of dit uitgerol het. En daar is baie take wat verband hou met ontplooiing, skoonmaak en montering.
Planne
Hierdie jaar gaan ons in op plaaslike ontwikkeling. Ons wil kom na wat voorheen in Vagrant was - ons het "vagrant up" getik en ons virtuele masjiene het omgedraai. Ons wil tot so 'n toestand kom dat daar 'n projek in Git is, ons skryf "werf daarbo", en dit bring 'n plaaslike kopie van hierdie projek op, ontplooi in 'n plaaslike mini-Kub, met alle gidse wat gerieflik is vir ontwikkeling ingesluit. Afhangende van die ontwikkelingstaal, word dit op verskillende maniere gedoen, maar nietemin sodat jy gerieflik plaaslike ontwikkeling onder gemonteerde lêers kan uitvoer.
Die volgende stap vir ons is sterk belê in ontwikkelaarvriendelikheid. Om die projek vinnig plaaslik met een instrument te ontplooi, ontwikkel dit, druk dit na Git, en dit sal ook na die verhoog of toetse uitrol, afhangende van die pyplyne, en dan met dieselfde instrument na produksie gaan. Hierdie eenheid, eenwording, reproduceerbaarheid van die infrastruktuur vanaf die plaaslike omgewing tot die verkoop is 'n baie belangrike punt vir ons. Maar dit is nog nie in werf nie – ons beplan net om dit te doen.
Maar die pad na dapp/werf was nog altyd dieselfde as met Kubernetes in die begin. Ons het probleme in die gesig gestaar, dit opgelos deur oplossings - ons het 'n paar oplossings vir onsself op die dop, oor enigiets, vorendag gekom. Toe het hulle probeer om op een of ander manier hierdie oplossings in hierdie geval reguit te maak, te veralgemeen en te konsolideer in binaries, wat ons eenvoudig deel.
Daar is 'n ander siening van hierdie hele verhaal, met analogieë.
Kubernetes is die skelet van 'n motor met 'n enjin. Daar is geen deure, geen vensters, geen radio, geen Kersboom nie - glad niks. Slegs raam en enjin. En daar is Helm - dit is die stuurwiel. Cool - daar is 'n stuurwiel, maar jy benodig ook 'n stuurpen, stuurrak, ratkas en wiele, maar jy kan nie daarsonder nie.
In die geval van werf is dit nog 'n komponent vir Kubernetes. Nou eers in ons alfa weergawe van werf word Helm byvoorbeeld enigsins in werf saamgestel, want ons is moeg daarvoor om dit self te doen. Daar is baie redes om dit te doen, in detail oor hoekom ons die hele stuur saamgestel het met helmstok binne werf, sal ek net vertel .
Nou is werf 'n meer geïntegreerde komponent. Ons kry 'n voltooide stuurwiel, 'n stuurpen - ek verstaan nie motors baie goed nie, maar dit is 'n groot eenheid wat reeds 'n redelike wye reeks take oplos. Ons hoef nie self deur die katalogus te klim nie, een deel vir 'n ander te kies, te dink oor hoe om hulle saam te skroef. Ons kry 'n klaargemaakte stroper wat 'n groot bondel take op een slag oplos. Maar binne is dit alles gebou uit dieselfde oopbronkomponente, alles gebruik ook Docker vir samestelling, Helm vir sommige van die funksionaliteit, en daar is verskeie ander biblioteke. Dit is 'n geïntegreerde hulpmiddel om koel CI/CD vinnig en gerieflik uit die boks te kry.
Is dit moeilik om Kubernetes in stand te hou?
- Jy praat oor die ervaring dat jy Kubernetes begin gebruik het, dit is 'n raam vir jou, 'n enjin, en dat jy baie verskillende goed daaraan kan hang: bak, stuurwiel, pedale vas, sitplekke. Die vraag ontstaan - hoe moeilik is dit vir jou om Kubernetes te ondersteun? Jy het 'n magdom ervaring, hoeveel tyd en hulpbronne spandeer jy spesifiek om Kubernetes te ondersteun in isolasie van alles anders?
Dmitri: Dit is 'n baie komplekse vraag en om dit te beantwoord, moet jy verstaan wat ondersteuning is en wat ons van Kubernetes wil hê. Kan jy dalk oopmaak?
- Sover ek weet en soos ek sien, wil baie spanne nou Kubernetes probeer. Almal word daartoe ingespan, op hul knieë gesit. Ek het 'n gevoel dat mense nie altyd die kompleksiteit van hierdie stelsel verstaan nie.
Dmitri: Dit is so.
- Hoe moeilik is dit om Kubernetes uit niks te neem en te installeer, sodat dit produksiegereed is?
Dmitri: Hoe moeilik dink jy is dit om 'n hart oor te plant? Ek verstaan die vraag is kompromie. Om 'n skalpel te dra en nie 'n fout te maak nie, is nie so moeilik nie. As jy vertel word waar om af te sny en waar om naaldwerk te maak, dan is die prosedure self eenvoudig. Dit is moeilik om van tyd tot tyd te waarborg dat alles sal uitwerk.
Dit is maklik om Kubernetes te installeer en dit te laat werk: chick! - gestel, daar is baie maniere om te installeer. Maar wat gebeur wanneer probleme opduik?
Vrae ontstaan altyd – wat het ons nog nie in ag geneem nie? Wat het ons nog nie gedoen nie? Watter parameters van die Linux-kern is verkeerd gespesifiseer? Here, het ons hulle enigsins genoem?! Watter Kubernetes-komponente het ons gestuur en watter nie? Duisende vrae ontstaan, en om dit te beantwoord, moet jy vir 15-20 jaar in hierdie bedryf kook.
Ek het 'n onlangse voorbeeld oor hierdie onderwerp wat dalk sin maak van die "Is dit moeilik om Kubernetes in stand te hou?"-probleem. 'n Tyd gelede het ons dit ernstig oorweeg om Cilium as 'n netwerk in Kubernetes te probeer implementeer.
Kom ek verduidelik wat Cilium is. Daar is baie verskillende implementerings van die netwerksubstelsel in Kubernetes, en een van hulle is baie gaaf - dit is Cilium. Wat is die betekenis daarvan? 'n Tyd gelede het die kern die vermoë bekendgestel om hake vir die kern te skryf, wat op een of ander manier die netwerksubstelsel en verskeie ander substelsels binnedring, en jou toelaat om groot stukke in die kern te omseil.
Die Linux-kern het histories 'n ip-roete, 'n oorfilter, brûe en baie verskillende ou komponente wat 15, 20, 30 jaar oud is. Oor die algemeen werk hulle, alles is gaaf, maar nou het hulle houers opgestapel, en dit lyk soos 'n rewolwer van 15 bakstene bo-op mekaar, en jy staan daarop op een been - 'n vreemde gevoel. Hierdie stelsel het histories ontwikkel met baie nuanses, soos die aanhangsel in die liggaam. Daar is prestasieprobleme in sommige situasies, bv.
Daar is 'n wonderlike BPF en die vermoë om hake vir die kern te skryf - die ouens het hul eie hake vir die kern geskryf. Die pakkie kom in die Linux-kern, hulle haal dit reg by die ingang uit, verwerk dit self soos dit moet sonder brûe, sonder TCP, sonder 'n IP-stack - kortom, omseil alles wat in die Linux-kern geskryf is, en spoeg dit dadelik in die houer uit.
Wat het gebeur? Baie cool prestasie, cool kenmerke - net cool! Maar ons kyk daarna en sien dat elke masjien 'n program het wat aan die Kubernetes API koppel en, volgens die data wat dit van hierdie API ontvang, C-kode genereer en binaries saamstel wat dit in die kern laai sodat hierdie hake in die kernspasie werk.
Wat gebeur as iets verkeerd loop? Ons weet nie. Om dit te verstaan, moet jy al hierdie kode lees, al die logika verstaan, en dis verstom hoe moeilik dit is. Maar aan die ander kant is daar hierdie brûe, netfilters, ip-roetes - ek het nie hul bronkodes gelees nie, en 40 ingenieurs wat ook in ons maatskappy werk. Miskien verstaan sommige stukke eenhede.
En wat is die verskil? Dit blyk dat daar ip-roete is, die Linux-kern, en daar is 'n nuwe instrument - wat is die verskil, ons verstaan nie die een of die ander nie. Maar ons is bang om die nuwe te gebruik – hoekom? Want as die instrument 30 jaar oud is, dan is al die goggas oor 30 jaar gevind, al die harke is getrap en jy hoef nie van alles te weet nie - dit werk soos 'n swart boks, en dit werk altyd. Almal weet watter diagnostiese skroewedraaier om op watter plek te plak, watter tcpdump om op watter oomblik te hardloop. Almal ken diagnostiese nutsprogramme goed en verstaan hoe hierdie stel komponente in die Linux-kern werk - nie hoe dit werk nie, maar hoe om dit te gebruik.
En die ontsagwekkende koel Cilium is nie 30 jaar oud nie, dit het nog nie volwasse geword nie. Dieselfde probleem met Kubernetes, kopieer. Dat Cilium wonderlik is, dat Kubernetes wonderlik is, maar wanneer iets verkeerd loop in die produksie, kan jy vinnig verstaan wat verkeerd geloop het in 'n kritieke situasie?
Wanneer ons sê of dit moeilik is om Kubernetes in stand te hou - nee, baie eenvoudig, en ja, ongelooflik moeilik. Kubernetes werk uitstekend op sy eie, maar met 'n miljard nuanses.
Oor die "Ek voel gelukkig"-benadering
— Is daar maatskappye waar hierdie nuanses amper gewaarborg sal wees? Gestel Yandex dra skielik alle dienste na Kubernetes oor, daar sal 'n groot vrag daar wees.
Dmitri: Nee, dit is nie 'n gesprek oor die vrag nie, maar oor die eenvoudigste dinge. Ons het byvoorbeeld Kubernetes, ons het 'n toepassing daar ontplooi. Hoe om te verstaan dat dit werk? Daar is eenvoudig geen gereedgemaakte hulpmiddel om te verstaan dat die toepassing nie ineenstort nie. Daar is geen gereedgemaakte stelsel wat waarskuwings stuur nie, jy moet hierdie waarskuwings en elke grafiek opstel. En ons werk Kubernetes op.
Daar is Ubuntu 16.04. Ons kan sê dat dit 'n ou weergawe is, maar ons is steeds daarop, want daar is LTS. Daar is systemd, wat die waarskuwing het dat dit nie C-groepe skoonmaak nie. Kubernetes begin die peule, skep C-groepe, vee dan die peule uit, en op een of ander manier blyk dit - ek onthou nie die besonderhede nie, jammer - dat die systemd-skywe oorbly. Dit lei daartoe dat enige motor met verloop van tyd baie stadiger begin ry. Dit is nie eens 'n vraag oor hoëlading nie. As aanhoudende peule loop, byvoorbeeld, as daar 'n Cron Job is wat voortdurend peule genereer, sal 'n Ubuntu 16.04-masjien na 'n week begin stadiger word. Daar sal 'n konstante hoë lasgemiddelde wees as gevolg van die feit dat 'n klomp C-groepe geskep word. Dit is 'n probleem wat enigiemand wat net Ubuntu 16 en Kubernetes bo-op sit, het.
Kom ons sê dit werk op een of ander manier systemd of iets anders op, maar in die Linux-kern voor 4.16 is dit selfs snaakser - wanneer jy C-groepe uitvee, lek hulle in die kern en word nie eintlik uitgevee nie. Daarom, na 'n maand se werk aan hierdie masjien, sal dit onmoontlik wees om geheuestatistieke vir peule te sien. Ons haal 'n lêer uit, rol dit in die program, en een lêer rol vir 15 sekondes, want die kern neem baie lank om miljoene C-groepe binne homself te tel, wat blykbaar uitgevee is, maar nee - hulle lek.
Hier en daar is nog baie sulke klein goedjies. Dit is nie 'n vraag waarmee reuse-maatskappye soms onder baie swaar vragte te staan kom nie - nee, dit is 'n kwessie van daaglikse dinge. Mense kan maande lank so lewe – hulle het Kubernetes geïnstalleer, die toepassing ontplooi – dit lyk of dit werk. Baie mense is goed daarmee. Hulle sal nie eers weet dat hierdie toepassing om een of ander rede eendag sal ineenstort, die waarskuwing sal nie kom nie, maar vir hulle is dit die norm. Voorheen het hulle op virtuele masjiene gewoon sonder monitering, nou het hulle ook sonder monitering na Kubernetes verhuis - wat is die verskil?
Die probleem is dat wanneer ons op ys loop, ons nooit die dikte daarvan weet nie, tensy ons dit vooraf meet. Baie gaan en bad nie, want hulle het gegaan.
Uit my oogpunt is die nuanse en kompleksiteit van die bedryf van enige stelsel om te verseker dat die dikte van die ys presies genoeg is om ons probleme op te los. Dit gaan hieroor.
In IT dink ek daar is te veel "I'm Feeling Lucky"-benaderings. Baie installeer sagteware, gebruik sagteware biblioteke in die hoop dat hulle gelukkig sal wees. Oor die algemeen is baie mense gelukkig. Dis seker hoekom dit werk.
- Uit my pessimistiese beoordeling lyk dit so: wanneer die risiko's hoog is, en die toepassing behoort te werk, dan benodig jy ondersteuning van Flant, moontlik van Red Hat, of jy benodig jou eie interne span wat spesifiek toegewy is aan Kubernetes, wat gereed is om dit te trek.
Dmitri: Objektief is dit. Om met Kubernetes op jou eie met 'n klein span in die storie te kom, is 'n sekere mate van risiko.
Het ons houers nodig?
— Kan jy ons vertel hoe algemeen Kubernetes in Rusland is?
Dmitri: Ek het nie hierdie data nie en ek is nie seker of iemand dit het nie. Ons sê: "Kubernetes, Kubernetes", maar daar is 'n ander manier om na hierdie kwessie te kyk. Ek weet ook nie hoe algemeen houers is nie, maar ek ken wel 'n syfer uit berigte op die internet dat 70% van houers deur Kubernetes georkestreer word. Dit was 'n betroubare bron vir 'n redelike groot steekproef regoor die wêreld.
Dan nog 'n vraag - het ons houers nodig? Ek het 'n persoonlike gevoel en oor die algemeen is die posisie van die Flant-maatskappy sodanig dat Kubernetes die de facto standaard is.
Daar sal niks anders as Kubernetes wees nie.
Dit is 'n absolute spel-wisselaar in infrastruktuurbestuur. Net absoluut - dit is dit, nie meer Ansible, Chef, virtuele masjiene, Terraform nie. Ek praat nie van die ou kollektiewe plaasmetodes nie. Kubernetes is die absolute veranderaar, en nou sal dit net so wees.
Dit is duidelik dat iemand 'n paar jaar nodig het, en iemand 'n paar dekades, om dit te besef. Ek het geen twyfel dat daar niks anders as Kubernetes en hierdie nuwe voorkoms sal wees nie: ons maak nie meer die bedryfstelsel seer nie, maar gebruik infrastruktuur as kode, maar nie met kode nie, maar met yml - 'n deklaratief beskryfde infrastruktuur. Ek het 'n gevoel dit sal altyd die geval wees.
- Dit wil sê, daardie maatskappye wat nog nie na Kubernetes oorgeskakel het nie, sal beslis daarna oorskakel of in die vergetelheid bly. Ek het jou reg verstaan?
DmitriA: Dit is ook nie heeltemal waar nie. Byvoorbeeld, as ons 'n taak het om 'n dns-bediener te laat loop, kan dit op FreeBSD 4.10 uitgevoer word en dit kan vir 20 jaar goed werk. Net werk is al. Miskien sal iets oor 20 jaar een keer opgedateer moet word. As ons praat oor sagteware in die formaat wat ons van stapel gestuur het en dit werk regtig vir baie jare sonder enige opdaterings, sonder om veranderinge aan te bring, dan sal daar natuurlik geen Kubernetes wees nie. Hy is nie daar nodig nie.
Alles wat verband hou met CI / CD - waar jy ook al deurlopende aflewering nodig het, waar jy weergawes moet opdateer, aktiewe veranderinge moet maak, waar jy ook al moet fouttoleransie bou - net Kubernetes.
Oor mikrodienste
- Hier het ek 'n effense dissonansie. Om met Kubernetes te werk, benodig jy eksterne of interne ondersteuning - dit is die eerste punt. Die tweede is wanneer ons net begin met ontwikkeling, ons is 'n klein begin, ons het nog niks, ontwikkeling vir Kubernetes of oor die algemeen vir 'n mikrodiens-argitektuur kan moeilik wees, en nie altyd ekonomies geregverdig nie. Ek stel belang in jou mening - moet beginners dadelik van voor af vir Kubernetes begin skryf, of kan hulle steeds 'n monoliet skryf, en dan eers na Kubernetes toe kom?
Dmitri: Cool vraag. Ek praat oor mikrodienste Ek het al baie keer op die feit afgekom dat mense probeer om spykers met 'n mikroskoop te slaan. Die benadering self is korrek, ons ontwerp self die interne sagteware op hierdie manier. Maar wanneer jy dit doen, moet jy duidelik verstaan wat jy doen. Wat ek die meeste van mikrodienste haat, is die woord "mikro". Histories het hierdie woord daar ontstaan, en om een of ander rede dink mense dat mikro baie klein is, minder as 'n millimeter, soos 'n mikrometer. Dis verkeerd.
Daar is byvoorbeeld 'n monoliet wat deur 300 mense geskryf is, en almal wat aan die ontwikkeling deelgeneem het, verstaan dat daar probleme daar is, en dit moet in mikrostukke opgebreek word - 10 stukke, wat elk deur 30 mense in die minimum weergawe geskryf is. Dit is belangrik, nodig en cool. Maar wanneer 'n begin by ons kom, waar 3 baie cool en talentvolle ouens 60 mikrodienste op hul knieë geskryf het, elke keer as ek na Corvalol soek.
Dit lyk vir my of dit al duisende kere gesê is – hulle het 'n verspreide monoliet in een of ander vorm gekry. Dit is nie ekonomies geregverdig nie, dit is oor die algemeen baie moeilik in alles. Dit is net dat ek dit al soveel keer gesien het dat dit my regtig seermaak, so ek hou aan om daaroor te praat.
Op die aanvanklike vraag, dat daar 'n konflik is tussen die feit dat, aan die een kant, Kubernetes skrikwekkend is om te gebruik, want dit is nie duidelik wat kan breek of misluk om daar te werk nie, aan die ander kant, is dit duidelik dat alles daar gaan en niks anders as Kubernetes sal wees nie. Antwoord - weeg die hoeveelheid voordeel wat kom, die hoeveelheid take wat jy kan oplos. Dit is aan die een kant van die skaal. Aan die ander kant is daar risiko's wat verband hou met stilstand of met 'n afname in reaksietyd, beskikbaarheidsvlak - met 'n afname in prestasie.
Hier is dit - óf ons beweeg vinnig, en Kubernetes laat jou toe om baie dinge baie vinniger en beter te doen, óf betroubare, beproefde oplossings te gebruik, maar beweeg baie stadiger. Hierdie keuse moet deur elke maatskappy gemaak word. Jy kan dit as 'n paadjie in die oerwoud beskou - wanneer jy vir die eerste keer stap, kan jy 'n slang, 'n tier of 'n hondsdol das ontmoet, en as jy 10 keer gegaan het, het jy die paadjie getrap, die takke verwyder en makliker gestap. Elke keer word die pad wyer. Dan is dit al 'n asfaltpad, en later 'n pragtige boulevard.
Kubernetes staan nie stil nie. Nog 'n vraag: Kubernetes, aan die een kant, is 4-5 binaries, aan die ander kant is dit die hele ekosisteem. Dit is die bedryfstelsel wat ons op die masjiene het. Wat is hierdie? Ubuntu of Curios? Dit is die Linux-kern, 'n klomp ekstras. Al hierdie dinge hier, een giftige slang is uit die pad gegooi, 'n heining is daar opgesit. Kubernetes ontwikkel baie vinnig en dinamies, en die volume risiko's, die volume van die onbekende neem elke maand af en dienooreenkomstig word hierdie skale herbalanseer.
As ek die vraag beantwoord oor wat 'n beginonderneming moet doen, sou ek sê - kom na Flant, betaal 150 duisend roebels en kry DevOps maklike diens op 'n sleutel-basis. As jy 'n klein begin met verskeie ontwikkelaars is, werk dit. In plaas daarvan om jou eie DevOps te huur, wat sal moet leer hoe om jou probleme op te los en op hierdie tydstip 'n salaris te betaal, sal jy 'n sleuteloplossing vir alle kwessies ontvang. Ja, daar is 'n paar nadele. Ons, as 'n uitkontrakter, kan nie so betrokke wees en vinnig reageer op veranderinge nie. Maar ons het baie kundigheid, klaargemaakte praktyke. Ons waarborg dat ons in enige situasie dit beslis vinnig sal uitvind en enige Kubernetes van die ander wêreld sal opwek.
Ek beveel sterk aan om uitkontraktering aan startups en gevestigde besighede tot 'n grootte waar jy 'n span van 10 mense kan toewys om te werk, want anders is daar geen sin nie. Dit maak absoluut sin om uit te kontrakteer.
Oor Amazon en Google
- Kan 'n gasheer van 'n oplossing van Amazon of Google as 'n uitkontrakter beskou word?
Dmitri: Ja, natuurlik, dit los 'n aantal probleme op. Maar weereens, nuanses. Jy moet nog verstaan hoe om dit te gebruik. Byvoorbeeld, daar is 'n duisend klein dingetjies in die werk van Amazon AWS: jy moet die Load Balancer opwarm of vooraf 'n versoek skryf dat "ouens, ons sal verkeer kry, die Load Balancer vir ons opwarm!" Jy moet hierdie nuanses ken.
As jy mense kontak wat hierin spesialiseer, kry jy amper al die tipiese goed toe. Ons het nou 40 ingenieurs, teen die einde van die jaar sal daar seker 60 van hulle wees – ons het beslis al hierdie dinge teëgekom. Selfs as ons op een of ander projek weer hierdie probleem teëkom, vra ons vinnig vir mekaar en weet hoe om dit op te los.
Waarskynlik, die antwoord is dit - natuurlik fasiliteer die aangebied-verhaal 'n deel. Die vraag is of jy gereed is om hierdie gashere te vertrou en of hulle jou probleme sal oplos. Amazon en Google het goed gevaar. Vir al ons gevalle - vir seker. Ons het geen ander positiewe ervarings nie. Al die ander wolke waarmee ons probeer werk het, skep baie probleme - en Ager, en alles wat in Rusland is, en allerhande OpenStack in verskillende implementerings: Headster, Overage - wat jy ook al wil hê. Hulle skep almal probleme wat jy nie wil oplos nie.
Daarom is die antwoord ja, maar in werklikheid is daar nie baie volwasse gasheeroplossings nie.
Wie het Kubernetes nodig?
- En tog, wie het Kubernetes nodig? Wie moet reeds oorskakel na Kubernetes, wie is 'n tipiese Flant-kliënt wat spesifiek vir Kubernetes kom?
Dmitri: Die vraag is interessant, want nou, net op die golf van Kubernetes, kom baie mense na ons toe: “Ouens, ons weet dat julle Kubernetes doen, doen dit vir ons!”. Ons antwoord hulle: "Mene, ons maak nie Kubernetes nie, ons maak prod en alles wat daarmee verband hou." Want om 'n produksie te maak sonder om al die CI/CD en al hierdie geskiedenis te doen, is tans eenvoudig onmoontlik. Almal het wegbeweeg van die verdeeldheid dat ons ontwikkeling deur ontwikkeling het, en dan uitbuiting deur uitbuiting.
Ons kliënte verwag verskillende dinge, maar almal wag vir een of ander soort wonderwerk dat hulle hierdie of daardie probleem het, en nou - hop! - Kubernetes sal dit oplos. Mense glo in wonderwerke. Hulle verstaan met hulle verstand dat daar geen wonderwerk sal wees nie, maar hulle hoop met hulle siele - wat as hierdie Kubernetes nou alles vir ons sal besluit, hulle praat so baie daaroor! Skielik is hy nou – nies! — en 'n silwer koeël, nies! - en ons het 100% uptyd, alle ontwikkelaars kan 50 keer enigiets vir produksie vrystel, en dit val nie. Oor die algemeen 'n wonderwerk!
Wanneer sulke mense na ons toe kom, sê ons: "Jammer, maar 'n wonderwerk gebeur nie." Om gesond te wees, moet jy goed eet en oefen. Om 'n betroubare produk te hê, moet dit betroubaar gedoen word. Om 'n gerieflike CI / CD te hê, moet dit so gemaak word. Dit is baie werk wat gedoen moet word.
Beantwoord die vraag, wie het Kubernetes nodig, niemand het Kubernetes nodig nie.
Sommige mense het die verkeerde gevoel dat hulle Kubernetes nodig het. Mense het 'n baie diep behoefte om op te hou dink, doen, belangstel in al die probleme van die infrastruktuur en die probleme om hul toepassings te bestuur. Hulle wil hê toepassings moet net werk en ontplooi. Vir hulle is Kubernetes die hoop dat hulle sal ophou om die storie te hoor dat “ons het daar gelê”, of “ons kan nie uitrol nie”, of iets anders.
Die tegniese direkteur kom gewoonlik na ons toe. Hulle vra hom twee dinge: gee ons aan die een kant kenmerke, aan die ander kant stabiliteit. Ons stel voor dat jy dit op jouself neem en dit doen. Die silwer koeël, of liewer, versilwer, is dat jy sal ophou om aan hierdie probleme te dink en tyd te mors. Jy sal spesiale mense hê wat hierdie uitgawe sal sluit.
Die bewoording dat ons of iemand Kubernetes nodig het, is verkeerd.
Kubernetes is baie nodig vir admins, want dit is 'n baie interessante speelding waarmee jy kan speel, dieper kan delf. Kom ons wees eerlik – almal is mal oor speelgoed. Ons is almal iewers kinders, en as ons 'n nuwe een sien, wil ons dit speel. Vir sommige word dit byvoorbeeld in die administrasie afgestoot, omdat hulle al genoeg gespeel het en al so moeg is dat hulle eenvoudig nie wil nie. Maar dit word nie heeltemal van enigiemand afgeweer nie. As ek byvoorbeeld vir 'n lang tyd moeg is vir speelgoed op die gebied van stelseladministrasie en DevOps, dan is ek steeds mal oor speelgoed, ek koop steeds 'n paar nuwes. Alle mense wil op een of ander manier nog 'n soort speelgoed hê.
Nie nodig om met produksie te speel nie. Wat sal ek kategories nie aanbeveel om te doen nie en wat ek nou massief sien: "Ag, 'n nuwe speelding!" - hulle het gehardloop om dit te koop, dit gekoop en: "Kom ons neem dit nou skool toe, wys dit vir al ons vriende." Moenie dit doen nie. Ek is jammer, my kinders word net groot, ek sien gedurig iets by kinders, ek sien dit by myself raak, en dan veralgemeen ek dit na ander.
Finale antwoord: Jy het nie Kubernetes nodig nie. Jy moet jou probleme oplos.
Jy kan dit bereik:
- prod val nie;
- al probeer hy val, weet ons vooraf daarvan, en ons kan iets daarop sit;
- ons kan dit verander teen die spoed waarmee ons vir besigheid nodig het, en doen dit gerieflik, dit veroorsaak geen probleme vir ons nie.
Daar is twee werklike behoeftes: betroubaarheid en dinamika / uitrolbuigsaamheid. Almal wat nou een of ander IT-projekte doen, maak nie saak watter soort besigheid nie - sag om die wêreld te verlig, en wat dit verstaan, hierdie behoeftes moet aangespreek word. Kubernetes, met die regte benadering, met die regte begrip en met genoeg ondervinding, kan dit oplos.
Oor bedienerloos
- As jy 'n bietjie verder in die toekoms kyk, en probeer om die probleem van die gebrek aan hoofpyn met die infrastruktuur op te los, met die spoed van uitrol en die spoed van toepassingsveranderinge, verskyn nuwe oplossings, byvoorbeeld, bedienerloos. Voel jy enige potensiaal in hierdie rigting en, kom ons sê, 'n gevaar vir Kubernetes en soortgelyke oplossings?
Dmitri: Hier is dit nodig om weer 'n opmerking te maak dat ek nie 'n siener is wat vorentoe kyk en sê - dit sal so wees nie! Al het ek net dieselfde gedoen. Ek kyk af na my voete en sien 'n klomp probleme daar, soos hoe transistors in 'n rekenaar werk. Belaglik, reg? Ons staar 'n paar foute in die SVE in die gesig.
Om bedienerloos te maak is redelik betroubaar, goedkoop, doeltreffend en gerieflik, wat alle ekosisteemkwessies oplos. Hier stem ek saam met Elon Musk dat 'n tweede planeet nodig is om foutverdraagsaamheid vir die mensdom te maak. Alhoewel ek nie weet wat hy sê nie, verstaan ek dat hy nie gereed is om self na Mars te vlieg nie en dit sal nie môre gebeur nie.
Met bedienerloos is dit duidelik dat dit 'n ideologies korrekte ding is, soos foutverdraagsaamheid vir die mensdom - om twee planete te hê is beter as een. Maar hoe om dit nou te doen? Om een ekspedisie te stuur is nie 'n probleem as jy jou pogings daarop konsentreer nie. Om verskeie ekspedisies te stuur en etlike duisende mense daar te vestig, dink ek, is ook realisties. Maar dit lyk nou vir my of dit onmoontlik is, nie in ag geneem nie, om dit heeltemal foutverdraagsaam te maak sodat die helfte van die mensdom daar woon.
Met bedienerlose een tot een: 'n gawe ding, maar dit is ver van die probleme van 2019. Nader aan 2030 – kom ons leef om dit te sien. Ek het geen twyfel dat ons sal lewe nie, ons sal beslis lewe (herhaal voor ons gaan slaap), maar nou moet ons ander probleme oplos. Dit is soos om in die wonderlike ponie Rainbow te glo. Ja, 'n paar persent van gevalle word opgelos, en hulle word perfek opgelos, maar subjektief is bedienerloos 'n reënboog ... Vir my is hierdie onderwerp te ver en te onverstaanbaar. Ek is nie gereed om te praat nie. In 2019 kan u nie 'n enkele toepassing met bedienerloos skryf nie.
Hoe Kubernetes sal ontwikkel
- Soos ons na hierdie potensieel pragtige verre toekoms beweeg, hoe dink jy sal Kubernetes en die ekosisteem rondom dit ontwikkel?
DmitriA: Ek het baie daaroor gedink en ek het 'n duidelike antwoord. Die eerste – statefull – staatloos is immers makliker om te doen. Kubernetes het aanvanklik meer hierin belê, dit het alles daarmee begin. Stateless werk amper perfek in Kubernetes, daar is net niks om oor te kla nie. Volgens statefull is daar nog baie probleme, of liewer, nuanses. Ons het reeds alles wat goed daar werk, maar dit is ons. Dit sal ten minste nog 'n paar jaar neem voordat dit vir almal werk. Dit is nie 'n berekende syfer nie, maar my gevoel uit die kop.
Kortom, statefull moet - en sal - baie sterk ontwikkel, want alle toepassings stoor hul status, daar is geen staatlose toepassings nie. Dit is 'n illusie, jy het altyd 'n soort databasis en iets anders nodig. Statefull gaan daaroor om alles reg te stel wat jy kan, al die foute reg te stel, al die probleme wat tans in die gesig gestaar word te verbeter – kom ons noem dit aanneming.
Die vlak van die onbekende, die vlak van onopgeloste probleme, die vlak van waarskynlikheid om iets teë te kom, sal dramaties daal. Dit is 'n belangrike storie. En operateurs - alles wat verband hou met die kodifisering van administrasielogika, bestuurslogika, om maklike diens te kry: MySQL maklike diens, RabbitMQ maklike diens, Memcache maklike diens - in die algemeen, al hierdie komponente wat ons nodig het om dit uit die boks te laat werk, gewaarborg. Dit los net die pyn op dat ons 'n databasis wil hê, maar dit nie wil administreer nie, of ons wil Kubernetes hê, maar wil dit nie administreer nie.
Hierdie storie met die ontwikkeling van operateurs in een of ander vorm sal in die volgende paar jaar belangrik wees.
Ek dink die gebruiksgemak behoort baie toe te neem - die boks sal al hoe meer swart word, meer en meer betroubaar, met meer en meer eenvoudige kinkels.
Ek het eenkeer op Saturday Night Live na 'n ou Isaac Asimov-onderhoud uit die 80's op YouTube geluister - 'n Urgant-tipe program, net interessant. Hy is daar uitgevra oor die toekoms van rekenaars. Hy het gesê dat die toekoms in eenvoud is, soos dit was met die radio. Die radio-ontvanger was oorspronklik 'n komplekse ding. Om 'n golf te vang, het dit 15 minute geneem om die draaiers te draai, die draaiers te draai en oor die algemeen te weet hoe alles werk, die fisika van radiogolfoordrag te verstaan. Gevolglik is die radio met een kinkel gelaat.
Nou in 2019 watter radio? In die kar vind die radio-ontvanger al die golwe, die naam van die stasies. Die fisika van die proses het nie in 100 jaar verander nie, die gemak van gebruik het. Nou, en nie net nou nie, reeds in 1980, toe daar 'n onderhoud met Azimov was, het almal die radio gebruik en niemand het gedink aan hoe dit werk nie. Dit het nog altyd gewerk – dis ’n gegewe.
Asimov het toe gesê dat dit soortgelyk sal wees met rekenaars - gebruiksgemak sal toeneem. As dit in 1980 nodig was om 'n spesiale opleiding te kry om knoppies op 'n rekenaar te druk, dan sal dit in die toekoms nie die geval wees nie.
Ek het 'n gevoel dat met Kubernetes en met die infrastruktuur die gebruiksgemak ook baie sal toeneem. Dit is myns insiens voor die hand liggend – dit lê op die oppervlak.
Wat om te doen met ingenieurs?
- En wat sal dan gebeur met die ingenieurs, stelseladministrateurs wat Kubernetes ondersteun?
Dmitri: En wat het met die rekenmeester geword ná die verskyning van 1C? Ongeveer dieselfde. Voor dit het hulle op ’n stuk papier getel – nou in die program. Arbeidsproduktiwiteit het met ordes van grootte toegeneem, maar arbeid self het nie hieruit verdwyn nie. As dit vroeër 10 ingenieurs gekos het om 'n gloeilamp in te skroef, sal een nou genoeg wees.
Die aantal sagteware en die aantal take, lyk dit vir my, groei nou teen 'n vinniger tempo as wat nuwe DevOps verskyn en doeltreffendheid verhoog. Nou is daar 'n spesifieke tekort in die mark en dit sal nog lank duur. Later sal alles 'n sekere norm binnegaan, waarteen die doeltreffendheid van werk sal toeneem, daar sal meer en meer bedienerloos wees, 'n neuron sal aan Kubernetes geheg word, wat al die hulpbronne reg sal kies soos dit moet, en in die algemeen alles self doen, soos dit moet - die persoon beweeg weg en moenie inmeng nie.
Maar besluite moet steeds deur iemand geneem word. Dit is duidelik dat die vlak van kwalifikasie en spesialisasie van hierdie persoon hoër is. Nou in die rekeningkundige afdeling het jy nie 10 werknemers nodig wat rekeningboeke hou sodat hul arm nie moeg word nie. Dis net nie nodig nie. Baie dokumente word outomaties geskandeer en herken deur die elektroniese dokumentbestuurstelsel. Een slim hoofrekenmeester is genoeg, reeds met baie groter vaardighede, met 'n goeie begrip.
In die algemeen, op hierdie manier in alle nywerhede. Dit is dieselfde met motors: vroeër was 'n motorwerktuigkundige en drie bestuurders aan die motor gekoppel. Om nou 'n motor te bestuur is die eenvoudigste proses waaraan ons almal elke dag deelneem. Niemand dink dat 'n motor iets ingewikkeld is nie.
DevOps of stelselingenieurswese sal nêrens heen gaan nie - die hoë vlak en doeltreffendheid van werk sal toeneem.
- Ek het ook 'n interessante idee gehoor dat die werk in werklikheid sal toeneem.
Dmitri: Natuurlik, honderd persent! Omdat die hoeveelheid sagteware wat ons skryf voortdurend groei. Die aantal kwessies wat ons met sagteware oplos, groei voortdurend. Die aantal werksgeleenthede groei. Nou is die DevOps-mark verskriklik oorverhit. Dit kan gesien word in salarisverwagtinge. Op 'n goeie manier, sonder om in besonderhede in te gaan, moet daar juniors wees wat X wil hê, middels wat 1,5X wil hê, en seniors wat 2X wil hê. En nou, as jy na die Moskou DevOps-salarismark kyk, wil 'n junior van X tot 3X hê en 'n senior van X tot 3X.
Niemand weet hoeveel dit kos nie. Die vlak van salaris word gemeet aan jou selfvertroue – ’n volslae malhuis, om eerlik te wees, ’n verskriklik oorverhitte mark.
Natuurlik sal hierdie situasie baie gou verander - daar behoort 'n mate van versadiging te wees. Met sagteware-ontwikkeling is dit nie so nie - ten spyte van die feit dat almal ontwikkelaars nodig het, en almal goeie ontwikkelaars nodig het, die mark verstaan wie kos hoeveel - het die bedryf gevestig. Nie so met DevOps nou nie.
- Uit wat ek gehoor het, het ek tot die gevolgtrekking gekom dat die huidige stelseladministrateur nie veel moet bekommer nie, maar dit is tyd om vaardighede af te laai en voor te berei vir die feit dat daar môre meer werk sal wees, maar dit sal meer hoogs gekwalifiseerd wees.
Dmitri: Absoluut. Oor die algemeen leef ons in 2019 en die lewensreël is dit: lewenslange leer – ons leer ons hele lewe lank. Dit lyk my nou weet en voel almal dit reeds, maar om te weet is nie genoeg nie – jy moet dit doen. Elke dag moet ons verander. As ons dit nie doen nie, sal ons vroeër of later aan die kant van die beroep afgelaai word.
Wees voorbereid vir skerp 180 grade draaie. Ek sluit nie situasies uit wanneer iets dramaties verander, iets nuuts uitgevind word nie – dit gebeur. Hop! — en nou tree ons anders op. Dit is belangrik om hierop voorbereid te wees en nie bekommerd te wees nie. Dit kan gebeur dat alles wat ek doen môre onnodig sal wees – niks, ek studeer my lewe lank en is gereed om iets anders te leer. Dit is nie 'n probleem nie. Jy moet nie bang wees vir werksekerheid nie, maar jy moet gereed wees om voortdurend iets nuuts te leer.
Wense en 'n minuut van advertensies
- Het jy enige wense?
Dmitri: Ja, ek het 'n paar wense.
Die eerste en merkantiele - teken in op . Beste lesers, gaan na YouTube en teken in op ons kanaal. Iewers oor 'n maand begin ons 'n aktiewe uitbreiding na die videodiens, ons sal 'n klomp opvoedkundige inhoud oor Kubernetes hê, oop en anders: van praktiese dinge, tot laboratoriums, tot diep fundamentele teoretiese dinge en hoe om Kubernetes op die vlak van beginsels en patrone toe te pas.
Die tweede handelswens - gaan na en sit sterre, want ons eet hulle. As jy nie vir ons sterre gee nie, sal ons niks hê om te eet nie. Dit is soos mana in 'n rekenaarspeletjie. Ons doen iets, ons doen, ons probeer, iemand sê dit is verskriklike fietse, iemand dat alles oor die algemeen verkeerd is, maar ons gaan voort en tree absoluut eerlik op. Ons sien die probleem raak, ons los dit op en deel ons ervaring. Daarom, gee ons 'n sterretjie, dit sal nie van jou afneem nie, maar dit sal na ons toe kom, want ons voed op hulle.
Die derde, belangrike en nie meer handelbare wens nie - hou op om in sprokies te glo. Julle is professionele mense. DevOps is 'n baie ernstige en verantwoordelike beroep. Hou op om in die werkplek te speel. Laat dit jou klik en jy sal dit verstaan. Stel jou voor dat jy na die hospitaal kom, en daar eksperimenteer die dokter met jou. Ek verstaan dat dit vir iemand aanstootlik kan wees, maar dit gaan heel waarskynlik nie oor jou nie, maar oor iemand anders. Sê vir ander om ook te stop. Dit bederf regtig ons almal se lewens – baie begin om die operasie, die admins en DevOps te behandel as ouens wat weer iets gebreek het. Dit was meestal "gebreek" as gevolg van die feit dat ons gaan speel het, en nie met 'n koue gemoed gekyk het dat dit so hier is nie, maar dis hoe dit hier is.
Dit beteken nie dat jy nie moet eksperimenteer nie. Ons moet eksperimenteer, ons doen dit self. Om eerlik te wees, ons self speel ook soms – dit is natuurlik baie sleg, maar niks mensliks is vir ons vreemd nie. Kom ons verklaar 2019 tot die jaar van ernstige deurdagte eksperimente, nie speletjies op die mark nie. Waarskynlik so.
- Baie dankie!
Dmitri: Dankie, Vitaly, vir die tyd en vir die onderhoud. Beste lesers, baie dankie as julle skielik by hierdie punt uitgekom het. Ek hoop dat ons u ten minste 'n paar gedagtes gebring het.
Dmitri het in ’n onderhoud die kwessie van werf aangeraak. Nou is dit 'n universele Switserse mes wat byna alle take oplos. Maar dit was nie altyd so nie. Aan by die fees Dmitri Stolyarov sal in detail oor hierdie instrument praat. in die verslag daar sal alles wees: probleme en verborge nuanses van Kubernetes, oplossings vir hierdie probleme en die huidige implementering van werf in detail. Sluit aan op 27 en 28 Mei, ons sal die perfekte gereedskap skep.
Bron: will.com