Ahojte! Volám sa Pavel Agalecskij. Pracujem ako tímový líder v tíme, ktorý vyvíja doručovaciu systém Lamoda. V roku 2018 som vystupoval na konferencii HighLoad++, a dnes chcem predstaviť prepis svojej prednášky.

Moja téma je venovaná skúsenostiam našej spoločnosti pri nasadzovaní systémov a služieb do rôznych prostredí. Začneme od našich prenádherných časov, keď sme nasadzovali všetky systémy na bežné virtuálne servery, až po postupný prechod od Nomad k nasadzovaniu do Kubernetes. Porozprávam o tom, prečo sme to urobili a aké problémy sme mali počas procesu.

Nasadzovanie aplikácií na VM

Začneme tým, že pred 3 rokmi sa všetky systémy a služby spoločnosti nasadzovali na bežné virtuálne servery. Technicky bolo organizované tak, že celý kód našich systémov sa ukladal a kompiloval prostredníctvom automatizovanej kompilácie s pomocou Jenkins. Pomocou Ansible sa z nášho systému kontroly verzií nasadil už na virtuálne servery. Každý systém, ktorý bol v našej spoločnosti, sa nasadzoval minimálne na 2 servery: jeden z nich bol head a druhý tail. Tieto dve systémy boli úplne identické vo všetkých svojich nastaveniach, výkone, konfigurácii a ostatnom. Rozdiel medzi nimi bol len v tom, že head prijímal používateľský traffic, zatiaľ čo tail nikdy nezískaval žiaden používateľský traffic.

Na čo to bolo potrebné?

Keď sme nasadzovali nové verzie našej aplikácie, chceli sme zabezpečiť bezšvové nasadenie, teda bez viditeľných následkov pre používateľov. To sa dosiahlo tým, že nový zostavený release pomocou Ansible sa nasadil na tail. Tam si ľudia, ktorí sa zaoberali nasadzovaním, mohli overiť a uistiť sa, že všetko funguje: všetky metriky, sekcie a aplikácie sú v poriadku; potrebné skripty sa spúšťajú. Až po tom, čo sa uistili, že všetko je v poriadku, sa traffic prepol. Začal sa presúvať na server, ktorý predtým bol tail. Ten, ktorý predtým bol head, zostal bez používateľského trafficu, pričom mala predchádzajúcu verziu našej aplikácie.

Tým pádom to bolo pre užívateľov plynulé. Pretože prechod je okamžitý, je to len prepínanie vyrovnávača záťaže. Je veľmi jednoduché vrátiť sa k predchádzajúcej verzii jednoducho prepnutím vyrovnávača záťaže späť. Taktiež sme mohli overiť schopnosti aplikácie na produkcii ešte predtým, ako na ňu pôjde užívateľský trafik, čo bolo dosť pohodlné.

Aké výhody sme v tom všetkom videli?

1. V prvom rade to jednoducho funguje. Všetkým je jasné, ako takýto spôsob nasadenia funguje, pretože väčšina ľudí už niekedy nasadila na bežné virtuálne servery.
2. Je to dosť spoľahlivé, pretože technológia nasadenia je jednoduchá, testovaná tisíckami spoločností. Milióny serverov sa takto nasadzujú. Je ťažké niečo pokaziť.
3. A nakoniec, mohli sme získať atomárne nasadenia. Nasadenia, ktoré pre užívateľov prebiehajú okamžite, bez viditeľnej fázy prechodu medzi starou a novou verziou.

Ale aj v tomto všetkom sme videli niekoľko nedostatkov:

1. Okrem produkčného prostredia a vývojového prostredia existujú aj iné prostredia. Napríklad, qa a preprodukcia. V tom čase sme mali mnoho serverov a približne 60 služieb. Z tohto dôvodu sme museli u každého servisu udržiavať aktuálnu verziu virtuálneho stroja. A ak chcete aktualizovať knižnice alebo pridať nové závislosti, musíte to urobiť vo všetkých prostrediach. Tiež bolo potrebné synchronizovať čas, kedy plánujete nasadiť ďalšiu novú verziu aplikácie, s časom, keď devops vykoná potrebné nastavenia prostredia. V takom prípade je ľahké dostať sa do situácie, kde sa naše prostredie bude v rôznych prostrediach líšiť. Napríklad v QA prostredí budú iné verzie knižníc, zatiaľ čo na produkcii budú iné, čo povedie k problémom.
2. Zložitosti pri aktualizácii závislostí vašej aplikácie. To nezávisí od vás, ale od iného tímu. A to konkrétne od tímu devops, ktorý spravuje servery. Musíte im nastaviť príslušnú úlohu a poskytnúť popis toho, čo chcete urobiť.
3. V tom čase sme sa tiež chceli zbaviť našich veľkých monolitov a rozdeliť ich na menšie služby, pretože sme si uvedomovali, že ich bude stále viac. V tom čase sme už mali viac ako 100 z nich. Pre každú novú službu bolo potrebné vytvoriť novú virtuálnu mašinu, ktorú bolo potrebné spravovať a nasadzovať. Okrem toho sme potrebovali nie jednu, ale aspoň dve mašiny. K tomu všetkému sa pridáva aj QA prostredie. To vytvára problémy a sťažuje vám vytváranie a spúšťanie nových systémov komplikovaným, nákladným a zdĺhavým procesom.

Preto sme sa rozhodli, že bude pohodlnejšie prejsť od nasadenia bežných virtuálnych strojov k nasadeniu našich aplikácií v kontejnery Docker. Pri používaní Dockeru je potrebný systém, ktorý dokáže spustiť aplikáciu v klastri, pretože nemôžete len tak spustiť kontajner. Zvyčajne chcete sledovať, koľko kontajnerov je spustených, a aby sa spúšťali automaticky. Z tohto dôvodu sme museli vybrať správcovský systém.

Dlho sme uvažovali, ktorý z nich si môžeme zvoliť. Faktom je, že v tom čase bol náš nasadzovací stack na bežné virtuálne servery už trochu zastaraný, pretože tam boli nie úplne aktuálne verzie operačných systémov. Niekedy tam dokonca bežala FreeBSD, ktorú nebolo veľmi pohodlné spravovať. Uvedomovali sme si, že je potrebné čo najrýchlejšie migrovať na Docker. Naši DevOps sa pozreli na svoje existujúce skúsenosti s rôznymi riešeniami a vybrali taký systém ako Nomad.

Prechod na Nomad

Nomad je produkt spoločnosti „HashiCorp“. Taktiež sú známi ďalšími svojimi riešeniami:

„Consul“ — to je prostriedok na služobné zistovanie.

„Terraform“ — systém na správu serverov, ktorý vám umožňuje ich nastaviť prostredníctvom konfigurácie, známej ako infrastructure-as-code.

„Vagrant“ umožňuje vám nasadiť virtuálne stroje lokálne alebo v oblaku pomocou určitých konfiguračných súborov.

Nomad nám v tom čase pripadal ako dosť jednoduché riešenie, na ktoré sa dá rýchlo prejsť bez zmeny celej infraštruktúry. Okrem toho je dostatočne ľahko osvojené. Preto sme ho vybrali ako systém na filtrovanie našich kontajnerov.

Čo potrebujete na to, aby ste vôbec mohli nasadiť váš systém v Nomad?

1. Predovšetkým potrebujete docker image vašej aplikácie. Je potrebné ju zostaviť a umiestniť do úložiska obrazov Docker. V našom prípade je to artifactory — systém, ktorý umožňuje posielať doň rôzne artefakty rôzneho typu. Ukladá archívy, obrazy Docker, balíky composer PHP, NPM balíky a tak ďalej.
2. Tiež je potrebné konfiguračný súbor, ktorý povie Nomad, čo, kam a v akom množstve chcete nasadiť.

Keď hovoríme o Nomad, ako formát informačného súboru používa jazyk HCL, čo sa dešifruje ako HashiCorp Configuration Language. Je to nadmnožina Yaml, ktorá vám umožňuje opísať váš servis v pojmoch Nomad.

Umožňuje povedať, koľko kontajnerov chcete nasadiť, z akých obrázkov im poslať rôzne parametre pri nasadení. Takto podávate tento súbor Nomad, a on spúšťa kontajnery podľa neho v produkcii.

V našom prípade sme zistili, že písať absolútne identické HCL súbory pre každý servis nie je veľmi pohodlné, pretože je veľa servisov a niekedy ich chceme aktualizovať. Sú prípady, keď je jeden servis nasadený nie v jednom exemplári, ale v rôznych. Napríklad jeden z systémov, ktorý máme v produkcii, má viac ako 100 inštancií v prevádzke. Spúšťajú sa z rovnakých obrazov, ale líšia sa konfiguračnými nastaveniami a konfiguračnými súbormi.

