Kubernetes orchestrace

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

Kontejnerizace standardizuje balení aplikací a jejich závislostí, ale až orchestrace řeší provoz ve škále: 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 cloud-agnostický. Umožňuje provozovat mikroslužby, batch úlohy i stavové aplikace, a to na holém železe, on-prem 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.
  • kube-scheduler – plánuje Pody na uzly dle zdrojů, afinit a omezení.
  • kube-controller-manager – kontrolery udržující stav (Deployment, Node, Service, EndpointSlice aj.).
  • cloud-controller-manager – integrace s cloudy (LoadBalancer, uzly, svazky).
• Datová rovina (data plane):
  • kubelet – agent na uzlu, zajišťuje běh podů podle PodSpec.
  • kube-proxy – implementuje síťové služby (iptables/ipvs) pro Service.
  • Container runtime – např. containerd, CRI-O.

Základní objekty: od Podu po Deployment

• Pod – nejmenší plánovatelná jednotka (jedna 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 přes Deployment.
• Deployment – deklarativní rollout/rollback stateless workloadů.
• StatefulSet – pořadí, stabilní identity a per-pod perzistentní svazky pro stavové služby (DB, fronty).
• DaemonSet – běh Podu na každém (nebo vybraném) uzlu (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 LB v cloudu).
• Ingress – L7 (HTTP/HTTPS) směrování na základě hostů/cest; vyžaduje Ingress Controller.
• Gateway API – moderní náhrada Ingress s jednoznačnějším modelem (GatewayClass, HTTPRoute, TCPRoute) a lepší podporou traffic-policies.

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

• ConfigMap – nekritická konfigurace (klíč–hodnota, soubory) montovaná jako soubory nebo env proměnné.
• Secret – data citlivá (base64 v etcd, doporučeno šifrování v klidu + KMS). Podpora pro imagePullSecrets a TLS.
• Downward API – promítá metadata (labels, resources) 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 perzistence nezávislá na Podu.
• StorageClass – parametry dynamického provisioningu (typ disku, zónování, replikace).
• CSI (Container Storage Interface) – standardizovaný driver model pro storage (RWO, RWX, RWOP; snapshoty, rozšíření kapacity).

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

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

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

• QoS Guaranteed – request=limit pro CPU i paměť → nejvyšší priorita při tlaku.
• QoS Burstable – definované requesty, limity 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í repliky.
• Vertical Pod Autoscaler (VPA) – doporučuje/automaticky mění requesty/limity (často v „recommendation“ režimu pro stabilitu).
• Cluster Autoscaler – škáluje nodepool podle neschedulovatelných Podů (cloudové API, on-prem integrace).

Networking: CNI, DNS a NetworkPolicies

• CNI pluginy – Calico, Cilium, Flannel, Weave aj. (různé vlastnosti: eBPF datapath, NetworkPolicy enforcement, wireguard šifrování).
• Cluster DNS (CoreDNS) – servis discovery, headless Service pro přímé rozlišení Podů (StatefulSet identity).
• NetworkPolicy – L3/L4 politiky příchozích/odchozích spojení mezi Pody a namespace; 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í, oddělení povinností.
• Pod Security Standards (PSS) – baseline/restricted profily vynucované 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ř. povinné livenessProbes, zákaz :latest tagu).
• Supply chain – podepisování obrazů (Cosign), policy enforcement (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 LB, liveness restartuje při zacyklení, startup chrání pomalý start.
• Logování – stdout/stderr, sidecar shipper, log-agent jako DaemonSet; korelace pomocí labelů a trace IDs.
• Metriky – Metrics Server pro HPA, Prometheus pro detailní scraping, Grafana pro dashboardy, OpenTelemetry pro 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í.
• Canary/Progressive – postupné navyšování provozu na novou verzi, metriky a automatické revertování (Argo Rollouts, Flagger).
• Rollback – Deployment revises; uchovávání historie rolloutů.

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

• Helm – balíčkování manifestů, templating, values a release management.
• Kustomize – deklarativní „overlay“ přístup bez templatingu (patches, bases, generators).
• GitOps – Argo CD/Flux: pravda v Gitu, rekonsiliace stavu, auditní stopa, multi-env propagace.

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

• CRD (CustomResourceDefinition) – vlastní zdroje (např. KafkaTopic, Backup).
• Operator pattern – kontroler, který automatizuje 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í HA, řízení provozu přes global LB 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 – lightweight 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/cest, canary/AB testy, fault injection.
• Telemetrie – jednotné metriky, logy a trace napříč službami.

Životní cyklus clusteru: instalace, upgrady a backup

• Instalace – spravované (GKE/AKS/EKS), on-prem (kubeadm, Rancher/RKE2, OpenShift), lightweight (K3s).
• Upgrady – nejdříve control plane, pak uzly po dávkách; kontrola kompatibility API a deprecations; canary nodepool.
• Zálohy – etcd snapshoty, backup PV (CSI snapshots, storage-native), obnova pomocí Velero/Restic.

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

• SecurityContext – běh jako ne-root, readOnlyRootFilesystem, omezení Linux capabilities, drop ALL + whitelist nutných.
• Seccomp/AppArmor – profily omezující systémová volání a chování procesu.
• Host namespaces – vyhýbat se hostNetwork, hostPID, hostIPC bez silné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žívat neměnné tagy/digesty.
• Bez requestů/limitů – neřízené plánování, OOM; definujte rozumné baseline.
• Jedna replika pro kritickou službu – žádná HA; používejte min. 2–3 repliky a topology spread.
• Promíchání citlivých a necitlivých workloadů – oddělujte pomocí taints, nodepoolů, NetworkPolicies a RBAC.
• Konfigurace v obrazu – použijte ConfigMap/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 jen nutné toky.
• Vynucujte security standardy přes admission policy (Kyverno/OPA).
• Automatizujte nasazení přes GitOps s validací a canary rollouty.
• Měřte a alertujte na SLO/SLI (latence, chybovost, saturace), sledujte etcd a control plane zdraví.
• Plánujte disaster recovery – pravidelné testy obnovy.

Závěr: Kubernetes jako platforma pro škálovatelný a bezpečný provoz

Kubernetes přináší silný deklarativní model, automatizaci a rozšiřitelnost. Správná volba objektů (Deployment/StatefulSet), síťových a bezpečnostních politik, autoscalingu a GitOps přístupu umožní provozovat resilentní systémy v řádech tisíců Podů. Úspěch stojí na disciplíně (limity, politiky, observabilita), automatizaci (CI/CD, GitOps) a neustálé práci s riziky (supply chain, přístupová práva, izolace). Kubernetes není cíl, ale platforma – stavebnice, ze které lze postavit robustní a udržitelný provozní ekosystém.