Orchestrace Kubernetes

Proč orchestrace kontejnerů a proč právě Kubernetes

Kontejnerizace standardizuje balení aplikací a jejich závislostí, ale až orchestrace řeší provoz v rozsahu: plánování (scheduling), samoléčbu (self-healing), vyrovnávání zátěže, rollouty a bezpečnost. Kubernetes (K8s) je de-facto standard pro orchestraci – otevřený, rozšiřitelný a nezávislý na cloudovém prostředí. Umožňuje provozovat mikroslužby, batch úlohy i stavové aplikace, a to na holém železe, on-premise clusterech i v cloudu.

Architektura Kubernetes: řídicí rovina a datová rovina

Řídicí rovina (control plane):
- kube-apiserver – jediný autoritativní vstup do clusteru (REST), validace a mutace objektů.
- etcd – distribuovaný key-value store pro chtěný i aktuální stav clusteru.
- kube-scheduler – plánuje Pody na uzly podle dostupných zdrojů, afinit a omezení.
- kube-controller-manager – kontrolery udržující požadovaný stav (Deployment, Node, Service, EndpointSlice a další).
- cloud-controller-manager – integrace s cloudovými službami (LoadBalancer, uzly, svazky).
Datová rovina (data plane):
- kubelet – agent na uzlu, zajišťuje běh Podů podle specifikace PodSpec.
- kube-proxy – implementuje síťové služby (iptables/ipvs) pro Service.
- Container runtime – například containerd, CRI-O.

Základní objekty: od Podu po Deployment

Pod – nejmenší plánovatelná jednotka (jeden nebo více úzce svázaných kontejnerů se sdílenou sítí a úložišti).
ReplicaSet – udržuje počet replik Podů; nepoužívá se přímo, ale prostřednictvím Deploymentu.
Deployment – deklarativní rollout/rollback stateless workloadů.
StatefulSet – zajišťuje pořadí, stabilní identity a per-Pod perzistentní svazky pro stavové služby (databáze, fronty).
DaemonSet – běh Podu na každém (nebo vybraném) uzlu (například agent, log shipper).
Job/CronJob – jednorázové a plánované dávkové úlohy.

Expozice služeb: Service, Ingress a Gateway API

Service – stabilní virtuální IP/DNS pro skupinu Podů (label selector). Typy: ClusterIP (interní), NodePort (expozice přes porty uzlů), LoadBalancer (L4 load balancer v cloudu).
Ingress – L7 (HTTP/HTTPS) směrování na základě hostitelů a cest; vyžaduje Ingress Controller.
Gateway API – moderní náhrada Ingress s jednoznačnějším modelem (GatewayClass, HTTPRoute, TCPRoute) a lepší podporou traffic politik.

Konfigurace a tajemství: ConfigMap, Secret a správa prostředí

ConfigMap – nekritická konfigurace (klíč–hodnota, soubory) montovaná jako soubory nebo proměnné prostředí.
Secret – citlivá data (base64 v etcd, doporučeno šifrování v klidu a využití KMS). Podpora imagePullSecrets a TLS.
Downward API – promítá metadata (labely, zdroje) do prostředí kontejneru.

Úložiště: Volumes, PVC/PV, StorageClass a CSI

Volume – svazek připojený do Podu (emptyDir, configMap, secret, projected).
PersistentVolume (PV) a PersistentVolumeClaim (PVC) – abstrakce perzistentního úložiště nezávislá na životním cyklu Podu.
StorageClass – parametry dynamického provisioningu (typ disku, zónování, replikace).
CSI (Container Storage Interface) – standardizovaný model ovladačů pro storage (RWO, RWX, RWOP; snapshoty, rozšiřování kapacity).

Plánování a umísťování: affinity, taints & tolerations, topology

Node/Pod affinity & anti-affinity – pravidla pro přitahování či oddělení workloadů (využití zón, vysoká dostupnost, anti-colocation primár/sekundár).
Taints & tolerations – odpuzování nechtěných workloadů (dedikované node pooly, GPU, latency-sensitive aplikace).
Topology spread constraints – rovnoměrné rozprostření replik mezi zóny a uzly.
Resource requests/limits – zajišťují spravedlivé plánování a ochranu uzlů před OOM a throttlingem.

QoS třídy, limity a řízení zdrojů

QoS Guaranteed – request = limit pro CPU i paměť → nejvyšší priorita při tlaku na zdroje.
QoS Burstable – definované requesty, limity jsou vyšší nebo chybějící.
QoS BestEffort – bez requestů; nejnižší priorita, riziko evikce.
LimitRange a ResourceQuota – guardraily na úrovni Namespace.

Autoscaling: HPA, VPA a Cluster Autoscaler

Horizontal Pod Autoscaler (HPA) – mění počet replik podle metrik (CPU, paměť, custom/external Prometheus). Vyhlazování, cool-downs a minimální/maximální počet replik.
Vertical Pod Autoscaler (VPA) – doporučuje nebo automaticky upravuje requesty/limity (často v režimu „recommendation“ pro stabilitu).
Cluster Autoscaler – škáluje node pool podle neschedulovatelných Podů (přes cloudové API nebo on-prem integrace).

Networking: CNI, DNS a NetworkPolicies

CNI pluginy – Calico, Cilium, Flannel, Weave a další (různé vlastnosti: eBPF datapath, enforcement NetworkPolicy, WireGuard šifrování).
Cluster DNS (CoreDNS) – service discovery, headless Service pro přímé rozlišení Podů (stabilní identity ve StatefulSet).
NetworkPolicy – L3/L4 politiky pro příchozí a odchozí spojení mezi Pody a namespaces; default-deny je doporučený výchozí stav.

