Yn ôfwachting Vitaly Khabarov ynterviewd Dmitry Stolyarov (), technysk direkteur en mei-oprjochter fan it bedriuw Flant. Vitaly frege Dmitry oer wat Flant docht, oer Kubernetes, ekosysteemûntwikkeling, stipe. Wy hawwe besprutsen wêrom Kubernetes nedich is en oft it überhaupt nedich is. En ek oer mikrotsjinsten, Amazon AWS, de "I'll be lucky" oanpak fan DevOps, de takomst fan Kubernetes sels, wêrom, wannear en hoe't it de wrâld sil oernimme, de perspektiven fan DevOps en wêrop yngenieurs moatte tariede yn 'e heldere en tichtby takomst mei ferienfâldiging en neurale netwurken.
harkje as podcast op DevOps Deflop - in Russysktalige podcast oer DevOps, en hjirûnder is de tekstferzje.
Hjir en hjirûnder stelt er fragen yngenieur út Express42.
Over "Flant"
- Hallo Dima. Jo binne de technyske direkteur ""en ek syn oprjochter. Fertel ús asjebleaft wat it bedriuw docht en wat jo deryn binne?
Dmitry: Fan bûten liket it as binne wy de jonges dy't foar elkenien Kubernetes ynstalleare en der wat mei dogge. Mar dat is net wier. Wy binne begûn as in bedriuw dat dwaande hâldt mei Linux, mar foar in heul lange tiid is ús haadaktiviteit it tsjinjen fan produksje en turnkey-projekten mei hege lading. Meastentiids bouwe wy de hiele ynfrastruktuer fanôf it begjin en binne wy dêr dan lang, lang ferantwurdlik foar. Dêrom is it wichtichste wurk dat "Flant" docht, dêr't it jild foar krijt ferantwurdlikens nimme en turnkey produksje útfiere.
Ik, as technysk direkteur en ien fan 'e oprjochters fan it bedriuw, besteegje de hiele dei en nacht troch te besykjen út te finen hoe't jo de tagonklikens fan produksje kinne ferheegje, har wurking ferienfâldigje, it libben fan behearders makliker meitsje en it libben fan ûntwikkelders nofliker meitsje .
Oer Kubernetes
- De lêste tiid haw ik in protte rapporten sjoen fan Flant en oer Kubernetes. Hoe bist der by kommen?
Dmitry: Ik haw it hjir al in protte kearen oer hân, mar ik haw der gjin sin oan om it hielendal te werheljen. Ik tink dat it rjocht is om dit ûnderwerp te werheljen, om't d'r betizing is tusken oarsaak en gefolch.
Wy hawwe echt in ark nedich. Wy konfrontearre in soad problemen, stride, oerwûn se mei ferskate krukken en fielde de needsaak foar in ark. Wy gongen troch in protte ferskillende opsjes, bouden ús eigen fytsen, en opdien ûnderfining. Stadichoan kamen wy op it punt wêr't wy Docker begon te brûken hast sa gau as it ferskynde - om 2013 hinne. Op it stuit fan syn ferskining hiene wy al in protte ûnderfining mei konteners, wy hienen al in analoog fan "Docker" skreaun - guon fan ús eigen krukken yn Python. Mei de komst fan Docker waard it mooglik om de krukken út te smiten en in betroubere en mienskip-stipe oplossing te brûken.
Mei Kubernetes is it ferhaal fergelykber. Tsjin de tiid dat it momentum begon te winnen - foar ús is dit ferzje 1.2 - hienen wy al in boskje krukken op sawol Shell as Chef, dy't wy op ien of oare manier besochten te orkestrearjen mei Docker. Wy sochten serieus nei Rancher en ferskate oare oplossingen, mar doe ferskynde Kubernetes, wêryn alles wurdt ymplementearre krekt sa't wy it dien hawwe of noch better. Der is neat te kleien.
Ja, d'r is hjir in soarte fan ûnfolsleinens, d'r is in soarte fan ûnfolsleinens dêr - d'r binne in protte ûnfolsleinens, en 1.2 is oer it algemien ferskriklik, mar ... Kubernetes is as in gebou yn oanbou - jo sjogge nei it projekt en begripe dat it sil wêze cool. As it gebou no in stichting en twa ferdjippings hat, dan begripe jo dat it better is om noch net yn te bewegen, mar d'r binne gjin sokke problemen mei de software - jo kinne it al brûke.
Wy hiene gjin momint wêr't wy neitocht oer it brûken fan Kubernetes of net. Wy wachte der lang op foardat it ferskynde, en besochten sels analogen te meitsjen.
Oer Kubernetes
- Binne jo direkt belutsen by de ûntwikkeling fan Kubernetes sels?
Dmitry: Middelmjittich. Wy dogge leaver mei oan de ûntwikkeling fan it ekosysteem. Wy stjoere in bepaald oantal pull-oanfragen: nei Prometheus, nei ferskate operators, nei Helm - nei it ekosysteem. Spitigernôch, ik bin net by steat om te folgjen alles wat wy dogge en ik koe wêze ferkeard, mar der is net in inkele pool fan ús yn 'e kearn.
- Tagelyk ûntwikkelje jo in protte fan jo ark om Kubernetes hinne?
Dmitry: De strategy is dit: wy geane en lûke fersiken nei alles dat al bestiet. As pull-oanfragen dêr net wurde aksepteare, forke wy se gewoan sels en libje oant se wurde aksepteare mei ús builds. Dan, as it de streamop komt, geane wy werom nei de streamopferzje.
Wy hawwe bygelyks in Prometheus-operator, wêrmei't wy al sa'n 5 kear oerstapten nei de streamop fan ús gearkomste. Wy hawwe in soarte fan funksje nedich, wy hawwe in pull-oanfraach stjoerd, wy moatte it moarn útrôlje, mar wy wolle net wachtsje op it streamopút frijlitten. Dêrom sammelje wy foar ússels, rôlje ús gearstalling út mei ús funksje, dy't wy om ien of oare reden nedich binne, nei al ús klusters. Dan jouwe se it bygelyks yn de streamop oan ús oer mei de wurden: "Jongens, litte wy it dwaan foar in mear algemiene saak", wy, of in oar, meitsje it ôf, en mei de tiid fusearret it wer werom.
Wy besykje alles te ûntwikkeljen dat bestiet. In protte eleminten dy't noch net bestean, binne noch net útfûn, of binne útfûn, mar hawwe gjin tiid om te realisearjen - wy dogge it. En net om't wy it proses of fytsbou as yndustry leuk fine, mar gewoan om't wy dit ark nedich hawwe. De fraach wurdt faak steld, wêrom hawwe wy dit of dat ding dien? It antwurd is ienfâldich - ja, om't wy fierder gean moasten, wat praktysk probleem oplosse, en wy hawwe it oplost mei dizze tula.
It paad is altyd sa: wy sykje hiel foarsichtich en, as wy gjin oplossing fine oer hoe't wy in trolleybus meitsje fan in bôle, dan meitsje wy ús eigen brea en ús eigen trolleybus.
Flanta ark
- Ik wit dat Flant no addon-operators, shell-operators en dapp/werf-ark hat. As ik it begryp, is dit itselde ynstrumint yn ferskate ynkarnaasjes. Ik begryp ek dat d'r folle mear ferskillende ark binne binnen Flaunt. Is dit wier?
Dmitry: Wy hawwe in protte mear op GitHub. Fan wat ik my no herinner, hawwe wy in statuskaart - in paniel foar Grafana dat elkenien tsjinkaam. It wurdt neamd yn hast elk twadde artikel oer Kubernetes-monitoring op Medium. It is ûnmooglik om koart út te lizzen wat in statusmap is - it hat in apart artikel nedich, mar it is in heul nuttich ding foar it kontrolearjen fan status oer de tiid, om't wy yn Kubernetes faaks status oer de tiid moatte sjen litte. Wy hawwe ek LogHouse - dit is in ding basearre op ClickHouse en swarte magy foar it sammeljen fan logs yn Kubernetes.
In protte nutsfoarsjenningen! En der komme noch mear, want dit jier komme der in tal ynterne oplossingen út. Fan 'e heul grutte basearre op' e addon-operator, binne d'r in boskje tafoegings foar Kubernetes, ala hoe't jo sert manager goed kinne ynstallearje - in ark foar it behearen fan sertifikaten, hoe jo Prometheus korrekt kinne ynstallearje mei in boskje aksessoires - dit binne sawat tweintich ferskillende binaries dy't eksportearje gegevens en sammelje wat, nei dizze Prometheus hat de meast geweldige grafiken en warskôgings. Dit alles is gewoan in boskje tafoegings oan Kubernetes, dy't binne ynstalleare yn in kluster, en it feroaret fan ienfâldich nei koel, ferfine, automatysk, wêryn in protte problemen al binne oplost. Ja, wy dogge in protte.
Ekosysteemûntwikkeling
"It liket my ta dat dit in heul grutte bydrage is oan 'e ûntwikkeling fan dit ynstrumint en de metoaden fan gebrûk." Kinne jo rûchwei ynskatte wa't oars deselde bydrage leverje soe oan 'e ûntwikkeling fan it ekosysteem?
Dmitry: Yn Ruslân, fan 'e bedriuwen dy't op ús merk operearje, is gjinien sels tichtby. Fansels is dit in lûde útspraak, om't d'r grutte spilers binne lykas Mail en Yandex - se dogge ek wat mei Kubernetes, mar sels se komme net tichtby de bydrage fan bedriuwen yn 'e hiele wrâld dy't folle mear dogge as ús. It is dreech om te ferlykjen Flant, dat hat in personiel fan 80 minsken, en Red Hat, dat hat 300 yngenieurs per Kubernetes allinne, as ik bin net fersin. It is dreech om te fergelykjen. Wy hawwe 6 minsken yn 'e RnD ôfdieling, ynklusyf my, dy't snije al ús ark. 6 minsken tsjin 300 Red Hat-yngenieurs - it is op ien of oare manier lestich om te fergelykjen.
- Lykwols, as sels dizze 6 minsken kinne dwaan wat echt nuttich en ferfrjemde, as se te krijen hawwe mei in praktysk probleem en jouwe de oplossing foar de mienskip - in nijsgjirrich gefal. Ik begryp dat yn grutte technologybedriuwen, wêr't se har eigen Kubernetes-ûntwikkelings- en stipeteam hawwe, yn prinsipe deselde ark kinne wurde ûntwikkele. Dit is in foarbyld foar harren fan wat kin wurde ûntwikkele en jûn oan de mienskip, dy't ympuls jaan oan de hiele mienskip dy't brûkt Kubernetes.
Dmitry: Dit is wierskynlik in eigenskip fan 'e yntegrator, syn eigenaardichheid. Wy hawwe in protte projekten en wy sjogge in protte ferskillende situaasjes. Foar ús is de wichtichste manier om mearwearde te meitsjen om dizze gefallen te analysearjen, mienskiplikens te finen en foar ús sa goedkeap mooglik te meitsjen. Wy wurkje hjir aktyf oan. It is lestich foar my om oer Ruslân en de wrâld te praten, mar wy hawwe sawat 40 DevOps-yngenieurs yn it bedriuw dy't wurkje oan Kubernetes. Ik tink net dat d'r in protte bedriuwen yn Ruslân binne mei in fergelykber oantal spesjalisten dy't Kubernetes begripe, as der ien is.
Ik begryp alles oer de baantitel DevOps-yngenieur, elkenien begrypt alles en is wend om DevOps-yngenieurs DevOps-yngenieurs te neamen, wy sille dit net besprekke. Al dizze 40 geweldige DevOps-yngenieurs hawwe elke dei problemen en oplosse, wy analysearje dizze ûnderfining gewoan en besykje te generalisearjen. Wy begripe dat as it yn ús bliuwt, dan sil it ark oer in jier as twa nutteloos wêze, want earne yn 'e mienskip sil in klearmakke Tula ferskine. D'r hat gjin punt om dizze ûnderfining yntern te sammeljen - it drain gewoan enerzjy en tiid yn dev / null. En wy hawwe der hielendal gjin spyt fan. Wy publisearje alles mei in protte wille en begripe dat it publisearre, ûntwikkele, befoardere, befoardere wurde moat, sadat minsken it brûke en har ûnderfining tafoegje - dan groeit en libbet alles. Dan nei twa jier giet it ynstrumint net yn it jiskefet. It is net spitich om troch te gean mei krêft, om't it dúdlik is dat immen jo ark brûkt, en nei twa jier brûkt elkenien it.
Dit is ûnderdiel fan ús grutte strategy mei dapp/werf. Ik wit net ûnthâlde doe't wy begûn meitsjen it, it liket as 3 jier lyn. Yn it earstoan wie it oer it generaal op 'e skyl. It wie in super proof of concept, wy hawwe guon fan ús bepaalde problemen oplost - it wurke! Mar d'r binne problemen mei de shell, it is ûnmooglik om it fierder út te wreidzjen, programmearjen op 'e shell is in oare taak. Wy hienen in gewoante om yn Ruby te skriuwen, dêrom hawwe wy wat yn Ruby opnij makke, ûntwikkele, ûntwikkele, ûntwikkele, en rûnen yn it feit dat de mienskip, de kliber dy't net seit "wy wolle it of wy wolle it net, ” draait de noas omheech nei Ruby, hoe grappich is dat? Wy realisearre dat wy dit alles yn Go moatte skriuwe om it earste punt op 'e checklist te foldwaan: DevOps-ark moat in statysk binêr wêze. Om Go te wêzen of net is net sa wichtich, mar in statyske binêr skreaun yn Go is better.
Wy hawwe ús enerzjy útjûn, de dapp yn Go oerskreaun en werf neamd. De Dapp wurdt net mear stipe, net ûntwikkele, rint yn guon lêste ferzje, mar der is in absolút upgrade paad nei de top, en do kinst folgje it.
Wêrom is de dapp makke?
- Kinne jo ús koart fertelle wêrom't de dapp makke is, hokker problemen it oplost?
Dmitry: De earste reden is yn 'e gearkomste. Yn it earstoan hienen wy serieuze problemen mei de bou doe't Docker gjin multi-stage-mooglikheden hie, dus wy makken multi-stage op ús eigen. Dan hienen wy in bosk mear problemen mei it skjinmeitsjen fan de ôfbylding. Elkenien dy't CI/CD docht, earder as letter, wurdt konfrontearre mei it probleem dat der in bulte sammele bylden binne, jo moatte op ien of oare manier skjinmeitsje wat net nedich is en litte wat nedich is.
De twadde reden is ynset. Ja, d'r is Helm, mar it lost mar guon fan 'e problemen op. Grappich genôch is it skreaun dat "Helm is de pakketbehearder foar Kubernetes." Krekt wat "de". D'r binne ek de wurden "Package Manager" - wat is de gewoane ferwachting fan in Package Manager? Wy sizze: "Package Manager - ynstallearje it pakket!" en wy ferwachtsje dat hy ús fertelt: "It pakket is ôflevere."
It is nijsgjirrich dat wy sizze: "Helm, ynstallearje it pakket," en as hy antwurde dat hy it ynstallearre, docht bliken dat hy krekt begûn de ynstallaasje - hy oanjûn Kubernetes: "Start dit ding!", en oft it begûn of net , oft it wurket of net, Helm lost dit probleem hielendal net op.
It docht bliken dat Helm gewoan in tekstfoarferwurker is dy't gegevens yn Kubernetes lade.
Mar as ûnderdiel fan elke ynset wolle wy witte oft de applikaasje is frijjûn foar produksje of net? Útrôle ta prod betsjut dat de applikaasje is ferpleatst dêr, de nije ferzje is ynset, en op syn minst it net crashe dêr en reagearret korrekt. Helm lost dit probleem op gjin inkelde manier op. Om it op te lossen, moatte jo in protte muoite besteegje, om't jo Kubernetes it kommando moatte jaan om út te rollen en te kontrolearjen wat der bart - oft it ynset of útrol is. En d'r binne ek in protte taken yn ferbân mei ynset, skjinmeitsjen en montage.
Plannen
Dit jier begjinne wy mei lokale ûntwikkeling. Wy wolle berikke wat earder yn Vagrant wie - wy typten "vagrant up" en wy hawwe firtuele masines ynset. Wy wolle op it punt komme wêr't d'r in projekt is yn Git, wy skriuwe dêr "werf omheech", en it bringt in lokale kopy fan dit projekt op, ynset yn in lokale mini-Kub, mei alle mappen dy't handich binne foar ûntwikkeling ferbûn . Ôfhinklik fan de ûntwikkelingstaal wurdt dat oars dien, mar dochs, sadat de lokale ûntwikkeling maklik útfierd wurde kin ûnder mounted files.
De folgjende stap foar ús is ynvestearje yn gemak foar ûntwikkelders. Om fluch in projekt lokaal yn te setten mei ien ark, ûntwikkelje it, triuw it yn Git, en it sil ek útrolje nei poadium as tests, ôfhinklik fan 'e pipelines, en brûk dan itselde ark om nei produksje te gean. Dizze ienheid, ferieniging, reprodusearberens fan ynfrastruktuer fan 'e pleatslike omjouwing oant ferkeap is in heul wichtich punt foar ús. Mar dit is noch net yn 'e werf - wy binne gewoan fan plan om it te dwaan.
Mar it paad nei dapp/werf hat altyd itselde west as by Kubernetes yn it begjin. Wy tsjinkamen problemen, losten se op mei oplossingen - wy kamen mei wat oplossingen foar ússels op 'e shell, oer alles. Doe besochten se dizze oplossingen op ien of oare manier te rjochtsjen, se te generalisearjen en te konsolidearjen yn binaries yn dit gefal, dy't wy gewoan diele.
D'r is in oare manier om nei dit hiele ferhaal te sjen, mei analogyen.
Kubernetes is in auto frame mei in motor. Der binne gjin doarren, glês, radio, krystbeam - hielendal neat. Krekt it frame en motor. En der is Helm - dit is it stjoer. Cool - der is in stjoer, mar jo moatte ek in stjoer pin, stjoer rack, Fersnellingsbak en tsjillen, en do kinst net dwaan sûnder harren.
Yn it gefal fan werf is dat in oare komponint fan Kubernetes. Allinnich no yn de alfaferzje fan werf wurdt Helm bygelyks binnen werf gearstald, want wy binne nocht fan it sels dwaan. D'r binne in protte redenen om dit te dwaan, ik sil jo yn detail fertelle oer wêrom't wy it hiele roer gearstald hawwe tegearre mei helmstok binnen werf .
No is werf in mear yntegraal ûnderdiel. Wy krije in klear stjoer, in stjoerpin - ik bin net hiel goed yn auto's, mar dit is in grut blok dat al in frij breed oanbod fan problemen oplost. Wy hoege net sels te gean troch de katalogus, selektearje it iene diel foar it oare, tink oer hoe't wy se tegearre kinne skroef. Wy krije in klearmakke kombinearjen dy't in grut tal problemen tagelyk oplost. Mar binnen is it boud fan deselde iepen boarne-komponinten, it brûkt noch Docker foar assemblage, Helm foar guon fan 'e funksjonaliteit, en d'r binne ferskate oare biblioteken. Dit is in yntegreare ark om koele CI / CD fluch en maklik út 'e doaze te heljen.
Is Kubernetes lestich te ûnderhâlden?
- Jo prate oer de ûnderfining dat jo begûn te brûken Kubernetes, dit is in frame foar jo, in motor, en dat kinst hingje in protte ferskillende dingen op it: in lichem, in stjoer, schroef op pedalen, sitten. De fraach ûntstiet - hoe lestich is Kubernetes-stipe foar jo? Jo hawwe in protte ûnderfining, hoefolle tiid en boarnen besteegje jo oan it stypjen fan Kubernetes yn isolemint fan al it oare?
Dmitry: Dit is in heul lestige fraach en om te beantwurdzjen, moatte wy begripe wat stipe is en wat wy wolle fan Kubernetes. Miskien kinne jo iepenbierje?
- Sa fier as ik wit en sa't ik sjoch, no wolle in protte teams Kubernetes besykje. Elkenien spant him der op, set it op 'e knibbels. Ik haw it gefoel dat minsken de kompleksiteit fan dit systeem net altyd begripe.
Dmitry: It is sa.
- Hoe lestich is it om Kubernetes fanôf it begjin te nimmen en te ynstallearjen, sadat it klear is foar produksje?
Dmitry: Hoe dreech tinke jo dat it is om in hert te transplantearjen? Ik begryp dat dit in kompromisearjende fraach is. In skalpel brûke en gjin flater meitsje is net sa dreech. As se jo fertelle wêr't te knippen en wêr te naaien, dan is de proseduere sels net yngewikkeld. It is lestich om kear op kear te garandearjen dat alles goed komt.
Kubernetes ynstallearje en it oan it wurk krije is maklik: chick! - ynstalleare, d'r binne in protte ynstallaasjemetoaden. Mar wat bart der as problemen ûntsteane?
Der komme altyd fragen - wat hawwe wy noch net yn rekken brocht? Wat hawwe wy noch net dien? Hokker Linux kernel parameters waarden opjûn ferkeard? Hear, hawwe wy se sels neamd?! Hokker Kubernetes-komponinten hawwe wy levere en hokker hawwe wy net? Tûzenen fragen komme op, en om se te beantwurdzjen, moatte jo 15-20 jier yn dizze sektor besteegje.
Ik haw in resint foarbyld oer dit ûnderwerp dat de betsjutting fan it probleem "Is Kubernetes lestich te ûnderhâlden?" In skoft lyn hawwe wy serieus oertocht oft wy moatte besykje Cilium as netwurk yn Kubernetes te ymplementearjen.
Lit my útlizze wat Cilium is. Kubernetes hat in protte ferskillende ymplemintaasjes fan it netwurksubsysteem, en ien fan har is heul cool - Cilium. Wat is de betsjutting? Yn 'e kernel waard it in skoft lyn mooglik om heakken foar de kernel te skriuwen, dy't op ien of oare manier it netwurksubsysteem en ferskate oare subsystemen ynfalle, en kinne jo grutte stikken yn 'e kernel omgean.
De Linux-kernel hat histoarysk in ip-rûte, in oerfilter, brêgen en in protte ferskillende âlde komponinten dy't 15, 20, 30 jier âld binne. Yn 't algemien wurkje se, alles is geweldich, mar no hawwe se konteners opsteapele, en it liket in toer fan 15 bakstiennen op elkoar, en jo steane der op ien skonk - in nuver gefoel. Dit systeem is histoarysk ûntwikkele mei in protte nuânses, lykas de appendiks yn it lichem. Yn guon situaasjes binne der prestaasjesproblemen, bygelyks.
D'r is in prachtige BPF en de mooglikheid om haken foar de kernel te skriuwen - de jonges skreaunen har eigen haken foar de kernel. It pakket komt yn 'e Linux-kernel, se nimme it direkt út by de ynfier, ferwurkje it sels sa't it moat sûnder brêgen, sûnder TCP, sûnder in IP-stapel - koartsein, alles omgean wat yn 'e Linux-kernel is skreaun, en dan spuie it út yn 'e kontener.
Wat is bard? Hiel cool prestaasje, coole funksjes - gewoan cool! Mar wy sjogge dit en sjogge dat op elke masine in programma is dat ferbynt mei de Kubernetes API en, basearre op de gegevens dy't it ûntfangt fan dizze API, genereart C-koade en kompilearret binaries dy't it yn 'e kearn lade, sadat dizze haken wurkje yn 'e kernel romte.
Wat bart der as der wat mis giet? Wy witte it net. Om dit te begripen, moatte jo al dizze koade lêze, alle logika begripe, en it is geweldich hoe dreech it is. Mar, oan 'e oare kant, binne d'r dizze brêgen, netfilters, ip-rûte - ik haw har boarnekoade net lêzen, en ek net de 40 yngenieurs dy't yn ús bedriuw wurkje. Miskien mar in pear begripe guon dielen.
En wat is it ferskil? It docht bliken dat d'r ip-rout is, de Linux-kernel, en d'r is in nij ark - wat ferskil makket it, wy begripe it iene as it oare net. Mar wy binne bang om wat nijs te brûken - wêrom? Want as it ark 30 jier âld is, dan binne yn 30 jier alle bugs fûn, alle flaters binne trape en jo hoege net fan alles te witten - it wurket as in swarte doaze en wurket altyd. Elkenien wit hokker diagnostyske schroevendraaier op hokker plak plakke moat, hokker tcpdump op hokker momint te rinnen. Elkenien ken diagnostyske hulpprogramma's goed en begrypt hoe't dizze set komponinten wurket yn 'e Linux-kernel - net hoe't it wurket, mar hoe't jo it brûke.
En de bjusterbaarlike koele Cilium is net 30 jier âld, it is noch net âld. Kubernetes hat itselde probleem, kopiearje. Dat Cilium is ynstallearre perfekt, dat Kubernetes is ynstallearre perfekt, mar as der wat mis giet yn produksje, kinne jo fluch begripe yn in krityske situaasje wat der mis gie?
As wy sizze is it lestich om Kubernetes te ûnderhâlden - nee, it is heul maklik, en ja, it is ongelooflijk lestich. Kubernetes wurket geweldich op har eigen, mar mei in miljard nuânses.
Oer de "Ik sil gelok" oanpak
- Binne der bedriuwen dêr't dizze nuânses hast garandearre ferskine? Stel dat Yandex ynienen alle tsjinsten oerdraacht nei Kubernetes, d'r sil in enoarme lading wêze.
Dmitry: Nee, dit is gjin petear oer de lading, mar oer de ienfâldichste dingen. Wy hawwe bygelyks Kubernetes, wy hawwe de applikaasje dêr ynset. Hoe witte jo dat it wurket? D'r is gewoan gjin klear ark om te begripen dat de applikaasje net crasht. D'r is gjin ready-made systeem dat warskôgings ferstjoert; jo moatte dizze warskôgings en elk skema konfigurearje. En wy aktualisearje Kubernetes.
Ik haw Ubuntu 16.04. Jo kinne sizze dat dit in âlde ferzje, mar wy binne noch op it omdat it is LTS. D'r is systemd, wêrfan de nuânse is dat it gjin C-groepen skjinmakket. Kubernetes lanseart pods, makket C-groepen, wisket dan pods, en op ien of oare manier docht bliken - ik herinner my de details net, sorry - dat systemd slices bliuwe. Dit liedt ta it feit dat nei ferrin fan tiid, eltse auto begjint te fertrage sterk. Dit is net iens in fraach oer hege lading. As permaninte pods wurde lansearre, bygelyks, as der in Cron Job is dy't konstant pods genereart, dan sil de masine mei Ubuntu 16.04 nei in wike begjinne te fertrage. Troch it feit dat der in bulte C-groepen ûntstien is, komt der in konstant heech loadgemiddelde. Dit is it probleem dat elke persoan dy't gewoan Ubuntu 16 en Kubernetes boppe ynstalleart sil tsjinkomme.
Litte wy sizze dat hy op ien of oare manier systemd of wat oars bywurket, mar yn 'e Linux-kernel oant 4.16 is it noch grappiger - as jo C-groepen wiskje, lekke se yn' e kernel en wurde eins net wiske. Dêrom, nei in moanne fan wurkjen oan dizze masine, sil it ûnmooglik wêze om te sjen nei de ûnthâldstatistiken foar de hurden. Wy nimme in bestân út, rôlje it yn it programma, en ien bestân rôlet 15 sekonden, om't de kernel in protte tiid duorret om in miljoen C-groepen yn himsels te tellen, dy't lykje te wiskjen, mar nee - se lekke .
Der binne hjir en dêr noch in protte fan sokke lytse dingen. Dit is gjin probleem dat gigantyske bedriuwen soms ûnder heul swiere lesten kinne konfrontearje - nee, it is in kwestje fan deistige dingen. Minsken kinne moannen sa libje - se hawwe Kubernetes ynstalleare, de applikaasje ynset - it liket te wurkjen. Foar in protte minsken is dit normaal. Se sille net iens witte dat dizze applikaasje om ien of oare reden sil crashe, se sille gjin warskôging krije, mar foar har is dit de noarm. Earder wennen wy op firtuele masines sûnder tafersjoch, no ferhuze wy nei Kubernetes, ek sûnder tafersjoch - wat is it ferskil?
De fraach is dat as wy op iis rinne, wy de dikte nea witte, útsein as wy it foarôf mjitte. In protte minsken rinne en meitsje har gjin soargen, om't se earder rûn hawwe.
Fanút myn eachpunt is de nuânse en kompleksiteit fan it operearjen fan elk systeem om te soargjen dat de dikte fan it iis krekt genôch is om ús problemen op te lossen. Dit is wêr't wy it oer hawwe.
Yn IT, liket my, binne d'r te folle "ik sil gelok" oanpakken. In protte minsken ynstallearje software en brûke softwarebiblioteken yn 'e hope dat se gelok sille krije. Yn 't algemien binne in protte minsken gelok. Dat is wierskynlik wêrom it wurket.
- Ut myn pessimistyske beoardieling sjocht it der sa út: as de risiko's heech binne, en de applikaasje moat wurkje, dan is stipe nedich fan Flaunt, miskien fan Red Hat, of jo hawwe jo eigen ynterne team nedich spesifyk wijd oan Kubernetes, dat klear is om it fuort te heljen.
Dmitry: Objektyf is dit sa. Troch it Kubernetes-ferhaal foar in lyts team op jo eigen te kommen, befettet in oantal risiko's.
Binne wy konteners nedich?
- Kinne jo ús fertelle hoe wiidferspraat Kubernetes is yn Ruslân?
Dmitry: Ik haw net dizze gegevens, en ik bin der net wis fan dat immen oars hat it. Wy sizze: "Kubernetes, Kubernetes," mar d'r is in oare manier om nei dit probleem te sjen. Ik wit ek net hoe wiidferspraat konteners binne, mar ik wit in sifer út rapporten op it ynternet dat 70% fan konteners wurde orkestreare troch Kubernetes. It wie in betroubere boarne foar in frij grutte stekproef om 'e wrâld.
Dan in oare fraach - hawwe wy konteners nedich? Myn persoanlik gefoel en de algemiene posysje fan it Flant-bedriuw is dat Kubernetes in de facto standert is.
D'r sil neat wêze as Kubernetes.
Dit is in absolute game-changer op it mêd fan ynfrastruktuerbehear. Krekt absolút - dat is it, net mear Ansible, Chef, firtuele masines, Terraform. Ik ha it net oer de âlde metoaden fan kollektive pleats. Kubernetes is in absolute feroaring, en no sil it allinich sa wêze.
It is dúdlik dat it foar guon in pear jier duorret, en foar oaren in pear desennia, om dit te realisearjen. Ik haw gjin twifel dat d'r neat sil wêze as Kubernetes en dit nije uterlik: wy beskeadigje it bestjoeringssysteem net mear, mar brûke ynfrastruktuer as koade, allinich net mei koade, mar mei yml - in deklaratyf beskreaune ynfrastruktuer. Ik ha it gefoel dat it altyd sa wêze sil.
- Dat wol sizze, dy bedriuwen dy't noch net oerstutsen binne op Kubernetes, sille der definityf nei oerstappe of yn it ferjit bliuwe. Ik ha dy goed begrepen?
Dmitry: Dit is ek net alhiel wier. As wy bygelyks de taak hawwe om in DNS-tsjinner út te fieren, dan kin it wurde útfierd op FreeBSD 4.10 en it kin perfekt wurkje foar 20 jier. Gewoan wurkje en dat is it. Miskien moat der oer 20 jier wat bywurke wurde. As wy it hawwe oer software yn it formaat dat wy lansearre hawwe en it wurket eins in protte jierren sûnder updates, sûnder feroaringen te meitsjen, dan sil d'r fansels gjin Kubernetes wêze. Hy is dêr net nedich.
Alles relatearre oan CI / CD - wêr't Continuous Delivery nedich is, wêr't jo ferzjes moatte bywurkje, aktive feroarings meitsje, wêr't jo ek moatte bouwe fouttolerânsje - allinich Kubernetes.
Oer mikrotsjinsten
- Hjir haw ik in lichte dissonânsje. Om mei Kubernetes te wurkjen hawwe jo eksterne as ynterne stipe nedich - dit is it earste punt. Twad, as wy krekt begjinne mei ûntwikkeling, binne wy in lytse opstart, wy hawwe noch neat, ûntwikkeling foar Kubernetes of mikroservice-arsjitektuer yn 't algemien kin kompleks wêze en net altyd ekonomysk terjochte. Ik bin ynteressearre yn jo miening - moatte startups fuortendaliks begjinne mei skriuwen foar Kubernetes, of kinne se noch in monolyt skriuwe, en dan allinich nei Kubernetes komme?
Dmitry: Cool fraach. Ik haw in praat oer mikrotsjinsten In protte kearen haw ik minsken tsjinkommen dy't besykje spikers te hammerjen mei in mikroskoop. De oanpak sels is korrekt; wy sels ûntwerpe ús ynterne software op dizze manier. Mar as jo dit dogge, moatte jo dúdlik begripe wat jo dogge. It wurd dat ik it meast haatsje oer mikrotsjinsten is "mikro." Histoarysk is dit wurd dêr ûntstien, en om ien of oare reden tinke minsken dat mikro tige lyts is, minder as in millimeter, lykas in mikrometer. Dit is ferkeard.
Bygelyks, d'r is in monolyt dy't skreaun is troch 300 minsken, en elkenien dy't meidien hat oan 'e ûntwikkeling begrypt dat d'r problemen binne, en it moat wurde ferdield yn mikrostikken - sawat 10 stikken, elk fan dat is skreaun troch 30 minsken yn in minimum ferzje. Dit is wichtich, needsaaklik en cool. Mar as in opstart by ús komt, wêr't 3 heul coole en talintfolle jonges 60 mikrotsjinsten op har knibbels skreaunen, elke kear as ik nei Corvalol sykje.
It liket my dat dit al tûzenen kearen praat is - wy krigen in ferdielde monolyt yn ien of oare foarm. Dit is net ekonomysk terjochte, it is yn 't algemien heul lestich yn alles. Ik haw krekt sjoen dit safolle kearen dat it echt sear my, dus ik fierder te praten oer it.
Foar de earste fraach is d'r in konflikt tusken it feit dat Kubernetes oan 'e iene kant eng is om te brûken, om't it net dúdlik is wat der kin brekke of net wurkje, oan' e oare kant is it dúdlik dat alles dêr giet en neat oars as Kubernetes sil bestean. Antwurd - weagje it bedrach fan it foardiel dat komt, it oantal taken dat jo kinne oplosse. Dit is oan ien kant fan 'e skaal. Oan 'e oare kant binne d'r risiko's ferbûn mei downtime of mei in fermindering fan reaksjetiid, nivo fan beskikberens - mei in fermindering fan prestaasje-yndikatoaren.
Hjir is it - of wy ferpleatse fluch, en Kubernetes lit ús in protte dingen folle rapper en better dwaan, of wy brûke betroubere, time-teste oplossingen, mar bewege folle stadiger. Dit is in kar dat elk bedriuw moat meitsje. Jo kinne it betinke as in paad yn 'e jungle - as jo foar it earst rinne, kinne jo in slang, in tiger of in gekke das moetsje, en as jo 10 kear rûn binne, hawwe jo it paad trape, fuorthelle de tûken en kuierje makliker. Elke kear wurdt it paad breder. Dan is it in asfaltdyk, en letter in moaie boulevard.
Kubernetes stiet net stil. Fraach wer: Kubernetes, oan 'e iene kant, is 4-5 binaries, oan' e oare kant, it is it hiele ekosysteem. Dit is it bestjoeringssysteem dat wy op ús masines hawwe. Wat is dit? Ubuntu of Curios? Dit is de Linux kernel, in boskje ekstra komponinten. Al dy dingen hjir, ien giftige slang waard út 'e dyk smiten, dêr waard in hek oanlein. Kubernetes ûntwikkelet heul rap en dynamysk, en it folume fan risiko's, it folume fan 'e ûnbekende nimt elke moanne ôf en dêrtroch binne dizze skalen opnij yn balansearje.
It beantwurdzjen fan de fraach fan wat in opstart moat dwaan, soe ik sizze - kom nei Flaunt, betelje 150 tûzen roebel en krije in turnkey DevOps maklike tsjinst. As jo in lytse opstart binne mei in pear ûntwikkelders, wurket dit. Ynstee fan jo eigen DevOps yn te hieren, dy't moatte leare hoe't jo jo problemen kinne oplosse en op dit stuit in salaris betelje, krije jo in turnkey-oplossing foar alle problemen. Ja, der binne wat neidielen. Wy kinne as útbesteekker net sa belutsen wêze en fluch reagearje op feroarings. Mar wy hawwe in protte saakkundigens en klearebare praktiken. Wy garandearje dat wy yn elke situaasje it perfoarst fluch sille útfine en alle Kubernetes út 'e deaden opwekke.
Ik riede sterk oan om útbesteegje oan startups en fêstige bedriuwen oant in grutte wêr't jo in team fan 10 minsken kinne wije oan operaasjes, om't oars gjin punt hat. It hat perfoarst sin om dit út te besteegjen.
Oer Amazon en Google
- Kin in host fan in oplossing fan Amazon of Google wurde beskôge as in útbesteging?
Dmitry: Ja, fansels, dit lost in oantal problemen op. Mar wer binne der nuânses. Jo moatte noch begripe hoe't jo it brûke. Bygelyks, d'r binne tûzen lytse dingen yn it wurk fan Amazon AWS: de Load Balancer moat opwarmd wurde of in fersyk moat fan tefoaren skreaun wurde dat "jonges, wy sille ferkear krije, warmje de Load Balancer foar ús op!" Jo moatte dizze nuânses witte.
As jo wend binne ta minsken dy't har spesjalisearje, dan krije jo hast alle typyske dingen ticht. Wy hawwe no 40 yngenieurs, oan 'e ein fan it jier sille d'r wierskynlik 60 wêze - wy binne al dizze dingen definityf tsjinkommen. Sels as wy dit probleem wer tsjinkomme op ien of oare projekt, freegje wy inoar gau en witte hoe't wy it moatte oplosse.
Wierskynlik is it antwurd - fansels makket in hosted ferhaal wat diel makliker. De fraach is oft jo ree binne om dizze hosters te fertrouwen en oft se jo problemen sille oplosse. Amazon en Google hawwe it goed dien. Foar al ús gefallen - krekt. Wy hawwe gjin positive ûnderfinings mear. Alle oare wolken dy't wy besochten te wurkjen meitsje in protte problemen - Ager, en alles wat yn Ruslân is, en alle soarten OpenStack yn ferskate ymplemintaasjes: Headster, Overage - wat jo wolle. Se meitsje allegear problemen dy't jo net wolle oplosse.
Dêrom is it antwurd ja, mar yn feite binne d'r net heul in protte folwoeksen hosted oplossingen.
Wa hat Kubernetes nedich?
- En dochs, wa hat Kubernetes nedich? Wa moat al oerstappe nei Kubernetes, wa is de typyske Flaunt-kliïnt dy't spesjaal foar Kubernetes komt?
Dmitry: Dit is in nijsgjirrige fraach, want op it stuit, yn it spoar fan Kubernetes, komme in protte minsken nei ús: "Jongens, wy witte dat jo Kubernetes dogge, doch it foar ús!" Wy antwurdzje har: "Hearen, wy dogge gjin Kubernetes, wy dogge prod en alles wat dermei ferbûn is." Want it is op it stuit gewoan ûnmooglik om in produkt te meitsjen sûnder alle CI/CD en dit hiele ferhaal te dwaan. Elkenien is fuortgien fan 'e divyzje dat wy ûntwikkeling troch ûntwikkeling hawwe, en dan eksploitaasje troch eksploitaasje.
Us kliïnten ferwachtsje ferskate dingen, mar elkenien ferwachtet wat goed wûnder dat se bepaalde problemen hawwe, en no - hop! - Kubernetes sil se oplosse. Minsken leauwe yn wûnders. Yn har geast begripe se dat der gjin wûnder komme sil, mar yn har sielen hoopje se - wat as dizze Kubernetes no alles foar ús oplost, se prate der safolle oer! Ynienen hy no - gnizen! - en in sulveren kûgel, gnize! - en wy hawwe 100% uptime, alle ûntwikkelders kinne loslitte wat 50 kear yn produksje komt, en it crasht net. Yn it algemien, in wûnder!
As sokke minsken by ús komme, sizze wy: "Sorry, mar der is net sa'n ding as in wûnder." Om sûn te wêzen, moatte jo goed ite en oefenje. Om in betrouber produkt te hawwen, moat it betrouber makke wurde. Om in handige CI / CD te hawwen, moatte jo it sa meitsje. Dat is in soad wurk dat dien wurde moat.
De fraach beantwurdzje wa't Kubernetes nedich hat - gjinien hat Kubernetes nedich.
Guon minsken hawwe de misfetting dat se Kubernetes nedich binne. Minsken moatte, se hawwe in djippe behoefte om te stopjen mei tinken, studearjen en ynteressearje yn alle problemen fan ynfrastruktuer en de problemen fan it útfieren fan har applikaasjes. Se wolle dat applikaasjes gewoan wurkje en gewoan ynsette. Foar harren is Kubernetes de hope dat se ophâlde mei it hearren fan it ferhaal dat "wy leine dêr", of "wy kinne net útrolje," of wat oars.
De technysk direkteur komt meastentiids by ús. Se freegje him twa dingen: oan 'e iene kant, jou ús funksjes, oan' e oare kant, stabiliteit. Wy riede oan dat jo it op josels nimme en it dwaan. De sulveren kûgel, of leaver sulver-plated, is dat jo sille ophâlde te tinken oer dizze problemen en fergrieme tiid. Jo sille spesjale minsken hawwe dy't dit probleem sille slute.
De formulearring dat wy of in oar Kubernetes nedich binne is ferkeard.
Behearders hawwe Kubernetes echt nedich, om't it in heul ynteressant boartersguod is wêrmei jo kinne boartsje en mei tinken. Litte wy earlik wêze - elkenien hâldt fan boartersguod. Wy binne allegear bern earne, en as wy sjogge in nij, wy wolle boartsje it. Foar guon is dat bygelyks yn de administraasje ûntmoedige, om't se al genôch spile hawwe en al sa wurch binne dat se gewoan net wolle. Mar dit is net hielendal ferlern foar immen. As ik bygelyks al lang wurch bin fan boartersguod op it mêd fan systeemadministraasje en DevOps, dan hâld ik noch altyd fan it boartersguod, ik keapje noch wat nij. Alle minsken, op ien of oare manier, wolle noch wol wat soarte boartersguod.
Gjin needsaak om te boartsjen mei produksje. Wat ik ek kategoarysk oanbefel net te dwaan en wat ik no massaal sjoch: "Oh, in nij boartersguod!" - se rûnen om it te keapjen, kochten it en: "Litte wy it no nei skoalle nimme en it oan al ús freonen sjen litte." Doch dat net. Ik ferûntskuldigje my, myn bern groeie gewoan op, ik sjoch hieltyd wat yn bern, merk it by mysels, en generalisearje it dan nei oaren.
It definitive antwurd is: jo hawwe gjin Kubernetes nedich. Jo moatte jo problemen oplosse.
Wat jo berikke kinne is:
- prod falt net;
- sels as er bisiket to fallen, wy witte it fan tefoaren, en wy kinne der wat yn sette;
- wy kinne it feroarje mei de snelheid wêrmei't ús bedriuw it fereasket, en wy kinne it maklik dwaan; it feroarsaket ús gjin problemen.
D'r binne twa echte behoeften: betrouberens en dynamyk / fleksibiliteit fan útrol. Elkenien dy't op it stuit in soarte fan IT-projekten docht, nettsjinsteande hokker soarte bedriuw - sêft foar it gemak fan 'e wrâld, en dy't dit begrypt, moat dizze behoeften oplosse. Kubernetes mei de juste oanpak, mei it goede begryp en mei genôch ûnderfining kinne jo se oplosse.
Oer serverless
- As jo sjogge in bytsje fierder yn 'e takomst, dan besykje te lossen it probleem fan it ûntbrekken fan hoofdpijn mei ynfrastruktuer, mei de snelheid fan útrol en de snelheid fan de applikaasje feroarings, nije oplossings ferskine, bygelyks, serverless. Fiel jo potinsjeel yn dizze rjochting en, lit ús sizze, in gefaar foar Kubernetes en ferlykbere oplossingen?
Dmitry: Hjir moatte wy nochris in opmerking meitsje dat ik gjin sjenner bin dy't foarút sjocht en seit - it sil sa wêze! Hoewol't ik krekt dien itselde ding. Ik sjoch nei myn fuotten en sjoch dêr in bulte problemen, bygelyks hoe't transistors wurkje yn in kompjûter. It is grappich, krekt? Wy komme wat bugs tsjin yn 'e CPU.
Meitsje serverless frij betrouber, goedkeap, effisjint en handich, it oplossen fan alle ekosysteemproblemen. Hjir bin ik it mei Elon Musk iens dat in twadde planeet nedich is om skuldtolerânsje foar it minskdom te meitsjen. Hoewol ik net wit wat er seit, begryp ik dat ik net ree bin om sels nei Mars te fleanen en it sil moarn net barre.
Mei serverless is it dúdlik dúdlik dat dit in ideologysk korrekt ding is, lykas skuldtolerânsje foar it minskdom - twa planeten hawwe is better as ien. Mar hoe te dwaan it no? It ferstjoeren fan ien ekspedysje is gjin probleem as jo konsintrearje jo ynspannings op it. Ferskate ekspedysjes stjoere en dêr ferskate tûzenen minsken fêstigje, tink ik, is ek realistysk. Mar om it folslein skuldich tolerant te meitsjen sadat de helte fan it minskdom dêr wennet, it liket my no ûnmooglik, net beskôge.
Mei serverless ien op ien: it ding is cool, mar it is fier fan de problemen fan 2019. Tichter by 2030 - lit ús libje om it te sjen. Ik haw gjin twifel dat wy sille libje, wy sille perfoarst libje (werhelje foardat jo op bêd gean), mar no moatte wy oare problemen oplosse. It is as te leauwen yn 'e mearkepony Rainbow. Ja, in pear persint fan 'e gefallen binne oplost, en se wurde perfekt oplost, mar subjektyf is serverless in reinbôge ... Foar my is dit ûnderwerp te fier en te ûnbegryplik. Ik bin net ree om te praten. Yn 2019 kinne jo gjin inkele applikaasje skriuwe mei serverless.
Hoe Kubernetes sil evoluearje
- As wy nei dizze potensjeel prachtige fiere takomst gean, hoe tinke jo dat Kubernetes en it ekosysteem der omhinne sille ûntwikkelje?
Dmitry: Ik haw hjir in protte oer neitocht en ik haw in dúdlik antwurd. De earste is statefull - ommers, stateless is makliker te dwaan. Kubernetes ynvestearre yn earste ynstânsje mear yn dit, it begûn der allegear mei. Stateless wurket hast perfekt yn Kubernetes, der is gewoan neat te kleien. Der binne noch in soad problemen, of leaver, nuânses. Alles wurket dêr al geweldich foar ús, mar dat binne wy. It sil op syn minst in pear jier duorje foardat dit foar elkenien wurket. Dit is gjin berekkene yndikator, mar myn gefoel út myn holle.
Koartsein, statefull moat - en sil - tige sterk ûntwikkelje, om't al ús applikaasjes status opslaan; d'r binne gjin steatleaze applikaasjes. Dit is in yllúzje; jo hawwe altyd wat soart databank nedich en wat oars. Statefull giet oer it rjochtsjen fan alles wat mooglik is, it reparearjen fan alle bugs, it ferbetterjen fan alle problemen dy't op it stuit konfrontearre wurde - litte wy it oannimme neame.
It nivo fan it ûnbekende, it nivo fan ûnopgeloste problemen, it nivo fan kâns om wat tsjin te kommen sil signifikant sakje. Dit is in wichtich ferhaal. En operators - alles relatearre oan de kodifikaasje fan administraasjelogika, kontrôlelogika om in maklike tsjinst te krijen: MySQL maklike tsjinst, RabbitMQ maklike tsjinst, Memcache maklike tsjinst - yn 't algemien, al dizze komponinten wêrfan wy moatte wurde garandearre om út te wurkjen de doaze. Dit lost gewoan de pine op dat wy in databank wolle, mar wy wolle it net beheare, of wy wolle Kubernetes, mar wy wolle it net beheare.
Dit ferhaal fan operatorûntwikkeling yn ien of oare foarm sil de kommende pear jier wichtich wêze.
Ik tink dat it gebrûksgemak sterk moat tanimme - it fak sil mear en mear swart wurde, mear en betrouberder, mei mear en mear ienfâldige knoppen.
Ik harke ris nei in âld ynterview mei Isaac Asimov út de jierren '80 op YouTube op Saturday Night Live - in programma as Urgant, allinnich nijsgjirrich. Se fregen him oer de takomst fan kompjûters. Hy sei dat de takomst yn ienfâld is, krekt as de radio. De radio-ûntfanger wie oarspronklik in kompleks ding. Om in welle te fangen, moasten jo de knoppen foar 15 minuten draaie, de skewers draaie en yn 't algemien witte hoe't alles wurket, de fysika fan radiowave-oerdracht begripe. Dêrtroch siet der noch mar ien knop yn de radio.
No yn 2019 hokker radio? Yn de auto fynt de radio-ûntfanger alle weagen en de nammen fan de stasjons. De fysika fan it proses is net feroare yn 100 jier, mar it gemak fan gebrûk is. No, en net allinnich no, al yn 1980, doe't der in fraachpetear wie mei Azimov, elkenien brûkte de radio en gjinien tocht oer hoe't it wurke. It wurke altyd - dat is in gegeven.
Azimov sei doe dat it itselde wêze soe mei kompjûters - it gemak fan gebrûk sil tanimme. Wylst je yn 1980 trainearre wurde moasten om op in kompjûter op knoppen te drukken, sil dat yn de takomst net mear mear wêze.
Ik haw it gefoel dat der mei Kubernetes en mei de ynfrastruktuer ek in geweldige taname sil wêze yn it gebrûksgemak. Dit is neffens my fanselssprekkend - it leit oan it oerflak.
Wat te dwaan mei yngenieurs?
- Wat sil dan barre mei de yngenieurs en systeembehearders dy't Kubernetes stypje?
Dmitry: Wat barde der mei de boekhâlder nei de komst fan 1C? Oer it selde. Dêrfoar rekkenen se op papier - no yn it programma. Arbeidsproduktiviteit is tanommen mei oarders fan grutte, mar arbeid sels is net ferdwûn. As it earder 10 yngenieurs duorre om in gloeilampe yn te skroefjen, no sil ien genôch wêze.
De hoemannichte software en it oantal taken, it liket my, groeit no hurder dan nije DevOps ferskine en effisjinsje nimt ta. D'r is op it stuit in spesifyk tekoart op 'e merke en it sil lang duorje. Letter sil alles weromkomme nei in soarte fan normaliteit, wêryn de effisjinsje fan wurk sil tanimme, d'r sil mear en mear serverless wêze, oan Kubernetes sil in neuron wurde hechte, dy't alle boarnen krekt as nedich sil selektearje, en yn 't algemien sil alles sels dwaan, sa't it moat - de persoan stapt gewoan fuort en bemuoit him net.
Mar immen sil noch besluten moatte nimme. It is dúdlik dat it nivo fan kwalifikaasjes en spesjalisaasje fan dizze persoan heger is. Tsjintwurdich hoege jo op de boekhâlding gjin 10 meiwurkers dy't boekhâlde, sadat de hannen net wurch wurde. It is gewoan net nedich. In protte dokuminten wurde automatysk skansearre en erkend troch it elektroanyske dokumintbehearsysteem. Ien tûke haadboekhâlder is genôch, al mei folle gruttere feardichheden, mei goed begryp.
Yn 't algemien is dit de manier om te gean yn alle yndustry. Sa is it mei auto's: earder kaam der in auto mei in monteur en trije bestjoerders. Tsjintwurdich is it autoriden in ienfâldich proses dêr't wy allegear alle dagen oan meidogge. Nimmen tinkt dat in auto wat yngewikkeld is.
DevOps as systeemtechnyk giet net oeral - wurk en effisjinsje op heech nivo sille tanimme.
- Ik hearde ek in nijsgjirrich idee dat it wurk eins tanimme sil.
Dmitry: Fansels, hûndert prosint! Om't de hoemannichte software dy't wy skriuwe hieltyd groeit. It oantal problemen dat wy oplosse mei software groeit konstant. De hoemannichte wurk groeit. No is de DevOps-merk ferskriklik oerverhit. Dit is te sjen yn salarisferwachtingen. Op in goede manier, sûnder yn details te gean, soene der junioaren moatte wêze dy't X wolle, middens dy't 1,5X wolle, en senioaren dy't 2X wolle. En no, as jo nei de Moskouske DevOps-salarismerk sjogge, wol in junior fan X nei 3X en in senior wol fan X nei 3X.
Nimmen wit hoefolle it kostet. It salarisnivo wurdt mjitten troch jo fertrouwen - in folslein gekkehûs, om earlik te wêzen, in ferskriklik oerferhitte merk.
Fansels sil dizze situaasje heul gau feroarje - wat sêding moat foarkomme. Dit is net it gefal mei softwareûntwikkeling - nettsjinsteande it feit dat elkenien ûntwikkelders nedich is, en elkenien hat goede ûntwikkelders nedich, begrypt de merk wa't wat wurdich is - de yndustry is fêstige. Dat is dizze dagen net it gefal mei DevOps.
- Fan wat ik hearde, konkludearre ik dat de hjoeddeistige systeembehearder net te folle soargen moat meitsje, mar it is tiid om syn feardichheden te ferbetterjen en te meitsjen foar it feit dat moarn mear wurk sil wêze, mar it sil heger kwalifisearre wurde.
Dmitry: Hûndert persint. Yn 't algemien libje wy yn 2019 en de libbensregel is dit: lifetime learning - wy leare ús hiele libben. It liket my dat no elkenien dit al wit en fielt, mar it is net genôch om te witten - jo moatte it dwaan. Elke dei moatte wy feroarje. As wy dat net dogge, dan falle wy ier of let oan de kant fan it berop.
Wês taret op skerpe 180-graden bochten. Ik slút in situaasje net út dêr't wat radikaal feroaret, wat nij wurdt útfûn - it bart. Hop! - en wy dogge no oars. It is wichtich om hjirfoar taret te wêzen en gjin soargen te meitsjen. It kin barre dat moarn alles wat ik doch net nedich is - neat, ik haw myn hiele libben studearre en bin ree om wat oars te learen. It is gjin probleem. D'r is gjin need om bang te wêzen foar wurkfeiligens, mar jo moatte ree wêze om hieltyd wat nijs te learen.
Winsken en in minút fan reklame
- Hawwe jo in winsk?
Dmitry: Ja, ik ha ferskate winsken.
Earste en mercantile - abonnearje op . Bêste lêzers, gean nei YouTube en abonnearje op ús kanaal. Oer in moanne begjinne wy mei aktive útwreiding fan 'e fideotsjinst. Wy sille in soad edukative ynhâld hawwe oer Kubernetes, iepen en farieare: fan praktyske dingen, oant laboratoaria, oant djippe fûnemintele teoretyske dingen en hoe't jo Kubernetes brûke by de nivo fan prinsipes en patroanen.
De twadde mercantile winsk - gean nei en sette stjerren om't wy har fiede. As jo ús gjin stjerren jouwe, hawwe wy neat te iten. It is as mana yn in kompjûterspultsje. Wy dogge wat, wy dogge, wy besykje, immen seit dat dit ferskriklike fytsen binne, ien dat alles folslein mis is, mar wy geane troch en dogge absolút earlik. Wy sjogge in probleem, losse it op en diele ús ûnderfining. Dêrom, jou ús in stjer, it sil net fuortgean fan dy, mar it sil komme ta ús, om't wy feed op harren.
Tredde, wichtige, en net mear merkantile winsk - stopje te leauwen yn mearkes. Jo binne professionals. DevOps is in heul serieus en ferantwurde berop. Stopje mei spieljen op 'e wurkflier. Lit it foar jo klikke en jo sille it begripe. Stel jo foar dat jo nei it sikehûs komme, en dêr eksperimintearret de dokter op jo. Ik begryp dat dit miskien beledigend wêze kin foar ien, mar wierskynlik giet dit net oer jo, mar oer in oar. Fertel oaren om ek te stopjen. Dit ferneatiget echt it libben foar ús allegear - in protte begjinne operaasjes, admins en DevOps te behanneljen as dudes dy't wer wat brutsen hawwe. Dit wie "brutsen" meastentiids fanwege it feit dat wy gongen te spyljen, en net seach mei in kâld bewustwêzen dat dit is hoe't it is, en dat is hoe't it is.
Dit betsjut net dat jo net moatte eksperimintearje. Wy moatte eksperimintearje, wy dogge it sels. Om earlik te wêzen, spylje wy sels soms spultsjes - dit is fansels tige slim, mar neat minskliks is ús frjemd. Litte wy 2019 ferklearje as in jier fan serieuze, goed trochtochte eksperiminten, en net spultsjes op produksje. Wierskynlik sa.
- Tige dank!
Dmitry: Tankewol, Vitaly, sawol foar de tiid as foar it ynterview. Bêste lêzers, tige tank as jo dit punt ynienen hawwe berikt. Ik hoopje dat wy jo op syn minst in pear gedachten brocht hawwe.
Yn it fraachpetear rekke Dmitry de kwestje fan werf oan. No is dit in universele Switserske mes dat hast alle problemen oplost. Mar it wie net altyd sa. Op op it festival Dmitry Stolyarov sil fertelle jo oer dit ark yn detail. yn it rapport der komt fan alles: problemen en ferburgen nuânses fan Kubernetes, mooglikheden om dizze swierrichheden op te lossen en de hjoeddeiske útfiering fan werf yn detail. Doch mei ús op 27 en 28 maaie, wy sille de perfekte ark meitsje.
Boarne: www.habr.com