🥇Kubernetes: open source kundër një ofruesi

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ë Kubernetes. 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.