Ahoj všichni! Jmenuji se Pavel Agaletsky. Pracuji jako vedoucí týmu v týmu, který vyvíjí doručovací systém Lamoda. V roce 2018 jsem vystoupil na konferenci HighLoad ++ a dnes chci předložit přepis své zprávy.

Moje téma je věnováno zkušenostem naší společnosti s nasazováním systémů a služeb do různých prostředí. Počínaje našimi prehistorickými časy, kdy jsme všechny systémy nasazovali do běžných virtuálních serverů, konče postupným přechodem od nasazení Nomad k nasazení Kubernetes. Řeknu vám, proč jsme to udělali a jaké problémy jsme při tom měli.

Nasazení aplikací do VM

Začněme tím, že před 3 lety byly všechny systémy a služby společnosti nasazeny na běžné virtuální servery. Technicky to bylo organizováno tak, že veškerý kód našich systémů ležel a byl sestaven pomocí automatických montážních nástrojů, pomocí jenkinů. S pomocí Ansible byl již zaveden z našeho systému správy verzí na virtuální servery. Zároveň byl každý systém, který byl v naší společnosti, nasazen minimálně na 2 servery: jeden z nich - na hlavě, druhý - na ocasu. Tyto dva systémy byly naprosto totožné ve všech nastaveních, výkonu, konfiguraci a tak dále. Jediný rozdíl mezi nimi byl, že head přijímal uživatelský provoz, zatímco tail nikdy nepřijímal uživatelský provoz pro sebe.

k čemu to bylo?

Když jsme nasazovali nové verze naší aplikace, chtěli jsme být schopni bezproblémově zavést, to znamená bez znatelných následků pro uživatele. Toho bylo dosaženo díky skutečnosti, že další zkompilované vydání využívající Ansible bylo vydáno na konec. Tam mohli lidé, kteří se podíleli na nasazení, zkontrolovat a ujistit se, že je vše v pořádku: všechny metriky, sekce a aplikace fungují; jsou spuštěny potřebné skripty. Až poté, co se přesvědčili, že je vše v pořádku, se provoz změnil. Začal chodit na server, který byl předtím ocas. A ten, který byl dříve hlavou, zůstal bez uživatelského provozu, zatímco na něm byla dostupná předchozí verze naší aplikace.

Pro uživatele to tedy bylo bezproblémové. Protože sepnutí je okamžité, protože se jedná pouze o sepnutí balanceru. Je velmi snadné vrátit se k předchozí verzi jednoduchým přepnutím balanceru zpět. Mohli jsme se také ujistit, že aplikace byla připravena k produkci ještě předtím, než do ní zamířil uživatelský provoz, což bylo docela pohodlné.

Jaké ctnosti v tom všem vidíme?

1. Za prvé, stačí prostě funguje. Každý chápe, jak takové schéma nasazení funguje, protože většina lidí někdy nasadila na běžné virtuální servery.
2. Tohle stačí spolehlivě, protože technologie nasazení je jednoduchá, testována tisíci společnostmi. Tímto způsobem jsou nasazeny miliony serverů. Je těžké něco rozbít.
3. A konečně jsme se mohli dostat atomové nasazení. Nasazení, která pro uživatele probíhají současně, bez znatelné fáze přepínání mezi starou verzí a novou.

Ale také jsme v tom všem viděli několik nedostatků:

