Co je kontejnerová technologie

Co je kontejner

Kontejner je izolované běhové prostředí pro aplikaci a její závislosti, které sdílí jádro operačního systému s hostitelem. Na rozdíl od virtuálního stroje (VM) nekopíruje celý operační systém; místo toho využívá namespaces a cgroups k izolaci procesů, zdrojů a souborového systému. Výsledkem je lehké, rychle startující a snadno přenositelné balení aplikace napříč prostředími.

Proč kontejnery nahradily (mnoho) VM

Hustota: bez hypervizoru a hostujícího OS běží více instancí na stejné infrastruktuře.
Rychlý start: kontejnery startují v řádu milisekund až sekund, VM v desítkách sekund až minut.
Portabilita: standardy OCI zaručují, že image běží stejně v prostředích vývoje, testování i produkce.
Opakovatelnost: deklarativní Dockerfile/Buildpacks vytvářejí spustitelné artefakty konzistentně.
Ekosystém: orchestrace (Kubernetes), registry, observabilita a síťové pluginy zjednodušují provoz.
Náklady: vyšší využití zdrojů snižuje celkové náklady na vlastnictví (TCO), zejména u mikroservisní architektury.

Architektura: jak kontejnery fungují

Základ tvoří dvě techniky v Linuxu (a analogie v dalších operačních systémech):

Namespaces (pid, net, mnt, ipc, uts, user): oddělují procesy, síť, mounty, IPC, hostname a uživatele.
cgroups v2: omezují/účtují CPU, paměť, I/O a další kvóty; chrání hostitele před vyčerpáním zdrojů.

Izolace souborového systému je řešena prostřednictvím union filesystémů (OverlayFS). Kontejner má read-only image vrstvy a samostatnou read-write vrstvu pro každou instanci.

Image a vrstvy: neboli „balíček runtime“

OCI image se skládá z vrstev (tar archivy), které sdílejí obsah mezi kontejnery – šetří místo a umožňují cache.
Dockerfile / Buildpacks popisují proces buildování; běžnou praxí je multi-stage build pro minimalizaci výsledného image.
Registry (Docker Hub, GHCR, ECR, GCR) slouží k distribuci image; podpisy (cosign), SBOM a bezpečnostní skeny jsou klíčové pro zabezpečení dodavatelského řetězce.

Běh kontejneru: runtime a shim

Spuštění kontejneru zajišťuje container runtime. V praxi:

Vyšší úroveň: containerd, CRI-O (komunikuje s Kubernetes přes CRI).
Nižší úroveň (OCI runtime): runc, crun – volají jádro, nastavují namespaces/cgroups a spouštějí proces PID 1 v kontejneru.

Komponenta shim udržuje životní cyklus a logy procesu i po ukončení klienta.

Síťování kontejnerů

Bridge (lokální): NAT přes hostitele, izolované subnety, port-mapping (-p).
Overlay (multi-host): virtuální L3/L2 sítě nad existující infrastrukturou.
CNI pluginy v Kubernetes (Calico, Cilium, Flannel): přidělují IP adresy, nastavují routing a politiku, někdy s eBPF akcelerací.
Service discovery: DNS služby (kube-dns/CoreDNS), virtuální IP a load-balancing.

Perzistence dat

Data patří mimo životní cyklus kontejneru:

Volumes (hostPath, block, NFS, CSI): připojitelné úložiště s řízením přístupů a kvót.
Stateful workloads v Kubernetes: StatefulSet + PersistentVolumeClaim, stabilní identity a failovery.

Bezpečnost: izolace a tvrdý režim

Princip minimálních práv: neběhat jako root; používat USER v Dockerfile, rootless režimy.
Linux Security Modules: seccomp (filtr systémových volání), AppArmor/SELinux profily, capabilities – odebrat nepotřebné oprávnění.
Dodavatelský řetězec: skenování zranitelností, podepisování image, policy engines (OPA/Gatekeeper, Kyverno), SBOM.
Sandboxing: pro vícetenantní prostředí lze použít kata-containers/gVisor (lehké VM) – dodatečná tvrdá hranice izolace.

Orchestrace: proč samotný kontejner nestačí

Ve větších rozsazích je nutné řešit plánování, škálování, aktualizace a odolnost:

Kubernetes: deklarativní API (Deployment, StatefulSet, DaemonSet), autoscaling (HPA/VPA), Pod jako atomická jednotka běhu.
Service mesh (Istio, Linkerd): mTLS, pravidla provozu, observabilita bez nutnosti změny kódu.
Ingress/Edge: řízení příchozího provozu (Ingress Controller / Gateway API), rate limiting a WAF.

CI/CD: od kódu k běžícímu kontejneru

