Ahoj, jmenuji se Dmitrij Krasnov. Více než pět let spravuji clustery Kubernetes a stavím komplexní architektury mikroslužeb. Na začátku letošního roku jsme spustili službu pro správu clusterů Kubernetes na bázi Containeru. Při této příležitosti vám řeknu, co je Kubernetes a jak se integrace s dodavatelem liší od open source.
Pro začátek, co je . Jedná se o systém pro správu kontejnerů na velkém počtu hostitelů. Z řečtiny se mimochodem překládá jako „pilot“ nebo „kormidelník“. Původně vyvinutý společností Google a poté darovaný jako technologický příspěvek nadaci Cloud Native Computing Foundation, mezinárodní neziskové organizaci, která sdružuje přední světové vývojáře, koncové uživatele a poskytovatele kontejnerových technologií.
Spravujte velké množství kontejnerů
Nyní pojďme zjistit, jaké druhy kontejnerů to jsou. Jedná se o aplikaci s celým svým prostředím - hlavně knihovnami, na kterých je program závislý. To vše je zabaleno v archivech a prezentováno ve formě obrazu, který lze spustit bez ohledu na operační systém, testovat a další. Je tu ale problém – správa kontejnerů na velkém počtu hostitelů je velmi obtížná. Proto vznikl Kubernetes.
Obrázek kontejneru představuje aplikaci plus její závislosti. Aplikace, její závislosti a obraz souborového systému OS jsou umístěny v různých částech obrazu, tzv. vrstvách. Vrstvy lze znovu použít pro různé nádoby. Všechny aplikace ve společnosti mohou například používat základní vrstvu Ubuntu. Při spouštění kontejnerů není potřeba ukládat více kopií jedné základní vrstvy na hostiteli. To vám umožní optimalizovat ukládání a doručování snímků.
Když chceme spustit aplikaci z kontejneru, potřebné vrstvy se na sebe navrství a vytvoří se překryvný souborový systém. Nahoře je umístěna záznamová vrstva, která se odstraní, když se nádoba zastaví. Tím je zajištěno, že při spuštění kontejneru bude mít aplikace vždy stejné prostředí, které nelze změnit. To zaručuje reprodukovatelnost prostředí na různých hostitelských OS. Ať už jde o Ubuntu nebo CentOS, prostředí bude vždy stejné. Kromě toho je kontejner izolován od hostitele pomocí mechanismů zabudovaných do jádra Linuxu. Aplikace v kontejneru nevidí soubory, procesy hostitele a sousední kontejnery. Tato izolace aplikací od hostitelského OS poskytuje další vrstvu zabezpečení.
Pro správu kontejnerů na hostiteli je k dispozici mnoho nástrojů. Nejoblíbenější z nich je Docker. Umožňuje vám zajistit celý životní cyklus kontejnerů. Funguje však pouze na jednom hostiteli. Pokud potřebujete spravovat kontejnery na více hostitelích, Docker může inženýrům udělat ze života peklo. Proto vznikl Kubernetes.
Poptávka po Kubernetes je právě kvůli schopnosti spravovat skupiny kontejnerů na více hostitelích jako nějaký druh jediné entity. Popularita systému poskytuje možnost vybudovat DevOps nebo Development Operations, ve kterých Kubernetes slouží ke spuštění procesů právě tohoto DevOps.
Obrázek 1. Schematické znázornění toho, jak Kubernetes funguje
Plná automatizace
DevOps je v podstatě automatizace vývojového procesu. Zhruba řečeno, vývojáři píší kód, který je nahrán do úložiště. Poté lze tento kód automaticky okamžitě shromáždit do kontejneru se všemi knihovnami, otestovat a „zavést“ do další fáze - Staging a poté okamžitě do výroby.
Spolu s Kubernetes vám DevOps umožňuje automatizovat tento proces tak, aby probíhal prakticky bez účasti samotných vývojářů. Díky tomu je sestavení výrazně rychlejší, protože vývojář to nemusí dělat na svém počítači - jednoduše napíše kus kódu, vloží kód do úložiště, poté se spustí pipeline, která může zahrnovat proces budování, testování a zavádění. A to se děje s každým potvrzením, takže testování probíhá nepřetržitě.
Použití kontejneru zároveň umožňuje mít jistotu, že celé prostředí tohoto programu bude uvolněno do výroby přesně v té podobě, v jaké bylo testováno. To znamená, že nebudou žádné problémy typu „některé verze byly v testu, jiné ve výrobě, ale když jsme je nainstalovali, všechno spadlo“. A protože dnes máme trend k architektuře mikroslužeb, kdy místo jedné obrovské aplikace existují stovky malých, k jejich ruční správě bude potřeba obrovský štáb zaměstnanců. Proto používáme Kubernetes.
Pro, pro, pro
Pokud mluvíme o výhodách Kubernetes jako platformy, pak má významné výhody z pohledu správy architektury mikroslužeb.
- Správa více replik. Nejdůležitější je správa kontejnerů na více hostitelích. A co je důležitější, spravujte více replik aplikací v kontejnerech jako jednu entitu. Díky tomu se inženýři nemusí starat o každý jednotlivý kontejner. Pokud některý z kontejnerů selže, Kubernetes to uvidí a restartuje jej znovu.
- Clusterová síť. Kubernetes má také tzv. clusterovou síť s vlastním adresním prostorem. Díky tomu má každý pod svou adresu. Subpod je chápán jako minimální konstrukční jednotka clusteru, ve kterém jsou kontejnery přímo vypouštěny. Kromě toho má Kubernetes funkcionalitu, která kombinuje nástroj pro vyrovnávání zatížení a zjišťování služeb. To vám umožní zbavit se ruční správy IP adres a delegovat tento úkol na Kubernetes. A automatické kontroly stavu pomohou odhalit problémy a přesměrovat provoz na pracovní moduly.
- Správa konfigurace. Při správě velkého počtu aplikací je obtížné spravovat konfiguraci aplikací. Pro tento účel má Kubernetes speciální prostředky ConfigMap. Umožňují vám centrálně ukládat konfigurace a vystavovat je modulům při spouštění aplikací. Tento mechanismus nám umožňuje zaručit konzistenci konfigurace v minimálně deseti nebo stovce aplikačních replik.
- Trvalé svazky. Kontejnery jsou ze své podstaty neměnné a když je kontejner zastaven, všechna data zapsaná do systému souborů budou zničena. Některé aplikace ale ukládají data přímo na disk. K vyřešení tohoto problému má Kubernetes funkci správy diskového úložiště - Trvalé svazky. Tento mechanismus využívá externí úložiště pro data a může přenášet trvalé úložiště, blok nebo soubor, do kontejnerů. Toto řešení umožňuje ukládat data odděleně od pracovníků, což je šetří, pokud tito pracovníci selžou.
- Load Balancer. I když v Kubernetes spravujeme abstraktní entity jako Deployment, StatefulSet atd., kontejnery nakonec běží na běžných virtuálních strojích nebo hardwarových serverech. Nejsou dokonalé a mohou kdykoli spadnout. Kubernetes to uvidí a přesměruje interní provoz na jiné repliky. Co ale dělat s dopravou, která přichází zvenčí? Pokud jednoduše nasměrujete provoz na jednoho z pracovníků, pokud dojde k jeho zhroucení, služba bude nedostupná. K vyřešení tohoto problému má Kubernetes služby jako Load Balancer. Jsou navrženy tak, aby automaticky konfigurovaly externí cloud balancer pro všechny pracovníky v clusteru. Tento externí balancer směruje externí provoz na pracovníky a sám monitoruje jejich stav. Pokud se jeden nebo více pracovníků stane nedostupným, provoz je přesměrován na ostatní. To vám umožňuje vytvářet vysoce dostupné služby pomocí Kubernetes.
Kubernetes funguje nejlépe při spouštění architektur mikroslužeb. Je možné implementovat systém do klasické architektury, ale je to zbytečné. Pokud aplikace nemůže běžet na více replikách, jaký je v tom rozdíl - v Kubernetes nebo ne?
Open source Kubernetes
Open source Kubernetes je skvělá věc: nainstaloval jsem ho a funguje. Můžete jej nasadit na vlastní hardwarové servery, na vlastní infrastrukturu, instalovat mastery a workery, na kterých poběží všechny aplikace. A co je nejdůležitější, to vše je zdarma. Existují však nuance.
- Prvním je požadavek na znalosti a zkušenosti administrátorů a inženýrů, kteří toto vše nasadí a podpoří. Vzhledem k tomu, že klient získává úplnou svobodu jednání v clusteru, je sám odpovědný za výkon clusteru. A tady je velmi snadné všechno rozbít.
- Druhým je nedostatek integrace. Pokud Kubernetes provozujete bez oblíbené virtualizační platformy, nezískáte všechny výhody programu. Například pomocí služeb Trvalé svazky a Vyrovnávání zatížení.
Obrázek 2. Architektura k8s
Kubernetes od dodavatele
Integrace s poskytovatelem cloudu nabízí dvě možnosti:
- Za prvé, uživatel může jednoduše kliknout na tlačítko „vytvořit cluster“ a získat cluster již nakonfigurovaný a připravený k použití.
- Za druhé, dodavatel sám nainstaluje cluster a nastaví integraci s cloudem.
Jak se to děje tady. Technik, který spouští cluster, určí, kolik pracovníků potřebuje a s jakými parametry (například 5 pracovníků, každý s 10 CPU, 16 GB RAM a řekněme 100 GB disku). Poté získá přístup k již vytvořenému shluku. V tomto případě jsou pracovníci, na kterých je zátěž spuštěna, zcela převedeni na klienta, ale celá rovina správy zůstává v odpovědnosti dodavatele (pokud je služba poskytována podle modelu spravované služby).
Toto schéma má však své nevýhody. Vzhledem k tomu, že rovina správy zůstává u dodavatele, dodavatel neposkytuje úplný přístup ke klientovi, což snižuje flexibilitu při práci s Kubernetes. Občas se stane, že klient chce do Kubernetes přidat nějakou konkrétní funkcionalitu, například autentizaci přes LDAP, ale konfigurace manažerské roviny to neumožňuje.
Obrázek 3. Příklad clusteru Kubernetes od poskytovatele cloudu
Co si vybrat: open source nebo prodejce
Je tedy Kubernetes open source nebo specifický pro dodavatele? Pokud vezmeme open source Kubernetes, tak si s tím uživatel dělá, co chce. Ale je tu velká šance, že se střelíte do nohy. S dodavatelem je to složitější, protože vše je promyšlené a nakonfigurované pro firmu. Největší nevýhodou open source Kubernetes je požadavek na specialisty. S volbou dodavatele se společnost této bolesti zbaví, ale bude se muset rozhodnout, zda zaplatí svým specialistům nebo prodejci.
No, klady jsou zřejmé, zápory jsou také známé. Jedna věc je konstantní: Kubernetes řeší spoustu problémů automatizací správy mnoha kontejnerů. A který si vybrat, open source nebo prodejce – každý se rozhoduje sám.
Článek připravil Dmitrij Krasnov, přední architekt služby Containerum poskytovatele #CloudMTS
Zdroj: www.habr.com