Monitorování a škálování kontejnerových aplikací

Proč monitorovat a škálovat kontejnerové aplikace

Kontejnerizace (Docker) a orchestrace (Kubernetes) zásadně zrychlily dodávání softwaru, ale současně zvýšily komplexitu provozu. Úspěšný běh aplikací v kontejnerech vyžaduje disciplinovanou observabilitu (metriky, logy, trasování, události) 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 události

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í.
Události: 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, aplikační metriky) a ukládá je do TSDB.
Grafana vizualizuje SLI, SLO a umožňuje tvorbu dashboardů pro týmy (service, infra, DB, síť, mesh).
Loki s promyšlenou retencí pro logy, TEMPO/Jaeger pro trasování, 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 by měly být vázané na porušení SLO (uživatelský dopad), ne pouze na nízkoúrovňové metriky.

Základní metriky: golden signals a specifika kontejnerů

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ěťového tlaku a podtlaku (memory pressure), restartovací politika.

Resource requests a limits: prevence throttlingu a evikací

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

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

Probes: liveness, readiness, startup

Readiness určuje, kdy může pod přijímat provoz; sledujte závislosti (DB, cache, externí API).
Liveness restartuje zamrzlý proces; nastavte nadstandardní initialDelay a opatrný timeout, aby nedocházelo k restartovacím smyčkám.
Startup pro pomalý cold start – chrání před falešnými liveness selháními.

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

Horizontal Pod Autoscaler upravuje počet replik podle metrik (CPU, paměť, vlastní metriky z Promethea). Typické signály: p95 latence, délka fronty (RabbitMQ/Kafka), využ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 upravuje requests/limits podle historie. V režimu Recommendation generuje návrhy; v režimu Auto restartuje pod a aplikuje nové hodnoty. V praxi se VPA často kombinuje s HPA (HPA podle vlastní metriky, VPA v režimu doporučení 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 z Promethea). 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á a odebírá nody podle nenaplánovaných podů a jejich využití. Oddělte node pooly (compute vs. memory-optimized, GPU), použijte tainty/tolerace 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 předpoklá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ě nebo rolloutech (minAvailable/maxUnavailable).
Pod anti-affinity a topologySpreadConstraints minimalizují riziko umístění replik na stejné fyzické entitě.
Zone-aware scheduling zlepšuje odolnost proti výpadkům Availability Zone.

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

Nastavte requests blízko reálnému p95, vyhněte se zbytečnému přebytku; využijte doporučení VPA.
Definujte resource quotas a limit ranges v rámci namespace pro správu zdrojů.
Měřte cenu oproti SLI: náklady na RPS, cenu za 1 GB RAM/hod, náklady na storage/logy; omezujte retenční doby a sampling tras.

Alerting: od symptomů ke kauzální diagnostice

Notifikace musí být akční a mít nízkou míru šumu. Příklad 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 minut, zvažte škálování nebo incident."

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

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

Distribuované trasování: OTel a service mesh

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

Š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 operace a využívejte connection pooling.
Fronty (Kafka/RabbitMQ/SQS) škálujte podle lag/délky, nastavte paralelismus v consumer groups a idempotentní zpracování.
Pro náročné úlohy používejte Jobs/CronJobs, Pod Priority pro důležité dávkové úlohy a resource quotas.

Strategie releasů 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 postupu nebo rollbacku.
Blue/Green umožňuje 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í sběr síťových a systémových metrik, sledování systémových volání, bezpečnostní audit a hlubokou diagnostiku anomálií bez nutnosti zasahovat do aplikačního kódu.

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

RBAC pro čtení metrik a logů; tajemství (tokeny, přihlašovací údaje) maskujte již na straně agenta.
Pod Security a NetworkPolicies omezují blast radius; endpointy pro logging a metriky chraňte (TLS, autentizace), nesdílejte 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ěť, počet podů, HPA cíle a aktuální stav.
Pod health: počet restartů, readiness, liveness, OOM, throttling, GC, event loop lag (u Node.js), heap a GC (u JVM).
Infra: uzly, allocatable vs. requested, pod scheduler waiting, diskové I/O, síťová propustnost.
Business SLI: doménové metriky (úspěšnost checkoutu, objednávky za minutu), navázané na SLO a error budget.

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

Aplikace exportuje HTTP metriky (Prometheus client) a OpenTelemetry trasy.
HPA škáluje na základě průměrné hodnoty inflight požadavků na pod (cílová hodnota 50).
KEDA zvyšuje počet workerů podle lag ve frontě (Kafka topic lag > 10 000).
Cluster Autoscaler přidává nody, pokud HPA narazí na nedostatek zdrojů; VPA doporučuje nové hodnoty requests.
Alerty jsou vázané na SLO p95 latence a chybovost s dobou trvání for: 10 minut, propojené s runbooky a detailní diagnostikou (dotazy LogQL v Lokim, trasování v Jaegeru).

Konfigurace scrape a service discovery

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