1. Kromě produkčního prostředí, vývojového prostředí, existují ještě další prostředí. Například qa a předprodukce. V té době jsme měli mnoho serverů a asi 60 služeb. Z tohoto důvodu muselo pro každou službu udržujte její nejnovější verzi virtuální stroj. Navíc, pokud chcete aktualizovat knihovny nebo instalovat nové závislosti, musíte to udělat ve všech prostředích. Bylo také nutné synchronizovat čas, kdy se chystáte nasadit další novou verzi vaší aplikace, s časem, kdy devops provede potřebná nastavení prostředí. V tomto případě je snadné se dostat do situace, kdy naše prostředí bude najednou ve všech prostředích za sebou poněkud odlišné. Například v prostředí QA budou některé verze knihoven a ve výrobě - ​​jiné, což povede k problémům.
2. Potíže s aktualizací závislostí tvá aplikace. Nezáleží na vás, ale na druhém týmu. Konkrétně od týmu devops, který spravuje servery. Měli byste jim zadat vhodný úkol a popsat, co chcete dělat.
3. V té době jsme také chtěli rozdělit velké velké monolity, které jsme měli, na samostatné malé služby, protože jsme chápali, že jich bude stále více. V té době jsme jich měli již více než 100. Pro každou novou službu bylo nutné vytvořit samostatný nový virtuální stroj, který bylo také potřeba obsluhovat a nasazovat. Navíc nepotřebujete jedno auto, ale minimálně dvě. K tomu všemu je přidáno prostředí QA. To způsobuje problémy a ztěžuje vám vytváření a provozování nových systémů. složitý, nákladný a zdlouhavý proces.

Proto jsme se rozhodli, že bude pohodlnější přejít od nasazení běžných virtuálních strojů k nasazení našich aplikací v docker kontejneru. Pokud máte docker, potřebujete systém, který dokáže spouštět aplikaci v clusteru, protože nemůžete jen tak zvednout kontejner. Obvykle chcete mít přehled o tom, kolik kontejnerů bylo zvednuto, aby byly zvednuty automaticky. Z tohoto důvodu jsme museli zvolit řídicí systém.

Dlouho jsme přemýšleli, kterou vzít. Faktem je, že v té době byl tento zásobník nasazení na běžné virtuální servery poněkud zastaralý, protože neexistovaly nejnovější verze operačních systémů. V určitém okamžiku tam bylo dokonce i FreeBSD, které nebylo příliš vhodné podporovat. Pochopili jsme, že musíme co nejdříve migrovat na docker. Naši vývojáři se podívali na své zkušenosti s různými řešeními a vybrali si systém jako Nomad.

Přechod na Nomáda

Nomad je produktem HashiCorp. Jsou také známé svými dalšími řešeními:

Konzul je nástroj pro vyhledávání služeb.

"Teraform" - systém pro správu serverů, který umožňuje jejich konfiguraci prostřednictvím konfigurace, tzv. infrastruktura-jako-kód.

Tulák umožňuje nasadit virtuální stroje lokálně nebo v cloudu prostřednictvím specifických konfiguračních souborů.

Nomad se v té době jevil jako celkem jednoduché řešení, na které můžete rychle přejít bez změny celé infrastruktury. Navíc se to dá poměrně snadno naučit. Proto jsme jej zvolili jako filtrační systém pro náš kontejner.

Co vlastně potřebujete k nasazení vašeho systému v Nomadu?

1. V první řadě potřebujete obrázek dockeru tvá aplikace. Musíte jej sestavit a vložit do úložiště obrázků dockeru. V našem případě se jedná o artifactory - systém, který do něj umožňuje strkat různé artefakty různého typu. Může ukládat archivy, obrázky dockerů, balíčky skladatelů PHP, balíčky NPM a tak dále.
2. Také potřeba konfigurační soubor, který Nomadovi řekne, co, kde a jak moc chcete nasadit.

Když mluvíme o Nomad, používá jazyk HCL jako formát souboru informací, což znamená Konfigurační jazyk HashiCorp. Toto je nadmnožina Yaml, která vám umožňuje popsat vaši službu z hlediska Nomad.

Umožňuje vám říci, kolik kontejnerů chcete nasadit, ze kterých obrázků do nich během nasazení přenést různé parametry. Tento soubor tedy dáte Nomadovi a ten podle něj spustí kontejnery do výroby.

V našem případě jsme si uvědomili, že psát úplně stejné, identické HCL soubory pro každou službu by nebylo příliš pohodlné, protože služeb je spousta a občas je chcete aktualizovat. Stává se, že jedna služba není nasazena v jedné instanci, ale v řadě různých. Například jeden ze systémů, které máme ve výrobě, má více než 100 instancí ve výrobě. Spouštějí se ze stejných obrazů, ale liší se v nastavení konfigurace a konfiguračních souborech.

