Moderne infrastruktuur: probleme en vooruitsigte

Moderne infrastruktuur: probleme en vooruitsigte

Aan die einde van Mei ons 'n aanlyn vergadering oor die onderwerp gehou "Moderne infrastruktuur en houers: probleme en vooruitsigte". Ons het gesels oor houers, Kubernetes en orkestrasie in beginsel, kriteria vir die keuse van infrastruktuur en nog baie meer. Deelnemers het gevalle uit hul eie praktyk gedeel.

deelnemers:

  • Evgeniy Potapov, uitvoerende hoof van ITSumma. Meer as die helfte van sy klante trek óf reeds óf wil na Kubernetes oorskakel.
  • Dmitri Stolyarov, CTO "Flant". Het 10+ jaar ondervinding om met houerstelsels te werk.
  • Denis Remchukov (ook bekend as Eric Oldmann), bedryfshoof van argotech.io, oud-RAO UES. Hy het belowe om oor sake in die "bloedige" onderneming te praat.
  • Andrey Fedorovsky, CTO "News360.com"Nadat hy die maatskappy deur 'n ander speler gekoop het, is hy verantwoordelik vir 'n aantal ML- en KI-projekte en infrastruktuur.
  • Ivan Kruglov, stelselingenieur, oud-Booking.com.Dieselfde persoon wat baie met Kubernetes met sy eie hande gedoen het.

Temas:

  • Deelnemers se insigte oor houers en orkestrasie (Docker, Kubernetes, ens.); wat in die praktyk beproef of ontleed is.
  • Geval: Die maatskappy bou vir jare 'n infrastruktuurontwikkelingsplan. Hoe word die besluit geneem om die huidige infrastruktuur te bou (of te migreer) na houers en Kuber of nie?
  • Probleme in die wolk-inheemse wêreld, wat ontbreek, kom ons stel ons voor wat môre sal gebeur.

'n Interessante bespreking het gevolg, die menings van die deelnemers was so verskillend en het soveel kommentaar veroorsaak dat ek dit met julle wil deel. Eet drie uur video, en hieronder is 'n opsomming van die bespreking.

Is Kubernetes reeds 'n standaard of uitstekende bemarking?

“Ons het daarby gekom (Kubernetes. - Red.) toe niemand nog daarvan geweet het nie. Ons het na hom toe gekom al was hy nie daar nie. Ons wou dit voorheen hê" - Dmitri Stolyarov

Moderne infrastruktuur: probleme en vooruitsigte
Foto van Reddit.com

5-10 jaar gelede was daar 'n groot aantal gereedskap, en daar was geen enkele standaard nie. Elke ses maande het 'n nuwe produk verskyn, of selfs meer as een. Eers Vagrant, dan Salt, Chef, Puppet,... “en jy herbou jou infrastruktuur elke ses maande. Jy het vyf administrateurs wat voortdurend besig is om konfigurasies te herskryf,” onthou Andrey Fedorovsky. Hy meen dat Docker en Kubernetes die res “oorvol” het. Docker het die afgelope vyf jaar 'n standaard geword, Kubernetes in die afgelope twee jaar. En dit is goed vir die bedryf..

Dmitri Stolyarov en sy span is mal oor Kuber. Hulle wou so 'n gereedskap hê voordat dit verskyn het, en het daarby gekom toe niemand daarvan geweet het nie. Tans neem hulle geriefsredes nie 'n kliënt aan as hulle verstaan ​​dat hulle nie Kubernetes saam met hom sal implementeer nie. Terselfdertyd, volgens Dmitry, het die maatskappy "baie reusagtige suksesverhale oor die herskepping van die verskriklike nalatenskap."

Kubernetes is nie net houerorkestrasie nie, dit is 'n konfigurasiebestuurstelsel met 'n ontwikkelde API, 'n netwerkkomponent, L3-balansering en Ingress-beheerders, wat dit relatief maklik maak om hulpbronne te bestuur, skaal en abstraheer vanaf die onderste lae van die infrastruktuur.

