Kubernetes

Kubernetes definuje základní sadu stavebních bloků, které společně poskytují mechanismy pro nasazování, udržování a škálování aplikací na základě CPU, paměti nebo vlastních metrik. Jednotlivé bloky jsou volně spojené a rozšiřitelné, čímž mohou být upraveny pro různá aplikační vytížení. Tuto rozšiřitelnost ve velké části poskytuje rozhraní Kubernetes API, které používají interní komponenty i rozšíření a kontejnery běžící na Kubernetes. Chápáním výpočetních a úložných komponent jakožto objektů pak má platforma možnost je kontrolovat a ovládat.

Kubernetes vychází z Master/Slave architektury. Komponenty Kubernetes lze rozdělit na ty, které spravují jednotlivý uzel, a ty, které jsou součástí řídicí roviny.

Kubernetes Master je hlavní řídicí jednotkou clusteru, která spravuje vytížení komponent a řídí komunikaci napříč systémem. Řídicí rovina Kubernetes se skládá z různých komponent, z nichž každá má svůj vlastní proces, který může běžet jak na jednom hlavním uzlu, tak na více hlavních zařízeních podporujících clustery s vysokou dostupností. Jednotlivé součásti řídicí roviny Kubernetes jsou následující:

• etcd: etcd je trvalé, lehké, distribuované úložiště klíčů a hodnot vyvinuté společností CoreOS, které spolehlivě ukládá konfigurační data clusterů, což představuje celkový stav klastru v daném okamžiku. Etcd je systém, který upřednostňuje konzistenci před dostupností v případě síťového oddílu. Tato konzistence je zásadní pro správné plánování a provoz služeb. Server Kubernetes API používá rozhraní API hodinek etcd ke sledování clusterů a zavádění důležitých změn konfigurace nebo jednoduše k obnovení jakýchkoli odchylek stavu clusteru zpět na to, co bylo deklarováno při jeho vytvoření. Například, je-li při vytvoření konkrétního uzlu stanoveno, že musí být spuštěny tři instance podu, je tato skutečnost uložena v etcd. Pokud bude zjištěno, že etcd má uloženou konfiguraci uzlu se třemi běžícími instancemi a spuštěny jsou jen dvě, naplánuje platforma vytvoření dodatečné instance daného podu.

• Server API: Server API je klíčová součást a slouží rozhraní API Kubernetes pomocí JSON přes HTTP, který poskytuje Kubernetes interní i externí rozhraní. Server API zpracovává a ověřuje požadavky REST a aktualizuje stav objektů API v etcd, čímž umožňuje klientům konfigurovat úlohy a kontejnery napříč existujícími uzly.

• Plánovač (anglicky Scheduler): Plánovač je přídavná komponenta, která na základě dostupnosti prostředků vybere, na kterém uzlu běží neplánovaný pod. Plánovač sleduje využití prostředků v každém uzlu, aby zajistil, že pracovní zátěž nebude naplánována nad rámec dostupných zdrojů. Z tohoto důvodu musí plánovač znát požadavky na zdroje, dostupnost zdrojů a další omezení a směrnice poskytované uživateli, jako je kvalita služby, požadavky na podobnost či odlišnost, lokalita dat atd. Úlohou plánovače je v zásadě sladit „nabídku“ zdroje s „poptávkou“ pracovní zátěže.

• Správce řadiče (anglicky Controller Manager): Řadič je slučovací smyčka, která řídí skutečný stav clusteru směrem k jeho požadovanému stavu a komunikuje se serverem API za účelem vytváření, aktualizace a mazání prostředků, které spravuje (pody, koncové body služby atd.). Správce řadičů je proces, který spravuje sadu základních řadičů Kubernetes. Jedním druhem řadiče je řadič replikace, který zpracovává replikaci a změnu měřítka spuštěním zadaného počtu kopií modulu v clusteru. Zpracovává také vytváření náhradních podů, pokud selže základní uzel. Mezi další řadiče, které jsou součástí základního systému Kubernetes, patří řadič DaemonSet pro spuštění přesně jednoho podu na každém počítači (nebo nějaké podmnožině strojů) a řadič úloh pro spouštění podů, které běží až do konce, např. jako součást dávkové úlohy. Sada podů, které řadič spravuje, je určena selektory popisků, které jsou součástí definice řadiče.