Preto sme sa rozhodli, že bude pohodlné ukladať všetky naše konfiguračné súbory pre nasadenie v jednom spoločnom repozitári. Takto sú prehľadné: je ich ľahké spravovať a môžete vidieť, aké systémy máme. V prípade potreby nie je ťažké niečo aktualizovať alebo zmeniť. Pridať nový systém tiež nebude náročné — stačí jednoducho vytvoriť konfiguračný súbor v nového adresáru. Vnútri sa nachádzajú súbory: service.hcl, ktorý obsahuje popis našich služieb, a niektoré env súbory, ktoré umožňujú tento servis, po nasadení v produkcii, nastaviť.

Niektoré naše systémy sú však nasadené v produkcii nie v jednom exemplári, ale v niekoľkých naraz. Preto sme sa rozhodli, že bude pohodlné ukladať nie konfigurácie v čistej forme, ale ich šablónizovanú podobu. Ako jazyk šablónovania sme vybrali jinja 2. V tomto formáte máme uložené ako konfigurácie samotnej služby, tak aj env-súbory, ktoré sú pre ňu potrebné.

Okrem toho sme umiestnili do repozitára spoločný skript pre všetky projekty, ktorý umožňuje spustiť a nasadiť vašu službu do produkcie, do požadovaného prostredia a na požadovaný cieľ. Keď sme transformovali náš HCL-konfiguráciu na šablónu, HCL-súbor, ktorý bol predtým obyčajnou konfiguráciou Nomad, sa teraz zmenil na trochu iný formát.

Teda sme nahradili niektoré premenné miesta konfigurácie vkladmi premenných, ktoré sú načítané z env-súborov alebo z iných zdrojov. Okrem toho sme získali možnosť dynamicky generovať HCL-súbory, to znamená, že môžeme aplikovať nielen bežné vklady premenných. Keďže jinja podporuje cykly a podmienky, môžeme tam vytvárať konfiguračné súbory, ktoré sa menia v závislosti od toho, kam presne nasadzujete svoje aplikácie.

Napríklad, ak chcete nasadiť svoju službu do preprodukcie a do produkcie. Predpokladajme, že v preprodukcii nechcete spúšťať crontab skripty, ale jednoducho chcete vidieť službu na samostatnej doméne, aby ste sa uistili, že funguje. Pre každého, kto nasadzuje službu, sa proces zdá veľmi jednoduchý a prehľadný. Stačí vykonať súbor deploy.sh, uviesť, ktorú službu chcete nasadiť a na aký cieľ. Napríklad, chcete nasadiť nejaký systém do Ruska, Bieloruska alebo Kazachstanu. Na to stačí len zmeniť jeden z parametrov a správny konfiguračný súbor sa vytvorí.

Keď je služba Nomad už nasadená vo vašom klastri, vyzerá to nasledovne.

Najprv potrebujete nejakého externého vyvažovača, ktorý bude prijímať celý užívateľský prenos. Bude pracovať spolu s Consulom a zisťovať od neho, kde, na ktorej uzle, podľa akého IP adresu sa nachádza konkrétna služba, ktorá zodpovedá určitému doménovému názvu. Služby v Consule sa objavujú priamo z Nomadu. Keďže sú to produkty jednej a tej istej spoločnosti, sú medzi sebou dobre prepojené. Dá sa povedať, že Nomad dokáže priamo zaregistrovať všetky služby, ktoré sa v ňom spúšťajú, v Consule.

Keď sa váš externý vyvažovač zaťaženia dozvie, do ktorého servisu má poslať traffic, presmeruje ho do príslušného kontajnera alebo do viacerých kontajnerov, ktoré zodpovedajú vašej aplikácii. Je samozrejmé, že pri tom treba myslieť aj na bezpečnosť. Aj keď všetky služby bežia na tých istých virtuálnych strojoch v kontajneroch, zvyčajne je potrebné zakázať voľný prístup z ktorejkoľvek služby k akejkoľvek inej. Toho sme dosiahli segmentáciou. Každá služba bežala vo svojej virtuálnej sieti, na ktorej boli nastavené pravidlá smerovania a pravidlá povolenia/zákazu prístupu k iným systémom a službám. Môžu sa nachádzať buď v rámci tohto klasttra, alebo mimo neho. Ak napríklad chcete zakázať službe pripojiť sa k určitej databáze, môžete to urobiť prostredníctvom segmentácie na úrovni siete. To znamená, že ani omylom sa nemôžete náhodou pripojiť z testovacieho prostredia k vašej produkčnej databáze.

