🥇Kubernetes: open source vs. dodavatelský

Ahoj, jmenuji se Dmitrij Krasnov. Už více než pět let se zabývám administrací Kubernetes klastrů a budováním složitých mikroslužebných architektur. Na začátku tohoto roku jsme spustili službu pro správu Kubernetes klastrů založenou na Containerum. Využiji této příležitosti a povím, co vlastně Kubernetes je a jak se integrace s dodavatelem liší od open source.

Nejprve, co je to Kubernetes. Je to 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ě jej vyvinula Google a poté byla jako technologický příspěvek předána Cloud Native Computing Foundation, mezinárodní neziskové organizaci, která sdružuje přední světové vývojáře, koncové uživatele a dodavatele kontejnerových technologií.

Řídit velké množství kontejnerů

Teď si objasníme, co to vlastně jsou tyto kontejnery. Je to aplikace se vším jejím prostředím – převážně knihovnami, od kterých závisí funkce programu. Všechno toto je zabaleno do archivů a představuje se ve formě obrazu, který lze spouštět nezávisle na operačním systému, testovat a nejen to. Ale je tu problém — spravovat kontejnery na velkém počtu hostitelů je velmi obtížné. Proto byl Kubernetes vytvořen.

Obraz kontejneru představuje aplikaci plus její závislosti. Aplikace, její závislosti a obraz souborového systému OS se nacházejí v různých částech obrazu, takzvaných vrstvách. Vrstvy mohou být opětovně použity pro různé kontejnery. Například základní vrstvu Ubuntu může používat všechna aplikace ve společnosti. Při spouštění kontejnerů není potřeba uchovávat na hostiteli mnoho kopií jedné základní vrstvy. To umožňuje optimalizovat úložiště a doručování obrazů.

Když chceme spustit aplikaci z kontejneru, potřebné vrstvy se skládají na sebe a vytváří se overlayová souborová systém. Na vrch se nanáší vrstva pro zápis, která se při zastavení kontejneru odstraňuje. To zaručuje, že při spuštění kontejneru má aplikace vždy stejné prostředí, které nemůže být změněno. Zajišťuje to reprodukovatelnost prostředí na různých hostitelských operačních systémech. Ať už je to Ubuntu nebo CentOS, prostředí bude vždy stejné. Navíc je kontejner izolován od hostitele pomocí mechanismů zabudovaných v jádru Linuxu. Aplikace v kontejneru nevidí soubory, procesy hostitele a sousedních kontejnerů. Taková izolace aplikací od hostitelského OS poskytuje další úroveň bezpečnosti.

Pro správu kontejnerů na hostiteli existuje celá řada nástrojů. Nejpopulárnější z nich je Docker. Umožňuje zajistit kompletní životní cyklus práce s kontejnery. Funguje však pouze na jednom hostiteli. Při potřebě správy kontejnerů na mnoha hostitelích se Docker může stát noční můrou pro inženýry. Proto byl vytvořen Kubernetes.

Očekávanost Kubernetes je právě dána možností řídit skupiny kontejnerů na mnoha hostitelích jako by byly jednou jednotnou entitou. Popularitu systému zajišťuje možnost vybudovat DevOps neboli Development Operations, v nichž se Kubernetes používá k provozování procesů tohoto DevOps.

Obrázek 1. Schéma principu fungování Kubernetes

Úplná automatizace

DevOps v zásadě představuje automatizaci procesu vývoje. Zjednodušeně řečeno, vývojáři píší kód, který se nahrává do repozitáře. Poté může být tento kód automaticky sestaven do kontejneru se všemi knihovnami, testován a 'nasazen' na další fázi – Staging, a poté rovnou na Production.

Spolu s Kubernetes DevOps umožňuje automatizovat tento proces, aby probíhal prakticky bez účasti samotných vývojářů. Díky tomu se výrazně zrychluje sestavení, protože vývojář se tím nemusí zabývat na svém počítači — jednoduše napíše část kódu, pushne kód do repozitáře, po čemž se spustí pipeline, která může zahrnovat proces sestavení, testování a nasazení. A tak se to děje s každým commitem, takže testování probíhá nepřetržitě.

Použití kontejneru přitom umožňuje být si jistý, že celé prostředí této aplikace se dostane do produkce přesně v tom stavu, v jakém bylo testováno. To znamená, že nevzniknou problémy typu „v testu byly jiné verze, v produkci – další, a když jsme nasadili – všechno spadlo“. A protože dnes máme trend na mikroslužbovou architekturu, kdy místo jedné obrovské aplikace existují stovky malých, bude pro administraci jejich ručně třeba obrovský tým zaměstnanců. Proto používáme Kubernetes.

Výhody, výhody, výhody

Pokud hovoříme o výhodách Kubernetes jako platformy, má značné výhody z pohledu správy mikroslužbové architektury.

