🥇Kubernetes: open source pret vendoru

Sveiki, mani sauc Dmitrijs Krasnovs. Jau vairāk nekā piecus gadus es nodarbojos ar Kubernetes klasteru administrēšanu un sarežģītu mikroservisu arhitektūru veidošanu. Šā gada sākumā mēs uzsākām Kubernetes klasteru pārvaldības pakalpojumu, balstoties uz Containerum. Izmantojot šo iespēju, pastāstīšu, kas īsti ir šis Kubernetes un kā integrācija ar pārdevēju atšķiras no open source.

Vispirms, kas ir Kubernetes. Tas ir sistēma, kas pārvalda konteinerus lielā daudzumā hostos. No grieķu valodas tas patiesībā tiek tulkots kā "pilots" vai "stūrmanis". Sākotnēji to izstrādāja Google, pēc tam tas tika nodots Cloud Native Computing Foundation, starptautiskai bezpeļņas organizācijai, kas apvieno vadošos pasaules izstrādātājus, galapatērētājus un konteineru tehnoloģiju piegādātājus.

Vadīt lielu skaitu konteineru

Tagad izdomāsim, kas tieši ir šie konteineri. Tie ir lietojumi ar visu to apkārtni – galvenokārt, bibliotēkām, no kurām atkarīga programmas darbība. Viss tas ir iesaiņots arhīvos un prezentēts kā attēls, ko var palaist neatkarīgi no operētājsistēmas, testēt un ne tikai. Bet ir problēma — pārvaldīt konteinerus lielā daudzumā hostos ir ļoti grūti. Tāpēc tika izveidots Kubernetes.

Konteinera attēls sastāv no lietojuma plus tā atkarībām. Lietojums, tā atkarības un operētājsistēmas failu sistēmas attēls atrodas dažādās attēla daļās, tā sauktajos slāņos. Slāņus var izmantot atkārtoti dažādiem konteineriem. Piemēram, visām uzņēmuma lietojumprogrammām var tikt izmantots pamata slānis Ubuntu. Konteineru palaišanā nav vajadzības uz hosta glabāt daudzus viena pamata slāņa eksemplārus. Tas ļauj optimizēt glabāšanu un attēlu piegādi.

Kad mēs vēlamies palaist lietojumprogrammu no konteinera, nepieciešamie slāņi sakrīt viens virs otra un izveidojas pārklājoša failu sistēma. Virsū tiek uzklāts rakstīšanas slānis, kas, apstādinot konteineru, tiek izdzēsts. Tas garantē, ka, palaidienu konteineru, lietojumprogrammai vienmēr būs vienāda vide, ko nevar mainīt. Tas nodrošina reproducējamību vidē dažādās viesdatoru operētājsistēmās. Neatkarīgi no tā, vai tā ir Ubuntu vai CentOS, – vide vienmēr būs vienāda. Turklāt konteiners ir izolēts no viesdatora, izmantojot Linux kodolā iebūvētos mehānismus. Lietojumprogrammas konteinerā neredz viesdatora failus, procesus un blakus konteinerus. Šāda izolācija no viesdatora operētājsistēmas nodrošina papildu drošības līmeni.

Lai pārvaldītu konteinerus uz viesdatora, ir ļoti daudz rīku. Vispopulārākais no tiem ir Docker. Tas nodrošina pilnu konteineru darbības ciklu. Tomēr tas darbojas tikai uz viena viesdatora. Ja nepieciešams pārvaldīt konteinerus uz vairākiem viesdatoriem, Docker var pārvērst inženieru dzīvi par elles. Tāpēc tika izveidots Kubernetes.

Kubernetes pieprasījums ir tieši saistīts ar spējām vadīt grupas konteineru uz vairākiem viesdatoriem kā vienotas entitātes. Sistēmas popularitāti nodrošina iespēja veidot DevOps jeb izstrādes operācijas, kur Kubernetes tiek izmantots, lai palaistu šos procesus.

Attēls 1. Schematic representation of how Kubernetes works

Pilnīga automatizācija

DevOps, principā, ir kūku automatizācija. Vienkārši sakot, izstrādātāji raksta kodu, kas tiek augšupielādēts krātuves vietā. Pēc tam šo kodu var automātiski savākt tieši konteinerā ar visām bibliotēkām, nodot testēšanai un "izlaist" nākamajā posmā - Staging, un pēc tam uzreiz uz Production.

