Përshëndetje, emri im është Dmitry Krasnov. Për më shumë se pesë vjet unë kam administruar grupimet e Kubernetes dhe kam ndërtuar arkitektura komplekse mikroservice. Në fillim të këtij viti, ne lançuam një shërbim për menaxhimin e grupimeve të Kubernetes bazuar në Containerum. Duke shfrytëzuar këtë mundësi, do t'ju tregoj se çfarë është Kubernetes dhe si ndryshon integrimi me një shitës nga burimi i hapur.
Për të filluar, çfarë është . Ky është një sistem për menaxhimin e kontejnerëve në një numër të madh hostesh. Nga greqishtja, meqë ra fjala, përkthehet si "pilot" ose "timonier". Fillimisht u zhvillua nga Google dhe më pas u dhurua si një kontribut teknologjik për Cloud Native Computing Foundation, një organizatë ndërkombëtare jofitimprurëse që bashkon zhvilluesit kryesorë në botë, përdoruesit përfundimtarë dhe ofruesit e teknologjisë së kontejnerëve.
Menaxhoni një numër të madh kontejnerësh
Tani le të kuptojmë se çfarë lloj kontejnerësh janë këto. Ky është një aplikacion me të gjithë mjedisin e tij - kryesisht bibliotekat nga të cilat varet programi. E gjithë kjo paketohet në arkiva dhe paraqitet në formën e një imazhi që mund të ekzekutohet pavarësisht nga sistemi operativ, i testuar dhe më shumë. Por ka një problem - menaxhimi i kontejnerëve në një numër të madh hostesh është shumë i vështirë. Kjo është arsyeja pse Kubernetes u krijua.
Një imazh i kontejnerit përfaqëson një aplikacion plus varësitë e tij. Aplikacioni, varësitë e tij dhe imazhi i sistemit të skedarëve OS ndodhen në pjesë të ndryshme të imazhit, të ashtuquajturat shtresa. Shtresat mund të ripërdoren për kontejnerë të ndryshëm. Për shembull, të gjitha aplikacionet në një kompani mund të përdorin shtresën bazë të Ubuntu. Kur përdorni kontejnerë, nuk ka nevojë të ruani kopje të shumta të një shtrese të vetme bazë në host. Kjo ju lejon të optimizoni ruajtjen dhe shpërndarjen e imazhit.
Kur duam të ekzekutojmë një aplikacion nga një kontenier, shtresat e nevojshme mbivendosen mbi njëra-tjetrën dhe formohet një sistem skedari mbivendosje. Një shtresë regjistrimi vendoset sipër, e cila hiqet kur ena ndalon. Kjo siguron që kur kontejneri të funksionojë, aplikacioni do të ketë gjithmonë të njëjtin mjedis, i cili nuk mund të ndryshohet. Kjo garanton riprodhueshmërinë e mjedisit në OS të ndryshëm pritës. Qoftë Ubuntu apo CentOS, mjedisi do të jetë gjithmonë i njëjtë. Për më tepër, kontejneri është i izoluar nga hosti duke përdorur mekanizma të integruar në kernelin Linux. Aplikacionet në një kontejner nuk shohin skedarë, procese të hostit dhe kontejnerëve fqinjë. Ky izolim i aplikacioneve nga hosti OS ofron një shtresë shtesë sigurie.
Ka shumë mjete të disponueshme për të menaxhuar kontejnerët në një host. Më i popullarizuari prej tyre është Docker. Kjo ju lejon të siguroni ciklin e plotë të jetës së kontejnerëve. Sidoqoftë, funksionon vetëm në një host. Nëse keni nevojë të menaxhoni kontejnerët nëpër hoste të shumtë, Docker mund ta bëjë jetën ferr për inxhinierët. Kjo është arsyeja pse Kubernetes u krijua.
Kërkesa për Kubernetes është pikërisht për shkak të aftësisë për të menaxhuar grupet e kontejnerëve në host të shumëfishtë si një lloj entiteti i vetëm. Popullariteti i sistemit ofron mundësinë për të ndërtuar DevOps ose Operacione Zhvillimi, në të cilat Kubernetes përdoret për të drejtuar proceset e këtij DevOps.
Figura 1. Paraqitje skematike se si funksionon Kubernetes
Automatizimi i plotë
DevOps është në thelb automatizimi i procesit të zhvillimit. Përafërsisht, zhvilluesit shkruajnë kodin që ngarkohet në depo. Më pas, ky kod mund të mblidhet automatikisht menjëherë në një kontejner me të gjitha bibliotekat, të testohet dhe të "përdoret" në fazën tjetër - Skenimi, dhe më pas menjëherë në Prodhim.
Së bashku me Kubernetes, DevOps ju lejon të automatizoni këtë proces në mënyrë që të ndodhë praktikisht pa pjesëmarrje nga vetë zhvilluesit. Për shkak të kësaj, ndërtimi është dukshëm më i shpejtë, pasi zhvilluesi nuk duhet ta bëjë këtë në kompjuterin e tij - ai thjesht shkruan një pjesë të kodit, e shtyn kodin në depo, pas së cilës hapet tubacioni, i cili mund të përfshijë procesin të ndërtimit, testimit dhe nxjerrjes. Dhe kjo ndodh me çdo angazhim, kështu që testimi ndodh vazhdimisht.
Në të njëjtën kohë, përdorimi i një kontejneri ju lejon të jeni të sigurt se i gjithë mjedisi i këtij programi do të lëshohet në prodhim pikërisht në formën në të cilën është testuar. Kjo do të thotë, nuk do të ketë probleme si "ka pasur disa versione në provë, të tjerët në prodhim, por kur i instaluam, gjithçka ra". Dhe duke qenë se sot kemi një tendencë drejt arkitekturës së mikroserviseve, kur në vend të një aplikacioni të madh ka qindra të vogla, për t'i administruar ato me dorë, do të kërkohet një staf i madh punonjësish. Kjo është arsyeja pse ne përdorim Kubernetes.
Të mirat, të mirat, të mirat
Nëse flasim për avantazhet e Kubernetes si një platformë, atëherë ai ka avantazhe të rëndësishme nga pikëpamja e menaxhimit të një arkitekture mikroshërbimi.
- Menaxhimi i kopjeve të shumta. Gjëja më e rëndësishme është menaxhimi i kontejnerëve nëpër hoste të shumtë. Më e rëndësishmja, menaxhoni kopjet e shumëfishta të aplikacioneve në kontejnerë si një entitet i vetëm. Falë kësaj, inxhinierët nuk duhet të shqetësohen për çdo enë individuale. Nëse një nga kontejnerët rrëzohet, Kubernetes do ta shohë këtë dhe do ta rifillojë përsëri.
- Rrjeti i grupimeve. Kubernetes gjithashtu ka një të ashtuquajtur rrjet grupi me hapësirën e vet të adresave. Falë kësaj, çdo pod ka adresën e vet. Një nënpod kuptohet si njësia minimale strukturore e një grupi në të cilin kontejnerët lëshohen drejtpërdrejt. Për më tepër, Kubernetes ka funksionalitet që kombinon një balancues të ngarkesës dhe Zbulimin e Shërbimit. Kjo ju lejon të heqni qafe menaxhimin manual të adresës IP dhe ta delegoni këtë detyrë te Kubernetes. Dhe kontrollet automatike të shëndetit do të ndihmojnë në zbulimin e problemeve dhe ridrejtimin e trafikut në grupet e punës.
- Menaxhimi i konfigurimit. Kur menaxhoni një numër të madh aplikacionesh, bëhet e vështirë të menaxhoni konfigurimin e aplikacionit. Për këtë qëllim, Kubernetes ka burime të veçanta ConfigMap. Ato ju lejojnë të ruani në mënyrë qendrore konfigurimet dhe t'i ekspozoni ato në pods kur ekzekutoni aplikacionet. Ky mekanizëm na lejon të garantojmë konsistencën e konfigurimit në të paktën dhjetë ose njëqind kopje të aplikacioneve.
- Vëllimet e vazhdueshme. Kontejnerët janë në thelb të pandryshueshëm dhe kur kontejneri ndalet, të gjitha të dhënat e shkruara në sistemin e skedarëve do të shkatërrohen. Por disa aplikacione ruajnë të dhënat direkt në disk. Për të zgjidhur këtë problem, Kubernetes ka një funksionalitet të menaxhimit të ruajtjes së diskut - Vëllimet e vazhdueshme. Ky mekanizëm përdor ruajtjen e jashtme për të dhënat dhe mund të transferojë ruajtje të vazhdueshme, bllok ose skedar, në kontejnerë. Kjo zgjidhje ju lejon të ruani të dhënat veçmas nga punëtorët, gjë që i ruan ato nëse të njëjtët punëtorë prishen.
- Balancues i ngarkesës. Edhe pse në Kubernetes ne menaxhojmë entitete abstrakte si Deployment, StatefulSet, etj., përfundimisht kontejnerët funksionojnë në makina të rregullta virtuale ose serverë harduerësh. Ata nuk janë të përsosur dhe mund të bien në çdo kohë. Kubernetes do ta shohë këtë dhe do të ridrejtojë trafikun e brendshëm në kopje të tjera. Por çfarë të bëjmë me trafikun që vjen nga jashtë? Nëse thjesht e drejtoni trafikun te një prej punëtorëve, nëse ai rrëzohet, shërbimi do të bëhet i padisponueshëm. Për të zgjidhur këtë problem, Kubernetes ka shërbime si Load Balancer. Ato janë krijuar për të konfiguruar automatikisht një balancues të jashtëm cloud për të gjithë punëtorët në grup. Ky balancues i jashtëm drejton trafikun e jashtëm te punëtorët dhe monitoron vetë statusin e tyre. Nëse një ose më shumë punëtorë bëhen të padisponueshëm, trafiku ridrejtohet te të tjerët. Kjo ju lejon të krijoni shërbime shumë të disponueshme duke përdorur Kubernetes.
Kubernetes funksionon më mirë kur ekzekuton arkitekturat mikroservice. Është e mundur të zbatohet sistemi në arkitekturën klasike, por është e pakuptimtë. Nëse një aplikacion nuk mund të funksionojë në kopje të shumta, atëherë çfarë ndryshimi ka - në Kubernetes apo jo?
Kubernetes me burim të hapur
Kubernetes me burim të hapur është një gjë e mrekullueshme: e instalova dhe funksionon. Mund ta vendosni në serverët tuaj të harduerit, në infrastrukturën tuaj, të instaloni master dhe punëtorë mbi të cilët do të ekzekutohen të gjitha aplikacionet. Dhe më e rëndësishmja, e gjithë kjo është falas. Megjithatë, ka nuanca.
- E para është kërkesa për njohuri dhe përvojë e administratorëve dhe inxhinierëve që do të vendosin dhe mbështesin të gjitha këto. Meqenëse klienti merr liri të plotë veprimi në grup, ai mban përgjegjësi për performancën e grupit. Dhe është shumë e lehtë të thyesh gjithçka këtu.
- E dyta është mungesa e integrimeve. Nëse përdorni Kubernetes pa një platformë të njohur virtualizimi, nuk do të merrni të gjitha përfitimet e programit. Të tilla si përdorimi i shërbimeve të Vëllimeve të Përhershme dhe Balancuesit të Ngarkesës.
Figura 2. Arkitektura k8s
Kubernetes nga shitësi
Integrimi me një ofrues cloud ofron dy opsione:
- Së pari, një person thjesht mund të klikojë në butonin "krijo grup" dhe të marrë një grup tashmë të konfiguruar dhe gati për përdorim.
- Së dyti, vetë shitësi instalon grupin dhe vendos integrimin me cloud.
Si ndodh këtu. Inxhinieri që nis grupin specifikon sa punëtorë i duhen dhe me çfarë parametrash (për shembull, 5 punëtorë, secili me 10 CPU, 16 GB RAM dhe, të themi, 100 GB disk). Pas së cilës ai fiton qasje në grupimin tashmë të formuar. Në këtë rast, punëtorët mbi të cilët lëshohet ngarkesa transferohen plotësisht te klienti, por i gjithë plani i menaxhimit mbetet nën përgjegjësinë e shitësit (nëse shërbimi ofrohet sipas modelit të shërbimit të menaxhuar).
Sidoqoftë, kjo skemë ka të metat e saj. Për shkak të faktit se rrafshi i menaxhimit mbetet me shitësin, shitësi nuk i jep akses të plotë klientit dhe kjo zvogëlon fleksibilitetin në punën me Kubernetes. Ndonjëherë ndodh që një klient dëshiron të shtojë disa funksione specifike në Kubernetes, për shembull, vërtetimin përmes LDAP, por konfigurimi i planit të menaxhimit nuk e lejon këtë.
Figura 3. Shembull i një grupi Kubernetes nga një ofrues cloud
Çfarë të zgjidhni: me burim të hapur ose shitës
Pra, a është Kubernetes me burim të hapur apo shitës specifik? Nëse marrim Kubernetes me kod të hapur, atëherë përdoruesi bën atë që dëshiron me të. Por ka një shans të madh për të qëlluar veten në këmbë. Me shitësin është më e vështirë, sepse gjithçka është menduar dhe konfiguruar për kompaninë. Disavantazhi më i madh i Kubernetes me burim të hapur është kërkesa për specialistë. Me opsionin e shitësit, kompania çlirohet nga kjo dhimbje koke, por do të duhet të vendosë nëse do të paguajë specialistët e saj apo shitësin.
Epo, të mirat janë të dukshme, të këqijat gjithashtu dihen. Një gjë është konstante: Kubernetes zgjidh shumë probleme duke automatizuar menaxhimin e shumë kontejnerëve. Dhe cilin të zgjidhni, me burim të hapur apo shitës - secili merr vendimin e tij.
Artikulli u përgatit nga Dmitry Krasnov, arkitekti kryesor i shërbimit Containerum të ofruesit #CloudMTS
Burimi: www.habr.com