Në fund të majit mbajti një takim online për këtë temë . Ne folëm për kontejnerët, Kubernetes dhe orkestrimin në parim, kriteret për zgjedhjen e infrastrukturës dhe shumë më tepër. Pjesëmarrësit ndanë raste nga praktika e tyre.
Pjesëmarrësit:
- Evgeniy Potapov, CEO i ITSumma. Më shumë se gjysma e klientëve të saj ose tashmë janë duke lëvizur ose duan të kalojnë në Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Ka mbi 10 vjet përvojë pune me sistemet e kontejnerëve.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ish-RAO UES. Ai premtoi se do të fliste për raste në ndërmarrjen “e përgjakshme”.
- Andrey Fedorovsky, CTO "News360.com"Pas blerjes së kompanisë nga një lojtar tjetër, ai është përgjegjës për një numër projektesh dhe infrastrukturës ML dhe AI.
- Ivan Kruglov, inxhinier sistemesh, ish-Booking.com.I njëjti person që bëri shumë me Kubernetes me duart e veta.
Temat:
- Vështrimet e pjesëmarrësve në lidhje me kontejnerët dhe orkestrimin (Docker, Kubernetes, etj.); ajo që u provua në praktikë ose u analizua.
- Rasti: Kompania po ndërton një plan zhvillimi të infrastrukturës prej vitesh. Si merret vendimi nëse do të ndërtohet (ose migrimi i infrastrukturës aktuale) në kontejnerë dhe Kuber apo jo?
- Problemet në botën amtare të reve, çfarë mungon, le të imagjinojmë se çfarë do të ndodhë nesër.
U zhvillua një diskutim interesant, mendimet e pjesëmarrësve ishin aq të ndryshme dhe shkaktuan aq shumë komente sa dua t'i ndaj me ju. Hani , dhe më poshtë është një përmbledhje e diskutimit.
A është Kubernetes tashmë një marketing standard apo i shkëlqyeshëm?
“Ne erdhëm tek ajo (Kubernetes. - Ed.) kur askush nuk dinte ende për të. Ne erdhëm tek ai edhe kur ai nuk ishte aty. Ne e donim më parë" - Dmitry Stolyarov
Foto nga Reddit.com
5-10 vjet më parë kishte një numër të madh mjetesh, dhe nuk kishte asnjë standard të vetëm. Çdo gjashtë muaj shfaqej një produkt i ri, ose edhe më shumë se një. Së pari Vagrant, pastaj Salt, Chef, Puppet,... “dhe ju rindërtoni infrastrukturën tuaj çdo gjashtë muaj. Ju keni pesë administratorë që janë vazhdimisht të zënë me rishkrimin e konfigurimeve, "kujton Andrey Fedorovsky. Ai beson se Docker dhe Kubernetes e kanë "pushtuar" pjesën tjetër. Docker është bërë standard në pesë vitet e fundit, Kubernetes në dy vitet e fundit. Dhe është e mirë për industrinë.
Dmitry Stolyarov dhe ekipi i tij e duan Kuber. Ata donin një mjet të tillë përpara se të shfaqej, dhe erdhën tek ai kur askush nuk dinte për të. Aktualisht, për arsye komoditeti, ata nuk marrin përsipër një klient nëse e kuptojnë se nuk do të zbatojnë Kubernetes me të. Në të njëjtën kohë, sipas Dmitry, kompania ka "shumë histori gjigante suksesi për ribërjen e trashëgimisë së tmerrshme".
Kubernetes nuk është vetëm orkestrimi i kontejnerëve, por është një sistem menaxhimi i konfigurimit me një API të zhvilluar, një komponent rrjeti, balancues L3 dhe kontrollues Ingress, gjë që e bën relativisht të lehtë menaxhimin e burimeve, shkallës dhe abstraktit nga shtresat e poshtme të infrastrukturës.
Fatkeqësisht, në jetën tonë ne duhet të paguajmë për gjithçka. Dhe kjo taksë është e madhe, veçanërisht nëse flasim për kalimin në Kubernetes të një kompanie me një infrastrukturë të zhvilluar, siç beson Ivan Kruglov. Ai mund të punonte lirisht si në një kompani me infrastrukturë tradicionale ashtu edhe me Kuber. Gjëja kryesore është të kuptoni karakteristikat e kompanisë dhe të tregut. Por, për shembull, për Evgeny Potapov, i cili do ta përgjithësonte Kubernetes në çdo mjet orkestrimi të kontejnerëve, një pyetje e tillë nuk lind.
Evgeniy tërhoqi një analogji me situatën në vitet 1990, kur programimi i orientuar nga objekti u shfaq si një mënyrë e programimit të aplikacioneve komplekse. Në atë kohë, debati vazhdoi dhe u shfaqën mjete të reja për të mbështetur OOP. Më pas u shfaqën mikroshërbimet si një mënyrë për t'u larguar nga koncepti monolit. Kjo, nga ana tjetër, çoi në shfaqjen e kontejnerëve dhe mjeteve të menaxhimit të kontejnerëve. “Unë mendoj se së shpejti do të vijmë në një kohë kur nuk do të ketë asnjë pyetje nëse ia vlen të shkruhet një aplikacion i vogël mikroservice, ai do të shkruhet si një mikroshërbim si parazgjedhje,” beson ai. Po kështu, Docker dhe Kubernetes përfundimisht do të bëhen zgjidhja standarde pa pasur nevojë për zgjedhje.
Problemi i bazave të të dhënave në personat pa shtetësi
Foto nga
Në ditët e sotme, ka shumë receta për ekzekutimin e bazave të të dhënave në Kubernetes. Edhe si të ndahet pjesa që punon me diskun I/O nga, me kusht, pjesa e aplikacionit të bazës së të dhënave. A ka mundësi që në të ardhmen bazat e të dhënave të ndryshojnë aq shumë sa të dorëzohen në një kuti, ku një pjesë do të orkestrohet përmes Docker dhe Kubernetes dhe në një pjesë tjetër të infrastrukturës, përmes softuerit të veçantë, do të sigurohet pjesa e ruajtjes. ? A do të ndryshojnë bazat si produkt?
Ky përshkrim është i ngjashëm me menaxhimin e radhëve, por kërkesat për besueshmërinë dhe sinkronizimin e informacionit në bazat e të dhënave tradicionale janë shumë më të larta, beson Andrey. Raporti i goditjes së cache në bazat e të dhënave normale mbetet në 99%. Nëse një punëtor zbret, lëshohet një i ri dhe cache "ngrohet" nga e para. Derisa cache të ngrohet, punonjësi punon ngadalë, që do të thotë se nuk mund të ngarkohet me ngarkesën e përdoruesit. Ndërsa nuk ka ngarkesë të përdoruesit, cache nuk ngrohet. Është një rreth vicioz.
Dmitry thelbësisht nuk pajtohet - kuorumet dhe ndarjet e zgjidhin problemin. Por Andrey këmbëngul se zgjidhja nuk është e përshtatshme për të gjithë. Në disa situata, kuorumi është i përshtatshëm, por vendos ngarkesë shtesë në rrjet. Baza e të dhënave NoSQL nuk është e përshtatshme në të gjitha rastet.
Pjesëmarrësit e takimit u ndanë në dy kampe.
Denis dhe Andrey argumentojnë se gjithçka që është shkruar në disk - bazat e të dhënave dhe kështu me radhë - është e pamundur të bëhet në ekosistemin aktual Kuber. Është e pamundur të ruhet integriteti dhe konsistenca e të dhënave të prodhimit në Kubernetes. Kjo është një veçori themelore. Zgjidhja: infrastruktura hibride.
Edhe bazat moderne të të dhënave vendase të cloud si MongoDB dhe Cassandra, ose radhët e mesazheve si Kafka ose RabbitMQ, kërkojnë dyqane të vazhdueshme të të dhënave jashtë Kubernetes.
Evgeniy kundërshton: "Bazat në Kubera janë një dëmtim afër rus ose afër sipërmarrjes, i cili shoqërohet me faktin se nuk ka adoptim të reve në Rusi". Kompanitë e vogla ose të mesme në Perëndim janë Cloud. Bazat e të dhënave të Amazon RDS janë më të lehta për t'u përdorur sesa të ndërhyni vetë me Kubernetes. Në Rusi, ata përdorin Kuber "në premisë" dhe transferojnë baza në të kur përpiqen të heqin qafe kopshtin zoologjik.
Dmitry gjithashtu nuk u pajtua me deklaratën se asnjë bazë të dhënash nuk mund të mbahet në Kubernetes: "Baza është e ndryshme nga baza. Dhe nëse shtyni një bazë të dhënash gjigante relacionale, atëherë në asnjë rrethanë. Nëse shtyni diçka të vogël dhe vendase me re, e cila është e përgatitur mendërisht për një jetë gjysmë kalimtare, gjithçka do të jetë mirë.” Dmitry përmendi gjithashtu se mjetet e menaxhimit të bazës së të dhënave nuk janë gati as për Docker dhe as për Kuber, kështu që lindin vështirësi të mëdha.
Ivan, nga ana tjetër, është i sigurt se edhe nëse abstragojmë nga konceptet e shtetësisë dhe pa shtetësisë, ekosistemi i zgjidhjeve të ndërmarrjeve në Kubernetes nuk është ende gati. Me Kuber, është e vështirë të ruash kërkesat legjislative dhe rregullatore. Për shembull, është e pamundur të bëhet një zgjidhje për sigurimin e identitetit ku kërkohen garanci strikte për identifikimin e serverit, deri te hardueri që futet në serverë. Kjo zonë po zhvillohet, por ende nuk ka zgjidhje.
Pjesëmarrësit nuk ishin në gjendje të pajtoheshin, kështu që nuk do të nxirren përfundime në këtë pjesë. Le të japim disa shembuj praktikë.
Rasti 1. Siguria kibernetike e një "mega-rregullatori" me baza jashtë Kubera
Në rastin e një sistemi të zhvilluar të sigurisë kibernetike, përdorimi i kontejnerëve dhe orkestrimit bën të mundur luftimin e sulmeve dhe ndërhyrjeve. Për shembull, në një mega-rregullator, Denis dhe ekipi i tij zbatuan një kombinim të një orkestruesi me një shërbim SIEM të trajnuar që analizon regjistrat në kohë reale dhe përcakton procesin e një sulmi, hakimi ose dështimi. Në rast të një sulmi, një përpjekje për të vendosur diçka, ose në rast të një pushtimi të virusit ransomware, ai, nëpërmjet orkestruesit, merr kontejnerët me aplikacione më shpejt se sa infektohen ose më shpejt sesa sulmuesi i sulmon.
Rasti 2. Migrimi i pjesshëm i bazave të të dhënave të Booking.com në Kubernetes
Në Booking.com, baza e të dhënave kryesore është MySQL me replikim asinkron - ekziston një master dhe një hierarki e tërë skllevërsh. Në kohën kur Ivan u largua nga kompania, filloi një projekt për të transferuar skllevër që mund të "qëlloheshin" me dëme të caktuara.
Përveç bazës kryesore, ekziston një instalacion Cassandra me orkestrim të shkruar vetë, i cili u shkrua edhe para se Kuber të hynte në rrjedhën kryesore. Nuk ka probleme në këtë drejtim, por është e vazhdueshme në SSD-të lokale. Ruajtja në distancë, edhe brenda të njëjtës qendër të të dhënave, nuk përdoret për shkak të problemit të vonesës së lartë.
Klasa e tretë e bazave të të dhënave është shërbimi i kërkimit Booking.com, ku çdo nyje shërbimi është një bazë të dhënash. Përpjekjet për të transferuar shërbimin e kërkimit në Kuber dështuan, sepse secila nyje ka 60-80 GB memorie lokale, e cila është e vështirë të "ngritet" dhe "ngrohet".
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 në gjysmë: vetëm skllevër, të cilët nuk kanë frikë të "qëllohen". Cassandra është vendosur në mënyrë të përsosur.
Përzgjedhja e infrastrukturës si detyrë pa zgjidhje të përgjithshme
Foto nga
Le të themi se kemi një kompani të re, ose një kompani ku një pjesë e infrastrukturës është ndërtuar në mënyrën e vjetër. Ajo ndërton një plan zhvillimi të infrastrukturës prej vitesh. Si merret vendimi nëse do të ndërtohet apo jo infrastrukturë në kontejnerë dhe Kuber?
Kompanitë që luftojnë për nanosekonda janë të përjashtuara nga diskutimi. Konservatorizmi i shëndetshëm shpërblehet për sa i përket besueshmërisë, por ka ende kompani që duhet të marrin në konsideratë qasje të reja.
Ivan: "Unë patjetër do të hapja një kompani në cloud tani, thjesht sepse është më e shpejtë", megjithëse jo domosdoshmërisht më e lirë. Me zhvillimin e kapitalizmit sipërmarrës, startup-et nuk kanë probleme të mëdha me paratë dhe detyra kryesore është të pushtojnë tregun.
Ivan është i mendimit se Kriter përzgjedhjeje është zhvillimi i infrastrukturës aktuale. Nëse ka pasur një investim serioz në të kaluarën, dhe funksionon, atëherë nuk ka kuptim ta ribëjmë atë. Nëse infrastruktura nuk është e zhvilluar dhe ka probleme me mjetet, sigurinë dhe monitorimin, atëherë ka kuptim të shikohet një infrastrukturë e shpërndarë.
Taksa do të duhet të paguhet në çdo rast, dhe Ivan do të paguante atë që i lejonte të paguante më pak në të ardhmen. "Sepse thjesht për shkak të faktit që unë jam duke hipur në një tren që lëvizin të tjerët, unë do të udhëtoj shumë më larg sesa nëse ulem në një tren tjetër, në të cilin duhet të hedh vetë karburant.“, thotë Ivan. Kur kompania është e re dhe kërkesat e vonesës janë dhjetëra milisekonda, atëherë Ivan do të shikonte drejt "operatorëve" në të cilët sot janë "mbështjellë" bazat e të dhënave klasike. Ata ngrenë një zinxhir replikues, i cili ndërrohet vetë në rast dështimi, etj...
Për një kompani të vogël me disa serverë, Kubera nuk ka kuptim, "thotë Andrey. Por nëse planifikon të rritet në qindra serverë ose më shumë, atëherë ai ka nevojë për automatizim dhe një sistem të menaxhimit të burimeve. 90% e rasteve ia vlen kostoja. Për më tepër, pavarësisht nga niveli i ngarkesës dhe burimeve. Ka kuptim që të gjithë, nga startup-et deri tek kompanitë e mëdha me një audiencë prej miliona, të shikojnë gradualisht drejt produkteve të orkestrimit të kontejnerëve. "Po, kjo është me të vërtetë e ardhmja," është i sigurt Andrey.
Denis përshkroi dy kritere kryesore - shkallëzueshmëria dhe qëndrueshmëria e funksionimit. Ai do të zgjedhë mjetet që janë më të përshtatshme për detyrën. “Mund të jetë një noname i montuar në gjunjë dhe ka Nutanix Community Edition mbi të. Kjo mund të jetë një linjë e dytë në formën e një aplikacioni në Kuber me një bazë të dhënash në pjesën e pasme, e cila përsëritet dhe ka parametra të specifikuar RTO dhe RPO" (objektivat e kohës së rikuperimit/pikës - përafërsisht.).
Evgeniy identifikoi një problem të mundshëm me personelin. Për momentin, nuk ka shumë specialistë të kualifikuar në treg që e kuptojnë "zorrët". Në të vërtetë, nëse teknologjia e zgjedhur është e vjetër, atëherë është e vështirë të punësosh dikë tjetër përveç njerëzve të moshës së mesme që janë të mërzitur dhe të lodhur nga jeta. Edhe pse pjesëmarrësit e tjerë besojnë se kjo është një çështje e trajnimit të personelit.
Nëse vendosim pyetjen e zgjedhjes: të lëshojmë një kompani të vogël në Public Cloud me baza të të dhënave në Amazon RDS ose "në premisa" me baza të të dhënave në Kubernetes, atëherë pavarësisht disa mangësive, Amazon RDS u bë zgjedhja e pjesëmarrësve.
Meqenëse shumica e dëgjuesve të takimit nuk janë nga sipërmarrja "e përgjakshme", atëherë zgjidhjet e shpërndara janë ato për të cilat duhet të përpiqemi. Sistemet e ruajtjes së të dhënave duhet të jenë të shpërndara, të besueshme dhe të krijojnë vonesë të matur në njësi milisekonda, maksimumi dhjetëra", përmblodhi Andrey.
Vlerësimi i përdorimit të Kubernetes
Dëgjuesi Anton Zhbankov u bëri një pyetje kurth apologjetëve të Kubernetes: si zgjodhët dhe kryeni një studim fizibiliteti? Pse Kubernetes, pse jo makina virtuale, për shembull?
Foto nga
Dmitry dhe Ivan iu përgjigjën. Në të dyja rastet, përmes provës dhe gabimit, u mor një sekuencë vendimesh, si rezultat i të cilave të dy pjesëmarrësit arritën në Kubernetes. Tani bizneset kanë filluar të zhvillojnë në mënyrë të pavarur softuer që ka kuptim të transferohet në Kuber. Nuk po flasim për sisteme klasike të palëve të treta, siç është 1C. Kubernetes ndihmon kur zhvilluesit duhet të bëjnë shpejt publikime, me përmirësim të vazhdueshëm pa ndërprerje.
Ekipi i Andrey u përpoq të krijonte një grup të shkallëzuar të bazuar në makina virtuale. Nyjet binin si domino, gjë që ndonjëherë çonte në shembjen e grupit. “Teorikisht, mund ta përfundoni dhe ta mbështesni me duar, por është e lodhshme. Dhe nëse ka një zgjidhje në treg që ju lejon të punoni jashtë kutisë, atëherë ne jemi të lumtur ta bëjmë atë. Dhe si rezultat, ne u ndërruam, "thotë Andrey.
Ekzistojnë standarde për analiza dhe llogaritje të tilla, por askush nuk mund të thotë se sa të sakta janë ato në pajisje reale në funksionim. Për llogaritjet, është gjithashtu e rëndësishme të kuptohet çdo mjet dhe ekosistem, por kjo nuk është e mundur.
Çfarë na pret
Foto nga
Ndërsa teknologjia evoluon, shfaqen gjithnjë e më shumë pjesë të ndryshme dhe më pas ndodh një tranzicion fazor, shfaqet një shitës që ka vrarë brumë të mjaftueshëm që gjithçka të bashkohet në një mjet të vetëm.
A mendoni se do të vijë një kohë kur do të ketë një mjet si Ubuntu për botën Linux? Ndoshta një mjet i vetëm kontejnerizimi dhe orkestrimi do të përfshijë Kuber. Do ta bëjë të lehtë ndërtimin e reve në premisë.
Përgjigja u dha nga Ivan: "Google tani po ndërton Anthos - kjo është oferta e tyre e paketuar që shpërndan cloud dhe përfshin Kuber, Service Mesh, monitorimin - të gjithë harduerin që nevojitet për mikroshërbimet në premisë." Jemi pothuajse në të ardhmen”.
Denis përmendi gjithashtu Nutanix dhe VMWare me produktin vRealize Suite, të cilët mund të përballojnë një detyrë të ngjashme pa kontejnerizim.
Dmitry ndau mendimin e tij se ulja e "dhimbjes" dhe ulja e taksave janë dy fusha ku mund të presim përmirësime.
Për të përmbledhur diskutimin, ne theksojmë problemet e mëposhtme të infrastrukturës moderne:
- Tre pjesëmarrës identifikuan menjëherë një problem me gjendjen.
- Çështje të ndryshme të mbështetjes së sigurisë, duke përfshirë mundësinë që Docker të përfundojë me versione të shumta të Python, serverë aplikacionesh dhe komponentë.
Shpenzimet e tepërta, e cila është më mirë të diskutohet në një takim të veçantë.
Një sfidë mësimore si orkestrimi është një ekosistem kompleks.
Një problem i zakonshëm në industri është keqpërdorimi i mjeteve.Pjesa tjetër e konkluzioneve varet nga ju. Ekziston ende një ndjenjë se nuk është e lehtë për kombinimin Docker+Kubernetes të bëhet pjesë “qendrore” e sistemit. Për shembull, sistemet operative janë instaluar fillimisht në harduer, 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 e menaxhimit të cloud.
Foto ngaDo të doja të përfitoj nga ky rast për t'i përshëndetur nënës sime dhe t'ju kujtoj se ne kemi një grup në Facebook , kanal me botime interesante nga blogje të ndryshme teknologjike. Dhe kanali im , ku flas për menaxhimin e zhvillimit në kompanitë e produkteve.
Burimi: www.habr.com