Proto jsme se rozhodli, že pro nás bude výhodné uložit všechny naše konfigurační soubory pro nasazení do jednoho společného úložiště. Tímto způsobem se staly viditelnými: snadno se udržovaly a bylo vidět, jaké máme systémy. V případě potřeby je také snadné něco aktualizovat nebo změnit. Přidání nového systému také není obtížné – stačí přidat konfigurační soubor do nového adresáře. Uvnitř jsou soubory: service.hcl, který obsahuje popis naší služby, a některé env-soubory, které umožňují konfigurovat právě tuto službu, která je nasazena v produkci.

Některé naše systémy jsou však v produkci nasazeny nikoli v jedné kopii, ale v několika najednou. Proto jsme se rozhodli, že pro nás bude vhodné ukládat nikoli konfigurace v jejich čisté formě, ale jejich šablonovanou formu. A jako šablonovací jazyk jsme zvolili jinja 2. V tomto formátu ukládáme jak konfigurace samotné služby, tak soubory env, které jsou pro ni potřebné.

Kromě toho jsme do úložiště umístili implementační skript, který je společný pro všechny projekty, což vám umožní spustit a nasadit vaši službu v produkci, ve správném prostředí, ve správném cíli. V případě, že jsme z naší konfigurace HCL udělali šablonu, pak soubor HCL, který byl předtím obvyklou konfigurací Nomad, v tomto případě začal vypadat trochu jinak.

To znamená, že jsme nahradili některé proměnné místa konfigurace za vkládání proměnných, které jsou převzaty ze souborů env nebo z jiných zdrojů. Kromě toho jsme získali možnost dynamicky vytvářet soubory HCL, to znamená, že můžeme používat nejen obvyklé proměnné inserty. Vzhledem k tomu, že jinja podporuje cykly a podmínky, můžete tam umístit i konfigurační soubory, které se mění v závislosti na tom, kde přesně své aplikace nasazujete.

Například chcete nasadit svou službu do předprodukce a produkce. Řekněme, že v předprodukci nechcete spouštět cron skripty, ale chcete službu vidět na samostatné doméně, abyste měli jistotu, že běží. Pro každého, kdo nasazuje službu, je proces velmi jednoduchý a transparentní. Stačí spustit soubor deploy.sh, určit, jakou službu chcete nasadit a na jaký cíl. Například chcete nasadit nějaký systém do Ruska, Běloruska nebo Kazachstánu. Chcete-li to provést, jednoduše změňte jeden z parametrů a získáte správný konfigurační soubor.

Když je služba Nomad již nasazena ve vašem clusteru, vypadá to takto.

Pro začátek potřebujete nějaký load balancer zvenčí, který do sebe vezme veškerý uživatelský provoz. Bude spolupracovat s Consul a dozví se z něj, kde, na kterém uzlu, na jaké IP adrese se nachází konkrétní služba, která odpovídá konkrétnímu názvu domény. Služby v Consul pocházejí od samotného Nomada. Protože se jedná o produkty stejné společnosti, jsou dobře propojeny. Dá se říci, že po vybalení je Nomad schopen zaregistrovat všechny služby v něm spuštěné uvnitř Consul.

Poté, co váš externí balancér ví, na kterou službu má odeslat provoz, přesměruje jej do příslušného kontejneru nebo více kontejnerů, které odpovídají vaší aplikaci. Samozřejmě je potřeba myslet i na bezpečnost. I když všechny služby běží na stejných virtuálních počítačích v kontejnerech, obvykle to vyžaduje, abyste odepřeli volný přístup z jakékoli služby k jakékoli jiné. Toho jsme dosáhli segmentací. Každá služba byla spuštěna ve vlastní virtuální síti, na které byla napsána směrovací pravidla a pravidla pro povolení/zakázání přístupu k jiným systémům a službám. Mohou být jak uvnitř tohoto shluku, tak mimo něj. Pokud například chcete zabránit službě v připojení k určité databázi, lze to provést segmentací na úrovni sítě. To znamená, že ani omylem se nemůžete náhodně připojit z testovacího prostředí k vaší produkční základně.