Koľko nás stál proces prechodu z hľadiska ľudských zdrojov?

Celý prechod spoločnosti do systému Nomad trval približne 5-6 mesiacov. Prechádzali sme po službách, ale v pomerne rýchlom tempe. Každý tím musel vytvoriť svoje vlastné kontajnery pre služby.

U nás platí prístup, že každý tím je zodpovedný za docker images svojich systémov samostatne. DevOps poskytuje spoločnú infraštruktúru potrebnú na nasadenie, teda podporu samotného klasttra, podporu CI systému a tak ďalej. A v tom čase už viac ako 60 systémov prešlo do Nomadu, vzniklo približne 2000 kontajnerov.

DevOps je zodpovedný za spoločnú infraštruktúru všetkého súvisiaceho s nasadením, so servermi. A každý tím vývoja na druhej strane je zodpovedný za realizáciu kontajnerov pre svoj konkrétny systém, pretože práve tím vie, čo presne potrebuje v tom ktorom kontajneri.

Dôvody odmietnutia Nomadu

Aké výhody sme získali prechodom na nasadenie pomocou Nomadu a dockeru?

1. Integrujeme Grafanu s Omnibus zabezpečili sme rovnaké podmienky pre všetky prostredia. V devops, QA prostredí, preprodukcii a produkcii sa používajú rovnaké kontajnerové obrazy s tými istými závislosťami. Tým pádom máte prakticky nulovú šancu, že do produkcie sa dostane niečo, čo ste predtým netestovali lokálne alebo na testovacom prostredí.
2. Tiež sme zistili, že je dosť ľahké pridať novú službu. Akékoľvek nové systémy z pohľadu nasadenia sa spúšťajú veľmi jednoducho. Stačí ísť do repozitára, ktorý uchováva konfigurácie, pridať tam ďalšiu konfiguráciu pre váš systém a máte všetko pripravené. Môžete nasadiť váš systém do produkcie bez dodatočných námahy od devops.
3. Všechna konfiguračné súbory v jednom spoločnom repozitári sa ukázali ako prehľadné. V tom momente, keď sme nasadzovali naše systémy pomocou virtuálne servery., používali sme Ansible, kde konfigurácie ležali v rovnakom repozitári. Avšak pre väčšinu vývojárov bolo s týmto trochu zložitejšie pracovať. Tu sa objem konfigurácií a kódu, ktorý musíte pridať na nasadenie služby, výrazne zmenšil. Plus pre devops je veľmi jednoduché to opraviť alebo zmeniť. V prípade prechodov, napríklad na novej verzii Nomad, môžu vziať a masívne aktualizovať všetky operačné súbory, ktoré ležia na rovnakom mieste.

Ale tiež sme sa stretli s niekoľkými nevýhodami:

Ukázalo sa, že sme nedokázali dosiahnuť bezproblémovosť nasadení v prípade Nomad. Pri vydaní kontajnerov z rôznych podmienok sa mohlo stať, že bol spustený a Nomad ho vnímal ako kontajner pripravený prijímať provoz. K tomu dochádzalo ešte predtým, než sa aplikácia vo vnútri stihla spustiť. Z tohto dôvodu systém na krátky čas začal vydávať 500-ky chyby, pretože prevádzka začala ísť na kontajner, ktorý ešte nebol pripravený ju prijať.

Stretli sme sa s niektorými chybami. Najväčší problém spočíva v tom, že Nomad nie je veľmi dobrý pri spracovaní veľkých klastrov, ak máte veľa systémov a kontajnerov. Keď chcete odstaviť jeden zo serverov, ktorý je súčasťou klastrov Nomad, existuje pomerne vysoká pravdepodobnosť, že sa klaster nebude cítiť príliš dobre a rozpadne sa. Niektoré kontajnery môžu napríklad zlyhať a nemusí sa im podariť obnoviť sa – to vás nielenže bude stáť nemalé peniaze, ak sú všetky vaše systémy v produkcii práve v klasteri riadenom Nomad.