Kubernetes kopā ar DevOps ļauj automatizēt šo procesu, padarot to praktiski neatkarīgu no pašu izstrādātāju līdzdalības. Tas ievērojami paātrina būvniecību, jo izstrādātājam nav jānodarbojas ar to savā datorā — viņš vienkārši raksta koda fragmentu, nospiež to repozitorijā, pēc tam palaižas pipeline, kas var ietvert būvniecības, testēšanas un izvietošanas procesu. Un tas notiek ar katru kommitu, tāpēc тестēšana notiek nepārtraukti.

Tajā pašā laikā konteineru izmantošana nodrošina, ka visa šīs programmas vide tiks izlaista production tieši tādā veidā, kādā tā tika testēta. Proti, neradīsies problēmas no sērijas "testēšanā bija citas versijas, production — citas, bet, kad tika uzstādīts, viss avarēja". Un, ņemot vērā, ka šodien ir tendence uz mikropakalpojumu arhitektūru, kad vienas milzīgas lietojumprogrammas vietā ir simtiem mazu, manuāli tos administrēt prasīs milzīgu darbinieku skaitu. Tāpēc mēs izmantojam Kubernetes.

Priekšrocības, priekšrocības, priekšrocības

Runājot par Kubernetes priekšrocībām kā platformu, tā ir ievērojamām priekšrocībām mikropakalpojumu arhitektūras pārvaldības ziņā.

Daudzreplicu pārvaldība. Visvairāk svarīgs ir konteineru pārvaldība vairākos hostos. Un kas ir vēl svarīgāk, — daudzu aplikāciju replikāciju pārvaldība konteineros kā vienai vienībai. Pateicoties tam, inženieriem nav jātur uzmanība uz katru atsevišķu konteineru. Ja viens no konteineriem avarēs, Kubernetes to pamanīs un atkārtoti palaidīs.
Klusteru tīkls. Tāpat Kubernetes ir tā sauktais klusteru tīkls ar savu adreses telpu. Pateicoties tam, katram podam ir sava adrese. Pod tiek uzskatīts par minimālo klusteru strukturālo vienību, kurā tieši tiek palaisti konteineri. Turklāt Kubernetes ir funkcionalitāte, kas apvieno slodzes balansētāju un pakalpojumu atklāšanu. Tas ļauj izvairīties no manuālas IP adresu pārvaldības un uzlikt šo uzdevumu Kubernetes pleciem. Automatiskie veselības pārbaudes palīdzēs atklāt problēmas un novirzīt trafiku uz aktīvajiem podiem.
Konfigurāciju pārvaldība. Pārvaldīt lielu skaitu lietojumprogrammu var būt grūti, jo īpaši kad runa ir par konfigurācijas pārvaldību. Tāpēc Kubernetes piedāvā īpašus resursus - ConfigMap, kas ļauj centralizēti glabāt konfigurācijas un iekļaut tās podos, palaižot lietojumprogrammas. Šāds mehānisms garantē konfigurāciju konsekvenci neatkarīgi no tā, vai ir desmit vai simts lietojumprogrammu replikāciju.
Pastāvīgie apjomi. Konteineri pēc savas būtības ir nemainīgi, un, apstājoties konteineram, visi dati, kas rakstīti failu sistēmā, tiks iznīcināti. Taču daži lietojumi glabā datus tieši diskā. Šīs problēmas risināšanai Kubernetes nodrošina funkcionalitāti diskhaļu pārvaldībai - pastāvīgos apjomus. Šis mehānisms izmanto ārējo krātuvi datiem, var nodrošināt pastāvīgu krātuvi, bloķētu vai failu, konteineriem. Šāds risinājums ļauj saglabāt datus atsevišķi no darbiniekiem, saglabājot tos to bojājuma gadījumā.
Slodzes līdzsvarotājs. Neskatoties uz to, ka Kubernetes mēs pārvaldām abstraktas entitātes, piemēram, Deployment, StatefulSet u.c., galu galā konteineri tiek palaisti uz parastiem virtuālās mašīnās vai metāla serveriem. Tie nav ideāli un var avarēt jebkurā brīdī. Kubernetes to pamanīs un novirzīs iekšējo trafiku uz citām replikām. Bet ko darīt ar trafiku, kas nāk no ārienes? Ja vienkārši novirzīs trafiku uz vienu no darbiniekiem, kas notiks, ja tas avarē? Pakalpojums kļūs nepieejams. Šīs problēmas risināšanai Kubernetes ir pakalpojumi kā Load Balancer. Tie ir paredzēti automātiskai ārējā mākoņa līdzsvarotāja iestatīšanai visiem darbiniekiem klasterī. Šis ārējais līdzsvarotājs novirza ārējo trafiku uz darbiniekiem un pats uzrauga to statusu. Ja viens vai vairāki darbinieki kļūst nepieejami, tad trafiks tiek novirzīts uz citiem. Tas ļauj izveidot augsti pieejamus pakalpojumus, izmantojot Kubernetes.