Ongelukkig moet ons in ons lewe vir alles betaal. En hierdie belasting is groot, veral as ons praat oor die oorgang na Kubernetes van 'n maatskappy met 'n ontwikkelde infrastruktuur, soos Ivan Kruglov glo. Hy kon vrylik werk in 'n maatskappy met 'n tradisionele infrastruktuur en met Kuber. Die belangrikste ding is om die eienskappe van die maatskappy en die mark te verstaan. Maar, byvoorbeeld, vir Evgeny Potapov, wat Kubernetes sal veralgemeen na enige houer-orkestrasie-instrument, kom so 'n vraag nie op nie.

Evgeniy het 'n analogie getrek met die situasie in die 1990's, toe objekgeoriënteerde programmering verskyn het as 'n manier om komplekse toepassings te programmeer. Op daardie tydstip het die debat voortgegaan en nuwe instrumente het verskyn om OOP te ondersteun. Toe het mikrodienste na vore gekom as 'n manier om weg te beweeg van die monolitiese konsep. Dit het op sy beurt gelei tot die ontstaan ​​van houers en houerbestuursinstrumente. "Ek dink dat ons binnekort by 'n tyd sal kom wanneer daar geen twyfel sal wees oor of dit die moeite werd is om 'n klein mikrodienstoepassing te skryf nie, dit sal by verstek as 'n mikrodiens geskryf word," glo hy. Net so sal Docker en Kubernetes uiteindelik die standaardoplossing word sonder die behoefte aan keuse.

Die probleem van databasisse in staatloses

Moderne infrastruktuur: probleme en vooruitsigte
Foto deur Twitter: @jankolario op Unsplash

Deesdae is daar baie resepte vir die bestuur van databasisse in Kubernetes. Selfs hoe om die deel wat met die I/O-skyf werk te skei van, voorwaardelik, die toepassingsdeel van die databasis. Is dit moontlik dat databasisse in die toekoms soveel sal verander dat hulle in 'n boks afgelewer sal word, waar een deel deur Docker en Kubernetes georkestreer sal word, en in 'n ander deel van die infrastruktuur, deur aparte sagteware, sal die stoorgedeelte voorsien word ? Sal die basisse as 'n produk verander?

Hierdie beskrywing is soortgelyk aan toubestuur, maar die vereistes vir betroubaarheid en sinchronisasie van inligting in tradisionele databasisse is baie hoër, meen Andrey. Kastrefferverhouding in normale databasisse bly op 99%. As 'n werker afgaan, word 'n nuwe een geloods, en die kas "warm op" van nuuts af. Totdat die kas opgewarm is, werk die werker stadig, wat beteken dat dit nie met gebruikerslading gelaai kan word nie. Terwyl daar geen gebruikerlading is nie, word die kas nie warm nie. Dit is 'n bose kringloop.

Dmitri stem fundamenteel nie saam nie - kworums en skeuring los die probleem op. Maar Andrey dring daarop aan dat die oplossing nie vir almal geskik is nie. In sommige situasies is kworum geskik, maar dit plaas bykomende las op die netwerk. 'n NoSQL-databasis is nie in alle gevalle geskik nie.

Die deelnemers aan die byeenkoms is in twee kampe verdeel.

Denis en Andrey voer aan dat alles wat op skyf geskryf word - databasisse en so meer - onmoontlik is om in die huidige Kuber-ekosisteem te doen. Dit is onmoontlik om die integriteit en konsekwentheid van produksiedata in Kubernetes te handhaaf. Dit is 'n fundamentele kenmerk. Oplossing: hibriede infrastruktuur.

Selfs moderne wolk-inheemse databasisse soos MongoDB en Cassandra, of boodskaprye soos Kafka of RabbitMQ, vereis aanhoudende datawinkels buite Kubernetes.

Evgeniy maak beswaar: "Die basisse in Kubera is 'n byna-Russiese, of byna-ondernemingsbesering, wat verband hou met die feit dat daar geen wolkaanneming in Rusland is nie." Klein of mediumgrootte maatskappye in die Weste is Cloud. Amazon RDS-databasisse is makliker om te gebruik as om self met Kubernetes te peuter. In Rusland gebruik hulle Kuber “on-premise” en dra basisse daarheen oor wanneer hulle probeer om van die dieretuin ontslae te raak.

Dmitry het ook nie saamgestem met die stelling dat geen databasisse in Kubernetes gehou kan word nie: “Basis is anders as basis. En as jy 'n reuse relasionele databasis stoot, dan onder geen omstandighede nie. As jy iets kleins en vertroebel inheems stoot, wat geestelik voorberei is vir semi-verganklike lewe, sal alles reg wees.” Dmitry het ook genoem dat databasisbestuurnutsmiddels nie gereed is vir Docker of Kuber nie, so groot probleme ontstaan.

Ivan is op sy beurt seker dat selfs al abstraheer ons van die konsepte van staatsvol en staatloos, die ekosisteem van ondernemingsoplossings in Kubernetes nog nie gereed is nie. Met Kuber is dit moeilik om wetgewende en regulatoriese vereistes te handhaaf. Dit is byvoorbeeld onmoontlik om 'n oplossing vir identiteitsvoorsiening te maak waar streng waarborge van bedieneridentifikasie vereis word, tot by die hardeware wat in die bedieners ingevoeg word. Hierdie gebied ontwikkel, maar daar is nog geen oplossing nie.
Die deelnemers kon nie saamstem nie, so geen gevolgtrekkings sal in hierdie deel gemaak word nie. Kom ons gee 'n paar praktiese voorbeelde.

Geval 1. Kuberveiligheid van 'n "mega-reguleerder" met basisse buite Kubera

In die geval van 'n ontwikkelde kuberveiligheidstelsel maak die gebruik van houers en orkestrasie dit moontlik om aanvalle en indringers te bekamp. Byvoorbeeld, in een megareguleerder het Denis en sy span 'n kombinasie van 'n orkeseerder met 'n opgeleide SIEM-diens geïmplementeer wat logs in reële tyd ontleed en die proses van 'n aanval, inbraak of mislukking bepaal. In die geval van 'n aanval, 'n poging om iets te plaas, of in die geval van 'n losprysvirus-inval, tel dit, deur die orkeseerder, houers met toepassings vinniger op as wat hulle besmet raak, of vinniger as wat die aanvaller dit aanval.

Geval 2. Gedeeltelike migrasie van Booking.com-databasisse na Kubernetes

In Booking.com is die hoofdatabasis MySQL met asinchroniese replikasie - daar is 'n meester en 'n hele hiërargie van slawe. Teen die tyd dat Ivan die maatskappy verlaat het, is 'n projek van stapel gestuur om slawe oor te dra wat met sekere skade "geskiet" kon word.

Benewens die hoofbasis is daar 'n Cassandra-installasie met selfgeskrewe orkestrasie, wat geskryf is nog voordat Kuber die hoofstroom betree het. Daar is geen probleme in hierdie verband nie, maar dit is aanhoudend op plaaslike SSD's. Afgeleë berging, selfs binne dieselfde datasentrum, word nie gebruik nie weens die probleem van hoë latensie.

Die derde klas databasisse is die Booking.com-soekdiens, waar elke diensnodus 'n databasis is. Pogings om die soekdiens na Kuber oor te dra, het misluk, want elke nodus is 60-80 GB se plaaslike berging, wat moeilik is om te "lig" en "op te warm".

As gevolg hiervan is die soekenjin nie na Kubernetes oorgedra nie, en Ivan dink nie dat daar in die nabye toekoms nuwe pogings sal wees nie. Die MySQL-databasis is in die helfte oorgedra: slegs slawe, wat nie bang is om "geskiet" te word nie. Cassandra het perfek gevestig.

Infrastruktuurkeuse as 'n taak sonder 'n algemene oplossing

Moderne infrastruktuur: probleme en vooruitsigte
Foto deur Manuel Geissinger van Pexels

Kom ons sê ons het 'n nuwe maatskappy, of 'n maatskappy waar 'n deel van die infrastruktuur op die ou manier gebou is. Dit bou 'n infrastruktuur-ontwikkelingsplan vir jare. Hoe word die besluit geneem of infrastruktuur op houers en Kuber gebou moet word of nie?

