Maiatzaren amaieran lineako bilera bat egin zuen gaiari buruz . Edukiontziez, Kubernetez eta orkestrazioaz, printzipioz, azpiegiturak aukeratzeko irizpideez eta askoz gehiago hitz egin dugu. Parte-hartzaileek beren praktikaren kasuak partekatu zituzten.
Parte-hartzaileak:
- Evgeniy Potapov, ITSummako zuzendari nagusia. Bere bezeroen erdia baino gehiago dagoeneko mugitzen ari da edo Kubernetesera aldatu nahi dute.
- Dmitry Stolyarov, "Flant" zuzendaria. 10 urtetik gorako esperientzia du edukiontzi-sistemekin lanean.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, RAO UES ohia. Enpresa “odoltsuan” kasuei buruz hitz egingo duela agindu zuen.
- Andrey Fedorovsky, "News360.com" zuzendariaBeste jokalari batek konpainia erosi ondoren, ML eta AI proiektu eta azpiegitura batzuen arduraduna da.
- Ivan Kruglov, sistemen ingeniaria, Booking.com ohia.Kubernetesekin bere eskuekin asko egin zuen pertsona bera.
Gaiak:
- Parte-hartzaileen edukiontziei eta orkestrazioari buruzko ikuspegiak (Docker, Kubernetes, etab.); praktikan probatu edo aztertutakoa.
- Kasua: Enpresa urteak daramatza azpiegiturak garatzeko plan bat eraikitzen. Nola hartzen da erabakia edukiontzietara eta Kuber-era egungo azpiegitura eraiki (edo migratu) ala ez?
- Hodei-jatorrizko munduan arazoak, falta dena, pentsa dezagun bihar zer gertatuko den.
Eztabaida interesgarri bat sortu zen, parte-hartzaileen iritziak hain desberdinak ziren eta hainbeste iruzkin eragin zituenez, zuekin partekatu nahi ditudala. Jan , eta behean eztabaidaren laburpena.
Kubernetes marketing estandarra edo bikaina da dagoeneko?
“Hara (Kubernetes. - Ed.) iritsi ginen oraindik inork ez zekienean. Berarengana etorri ginen han ez zegoenean ere. Lehen nahi genuen" - Dmitri Stolyarov
Reddit.com-eko argazkia
Duela 5-10 urte tresna ugari zeuden, eta ez zegoen estandar bakarra. Sei hilean behin produktu berri bat agertzen zen, edo bat baino gehiago ere. Lehenengo Vagrant, gero Salt, Chef, Puppet,... “eta sei hilabetero berreraikitzen duzu zure azpiegitura. Konfigurazioak berridazten etengabe lanpetuta dauden bost administratzaile dituzu», gogoratzen du Andrey Fedorovskyk. Docker eta Kubernetes gainontzekoak "saretu" dituztela uste du. Docker estandar bihurtu da azken bost urteetan, Kubernetes azken bi urteetan. Eta hori ona da industriarentzat..
Dmitry Stolyarov eta bere taldeak Kuber maite dute. Halako tresna bat agertu baino lehen nahi zuten, eta inork ez zekienean iritsi ziren. Gaur egun, erosotasun arrazoiengatik, ez dute bezero bat hartzen ulertzen badute ez dutela berarekin Kubernetes ezarriko. Aldi berean, Dmitryren arabera, konpainiak "arrakasta erraldoi asko ditu ondare ikaragarria berriro egiteari buruz".
Kubernetes ez da edukiontzien orkestrazioa soilik, garatutako API bat, sareko osagai bat, L3 orekatzea eta Ingress kontrolagailuak dituen konfigurazio kudeaketa sistema bat da, eta horrek nahiko erraza da baliabideak kudeatzea, eskalatzea eta azpiegituraren beheko geruzetatik abstraitzea.
Zoritxarrez, gure bizitzan dena ordaindu behar dugu. Eta zerga hau handia da, batez ere azpiegitura garatua duen enpresa baten Kuberneteserako trantsizioaz hitz egiten badugu, Ivan Krugloven ustez. Aske lan egin zezakeen bai azpiegitura tradizionala duen enpresa batean, bai Kuber-ekin. Gauza nagusia enpresaren eta merkatuaren ezaugarriak ulertzea da. Baina, adibidez, Evgeny Potapov-entzat, Kubernetes edozein edukiontzi orkestratzeko tresnara orokortuko lukeena, ez da horrelako galderarik sortzen.
Evgeniyk 1990eko hamarkadako egoerarekin analogia bat egin zuen, objektuetara zuzendutako programazioa aplikazio konplexuak programatzeko modu gisa agertu zenean. Garai hartan, eztabaidak jarraitu zuen eta tresna berriak agertu ziren OOP laguntzeko. Orduan, mikrozerbitzuak kontzeptu monolitikotik urruntzeko modu gisa sortu ziren. Horrek, aldi berean, edukiontziak eta edukiontziak kudeatzeko tresnak sortu zituen. "Uste dut laster iritsiko garela mikrozerbitzuen aplikazio txiki bat idaztea merezi duen ala ez, mikrozerbitzu gisa idatziko da lehenespenez", uste du. Era berean, Docker eta Kubernetes irtenbide estandar bihurtuko dira azkenean aukerarik gabe.
Estaturik gabeko datu-baseen arazoa
Argazkia
Gaur egun, Kubernetesen datu-baseak exekutatzeko errezeta asko daude. Are gehiago, nola bereizi I/O diskoarekin lan egiten duen zatia, baldintzapean, datu-baseko aplikazio zatitik. Posible al da etorkizunean datu-baseak hainbeste aldatzea, ezen kutxa batean entregatuko direla, non zati bat Docker eta Kubernetes bidez orkestratuko den, eta azpiegituraren beste zati batean, software bereizi baten bidez, biltegiratze zatia emango den. ? Oinarriak aldatuko al dira produktu gisa?
Deskribapen hau ilararen kudeaketaren antzekoa da, baina datu-base tradizionaletan informazioaren fidagarritasuna eta sinkronizazioaren baldintzak askoz handiagoak dira, Andreyren ustez. Datu-base arruntetan cache-ren arrakasta-ratioa % 99an jarraitzen du. Langile bat jaisten bada, berri bat abiarazten da, eta cachea hutsetik "berotzen" da. Cachea berotu arte, langileak poliki funtzionatzen du, hau da, ezin da erabiltzaileen kargarekin kargatu. Erabiltzaileen kargarik ez dagoen bitartean, cachea ez da berotzen. Zirkulu zoro bat da.
Dmitry funtsean ez dago ados - quorumek eta zatiketak arazoa konpontzen dute. Baina Andreyk azpimarratzen du irtenbidea ez dela guztientzako egokia. Zenbait egoeratan, quoruma egokia da, baina karga gehigarria jartzen du sarean. NoSQL datu-base bat ez da egokia kasu guztietan.
Topaketan parte hartzaileak bi udalekutan banatu ziren.
Denis eta Andreyk diote diskoan idazten den guztia - datu-baseak eta abar- ezinezkoa dela egin egungo Kuber ekosisteman. Ezinezkoa da ekoizpen-datuen osotasuna eta koherentzia mantentzea Kubernetesen. Hau oinarrizko ezaugarri bat da. Irtenbidea: azpiegitura hibridoa.
MongoDB eta Cassandra bezalako hodeiko jatorrizko datu-base modernoek edo Kafka edo RabbitMQ bezalako mezu-ilarek ere Kubernetesetik kanpoko datu-biltegi iraunkorrak behar dituzte.
Evgeniyk honela dio: "Kuberako oinarriak errusiar ia edo enpresaren inguruko lesio bat dira, Errusian Hodei Adopziorik ez egotearekin lotuta dagoena". Mendebaldeko enpresa txiki edo ertainak Hodeia dira. Amazon RDS datu-baseak errazagoak dira Kubernetes-ekin zuk zeuk manipulatzea baino. Errusian Kuber "on-premise" erabiltzen dute eta hari baseak transferitzen dituzte zooa kentzen saiatzen ari direnean.
Dmitry ere ez zegoen ados Kubernetes-en datu-baserik ezin dela gorde esatearekin: “Base base-tik ezberdina da. Eta datu-base erlazional erraldoi bat bultzatzen baduzu, inola ere ez. Bizitza erdi-irafimerorako mentalki prestatuta dagoen zerbait txikia eta hodeia bultzatzen baduzu, dena ondo egongo da». Dmitryk ere aipatu zuen datu-baseak kudeatzeko tresnak ez daudela prest ez Dockerrentzat ez Kuberentzat, beraz, zailtasun handiak sortzen dira.
Ivanek, berriz, ziur dago egoera eta estaturik gabeko kontzeptuetatik abstraitzen bagara ere, Kubernetes-en enpresa irtenbideen ekosistema oraindik prest ez dagoela. Kuber-ekin, zaila da lege- eta arau-eskakizunak mantentzea. Esaterako, ezinezkoa da identitatea hornitzeko irtenbide bat egitea non zerbitzarien identifikazio-berme zorrotzak behar diren, zerbitzarietan txertatzen den hardwareraino. Arlo hau garatzen ari da, baina oraindik ez dago irtenbiderik.
Parte hartzaileak ezin izan ziren ados jarri, beraz, ez da zati honetan ondoriorik aterako. Eman ditzagun adibide praktiko pare bat.
1. kasua. Kuberatik kanpoko oinarriak dituen “mega-erregulatzaile” baten zibersegurtasuna
Garatutako zibersegurtasun sistema baten kasuan, edukiontziak eta orkestrazioak erabiltzeak erasoei eta intrusioei aurre egiteko aukera ematen du. Esaterako, mega-erregulatzaile batean, Denis eta bere taldeak orkestratzaile baten konbinazio bat inplementatu zuten SIEM zerbitzu trebatu batekin, erregistroak denbora errealean aztertzen dituena eta eraso, hacking edo hutsegite baten prozesua zehazten duena. Erasoren bat gertatuz gero, zerbait jartzen saiatzean edo ransomware birusaren inbasioa gertatuz gero, orkestratzailearen bitartez, infektatzen diren baino azkarrago edo erasotzaileak erasotzaileak baino azkarrago jasotzen ditu aplikazioak dituzten edukiontziak.
2. kasua. Booking.com datu-baseen migrazio partziala Kubernetesera
Booking.com-en, datu-base nagusia MySQL da erreplikazio asinkronoarekin - maisu bat eta esklaboen hierarkia oso bat dago. Ivanek enpresa utzi zuenerako, zenbait kalterekin "tiroak" litezkeen esklaboak transferitzeko proiektu bat martxan jarri zen.
Oinarri nagusiaz gain, auto-idatzitako orkestrazioarekin Cassandra instalazio bat dago, Kuber korrontean sartu baino lehen ere idatzi zena. Zentzu honetan ez dago arazorik, baina iraunkorra da tokiko SSDetan. Urruneko biltegiratzea, datu-zentro beraren barruan ere, ez da erabiltzen latentzia handiko arazoa dela eta.
Hirugarren datu-baseen klasea Booking.com bilaketa zerbitzua da, non zerbitzu-nodo bakoitza datu-base bat den. Bilaketa-zerbitzua Kuberra transferitzeko saiakerak huts egin zuen, nodo bakoitzak tokiko biltegiratze 60-80 GB dituelako, eta hori zaila da "altxatzea" eta "berotzea".
Ondorioz, bilatzailea ez zen Kubernetesera eraman, eta Ivanek ez du uste etorkizun hurbilean saiakera berriak egongo direnik. MySQL datu-basea erditik transferitu zen: Esklaboak bakarrik, "tiroak" izateko beldurrik ez dutenak. Cassandra primeran moldatu da.
Azpiegitura hautatzea irtenbide orokorrik gabeko zeregin gisa
Argazkia
Demagun enpresa berri bat dugula, edo azpiegituraren zati bat modu zaharrean eraikita dagoen enpresa bat. Urteetarako azpiegiturak garatzeko plan bat eraikitzen du. Nola hartzen da edukiontzietan eta Kuber-en azpiegiturak eraiki ala ez erabakitzea?
Eztabaidatik kanpo geratzen dira nanosegundoen alde borrokatzen duten enpresak. Kontserbadurismo osasungarriak fidagarritasunari dagokionez, badaude oraindik ere planteamendu berriak kontuan hartu beharko lituzkeen enpresak.
Ivan: "Zalantzarik gabe, enpresa bat sortuko nuke hodeian orain, besterik gabe, azkarragoa delako", nahiz eta ez derrigor merkeagoa izan. Arrisku-kapitalismoaren garapenarekin, startupek ez dute arazo handirik diruarekin, eta zeregin nagusia merkatua konkistatzeko da.
Ivanek uste du egungo azpiegituren garapena aukeraketa irizpidea da. Iraganean inbertsio serio bat egon bazen, eta funtzionatzen badu, ez du balio berriro egiteak. Azpiegitura garatu ez bada, eta tresnekin, segurtasunarekin eta monitorizazioarekin arazoak badira, zentzuzkoa da banatutako azpiegitura bat aztertzea.
Zerga edozein kasutan ordaindu beharko da, eta Ivanek etorkizunean gutxiago ordaintzeko aukera ematen zionari ordainduko zion. "Zeren eta beste batzuk mugitzen ari diren tren batean nagoelako, beste tren batean esertzen banaiz baino askoz urrunago ibiliko naiz, eta bertan erregaia neuk jarri behar dut."esan du Ivanek. Konpainia berria denean, eta latentzia-eskakizunak milisegundoko hamarnakakoak direnean, Ivanek gaur egun datu-base klasikoak "bilduta" dituzten "operadoreak" aztertuko lituzke. Erreplikazio-kate bat planteatzen dute, hutsegitearen kasuan bere burua aldatzen duena, etab...
Zerbitzari pare bat dituen enpresa txiki batentzat, Kuberak ez du zentzurik», dio Andreyk. Baina ehunka zerbitzari edo gehiago hazteko asmoa badu, automatizazioa eta baliabideak kudeatzeko sistema bat behar ditu. Kasuen %90ek kostua merezi dute. Gainera, karga eta baliabide maila edozein dela ere. Zentzuzkoa da guztiontzat, startupetatik hasi eta milioika audientzia duten enpresa handietaraino, pixkanaka edukiontzien orkestrazio produktuetara begiratzea. "Bai, hau da benetan etorkizuna", ziur dago Andrey.
Denisek bi irizpide nagusi zehaztu zituen: eskalagarritasuna eta funtzionamenduaren egonkortasuna. Zereginerako egokienak diren tresnak hautatuko ditu. "Zure belaunetan muntatutako ezizena izan liteke, eta Nutanix Community Edition du. Hau bigarren lerro bat izan daiteke Kuber-en atzeko aldean datu-base bat duen aplikazio baten moduan, erreplikatzen dena eta RTO eta RPO parametroak zehaztu dituena" (berreskuratzeko denbora/puntuaren helburuak - gutxi gorabehera.).
Evgeniyk langileekin arazo posible bat identifikatu zuen. Momentuz, ez dago merkatuan kualifikazio handiko espezialista asko "barruak" ulertzen dituztenak. Izan ere, aukeratutako teknologia zaharra bada, zaila da bizitzaz aspertuta eta nekatuta dauden adin ertaineko pertsonak ez diren beste inor kontratatzea. Beste parte-hartzaile batzuek langileen prestakuntza kontua dela uste badute ere.
Aukeraren galdera jartzen badugu: Hodei Publikoan enpresa txiki bat martxan jartzea Amazon RDS-en datu-baseekin edo Kubernetes-en datu-baseekin "on premise" batekin, orduan gabezia batzuk izan arren, Amazon RDS parte-hartzaileen aukera bihurtu zen.
Topaketaren entzule gehienak ez direnez "odoltsu" enpresakoak, orduan konponbide banatuak dira ahalegindu behar ditugunak. Datuak biltegiratzeko sistemak banatuak, fidagarriak eta latentzia sortu behar dira, milisegundoko unitateetan neurtuta, hamarnaka gehienez.", laburbildu zuen Andreyk.
Kubernetesen erabilera ebaluatzea
Anton Zhbankov entzuleak tranpa galdera bat egin zien Kubernetesen apologistei: nola aukeratu eta egin zenuten bideragarritasun azterketa? Zergatik Kubernetes, zergatik ez makina birtualak, adibidez?
Argazkia
Dmitryk eta Ivanek erantzun zioten. Bi kasuetan, saiakeraren bidez, erabaki sekuentzia bat hartu zen, eta horren ondorioz bi parte-hartzaileak Kubernetesera iritsi ziren. Orain enpresak Kuberra transferitzeko zentzua duen softwarea modu independentean garatzen hasi dira. Ez gara hirugarrenen sistema klasikoez ari, 1C adibidez. Kubernetes-ek garatzaileek argitalpenak azkar egin behar dituztenean laguntzen du, etengabeko hobekuntzarekin.
Andreyren taldea makina birtualetan oinarritutako kluster eskalagarri bat sortzen saiatu zen. Nodoak dominoak bezala erortzen ziren, eta horrek batzuetan klusterren kolapsoa ekarri zuen. «Teorian, amaitu eta eskuekin sostenga dezakezu, baina neketsua da. Eta merkatuan lan egiteko aukera ematen dizun irtenbiderik badago, pozik gaude. Eta horren ondorioz aldatu ginen», dio Andreyk.
Analisi eta kalkulu horietarako estandarrak daude, baina inork ezin du esan zein zehaztasuna duten benetako hardware funtzionamenduan. Kalkuluak egiteko, tresna eta ekosistema bakoitza ulertzea ere garrantzitsua da, baina hori ez da posible.
Gure zain dagoena
Argazkia
Teknologiak eboluzionatzen duen heinean, gero eta pieza desberdin gehiago agertzen dira, eta, orduan, fase-trantsizioa gertatzen da, dena tresna bakar batean elkartzeko adina ore hil duen saltzaile bat agertzen da.
Linux mundurako Ubuntu bezalako tresna bat egongo dela uste duzu? Beharbada edukiontzi bakarreko eta orkestrazio tresna batek Kuber barne hartuko du. Hodeiak lokalean eraikitzea erraztuko du.
Erantzuna Ivanek eman zuen: "Google orain Anthos eraikitzen ari da; hau da hodeia zabaltzen duen eskaintza paketatua eta Kuber, Service Mesh, monitorizazioa barne hartzen dituena, mikrozerbitzu lokaletarako behar den hardware guztia". Ia etorkizunean gaude».
Denisek Nutanix eta VMWare ere aipatu zituen vRealize Suite produktuarekin, edukiontzirik gabe antzeko zeregin bati aurre egin diezaiokeena.
Dmitryk bere iritzia partekatu zuen "mina" murriztea eta zergak murriztea hobekuntzak espero ditzakegun bi arlo direla.
Eztabaida laburbiltzeko, azpiegitura modernoen arazo hauek azpimarratzen ditugu:
- Hiru parte-hartzaile berehala identifikatu zuten arazo bat stateful-ekin.
- Segurtasun-laguntzarako hainbat arazo, Docker-ek Python-en, aplikazio-zerbitzarien eta osagaien hainbat bertsiorekin amaitzeko aukera barne.
Gehiegizko gastua, eta hori hobe da aparteko bilera batean eztabaidatzea.
Ikasteko erronka bat orkestrazioa ekosistema konplexua da.
Industrian ohiko arazo bat tresnak gaizki erabiltzea da.Gainerako ondorioak zure esku daude. Oraindik docker+Kubernetes konbinazioa sistemaren zati "zentral" bihurtzea ez dela erraza sentsazioa dago. Adibidez, sistema eragileak hardwarean instalatzen dira lehenik, eta hori ezin da esan edukiontziei eta orkestrazioari buruz. Agian, etorkizunean, sistema eragileak eta edukiontziak hodeian kudeatzeko softwarearekin bat egingo dute.
ArgazkiaAukera hau aprobetxatu nahi dut nire amari agurtzeko eta Facebook talde bat dugula gogoratzeko , kanala blog teknologiko ezberdinetako argitalpen interesgarriekin. Eta nire kanala , non produktu enpresetan garapena kudeatzeaz hitz egiten dudan.
Iturria: www.habr.com