🥇Kubernetes: open source kundër vendorëve

Tungjatjeta, emri im është Dmitri Krasnov. Prej më shumë se pesë vjetësh jam duke u angazhuar në administrimin e klastereve Kubernetes dhe ndërtimin e arkitekturave të komplikuara të mikrosërvicesh. Në fillim të këtij viti, lançuam një shërbim për menaxhimin e klastereve Kubernetes mbi Containerum. Duke përfituar nga rasti, do të flas për atë çfarë është ky Kubernetes dhe si ndan integrimi me furnizuesin nga open source.

Për fillim, çfarë është Kubernetes. Është një sistem për menaxhimin e kontejnerëve në një numër të madh hostesh. Nga greqishtja, përndryshe, përkthehet si "piloti" ose "kapitani". Fillimisht e zhvilluar nga Google, më pas si një kontribut teknologjik iu kalua Fondacionit të Komunikimit Cloud Native, një organizatë ndërkombëtare jo-fitimprurëse që bashkon zhvilluesit kryesorë globalë, përdoruesit e fundit dhe ofruesit e teknologjive të kontejnerëve.

Të drejtojë një numër të madh kontejnerësh

Tani do ta kuptojmë se çfarë janë këto kontejnerë. Kjo është një aplikacion me të gjithë mjedisin e tij – në thelb, bibliotekat nga të cilat varet funksionimi i programit. Të gjitha këto janë të paketuar në arkiva dhe paraqiten si një imazh, i cili mund të ekzekutohet pavarësisht nga sistemi operativ, të testohen dhe jo vetëm. Por ka një problem — menaxhimi i kontejnerëve në një numër të madh hostesh është shumë i vështirë. Prandaj u krijua Kubernetes.

Imazhi i kontejnerit përbën aplikacionin plus varësitë e tij. Aplikacioni, varësitë e tij dhe imazhi i sistemit të files së OS gjenden në pjesë të ndryshme të imazhit, të ashtuquajturat shtresa. Shtresat mund të përdoren përsëritshëm për kontejnerë të ndryshëm. Për shembull, një shtresë bazë e Ubuntu mund të përdoret për të gjitha aplikacionet në kompani. Kur kontejnerët janë në punë, nuk ka nevojë të ruani shumë kopje të një shtrese baze në host. Kjo ndihmon për të optimizuar ruajtjen dhe shpërndarjen e imazheve.

Kur ne dëshirojmë të nisëm një aplikacion nga një kontejner, shtresat e nevojshme janë të vendosura një mbi tjetër dhe formohet një sistem skedari i mbuluar. Një shtresë e shkruar vendoset mbi të, e cila, kur ndalet kontejneri, fshihet. Kjo garanton që gjatë nisjes së kontejnerit aplikacioni gjithmonë ka të njëjtin mjedis, i cili nuk mund të ndryshohet. Kjo siguron rikthyeshmërinë e mjedisit në sisteme të ndryshme operative nikoqire. Qoftë Ubuntu apo CentOS, mjedisi gjithmonë do të jetë i njëjtë. Për më tepër, kontejneri është i izoluara nga nikoqiri me mekanizmat e ndërtuar në bërthamën e Linux-it. Aplikacionet në kontejner nuk shohin skedarët, proceset e nikoqirit apo kontejnerët fqinjë. Kjo izolim e aplikacioneve nga sistemi operativ nikoqir ofron një shtresë të shtuar sigurie.

Për menaxhimin e kontejnerëve në nikoqirin ka shumë mjete. Mjeti më i njohur është Docker. Ai lejon të sigurohet një cikël jetësor të plotë të punës për kontejnerët. Megjithatë, ai funksionon vetëm në një nikoqir. Kur nevojitet menaxhimi i kontejnerëve në shumë nikoqirë, Docker mund të kthejë jetën e inxhinierëve në një makth. Kështu, Kubernetes u krijua.

Kubernetes është i kërkuar për shkak të aftësisë për të menaxhuar grupe konteinerësh në shumë hoste si entitete të vetme. Popullariteti i sistemit e mundëson ndërtimin e DevOps ose Operacioneve të Zhvillimit, ku Kubernetes përdoret për të nisur proceset e këtij DevOps.

Figura 1. Pamje skematike e parimit të punës së Kubernetes

Automatizim i plotë

DevOps, në thelb, përfaqëson automatizimin e procesit të zhvillimit. Në mënyrë të thjeshtë, zhvilluesit shkruajnë kod që ngarkohet në një repository. Më pas, ky kod mund të ndahet automatikisht menjëherë në një kontenier me të gjitha bibliotekat, të testohet dhe të "publikohet" në fazën tjetër – Staging, dhe pastaj menjëherë në Production.

