Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

Sveiki, mani sauc Dmitrijs Krasnovs. Vairāk nekā piecus gadus es administrēju Kubernetes klasterus un veidoju sarežģītas mikropakalpojumu arhitektÅ«ras. Å Ä« gada sākumā mēs uzsākām pakalpojumu Kubernetes klasteru pārvaldÄ«bai, pamatojoties uz Containerum. Izmantojot Å”o iespēju, es jums pastāstÄ«Å”u, kas ir Kubernetes un kā integrācija ar pārdevēju atŔķiras no atvērtā pirmkoda.

Lai sāktu, kas ir Kubernetes. Å Ä« ir sistēma konteineru pārvaldÄ«bai daudzos saimniekdatoros. Starp citu, no grieÄ·u valodas tas tiek tulkots kā ā€œpilotsā€ vai ā€œstÅ«rmanisā€. Sākotnēji to izstrādāja Google un pēc tam ziedoja kā tehnoloÄ£iju ieguldÄ«jumu Cloud Native Computing Foundation ā€” starptautiskai bezpeļņas organizācijai, kas apvieno pasaulē vadoÅ”os izstrādātājus, galalietotājus un konteineru tehnoloÄ£iju nodroÅ”inātājus.

Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

Pārvaldiet lielu skaitu konteineru

Tagad izdomāsim, kādi konteineri tie ir. Šī ir lietojumprogramma ar visu vidi - galvenokārt bibliotēkām, no kurām ir atkarīga programma. Tas viss tiek iepakots arhīvos un parādīts attēla veidā, kuru var palaist neatkarīgi no operētājsistēmas, pārbaudīt un daudz ko citu. Bet ir problēma - pārvaldīt konteinerus daudzos saimniekdatoros ir ļoti grūti. Tāpēc tika izveidota Kubernetes.

Konteinera attēls attēlo lietojumprogrammu un tās atkarÄ«bas. Lietojumprogramma, tās atkarÄ«bas un OS failu sistēmas attēls atrodas dažādās attēla daļās, tā sauktajos slāņos. Slāņus var atkārtoti izmantot dažādiem konteineriem. Piemēram, visas uzņēmuma lietojumprogrammas var izmantot Ubuntu bāzes slāni. Palaižot konteinerus, resursdatorā nav jāuzglabā vairākas viena pamata slāņa kopijas. Tas ļauj optimizēt attēlu uzglabāŔanu un piegādi.

Kad mēs vēlamies palaist lietojumprogrammu no konteinera, nepiecieÅ”amie slāņi tiek uzlikti viens otram un tiek izveidota pārklājuma failu sistēma. Uz augÅ”u ir uzlikts ierakstÄ«Å”anas slānis, kas tiek noņemts, kad tvertne apstājas. Tas nodroÅ”ina, ka, palaižot konteineru, lietojumprogrammai vienmēr bÅ«s tā pati vide, kuru nevar mainÄ«t. Tas garantē vides reproducējamÄ«bu dažādās resursdatora operētājsistēmās. NeatkarÄ«gi no tā, vai tas ir Ubuntu vai CentOS, vide vienmēr bÅ«s tāda pati. Turklāt konteiners ir izolēts no resursdatora, izmantojot Linux kodolā iebÅ«vētus mehānismus. Lietojumprogrammas konteinerā neredz failus, resursdatora procesus un blakus esoÅ”os konteinerus. Å Ä« lietojumprogrammu izolācija no resursdatora OS nodroÅ”ina papildu droŔības lÄ«meni.

Ir pieejami daudzi rÄ«ki, lai pārvaldÄ«tu konteinerus resursdatorā. Populārākais no tiem ir Docker. Tas ļauj nodroÅ”ināt pilnu konteineru dzÄ«ves ciklu. Tomēr tas darbojas tikai vienā resursdatorā. Ja jums ir jāpārvalda konteineri vairākos saimniekdatoros, Docker var padarÄ«t inženieru dzÄ«vi par elli. Tāpēc tika izveidota Kubernetes.

PieprasÄ«jums pēc Kubernetes ir tieÅ”i saistÄ«ts ar spēju pārvaldÄ«t konteineru grupas vairākos saimniekdatoros kā atseviŔķu vienÄ«bu. Sistēmas popularitāte sniedz iespēju izveidot DevOps vai attÄ«stÄ«bas operācijas, kurās Kubernetes tiek izmantots, lai palaistu tieÅ”i Ŕī DevOps procesus.

Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

1. attēls. Kubernetes darbības shematisks attēlojums

Pilnīga automatizācija

DevOps bÅ«tÄ«bā ir izstrādes procesa automatizācija. Aptuveni runājot, izstrādātāji raksta kodu, kas tiek augÅ”upielādēts repozitorijā. Pēc tam Å”o kodu var automātiski uzreiz savākt konteinerā ar visām bibliotēkām, pārbaudÄ«t un ā€œizrullētā€ uz nākamo posmu - Staging un pēc tam uzreiz uz RažoÅ”anu.

Kopā ar Kubernetes DevOps ļauj automatizēt Å”o procesu tā, lai tas notiktu praktiski bez paÅ”u izstrādātāju lÄ«dzdalÄ«bas. Sakarā ar to bÅ«vniecÄ«ba ir ievērojami ātrāka, jo izstrādātājam tas nav jādara savā datorā - viņŔ vienkārÅ”i ieraksta koda daļu, nospiež kodu uz repozitoriju, pēc kura tiek palaists konveijers, kas var ietvert procesu. veidoÅ”anu, testÄ“Å”anu un izvērÅ”anu. Un tas notiek ar katru apņemÅ”anos, tāpēc testÄ“Å”ana notiek nepārtraukti.

Tajā paŔā laikā konteinera izmantoÅ”ana ļauj bÅ«t pārliecinātam, ka visa Ŕīs programmas vide tiks izlaista ražoÅ”anā tieÅ”i tādā formā, kādā tā tika pārbaudÄ«ta. Tas nozÄ«mē, ka nebÅ«s tādu problēmu kā "pārbaudē bija dažas versijas, citas - ražoÅ”anā, bet, kad mēs tās instalējām, viss nokrita." Un tā kā Å”odien mums ir tendence uz mikropakalpojumu arhitektÅ«ru, kad vienas milzÄ«gas aplikācijas vietā ir simtiem mazu, lai tos manuāli administrētu, bÅ«s nepiecieÅ”ams milzÄ«gs darbinieku kolektÄ«vs. Tāpēc mēs izmantojam Kubernetes.

Plusi, plusi, plusi


Ja runājam par Kubernetes kā platformas priekŔrocībām, tad tai ir būtiskas priekŔrocības no mikropakalpojumu arhitektūras pārvaldības viedokļa.

  • Vairāku kopiju pārvaldÄ«ba. VissvarÄ«gākais ir pārvaldÄ«t konteinerus vairākos saimniekdatoros. Vēl svarÄ«gāk ir pārvaldÄ«t vairākas lietojumprogrammu kopijas konteineros kā vienu vienÄ«bu. Pateicoties tam, inženieriem nav jāuztraucas par katru atseviŔķu konteineru. Ja kāds no konteineriem avarē, Kubernetes to redzēs un restartēs vēlreiz.
  • Klasteru tÄ«kls. Kubernetes ir arÄ« tā sauktais klasteru tÄ«kls ar savu adreÅ”u telpu. Pateicoties tam, katram podam ir sava adrese. ApakÅ”pods tiek saprasts kā klastera minimālā struktÅ«rvienÄ«ba, kurā konteineri tiek tieÅ”i palaisti. Turklāt Kubernetes ir funkcionalitāte, kas apvieno slodzes balansētāju un pakalpojumu atklāŔanu. Tas ļauj atbrÄ«voties no manuālas IP adreÅ”u pārvaldÄ«bas un deleģēt Å”o uzdevumu Kubernetes. Automātiskās veselÄ«bas pārbaudes palÄ«dzēs atklāt problēmas un novirzÄ«t trafiku uz strādājoÅ”iem podiem.
  • Konfigurācijas pārvaldÄ«ba. Pārvaldot lielu skaitu lietojumprogrammu, kļūst grÅ«ti pārvaldÄ«t lietojumprogrammu konfigurāciju. Å im nolÅ«kam Kubernetes ir Ä«paÅ”i ConfigMap resursi. Tie ļauj centralizēti glabāt konfigurācijas un, palaižot lietojumprogrammas, pakļaut tās podiem. Å is mehānisms ļauj garantēt konfigurācijas konsekvenci vismaz desmit vai simts lietojumprogrammu replikās.
  • PastāvÄ«gi sējumi. Konteineri pēc bÅ«tÄ«bas ir nemainÄ«gi, un, kad konteiners tiek apturēts, visi failu sistēmā ierakstÄ«tie dati tiks iznÄ«cināti. Bet dažas lietojumprogrammas datus glabā tieÅ”i diskā. Lai atrisinātu Å”o problēmu, Kubernetes ir diska krātuves pārvaldÄ«bas funkcionalitāte - Persistent Volumes. Å is mehānisms izmanto ārējo datu krātuvi un var pārsÅ«tÄ«t pastāvÄ«go krātuvi, bloku vai failu, konteineros. Å is risinājums ļauj glabāt datus atseviŔķi no darbiniekiem, kas tos saglabā, ja Å”ie paÅ”i darbinieki sabojājas.
  • Slodzes balansētājs. Lai gan pakalpojumā Kubernetes mēs pārvaldām tādas abstraktas entÄ«tijas kā izvietoÅ”ana, StatefulSet utt., galu galā konteineri darbojas parastās virtuālajās maŔīnās vai aparatÅ«ras serveros. Tie nav ideāli un var nokrist jebkurā laikā. Kubernetes to redzēs un novirzÄ«s iekŔējo trafiku uz citām replikām. Bet ko darÄ«t ar satiksmi, kas nāk no ārpuses? Ja jÅ«s vienkārÅ”i novirzÄ«sit trafiku kādam no darbiniekiem, ja tas avarē, pakalpojums kļūs nepieejams. Lai atrisinātu Å”o problēmu, Kubernetes piedāvā tādus pakalpojumus kā Load Balancer. Tie ir paredzēti, lai automātiski konfigurētu ārējo mākoņu balansētāju visiem klastera darbiniekiem. Å is ārējais balansētājs novirza ārējo trafiku uz darbiniekiem un pats uzrauga viņu statusu. Ja viens vai vairāki darbinieki kļūst nepieejami, satiksme tiek novirzÄ«ta uz citiem. Tas ļauj izveidot ļoti pieejamus pakalpojumus, izmantojot Kubernetes.

Kubernetes vislabāk darbojas, palaižot mikropakalpojumu arhitektÅ«ras. Sistēmu ir iespējams ieviest klasiskajā arhitektÅ«rā, taču tas ir bezjēdzÄ«gi. Ja lietojumprogramma nevar darboties vairākās replikās, kāda ir atŔķirÄ«ba - Kubernetes vai nē?

Atvērtā koda Kubernetes


