Abstrakt: Kubernetes se za poslední dekádu vyvinul z experimentální technologie na de facto standard pro orchestraci kontejnerů v podnikovém prostředí. Článek poskytuje úvod do architektury Kubernetes se zaměřením na praktické aspekty implementace. Vysvětluje rozdělení clusteru na řídicí rovinu a pracovní uzly, popisuje role klíčových komponent a základních objektů (pod, deployment, služba, ingress) a shrnuje aktuální trendy včetně bezserverových kontejnerů, servisní mřížky a postupů GitOps.
1. Od ruční správy k automatizované orchestraci
Název Kubernetes pochází z řeckého slova pro kormidelníka. Před vznikem této platformy čelily organizace třem zásadním problémům správy kontejnerizovaných aplikací.
Problém škálování. Spustit jednu aplikaci v jednom kontejneru je triviální, ale provozovat sto kopií na padesáti serverech ručně se rychle stává neúnosným.
Problém dostupnosti. Servery selhávají. Bez orchestračního systému znamená výpadek serveru pád všech aplikací na něm běžících, dokud někdo nezareaguje ručně.
Problém alokace zdrojů. Aplikace mají různé požadavky na procesor, paměť a síť. Efektivní využití hardwaru vyžaduje inteligentní rozmístění úloh napříč clusterem.
Tradiční přístup byl imperativní — administrátor přesně říkal, kde co spustit. Kubernetes zavádí deklarativní paradigma: definujeme cílový stav, platforma se sama stará o jeho dosažení a udržení. Stačí například vyjádřit požadavek „vždy mají běžet tři kopie této aplikace“ a Kubernetes detekuje výpadek a okamžitě jej kompenzuje.
2. Architektura clusteru
Kubernetes cluster se dělí na řídicí rovinu (control plane) a pracovní uzly (worker nodes).
2.1 Řídicí rovina
Řídicí rovina rozhoduje o globálních záležitostech clusteru — plánování úloh, škálování, upgrady — a reaguje na události typu výpadku uzlu.
API server je jediný vstupní bod do clusteru. Veškerá komunikace, ať už od vývojářů přes nástroj kubectl, od interních komponent nebo externích integrací, prochází jeho rozhraním REST. Server zajišťuje autentizaci, autorizaci, validaci YAML manifestů a ukládání stavu objektů do databáze.
etcd je distribuovaná databáze typu klíč–hodnota, která slouží jako jediný zdroj pravdy o stavu clusteru. Postavená je na konsenzuálním algoritmu Raft a typicky běží ve formaci tří, pěti nebo sedmi uzlů. Ztráta dat z etcd znamená ztrátu celého clusteru — pravidelné zálohy jsou nezbytné. Databáze obsahuje i citlivé informace včetně certifikátů a tajných klíčů, proto musí být šifrovaná.
Plánovač (scheduler) rozhoduje, na který pracovní uzel umístit nově vytvořený pod. Bere v úvahu požadavky na zdroje, preference uzlů, pravidla soudržnosti (affinity), výjimky (taints a tolerations) a třídy kvality služby. Cílem je optimální rozložení zátěže s ohledem na priority.
Správce kontrolerů (controller manager) obsahuje sadu kontrolerů, které neustále porovnávají skutečný stav s cílovým a provádějí korekce. Patří sem kontroler pro deployments, replikační kontroler, kontroler uzlů detekující selhání a servisní kontroler komunikující s cloudovými poskytovateli.
2.2 Pracovní uzly
Každý pracovní uzel obsahuje komponenty potřebné k běhu kontejnerů a jejich zapojení do sítě clusteru.
Kubelet je primární agent na uzlu. Zajišťuje, aby kontejnery popsané ve specifikaci podu skutečně běžely — řídí jejich životní cyklus, monitoruje využití zdrojů, provádí sondy zdraví, připojuje úložiště a komunikuje s běhovým prostředím kontejnerů (containerd, CRI-O).
Kube-proxy implementuje síťové abstrakce služeb a zajišťuje, že provoz směřovaný na adresu služby je správně distribuován mezi cílové pody. Dnes typicky pracuje v režimu IPVS, který zvládá velké množství služeb lépe než starší režim iptables.
3. Základní objekty Kubernetes
Pod je nejmenší jednotka nasazení. Obsahuje jeden nebo více těsně spjatých kontejnerů sdílejících síť a úložiště. V drtivé většině případů obsahuje jediný kontejner, někdy se používají vzory s pomocným kontejnerem (sidecar pro logování, agenta servisní mřížky) nebo s inicializačním kontejnerem provádějícím přípravné úkoly.
Deployment spravuje aplikace deklarativně. Postavený je nad replikační sadou, ale přidává postupné aktualizace a možnost vrácení změn. Strategie postupné aktualizace (rolling update) nahrazuje staré pody novými bez výpadku, alternativa s rekreací způsobí krátký výpadek, ale je jednodušší.
Služba (service) poskytuje stabilní síťový bod pro skupinu podů a řeší problém dynamických adres. Existují tři hlavní typy. ClusterIP slouží pro interní komunikaci uvnitř clusteru. NodePort vystavuje službu na pevném portu každého uzlu. LoadBalancer integruje cloudový vyrovnávač zátěže pro externí přístup.
Ingress zajišťuje směrování provozu HTTP a HTTPS do služeb v clusteru. Funguje jako reverzní proxy s podporou virtuálních hostitelů, cest a šifrování TLS. V praxi běží jako nginx, Traefik nebo HAProxy.
4. Aktuální trendy
Bezserverové kontejnery. Platforma Knative umožňuje automatické škálování až na nulu při nečinnosti a rychlý náběh při příchozím požadavku. Vhodné pro úlohy s nepravidelnou zátěží, kde se neplatí za nevyužité zdroje.
Servisní mřížka (service mesh). Istio a Linkerd přidávají pokročilé síťové schopnosti bez zásahu do kódu — vzájemnou autentizaci mezi službami, řízení provozu pro postupné nasazování, automatické metriky a strukturované záznamy.
GitOps. Nástroje ArgoCD a Flux používají Git jako jediný zdroj pravdy o stavu infrastruktury. Změny v repozitáři se automaticky aplikují do clusteru, drift se detekuje a opravuje, vrácení změny je otázkou jednoho příkazu git revert. Audit historie je samozřejmou součástí.
Správa více clusterů. Organizace stále častěji provozují cluster na okraji sítě, v různých regionech nebo u různých poskytovatelů. Nástroje Cluster API, Liqo a Admiralty řeší orchestraci napříč clustery, replikaci stavu a převod úloh mezi prostředími.
5. Praktická doporučení
Správa zdrojů. U každého kontejneru definujte požadavek (request) i limit pro procesor i paměť. Plánovač používá požadavky pro umístění, limity vynucují horní hranici spotřeby. Třídy kvality služby (Guaranteed, Burstable, BestEffort) určují prioritu při tlaku na zdroje.
Bezpečnost. Standardy bezpečnosti podů (Pod Security Standards) nahrazují starší zásady. Doporučuje se profil restricted pro produkční jmenné prostory. Síťové politiky (NetworkPolicy) zavádějí mikrosegmentaci na úrovni podů, výchozí pravidlo „zakázat vše“ s explicitním povolením potřebného provozu je osvědčený přístup.
Pozorovatelnost. Standardní zásobník zahrnuje Prometheus a Grafana pro metriky, Jaeger nebo Zipkin pro distribuované sledování a kombinaci Elasticsearch, Fluentd a Kibana pro centralizované záznamy. Systém kube-state-metrics doplňuje metriky o stav samotných objektů Kubernetes.
6. Závěr
Kubernetes není jen nástroj, ale celý ekosystém měnící způsob, jakým se vyvíjejí a provozují moderní aplikace. Jeho nasazení vyžaduje technické znalosti, ale především kulturní posun k DevOps praktikám, infrastruktuře jako kódu a cloud-native myšlení.
Začátečníkům se osvědčuje postupný přístup: nejdřív pochopit základní pojmy (pod, deployment, služba), pak si vyzkoušet lokální cluster v nástrojích jako minikube nebo kind, následně postavit pipeline pro průběžnou integraci a nasazení a teprve poté přidávat pokročilé funkce — monitoring, bezpečnostní pravidla, servisní mřížku.
Křivka učení je strmá, ale investice se vyplatí. V éře cloud-native je Kubernetes základní dovedností pro každého, kdo se zabývá moderní infrastrukturou. Není to cíl, ale prostředek k dosažení škálovatelné, odolné a automatizované infrastruktury.
---
Doporučená literatura
- Hightower, K., Burns, B., Beda, J.: Kubernetes: Up and Running
- Lukša, M.: Kubernetes in Action
- Oficiální dokumentace na kubernetes.io
- Cloud Native Computing Foundation (CNCF) — krajina projektů a certifikace
