Kontejnerizace: důvody nahrazení virtuálních strojů

Driver

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.
  • Přenositelnost: standardy OCI zaručují, že image běží stejně ve vývoji, testování i produkci.
  • Opakovatelnost: deklarativní Dockerfile/Buildpacks vytváří 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 OS):

  • Namespaces (pid, net, mnt, ipc, uts, user): oddělují procesy, síť, mounty, IPC, hostname a uživatele.
  • cgroups v2: omezují a sledují využití CPU, paměti, I/O a dalších zdrojů; 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 pro jednotlivou 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 cache.
  • Dockerfile a Buildpacks popisují proces sestavení; 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 skeny jsou klíčové pro bezpečnost dodavatelského řetězce.

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 a 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 politiky, někdy s podporou eBPF akcelerace.
  • Service discovery: DNS služby (kube-dns/CoreDNS), virtuální IP a load balancing.

Perzistence dat

Data by měla být uchovávána 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 nejnižších oprávnění: 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 – odstranit nepotřebná oprávnění.
  • Dodavatelský řetězec: skenování zranitelností, podpisy image, policy enginy (OPA/Gatekeeper, Kyverno), SBOM.
  • Sandboxing: pro vícetenantní prostředí je možné použít kata-containers/gVisor (lehké VM) – dodatečná tvrdá hranice izolace.

Orchestrace: proč samotný kontejner nestačí

Ve větším měřítku je potřeba řešit plánování, škálování, aktualizace a odolnost:

  • Kubernetes: deklarativní API (Deployment, StatefulSet, DaemonSet), autoscaling (HPA/VPA), Pod jako atomickou jednotku běhu.
  • Service mesh (Istio, Linkerd): mTLS, pravidla provozu, observabilita bez zásahu do kódu.
  • Ingress/Edge: řízení příchozího provozu (Ingress Controller/Gateway API), omezení rychlosti a WAF.

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

  • Build: reprodukovatelné sestavení (BuildKit, kaniko), cache, multi-architektura (amd64/arm64).
  • Test: unit testy, integrační testy, bezpečnostní skeny; dočasná 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á méně paměti a CPU pro infrastrukturu než VM s guest OS.
  • Cache vrstev: rychlé sestavení a nasazení; minimalizace image snižuje cold-start.
  • QoS zdrojů: limity cgroups, 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í hranice VM.
  • Specifický hardware: PCIe passthrough, některé GPU/FPGA scénáře nebo modely ovladačů lépe sedí VM či fyzickému stroji (bare metal).
  • Monolitické OS závislosti: aplikace pevně svázané s konkrétním jádrem nebo verzí OS.

Design kontejneru: 12-Factor a best practices

  • Jeden proces na kontejner (PID 1 dělá pouze jednu věc; procesní supervize přes init wrapper, ne 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 je mimo; sestavení → test → nasazení bez změny artefaktu.
  • Observabilita: logy na stdout/stderr, health checks (liveness/readiness/startup), metriky a tracing.

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é jsou API kontrakty, verze, observabilita, odolnost (circuit breaker, retries, timeouty) a řízení závislostí.

Náklady a ekonomika provozu

  • Využití zdrojů: vyšší hustota snižuje potřebu uzlů a licencí.
  • Rychlost dodávky: kratší doba dodání zvyšuje hodnotu pro byznys.
  • Skryté náklady: orchestrátory přinášejí komplexitu – je nutné investovat do SRE, bezpečnosti a řízení.

Bezpečná dodavatelská cesta (Supply Chain)

  • Minimal base images: distroless/ubi-minimal, odstraňovat shell a správce balíčků.
  • Reprodukovatelnost: pinování verzí, hermetické sestavení, SBOM a podpisy artefaktů.
  • Prosazení pravidel: admission kontrolery, pravidla pro původ image, 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 image umožňují jednotné vydávání pro amd64 i 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. Refaktorování: oddělení konfigurace, logů a perzistence; health checky.
  3. Kontejnerizace: Dockerfile/Buildpacks, minimalizace image, skeny.
  4. Provoz: nasazení do orchestrátoru, limity/žádosti o zdroje, 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 kontejneru.
  • Stav uvnitř kontejneru: zapisování do read-write vrstvy → problémy se škálovatelností a perzistencí.
  • Root a široká oprávnění: nezmenšují útokovou plochu; používejte USER, odstraňujte capability, seccomp profily.
  • Drift: ruční zásahy do běžících kontejnerů; vše by mělo být řízeno přes rebuild a 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 hraniční izolací 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 virtuální stroje ú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.

Súvisiace články