Në fund të majit organizuan një takimin online mbi . Diskutuam për kontejnerët, Kubernetes dhe orkestrimin në përgjithësi, kritere 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 «ITSumma». Më shumë se gjysma e klientëve të tij tashmë po kalojnë, apo duan të kalojnë në Kubernetes.
- Dmitry Stolyarov, CTO «Flant». Ka mbi 10 vjet eksperiencë në sistemet me konteiner.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ish-RAO EEC. Premtoi të flasë për raste në «enterprise-in e gjakosur».
- Andrey Fedorovsky, CTO «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 sistemesh, ish–Booking.com.Ai është njeriu që me duar e ka bërë shumë për Kubernetes.
Temat:
- Insightet e pjesëmarrësve mbi kontejnerët dhe orkestrimin (Docker, Kubernetes dhe të tjera); çfarë kanë provuar në praktikë apo kanë analizuar.
- Rasti: Kompania po zhvillon një plan për zhvillimin e infrastrukturës për shumë vite. Si merret vendimi, të ndërtohet (apo të përkthehet infrastruktura aktuale) në kontejner dhe Kubernetes apo jo?
- Problemet në botën cloud-native, çfarë nuk mjafton, le të fantazojmë se çfarë do të ndodhë nesër.
U zhvillua një diskutim interesant, mendimet e pjesëmarrësve ishin kaq të ndryshme dhe shkaktuan kaq shumë komente, saqë dëshirojmë t'i ndajmë ato me ju. Ka , dhe më poshtë është një përmbledhje e diskutimit.
Kubernetes është standard ose një marketing i shkëlqyer?
«Ne erdhëm te ai (Kubernetes. — Red.) kur askush nuk e njihte ende. Ne erdhëm te ai edhe atëherë kur nuk ekzistonte. Ne e dëshironim atë më parë» — Dmitry Stolyarov
Foto nga Reddit.com
5-10 vite më parë kishte një numër të madh mjetesh, dhe nuk kishte një standard të vetëm. Çdo gjashtë muaj shfaqej një produkt i ri, e ndonjëherë më shumë se një. Fillimisht Vagrant, pastaj Salt, Chef, Puppet,… «dhe ti çdo gjashtë muaj ndihesh i detyruar të rinovosh infrastrukturën tënde. Ke pesë administrues që vazhdimisht janë të zënë me rishkrimin e konfigurations» — kujton Andrey Fedorovsky. Ai mendon se Docker dhe Kubernetes kanë «shtypur» të tjerët. Docker është bërë standardi në pesë vitet e fundit, Kubernetes në dy vitet e fundit. Dhe kjo është e mirë për industrinë..
Dmitri Stolyarov dhe ekipi i tij e duan Kubernetes. Ata e donin një mjet të tillë përpara se të shfaqej dhe erdhën tek ai kur askush nuk e dinte për të. Aktualisht, për arsye komoditeti, ata nuk pranojnë klientë nëse kuptojnë që nuk do ta implementojnë Kubernetes. Sipas Dmitrit, kompania ka "mësime të shumta të mëdha suksesi në transformimin e trashëgimisë së tmerrshme".
Kubernetes nuk është vetëm orkestrimi i kontejnerëve, është një sistem i menaxhimit të konfiguracionit me një API të avancuar, komponent të punës me rrjetin, balancimin L3 dhe kontrollet Ingress, që lejon menaxhimin relativisht të lehtë të burimeve, të shkallëzimit dhe të abstraktimit nga nivelet e poshtme të infrastrukturës.
Fatkeqësisht, në jetën tonë duhet paguar për gjithçka. Dhe kjo taksë është e madhe, sidomos kur flitet për kalimin në Kubernetes për një kompani me një infrastrukturë të zhvilluar, siç mendon Ivan Kruglov. Ai do të mund të punonte si në një kompani me infrastrukturë tradicionale, ashtu edhe me Kubernetes. E rëndësishme është të kuptosh veçoritë e kompanisë dhe të tregut. Por, për shembull, për Evgeny Potapov, i cili do ta përmbledhte Kubernetes si një instrument orkestrimi të kontejnerëve, ky problem nuk ekziston.
Evgeny bëri një analogji me situatën në vitet 1990, kur lindte programimi objekt-orientuar si një mënyrë për të programuar aplikacione komplekse. Në atë kohë diskutimet nuk pushonin dhe shfaqeshin mjete të reja që mbështesnin OOP. Pastaj lindën mikroshërbimet si një mënyrë për të ikur nga koncepti monolitik. Kjo, nga ana e saj, çoi në lindjen e kontejnerëve dhe mjeteve për menaxhimin e tyre. "Mendoj se së shpejti do të arrijmë në atë kohë kur nuk do të ketë pyetje nëse duhet të shkruash një aplikacion të vogël në stilin mikroshërbim, do të shkruhet automatikisht si mikroshërbim," mendon ai. Po ashtu, Docker dhe Kubernetes me kalimin e kohës do të bëhen një zgjidhje standarde pa nevojën për zgjedhje.
Problemi i bazave në stateless
Foto nga
Në ditët e sotme ka shumë receta për të nisur bazat e të dhënave në Kubernetes. Edhe si të ndash një pjesë që punon me diskun I/O nga, në mënyrë të kushtueshme, pjesa e aplikacionit të bazës. A është e mundur që në të ardhmen bazat e të dhënave të modifikohen aq shumë sa që do të ofrohen në një kuti, ku një pjesë do të orkestrohet përmes Docker dhe Kubernetes, ndërsa pjesa tjetër e infrastrukturës, përmes një programi të veçantë, do të sigurojë pjesën e ruajtjes? Do të modifikohen bazat si produkt?
Ky përshkrim ngjan me menaxhimin e radhëve, por kërkesat për besueshmëri dhe sinkronizim të informacionit në bazat e të dhënave tradicionale janë shumë më të larta, mendon Andrei. Koeficienti i goditjes në cache në bazat normale është mbi 99%. Nëse një punëtor dështon, fillohet një tjetër, dhe cache 'ngrihet' nga e para. Derisa cache të mos ngrihet, punëtori punon ngadalë, kështu që nuk mund të përballojë ngarkesën e përdoruesve. Derisa nuk ka ngarkesë nga përdoruesit, cache nuk ngrihet. Kjo është një rreth vicioz.
Dmitri është në thelb kundër, - kuorumi dhe sharding zgjidhin problemin. Por Andrei insiston se zgjidhja nuk është e përshtatshme për të gjithë. Në disa raste, një kuorum do të bëjë, por ai i jep një ngarkesë shtesë rrjetit. Baza NoSQL nuk është e përshtatshme për çdo situatë.
Pjesëmarrësit e mitapit janë ndarë në dy grupe.
Denis dhe Andrei pretendojnë se gjithçka që shkruhet në disk — bazat dhe të tjera — në ekosistemin aktual të Kubernetesit nuk është e mundur. Nuk është e mundur të ruhet integriteti dhe qëndrueshmëria e të dhënave produktive në Kubernetes. Ky është një tipar themelor. 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ë vazhdueshme të të dhënave jashtë Kubernetes.
Evgeniy kundërshton: "Bazat në Kubernetes janë një traumë e nivelit të lartë, e lidhur me atë se nuk ka adoptim të cloud-it në Rusi". Kompanitë e vogla ose të mesme në Perëndim janë të fokusuar në Cloud. Bazat Amazon RDS janë më të lehta për t'u përdorur sesa të merresh vetë me Kubernetes. Në Rusi, përdorin Kubernetes "on-premise" dhe transferojnë aty bazat kur përpiqen të zbulojnë kafazët.
Dmitri gjithashtu nuk u pajtua me pretendimin se asnjë bazë nuk mund të mbahet në Kubernetes: "Baza është e ndryshme nga baza. Dhe nëse futni një bazë relacional të madhe — asnjëherë. Nëse futni diçka të vogël dhe cloud native, që është moralshëm e përgatitur për një jetë gjysmë ephemeral, gjithçka do të shkojë mirë." Dmitri gjithashtu përmendi se mjetet e menaxhimit të bazave nuk janë të gatshme për as Docker dhe as Kubernetes, kështu që shkaktohen vështirësi të mëdha.
Ivan, për pjesën e tij, është i sigurt se madje edhe nëse hiqen parimet stateful dhe stateless, ekosistemi i zgjidhjeve enterprise në Kubernetes ende nuk është gati. Me Kubernetesin është e vështirë të përmbushen kërkesat e legjislacionit dhe rregullatorëve. Për shembull, është e pamundur të krijohet një zgjidhje për ofrimin e identitetit, ku kërkohen garanci të rrepta për identifikimin e serverëve, deri në harduerin që vendoset në servera. Ky sektor po zhvillohet, por për momentin nuk ka zgjidhje.
Pjesëmarrësit nuk arritën të bien dakord, kështu që në këtë pjesë nuk do të ketë konkluzione. Më mirë do të sjellim disa shembuj praktik.
Rasti 1. Siguria kibernetike e "megaregulatorit" me baza jashtë Kubernetesit.
Në rastin e një sistemi të zhvilluar të sigurisë kibernetike, përdorimi i kontejnerëve dhe orkestrimit lejon mbrojtjen nga sulme dhe ndërhyrje. Për shembull, në një megaregulator, Denis dhe ekipi i tij realizuan një lidhje midis orkestratorit dhe një shërbimi SIEM të trajnuar, i cili analizon logët në kohë reale dhe identifikon procesin e sulmit, thyerjes ose dështimit. Në rast sulmi, përpjekjesh për të vendosur diçka, apo gjatë një ndërhyrjeje nga një virus-kërkesë, ai përmes orkestratorit aktivizon kontejnerët me aplikacionet më shpejt se sa ato infektohen, ose më shpejt se sa sulmuesi godet.
Rasti 2. Pjesërisht migrojnë bazat e të dhënave të Booking.com në Kubernetes.
Në Booking.com, baza kryesore e të dhënave është MySQL me replikim asinkron - ka master dhe një hierarki të të slaveve. Në momentin që Ivan u largua nga kompania, ishte nisur një projekt për transferimin e slaveve, të cilët mund të "përcaktohen" me një dëmtim të caktuar.
Përveç bazës kryesore, ka një instalim të Cassandra me orkestrim të shkruar vetë, të cilin e kishin krijuar edhe përpara se Kubernetes të dilte në treg. Problemet në këtë drejtim nuk ekzistojnë, por ajo ka persistent në SSD lokale. Magazinat e largëta, madje edhe brenda një qendre të të dhënave, nuk përdoren për shkak të problemeve me vonesat e larta.
Klasa e tretë e bazave të të dhënave është shërbimi i kërkimit të Booking.com, ku çdo nodë shërbimi ë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 hapësirë lokale, të cilat është e vështirë të "ngjiten" dhe "ngrohen".
Si rezultat, motori i kërkimit nuk u transferua në Kubernetes, dhe Ivan nuk mendon se do të ketë përpjekje të reja në afatin e afërt. Baza MySQL u transferua napjesërisht: vetëm slave, të cilat nuk është e frikshme të "përcaktohen". Cassandra "i mbijetoi" shkëlqyeshëm.
Zgjedhja e infrastrukturës si një detyrë pa zgjidhje të përgjithshme
Foto nga
Supozoni se kemi një kompani të re, ose një kompani ku një pjesë e infrastrukturës është ndërtuar në mënyrë të vjetër. Ajo po zhvillon një plan për zhvillimin e infrastrukturës për vitet në vazhdim. Si merret vendimi për të ndërtuar infrastrukturën në konteinerë dhe Kubernetes apo jo?
Kompani që garojnë për nanosekonda janë përjashtuar nga diskutimi. Konservatizmi e shëndoshë kompensohet për shkak të besueshmërisë, por megjithatë, ka kompani që është e rëndësishme të shqyrtojnë qasje të reja.
Ivan: "Unë do të filloja një kompani në cloud, thjesht sepse është më e shpejtë", edhe pse nuk është domosdoshmërisht më e lirë. Me zhvillimin e kapitalit të rrezikut, startup-et nuk kanë probleme të mëdha me financat, dhe detyra kryesore është të fitojnë tregun.
Ivan e mban qëndrimin se zhvillimi i infrastrukturës aktuale është kriteri i zgjedhjes. Nëse në të kaluarën janë bërë investime të konsiderueshme dhe ajo funksionon, nuk ka sens të riparosh. Nëse infrastruktura nuk është e zhvilluar dhe ka probleme me mjete, sigurinë dhe monitorimin, ka kuptim të shqyrtohet infrastruktura e shpërndarë.
Tatimi duhet paguar në çdo rast, dhe Ivan do të paguante atë, i cili do t’i mundësonte atij të paguante më pak në të ardhmen. "Sepse thjesht për shkak se udhëtoj në një tren të cilin e lëvizin të tjerët, do të shkoj shumë më larg se po të ulem në një tren tjetër, në të cilin do të duhet ta mbush vetë me karburant." thotë Ivan. Kur kompania është e re dhe kërkesat për latencë janë dhjetëra milisekonda, Ivan do të shikonte në "operatoret", në të cilët sot "fitojnë" bazat e të dhënave klasike. Ata ngritin zinxhirin e replikimit, i cili ndërlikon automatikisht në rast dështimi dhe kështu me radhë...
Për një kompani të vogël me disa serverë në Kubernetes nuk ka kuptim, - pohon Andrei. Por nëse ajo planifikon të rritet në njëqind serverë dhe më shumë, atëherë është e nevojshme automatizimi dhe një sistem menaxhimi të burimeve. 90 % e rasteve justifikojnë shpenzimet. Për më tepër, pavarësisht nga niveli i ngarkesës dhe burimeve. Të gjithë, nga startup-et deri te kompanitë e mëdha me miliona audiencë, është e arsyeshme të fillojnë të shikojnë gradualisht në produktet për orkestrimin e konteinerëve. "Po, kjo padyshim është e ardhmja", - beson Andrei.
Denis shënoi dy kriteret kryesore - shkallëzueshmëria dhe qëndrueshmëria e funksionimit. Ai do të zgjedhë ato mjete që i përshtaten më mirë këtij problemi. “Kjo mund të jetë një pajisje e montuar vetë, dhe mbi të Nutanix Community Edition. Mund të jetë një linjë e dytë si një aplikacion në Kuber me një bazë të dhënash në backend, e cila riprodhohet dhe ka parametra të caktuar RTO dhe RPO” (qëllimet e kohës së rikuperimit / pikës së rikuperimit — shembuj).
Evgeni theksoi një problem të mundshëm me kuadrot. Në momentin aktual, në treg nuk ka shumë specialistë të nivelit të lartë që kuptojnë “pjesët e brendshme”. Në të vërtetë, nëse teknologjia e zgjedhur është e vjetër, është e vështirë të rekrutosh dikë tjetër 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ë çështje e trajnimit të kuadrove.
Nëse do të vendosnim pyetjen e zgjedhjes: të ngremë një kompani të vogël në Public Cloud me baza në Amazon RDS ose “on premise” me baza në Kubernetes, atëherë, përkundër disa të metave, zgjedhja e pjesëmarrësve ishte Amazon RDS.
Pasi shumica e dëgjuesve të mitapit nuk janë nga “korporata e madhe”, atëherë zgjidhjet e shpërndara janë ajo për të cilën duhet të synojmë. Sistemet e ruajtjes së të dhënave duhet të jenë të shpërndara, të besueshme, dhe të krijojnë një latency që matet në disa milisekonda, maksimumi dhjetëra, — përfundoi Andrei.
Vlerësimi i përdorimit të Kubernetes
Dëgjuesi Anton Zhbankov bëri një pyetje për apologjetët e Kubernetes: si u zgjodh dhe u realizua studimi teknik-ekonomik? Pse Kubernetes, pse jo makinat virtuale, për shembull?
Foto nga
Dhe për këtë u përgjigjën Dmitri dhe Ivan. Në të dy rastet, përmes një metode provash dhe gabimesh, u krijua një renditje vendimesh, si rezultat i së cilës të dy pjesëmarrësit arritën te Kubernetes. Tani biznesi fillon të zhvillojë vetë softuer, i cili ka kuptim të transferohet në Kuber. Nuk është fjala për sistemet klasike të huaja, si 1C. Kubernetes ndihmon kur nd developers duan të bëjnë lëshime operacionale me përmirësimin e vazhdueshëm pa ndërprerje.
Ekipa e Andrei përpiqej të bënte një klasër të shkallëzueshëm mbi baza të makinave virtuale. Nodat binin si dominot, gjë që ndonjëherë çonte në rënien e klasit. “Teoretikisht, mund ta përfundojmë dhe ta mbështesim me dorë, por është e lodhshme. Dhe nëse ka një zgjidhje në treg që lejon të punosh nga kutia, atëherë ne shkojmë me kënaqësi drejt saj. Dhe ne e bëmë përfundimisht këtë zgjidhje.”, — thotë Andrei.
Ekzistojnë standarde për një analizë dhe llogaritje të tillë, por askush nuk mund të thotë sa të sakta janë ato në harduerin real në përdorim. Për llogaritjet është gjithashtu e rëndësishme të kuptosh çdo mjet dhe ekosistem, por kjo është e pamundur.
Çfarë na pret
Foto nga
Kur teknologjitë zhvillohen, shfaqen gjithnjë e më shumë copëza të shkëputura, dhe pastaj ndodh një kalim fazor, shfaqet një furnizues që ka shpenzuar mjaft "cash" për t'i bashkuar ato në një mjet të vetëm.
A nuk ju duket juve se do të vijë një moment kur do të shfaqet një mjet siç u bë Ubuntu për botën Linux? Mundësisht, një mjet i vetëm për kontejnerizimin dhe orkestrimin do të përfshijë edhe Kubernetes. Me të do të jetë e lehtë të ndërtojmë cloud on-premise.
Ivan dha përgjigjen: "Google po ndërton tani Anthos - kjo është oferta e tyre paketë, e cila aktivizon cloud-in dhe përfshin Kuber, Service Mesh, monitorimin - të gjithë rrethin që nevojitet për mikroshërbimet në 'on-premise'. Ne jemi thuajse në të ardhmen."
Denis gjithashtu përmendi Nutanix dhe VMWare me produktin e tyre vRealize Suite, të cilat mund të përballen me një detyrë të tillë pa kontejnerizim.
Dmitry ndau mendimin se zvogëlimi i "dhimbjes" dhe ulja e taksës janë dy drejtime ku pritet të ketë përmirësime.
Duke përmbledhur diskutimin, do të theksojmë këto probleme të infrastrukturës moderne
- Të tre pjesëmarrësit nënvizuan problemin me stateful.
- Lloje të ndryshme problemesh për mbështetje sigurie, duke përfshirë probabilitetin që në Docker të përfundojnë disa versione të Python, serverëve të aplikacioneve dhe komponenteve.
Shpenzimi i tepruar, për të cilin është më mirë të bëhet një mitap i veçantë.
Problemi i mësimdhënies, pasi orkestrimi përbën një ekosistem të komplikuar.
Problemi i përgjithshëm i industrisë është përdorimi i mjeteve jashtë qëllimit të tyre.Të tjerat përfundime mbeten për ju. Deri tani, ndjehet se lidhja Docker+Kubernetes nuk është e lehtë për t'u bërë një pjesë "qendrore" e sistemit. Për shembull, sistemet operative janë instaluar në harduerin e parë, diçka që nuk mund të thuhet për kontejnerët dhe orkestrimin. Ndoshta në të ardhmen do të bashkohen sistemet operative dhe kontejnerët me softuerin për menaxhimin e cloud-it.
Foto ngaDuke shfrytëzuar rastin, dua të dërgoj përshëndetje mamit dhe të kujtoj se kemi një grup në Facebook , kanal me publikime interesante nga bloget e ndryshme teknologjike. Dhe kanali im , ku bisedoj për menaxhimin e zhvillimit në kompanitë produktive.
Burimi: habr.com
