Monitoring a škálování kontejnerů

Proč monitorovat a škálovat kontejnerové aplikace

Kontejnerizace (Docker) a orchestrace (Kubernetes) zásadně zrychlily doručování software, ale současně zvýšily komplexitu provozu. Úspěšný běh aplikací v kontejnerech vyžaduje disciplinovanou observabilitu (metriky, logy, trasy, eventy) a promyšlené škálování (horizontální/vertikální i na úrovni clusteru). Cílem je dosáhnout prediktivní latence, nízké chybovosti, efektivního využití zdrojů a automatické reakce na změny zátěže při zachování nákladové efektivity a spolehlivosti.

Pilíře observability: metriky, logy, trasování a eventy

• Metriky: číselné časové řady pro SLI (latence, chybovost, propustnost, saturace). Standardem je Prometheus/OpenMetrics.
• Logy: detailní diagnostika, audit a forenzní data. Sběr přes Fluent Bit/Vector → úložiště (Loki/Elastic/Cloud Logging).
• Trasy: distribuované trasování (OpenTelemetry → Jaeger/Tempo/DataDog) pro pochopení závislostí služeb a latencí.
• Eventy: Kubernetes události (evikace, restart), vlastní doménové události, upozornění CI/CD.

Referenční architektura monitoringu v Kubernetes

• cAdvisor a kubelet poskytují základní metriky kontejnerů a podů (CPU, paměť, I/O).
• Prometheus scrape-uje metriky z exporterů (node-exporter, kube-state-metrics, application metrics) a ukládá je do TSDB.
• Grafana vizualizuje SLI, SLO a tvorbu dashboardů pro týmy (service, infra, DB, síť, mesh).
• Loki s promyšlenou retencí pro logy, TEMPO/Jaeger pro trasy, alertmanager pro notifikace.
• OpenTelemetry SDK/collector sjednocuje ingest metrik, logů a tras do standardních backendů.

SLI, SLO a error budget: řízení rizik a škálování

Definujte SLI (např. p95 latence < 300 ms, chybovost < 0,5 %, dostupnost > 99,9 %) a z nich odvoďte SLO. Error budget (1–SLO) určuje toleranci porušení; překročení spouští opatření: zpomalení releasů, navýšení kapacity, optimalizace kódu, změna autoscalingových prahů. Alerty se mají vázat na porušení SLO (uživatelský dopad), ne jen na nízkoúrovňové metriky.

Základní metriky: golden signals a kontejnerové specifikum

• Latence (p50/p95/p99) a propustnost (RPS) z aplikačních metrik.
• Chybovost (4xx/5xx, doménové chyby) a saturovanost (CPU throttling, paměť blížící se limitu, délka front v DB/queue).
• Specifika kontejnerů: requests/limits, QoS třídy (Guaranteed/Burstable/BestEffort), evikace z důvodu paměti a podtlaku (memory pressure), restart policy.

Resource requests a limits: prevence throttlingu a evikací

Správné nastavení resources.requests a limits je základ škálování. Příliš nízké requests vyvolají přetížené nody; příliš nízké limits způsobí CPU throttling a OOMKill. Doporučení:

• Začněte od měřeného p95 využití a přidejte headroom (např. 20–30 %).
• Preferujte CPU limit = žádný u latencí citlivých služeb (místo toho nastavte vyšší request), jinak riskujete micro-burst throttling.
• U paměti nastavte limit = request pro deterministické chování GC a evikací (QoS Guaranteed) tam, kde to dává smysl.

Probes: liveness, readiness, startup

• Readiness říká, kdy může pod přijímat provoz; měřte závislosti (DB, cache, externí API).
• Liveness restartuje zamrzlý proces; nastavte velkorysý initialDelay a opatrný timeout, aby nedošlo k restart loops.
• Startup pro pomalý cold start – ochrání před falešnými liveness fail.

Horizontální škálování: HPA a metriky

Horizontal Pod Autoscaler škáluje počet replik podle metrik (CPU, paměť, vlastní metriky z Promethea). Typické signály: p95 latence, délka fronty (RabbitMQ/Kafka), vyžití CPU, aktivní sessions. Příklad HPA na vlastní metrice z Promethea:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: webapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: webapp minReplicas: 3 maxReplicas: 50 metrics: - type: Pods pods: metric: name: http_requests_inflight target: type: AverageValue averageValue: "50" 