Uzel (anglicky Node), známý také jako Worker nebo Minion, je stroj, kde jsou nasazeny kontejnery. Každý uzel v clusteru musí obsahovat prostředí pro běh kontejneru, například Docker, stejně tak i níže uvedené komponenty:

• Kubelet: Kubelet je zodpovědný za provozní stav každého uzlu a zajišťuje, že všechny kontejnery v uzlu jsou v pořádku. Stará se o spouštění, zastavování a údržbu aplikačních kontejnerů uspořádaných do podů podle pokynů v řídicí rovině. Kubelet monitoruje stav podu a zjistí-li, že pod není v požadovaném stavu, nasadí znovu pod do stejného uzlu. Stav uzlu je kontrolován každých pár sekund prostřednictvím prezenčních zpráv do Masteru. Jakmile Master detekuje selhání uzlu, kontroluje replikační řadič tuto změnu stavu a spustí pody na dalších zdravých uzlech.

• Kube-proxy: Kube-proxy je implementace síťového proxy a nástroje pro vyrovnávání zatížení, a podporuje abstrakci služby spolu s dalšími síťovými operacemi. Je zodpovědný za směrování provozu do příslušného kontejneru na základě IP a čísla portu příchozího požadavku.

• Runtime kontejneru: Kontejner je umístěn uvnitř podu. Kontejner je nejnižší úroveň mikroslužby, která obsahuje běžící aplikaci, knihovny a jejich závislosti. Kontejnery mohou se světem komunikovat prostřednictvím externí adresy IP.

Základní plánovací jednotkou v Kubernetes je pod (česky "Lusk"). Pod se skládá z jednoho nebo více kontejnerů, u nichž je zaručeno společné umístění ve stejném uzlu.

Každému modulu v Kubernetes je v clusteru přiřazena jedinečná adresa IP, která aplikacím umožňuje používat porty bez rizika konfliktu. V rámci podu se mohou všechny kontejnery navzájem odkazovat na localhost, ale kontejner v jednom podu nemá způsob, jak přímo adresovat jiný kontejner v jiném podu; k tomu musí použít IP adresu daného podu. Vývojář aplikace by nikdy neměl používat IP adresu podu k odkazování / vyvolání funkce v jiném podu, protože jejich IP adresy jsou dynamické – konkrétnímu podu, na který odkazují, může být při restartu přiřazena jiná IP adresa. Místo toho by měli použít odkaz na službu, která obsahuje odkaz na zvolený pod.

Pod může definovat svazek, například adresář místního disku nebo síťový disk, a vystavit jej kontejnerům uvnitř podu. Pody lze spravovat ručně prostřednictvím rozhraní Kubernetes API nebo jejich správu lze delegovat na řadič. Takové svazky jsou také základem pro funkce Kubernetes nástroje ConfigMaps (pro zajištění přístupu ke konfiguraci prostřednictvím souborového systému viditelného pro kontejner) a Secrets (pro poskytnutí přístupu k pověřením potřebným pro bezpečný přístup ke vzdáleným prostředkům).

Účelem sady replik je udržovat stabilní sadu replik podů spuštěných v daném okamžiku. Jako takový se často používá k zajištění dostupnosti určitého počtu identických podů.

Sadu replik lze také označit za mechanismus seskupování, který umožňuje Kubernetes udržovat počet instancí deklarovaných pro daný pod. Definice sady replik používá selektor, jehož vyhodnocení má za následek identifikaci všech podů, které jsou k němu přidruženy.

Služba je sada podů, které fungují společně, například jako jedna úroveň vícevrstvé aplikace. Sada podů, které tvoří službu, je definována selektorem štítků. Kubernetes poskytuje dva režimy zjišťování služeb, pomocí proměnných prostředí nebo pomocí Kubernetes DNS. Service discovery přiřadí službě stabilní IP adresu a název DNS, přičemž vyvažuje zatížení podů round-robin způsobem. Ve výchozím nastavení je služba vystavena uvnitř clusteru (např. back-endové pody mohou být seskupeny do služby, přičemž požadavky z front-endových podů jsou mezi nimi vyváženy), ale služba může být vystavena i mimo cluster (např. aby se klienti dostali k front-end podům).