Kolik nás stál přechod z hlediska lidských zdrojů?

Přibližně 5-6 měsíců trval přechod celé společnosti na Nomad. Přesouvali jsme službu po službě, ale poměrně rychlým tempem. Každý tým si musel vytvořit vlastní servisní kontejnery.

Přijali jsme takový přístup, že každý tým je zodpovědný za obrázky dockerů svých systémů nezávisle. Devops naopak poskytuje obecnou infrastrukturu nezbytnou pro nasazení, tedy podporu samotného clusteru, podporu CI systému a tak dále. A v té době jsme do Nomadu nechali přestěhovat více než 60 systémů, což bylo asi 2 tisíce kontejnerů.

DevOps je zodpovědný za obecnou infrastrukturu všeho, co souvisí s nasazením, se servery. A každý vývojový tým je zase zodpovědný za implementaci kontejnerů pro svůj specifický systém, protože je to tým, kdo ví, co obecně potřebuje v konkrétním kontejneru.

Důvody pro odchod z Nomada

Jaké výhody jsme získali přechodem na nasazení také pomocí Nomad a docker?

1. My za stejných podmínek pro všechna prostředí. Ve vývoji, QA-prostředí, předprodukci, výrobě se používají stejné obrazy kontejnerů se stejnými závislostmi. V souladu s tím prakticky nemáte šanci, že se v produkci objeví něco jiného, ​​než co jste dříve testovali lokálně nebo na testovacím prostředí.
2. Také jsme zjistili, že to stačí snadné přidání nové služby. Jakékoli nové systémy z hlediska nasazení se spouštějí velmi jednoduše. Stačí přejít do úložiště, kde jsou uloženy konfigurace, přidat tam další konfiguraci pro váš systém a je hotovo. Svůj systém můžete nasadit do produkce bez dalšího úsilí ze strany vývojářů.
3. vše konfigurační soubory v jednom sdíleném úložišti se ukázalo být přehlíženo. V okamžiku, kdy jsme nasazovali naše systémy pomocí virtuálních serverů, použili jsme Ansible, ve kterém byly konfigurace ve stejném úložišti. Pro většinu vývojářů s tím však bylo trochu obtížnější pracovat. Zde se objem konfigurací a kódu, který je třeba přidat k nasazení služby, mnohem zmenšil. Navíc pro devops je velmi snadné jej opravit nebo změnit. V případě přechodů například na novou verzi Nomad mohou vzít a masivně aktualizovat všechny provozní soubory ležící na stejném místě.

Ale narazili jsme i na několik nevýhod:

Ukázalo se, že my nepodařilo dosáhnout bezproblémového nasazení v případě Nomáda. Při vyjíždění kontejnerů z různých podmínek se mohlo stát, že se ukázalo, že jede, a Nomad to vnímal jako kontejner připravený na provoz. Stalo se to ještě předtím, než se aplikace uvnitř stačila spustit. Z tohoto důvodu začal systém krátkodobě vydávat 500 chyb, protože provoz začal směřovat do kontejneru, který ještě nebyl připraven jej přijmout.

S některými jsme se setkali u bažin. Nejvýznamnější chybou je, že Nomad nezvládá příliš dobře velký cluster, pokud máte mnoho systémů a kontejnerů. Když chcete zprovoznit jeden ze serverů, které jsou součástí clusteru Nomad, je poměrně vysoká pravděpodobnost, že se cluster nebude cítit dobře a rozpadne se. Některé kontejnery mohou například spadnout a nezvednout se – to vás bude později stát hodně, pokud jsou všechny vaše produkční systémy umístěny v clusteru spravovaném Nomad.