Preto sme sa rozhodli premýšľať, kam ísť ďalej. Vtedy sme sa už oveľa lepšie vedeli zamerať na to, čo chceme dosiahnuť. A to konkrétne: chceme spoľahlivosť, o niečo viac funkcií, než ponúka Nomad, a zrelší, stabilnejší systém.

V tomto ohľade sme si vybrali Kubernetes ako najpopulárnejšiu platformu na spúšťanie klastrov. Obzvlášť vzhľadom na to, že veľkosť a množstvo našich kontajnerov bolo dosť veľké. Kubernetes sa ukázal ako najvhodnejší systém zo všetkých, ktoré sme mohli preskúmať.

Prechod na Kubernetes

Trochu vám priblížim, aké sú základné pojmy Kubernetes a čím sa líšia od Nomad.

Predovšetkým najzákladnejším pojmom v Kubernetes je pojem pod. Pod – ide o skupinu jedného alebo viacerých kontajnerov, ktoré sa vždy spúšťajú spolu. Fungujú ako keby vždy striktne na jednom virtuálnom stroji. Navzájom majú prístup cez IP adresu 127.0.0.1 na rôznych portoch.

Predpokladajme, že máte PHP aplikáciu, ktorá sa skladá z nginx a php-fpm – klasická schéma. Pravdepodobne budete chcieť, aby kontajnery nginx a php-fpm boli vždy spolu. Kubernetes toto umožňuje dosiahnuť opísaním ich ako jedného spoločného podu. Toto je presne to, čo sme nemohli dosiahnuť pomocou Nomad.

Druhým pojmom je deployment. Faktom je, že pod sám o sebe je efemérna záležitosť, spúšťa sa a zaniká. Chcete najprv odstrániť všetky vaše predchádzajúce kontajnery a potom okamžite spustiť nové verzie, alebo chcete, aby sa zavádzali postupne – presne za tento proces zodpovedá pojem deployment. Ten popisuje, ako nasadzujete svoje pody, v akom množstve a ako ich aktualizovať.

Tretím pojmom je service. Váš service je v podstate váš systém, ktorý prijíma určitý traffic a následne ho smeruje na jeden alebo viac podov, ktoré zodpovedajú vašemu servisu. To znamená, že umožňuje povedať, že celý prichádzajúci traffic na takýto servis s takýmto menom musí byť zaslaný na konkrétne tieto pody. A pritom vám zabezpečuje vyváženie trafficu. To znamená, že môžete spustiť dva pody vašej aplikácie a celý prichádzajúci traffic bude rovnomerne vyvážený medzi týmito servisom prislúchajúcimi podmi.

A štvrtý základný pojem — Ingress. Je to servis, ktorý sa spúšťa v klastre Kubernetes. Pôsobí ako externý vyvažovač záťaže, ktorý preberá všetky požiadavky. Vďaka API Kubernetes Ingress môže určiť, kam tieto požiadavky zaslať. Zároveň to robí veľmi flexibilne. Môžete povedať, že všetky požiadavky na tento hostiteľ a takýto URL posielame na tento servis. A tieto požiadavky, ktoré prichádzajú na tento hostiteľ a na iný URL posielame na iný servis.

Najlepšie z pohľadu toho, kto vyvíja aplikáciu — je to, že máte schopnosť týmto všetkým sami spravovať. Nastavením konfigurácie Ingress môžete poslať celý traffic prichádzajúci na takýto API na jednotlivé kontajnery, zapísané napríklad v Go. A tento traffic, prichádzajúci na ten istý domén, ale na iný URL, posielať na kontajnery napísané v PHP, kde je veľa logiky, ale nie sú veľmi rýchle.

Ak porovnáme všetky tieto pojmy s Nomad, dá sa povedať, že prvé tri pojmy – to všetko dohromady predstavuje Service. A posledný pojem v samom Nomade chýba. Ako jeho alternatívu sme použili externý vyvažovač: to môže byť haproxy, nginx, nginx+ a tak ďalej. V prípade kubu nemusíte toto dodatočné pojmové schéma zavádzať osobitne. Avšak, ak sa pozriete na Ingress vo vnútri, je to buď nginx, alebo haproxy, alebo traefik, ale akoby integrované do Kubernetes.

