Aplikace běží. Pak přijde aktualizace, selže server nebo několik oddělení potřebuje současně vyšší kapacitu. Kubernetes organizuje, kde kontejnery běží a jak se obnoví požadovaný provozní stav. Zda tím bude aplikace spolehlivější, závisí na celé architektuře.
Představme si interní objednávkový portál: zaměstnanci zadávají objednávky, rozhraní je předává do skladového systému a proces na pozadí vytváří dokumenty. Tyto úlohy mohou zajišťovat samostatné kontejnery. Kdo je spouští jednotlivě, musí koordinovat také aktualizace, restarty a rozmístění na strojích. Právě zde pomáhá orchestrace.
Požadovaný stav se stává základem provozu
V Kubernetes lze například určit, že mají běžet dvě instance webové aplikace v konkrétní verzi. Platforma tento požadovaný stav průběžně porovnává se skutečností. Deployment popisuje nasazení aplikace a prostřednictvím řadiče ReplicaSet spravuje její pody. Pokud instance chybí, řídicí mechanismus se pokusí zajistit náhradu.
To pomáhá i při aktualizacích: novou verzi lze nasazovat postupně. Musí tomu odpovídat zdroje, chování při spouštění i zvolená strategie aktualizace. Technicky úspěšné nasazení ale nedokládá, že byla objednávka správně zpracována. To zůstává úkolem aplikace a jejích testů.
Důležité pojmy na příkladu objednávkového portálu
- Kontejnerový obraz
- Zabalený základ aplikace včetně potřebných souborů a běhových součástí. Z tohoto obrazu se spouštějí kontejnery.
- Pod
- Nejmenší nasaditelná jednotka v Kubernetes. Obvykle obsahuje jeden aplikační kontejner; úzce související kontejnery mohou sdílet pod a mimo jiné jeho síťový jmenný prostor. Dvě kopie webové aplikace zpravidla znamenají dva pody.
- Uzel
- Stroj, na kterém běží pody. Uzel může být virtuální stroj i fyzický server. Kubernetes tedy může virtualizační vrstvu doplňovat, nemusí ji nahrazovat.
- Cluster a řídicí rovina
- Cluster propojuje řídicí mechanismus s uzly, které vykonávají úlohy. Řídicí rovina zahrnuje API server, databázi stavu, plánovač a řadiče. Na uzlech se o běh starají kubelet a kontejnerové běhové prostředí.
- Service
- Stabilní logický přístupový bod pro skupinu podů. Jejich adresy se při nahrazení mohou změnit. Service odděluje přístup od jednotlivých krátkodobých instancí.
Co se skutečně děje při výpadku
Pokud uzel selže, mohou být spravované pody znovu nasazeny na jiné vhodné uzly. Vyžaduje to rozpoznání výpadku, dostatečnou volnou kapacitu a přístup k potřebným datům. Druhá instance na stejném fyzickém hostiteli nechrání před jeho selháním. Také více serverů ve stejné napájecí nebo síťové doméně může sdílet bod selhání.
Pro náš objednávkový portál to znamená, že webové rozhraní lze případně rychle nahradit. Již spuštěná úloha vytvářející dokument ale musí být navržena tak, aby opakování nevytvořilo duplicitní fakturu či objednávku. Relace se při nahrazení instance nesmějí nekontrolovaně ztratit. Tyto vlastnosti závisejí na architektuře softwaru a připojených systémech.
Samotné tři servery proto ještě nejsou plánem dostupnosti. Řízení, aplikace, síť, úložiště a kapacitu zbývající po výpadku je nutné posuzovat společně. Totéž platí v cloudu nebo u spravované služby Kubernetes: konkrétní rozsah služby určuje, za co odpovídá poskytovatel a co zůstává firmě.
Trvalá data potřebují vlastní plán
Pody jsou nahraditelné. Firemní data proto nesmějí existovat pouze v zapisovatelné části souborového systému kontejneru. Kubernetes může připojit trvalé úložiště pomocí PersistentVolume a odpovídajících požadavků PersistentVolumeClaim. StorageClass popisuje, jak lze vhodné úložiště poskytovat.
Tyto objekty nezajišťují automaticky odolnost samotného úložiště. Lokální disk zůstává vázaný na svou infrastrukturu; externí úložná služba má vlastní výkonnostní a poruchové charakteristiky. Vhodným řešením může být i databáze mimo cluster. Rozhodují podpora aplikace, konzistence dat, přístupové cesty a dohodnutý postup obnovy.
Pro portál proto samostatně stanovíme, jak dlouho může být nedostupný, jaká ztráta dat je přijatelná a jak se vyzkouší obnova. Cluster, který spolehlivě rozšíří omylem provedené smazání do všech instancí, nenahrazuje zálohu. Více o zálohování a obnově.
Kdy se dodatečná infrastruktura vyplatí
Kubernetes je zajímavý, pokud se pravidelně aktualizuje více aplikací, je potřeba opakovatelné nasazování nebo cílené rozdělování úloh mezi dostupné stroje. Současně přináší úkoly kolem aktualizací platformy, správy přístupů, sítě, úložiště a monitoringu.
Pro jednu stabilní aplikaci může být ekonomicky vhodnější řádně udržovaný server s Docker Compose nebo běžný virtuální stroj. Rozhodování má vycházet z požadovaného provozu: jaké přerušení je přijatelné? Jak často přicházejí změny? Kdo prostředí rozumí a dokáže je při problému obnovit?
Smysluplný pilot má ověřitelné cíle
- Vyzkoušet reprezentativní firemní proces s realistickým objemem dat a bez produkčních zákaznických dat.
- Nacvičit aktualizaci včetně plánovaného návratu. Změny databázového schématu posoudit samostatně.
- Za řízených podmínek otestovat výpadek jedné instance a jedné plánované infrastrukturní součásti.
- Obnovit zálohu do samostatného testovacího prostředí a otevřením ověřit použitelnost firemních dat.
- Přidělit konkrétní odpovědnost za alarmy, údržbu platformy a aplikaci.
DAXS pomáhá s posouzením aplikace a výběrem vhodné infrastruktury i s realizací a dohodnutým provozem. Praktickým prvním krokem je úvodní posouzení s konkrétním případem použití a jasnými podmínkami přijetí.
Zdroje: Kubernetes: úloha a hranice platformy · Součásti clusteru · Pody a jejich životní cyklus · Deployment a aktualizace · Service · Trvalé úložiště · Plánování produkčních prostředí