Rozhodli jsme se tedy zamyslet nad tím, kam bychom se měli vydat dál. Tehdy jsme si mnohem více uvědomili, čeho chceme dosáhnout. Konkrétně: chceme spolehlivost, trochu více funkcí, než nabízí Nomad, a vyspělejší a stabilnější systém.

V tomto ohledu naše volba padla na Kubernetes jako nejoblíbenější platformu pro provoz clusterů. Zejména vzhledem k tomu, že velikost a počet našich kontejnerů byl dostatečně velký. Pro takové účely se Kubernetes jevil jako nejvhodnější systém z těch, na které jsme se mohli podívat.

Přesun na Kubernetes

Budu mluvit trochu o tom, jaké jsou základní koncepty Kubernetes a jak se liší od Nomad.

Za prvé, nejzákladnějším konceptem v Kubernetes je koncept pod. Lusk je skupina jednoho nebo více kontejnerů, které vždy začínají společně. A fungují jakoby vždy striktně na stejném virtuálním stroji. Jsou si navzájem dostupné pomocí IP adresy 127.0.0.1 na různých portech.

Řekněme, že máte aplikaci PHP, která se skládá z nginx a php-fpm - klasický vzor. S největší pravděpodobností budete chtít, aby kontejnery nginx i php-fpm byly vždy pohromadě. Kubernetes vám toho umožňuje dosáhnout tím, že je popíšete jako jeden společný modul. To je přesně to, co jsme s Nomadem nemohli dostat.

Druhý koncept je rozvinutí. Jde o to, že samotný lusk je pomíjivá věc, začíná a mizí. Ať už chcete nejprve zabít všechny své předchozí kontejnery a poté ihned spustit nové verze, nebo je chcete zavádět postupně – přesně toto je koncept nasazení, který je zodpovědný za tento proces. Popisuje, jak nasazujete své moduly, kolik jich je a jak je aktualizovat.

Třetí koncept je servis. Vaše služba je ve skutečnosti váš systém, který přijímá určitý provoz a poté jej nasměruje na jeden nebo více modulů odpovídajících vaší službě. To znamená, že vám umožňuje říci, že veškerý příchozí provoz na takovou a takovou službu s takovým a takovým názvem musí být odeslán do těchto konkrétních modulů. A zároveň vám poskytuje vyvážení provozu. To znamená, že můžete spustit dva moduly vaší aplikace a veškerý příchozí provoz bude rovnoměrně vyvážen mezi moduly související s touto službou.

A čtvrtý základní koncept - Ingress. Toto je služba, která běží na clusteru Kubernetes. Funguje jako externí load balancer, který přebírá všechny požadavky. Prostřednictvím rozhraní Kubernetes API může Ingress určit, kam mají být tyto požadavky odeslány. A dělá to velmi flexibilně. Můžete říci, že všechny požadavky na tohoto hostitele a takové a takové URL jsou odesílány této službě. A tyto požadavky přicházející na tento hostitel a na jinou adresu URL jsou odesílány do jiné služby.

Nejúžasnější věc z pohledu někoho, kdo vyvíjí aplikaci, je, že jste schopni to všechno spravovat sami. Nastavením Ingress config můžete posílat veškerý provoz přicházející do toho a takového API do samostatných kontejnerů, registrovaných například v Go. Ale tento provoz, který přichází do stejné domény, ale na jinou URL, je posílán do kontejnerů napsaných v PHP, kde je spousta logiky, ale nejsou moc rychlé.

Pokud porovnáme všechny tyto koncepty s Nomad, pak můžeme říci, že první tři koncepty jsou všechny dohromady Služba. A poslední koncept chybí v samotném Nomadovi. Použili jsme externí balancer: může to být haproxy, nginx, nginx + a tak dále. V případě krychle není nutné tento dodatečný pojem zvlášť představovat. Pokud se však podíváte na Ingress uvnitř, pak je to buď nginx, nebo haproxy, nebo traefik, ale jakoby zabudovaný do Kubernetes.