Všetky mnou popísané pojmy – to sú v podstate zdroje, ktoré existujú v rámci klastru Kubernetes. Na ich popis v kubu sa používa yaml formát, ktorý je viac čitateľný a známejší než HCL súbory v prípade Nomad. Ale štrukturálne opisujú v prípade, napríklad, podu to isté. Hovoria — chcem nasadiť takéto pody tamto, s takýmito obrázkami, v takomto počte.

Okrem toho sme si uvedomili, že nechceme manuálne vytvárať každý jednotlivý zdroj: nasadenie, služby, Ingress a podobne. Namiesto toho sme chceli pri nasadení popísať každý náš systém v pojmoch Kubernetes, aby sme nemuseli ručne znova vytvárať v správnom poradí všetky potrebné závislosti zdrojov. Ako taký systém, ktorý nám to umožnil, bol vybraný Helm.

Základné pojmy v Helme

Helm je správca balíkov pre Kubernetes. Je veľmi podobný tomu, ako fungujú správci balíkov v programovacích jazykoch. Umožňujú vám uchovávať službu, ktorá sa skladá napríklad z nasadenia nginx, nasadenia php-fpm, konfigurácie pre Ingress, configmaps (to je entita, ktorá vám umožňuje nastaviť env a ďalšie parametre pre váš systém) vo forme takzvaných chartov. Pri tom Helm funguje nad Kubernetes. Teda to nie je nejaký systém, ktorý by stál bokom, ale len ďalšia služba, ktorá sa spúšťa vo vnútri klastru. S ním interagujete prostredníctvom jeho API cez príkazový riadok. Jeho pohodlie a krása spočíva v tom, že aj keď sa helm pokazí alebo ho odstránite z klastra, vaše služby nezmiznú, pretože helm v podstate slúži len na spustenie systému. Za funkčnosť a stav služieb ďalej zodpovedá samotný Kubernetes.

Tiež sme si uvedomili, že šablonizácia, ktorú sme predtým museli robiť manuálne zavedením jinja do našich konfigurácií, je jednou z hlavných možností helmu. Všetky konfigurácie, ktoré vytvárate pre svoje systémy, sú v helme uložené vo forme šablón, ktoré sú trochu podobné jinja, ale v skutočnosti používajú šablonizáciu jazyka Go, v ktorom je helm napísaný, ako aj Kubernetes.

Helm nám pridáva ešte niekoľko ďalších pojmov.

Chart – je to popis vašej služby. V iných správcovských balíkoch by sa to nazvalo balík, bundle alebo niečo podobné. Tu sa to volá chart.

Values – to sú premenné, ktoré chcete použiť na zostavenie vašich konfigurácií zo šablón.

VerziaKaždý raz, keď sa služba nasadzuje pomocou helm, dostáva inkrementálnu verziu vydania. Helm si pamätá, aká bola konfigurácia služby pri predchádzajúcom, predpredchádzajúcom vydaní a tak ďalej. Preto, ak sa potrebujete vrátiť späť, stačí vykonať príkaz helm rollback a uviesť mu predchádzajúcu verziu vydania. Aj keď v okamihu vrátenia zodpovedajúca konfigurácia vo vašom repozitári nie je dostupná, helm si aj tak pamätá, aká bola, a vráti vašu systém do stavu, v ktorom bola pri predchádzajúcom vydaní.

V prípade používania helmu sa bežné konfigurácie pre Kubernetes tiež premenia na šablóny, v ktorých je možné používať premenné, funkcie a podmienené operátory. Týmto spôsobom môžete zostaviť konfiguráciu vašej služby v závislosti od prostredia.

V praxi sme sa rozhodli konať trochu inak, ako sme to robili v prípade Nomad. Zatiaľ čo v Nomad boli v jednom repozitári uložené konfigurácie pre nasadenie a n-premenné potrebné na nasadenie našej služby, tu sme sa rozhodli rozdeliť ich na dva oddelené repozitáre. V repozitári "deploy" sa ukladajú iba n-premenné potrebné na nasadenie, zatiaľ čo v repozitári "helm" sa nachádzajú konfigurácie alebo chart-y.

Čo nám to dalo?

Napriek tomu, že v konfiguráciach samotných neuchovávame naozaj citlivé údaje. Napríklad, heslá k databázam. Tieto sú uložené vo forme secrets v Kubernetes, ale aj tak existujú určité veci, ku ktorým nechceme dať prístup všetkým. Preto je prístup k repozitáru "deploy" viac obmedzený, zatiaľ čo repozitár "helm" obsahuje len popis služby. Z tohto dôvodu možno doň poskytnúť prístup bezpečne väčšiemu okruhu osôb.