Vislabāk Kubernetes parādās, kad tiek palaistās mikroservisu arhitektūras. Sistēmas ieviešana klasiskajās arhitektūrās ir iespējama, taču bezjēdzīga. Ja lietojumprogramma nevar darboties vairākās replikās, tad kāda jēga ir atšķirībai - ar Kubernetes vai bez tā?

Atvērtā koda Kubernetes

Atvērtā koda Kubernetes – lieliska lieta: uzstādi un tas strādā. Var izvērst uz saviem serveriem, savā infrastruktūrā, uzstādīt meistaru un darbiniekus, uz kuriem tiks palaistas visas lietojumprogrammas. Un galvenais – viss tas ir bez maksas. Tomēr ir dažas nianses.

Pirmais – prasības pret administratoru un inženieru zināšanām un pieredzi, kuri visu to uzstādīs un uzturēs. Tā kā klients iegūst pilnīgas rīcības brīvību klasterī, atbildība par klastera darbspēju gulstas uz viņa paša pleciem. Un šeit ir ļoti viegli visu salauzt.
Otrais – integrāciju trūkums. Ja palaidīs Kubernetes, neiegūstot kādu populāru virtualizācijas platformu, tad nesaņemsiet visus programmas priekšrocības. Piemēram, izmantojot Persistent Volumes un Load balancer pakalpojumus.

Attēls 2. K8s arhitektūra

Kubernetes no piegādātāja

Integrācija ar mākoņu pakalpojumu sniedzēju nodrošina divas iespējas:

Pirmkārt, lietotājs var vienkārši nospiest pogu «izveidot klasteri» un saņemt jau konfigurētu un gatavu darbam klasteri.
Otrkārt, piegādātājs pats uzstāda klasteri un konfigurē integrāciju ar mākoņu.

Kā tas notiek pie mums. Inženieris, kurš uzstāda klasteri, norāda, cik darbinieku un kādiem parametriem tam nepieciešami (piemēram, 5 darbinieki, katrs ar 10 CPU, 16 GB RAM un, teiksim, 100 GB diska). Pēc tam viņš iegūst piekļuvi jau izveidotajam klasterim. Šajā procesā darbinieki, uz kuriem tiek palaista slodze, pilnībā tiek nodoti klientam, bet viss pārvaldības slānis paliek pie piegādātāja atbildības (ja pakalpojums tiek sniegts kā pārvaldīts pakalpojums).

Tomēr šai shēmai ir savi trūkumi. Tā kā pārvaldības slānis paliek pie piegādātāja, piegādātājs neļauj klientam pilnībā piekļūt, un tas samazina elastību darbā ar Kubernetes. Dažreiz klients vēlas pievienot kādu specifisku funkcionalitāti Kubernetes, piemēram, autentifikāciju caur LDAP, bet pārvaldības slāņa konfigurācija to neļauj.

Attēls 3. Kubernetes klastera piemērs no mākoņu pakalpojumu sniedzēja

Ko izvēlēties: atvērtā koda vai piegādātāja risinājumu

Tātad, open source Kubernetes vai vendoru risinājums? Izvēloties open source Kubernetes, lietotājs var darīt, ko vēlas. Bet ir liela iespēja trāpīt sev kājā. Ar vendoru risinājumu tas ir sarežģītāk, jo uzņēmums ir pārliecinājies un visu noregulējis. Lielākais trūkums open source Kubernetes ir prasība pēc speciālistiem. Ar vendoru uzņēmums atbrīvojas no šīs galvassāpes, taču tam nāksies izlemt: maksāt saviem speciālistiem vai vendoram.

Nu tad, plusi ir acīmredzami, mīnusi arī ir zināmi. Neizmainīts ir viens: Kubernetes risina milzumu problēmu, automatizējot daudzu konteineru pārvaldību. Un kuru izvēlēties, open source vai vendoru risinājumu — to katrs izlemj pats.