Všechny koncepty, které jsem popsal, jsou ve skutečnosti prostředky, které existují uvnitř clusteru Kubernetes. K jejich popisu v kostce se používá formát yaml, který je v případě Nomad čitelnější a známější než soubory HCL. Konstrukčně ale popisují totéž v případě např. lusku. Říkají - chci tam rozmístit takové a takové lusky, s takovými a takovými obrázky, v takovém a takovém množství.

Navíc jsme si uvědomili, že nechceme ručně vytvářet každý jednotlivý zdroj: nasazení, služby, Ingress a tak dále. Místo toho jsme chtěli popsat každý náš systém z hlediska Kubernetes během nasazení, abychom nemuseli ručně znovu vytvářet všechny potřebné závislosti prostředků ve správném pořadí. Helm byl vybrán jako takový systém, který nám to umožnil.

Základní pojmy v Helmu

Helm je správce balíčků pro Kubernetes. Je to velmi podobné tomu, jak pracují správci balíčků v programovacích jazycích. Umožňují uložit službu skládající se např. z deploymentu nginx, deployment php-fpm, configu pro Ingress, configmaps (to je entita, která umožňuje nastavit env a další parametry pro váš systém) ve formě tzv. tzv. grafy. Zároveň Helm běží nad Kubernetes. To znamená, že to není nějaký druh systému stojícího stranou, ale jen další služba běžící uvnitř krychle. Interagujete s ním přes jeho API pomocí příkazu konzoly. Jeho pohodlí a kouzlo spočívá v tom, že i když se kormidlo rozbije nebo jej odstraníte z clusteru, vaše služby nezmizí, protože kormidlo v podstatě slouží pouze ke spuštění systému. Za zdraví a stav služeb je dále odpovědný sám Kubernetes.

To jsme si také uvědomili normalizace, což jsme do té doby museli dělat sami prostřednictvím zavedení jinja do našich konfigurací, je jedním z hlavních rysů kormidla. Všechny konfigurace, které vytvoříte pro své systémy, jsou uloženy v helm jako šablony, trochu jako jinja, ale ve skutečnosti používají šablonu jazyka Go, ve kterém je helm napsán, stejně jako Kubernetes.

Helm k nám přidává několik dalších konceptů.

Graf je popis vaší služby. V jiných správcích balíčků by se to nazývalo bundle, bundle nebo podobně. Tady se tomu říká graf.

Hodnoty jsou proměnné, které chcete použít k sestavení svých konfigurací ze šablon.

Uvolnění. Pokaždé, když služba, která se nasadí pomocí kormidla, získá přírůstkovou verzi vydání. Helm si pamatuje, jaká byla konfigurace služby pro předchozí vydání, předloňský rok a tak dále. Pokud se tedy potřebujete vrátit zpět, stačí spustit příkaz zpětného volání helm a nasměrovat jej na předchozí verzi vydání. I když odpovídající konfigurace ve vašem úložišti není v době vrácení zpět k dispozici, helm si bude stále pamatovat, co to bylo, a vrátí váš systém do stavu, v jakém byl v předchozím vydání.

V případě, kdy používáme helm, se obvyklé konfigurace pro Kubernetes také promění v šablony, ve kterých je možné používat proměnné, funkce a aplikovat podmíněné příkazy. Můžete tak shromažďovat konfiguraci své služby v závislosti na prostředí.

V praxi jsme se rozhodli dělat věci trochu jinak než s Nomadem. Pokud Nomad uložil jak konfigurace nasazení, tak n-proměnné, které jsou potřeba k nasazení naší služby, v jednom úložišti, pak jsme se rozhodli je rozdělit do dvou samostatných úložišť. Úložiště „deploy“ ukládá pouze n-proměnných potřebných pro nasazení, zatímco úložiště „helm“ ukládá konfigurace nebo grafy.

co nám to dalo?

Nehledě na to, že v samotných konfiguračních souborech neukládáme žádná opravdu citlivá data. Například databázová hesla. Jsou uloženy jako tajné v Kubernetes, ale přesto existují oddělené věci, ke kterým nechceme zpřístupnit všechny v řadě. Přístup do úložiště „deploy“ je proto omezenější a úložiště „helm“ obsahuje pouze popis služby. Z tohoto důvodu může mít bezpečný přístup k většímu okruhu lidí.