Vertikální škálování: VPA a doporučení

Vertical Pod Autoscaler doporučuje nebo mění requests/limits dle historie. V režimu Recommendation generuje návrhy; v Auto pod restartuje a aplikuje nové hodnoty. V praxi se VPA často kombinuje s HPA (HPA podle vlastní metriky, VPA v doporučovacím režimu pro periodické ladění).

Event-driven škálování: KEDA a fronty

KEDA škáluje podle externích signálů (délka fronty, lag v Kafka, počet zpráv v SQS, metrika v Prometheu). Příklad škálování podle Prometheus metriky latence:

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: webapp-keda spec: scaleTargetRef: name: webapp pollingInterval: 10 cooldownPeriod: 60 minReplicaCount: 2 maxReplicaCount: 100 triggers: - type: prometheus metadata: serverAddress: http://prometheus.monitoring.svc:9090 metricName: http_request_latency_p95_seconds threshold: "0.3" query: | histogram_quantile(0.95,sum(rate(http_request_duration_seconds_bucket{job="webapp"}[2m])) by (le)) 

Cluster Autoscaler a kapacitní plánování

Cluster Autoscaler přidává/odebírá nody dle nenaplánovaných podů a využití. Oddělte node pooly (compute vs. memory-optimized, GPU), použijte taints/tolerations pro kontrolu schedulingu a priority classes pro preempcí méně důležitých workloadů. Kapacitní plánování vychází z dlouhodobých trendů metrik a z předvídaných špiček (události, marketingové kampaně).

Topologie a rozložení: PDB, Pod anti-affinity, topology spread

• PodDisruptionBudget brání degradaci při údržbě/rolloutech (minAvailable/maxUnavailable).
• Pod anti-affinity a topologySpreadConstraints minimalizují riziko kolokace replik na jedné fyzické entitě.
• Zone-aware scheduling zlepšuje odolnost proti výpadkům AZ.

Řízení nákladů: efektivita a rozpočty

• Nastavte requests blízko reálnému p95, vyhněte se zbytečnému headroomu; použijte VPA doporučení.
• Definujte resource quotas a limit ranges v namespace pro governance.
• Měřte cenu/SLI: náklad na RPS, náklad na 1 GB RAM/hod, náklady na storage/logs; omezte retenční doby a sampling tras.

Alerting: od symptomů ke kauzální diagnostice

Notifikace musí být akční a s nízkým šumem. Přiklad pravidla (Alertmanager) pro porušení SLO latence:

groups: - name: slo-latency rules: - alert: HighLatencyP95 expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="webapp"}[5m])) by (le)) > 0.3 for: 10m labels: severity: page service: webapp annotations: summary: "p95 latence > 300 ms" description: "SLO porušeno 10 min, zvažte škálování nebo incident." 

Logování v kontejnerech: struktura, retence, korelace

• Logujte strukturovaně (JSON) s trace_id/span_id a kubernetes.labels.
• Forward přes DaemonSet (Fluent Bit/Vector) s TLS; nastavte rate limiting a backpressure.
• Retence podle třídy logů; archivace do levnějšího objektového úložiště, sampling u debug logů.

Distribuované trasování: OTel a service mesh

OpenTelemetry SDK a Collector umožní jednotné trasování a metriky. V service meshi (Istio/Linkerd) získáte síťová SLI (latence mezi službami, chybovost, retry) bez úprav kódu; pozor na režii sidecarů a plánujte zdroje.

Škálování stavových služeb a front

• StatefulSets škálujte konzervativně; sledujte replikaci (lag), latenci disků a IOPS. U DB oddělte read/write a používejte connection pooling.
• Fronty (Kafka/RabbitMQ/SQS) škálujte podle lag/délky, nastavte consumer group paralelismus a idempotenci zpracování.
• Pro heavy úlohy použijte Jobs/CronJobs, Pod Priority pro důležité dávky a resource quotas.

Release strategie a dopad na observabilitu

• Rolling update vyžaduje readiness a graceful shutdown pro minimalizaci chyb.
• Canary s řízením provozu (service mesh, ingress) a experimentálními SLO (latence, chybovost) rozhoduje o progresi/rollbacku.
• Blue/Green pro rychlý rollback; měřte pre-switch warm-up a cache priming.