Build: reprodukovatelné buildy (BuildKit, kaniko), cache, multi-architektura (amd64/arm64).
Test: unit testy, integrační testy, bezpečnostní skeny; ephemeral prostředí.
Release: immutable tagy (sha256 digest), GitOps (Argo CD/Flux), progresivní nasazení (canary/blue-green).

Výkon: proč jsou kontejnery efektivnější

Menší režie: sdílené jádro znamená nižší spotřebu paměti/CPU na infrastrukturní vrstvu než VM s hostujícím OS.
Cache vrstev: rychlé buildy a nasazení; minimalizace image snižuje cold-start latenci.
Kvalita služeb zdrojů: cgroups limity, requesty/limity v Kubernetes, NUMA a pinning pro citlivé workloady.

Kdy dát přednost VM nebo fyzickému stroji

Silná izolace a compliance: různé úrovně důvěry mezi tenanty, regulace vyžadující VM hranice.
Specializovaný hardware: PCIe passthrough, některé GPU/FPGA scénáře nebo modely ovladačů lépe vhodné pro VM/metal.
Monolitické OS závislosti: aplikace pevně svázané s konkrétním jádrem nebo verzí OS.

Design kontejneru: 12-Factor a osvědčené postupy

Jeden proces na kontejner (PID 1 provádí pouze jednu úlohu; procesní dozor přes init wrapper, nikoliv cron uvnitř image).
Konfigurace mimo image: přes proměnné prostředí nebo secrets/config maps; žádné tajné klíče v image.
Neměnnost: image je read-only, stav mimo image; build → test → release bez změn artefaktu.
Observabilita: logy na stdout/stderr, health checks (liveness/readiness/startup), metriky a trace.

Monolit vs. mikroservisy

Kontejnery podporují oba přístupy. Monolit je jednodušší na začátek, mikroservisy přinášejí nezávislé release cykly a škálování. Kritické je dodržovat API contract, správu verzí, observabilitu, odolnost (circuit breaker, retries, timeouty) a správu závislostí (governance).

Náklady a ekonomika provozu

Využití zdrojů: vyšší hustota snižuje potřebu uzlů a licencí.
Rychlost dodávky: kratší lead time zvyšuje hodnotu pro byznys.
Skryté náklady: orchestrátory přinášejí složitost – vyžadují investice do SRE, bezpečnosti a governance.

Bezpečná dodavatelská cesta (Supply Chain)

Minimal base images: distroless/ubi-minimal, odstranění shellu a správců balíčků.
Reprodukovatelnost: pin verzí, hermetické buildy, SBOM a podpisy artefaktů.
Vynucování zásad: admission kontrolery, pravidla původu image, skeny v CI i v clusteru.

Windows a další platformy

Kontejnery existují také na Windows (Windows Server Containers, Hyper-V Containers) a macOS (přes VM). Multi-architektura image umožňuje jednotné vydávání pro amd64 a arm64 platformy.

Observabilita v kontejnerech

Metriky: cAdvisor/Node Exporter, Prometheus + Alertmanager; Golden signals (latence, chybovost, provoz, saturace).
Logy: sidecar/agent (Fluent Bit/Vector), standardní formát, korelace s trace ID.
Sledování tras: OpenTelemetry, sampling a baggage; korelace napříč službami.

Migrace z VM do kontejnerů

Inventura: závislosti, konfigurace, stav, profily I/O a latence.
Refaktorování: oddělení konfigurace, logů a perzistence; health-checky.
Kontejnerizace: Dockerfile/Buildpacks, minimální image, bezpečnostní skeny.
Provoz: nasazení do orchestrátoru, limity/requests, HPA, strategie rollout, observabilita.

Příklady anti-patternů

„VM uvnitř kontejneru“: velké image s init systémy a více démony – ztráta výhod kontejnerů.
Stav uvnitř: zapisování do RW vrstvy → problémy se škálováním a perzistencí.
Root a široké capability: neomezujete útokovou plochu; používejte USER, odstraňujte schopnosti, seccomp profily.
Drift: ruční zásahy do běžících kontejnerů; vše přes rebuild/redeploy.

Budoucnost: lehké VM a konvergence

Pro vícetenantní scénáře se prosazuje kombinace lehkých VM (Firecracker, Kata) a kontejnerů: výkon a hustota kontejnerů s tvrdou hranicí izolace VM. Trendem je využití eBPF pro síť, bezpečnost a observabilitu a WASM pro ultra-lehké sandboxované moduly na okraji (edge).

Závěr

Kontejnery přinášejí standardizované, lehké a rychlé běhové prostředí, které výrazně zjednodušuje vývoj i provoz. Nezrušily VM úplně, ale ve velké části aplikačních scénářů nahradily jejich roli díky lepší hustotě, rychlosti nasazení a bohatému ekosystému orchestrace a observability. Správně navržený kontejner, řízený deklarativně, s minimálními právy a jasnou dodavatelskou cestou, je dnes výchozím stavebním kamenem moderní cloud-nativní architektury.