Vzhledem k tomu, že máme nejen produkční, ale i další prostředí, můžeme díky tomuto oddělení znovu využít naše kormidelní grafy k nasazení služeb nejen do výroby, ale například i do QA prostředí. Dokonce je nasadit lokálně pomocí Minikube - to je taková věc pro místní spuštění Kubernetes.

Uvnitř každého úložiště jsme ponechali rozdělení na samostatné adresáře pro každou službu. To znamená, že uvnitř každého adresáře jsou šablony související s odpovídajícím diagramem a popisující prostředky, které je třeba nasadit ke spuštění našeho systému. V "deploy" úložišti jsme nechali jen závist. V tomto případě jsme nepoužili šablonování jinja, protože helm poskytuje šablonování hned po vybalení – to je jedna z jeho hlavních funkcí.

Opustili jsme skript nasazení – deploy.sh, který zjednodušuje a standardizuje spouštění pro nasazení pomocí helm. Pro každého, kdo chce nasadit, tedy rozhraní nasazení vypadá úplně stejně, jako tomu bylo v případě nasazení přes Nomad. Stejný deploy.sh, název vaší služby a místo, kde ji chcete nasadit. To způsobí vnitřní běh kormidla. Ten na oplátku shromažďuje konfigurace ze šablon, nahradí do nich potřebné soubory s hodnotami, poté je nasadí a spustí do Kubernetes.

Závěry

Zdá se, že služba Kubernetes je složitější než Nomad.

Zde přichází odchozí provoz v Ingress. Jedná se pouze o přední řadič, který přebírá všechny požadavky a následně je odesílá službám odpovídajícím údajům požadavku. Určuje je na základě konfigurací, které jsou součástí popisu vaší aplikace u kormidla a které si vývojáři sami nastaví. Služba na druhou stranu posílá požadavky do svých podů, tedy konkrétních kontejnerů, a vyrovnává příchozí provoz mezi všemi kontejnery, které této službě patří. A samozřejmě bychom neměli zapomínat, že od zabezpečení na úrovni sítě bychom neměli nikam přecházet. V clusteru Kubernetes tedy funguje segmentace, která je založena na značkování. Všechny služby mají určité značky, ke kterým jsou připojena přístupová práva služeb k určitým externím / interním zdrojům uvnitř nebo vně clusteru.

Při přechodu jsme viděli, že Kubernetes má všechny funkce Nomad, které jsme dosud používali, a také přidává spoustu nových věcí. Lze jej rozšířit pomocí pluginů a ve skutečnosti prostřednictvím vlastních typů zdrojů. To znamená, že máte příležitost nejen používat něco, co je dodáváno s Kubernetes ihned po vybalení, ale vytvořit si vlastní zdroj a službu, která bude číst váš zdroj. To vám dává více možností, jak rozšířit systém, aniž byste museli přeinstalovat Kubernetes a aniž byste museli provádět změny.

Příkladem takového použití je Prometheus, který provozujeme uvnitř clusteru Kubernetes. Aby mohla začít sbírat metriky z konkrétní služby, musíme do popisu služby přidat další typ zdroje, tzv. službu monitor. Prometheus, protože umí číst, je spuštěn v Kubernetes, vlastním typu zdroje, automaticky začne shromažďovat metriky z nového systému. Je to dost pohodlné.

První nasazení, které jsme provedli v Kubernetes, bylo v březnu 2018. A během této doby jsme s ním nikdy nezažili žádné problémy. Funguje celkem stabilně bez výraznějších chyb. Navíc ji můžeme dále rozšiřovat. K dnešnímu dni máme dostatek schopností, které má, a tempo vývoje Kubernetes se nám opravdu líbí. V současné době je v Kubernetes více než 3000 kontejnerů. Cluster zabírá několik uzlů. Zároveň je provozuschopný, stabilní a velmi dobře ovladatelný.

Zdroj: www.habr.com