Së bashku me Kubernetes, DevOps lejon automatizimin e këtij procesi, në mënyrë që ai të zhvillohet praktikisht pa përfshirjen e zhvilluesve të vetë. Kështu, ndjeshëm shpejtohet ndërtimi, pasi zhvilluesi nuk ka nevojë të merret me këtë në kompjuterin e tij — ai thjesht shkruan një copë kod, e shtyn kodin në repository, 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 ndodh në mënyrë të vazhdueshme.

Në të njëjtën kohë, përdorimi i kontejnerëve siguron që e gjithë mjedisi i kësaj programi do të dalë në production pikërisht në atë formë në të cilën është testuar. Kjo do të thotë se nuk do të ketë probleme si «në test ishin versione të ndryshme, në production — të tjera, dhe si rezultat, gjithçka u rënk». Dhe duke pasur parasysh se sot kemi një trend drejt arkitekturës mikroshërbimore, kur në vend të një aplikacioni të madh ka qindra të vogla, do të kërkohet një numër i madh punonjësish për t'i administruar ato manualisht. Prandaj ne përdorim Kubernetes.

Pikat pozitive, pikat pozitive, pikat pozitive

Duke folen për avantazhet e Kubernetes si platformë, ajo ka disa përfitime të rëndësishme në menaxhimin e arkitekturës së mikroshërbimeve.

Menaxhimi i shumë kopjeve. E rëndësishmja është menaxhimi i kontejnerëve në shumë hoste. Dhe më e rëndësishmja, është menaxhimi i shumë kopjeve të aplikacioneve në kontejnerë si një entitet i vetëm. Kështu, inxhinierët nuk kanë nevojë të shqetësohen për çdo kontejner të veçantë. Nëse një nga kontejnerët dështon, Kubernetes do ta zbulojë këtë dhe do ta rinisë atë.
Rrjeti klaster. Gjithashtu, Kubernetes ka atë që quhet rrjeti klaster me hapësirë adresash të vetën. Falë kësaj, çdo pod ka adresën e vet. Një pod është njësia minimale strukturore e klasterit, ku kontejnerët ekzekutohen drejtpërdrejt. Për më tepër, Kubernetes disponon funksionalitet që kombinon balancuesin e ngarkesës dhe Shkaktimin e Shërbimeve. Kjo lejon që të hiqet menaxhimi manual i adresave IP dhe ta ngarkojë këtë detyrë tek Kubernetes. Kontrolli automatik i shëndetit do të ndihmojë në zb discoveryn e problemeve dhe në ridrejtimin e trafikur në pod-et aktive.
Menaxhimi i konfigurimeve. Kur menaxhohet një numër i madh aplikacionesh, bëhet e vështirë të menaxhosh konfigurimin e aplikacioneve. Për këtë, Kubernetes ka burime të veçanta të quajtur ConfigMap. Ato lejojnë ruajtjen qendrore të konfigurimeve dhe zëvendësimin e tyre në pod në momentin e nisjes së aplikacioneve. Ky mekanizëm garanton konsistencën e konfigurimeve në dhjetë apo në qindra replika aplikacionesh.
Vëllimet e përhershme. Kontejnerët janë në thelb të pandryshyeshëm dhe kur ndalen, të gjitha të dhënat e regjistruara në sistemin e skedarëve do të shuhen. Por disa aplikacione ruajnë të dhënat direkt në disk. Për të zgjidhur këtë problem, Kubernetes ka një funksionalitet për menaxhimin e ruajtjes së diskut — Vëllimet e përhershme. Ky mekanizëm përdor ruajtje të jashtme për të dhënat dhe mund të angazhojë ruajtje të përhershme, bllok ose në format skedari, në konteinerët. Ky zgjidhje lejon ruajtjen e të dhënave veçmas nga punonjësit, duke i mbrojtur ato në rast të prishjes së punonjësve.
Balancuesi i ngarkesës. Megjithëse në Kubernetes ne menaxhojmë entitete abstrakte si Deployment, StatefulSet etj., në fund të fundit, konteinerët nisi në makina të zakonshme. makinat virtuale ose oseve. Ato nuk janë të përsosura dhe mund të bien në çdo moment. Kubernetes do ta shohë këtë dhe do të redirektojë trafikun e brendshëm në replikat e tjera. Por çfarë të bëjmë me trafikun që vjen nga jashtë? Nëse e drejtojmë thjesht trafikun në një nga punëtorët, çfarë ndodh në rast se ai dështon, shërbimi do të bëhet i pa aksesueshëm. Për të zgjidhur këtë problem, Kubernetes ka shërbime të tipit Load Balancer. Ato janë të destinuara për të konfigurimin automatik të një balancuesi të jashtëm të cloud-it për të gjithë punëtorët në klaster. Ky balancues i jashtëm drejton trafikun e jashtëm në punëtorët dhe vetë ndiqet statusin e tyre. Nëse një ose disa punëtorë bëhen të paarritshëm, trafiku redirektohet në të tjerët. Kjo lejon krijimin e shërbimeve me disponueshmëri të lartë me ndihmën e Kubernetes.

