Përshëndetje, unë quhem Dmitry Krasnov. Tani e më shumë se pesë vjet merrem me administrimin e klastereve Kubernetes dhe ndërtimin e arkitekturave të komplikuara mikroshërbimesh. Në fillim të këtij viti lançuam një shërbim për menaxhimin e klastereve Kubernetes mbi Containerum. Duke e shfrytëzuar rastin, do të tregoj se çfarë është ky Kubernetes dhe si ndryshon integrimi me një ofrues në krahasim me open source.
Për të filluar, çfarë është . Kjo është një sistem për menaxhimin e konteinerëve në një numër të madh hostesh. Nga greqishtja, përndryshe, përkthehet si "pilot" ose "përgjegjës". Fillimisht është zhvilluar nga Google, dhe më pas është dhënë si një kontribut teknologjik në Cloud Native Computing Foundation, një organizatë ndërkombëtare jo fitimprurëse që bashkon zhvilluesit kryesorë të botës, përdoruesit përfundimtarë dhe ofruesit e teknologjive të konteinerëve.
Për të menaxhuar një numër të madh konteinerësh
Tani tĂ« marrim vesh se çfarĂ« janĂ« kĂ«ta konteinerĂ«. KĂ«ta janĂ« aplikacione me tĂ« gjithĂ« mjedisin e tyre â kryesisht, bibliotekat nga tĂ« cilat varet funksionimi i programit. TĂ« gjitha kĂ«to janĂ« paketuar nĂ« arkiva dhe paraqiten si imazhe, qĂ« mund tĂ« ekzekutohen pavarĂ«sisht nga sistemi operativ, tĂ« testohen dhe jo vetĂ«m. Por ka njĂ« problem â tĂ« menaxhosh konteinerĂ«t nĂ« njĂ« numĂ«r tĂ« madh hostesh Ă«shtĂ« shumĂ« e komplikuar. Prandaj, Kubernetes u krijua.
Imazhi i konteinerit përbën aplikacionin plus varësitë e tij. Aplikacioni, varësitë e tij dhe imazhi i sistemit të skedarëve të OS janë të vendosura në pjesë të ndryshme të imazhit, të ashtuquajturat shtresa. Shtresat mund të riciklohen për konteinerë të ndryshëm. Për shembull, një shtresë bazë Ubuntu mund të përdoret për të gjitha aplikacionet në kompani. Gjatë ekzekutimit të konteinerëve nuk ka nevojë për të ruajtur në host shumë kopje të një shtrese bazë. Kjo lejon optimizimin e ruajtjes dhe shpërndarjes së imazheve.
Kur ne duam të shkarkojmë një aplikacion nga një kontejner, shtresat e nevojshme vendosen njëra mbi tjetrën dhe formojnë një sistem të skedarëve të mbivendosur. Një shtresë për shkrim vendoset mbi të, e cila, kur kontejneri ndalet, fshihet. Kjo garanton që kur kontejneri hapet, aplikacioni gjithmonë ka një mjedis të njëjtë, i cili nuk mund të ndryshohet. Kjo siguron riprodhueshmërinë e mjedisit në sisteme të ndryshme operative të hostit. Pa marrë parasysh nëse është Ubuntu apo CentOS, mjedisi gjithmonë do të jetë i njëjtë. Për më tepër, kontejneri është i izoluar nga hosti përmes mekanizmave të inkorporuar në kernelin Linux. Aplikacionet në kontejner nuk shohin skedarët, proceset e hostit dhe kontejnerët e tjerë. Kjo izolim i aplikacioneve nga sistemi operativ i hostit ofron një shtesë të sigurisë.
Për menaxhimin e konteinerëve në host, ka shumë mjete. Mjeti më i njohur është Docker. Ai ofron një cikël të plotë jetësor për konteinerët. Megjithatë, ai funksionon vetëm në një host. Kur është e nevojshme të menaxhohen konteinerët në shumë hoste, Docker mund ta kthejë jetën e inxhinierëve në një ferr. Prandaj, Kubernetes u krijua.
Kërkesa për Kubernetes është pikërisht për shkak të mundësisë për të menaxhuar grupe kontejnerësh në shumë hoste si entitete të vetme. Popullariteti i sistemit siguron mundësinë e ndërtimit të DevOps ose Operacioneve të Zhvillimit, ku Kubernetes përdoret për të nisur proceset e këtij DevOps.
Figura 1. Një diagramë e thjeshtë e funksionimit të Kubernetes
Automatizimi i plotë
DevOps, nĂ« parim, Ă«shtĂ« automatizimi i procesit tĂ« zhvillimit. Thjesht, zhvilluesit shkruajnĂ« kodin, i cili ngarkohet nĂ« njĂ« depo. MĂ« pas, ky kod mund tĂ« ndĂ«rtohet automatikisht menjĂ«herĂ« nĂ« njĂ« kontejner me tĂ« gjitha bibliotekat, tĂ« testohet dhe "tĂ« pĂ«rfundojĂ«" nĂ« fazĂ«n tjetĂ«r â Staging, dhe mĂ« pas menjĂ«herĂ« nĂ« Production.
SĂ« bashku me Kubernetes, DevOps lejon automatizimin e kĂ«tij procesi, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« zhvillohet praktikisht pa pjesĂ«marrjen e vetĂ« zhvilluesve. Si rezultat, ndodhin pĂ«rshpejtimet e ndjeshme nĂ« ndĂ«rtim, pĂ«r shkak se zhvilluesit nuk e kanĂ« kĂ«tĂ« detyrĂ« nĂ« kompjuterin e tyre â ata thjesht shkruajnĂ« njĂ« pjesĂ« tĂ« kodit, e shtyjnĂ« kodin nĂ« depo, pas sĂ« cilĂ«s fillon pipeline-i, i cili mund tĂ« pĂ«rfshijĂ« procesin e ndĂ«rtimit, testimit dhe implementimit. KĂ«shtu ndodh me çdo komit, prandaj testimi Ă«shtĂ« i vazhdueshĂ«m.
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, pĂ«rdorimi i kontejnerĂ«ve siguron qĂ« e gjithĂ« ambienti i kĂ«saj programi tĂ« dalĂ« nĂ« prodhim nĂ« tĂ« njĂ«jtĂ«n formĂ« siç Ă«shtĂ« testuar. Pra, nuk do tĂ« ndodhin probleme si «nĂ« test ishin versionet njĂ«, nĂ« prodhim â tĂ« tjera, dhe kur u vendos â gjithçka ra». Dhe pasi sot kemi njĂ« tendencĂ« drejt arkitekturĂ«s mikroshĂ«rbimeve, kur nĂ« vend tĂ« njĂ« aplikacioni tĂ« madh ka qindra tĂ« vogla, atĂ«herĂ« pĂ«r ta administruar ato manualisht, do tĂ« kĂ«rkohet njĂ« staf i madh punonjĂ«sish. Prandaj ne pĂ«rdorim Kubernetes.
Përfitimet, përfitimet, përfitimet
Nëse flasim për avantazhet e Kubernetes si platformë, ajo ka përfitime të konsiderueshme në aspektin e menaxhimit të arkitekturës mikroshërbimeve.
- Menaxhimi i shumĂ« replikave. E rĂ«ndĂ«sishmja â Ă«shtĂ« menaxhimi i kontejnerĂ«ve nĂ« shumĂ« hoste. Dhe çfarĂ« Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja, â menaxhimi i shumĂ« replikave tĂ« aplikacioneve nĂ« kontejnerĂ« si njĂ« njĂ«si tĂ« vetme. FalĂ« kĂ«tij fakti, inxhinierĂ«t nuk duhet tĂ« kujdesen pĂ«r çdo kontejner individual. NĂ«se njĂ« nga kontejnerĂ«t dĂ«shton, atĂ«herĂ« Kubernetes e sheh kĂ«tĂ« dhe e rinis atĂ« pĂ«rsĂ«ri.
- Rrjeti klasterik. Gjithashtu, Kubernetes ka një rrjet klasterik të quajtur me hapësirën e vet adresore. Falë këtij fakti, çdo pod ka adresën e vet. Pod-i nënkupton njësinë minimale strukturale të klasterit, në të cilën drejtohen përveç kontejnerëve. Për më tepër, Kubernetes ka funksionalitet që kombinon në vetvete balancuesin e ngarkesës dhe Zbulimin e Shërbimit. Kjo lejon eliminimin e menaxhimit manual të IP-adresave dhe delegimin e kësaj detyre te Kubernetes. Dhe kontrolli automatik mbi shëndetin do të ndihmojë në zbulimin e problemeve dhe në ridrejtimin e trafikut në podet funksionale.
- Menaxhimi i konfigurimeve. Kur menaxhimi i një sërë të madhe aplikacionesh bëhet e vështirë të menaxhosh konfigurimin e aplikacioneve. Për këtë, Kubernetes ka burime speciale ConfigMap. Ato lejojnë ruajtjen në mënyrë qendrore të konfigurimeve dhe t'i vendosin ato në pods gjatë nisjes së aplikacioneve. Ky mekanizëm garanton konsistencën e konfigurimit, pavarësisht nëse ka dhjetë ose njëqind replika aplikacionesh.
- VĂ«llime tĂ« PĂ«rshtatshme. KontejnerĂ«t nĂ« thelb janĂ« imutabĂ«l dhe nĂ« momentin e ndalimit tĂ« njĂ« konteineri, tĂ« dhĂ«nat e shkruara nĂ« sistemin e skedarĂ«ve do tĂ« shkatĂ«rrohen. Por disa aplikacione ruajnĂ« tĂ« dhĂ«na direkt nĂ« disk. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, Kubernetes ka funksionalitet pĂ«r menaxhimin e ruajtjes sĂ« disqeve â VĂ«llime tĂ« PĂ«rshtatshme. Ky mekanizĂ«m pĂ«rdor njĂ« ruajtje tĂ« jashtme pĂ«r tĂ« dhĂ«nat, mund tĂ« ofrojĂ« ruajtje tĂ« pĂ«rhershme, tĂ« bllokuar ose tĂ« skedarit nĂ« konteinerĂ«t. Ky zgjidhje lejon ruajtjen e tĂ« dhĂ«nave ndaras nga punĂ«torĂ«t, duke i shpĂ«tuar ata nĂ« rastin e dĂ«shtimit tĂ« kĂ«tyre punĂ«torĂ«ve.
- Balancues Ngarkese. Pavarësisht se në Kubernetes ne menaxhojmë entitete abstrakte si Deployment, StatefulSet etj., në fund të fundit konteinerët fillojnë në servera të zakonshëm makina virtuale apo harduerë. Ato nuk janë perfekte dhe mund të bien në çdo moment. Kubernetes do ta vërejë këtë dhe do të drejtojë trafikun e brendshëm në replika të tjera. Por çfarë të bëjmë me trafikun që vjen nga jashtë? Nëse thjesht drejtojmë trafikun në një nga punëtorët, çfarë ndodh në rastin e dështimit të tij, shërbimi do të bëhet i paqëndrueshëm. Për të zgjidhur këtë problem, Kubernetes ka shërbime si Balancues Ngarkese. Ato janë të destinuara për konfigurimin automatik të një balancuesi të jashtëm të trafikut në të gjithë punëtorët në grumbull. Ky balancues i jashtëm drejton trafikun e jashtëm në punëtorë dhe vetë monitoron statusin e tyre. Nëse një ose më shumë punëtorë bëhen të paarritshëm, atëherë trafiku drejtohet në të tjerët. Kjo lejon krijimin e shërbimeve me disponueshmëri të lartë përmes Kubernetes.
Kubernetes tregon më së miri potencialin e tij kur fillon arkitekturat mikroshërbimore. Të implementosh sistemin në një arkitekturë klasike është e mundur, por pa kuptim. Nëse një aplikacion nuk mund të funksionojë në disa replika, çfarë rëndësie ka, nëse është në Kubernetes apo jo?
Kubernetes me burim të hapur
Kubernetes me burim tĂ« hapur â gjĂ« e shkĂ«lqyer: e vendos dhe funksionon. Mund tĂ« instalohet nĂ« serverat e tu, nĂ« infrastrukturĂ«n tuaj, tĂ« vendosni master dhe workere, mbi tĂ« cilat do tĂ« ekzekutohen tĂ« gjitha aplikacionet. Dhe mĂ« e rĂ«ndĂ«sishmja â e gjithĂ« kjo Ă«shtĂ« falas. MegjithatĂ«, ka nuanca.
- E para â kĂ«rkesat pĂ«r njohuritĂ« dhe pĂ«rvojĂ«n e administratorĂ«ve dhe inxhinierĂ«ve qĂ« do tĂ« instalojnĂ« dhe mbĂ«shtesin gjithçka. Duke qenĂ« se klienti merr lirinĂ« e plotĂ« tĂ« veprimit nĂ« klaster, ai mban pĂ«rgjegjĂ«sinĂ« pĂ«r funksionimin e klasterit vetĂ«. Dhe Ă«shtĂ« shumĂ« e lehtĂ« tĂ« dĂ«shtosh kĂ«tu.
- E dyta â mungesa e integrimeve. NĂ«se e filloni Kubernetes pa pasur ndonjĂ« platformĂ« virtualizimi tĂ« njohur, atĂ«herĂ« nuk do tĂ« merrni tĂ« gjithĂ« pĂ«rfitimet e programit. Siç janĂ« pĂ«rdorimi i Volume-ve tĂ« qĂ«ndrueshme dhe shĂ«rbimeve Load balancer.
Figura 2. Arkitektura k8s
Kubernetes nga nje ofrues
Integrimi me ofruesin e cloud-it ofron dy mundësi:
- Së pari, një person mund thjesht të klikojë butonin «krijo klaster» dhe të marrë një klaster të konfiguruar dhe gati për punë.
- SĂ« dyti, ofruesi e vendos vet klasterin dhe konfigurimin e integrimit me cloud-in.
Si ndodh kjo me ne. Inxhinieri që nis klasterin tregon se sa workera i duhen dhe me cilat parametra (p.sh., 5 workera, çdo një me 10 CPU, 16 GB RAM dhe, le të themi, 100 GB disk). Pas kësaj, ai merr qasje në klasterin e formuar tashmë. Në këtë mënyrë, worker-at mbi të cilët ngarkohet puna, i dorëzohen plotësisht klientit, por e gjithë plani i menaxhimit mbetet përgjegjësi e ofruesit (në rast se shërbimi ofrohet sipas modelit të shërbimeve të menaxhuara).
Megjithatë, kjo skemë ka mangësi. Për shkak se plani i menaxhimit mbetet te ofruesi, ai nuk i jep klientit qasje të plotë, dhe kjo redukton fleksibilitetin në punën me Kubernetes. Nsometimes ndodh që klienti dëshiron të shtojë një funksionalitet specifik te Kubernetes, për shembull, autentifikim përmes LDAP, por konfigurimi i planit të menaxhimit nuk e lejon këtë.
Figura 3. Shembulli i klasterit Kubernetes nga ofruesi i cloud-it
ĂfarĂ« tĂ« zgjidhni: burim tĂ« hapur apo nga ofruesi
Pra, Kubernetes me burim të hapur apo nga një furnizues? Po të marrim Kubernetes me burim të hapur, përdoruesi mund të bëjë çfarëdo që dëshiron me të. Por ka një shans të madh të qëllojë vetë në këmbë. Me furnizuesin, kjo është më e komplikuar, sepse për kompaninë gjithçka është menduar dhe e konfiguruar. Mangësia më e madhe e Kubernetes me burim të hapur është kërkesa për specialistë. Me furnizuesin, kompanitë janë të shpëtuara nga kjo dhimbje koke, por do t'u duhet të vendosin: të paguajnë specialistët e tyre ose furnizuesin.
Mirë, përfitimet janë të dukshme, të disavantazhet gjithashtu janë të njohura. Një gjë është e pashqyrtueshme: Kubernetes zgjidh shumë probleme, duke automatizuar menaxhimin e shumë konteinerëve. Dhe cila të zgjidhet, me burim të hapur apo nga një furnizues, - secili e merr vendimin vet.
Artikullin e përgatiti Dmitri Krasnov, arkitekt kryesor i shërbimit Containerum të ofruesit #CloudMTS
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish