ProHoster > Blogs > Administrācija > Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Sveiki visiem! Mani sauc Pāvels Agaletskis. Es strādāju kā komandas vadÄ«tājs komandā, kas izstrādā Lamoda piegādes sistēmu. 2018. gadā es uzstājos HighLoad++ konferencē, un Å”odien vēlos prezentēt sava ziņojuma atÅ”ifrējumu.

Mana tēma ir veltÄ«ta mÅ«su uzņēmuma pieredzei sistēmu un pakalpojumu izvietoÅ”anā dažādās vidēs. Sākot ar aizvēsturiskiem laikiem, kad visas sistēmas izvietojām parastos virtuālajos serveros, beidzot ar pakāpenisku pāreju no Nomad uz izvietoÅ”anu Kubernetes. Es jums pastāstÄ«Å”u, kāpēc mēs to darÄ«jām un kādas problēmas mums radās Å”ajā procesā.

Lietojumprogrammu izvietoŔana virtuālajā maŔīnā

Sāksim ar to, ka pirms 3 gadiem visas uzņēmuma sistēmas un pakalpojumi tika izvietoti uz parastajiem virtuālajiem serveriem. Tehniski tas tika organizēts tā, ka viss mÅ«su sistēmu kods tika saglabāts un salikts, izmantojot automātiskos montāžas rÄ«kus, izmantojot jenkins. Izmantojot Ansible, tas tika ieviests no mÅ«su versiju kontroles sistēmas virtuālajos serveros. Turklāt katra sistēma, kas bija mÅ«su uzņēmumam, tika izvietota vismaz 2 serveros: viens no tiem galvā, otrs uz astes. Å Ä«s divas sistēmas bija absolÅ«ti identiskas viena otrai visos to iestatÄ«jumos, jaudas, konfigurācijas utt. VienÄ«gā atŔķirÄ«ba starp tām bija tā, ka galva saņēma lietotāju trafiku, bet aste nekad nesaņēma lietotāju trafiku.

Kāpēc tas tika darīts?

Izvietojot jaunas lietojumprogrammas versijas, mēs vēlējāmies nodroÅ”ināt netraucētu izlaiÅ”anu, tas ir, bez manāmām sekām lietotājiem. Tas tika panākts tāpēc, ka nākamais apkopotais laidiens, izmantojot Ansible, tika izrullēts lÄ«dz galam. Tur cilvēki, kas bija iesaistÄ«ti izvietoÅ”anā, varēja pārbaudÄ«t un pārliecināties, ka viss ir kārtÄ«bā: visi rādÄ«tāji, sadaļas un lietojumprogrammas darbojas; tiek palaisti nepiecieÅ”amie skripti. Tikai pēc tam, kad viņi bija pārliecināti, ka viss ir kārtÄ«bā, satiksme tika pārslēgta. Tas sāka iet uz serveri, kas iepriekÅ” bija aste. Un tas, kas iepriekÅ” bija galvenais, palika bez lietotāju trafika, bet tajā joprojām bija mÅ«su lietojumprogrammas iepriekŔējā versija.

Tāpēc lietotājiem tas bija nevainojami. Tā kā pārslēgÅ”anās notiek acumirklÄ«, jo tā ir vienkārÅ”i balansiera pārslēgÅ”ana. JÅ«s varat ļoti viegli atgriezties pie iepriekŔējās versijas, vienkārÅ”i pārslēdzot balansētāju atpakaļ. Mēs varējām arÄ« pārbaudÄ«t, vai lietojumprogramma bija spējÄ«ga ražot pat pirms tā saņēma lietotāju trafiku, kas bija diezgan ērti.

Kādas priekÅ”rocÄ«bas mēs saskatÄ«jām Å”ajā visā?

  1. Pirmkārt, pietiek tas vienkārÅ”i darbojas. Ikviens saprot, kā darbojas Ŕāda izvietoÅ”anas shēma, jo lielākā daļa cilvēku jebkad ir izvietojuÅ”ies uz parastajiem virtuālajiem serveriem.
  2. Ar to pietiek ticami, jo izvietoÅ”anas tehnoloÄ£ija ir vienkārÅ”a, to pārbaudÄ«juÅ”i tÅ«kstoÅ”iem uzņēmumu. Šādā veidā tiek izvietoti miljoniem serveru. Ir grÅ«ti kaut ko salauzt.
  3. Un beidzot mēs varējām saņemties atomu izvietoÅ”ana. IzvietoÅ”ana, kas lietotājiem notiek vienlaicÄ«gi, bez pamanāmas pārslēgÅ”anās no vecās versijas uz jauno versiju.

Bet mēs arÄ« redzējām vairākus trÅ«kumus Å”ajā visā:

  1. Papildus ražoÅ”anas videi, izstrādes videi ir arÄ« citas vides. Piemēram, qa un preproduction. Tajā laikā mums bija daudz serveru un aptuveni 60 pakalpojumu. Å Ä« iemesla dēļ tas bija nepiecieÅ”ams katram pakalpojumam uzturiet tā jaunāko versiju virtuālā iekārta. Turklāt, ja vēlaties atjaunināt bibliotēkas vai instalēt jaunas atkarÄ«bas, tas jādara visās vidēs. Jums bija arÄ« jāsinhronizē laiks, kad plānojat izvietot nākamo jauno lietojumprogrammas versiju, ar laiku, kad devops veic nepiecieÅ”amos vides iestatÄ«jumus. Å ajā gadÄ«jumā ir viegli nonākt situācijā, kad mÅ«su vide bÅ«s kaut cik atŔķirÄ«ga visās vidēs vienlaikus. Piemēram, kvalitātes nodroÅ”ināŔanas vidē bÅ«s dažas bibliotēku versijas, bet ražoÅ”anas vidē - dažādas, kas radÄ«s problēmas.
  2. GrÅ«tÄ«bas atjaunināt atkarÄ«bas jÅ«su pieteikumu. Tas ir atkarÄ«gs nevis no tevis, bet no otras komandas. Proti, no devops komandas, kas apkalpo serverus. Jums ir jādod viņiem atbilstoÅ”s uzdevums un apraksts par to, ko vēlaties darÄ«t.
  3. Toreiz vēlējāmies arÄ« lielos lielos monolÄ«tus, kas mums bija, sadalÄ«t atseviŔķos mazos servisos, jo sapratām, ka tādu bÅ«s arvien vairāk. TobrÄ«d mums jau bija vairāk nekā 100. Katram jaunam pakalpojumam bija nepiecieÅ”ams izveidot atseviŔķu jaunu virtuālo maŔīnu, kas arÄ« bija jāuztur un jāizvieto. Turklāt jums ir nepiecieÅ”ama nevis viena automaŔīna, bet vismaz divas. Tam visam pievienota kvalitātes nodroÅ”ināŔanas vide. Tas rada problēmas un apgrÅ«tina jaunu sistēmu izveidi un darbināŔanu. sarežģīts, dārgs un ilgstoÅ”s process.

Tāpēc mēs nolēmām, ka ērtāk bÅ«tu pāriet no parasto virtuālo maŔīnu izvietoÅ”anas uz mÅ«su lietojumprogrammu izvietoÅ”anu doka konteinerā. Ja jums ir doks, jums ir nepiecieÅ”ama sistēma, kas var palaist lietojumprogrammu klasterÄ«, jo jÅ«s nevarat vienkārÅ”i pacelt konteineru. Parasti jÅ«s vēlaties sekot lÄ«dzi, cik daudz konteineru tiek pacelti, lai tie paceltos automātiski. Å Ä« iemesla dēļ mums bija jāizvēlas vadÄ«bas sistēma.

Ilgi domājām, kuru varētu paņemt. Fakts ir tāds, ka tajā laikā Ŕī izvietoÅ”anas kaudze parastajos virtuālajos serveros bija nedaudz novecojusi, jo tiem nebija jaunāko operētājsistēmu versiju. Kādā brÄ«dÄ« bija pat FreeBSD, kuru nebija Ä«paÅ”i ērti atbalstÄ«t. Mēs sapratām, ka mums pēc iespējas ātrāk jāpāriet uz doku. MÅ«su izstrādātāji aplÅ«koja savu esoÅ”o pieredzi ar dažādiem risinājumiem un izvēlējās tādu sistēmu kā Nomad.

Pārslēdzieties uz Nomad

Nomad ir HashiCorp produkts. Tie ir pazīstami arī ar citiem risinājumiem:

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

"Konsuls" ir pakalpojumu atklāŔanas rīks.

"Teraforma" - serveru pārvaldības sistēma, kas ļauj tos konfigurēt, izmantojot konfigurāciju, tā saukto infrastruktūru kā kodu.

"Klaidonis" ļauj izvietot virtuālās maŔīnas lokāli vai mākonī, izmantojot īpaŔus konfigurācijas failus.

Nomad tolaik Ŕķita diezgan vienkārÅ”s risinājums, uz kuru varēja ātri pārslēgties, nemainot visu infrastruktÅ«ru. Turklāt to ir diezgan viegli iemācÄ«ties. Tāpēc mēs to izvēlējāmies kā mÅ«su konteinera filtrÄ“Å”anas sistēmu.

Kas jums nepiecieÅ”ams, lai izvietotu savu sistēmu pakalpojumā Nomad?

  1. Vispirms jums ir nepiecieÅ”ams dokera attēls jÅ«su pieteikumu. Jums tas ir jāizveido un jāievieto docker attēlu krātuvē. MÅ«su gadÄ«jumā Ŕī ir artefaktÅ«ra - sistēma, kas ļauj tajā iespiest dažādus dažāda veida artefaktus. Tajā var glabāt arhÄ«vus, doku attēlus, komponista PHP pakotnes, NPM pakotnes utt.
  2. Vajadzīgs arī konfigurācijas fails, kas pateiks Nomad, ko, kur un kādā daudzumā vēlaties izvietot.

Kad mēs runājam par Nomad, tas izmanto HCL valodu kā informācijas faila formātu, kas apzīmē HashiCorp konfigurācijas valoda. Šis ir Yaml superkops, kas ļauj aprakstīt pakalpojumu nomadu valodā.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Tas ļauj norādÄ«t, cik konteineru vēlaties izvietot, no kuriem attēliem izvietoÅ”anas laikā tiem nodot dažādus parametrus. Tādējādi jÅ«s ievadāt Å”o failu uzņēmumam Nomad, un tas atbilstoÅ”i tam palaiž konteinerus ražoÅ”anā.

MÅ«su gadÄ«jumā sapratām, ka vienkārÅ”i katram servisam rakstÄ«t absolÅ«ti identiskus HCL failus nebÅ«tu Ä«paÅ”i ērti, jo servisu ir ļoti daudz un dažkārt gribas tos atjaunināt. Gadās, ka viens pakalpojums tiek izvietots nevis vienā, bet dažādos dažādos gadÄ«jumos. Piemēram, vienā no sistēmām, kas tiek ražotas, ir vairāk nekā 100 ražoÅ”anas gadÄ«jumu. Tie darbojas no tiem paÅ”iem attēliem, taču atŔķiras pēc konfigurācijas iestatÄ«jumiem un konfigurācijas failiem.

Tāpēc mēs nolēmām, ka mums bÅ«tu ērti visus mÅ«su konfigurācijas failus izvietoÅ”anai glabāt vienā kopējā repozitorijā. Tādā veidā tie bija redzami: tos bija viegli uzturēt, un mēs varējām redzēt, kādas sistēmas mums ir. Ja nepiecieÅ”ams, ir arÄ« viegli kaut ko atjaunināt vai mainÄ«t. Jaunas sistēmas pievienoÅ”ana arÄ« nav grÅ«ta - jums vienkārÅ”i jāizveido konfigurācijas fails jaunajā direktorijā. Tā iekÅ”pusē ir Ŕādi faili: service.hcl, kurā ir mÅ«su pakalpojuma apraksts, un daži env faili, kas ļauj konfigurēt tieÅ”i Å”o pakalpojumu, kas tiek izvietots ražoÅ”anā.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Tomēr dažas no mÅ«su sistēmām ražoÅ”anā tiek izvietotas nevis vienā eksemplārā, bet vairākās vienlaikus. Tāpēc nolēmām, ka mums bÅ«tu ērti glabāt nevis konfigurācijas tÄ«rā veidā, bet gan veidnes formā. Un mēs izvēlējāmies Džindža 2. Å ajā formātā mēs glabājam gan paÅ”a pakalpojuma konfigurācijas, gan tam nepiecieÅ”amos env failus.

Turklāt mēs esam ievietojuÅ”i repozitorijā visiem projektiem kopÄ«gu izvietoÅ”anas skriptu, kas ļauj palaist un izvietot pakalpojumu ražoÅ”anā, vēlamajā vidē, vēlamajā mērÄ·Ä«. GadÄ«jumā, ja mēs pārvērtām savu HCL konfigurāciju par veidni, HCL fails, kas iepriekÅ” bija parasta Nomad konfigurācija, Å”ajā gadÄ«jumā sāka izskatÄ«ties nedaudz savādāk.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Tas nozÄ«mē, ka mēs aizstājām dažus konfigurācijas atraÅ”anās vietas mainÄ«gos ar ievietotiem mainÄ«gajiem, kas ir ņemti no env failiem vai citiem avotiem. Turklāt mēs ieguvām iespēju dinamiski vākt HCL failus, tas ir, mēs varam izmantot ne tikai parastos mainÄ«go ievietoÅ”anu. Tā kā jinja atbalsta cilpas un nosacÄ«jumus, tur varat arÄ« izveidot konfigurācijas failus, kas mainās atkarÄ«bā no tā, kur tieÅ”i izvietojat savas lietojumprogrammas.

Piemēram, vēlaties izvietot savu pakalpojumu pirmsražoÅ”anas un ražoÅ”anas režīmā. Pieņemsim, ka pirmsražoÅ”anas laikā jÅ«s nevēlaties palaist cron skriptus, bet tikai vēlaties redzēt pakalpojumu atseviŔķā domēnā, lai pārliecinātos, ka tas darbojas. Ikvienam, kurÅ” izvieto pakalpojumu, process izskatās ļoti vienkārÅ”s un pārskatāms. Viss, kas jums jādara, ir jāizpilda fails deploy.sh, jānorāda, kuru pakalpojumu vēlaties izvietot un uz kuru mērÄ·i. Piemēram, jÅ«s vēlaties izvietot noteiktu sistēmu Krievijā, Baltkrievijā vai Kazahstānā. Lai to izdarÄ«tu, vienkārÅ”i mainiet vienu no parametriem, un jums bÅ«s pareizais konfigurācijas fails.

Kad pakalpojums Nomad jau ir izvietots jūsu klasterī, tas izskatās Ŕādi.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Pirmkārt, jums ir nepiecieÅ”ams kaut kāds balansētājs ārpusē, kas saņems visu lietotāju trafiku. Tas strādās kopā ar Consul un no tā noskaidros, kur, kādā mezglā, kādā IP adresē atrodas konkrēts pakalpojums, kas atbilst konkrētam domēna vārdam. Pakalpojumi Consul nāk no paÅ”a Nomad. Tā kā tie ir viena uzņēmuma produkti, tie ir diezgan saistÄ«ti viens ar otru. Var teikt, ka Nomad no kastes var reÄ£istrēt visus tajā uzsāktos pakalpojumus Consul iekÅ”ienē.

Kad jÅ«su priekÅ”gala slodzes lÄ«dzsvarotājs zina, uz kuru pakalpojumu nosÅ«tÄ«t trafiku, tas pārsÅ«ta to uz atbilstoÅ”o konteineru vai vairākiem konteineriem, kas atbilst jÅ«su lietojumprogrammai. Protams, ir jādomā arÄ« par droŔību. Lai gan visi pakalpojumi darbojas vienās un tajās paŔās virtuālajās maŔīnās konteineros, parasti tas prasa novērst brÄ«vu piekļuvi jebkuram pakalpojumam. Mēs to panācām, izmantojot segmentāciju. Katrs pakalpojums tika palaists savā virtuālajā tÄ«klā, kurā tika noteikti marÅ”rutÄ“Å”anas noteikumi un noteikumi piekļuves atļauÅ”anai/lieÅ”anai citām sistēmām un pakalpojumiem. Tie varētu atrasties gan Ŕī klastera iekÅ”pusē, gan ārpus tā. Piemēram, ja vēlaties neļaut pakalpojumam izveidot savienojumu ar noteiktu datu bāzi, to var izdarÄ«t, izmantojot tÄ«kla lÄ«meņa segmentāciju. Tas nozÄ«mē, ka pat kļūdas dēļ jÅ«s nevarat nejauÅ”i izveidot savienojumu no testa vides ar ražoÅ”anas datu bāzi.

Cik mums izmaksāja pāreja cilvēkresursu ziņā?

Visa uzņēmuma pāreja uz Nomad aizņēma aptuveni 5-6 mēneÅ”us. Mēs pārcēlāmies uz katru pakalpojumu atseviŔķi, taču diezgan ātrā tempā. Katrai komandai bija jāizveido savi konteineri pakalpojumiem.

Mēs esam pieņēmuÅ”i tādu pieeju, ka katra komanda ir neatkarÄ«gi atbildÄ«ga par savu sistēmu docker attēliem. DevOps nodroÅ”ina izvietoÅ”anai nepiecieÅ”amo vispārējo infrastruktÅ«ru, tas ir, atbalstu paÅ”am klasterim, atbalstu CI sistēmai un tā tālāk. Un tajā laikā mums uz Nomad tika pārvietotas vairāk nekā 60 sistēmas, kas sastādÄ«ja aptuveni 2 tÅ«kstoÅ”us konteineru.

Devops ir atbildÄ«gs par vispārējo infrastruktÅ«ru visam, kas saistÄ«ts ar izvietoÅ”anu un serveriem. Un katra izstrādes komanda savukārt ir atbildÄ«ga par konteineru ievieÅ”anu savai konkrētajai sistēmai, jo tā ir komanda, kas zina, kas tai kopumā ir nepiecieÅ”ams konkrētajā konteinerā.

Nomad pameŔanas iemesli

Kādas priekÅ”rocÄ«bas mēs ieguvām, cita starpā pārejot uz izvietoÅ”anu, izmantojot Nomad un Docker?

  1. Mēs nodroÅ”ināti vienādi apstākļi visām vidēm. Izstrādē, kvalitātes nodroÅ”ināŔanas vidē, pirmsražoÅ”anā, ražoÅ”anā tiek izmantoti tie paÅ”i konteinera attēli ar vienādām atkarÄ«bām. AttiecÄ«gi jums praktiski nav iespēju, ka tas, kas nonāks ražoÅ”anā, nav tas, ko iepriekÅ” pārbaudÄ«jāt lokāli vai savā testa vidē.
  2. Mēs arÄ« atklājām, ka ar to pietiek viegli pievienot jaunu pakalpojumu. No izvietoÅ”anas viedokļa jebkuras jaunas sistēmas tiek palaistas ļoti vienkārÅ”i. VienkārÅ”i dodieties uz repozitoriju, kurā tiek glabātas konfigurācijas, pievienojiet tur citu sistēmas konfigurāciju, un viss ir gatavs. JÅ«s varat izvietot savu sistēmu ražoÅ”anā bez jebkādām devops papildu pÅ«lēm.
  3. Viss konfigurācijas faili vienā kopējā repozitorijā izrādÄ«jās, ka tas tiek pārskatÄ«ts. Laikā, kad mēs izvietojām sistēmas, izmantojot virtuālos serverus, mēs izmantojām Ansible, kurā konfigurācijas atradās tajā paŔā repozitorijā. Tomēr lielākajai daļai izstrādātāju tas bija nedaudz grÅ«tāk strādāt. Å eit konfigurāciju un koda apjoms, kas jāpievieno pakalpojuma izvietoÅ”anai, ir kļuvis daudz mazāks. Turklāt devops to ir ļoti viegli salabot vai mainÄ«t. Ja notiek pāreja, piemēram, uz jaunu Nomad versiju, viņi var veikt un lielapjoma atjaunināt visus darbÄ«bas failus, kas atrodas tajā paŔā vietā.

Taču mēs saskārāmies arī ar vairākiem trūkumiem:

IzrādÄ«jās, ka mēs nevarēja panākt nevainojamu izvietoÅ”anu Nomad gadÄ«jumā. Izlaižot konteinerus dažādos apstākļos, tas varēja izrādÄ«ties darbināms, un Nomad to uztvēra kā konteineru, kas ir gatavs uztvert trafiku. Tas notika, pirms tajā esoÅ”ajai lietojumprogrammai pat bija iespēja palaist. Å Ä« iemesla dēļ sistēma uz Ä«su laiku sāka ražot 500 kļūdas, jo satiksme sāka virzÄ«ties uz konteineru, kas vēl nebija gatavs to pieņemt.

Mēs sastapāmies ar dažiem pie purviem. BÅ«tiskākā kļūda ir tā, ka Nomad ne pārāk labi apstrādā lielu kopu, ja jums ir daudz sistēmu un konteineru. Ja vēlaties izņemt kādu no serveriem, kas ir iekļauts Nomad klasterÄ« apkopei, pastāv diezgan liela varbÅ«tÄ«ba, ka klasteris nejutÄ«sies Ä«paÅ”i labi un izjuks. Daži konteineri, piemēram, var nokrist un nepacelties ā€” tas jums izmaksās ļoti daudz vēlāk, ja visas jÅ«su ražoÅ”anas sistēmas atrodas klasterÄ«, kuru pārvalda Nomad.

Tāpēc nolēmām padomāt, kurp doties tālāk. Tajā brÄ«dÄ« mēs daudz vairāk apzinājāmies, ko vēlamies sasniegt. Proti: mēs vēlamies uzticamÄ«bu, nedaudz vairāk funkciju, nekā nodroÅ”ina Nomad, un nobrieduŔāku, stabilāku sistēmu.

Å ajā sakarā mÅ«su izvēle krita uz Kubernetes kā vispopulārāko klasteru palaiÅ”anas platformu. ÄŖpaÅ”i ņemot vērā, ka mÅ«su konteineru izmērs un skaits bija pietiekami liels. Šādiem nolÅ«kiem Kubernetes Ŕķita vispiemērotākā sistēma, ko mēs varētu apskatÄ«t.

Pāreja uz Kubernetes

Es jums nedaudz pastāstÄ«Å”u par Kubernetes pamatjēdzieniem un to, kā tie atŔķiras no Nomad.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Pirmkārt, Kubernetes visvienkārŔākā koncepcija ir pod jēdziens. Pāksts ir viena vai vairāku konteineru grupa, kas vienmēr darbojas kopā. Un tie vienmēr darbojas tā, it kā tie bÅ«tu stingri vienā virtuālajā maŔīnā. Tie ir pieejami viens otram, izmantojot IP 127.0.0.1 dažādos portos.

Pieņemsim, ka jums ir PHP lietojumprogramma, kas sastāv no nginx un php-fpm - klasiskās shēmas. Visticamāk, jÅ«s vienmēr vēlaties turēt kopā gan nginx, gan php-fpm konteinerus. Kubernetes ļauj to sasniegt, aprakstot tos kā vienu kopÄ«gu podiņu. Tas ir tieÅ”i tas, ko mēs nevarējām iegÅ«t ar Nomad.

Otrais jēdziens ir izvietoÅ”ana. Fakts ir tāds, ka pati pāksts ir Ä«slaicÄ«ga lieta, tā sākas un pazÅ«d. Vai vispirms vēlaties iznÄ«cināt visus savus iepriekŔējos konteinerus un pēc tam uzreiz palaist jaunas versijas vai arÄ« vēlaties tos izlaist pakāpeniski? Par Å”o procesu ir atbildÄ«ga izvietoÅ”anas koncepcija. Tajā ir aprakstÄ«ts, kā izvietojat savus aplikumus, kādā daudzumā un kā tos atjaunināt.

TreÅ”ais jēdziens ir apkalpoÅ”ana. JÅ«su pakalpojums patiesÄ«bā ir jÅ«su sistēma, kas saņem daļu trafika un pēc tam pārsÅ«ta to uz vienu vai vairākiem jÅ«su pakalpojumam atbilstoÅ”iem podiem. Tas ir, tas ļauj teikt, ka visa ienākoŔā trafika uz Ŕādu un tādu pakalpojumu ar tādu un tādu nosaukumu ir jānosÅ«ta uz Å”iem konkrētajiem podiem. Un tajā paŔā laikā tas nodroÅ”ina satiksmes lÄ«dzsvaroÅ”anu. Tas nozÄ«mē, ka varat palaist divus savas lietojumprogrammas apgabalus, un visa ienākoŔā trafika tiks vienmērÄ«gi lÄ«dzsvarota starp ar Å”o pakalpojumu saistÄ«tajiem podiem.

Un ceturtais pamatjēdziens ir IekļūŔana. Å is ir pakalpojums, kas darbojas Kubernetes klasterÄ«. Tas darbojas kā ārējs slodzes balansētājs, kas pārņem visus pieprasÄ«jumus. Izmantojot Kubernetes API, Ingress var noteikt, kur Å”ie pieprasÄ«jumi jānosÅ«ta. Turklāt viņŔ to dara ļoti elastÄ«gi. Var teikt, ka visi pieprasÄ«jumi Å”im resursdatoram un tādiem un tādiem URL tiek nosÅ«tÄ«ti Å”im pakalpojumam. Un Å”ie pieprasÄ«jumi, kas tiek saņemti uz Å”o resursdatoru un citu URL, tiek nosÅ«tÄ«ti citam pakalpojumam.

Pats forŔākais no lietojumprogrammas izstrādātāja viedokļa ir tas, ka tu pats spēj to visu pārvaldÄ«t. Iestatot Ingress config, visu trafiku, kas nāk uz tādu un tādu API, var nosÅ«tÄ«t uz atseviŔķiem konteineriem, kas rakstÄ«ti, piemēram, Go. Bet Ŕī trafika, kas nāk uz to paÅ”u domēnu, bet uz citu URL, ir jāsÅ«ta uz PHP rakstÄ«tiem konteineriem, kur ir daudz loÄ£ikas, bet tie nav Ä«paÅ”i ātri.

Ja salÄ«dzinām visus Å”os jēdzienus ar Nomad, mēs varam teikt, ka pirmie trÄ«s jēdzieni visi kopā ir Pakalpojums. Un paŔā Nomadā pēdējā jēdziena nav. Mēs izmantojām ārējo balansētāju: tas varētu bÅ«t haproxy, nginx, nginx+ un tā tālāk. Kuba gadÄ«jumā Å”is papildu jēdziens nav jāievieÅ” atseviŔķi. Tomēr, ja paskatās uz Ingress iekŔēji, tas ir vai nu nginx, haproxy vai traefik, bet kaut kā iebÅ«vēts Kubernetes.

Visi manis aprakstÄ«tie jēdzieni faktiski ir resursi, kas pastāv Kubernetes klasterÄ«. Lai tos aprakstÄ«tu kubā, tiek izmantots yaml formāts, kas Nomad gadÄ«jumā ir lasāmāks un pazÄ«stamāks nekā HCL faili. Bet strukturāli tie apraksta to paÅ”u, piemēram, pāksts gadÄ«jumā. Saka - es gribu tur izvietot tādas un tādas pākstis, ar tādiem un tādiem attēliem, tādā un tādā daudzumā.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Turklāt mēs sapratām, ka nevēlamies katru atseviŔķu resursu izveidot ar rokām: izvietoÅ”anu, pakalpojumus, Ingress utt. Tā vietā mēs vēlējāmies izvietoÅ”anas laikā aprakstÄ«t katru mÅ«su sistēmu Kubernetes izteiksmē, lai mums nebÅ«tu manuāli jāpārveido visas nepiecieÅ”amās resursu atkarÄ«bas pareizajā secÄ«bā. Helma tika izvēlēta kā sistēma, kas ļāva mums to izdarÄ«t.

Helmas pamatjēdzieni

StÅ«re ir pakotņu pārvaldnieks par Kubernetes. Tas ir ļoti lÄ«dzÄ«gs tam, kā darbojas pakeÅ”u pārvaldnieki programmÄ“Å”anas valodās. Tie ļauj saglabāt pakalpojumu, kas sastāv, piemēram, no izvietoÅ”anas nginx, izvietoÅ”anas php-fpm, Config for Ingress, configmaps (Ŕī ir entÄ«tija, kas ļauj iestatÄ«t env un citus parametrus jÅ«su sistēmai) kā sauc par diagrammām. Tajā paŔā laikā Helms skrien virsÅ« Kubernetes. Tas ir, Ŕī nav kāda veida sistēma, kas stāv malā, bet tikai vēl viens pakalpojums, kas tiek palaists kuba iekÅ”pusē. JÅ«s mijiedarbojaties ar to, izmantojot tā API, izmantojot konsoles komandu. Tās ērtÄ«bas un skaistums ir tāds, ka pat tad, ja stÅ«re salÅ«zt vai jÅ«s to izņemat no klastera, jÅ«su pakalpojumi nepazudÄ«s, jo stÅ«re bÅ«tÄ«bā kalpo tikai sistēmas palaiÅ”anai. Pēc tam Kubernetes pati ir atbildÄ«ga par pakalpojumu veiktspēju un stāvokli.

Mēs arÄ« to sapratām veidņu veidoÅ”ana, ko iepriekÅ” bijām spiesti darÄ«t paÅ”i, savās konfigurācijās ievieÅ”ot džindzju, ir viena no galvenajām helm iezÄ«mēm. Visas konfigurācijas, ko izveidojat savām sistēmām, tiek glabātas helm veidņu veidā, kas ir nedaudz lÄ«dzÄ«gas jinja, bet patiesÄ«bā tiek izmantotas Go valodas veidnes, kurā ir rakstÄ«ts helm, piemēram, Kubernetes.

Helma mums pievieno vēl dažus jēdzienus.

Diagramma - Å”is ir jÅ«su pakalpojuma apraksts. Citos pakotņu pārvaldniekos to sauktu par pakotni, komplektu vai kaut ko lÄ«dzÄ«gu. Å eit to sauc par diagrammu.

Vērtības ir mainīgie, kurus vēlaties izmantot, lai izveidotu konfigurācijas no veidnēm.

Atlaidiet. Katru reizi, kad pakalpojums, kas tiek izvietots, izmantojot stÅ«ri, saņem pakāpenisku laidiena versiju. Helms atceras, kāda bija pakalpojuma konfigurācija iepriekŔējā laidienā, laidienā pirms tam utt. Tāpēc, ja jums ir jāatgriež, vienkārÅ”i palaidiet stÅ«res atzvanÄ«Å”anas komandu, norādot to uz iepriekŔējo laidiena versiju. Pat ja atbilstoŔā konfigurācija jÅ«su repozitorijā nav pieejama atcelÅ”anas laikā, Helm joprojām atcerēsies, kas tā bija, un atgriezÄ«s jÅ«su sistēmu tādā stāvoklÄ«, kādā tā bija iepriekŔējā laidienā.

GadÄ«jumā, ja mēs izmantojam helm, arÄ« parastās Kubernetes konfigurācijas pārvērÅ”as par veidnēm, kurās ir iespējams izmantot mainÄ«gos, funkcijas un lietot nosacÄ«jumu paziņojumus. Tādā veidā varat apkopot pakalpojuma konfigurāciju atkarÄ«bā no vides.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Praksē mēs nolēmām darÄ«t lietas nedaudz savādāk nekā ar Nomad. Ja pakalpojumā Nomad gan izvietoÅ”anas konfigurācijas, gan n-mainÄ«gie, kas bija nepiecieÅ”ami mÅ«su pakalpojuma izvietoÅ”anai, tika glabāti vienā repozitorijā, Å”eit mēs nolēmām tos sadalÄ«t divās atseviŔķās krātuvēs. ā€œIzvietoÅ”anasā€ repozitorijā tiek glabāti tikai izvietoÅ”anai nepiecieÅ”amie n-mainÄ«gie, un ā€œstÅ«resā€ repozitorijā tiek saglabātas konfigurācijas vai diagrammas.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Ko tas mums deva?

Neskatoties uz to, ka paÅ”os konfigurācijas failos mēs neuzglabājam nekādus patieŔām sensitÄ«vus datus. Piemēram, paroles datu bāzēm. Tie tiek glabāti kā noslēpumi Kubernetes, taču, neskatoties uz to, tur joprojām ir dažas lietas, kurām mēs nevēlamies visiem sniegt piekļuvi. Tāpēc piekļuve ā€œizvietoÅ”anasā€ repozitorijai ir ierobežotāka, un ā€œstÅ«resā€ repozitorijā ir vienkārÅ”i pakalpojuma apraksts. Å Ä« iemesla dēļ tai var droÅ”i piekļūt plaŔāks cilvēku loks.

Tā kā mums ir ne tikai ražoÅ”anas, bet arÄ« citas vides, pateicoties Å”ai atdalÄ«Å”anai, mēs varam atkārtoti izmantot mÅ«su stÅ«res diagrammas, lai izvietotu pakalpojumus ne tikai ražoÅ”anā, bet arÄ«, piemēram, kvalitātes nodroÅ”ināŔanas vidē. Pat lai tos izvietotu lokāli, izmantojot Minikube - Ŕī lieta ir paredzēta Kubernetes lokālai darbÄ«bai.

Katrā repozitorijā mēs atstājām sadalÄ«jumu atseviŔķos direktorijos katram pakalpojumam. Tas nozÄ«mē, ka katrā direktorijā ir veidnes, kas saistÄ«tas ar atbilstoÅ”o diagrammu un apraksta resursus, kas jāizvieto, lai palaistu mÅ«su sistēmu. Mēs atstājām tikai envs ā€œizvietoÅ”anasā€ repozitorijā. Å ajā gadÄ«jumā mēs neizmantojām veidņu veidoÅ”anu, izmantojot jinja, jo pati helm nodroÅ”ina Å”ablonu veidoÅ”anu no kastes - tā ir viena no tās galvenajām funkcijām.

Mēs atstājām izvietoÅ”anas skriptu - deploy.sh, kas vienkārÅ”o un standartizē palaiÅ”anu izvietoÅ”anai, izmantojot stÅ«ri. Tātad ikvienam, kurÅ” vēlas izvietot, izvietoÅ”anas saskarne izskatās tieÅ”i tāda pati kā, izvietojot, izmantojot Nomad. Tas pats deploy.sh, jÅ«su pakalpojuma nosaukums un vieta, kur vēlaties to izvietot. Tas izraisa stÅ«res iedarbināŔanu iekŔēji. Tas, savukārt, savāc konfigurācijas no veidnēm, ievieto tajās nepiecieÅ”amos vērtÄ«bu failus, pēc tam izvieto tos, palaižot tos Kubernetes.

Atzinumi

Šķiet, ka Kubernetes pakalpojums ir sarežģītāks nekā Nomad.

Lietojumprogrammu izvietoŔana VM, Nomad un Kubernetes

Å eit izejoŔā satiksme nonāk uz Ingress. Tas ir tikai priekŔējais kontrolieris, kas pārņem visus pieprasÄ«jumus un pēc tam nosÅ«ta tos pakalpojumiem, kas atbilst pieprasÄ«juma datiem. Tas nosaka tos, pamatojoties uz konfigurācijām, kas ir daļa no jÅ«su vadÄ«bas lietojumprogrammas apraksta un kuras izstrādātāji iestata paÅ”i. Pakalpojums nosÅ«ta pieprasÄ«jumus saviem podiem, tas ir, konkrētiem konteineriem, lÄ«dzsvarojot ienākoÅ”o trafiku starp visiem konteineriem, kas pieder Å”im pakalpojumam. Un, protams, mēs nedrÄ«kstam aizmirst, ka mums nevajadzētu aiziet no droŔības tÄ«kla lÄ«menÄ«. Tāpēc segmentācija darbojas Kubernetes klasterÄ«, kura pamatā ir marÄ·Ä“Å”ana. Visiem pakalpojumiem ir noteikti tagi, ar kuriem ir saistÄ«tas pakalpojumu piekļuves tiesÄ«bas noteiktiem ārējiem/iekŔējiem resursiem klasterÄ« vai ārpus tā.

Veicot pāreju, mēs redzējām, ka Kubernetes piedāvā visas iepriekÅ” izmantotās Nomad iespējas, kā arÄ« pievienojām daudz jaunu lietu. To var paplaÅ”ināt, izmantojot spraudņus un faktiski izmantojot pielāgotus resursu veidus. Tas nozÄ«mē, ka jums ir iespēja ne tikai izmantot kaut ko, kas ir iekļauts Kubernetes komplektācijā, bet arÄ« izveidot savu resursu un pakalpojumu, kas nolasÄ«s jÅ«su resursu. Tas sniedz papildu iespējas sistēmas paplaÅ”ināŔanai, nepārinstalējot Kubernetes un neprasot veikt izmaiņas.

Šādas izmantoÅ”anas piemērs ir Prometheus, kas darbojas mÅ«su Kubernetes klasterÄ«. Lai tas sāktu apkopot metriku no konkrēta pakalpojuma, pakalpojuma aprakstam ir jāpievieno papildu resursa veids, tā sauktais pakalpojumu monitors. Tā kā Prometheus var nolasÄ«t pielāgotu resursa veidu, kad tas tiek palaists Kubernetes, automātiski sāk vākt metriku no jaunās sistēmas. Tas ir diezgan ērti.

Pirmā izvietoÅ”ana Kubernetes tika veikta 2018. gada martā. Un Å”ajā laikā mēs nekad ar to nesaskārāmies ar problēmām. Tas darbojas diezgan stabili, bez bÅ«tiskām kļūdām. Turklāt mēs varam to paplaÅ”ināt vēl vairāk. Å odien mums ir pietiekami daudz iespēju, kas tai ir, un mums ļoti patÄ«k Kubernetes attÄ«stÄ«bas tempi. Å obrÄ«d Kubernetes atrodas vairāk nekā 3000 konteineru. Klasteris aizņem vairākus mezglus. Tajā paŔā laikā tas ir apkalpojams, stabils un ļoti vadāms.

Avots: www.habr.com

Pievieno komentāru