Keďže máme nielen produkčné, ale aj iné prostredia, vďaka takémuto rozdeleniu môžeme znovu využiť naše helm chart-y na nasadenie služieb nielen do produkcie, ale aj napríklad do QA prostredia. Dokonca aj na to, aby sme ich nasadili lokálne, používajúc Minikube — to je taká vec pre lokálne spúšťanie Kubernetes.

Vo vnútri každého repozitára sme ponechali rozdelenie na samostatné adresáre pre každú službu. To znamená, že v každom adresári sa nachádzajú šablóny, ktoré sa týkajú príslušného grafu a opisujú tie zdroje, ktoré je potrebné nasadiť na spustenie nášho systému. V repozitári „deploy“ sme nechali iba env. V tomto prípade sme sa nerozhodli použiť šablonizáciu pomocou jinja, pretože helm poskytuje šablonizáciu priamo, čo je jedna z jeho hlavných funkcií.

Nechali sme skript na nasadenie – deploy.sh, ktorý zjednodušuje a štandardizuje spustenie nasadenia pomocou helmu. Takže pre každého, kto chce nasadiť, vyzerá rozhranie nasadenia presne tak isto, ako to bolo v prípade nasadenia cez Nomad. Ten istý deploy.sh, názov vašej služby a miesto, kam ju chcete nasadiť. To vedie k tomu, že sa spúšťa helm. Ten následne zbiera konfigurácie zo šablón, vkladá do nich potrebné súbory values a následne nasadzuje, pričom ich odosiela do Kubernetes.

Zhrnutie

Služba Kubernetes vyzerá zložitejšie ako Nomad.

Tu prichádza odchádzajúca prevádzka do Ingress. To je presne front-end kontrolér, ktorý prijíma všetky požiadavky a neskôr ich odosiela do príslušných služieb podľa danej požiadavky. Určuje ich na základe konfigurácií, ktoré sú súčasťou opisu vašej aplikácie v helme a ktoré vývojári zadávajú sami. Služba potom odosiela požiadavky na svoje pod-y, teda konkrétne kontajnery, vyvažujúc prichádzajúcu prevádzku medzi všetkými kontajnermi, ktoré sa týkajú tejto služby. A samozrejme, nesmieme zabúdať, že na úrovni siete by sme nemali odísť od bezpečnosti. Preto v klastri Kubernetes funguje segmentácia, ktorá je založená na značkovaní. Všetky služby majú určité značky, ku ktorým sú priradené práva prístupu služieb k rôznym vonkajším/vnútorným zdrojom vo vnútri alebo mimo klastra.

Pri prechode sme zistili, že Kubernetes má všetky schopnosti Nomad, ktorý sme predtým používali, a navyše pridáva mnoho nového. Môže byť rozšírený prostredníctvom pluginov, resp. vlastných typov zdrojov. To znamená, že máte možnosť nielen používať niečo, čo prichádza s Kubernetes priamo, ale aj vytvoriť vlastný zdroj a službu, ktorá bude čítať váš zdroj. To poskytuje ďalšie možnosti rozšírenia vášho systému bez potreby reinstalácie Kubernetes a bez potreby zmien.

Príkladom takého použitia je Prometheus, ktorý u nás beží vnútri klastre Kubernetes. Aby začal zbierať metriky z určitej služby, potrebujeme pridať do opisu služby ďalší typ zdroja, tzv. service-monitor. Prometheus vďaka tomu, že dokáže čítať vlastné typy zdrojov, keď beží v Kubernetes, automaticky začína zbierať metriky z novej sústavy. Je to dosť pohodlné.

Prvý deploy, ktorý sme urobili v Kubernetes, bol v marci 2018. A za tento čas sme nikdy nemali s ním žiadne problémy. Funguje stabilne bez podstatných chýb. Okrem toho ho môžeme ďalej rozširovať. Dnes máme dostatočné možnosti, ktoré v ňom sú, a tempo rozvoja Kubernetes sa nám veľmi páči. V súčasnosti je v Kubernetes viac ako 3000 kontajnerov. Klaster zaberá niekoľko uzlov. Je pritom spravovaný, stabilný a veľmi kontrolovateľný.

Zdroj: habr.com