Správa mnoha replik. Nejdůležitější je správa kontejnerů na mnoha hostitelích. A co je ještě důležitější, správa mnoha replik aplikací v kontejnerech jako jedné entity. Díky tomu se inženýři nemusí starat o každý jednotlivý kontejner. Pokud jeden z kontejnerů spadne, Kubernetes to zjistí a znovu ho restartuje.
Klastrová síť. Kubernetes má také takzvanou klastrovou síť s vlastním adresním prostorem. Díky tomu má každý pod svou adresu. Pod pod je považována minimální strukturální jednotka clusteru, ve které se přímo spouštějí kontejnery. Navíc má Kubernetes funkci, která kombinuje load balancer a Service Discovery. To umožňuje zbavit se ručního řízení IP adres a svěřit tuto úlohu Kubernetes. A automatické health checky pomohou odhalit problémy a přesměrovat provoz na funkční pody.
Správa konfigurací. Při správě velkého množství aplikací je obtížné spravovat konfiguraci aplikací. Pro tento účel má Kubernetes speciální zdroje ConfigMapy. Ty umožňují centralizovaně uchovávat konfigurace a vkládat je do podů při spouštění aplikací. Takový mechanismus zajišťuje konzistenci konfigurace i ve stovkách replik aplikací.
Trvalé svazky. Kontejnery jsou v zásadě neměnné a při zastavení kontejneru budou všechna data zapsaná do souborového systému zničena. Některé aplikace však ukládají data přímo na disk. Pro ř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, může připojit trvalé úložiště do kontejnerů, blokové nebo souborové. Takové řešení umožňuje uchovávat data odděleně od pracovních uzlů, což je chrání při jejich případném selhání.
Vyrovnávač zátěže. I když v Kubernetes spravujeme abstraktní entity jako Deployment, StatefulSet atd., konečné kontejnery běží na běžných virtual machines nebo fyzických serverech. Ty nejsou dokonalé a mohou kdykoli selhat. Kubernetes to zjistí a přesměruje interní provoz na jiné repliky. Ale co s provozem, který přichází zvenčí? Pokud jednoduše nasměrujeme provoz na jeden z pracovních uzlů, co se stane v případě jeho selhání? Služba se stane nedostupnou. Pro řešení tohoto problému jsou v Kubernetes služby typu Vyrovnávač zátěže. Ty jsou určeny k automatické konfiguraci externího cloudového vyrovnávače zátěže na všechny pracovní uzly v клаsteru. Tento externí vyrovnávač směruje externí provoz na pracovní uzly a sám sleduje jejich stav. Pokud se jeden nebo více pracovních uzlů stanou nedostupnými, provoz je přesměrován na ostatní. To umožňuje vytvářet vysoce dostupné služby pomocí Kubernetes.

Nejlépe se Kubernetes projevuje právě při spuštění mikroslužebných architektur. Implementovat systém do klasické architektury je možné, ale je to bezvýznamné. Pokud aplikace nemůže běžet ve více replikách, jaký je pak smysl — v Kubernetes nebo ne?

Open source Kubernetes

Open source Kubernetes – skvělá věc: nastavíte a funguje to. Můžete ho nasadit na svých vlastních serverech, na vlastní infrastruktuře, nastavit master a workery, na kterých budou spuštěny všechny aplikace. A hlavně – to vše je zdarma. Nicméně existují určité nuance.

První – náročnost na znalosti a zkušenosti administrátorů a inženýrů, kteří to všechno budou nasazovat a udržovat. Protože klient získává plnou svobodu v klastru, nese odpovědnost za funkčnost klastru sám. A rozbít to je velmi snadné.
Druhý – absence integrací. Pokud spouštíte Kubernetes, aniž byste měli nějakou populární virtualizační platformu, nedostanete všechny výhody programu. Jako například využití Persistent Volumes a služeb Load balancer.

Obrázek 2. Architektura k8s

Kubernetes od dodavatele

Integrace s cloudovým poskytovatelem nabízí dvě možnosti:

Za prvé, člověk může jednoduše stisknout tlačítko „vytvořit klastr“ a získat již nakonfigurovaný a připravený k práci klastr.
Za druhé, dodavatel sám nasadí klastr a nakonfiguruje integraci s cloudem.

Jak to probíhá u nás. Inženýr, který spouští klastr, uvede, kolik potřebuje workerů a s jakými parametry (např. 5 workerů, každý s 10 CPU, 16 GB RAM a dejme tomu 100 GB disku). Po čemž získá přístup do již vytvořeného klastru. Přičemž workery, na kterých je zatížení spouštěno, plně náleží klientovi, ale celý management plane zůstává v oblasti zodpovědnosti dodavatele (pokud je služba poskytována podle modelu managed service).

Tato schéma však má své nevýhody. Protože management plane zůstává u dodavatele, dodavatel neposkytuje klientovi plný přístup, což snižuje flexibilitu při práci s Kubernetes. Někdy se stává, že klient chce přidat do Kubernetes nějakou specifickou funkčnost, například autentizaci přes LDAP, ale konfigurace management plane to neumožňuje.

Obrázek 3. Příklad klastru Kubernetes od cloudového poskytovatele

Co vybrat: open source nebo od dodavatele

Takže, open source Kubernetes nebo od dodavatele? Pokud zvolíte open source Kubernetes, máte svobodu dělat, co chcete. Ale existuje velké riziko, že si způsobíte problémy. S dodavatelem je to složitější, protože všechno je promyšlené a nastavené. Největší nevýhodou open source Kubernetes je požadavek na specialisty. Se dodavatelem se tato starost vyřeší, ale společnost se musí rozhodnout: platit vlastním odborníkům, nebo dodavateli.

No, výhody jsou jasné, nevýhody také známé. Jedno zůstává neměnné: Kubernetes řeší spoustu problémů, automatizuje správu mnoha kontejnerů. Jakou variantu zvolit, open source nebo dodavatelskou, rozhoduje každý sám.