Në fund të majit organizuam një mitap online mbi temën . Biseduam për kontejnerët, Kubernetes dhe orkestrimin në përgjithësi, kriteret për zgjedhjen e infrastrukturës dhe shumë të tjera. Pjesëmarrësit ndanë raste nga praktika e tyre.
Pjesëmarrësit:
- Evgeny Potapov, CEO i "ITSumma". Më shumë se gjysma e klientëve të tij ose po kalojnë, ose duan të kalojnë në Kubernetes.
- Dmitry Stolyarov, CTO i "Flant". Ka më shumë se 10 vjet përvojë pune me sistemet e kontejnerëve.
- Denis Remchukov (aka Eric Oldmann), COO i argotech.io, ish-RAO EES. Premtoi të tregojë për raste në "enterprisi gjakësor".
- Andrei Fedorovsky, CTO i "News360.com". Pas blerjes së kompanisë nga një lojtar tjetër, është përgjegjës për disa projekte ML dhe AI dhe për infrastrukturën.
- Ivan Kruglov, inxhinier sistemi, ish–Booking.com.Ai është ai njeri, i cili me duar e tij ka bërë shumë në Kubernetes.
Temat:
- Çfarë ndanë pjesëmarrësit mbi kontejnerët dhe orkestrimin (Docker, Kubernetes dhe të tjera); çfarë provuan në praktikë ose analizuan.
- Rasti: Në kompaninë e tyre po ndërtohet një plan zhvillimi të infrastrukturës për vitet në vazhdim. Si merret vendimi për të ndërtuar (apo transferuar) infrastrukturën aktuale në konteinerë dhe Kubernetes, apo jo?
- Problemet në botën e cloud-native, çfarë na mungon, le të imagjinojmë çfarë do të ndodhë nesër.
Nisi një diskutim interesant, mendimet e pjesëmarrësve ishin aq të ndryshme dhe shkaktuan kaq shumë komente, saqë do të doja t'i ndaja ato me ju. Ka , dhe më poshtë - përmbledhja e diskutimit.
A është Kubernetes tashmë një standard apo një marketing i shkëlqyer?
«Ne erdhëm te ai (Kubernetes. - Shënim) atëherë kur askush nuk e dinte për të. E arritëm atë kur ende nuk ekzistonte. E doja atë para kësaj» — Dmitry Stolyarov
Foto nga Reddit.com
Para 5-10 vjetësh kishte një sasi të madhe mjetesh, dhe nuk kishte asnjë standard të vetëm. Çdo gjashtë muaj shfaqej një produkt i ri, ndonjëherë të paktën një. Fillimisht Vagrant, pastaj Salt, Chef, Puppet,… «dhe çdo gjashtë muaj ndërronit infrastrukturën tuaj. Kishit pesë administratorë që ishin vazhdimisht të zënë duke rishkruar konfigurimet» — kujton Andrei Fyodorovsky. Ai beson se Docker dhe Kubernetes «shuarin» të tjerët. Docker është bërë standard në pesë vitet e fundit, ndërsa Kubernetes gjatë dy viteve të fundit. Dhe kjo është mirë për industrinë..
Dmitry Stolyarov dhe ekipa e tij e dashuron Kubernetes. Ata e donin një mjet të tillë para se të shfaqej, dhe e gjetën atë kur askush nuk e njihte. Në këtë moment, për arsye komoditeti, ata nuk pranojnë klientë nëse kuptojnë se nuk do të implementojnë Kubernetes për ta. Sipas Dmitry, kompania ka "m shumë histori suksesi të jashtëzakonshme për transformimin e trashëgimisë të tmerrshme".
Kubernetes nuk është vetëm orkestrimi i kontejnerëve, është një sistem menaxhimi të konfigurimeve me një API të avancuar, një komponent për menaxhimin e rrjetit, balancim L3 dhe kontrollues të Ingress, i cili lejon menaxhimin e burimeve në mënyrë relativisht të lehtë, shkallëzim dhe abstraksion nga nivelet e poshtme të infrastrukturës.
Fatkeq, në jetën tonë gjithçka ka një çmim. Dhe ky taksë është i lartë, veçanërisht kur flasim për kalimin në Kubernetes për kompanitë me një infrastrukturë të zhvilluar, siç mendon Ivan Kruglov. Ai mund të punojë lehtësisht si në një kompani me infrastrukturë tradicionale, ashtu edhe me Kubernetes. E rëndësishme është të kuptohet karakteristikat e kompanisë dhe tregut. Por, për shembull, për Evgeny Potapov, i cili do ta përmbledhte Kubernetes si një mjet për orkestrimin e kontejnerëve, ky pyetje nuk ekziston.
Evgeni bëri një analogji me situatën e viteve 1990, kur u shfaq programimi objekt-orientuar si një mënyrë për të programuara aplikacione të komplikuara. Në atë kohë, debatet vazhdonin dhe ishin duke u shfaqur mjete të reja që mbështesnin OOP-in. Më pas u shfaqën mikroshërbimet si një mënyrë për t’u larguar nga koncepti monolitik. Kjo, nga ana e saj, çoi në shfaqjen e kontejnerëve dhe mjeteve për menaxhimin e tyre. "Mendoj se shumë shpejt do të arrijmë në një kohë kur nuk do të ketë pyetje nëse do të shkruhet një aplikacion i vogël me mikroshërbime; do të shkruhet si një mikroshërbim nga defaulti," thotë ai. Po ashtu, Docker dhe Kubernetes me kalimin e kohës do të bëhen zgjidhje standarde pa nevojën për të bërë një zgjedhje.
Problemi i bazave në stateless
Foto nga
Sot, ka shumë receta për të nisur baza të dhënash në Kubernetes. Edhe si të ndash pjesën që punon me disk I/O nga, për shembull, pjesa e aplikacionit të bazës. A mund të ndodhë që në të ardhmen bazat e të dhënave të ndryshojnë aq shumë, saqë do të ofrohen në forma kornizash, ku një pjesë do të orkestrohet përmes Docker dhe Kubernetes, dhe në pjesën tjetër të infrastrukturës, përmes një programi të ndarë, do të ofrohet pjesa e ruajtjes? A do të ndryshojnë bazat si produkt?
Ky përshkrim duket si menaxhim i radhëve, por kërkesat për besueshmëri dhe sinkronizim të informacionit në bazat e dhënave tradicionale janë shumë më të larta, thotë Andrei. Ratia e goditjeve në cache në bazat normale mban nivelin 99%. Nëse një punëtor ndalon, aktivizohet një i ri, dhe cache 'ringrohet' nga zero. Deri sa cache të mos jetë ri-ngrohur, punëtori punon ngadalë, kështu që nuk mund të lejohet ngarkesë nga përdoruesit. Derisa nuk ka ngarkesë nga përdoruesit, cache nuk ri-ngrohet. Ky është një cikël i mbyllur.
Dmitri është në thelb në mosmarrëveshje, - kuorumet dhe sharding zgjidhin problemin. Por Andrei insiston se zgjidhja nuk i përshtatet të gjithëve. Në disa situata, një kuorum është i përshtatshëm, por ai shton një ngarkesë shtesë në rrjet. Baza NoSQL nuk është e përshtatshme në të gjitha rastet.
Anëtarët e mitapit u ndanë në dy grupe.
Denis dhe Andrei thonë se gjithçka që shkruan në disk — bazat dhe të tjera — nuk është e mundur të realizohet në ekosistemin aktual të Kubernetes. Nuk është e mundur të ruash integritetin dhe qëndrueshmërinë e të dhënave prodhuese në Kubernetes. Kjo është një veçori thelbësore. Zgjidhja: infrastruktura hibride.
Edhe bazat moderne cloud native, si MongoDB dhe Cassandra, ose radhët e mesazheve, si Kafka ose RabbitMQ, kërkojnë ruajtje të përhershme jashtë Kubernetes.
Evgeniy kundërshton: "Bazat në Kubernetes janë një traumë rreth-ruse, ose rreth-ndërmarrëse, e lidhur me faktin se në Rusi nuk ka pranim të Cloud-it." Kompanitë e vogla apo të mesme në Perëndim — janë Cloud. Përdorimi i Amazon RDS është më i thjeshtë se sa të merresh vetë me Kubernetes. Në Rusi, përdorin Kubernetes ‘on-premise’ dhe i transferojnë bazat kur përpiqen të shkëputen nga kafshë-zoologjike.
Dmitri gjithashtu nuk e pranoi pohimin se nuk mund të mbahen bazat në Kubernetes: "Baza është e ndryshme për çdo rast. Dhe nëse futim një bazë relacional gjigante — atëherë asnjëherë. Nëse futim diçka të vogël dhe cloud native, që është emocionalisht e gatshme për një jetë gjysmë efemere, gjithçka do të shkojë mirë." Dmitri gjithashtu përmendi se mjetet për menaxhimin e bazave nuk janë të gatshme as për Docker, as për Kuber, prandaj shfaqen vështirësi të mëdha.
Ivan, nga ana e tij, është i sigurt se edhe nëse abstrahohemi nga konceptet stateful dhe stateless, ekosistemi i zgjidhjeve enterprise në Kubernetes ende nuk është i gatshëm. Me Kuber, është e vështirë të mbahen kërkesat e organeve ligjore dhe rregullatore. Për shembull, nuk është e mundur të bëjmë një zgjidhje të ofrimit të identitetit, ku kërkohen garantime të rrepta të identifikimit të serverëve, deri tek hardueri që futet në servera. Kjo fushë po zhvillohet, por për momentin nuk ka zgjidhje.
Pjesëmarrësit nuk arritën të bien në marrëveshje, prandaj në këtë pjesë nuk do të ketë përfundime. Më mirë të japim disa shembuj praktikë.
Rasti 1. Siguria kibernetike e "megaregulatorit" me bazat jashtë Kubës
Në rastin e një sistemi të avancuar të sigurisë kibernetike, përdorimi i kontejnerëve dhe orkestrimit lejon mbrojtjen nga sulme dhe inkuadrime. Për shembull, në një mega-regulator, Denis dhe ekipi i tij implementuan një lidhje orkestruesi me një shërbim SIEM të trajnuar, i cili analizon log-et në kohë reale dhe përcakton procesin e sulmit, hacks ose dështimit. Në rast sulmi, përpjekjesh për të vendosur diçka, ose kur ndodh një infeksion nga një virus kërkues, ai ngre kontejnerët me aplikacionet më shpejt se sa ata infektohen, ose më shpejt se sa sulmuesi i sulmon.
Rasti 2. Pjesërisht zhvendosja e databazave të Booking.com në Kubernetes
Në Booking.com, databaza kryesore është MySQL me replikimin asinkron — ka një master dhe një hierarki të tërë skllavësh. Deri në momentin e largimit të Ivanit nga kompania, ishte e aktivizuar një projekt për transferimin e skllavëve, të cilët mund të "shkëputen" me një dëm të caktuar.
Përveç bazës kryesore, ka një instalim të Cassandra me orkestrim të shkruar nga vetë ne, i cili u krijua para se Kubernetes të bëhej mainstream. Nuk ka probleme në këtë drejtim, por ka persistent në SSD lokale. Zbatimet e largëta, edhe brenda një data-centri, nuk përdoren për shkak të problemeve me vonesë të lartë.
Klasa e tretë e bazave të të dhënave është shërbimi i kërkimit Booking.com, ku çdo nod i shërbimit është një bazë të dhënash. Përpjekjet për të transferuar shërbimin e kërkimit në Kubernetes dështuan, sepse çdo nod ka 60-80 GB të ruajtjes lokale, të cilat janë të vështira për tu 'ngritur' dhe 'ngrohur'.
Si rezultat, motori i kërkimit nuk u transferua në Kubernetes, dhe Ivan nuk mendon se do të ketë përpjekje të reja në të ardhmen e afërt. Baza e të dhënave MySQL u transferua gjysmë: vetëm Slave-t, të cilat nuk është frikë t'i 'qethim'. Cassandra 'u përshtat' shkëlqyeshëm.
Zgjedhja e infrastrukturës si një detyrë pa një zgjidhje të përgjithshme
Foto nga
Supozoni se kemi një kompani të re, ose një kompani ku një pjesë e infrastrukturës është e ndërtuar sipas mënyrës së vjetër. Aty po ndërtojnë një plan zhvillimi të infrastrukturës për disa vite. Si merret vendimi, të ndërtohet infrastruktura mbi konteinerë dhe Kubernetes apo jo?
Kompani, që garojnë për nanosekonda, janë të përjashtuara nga diskutimi. Një konservatorizëm i shëndoshë shpërblehet për arsye besueshmërie, por megjithatë, ka kompania që duhet të shqyrtojnë qasje të reja.
Ivan: "Unë do të filloja një kompani në cloud tani, thjesht sepse është më e shpejtë", edhe pse nuk është patjetër më e lira. Me zhvillimin e kapitalit rrezik, startup-et me para nuk kanë probleme të mëdha, dhe detyra kryesore është të fitojnë tregun.
Ivan është i mendimit se zhvillimi i infrastrukturës aktuale është një kriter zgjedhjeje. Nëse në të kaluarën janë bërë investime të mëdha, dhe kjo funksionon, atëherë nuk ka kuptim ta rishikosh. Nëse infrastruktura nuk është e zhvilluar, dhe ka probleme me mjetet, sigurinë dhe monitorimin, atëherë ka kuptim të shikosh drejt infrastrukturës së shpërndarë.
Taksa do të duhet të paguhet në çdo rast, dhe Ivan do të paguante atë, e cila do t'i lejonte atij të paguante më pak në të ardhmen. "Sepse thjesht duke u ndodhur në një tren, që e lëvizin të tjerët, do të arrij shumë më larg se nëse hip në një tren tjetër, në të cilin do të duhet të hedh vetë karburant.» — thotë Ivan. Kur kompania është e re dhe kërkesat për latency janë disa dhjetëra milisekonda, Ivan do të shikonte drejt "operatërve", në të cilët sot "dërgohen" bazat klasike të të dhënave. Ata ngritin një zinxhir replikimi që vetë переключается në rast dështimi, etj...
Për një kompani të vogël me disa serverë në Kubernet nuk ka kuptim, — deklaron Andrei. Por nëse ajo planifikon të rritet deri në njëqind serverë e më shumë, atëherë nevojitet automatizimi dhe një sistem menaxhimi të burimeve. 90% e rasteve justifikojnë shpenzimet. Dhe kjo pa marrë parasysh nivelin e ngarkesës dhe burimeve. Të gjithë, duke filluar nga startup-et e deri te kompanitë e mëdha me një audiencë prej miliona, ka sens të shikojnë gradualisht në produktet për orkestrimin e kontejnerëve. "Po, kjo është vërtet e ardhmja," — është i sigurt Andrei.
Denis përcaktoi dy kritere kryesore — shkallëzueshmëria dhe qëndrueshmëria e funksionimit. Ai do të zgjedhë ato mjete që i përshtaten më së miri kësaj detyre. "Kjo mund të jetë një pajisje e bërë manualisht dhe e bllokuar, me Nutanix Community Edition. Mund të jetë një aplikacion në Kubernetes me një bazë të dhënash mbrapa, e cila replikon dhe ka parametra të caktuar RTO dhe RPO" (objektet e kohës për rikuperim/pikës). shembuj).
Yevgeny shënoi një problem të mundshëm me përgatitjen e stafit. Aktualisht në treg nuk ka shumë specialistë të nivelit të lartë që kuptojnë "brendësinë". Në të vërtetë, nëse teknologjia e zgjedhur është e vjetër, është e vështirë të punësohet dikush, përveç njerëzve të moshuar që janë të mërzitur dhe të lodhur nga jeta. Megjithatë, pjesëmarrësit e tjerë mendojnë se kjo është një çështje përgatitjeje të stafit.
Nëse e vënë pyetjen e zgjedhjes: të fillohej një kompani të vogël në Public Cloud me bazat në Amazon RDS apo “on premise” me bazat në Kubernetes, atëherë, përkundër disa disavantazheve, zgjedhja e pjesëmarrësve ishte Amazon RDS.
Duke qenë se shumica e dëgjuesve të mitapit nuk vijnë nga "enterprise"-i i "përgjakshëm", atëherë zgjidhjet e shpërndara janë ato që duhet të kërkohen. Sistemet e ruajtjes së të dhënave duhet të jenë të shpërndara, të besueshme dhe të krijojnë latency, të matura në njësi milisekondash, maksimalisht dhjetëra., — përfundoi Andreu.
Vlerësimi i përdorimit të Kubernetes
Dëgjuesi Anton Zhbankov bëri një pyetje kapëse për avokatët e Kubernetes: si u zgjodh dhe u zhvillua studimi teknik dhe ekonomik? Pse Kubernetes, pse jo makina virtuale, për shembull?
Foto nga
Dmitri dhe Ivan i dhanë përgjigje. Në të dyja rastet, me metodën e përpjekjeve dhe gabimeve, u krijua një sekuencë vendimesh, me rezultat që të dy pjesëmarrësit arritën në Kubernetes. Tani biznesi fillon të zhvillojë vetë softuerin, i cili ka kuptim të transferohet në Kub. Nuk bëhet fjalë për sistemet klasike të palët të treta, si 1C. Kubernetes ndihmon kur zhvilluesve u nevojitet të bëjnë lirimin e shpejtë, me përmirësim të vazhdueshëm pa ndalesa.
Ekipi i Andreu përpiqej të krijonte një klasër të shkallëzuar mbi bazën e makinave virtuale. Nodet binin si domino, që ndonjëherë çonte në rënien e klastrit. "Teorikisht, mund të përfundohet dhe të mbahen me duar, por është e mërzitshme. Dhe nëse në treg ka një zgjidhje që lejon të punosh nga gjëja që merr, ne me kënaqësi shkojmë drejt saj. Dhe ne kaluam rezultatin," thotë Andreu.
Standartet për një analizë dhe llogaritje të tillë ekzistojnë, por askush nuk mund të thotë sa të vërteta janë ato në harduerin real gjatë përdorimit. Për llogaritjet është e rëndësishme të kuptohet çdo mjet dhe ekosistem, por kjo është e pamundur.
Çfarë na pret
Foto nga
Kur teknologjitë zhvillohen, shfaqen gjithnjë e më shumë pjesë të ndara, dhe pastaj ndodh një kalim fazor, shfaqet një tregtar që ka shpenzuar mjaft "para" për të bashkuar gjithçka në një mjet të vetëm.
A nuk mendoni se do të vije një moment kur do të ketë një mjet, siç bëri Ubuntu për botën Linux? Ndoshta një mjet i vetëm për kontejnerizim dhe orkestrim do të përfshijë edhe Kubernet. Me të do të bëhet e lehtë të ndërtosh cloud on-premise.
Ivan dha këtë përgjigje: "Google aktualisht është duke ndërtuar Anthos — kjo është oferta e tyre paketë, që shpërndan cloud dhe përfshin Kuber, Service Mesh, monitorimin — gjithë mbështetje që nevojitet për mikroshërbimet në 'on-premise'. Ne jemi gati për të ardhmen."
Denis gjithashtu përmendi Nutanix dhe VMWare me produktin vRealize Suite, të cilat mund të përballen me një detyrë të tillë pa kontejnerizim.
Dmitri shprehu mendimin se zvogëlimi i "dhembjes" dhe ulja e taksave janë dy drejtime ku priten përmirësime.
Duke përmbledhur diskutimin, të theksojmë problemet e dukshme me infrastrukturën moderne.
- Të tre pjesëmarrësit e ndanë problematikën me stateful.
- Probleme të ndryshme në mbështetje të sigurisë, duke përfshirë mundësinë që të përfundojnë në Docker disa versione të Python, serverë aplikacionesh dhe komponentë.
Teprica e shpenzimeve, për të cilën është më mirë të bëhet një mitap i veçantë.
Problemi i edukimit, pasi orkestrimi është një ekosistem i komplikuar.
Problemi i përgjithshëm i industrisë është përdorimi i mjeteve jashtë qëllimit të tyre.Të tjerat janë përfundime që duhet t'i bëni ju. Deri tani, perceptimi mbetet se lidhja Docker+Kubernetes nuk është e lehtë për t'u bërë një pjesë "qendrore" e sistemit. Për shembull, sistemet operative vendosen në hardware të parë, gjë që nuk mund të thuhet për kontejnerët dhe orkestrimin. Ndoshta në të ardhmen, sistemet operative dhe kontejnerët do të bashkohen me softuerin për menaxhimin e cloud.
Foto ngaDuke shfrytëzuar rastin, dua t'i dërgoj përshëndetje mamasë dhe t'i kujtoj se kemi një grup në Facebook. , kanal me publikime interesante nga blogje të ndryshme teknologjie. Dhe kanali im , ku flas për menaxhimin e zhvillimit në kompanitë e produktit.
Burimi: habr.com