Kubernetes tregon më së miri veten pikërisht kur nisin arkitektura të mikroshërbimeve. Të integrosh sistemin në një arkitekturë klasike është e mundur, por e paarsyeshme. Nëse aplikacioni nuk mund të funksionojë në disa replika, çfarë ka kuptim, a është në Kubernetes apo jo?

Kubernetes open source

Kubernetes me burim të hapur – një gjë e shkëlqyer: e vendos dhe funksionon. Mund të vendoset në serverat e tu, në infrastrukturën tënde, të vendosësh një master dhe punëtorë, ku do të ekzekutohen të gjitha aplikacionet. Dhe gjëja më e rëndësishme është – e gjithë kjo është falas. Megjithatë, ka disa nuanca.

E para – kërkesa për njohuri dhe përvojë të administratorëve dhe inxhinierëve që do ta vendosin dhe mbështesin gjithçka. Duke qenë se klienti merr lirinë e plotë të veprimit në klaster, ai merr përsipër përgjegjësinë për funksionimin e tij. Dhe këtu është shumë e lehtë të thyhet gjithçka.
E dyta – mungesa e integrimeve. Nëse aktivizoni Kubernetes pa pasur ndonjë platformë virtualizimi të njohur, nuk do të merrni të gjithë përfitimet e programit. Siç janë përdorimi i Volume-ve të Përhershëm dhe shërbimeve Load balancer.

Figurë 2. Arkitektura e k8s

Kubernetes nga furnizuesi

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ë gatshëm dhe të konfiguruar për punë.
Së dyti, furnizuesi krijon vetë klasterin dhe konfiguron integrimin me cloud-in.

Si si ndodh kjo me ne. Inxhinieri që aktivizon klasterin përcakton se sa punonjës i nevojiten dhe me cilat parametra (p.sh., 5 punonjës, secili me 10 CPU, 16 GB RAM dhe, le të themi, 100 GB disk). Më pas, ai merr qasje në klasterin që është formuar tashmë. Në këtë rast, punonjësit që aktivizohen për ngarkesën i jepen plotësisht klientit, por të gjithë menaxhimi mbetet në përgjegjësi të ofruesit (në rastin kur shërbimi ofrohet sipas modelit të shërbimit të menaxhuar).

Megjithatë, kjo skemë ka disa disavantazhe. Pavarësisht se menaxhimi mbetet te ofruesi, ky i fundit nuk i jep qasje të plotë klientit, dhe kjo ul fleksibilitetin në punën me Kubernetes. Ndonjëherë ndodh që klienti dëshiron të lidhë një funksionalitet të specifikuar me Kubernetes, si p.sh., autentikimin përmes LDAP, por konfigurimi i menaxhimit nuk e lejon këtë.

Figura 3. Shembulli i klasterit Kubernetes nga ofruesi i облачной.

Çfarë të zgjedhim: open source apo vendor?

Pra të hapur Kubernetes apo të ofruesit? Nëse zgjidhni Kubernetes me burim të hapur, përdoruesi mund të bëjë çfarëdo që dëshiron. Por ka një rrezik të lartë të gabimeve vetjake. Me ofruesin është më e vështirë, sepse gjithçka është menduar dhe konfigurimi është bërë nga kompania. Mangësia më e madhe e Kubernetes me burim të hapur është kërkesa për specialistë. Me ofruesin, kompania e shmang këtë dhimbje koke, por duhet të vendosë: të paguajë specialistët e saj apo ofruesin.

Pra, avantazhet janë të qarta, po ashtu edhe disavantazhet. Një gjë është e sigurt: Kubernetes zgjidh shumë probleme duke automatizuar menaxhimin e shumë konteinerëve. Cilin të zgjidhni, Kubernetes me burim të hapur apo të ofruesit, është një vendim që secili e merr vetë.