Jak funguje Kubernetes
Úspěšně nakonfigurovaná instalace Kubernetes závisí na solidním porozumění architektury systému Kubernetes. Tady se podíváte na všechny komponenty, které tvoří instalaci Kubernetes.
Co je počítačový cluster?
Cluster je sada počítačů, které nakonfigurujete tak, aby fungovaly společně a jevily se jako jeden systém. Počítače nakonfigurované v clusteru zpracovávají stejné druhy úloh. Například budou všechny hostovat weby či rozhraní API nebo provádět výpočetně náročné úlohy.
Cluster používá centralizovaný software, který odpovídá za plánování a řízení těchto úloh. Počítače v clusteru, které dokážou spouštět úlohy, se nazývají uzly a počítače, na kterých běží plánovací software, se nazývají hlavní uzly nebo řídicí roviny.
Architektura Kubernetes
Připomeňme si, že orchestrátor je systém, který nasazuje a spravuje aplikace. Také jste se dozvěděli, že cluster je sada počítačů, které spolupracují a jsou považovány za jeden systém. Kubernetes se používá jako software pro orchestraci a cluster, abyste mohli nasazovat aplikace a reagovat na změny v poptávce po výpočetních prostředcích.
Cluster Kubernetes obsahuje alespoň jednu hlavní rovinu a nejméně jeden běžný uzel. Řídicí roviny a instance běžných uzlů můžou být fyzická zařízení, virtuální počítače nebo instance v cloudu. Výchozí hostitelský operační systém v Kubernetes je Linux, který standardně podporuje linuxové úlohy.
Úlohy Microsoftu můžete také spouštět pomocí Windows Serveru 2019 nebo novějšího na uzlech clusteru. Předpokládejme například, že služba zpracování dat v aplikaci pro sledování dronů je napsaná jako aplikace .NET 4.5, která používá konkrétní volání rozhraní API operačního systému Windows. Tato služba se dá spustit jen na uzlech, na kterých běží operační systém Windows Server.
Teď se podrobněji podíváme na řídicí roviny i pracovní uzly i na software, který běží na jednotlivých uzlech. Při instalaci Kubernetes je dobré rozumět rolím jednotlivých komponent a tomu, kde v clusteru běží která komponenta.
Řídicí rovina Kubernetes
Na řídicí rovině Kubernetes běží v clusteru Kubernetes kolekce služeb, které v Kubernetes spravují funkce orchestrace.
Při zkoumání funkcí Kubernetes během výuky je v testovacím prostředí vhodné použít jednu řídicí rovinu. V produkčním a cloudovém nasazení, jako je Azure Kubernetes Service (AKS), ale zjistíte, že upřednostňovanou konfigurací je nasazení s vysokou dostupností se třemi až pěti replikovanými řídicími rovinami.
Poznámka:
Skutečnost, že v řídicí rovině běží specifický software pro uchovávání stavu clusteru, nevylučuje možnost spouštět v ní i jiné výpočetní úlohy. Obvykle je však vhodné v řídicí rovině vyloučit spouštění méně důležitých úloh a úloh uživatelských aplikací.
Uzel Kubernetes
Uzel v clusteru Kubernetes je místo, kde se spouštějí výpočetní úlohy. Každý uzel komunikuje s řídicí rovinou přes server rozhraní API, kterému poskytuje informace o změnách stavu na uzlu.
Služby, které běží v řídicí rovině
Kubernetes využívá několik služeb správy, které se spouštějí v řídicí rovině. Tyto služby spravují aspekty, jako je komunikace komponent clusteru, plánování úloh a trvalost stavu clusteru.
Následující služby tvoří řídicí rovinu clusteru Kubernetes:
- Server rozhraní API
- Záložní úložiště
- Scheduler
- Správce kontroleru
- Správce cloudového kontroleru
Co je server rozhraní API?
Server rozhraní API si můžete představit jako front-end řídicí rovinu clusteru Kubernetes. Veškerou komunikaci mezi komponentami v Kubernetes zprostředkovává právě toto rozhraní API.
Jako uživatel například používáte aplikaci kubectl příkazového řádku, která umožňuje spouštět příkazy na serveru rozhraní API clusteru Kubernetes. Komponenta, která toto rozhraní API nabízí, se nazývá kube-apiserver, a můžete nasadit několik instancí této komponenty, aby se v clusteru podporovalo škálování.
Toto rozhraní API zpřístupní rozhraní RESTful API, které můžete použít k odesílání příkazů nebo konfiguračních souborů založených na jazyce YAML. V programovacích jazycích je YAML lidsky čitelný standard pro serializaci dat. Pomocí souborů YAML definujete zamýšlený stav všech objektů v clusteru Kubernetes.
Předpokládejme například, že chcete navýšit počet instancí aplikace v clusteru. Nový stav definujete pomocí souboru založeného na YAML a tento soubor odešlete na server rozhraní API. Server rozhraní API ověří konfiguraci, uloží ji do clusteru a nakonec provede nakonfigurované zvýšení nasazení aplikací.
Co je záložní úložiště?
Záložní úložiště je trvalé úložiště, ve kterém cluster Kubernetes ukládá dokončenou konfiguraci. Kubernetes používá vysoce dostupné, distribuované a spolehlivé úložiště párů klíč-hodnota s názvem etcd. Toto úložiště párů klíč-hodnota uchovává aktuální i požadovaný stav všech objektů v clusteru.
V produkčním clusteru Kubernetes je oficiální doporučení Kubernetes mít tři až pět replikovaných instancí databáze etcd, aby byla zajištěná vysoká dostupnost.
Poznámka:
etcd nezodpovídá za zálohování dat. Je vaší zodpovědností zajistit pro zálohování dat etcd účinný plán zálohování.
Co je plánovač?
Plánovač je komponenta odpovědná za přiřazování úloh na všechny uzly. Plánovač v clusteru sleduje nově vytvořené kontejnery a přiřazuje je uzlům.
Co je správce kontroleru?
Správce kontroleru spouští a monitoruje kontrolery nakonfigurované pro cluster pomocí serveru rozhraní API.
Kubernetes používá kontrolery ke sledování stavů objektů v clusteru. Každý kontroler běží v neterminační smyčce při sledování událostí v clusteru a odpovídá na ně. Existují například kontrolery pro monitorování uzlů, kontejnerů a koncových bodů.
Kontroler komunikuje se serverem rozhraní API za účelem určení stavu objektu. Pokud se aktuální stav liší od požadovaného stavu objektu, řadič provede akci, která zajistí požadovaný stav.
Předpokládejme, že jeden ze tří kontejnerů spuštěných v clusteru přestane reagovat a selže. V takovém případě se kontroler rozhodne, jestli je nutné spouštět nové kontejnery, aby byla zajištěná nepřetržitá dostupnost aplikací. Pokud je žádoucím stavem mít v kteroukoliv chvíli spuštěné tři kontejnery, naplánuje se spuštění nového kontejneru.
Co je správce cloudového kontroleru?
Správce cloudového kontroleru se integruje se základními cloudovými technologiemi v clusteru, když cluster běží v cloudovém prostředí. Tyto služby můžou být například nástroje pro vyrovnávání zatížení, fronty a úložiště.
Služby běžící v uzlu
Na uzlu Kubernetes běží několik služeb, které řídí způsob spouštění úloh.
Na uzlu Kubernetes běží následující služby:
- Kubelet
- Kube-proxy
- Modul runtime kontejneru
Co je kubelet?
Kubelet je agent, který běží na každém uzlu v clusteru a monitoruje žádosti o práci ze serveru rozhraní API. Zajišťuje, že požadovaná jednotka práce je spuštěná a v pořádku.
Kubelet monitoruje uzly a zajišťuje, že kontejnery naplánované na jednotlivých uzlech poběží podle očekávání. Kubelet spravuje pouze kontejnery, které Kubernetes vytvoří. Neodpovídá za nové naplánování spuštění úlohy na jiných uzlech, pokud aktuální uzel nemůže úlohu spustit.
Co je kube-proxy?
Komponenta kube-proxy odpovídá za místní síť clusteru a běží na všech uzlech. Zajišťuje, aby každý uzel měl jedinečnou IP adresu. Navíc implementuje pravidla pro zpracovávání směrování a vyrovnávání zatížení provozem pomocí iptables a IPVS.
Tato služba proxy sama o sobě neposkytuje služby DNS. Doporučuje se využít doplněk clusteru DNS, který se zakládá na CoreDNS a který se instaluje ve výchozím nastavení.
Co je modul runtime kontejneru?
Modul runtime kontejneru je základní software, na kterém v clusteru Kubernetes běží kontejnery. Tento modul runtime odpovídá za načítání, spouštění a zastavování imagí kontejnerů. Kubernetes podporuje několik modulů runtime kontejneru, včetně dockeru, kontejneru, rkt, CRI-O a frakti. Podpora mnoha typů modulů runtime kontejnerů se zakládá na rozhraní CRI (Container Runtime Interface). CRI je návrh modulu plug-in, který umožňuje kubeletu komunikovat pomocí dostupného modulu runtime kontejneru.
Výchozí modul runtime kontejneru v AKS je kontejnerový, standardní modul runtime kontejneru.
Práce s clusterem Kubernetes
Kubernetes nabízí nástroj pro příkazový řádek s názvem kubectl, který slouží ke správě clusteru. Pomocí kubectl můžete posílat příkazy řídicí rovině clusteru nebo načítat informace o všech objektech Kubernetes přes server rozhraní API.
kubectl používá konfigurační soubor, který obsahuje následující informace:
- Konfigurace Cluster určuje název clusteru, informace o certifikátu a koncový bod služby rozhraní API přidružený ke clusteru. Tato definice umožňuje připojit se z jedné pracovní stanice k více clusterům.
- Konfigurace Uživatel určuje uživatele a jejich úrovně oprávnění při přístupu k nakonfigurovaným clusterům.
- Kontextové skupiny konfigurace seskupují clustery a uživatele pomocí popisného názvu. Můžete mít například názvy vyv-cluster a prod-cluster, které identifikují vývojový a produkční cluster.
kubectl je možné nakonfigurovat na připojování k několika clusterům tak, že se v rámci syntaxe příkazového řádku zadá správný kontext.
Pody Kubernetes
Pod představuje jednu instanci aplikace běžící v Kubernetes. Úlohy, které spouštíte v Kubernetes, jsou kontejnerizované aplikace. Na rozdíl od prostředí Dockeru v Kubernetes není možné kontejnery spouštět přímo. Kontejner zabalíte do objektu Kubernetes, kterému se říká pod. Pod je nejmenší objekt, který se v Kubernetes dá vytvořit.
Jeden pod může obsahovat skupinu s jedním nebo více kontejnery. Obvykle ale pod neobsahuje několik stejných aplikací.
Pod obsahuje informace o sdíleném úložišti a konfiguraci sítě a specifikaci, jak spouštět zabalené kontejnery. Pomocí šablon podů se definují informace o podech, které běží v clusteru. Šablony podů jsou soubory kódu YAML, které se opakovaně používají a zahrnují do jiných objektů, aby bylo možné spravovat nasazení podů.
Řekněme například, že chcete nasadit web do clusteru Kubernetes. Vytvoříte definiční soubor podu, který určuje image a konfiguraci kontejneru aplikace. Pak definiční soubor podu nasadíte do Kubernetes.
Je nepravděpodobné, že by webová aplikace měla web jako jedinou komponentu v řešení. Webová aplikace má obvykle určitý druh úložiště dat a další podpůrné prvky. Pody Kubernetes můžou navíc obsahovat více než jeden kontejner.
Předpokládejme, že váš web používá databázi. Web se zabalí do hlavního kontejneru a databáze do toho podpůrného. Více kontejnerů mezi sebou komunikuje prostřednictvím prostředí. Kontejnery zahrnují služby pro hostitelský operační systém, zásobník sítě, obor názvů jádra, sdílenou paměť a svazek úložiště. Pod je sandboxové prostředí, které všechny tyto služby nabízí vaší aplikaci. Umožňuje také, aby kontejnery sdílely přidruženou IP adresu podu.
Vzhledem k tomu, že je možné vytvořit mnoho podů spuštěných na velkém počtu uzlů, může být obtížné je identifikovat. Pody můžete rozpoznat a seskupit pomocí popisků řetězců, které zadáte při definování podu.
Životní cyklus podu Kubernetes
Pody Kubernetes mají specifický životní cyklus, který má vliv na způsob, jak je budete nasazovat, spouštět a aktualizovat. Začnete tak, že do clusteru odešlete manifest YAML podu. Po odeslání a trvalém uložení souboru manifestu do clusteru definuje požadovaný stav podu. Plánovač naplánuje pod na uzel, který je v pořádku a má pro spuštění podu dostatek prostředků.
Tady jsou fáze životního cyklu podu:
| Fáze | Popis |
|---|---|
| Probíhá | Pod přijímá cluster, ale ne všechny kontejnery v clusteru jsou nastavené nebo připravené ke spuštění. Stav Čeká na vyřízení označuje čas, kdy pod čeká na naplánování a čas strávený stahováním imagí kontejneru. |
| Spuštěno | Pod přejde do spuštěného stavu, jakmile v něm budou připravené všechny prostředky. |
| Úspěšný | Do úspěšného stavu pod přejde ve chvíli, když dokončí svůj zamýšlený úkol a úspěšně proběhne. |
| Neúspěšný | Pody můžou selhat z různých důvodů. Kontejner v podu může selhat, což může vést k ukončení všech ostatních kontejnerů nebo se při přípravě kontejnerů podů nepodařilo najít image. V těchto typech případů může pod přejít do stavu selhání. Pody můžou přejít do stavu selhání z čekajícího stavu nebo spuštěného stavu. Konkrétní chyba může navíc vrátit pod zpět do čekajícího stavu. |
| Neznámý | Pokud stav podu nelze určit, pod je v neznámém stavu. |
Pody se uchovávají v clusteru, dokud je kontroler, řídicí rovina nebo uživatel explicitně neodeberou. Po odstranění podu se hned po vytvoření vytvoří nový pod. Nový pod se považuje za zcela novou instanci založenou na manifestu podu. Nejedná se o přesnou kopii, takže se liší od odstraněného podu.
Cluster neukládá stav podu ani dynamicky přiřazenou konfiguraci. Neuloží například ID nebo IP adresu podu. Tento aspekt má vliv na to, jak nasazovat pody a jak navrhovat aplikace. Nedá se například spoléhat na předem přiřazené IP adresy podů.
Stavy kontejnerů
Nezapomeňte, že fáze jsou souhrn toho, v jaké části životního cyklu se pod nachází. Při kontrole podu používá cluster tři stavy ke sledování kontejnerů v podech:
| Stát | Popis |
|---|---|
| Čekání | Výchozí stav kontejneru a stav, ve kterém se kontejner nachází, když není spuštěný nebo ukončený |
| Spuštěno | Kontejner se spustil podle očekávání a bez problémů. |
| Ukončen | Kontejner už není spuštěný. Důvodem je to, že buď byly dokončeny všechny úlohy, nebo kontejner z nějakého důvodu selhal. V obou případech jsou k dispozici příčina a ukončovací kód pro ladění. |