Maatskappye wat vir nanosekondes veg, word van die bespreking uitgesluit. Gesonde konserwatisme betaal vrugte af in terme van betroubaarheid, maar daar is steeds maatskappye wat nuwe benaderings moet oorweeg.

Ivan: "Ek sal beslis nou 'n maatskappy op wolk begin, bloot omdat dit vinniger is," hoewel dit nie noodwendig goedkoper is nie. Met die ontwikkeling van waagkapitalisme het startups geen groot probleme met geld nie, en die hooftaak is om die mark te verower.

Ivan is van mening dat die ontwikkeling van die huidige infrastruktuur is 'n seleksiekriterium. As daar 'n ernstige belegging in die verlede was, en dit werk, dan is dit geen sin om dit oor te doen nie. As die infrastruktuur nie ontwikkel is nie, en daar is probleme met gereedskap, sekuriteit en monitering, dan maak dit sin om na 'n verspreide infrastruktuur te kyk.

Die belasting sal in elk geval betaal moet word, en Ivan sal die een betaal wat hom toegelaat het om in die toekoms minder te betaal. "Want bloot op grond van die feit dat ek op 'n trein ry wat ander beweeg, sal ek baie verder reis as wanneer ek op 'n ander trein klim wat ek self moet brandstof opgooi."sê Ivan. Wanneer die maatskappy nuut is, en die vertragingsvereistes tientalle millisekondes is, sal Ivan kyk na die "operateurs" waarin klassieke databasisse vandag "toegedraai" is. Hulle skep 'n replikasieketting wat homself oorskakel in geval van failover, ens ...

Vir 'n klein onderneming met 'n paar bedieners maak Kubera geen sin nie,” sê Andrey. Maar as dit beplan om te groei tot honderde bedieners of meer, dan benodig dit outomatisering en 'n hulpbronbestuurstelsel. 90% van gevalle is die koste werd. Verder, ongeag die vlak van vrag en hulpbronne. Dit maak sin vir almal, van beginners tot groot maatskappye met 'n gehoor van miljoene, om geleidelik na houerorkestrasieprodukte te kyk. "Ja, dit is regtig die toekoms," is Andrey seker.

Denis het twee hoofkriteria uiteengesit - skaalbaarheid en stabiliteit van werking. Hy sal die gereedskap kies wat die beste geskik is vir die taak. "Dit kan 'n noname wees wat op jou knieë saamgestel is, en dit het Nutanix Community Edition daarop. Dit kan 'n tweede reël wees in die vorm van 'n toepassing op Kuber met 'n databasis op die agterkant, wat gerepliseer word en gespesifiseerde RTO- en RPO-parameters het" (hersteltyd/puntdoelwitte - ongeveer).

Evgeniy het 'n moontlike probleem met personeel geïdentifiseer. Op die oomblik is daar nie baie hoogs gekwalifiseerde spesialiste op die mark wat die "guts" verstaan ​​nie. Inderdaad, as die gekose tegnologie oud is, dan is dit moeilik om iemand anders as middeljarige mense aan te stel wat verveeld en moeg is vir die lewe. Alhoewel ander deelnemers glo dat dit 'n kwessie van personeelopleiding is.
As ons die vraag van keuse stel: om 'n klein maatskappy in die Openbare Wolk te begin met databasisse in Amazon RDS of "op die perseel" met databasisse in Kubernetes, dan het Amazon RDS ten spyte van 'n paar tekortkominge die keuse van die deelnemers geword.

Aangesien die meerderheid van die meetup-luisteraars nie van die "bloedige" onderneming is nie verspreide oplossings is waarna ons moet streef. Databergingstelsels moet versprei, betroubaar wees en latensie skep gemeet in eenhede van millisekondes, hoogstens tiene", het Andrey opgesom.

Evaluering van Kubernetes-gebruik

Luisteraar Anton Zhbankov het 'n strikvraag aan Kubernetes-apologete gevra: hoe het jy 'n uitvoerbaarheidstudie gekies en uitgevoer? Hoekom Kubernetes, hoekom nie virtuele masjiene nie, byvoorbeeld?

Moderne infrastruktuur: probleme en vooruitsigte
Foto deur Tatyana Eremina op Unsplash