eBPF a pokročilá telemetrie

eBPF nástroje (Cilium/Tetragon/BCC) umožňují nízko-režijní síťové a systémové metriky, sledování systémových volání, bezpečnostní audit a hlubokou diagnostiku anomálií bez injektáže do aplikačního kódu.

Bezpečnost observability a škálování

• RBAC pro čtení metrik/logů; tajemství (tokens, credentials) maskujte už u agenta.
• Pod Security a NetworkPolicies omezují blast radius; logging/metrics endpointy chraňte (TLS, auth), nepouštějte je veřejně.
• Multi-tenancy: oddělení namespaces, resource quotas, samostatné data sources v Grafaně a retenční politiky.

Dashboardy pro provoz: doporučené panely

• Service overview: RPS, p50/p95/p99, 4xx/5xx, saturace CPU/paměť, pod count, HPA cíl/aktuální.
• Pod health: restarty, readiness, liveness, OOM, throttling, GC, event loop lag (u Node.js), heap/GC (u JVM).
• Infra: uzly, allocatable vs. requested, pod scheduler waiting, disk I/O, síťová propustnost.
• Business SLI: doménové metriky (checkout success rate, objednávky/min), navázané na SLO a error budget.

Praktický příklad: end-to-end telemetrie služby

1. Aplikace exportuje HTTP metriky (Prometheus client) a OpenTelemetry trasy.
2. HPA škáluje na průměrnou hodnotu inflight požadavků na pod (cílová hodnota 50).
3. KEDA zvětšuje počet workerů podle lag ve frontě (Kafka topic lag > 10k).
4. Cluster Autoscaler přidává nody, pokud HPA naráží na nedostatek zdrojů; VPA doporučuje nové requests.
5. Alerty vázané na SLO p95 latence a chybovost s for: 10 minut, propojené s runbookem a detailní diagnostikou (LogQL dotazy v Lokim, traces v Jaegeru).

Konfigurace scrape a service discovery

Prometheus v Kubernetes používá service discovery a relabeling. Dodržujte konvence: endpoint /metrics, metriky s namespace, pod, container labely a service label sjednocující názvy napříč prostředími.

Retention, downsampling a škálování observability

• Pro metriky používejte downsampling/remote write (Thanos/Cortex/Mimir) a oddělené retenční politky (např. 15 dní plný detail, 1 rok agregáty).
• Logy rozdělte do tříd (audit, aplikace, debug) s odlišnou retencí; archivujte do objektového úložiště.
• Trasy samplujte (tail-based sampling) pro zachycení outlierů (p99) při nízké režii.

Testování škálování: load testy a chaos

• Load test (k6, vegeta, wrk) pro ověření HPA/KEDA reakcí, latence pod tlakem, kolapsové body.
• Chaos engineering (chaos mesh, litmus) pro test evikací, výpadků uzlů, degradací sítě a latencí závislostí.
• GameDays se scénáři incidentů a cvičením runbooků.

Checklist zavedení monitoringu a škálování

• Definovaná SLI/SLO a error budgety pro klíčové služby.
• Export aplikačních metrik (OpenMetrics), strukturované logy s korelací, OTel trasy.
• HPA na relevatní signál (ne pouze CPU), KEDA pro event-driven, VPA doporučení.
• Správné requests/limits, QoS třídy, readiness/liveness/startup probes.
• PDB, anti-affinity a topology spread pro odolnost; priority classes pro kritické workloady.
• Alerty vázané na SLO s nízkým šumem, runbooky, eskalace.
• Retention a nákladový model pro metriky, logy a trasy; remote-write/long-term store.
• Pravidelné load testy, chaos experimenty a revize autoscalingových prahů.

Závěr

Monitoring a škálování kontejnerových aplikací je kombinací kvalitní telemetrie, jasně definovaných SLO a automatizovaných škálovacích mechanismů. Klíčem je měřit to, co ovlivňuje uživatelský zážitek, a škálovat podle signálů, které nejlépe korelují s obchodním dopadem. S promyšlenými requests/limits, robustními probes, HPA/VPA/KEDA, cluster autoscalerem a disciplinovanou observabilitou lze dosáhnout spolehlivého, výkonného a nákladově efektivního provozu v Kubernetes i mimo něj.