Kubernetes prakticky: jak funguje a jak ho založit s AKS
Minule jsem popisoval proč kontejnery, proč Kubernetes a proč v Azure. Dnes se podíváme na základní principy Kubernetes a nasadíme si ho v plně spravované verzi AKS v Azure.
Základní architektura
Kubernetes je postaven na dvou rolích – master a agent. Ty první mají na starost control plane a management plane celého clusteru. Je na nich etcd jako distribuovaná databáze, API komponenty, scheduler a jednotlivé kontrolery. Tuto vrstvu v AKS nemusíte řešit a ani do ni nemáte přístup – je součástí spravované služby a to dokonce zdarma.
Agent jsou potom nody (typicky VMka), na kterých se odehrává control plane a data plane, čili běží na nich vaše kontejnery. Jde v zásadě o kontejnerové hostitele s nějakým runtime jako je docker, rkt nebo runc. Vedle toho jsou řídící služby Kubernetes, které hostitele ovládají a komunikují s mastery – kubelet jako ovládací prvek (řídí vytváření Podů apod.) a kube-proxy (komunikační data plane systém a service discovery, tedy v zásadě síťová koponenta provádějící různá směrování).
Desired state v Kubernetes
Kubernetes je perfektním příkladem použití desired state principů. Základem je databáze požadovaného stavu, která je technologicky řešena v etcd – distribuované databázi pro distribuovaný konsenzus. Vaše interakce se systémem spočívá v deklaraci cílového stavu zapsaného nejčastěji jako YAML datová struktura (šablona). Kubernetes vám vrátí OK a změnu si zaznamená. V systému neustále dochází ke kontrolám zda skutečný stav odpovídá požadovanému a pokud ne, sjedná Kubernetes nápravu.
Vezměme například situaci, kdy požadujete vytvoření 3 instancí vašeho kontejneru. Po zadání požadavku přijde Kubernetes na to, že požadovaný stav jsou 3 instance, ale aktuálně jich běží 0. Sjedná tedy nápravu a nastartuje 3 instance v clusteru. Pak jeden agent node spadne a Kubernetes rychle přijde na to, že požadované instance jsou 3 a běží jen 2 – zajistí tedy spuštění třetí instance na jiném nodu.
Labely místo hierarchie
Kubernetes krásně ukazuje volnou provázanost a modularitu místo klasického hierarchického modelu. To vás zbavuje nutnosti vytvářet věci ve správném pořadí a značně zjednodušuje systému život. Tak například pokud potřebujete seskupit několik běžících kontejnerů do jedné služby (třeba s jednou IP a balancovaným provozem) neděláte to tak, že vytvoříte objekt služby a do něj zařadíte kontejnery (takový foreign key styl v relační tabulce). V Kubernetes přiřadíte kontejnerům patřícím k této službě libovolný label, tedy jeden a více key-value párů – cokoli vás napadne, cokoli vám dává smysl. V definici služby říkáte, že do ní patří všechny kontejnery, které mají určité key-value páry v popisu. Je tedy jedno co vytvoříte dřív a máte obrovskou míru svobody. Všechno je desired state popis, tedy Kubernetes pravidelně kontroluje, jaké kontejnery službě patří. Velmi podobné je to třeba s labely pro vaše nody (členy clusteru) a další součásti systému … však uvidíte.