Bezpečnost: RBAC, Pod Security, admission a supply chain

RBAC – Role/ClusterRole + (Cluster)RoleBinding; princip nejmenších oprávnění a oddělení povinností.
Pod Security Standards (PSS) – baseline/restricted profily uplatňované přes namespace policy (náhrada za PSP). Omezují privilegia, hostPath, capabilities, seccomp, AppArmor.
Admission control – Validating/Mutating webhooks (OPA Gatekeeper, Kyverno) pro guardraily (například povinné livenessProbes, zákaz :latest tagu).
Supply chain – podepisování obrazů (Cosign), enforcement politik (Sigstore), skenování CVE (Trivy, Grype), privátní registry a imagePullPolicy/immutabilní tagy.

Observabilita: readiness/liveness/startup, logy a metriky

Probes – readiness řídí zařazení do load balanceru, liveness restartuje container při zacyklení, startup chrání před restartem při pomalém startu.
Logování – stdout/stderr, sidecar shipper, log-agent jako DaemonSet; korelace pomocí labelů a trace ID.
Metriky – Metrics Server pro HPA, Prometheus pro detailní sběr metrik, Grafana pro dashboardy, OpenTelemetry pro distribuované trasování.

Nasazování: rollouty, strategie a progressive delivery

RollingUpdate – postupná obměna replik (maxUnavailable/maxSurge).
Blue-Green – paralelní verze a přepnutí směrování provozu.
Canary/Progressive – postupné navyšování provozu na novou verzi, monitoring metrik a automatické revertování (Argo Rollouts, Flagger).
Rollback – návrat k předchozím verzím pomocí historie Deploymentů.

Konfigurace na úrovni kódu: Helm, Kustomize a GitOps

Helm – balíčkování manifestů, templating, values a správa releasů.
Kustomize – deklarativní „overlay“ přístup bez templatingu (patches, bases, generators).
GitOps – Argo CD/Flux: jediný zdroj pravdy v Gitu, rekonsiliace stavu, auditní stopa, propagace do více prostředí.

Rozšiřitelnost: CRD, Operátoři a API rozšíření

CRD (CustomResourceDefinition) – vlastní zdroje (např. KafkaTopic, Backup).
Operator pattern – kontroler automatizující doménovou logiku (provoz DB clusteru, zálohy, upgrady).
Webhooks a rozšíření API – validace, mutace a audit podle interních pravidel.

Více clusterů, edge a federace

Multi-cluster – izolace prostředí, regionální vysoká dostupnost, řízení provozu přes globální load balancer a service mesh (Istio/Linkerd) se multi-cluster gateways.
Federace – sjednocené řízení vybraných objektů napříč clustery (omezené použití, častěji GitOps multi-target).
Edge – lehké distribuce (K3s, MicroK8s), přerušovaná konektivita, lokální cache registrů a OTA aktualizace.

Service Mesh: správa provozu a pozorovatelnost na L7

Sidecar proxy – transparentní mTLS, retries, circuit breaking, rate limiting.
Traffic management – routing podle hlaviček a cest, canary/AB testy, fault injection.
Telemetrie – jednotné metriky, logy a trasování napříč službami.

Životní cyklus clusteru: instalace, upgrady a zálohy

Instalace – spravované (GKE/AKS/EKS), on-premise (kubeadm, Rancher/RKE2, OpenShift), lehké distribuce (K3s).
Upgrady – nejdříve control plane, poté uzly po dávkách; kontrola kompatibility API a deprecací; tzv. canary node pool.
Zálohy – snapshoty etcd, zálohy PersistentVolume (CSI snapshoty, storage-native řešení), obnova pomocí Velero/Restic.

Bezpečná konfigurace Podů: seccomp, capabilities a rootless

SecurityContext – provoz jako ne-root uživatel, readOnlyRootFilesystem, omezení Linux capabilities s výchozím drop ALL a výjimkou nutných capability.
Seccomp/AppArmor – profily omezující systémy volání a chování procesů.
Host namespaces – vyhýbat se hostNetwork, hostPID a hostIPC bez závažného důvodu.

Typické YAML manifesty: minimální příklady

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        readinessProbe:
          httpGet:
            path: "/"
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80

Nejčastější proti-vzory a jak se jim vyhnout

:latest image tag – nepředvídatelné rollouty; vždy používejte neměnné tagy nebo digesty.
Bez definovaných requestů a limitů – nekontrolované plánování, riziko OOM; nastavte rozumné baseline hodnoty.
Jedna replika pro kritickou službu – žádná vysoká dostupnost; používejte minimálně 2–3 repliky a topology spread constraints.
Smíchání citlivých a necitlivých workloadů – oddělte pomocí taints, node poolů, NetworkPolicies a RBAC.
Konfigurace přímo v obrazu – použijte ConfigMap a Secret; oddělte build (immutable) od runtime konfigurace.

Best practices pro produkční provoz

Definujte ResourceQuota a LimitRange na každém namespace.
Zaveďte NetworkPolicy default-deny a povolujte pouze potřebné síťové toky.
Prosazujte bezpečnostní standardy pomocí admission policy (Kyverno/OPA).
Automatizujte nasazení přes GitOps s validací a canary rollouty.
Měřte a monitorujte SLO/SLI (latence, chybovost, saturace), sledujte zdraví etcd a control plane.
Plánujte disaster recovery včetně pravidelných testů obnovy.