Co je kontejner

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 guest 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 dev, test i produkci.
• Opakovatelnost: deklarativní Dockerfile/Buildpacks vytváří spustitelné artefakty konzistentně.
• Ekosystém: orchestrace (Kubernetes), registries, observabilita a síťové pluginy zjednodušují provoz.
• Náklady: vyšší využití zdrojů snižuje TCO, zejména u mikroservisní architektury.

Architektura: jak kontejnery fungují

Základ tvoří dvě techniky v Linuxu (a analogie v dalších OS):

• 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 se řeší přes union filesystémy (OverlayFS). Kontejner má read-only image vrstvy a samostatnou read-write vrstvu per instance.

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

• OCI image je složen z vrstev (tar archivy), které sdílejí obsah mezi kontejnery – šetří místo a cache.
• Dockerfile/Buildpacks popisují proces buildu; běžná praxe je multi-stage build pro minimalizaci výsledného image.
• Registries (Docker Hub, GHCR, ECR, GCR) slouží pro distribuci image; podpisy (cosign), SBOM a skeny jsou klíčové pro supply chain bezpečnost.

Běh kontejneru: runtime a shim

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

• High-level: containerd, CRI-O (komunikuje s Kubernetes přes CRI).
• Low-level (OCI runtime): runc, crun – volají kernel, nastavují namespaces/cgroups a spouštějí proces PID 1 v kontejneru.

Komponenta shim drží ž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, nastavují routing/policy, někdy eBPF akceleraci.
• 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

• Least privilege: neběhat jako root; použít USER v Dockerfile, rootless režimy.
• Linux Security Modules: seccomp (filtr syscalls), AppArmor/SELinux profily, capabilities – odstranit nepotřebné schopnosti.
• Supply chain: sken zranitelností, podpisy image, policy engines (OPA/Gatekeeper, Kyverno), SBOM.
• Sandboxing: pro vícetenantní prostředí lze použít kata-containers/gVisor (lehké VM) – dodatečná hard hranice.

Orchestrace: proč samotný kontejner nestačí

Ve větším měřítku je nutné řešit rozvrh, škálování, update a odolnost:

• Kubernetes: deklarativní API (Deployment, StatefulSet, DaemonSet), autoscaling (HPA/VPA), Pod jako atomická jednotka běhu.
• Service mesh (Istio, Linkerd): mTLS, traffic policy, observabilita bez 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: reproducibilní buildy (BuildKit, kaniko), cache, multi-arch (amd64/arm64).
• Test: unit, integrační, bezpečnostní skeny; ephemeral prostředí.
• Release: immutable tagy (sha256 digest), GitOps (Argo CD/Flux), progresivní rollout (canary/blue-green).

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

• Menší overhead: sdílené jádro znamená méně paměti/CPU na infra vrstvu než VM s guest OS.
• Cache vrstev: rychlé buildy a nasazení; minimalizace image snižuje cold-start.
• Resource QoS: 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, starší regulace vyžadující VM hranice.
• Specializovaný hardware: PCIe passthrough, některé GPU/FPGA scénáře nebo driver modely lépe sedí VM/metal.
• Monolitické OS závislosti: aplikace pevně spjaté s konkrétním jádrem/OS verzí.

Design kontejneru: 12-Factor a best practices

• Jeden proces na kontejner (PID 1 dělá jen jednu věc; proces supervision přes init wrapper, ne cron uvnitř obrazu).
• Konfigurace mimo image: přes proměnné nebo secrets/config maps; žádné tajné klíče v image.
• Neměnnost: image je read-only, stav mimo; 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áší nezávislé release cykly a škálování. Kritické je API contract, verze, observabilita, odolnost (circuit breaker, retries, timeouty) a governance závislostí.

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í komplexitu – je nutné investovat do SRE, bezpečnosti a governance.

Bezpečná dodavatelská cesta (Supply Chain)

• Minimal base images: distroless/ubi-minimal, odstraňovat shell a package manager.
• Reproducibilita: pin verzí, hermetické buildy, SBOM a podpisy artefaktů.
• Policy enforcement: admission kontrolery, pravidla pro image původ, skeny v CI i v clusteru.

Windows a další platformy

Kontejnery existují i na Windows (Windows Server Containers, Hyper-V Containers) a macOS (přes VM). Multi-arch obrazy umožňují jednotné vydávání pro amd64/arm64.

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.
• Tracing: OpenTelemetry, sampling a baggage; korelace napříč službami.

Migrace z VM do kontejnerů

1. Inventura: závislosti, konfigurace, stav, profily I/O a latence.
2. Refaktor: oddělení konfigurace, logů a perzistence; health-checky.
3. Containerization: Dockerfile/Buildpacks, minimální image, skeny.
4. Provoz: nasazení do orchestrátoru, limity/requests, HPA, rollout strategie, observabilita.

Příklady anti-patternů

• „VM uvnitř kontejneru“: velké image s init systémy a více démony – ztráta výhod kontejneru.
• State uvnitř: zapisování do RW vrstvy → problémy s škálováním a persistencí.
• Root a široké capability: neomezujete útokovou plochu; používejte USER, drop capabilities, 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é VM (Firecracker, Kata) a kontejnerů: výkon a hustota kontejnerů s hranicí izolace VM. Trendem je 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.