Atvērtā koda Kubernetes ir lieliska lieta: es to instalēju, un tas darbojas. Varat to izvietot savos aparatūras serveros, savā infrastruktūrā, instalēt galvenos un darbiniekus, kuros darbosies visas lietojumprogrammas. Un pats galvenais, tas viss ir bez maksas. Tomēr ir nianses.

  • Pirmais ir pieprasÄ«jums pēc zināŔanām un pieredzes administratoriem un inženieriem, kuri to visu izvietos un atbalstÄ«s. Tā kā klients klasterÄ« saņem pilnÄ«gu rÄ«cÄ«bas brÄ«vÄ«bu, viņŔ pats ir atbildÄ«gs par klastera darbÄ«bu. Un Å”eit ir ļoti viegli visu salauzt.
  • Otrais ir integrācijas trÅ«kums. Ja izmantojat Kubernetes bez populāras virtualizācijas platformas, jÅ«s nesaņemsit visas programmas priekÅ”rocÄ«bas. Piemēram, izmantojot pastāvÄ«gos apjomus un slodzes lÄ«dzsvara pakalpojumus.

Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

2. attēls. k8s arhitektūra

Kubernetes no pārdevēja


Integrācija ar mākoņa pakalpojumu sniedzēju nodroÅ”ina divas iespējas:

  • Pirmkārt, persona var vienkārÅ”i noklikŔķināt uz pogas ā€œIzveidot kopuā€ un iegÅ«t klasteru, kas jau ir konfigurēts un gatavs lietoÅ”anai.
  • Otrkārt, pārdevējs pats instalē klasteru un iestata integrāciju ar mākoni.

Kā tas Å”eit notiek. Inženieris, kurÅ” uzsāk klasteru, norāda, cik strādnieku viņam vajag un ar kādiem parametriem (piemēram, 5 darbinieki, katrs ar 10 CPU, 16 GB RAM un, teiksim, 100 GB diska). Pēc tam tas iegÅ«st piekļuvi jau izveidotajam klasterim. Å ajā gadÄ«jumā darbinieki, uz kuriem tiek palaista krava, tiek pilnÄ«bā nodoti klientam, bet visa pārvaldÄ«bas plakne paliek pārdevēja pārziņā (ja pakalpojums tiek sniegts saskaņā ar pārvaldÄ«tā pakalpojuma modeli).

Tomēr Å”ai shēmai ir savi trÅ«kumi. Sakarā ar to, ka pārvaldÄ«bas plāns paliek pārdevējam, pārdevējs nesniedz klientam pilnÄ«gu piekļuvi, un tas samazina elastÄ«bu darbā ar Kubernetes. Dažkārt gadās, ka klients vēlas Kubernetes pievienot kādu specifisku funkcionalitāti, piemēram, autentifikāciju caur LDAP, taču pārvaldÄ«bas plaknes konfigurācija to neļauj.

Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

3. attēls. Kubernetes klastera piemērs no mākoņa nodroÅ”inātāja

Ko izvēlēties: atvērtā koda vai pārdevēja


Tātad, vai Kubernetes ir atvērts avots vai piegādātājs? Ja ņemam atvērtā koda Kubernetes, tad lietotājs ar to dara, ko grib. Bet ir liela iespēja ieÅ”aut sev kājā. Ar pārdevēju tas ir grÅ«tāk, jo viss ir pārdomāts un konfigurēts uzņēmuma vajadzÄ«bām. Atvērtā koda Kubernetes lielākais trÅ«kums ir prasÄ«ba pēc speciālistiem. Izmantojot pārdevēja iespēju, uzņēmums ir atbrÄ«vots no Ŕīm galvassāpēm, taču tam bÅ«s jāizlemj, vai maksāt saviem speciālistiem vai pārdevējam.

Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

Kubernetes: atvērtā koda, salīdzinot ar piegādātāju

Nu plusi ir acÄ«mredzami, arÄ« mÄ«nusi ir zināmi. Viena lieta ir nemainÄ«ga: Kubernetes atrisina daudzas problēmas, automatizējot daudzu konteineru pārvaldÄ«bu. Un kuru izvēlēties, atvērtā koda vai pārdevēju ā€“ katrs pieņem lēmumu.

Rakstu sagatavoja Dmitrijs Krasnovs, #CloudMTS nodroŔinātāja Containerum servisa vadoŔais arhitekts

Avots: www.habr.com

Pievieno komentāru