Dmitri en Ivan het dit geantwoord. In beide gevalle is 'n reeks besluite deur beproewing en fout geneem, waardeur beide deelnemers by Kubernetes aangekom het. Nou begin besighede om onafhanklik sagteware te ontwikkel wat sin maak om na Kuber oor te dra. Ons praat nie van klassieke derdepartystelsels, soos 1C nie. Kubernetes help wanneer ontwikkelaars vinnig vrystellings moet maak, met ononderbroke Deurlopende Verbetering.

Andrey se span het probeer om 'n skaalbare groepering te skep gebaseer op virtuele masjiene. Nodusse het soos domino's geval, wat soms tot die ineenstorting van die tros gelei het. "Teoreties kan jy dit klaarmaak en dit met jou hande ondersteun, maar dit is vervelig. En as daar 'n oplossing op die mark is wat jou toelaat om uit die boks te werk, dan gaan ons graag daarvoor. En ons het gevolglik oorgeskakel,” sê Andrey.

Daar is standaarde vir sulke ontleding en berekening, maar niemand kan sê hoe akkuraat dit is op werklike hardeware in werking nie. Vir berekeninge is dit ook belangrik om elke instrument en ekosisteem te verstaan, maar dit is nie moontlik nie.

Wat op ons wag

Moderne infrastruktuur: probleme en vooruitsigte
Foto deur Drew Beamer op Unsplash

Soos tegnologie ontwikkel, verskyn meer en meer uiteenlopende stukke, en dan vind 'n fase-oorgang plaas, 'n verkoper verskyn wat genoeg deeg doodgemaak het sodat alles in 'n enkele werktuig bymekaar kan kom.

Dink jy daar sal 'n tyd kom wanneer daar 'n instrument soos Ubuntu vir die Linux-wêreld sal wees? Miskien sal 'n enkele houer- en orkestrasie-instrument Kuber insluit. Dit sal dit maklik maak om wolke op die perseel te bou.

Die antwoord is deur Ivan gegee: "Google bou nou Anthos - dit is hul verpakte aanbod wat die wolk ontplooi en Kuber, Service Mesh, monitering insluit - al die hardeware wat nodig is vir mikrodienste op die perseel." Ons is amper in die toekoms.”

Denis het ook Nutanix en VMWare genoem met die vRealize Suite-produk, wat 'n soortgelyke taak kan hanteer sonder containerisering.

Dmitry het sy mening gedeel dat die vermindering van die "pyn" en die vermindering van belasting twee gebiede is waar ons verbeterings kan verwag.

Om die bespreking op te som, lig ons die volgende probleme van moderne infrastruktuur uit:

  • Drie deelnemers het dadelik 'n probleem met stateful geïdentifiseer.
  • Verskeie sekuriteitsondersteuningskwessies, insluitend die moontlikheid dat Docker met veelvuldige weergawes van Python, toepassingsbedieners en komponente sal eindig.
    Oorbesteding, wat beter is om in 'n aparte vergadering bespreek te word.
    'n Leeruitdaging as orkestrasie is 'n komplekse ekosisteem.
    ’n Algemene probleem in die bedryf is die misbruik van gereedskap.

    Die res van die gevolgtrekkings is aan jou. Daar is steeds 'n gevoel dat dit nie maklik is vir die Docker + Kubernetes-kombinasie om 'n "sentrale" deel van die stelsel te word nie. Byvoorbeeld, bedryfstelsels word eers op hardeware geïnstalleer, wat nie oor houers en orkestrasie gesê kan word nie. Miskien sal bedryfstelsels en houers in die toekoms met wolkbestuursagteware saamsmelt.

    Moderne infrastruktuur: probleme en vooruitsigte
    Foto deur Gabriel Santos Fotografia van Pexels

    Ek wil van die geleentheid gebruik maak om vir my ma te groet en jou te herinner dat ons 'n Facebook-groep het "Bestuur en ontwikkeling van groot IT-projekte", kanaal @feedmeto met interessante publikasies van verskeie tegnologie-blogs. En my kanaal @rybakalexey, waar ek praat oor die bestuur van ontwikkeling in produkmaatskappye.

Bron: will.com

Voeg 'n opmerking