EN

Kubernetes (K8S)

Referenční dovednost pro Kubernetes: příkazy kubectl pro pody, deploymenty, služby, síťování, RBAC, Helm a řešení problémů v clusteru.

Kubernetes (K8S)

Referenční dovednost pro Kubernetes: příkazy kubectl pro pody, deploymenty, služby, síťování, RBAC, Helm, observabilitu, GitOps, bezpečnost a řešení problémů v clusteru.

Co tato dovednost pokrývá

Provoz Kubernetes (K8s) od základní správy podů přes deployment strategie, síťování a bezpečnost až po administraci clusteru — příkazy kubectl a helm a YAML manifesty potřebné k běžnému provozu a řešení problémů clusteru. Nově pokrývá také ekosystém kolem clusteru: observabilitu (Prometheus, Grafana, OpenTelemetry), GitOps nasazování (Flux, Argo CD), bezpečnostní skenování a runtime detekci (Trivy, Falco) a doporučenou cestu učení včetně přípravy na certifikace CKA/CKAD/CKS.

Kdy ji použít

  • Zakládání nebo administrace Kubernetes clusteru (uzly, namespacy, RBAC)
  • Nasazení, škálování nebo rollback aplikace pomocí Deploymentů
  • Ladění podu uvízlého ve stavu Pending, CrashLoopBackOff nebo ImagePullBackOff
  • Vystavení služby dovnitř nebo ven (Services, Ingress, DNS)
  • Správa konfigurace a tajemství (ConfigMaps, Secrets, TLS, přihlašovací údaje k registru)
  • Instalace nebo upgrade aplikací pomocí Helm chartů (včetně ladění šablon)
  • Vyšetřování uzlu ve stavu NotReady nebo tlaku na zdroje
  • Psaní nebo revize Kubernetes YAML manifestů (Pod, Deployment, Service)
  • Zavedení monitoringu a alertingu (Prometheus, Grafana) nebo instrumentace aplikací (OpenTelemetry)
  • Přechod na GitOps workflow (Flux, Argo CD) nebo progresivní nasazování (Argo Rollouts)
  • Skenování imagí a manifestů (Trivy) a runtime detekce hrozeb (Falco)
  • Příprava na certifikace CKA / CKAD / CKS

Základní koncepty

Architektura Kubernetes

  • Control Plane: API Server, etcd, Controller Manager, Scheduler
  • Worker Nodes: Kubelet, Kube Proxy, Container Runtime
  • Pods: Nejmenší nasaditelná jednotka obsahující jeden nebo více kontejnerů
  • Services: Síťová abstrakce pro pody
  • Deployments: Deklarativní způsob správy replik podů
  • ConfigMaps/Secrets: Správa konfigurace a citlivých dat

Tip pro pochopení architektury: Projděte si jednou Kubernetes the Hard Way — ruční bootstrap clusteru (certifikáty, etcd, API server, kubelet) bez kubeadm. Po jednom průchodu už nikdy nezapomenete, co control plane skutečně dělá: např. že s etcd komunikuje pouze API server a že kubelet si sám hlídá pody přiřazené svému uzlu.

Ekosystém CNCF

Cloud-native nástroje mají u CNCF tři úrovně zralosti:

  • Graduated — bezpečná produkční volba (Kubernetes, Prometheus, Helm, Envoy, Falco, Flux, Argo)
  • Incubating — ověřené, ale stále se vyvíjející projekty
  • Sandbox — experimentální projekty

Úroveň zralosti je užitečný filtr: když někdo navrhne nový nástroj, jeho CNCF tier hodně napoví o zdraví komunity a dlouhodobé životaschopnosti.

Správa podů

Základní příkazy pro pody

# Get pods
kubectl get pods
kubectl get pods -o wide          # Detailed view
kubectl get pods -w               # Watch mode
kubectl get pods -o yaml          # YAML output

# Pod operations
kubectl describe pod <pod-name>   # Detailed information
kubectl logs <pod-name>           # View logs
kubectl logs -f <pod-name>        # Follow logs
kubectl logs --previous <pod-name>  # Logs from crashed container
kubectl exec -it <pod-name> -- /bin/bash  # Execute into pod

# Debug distroless/minimal images (no shell inside)
kubectl debug -it <pod-name> --image=busybox --target=<container-name>

# Pod lifecycle
kubectl delete pod <pod-name>     # Delete pod
kubectl edit pod <pod-name>       # Edit pod

Vytváření podů

# Create pod from image
kubectl run <pod-name> --image=<image-name>

# Create pod with port and expose as service
kubectl run <pod-name> --image=<image-name> --port=<port> --expose

# Generate pod YAML
kubectl run <pod-name> --image=<image-name> --dry-run=client -o yaml > pod.yaml

Správa uzlů

Operace s uzly

# Get nodes
kubectl get nodes
kubectl get nodes -o wide
kubectl describe node <node-name>

# Node maintenance
kubectl drain <node-name> --ignore-daemonsets  # Safely evict pods
kubectl cordon <node-name>        # Mark as unschedulable
kubectl uncordon <node-name>      # Allow scheduling

Vytváření zdrojů

Aplikace manifestů

# Apply single file
kubectl apply -f <file>.yaml

# Apply multiple files
kubectl apply -f <file1>.yaml -f <file2>.yaml

# Apply directory
kubectl apply -f ./<directory>/

# Apply from URL
kubectl apply -f https://<url>

# Diff before apply
kubectl diff -f <file>.yaml

Imperativní vytváření zdrojů

# Create deployment
kubectl create deployment <name> --image=<image>
kubectl create deployment <name> --image=<image> --dry-run=client -o yaml > deployment.yaml

# Create service
kubectl create service <type> <name> --tcp=<port>:<target-port>
kubectl create service <type> <name> --tcp=<port>:<target-port> --dry-run=client -o yaml > service.yaml

# Expose existing deployment
kubectl expose deployment <name> --type=<type> --port=<port> --target-port=<target-port>

Správa konfigurace

# Create ConfigMap
kubectl create configmap <name> --from-literal=<key>=<value>
kubectl create configmap <name> --from-file=<file>
kubectl create configmap <name> --from-env-file=<file>

# Create Secret
kubectl create secret generic <name> --from-literal=<key>=<value>
kubectl create secret generic <name> --from-file=<file>

Monitoring a řešení problémů

Monitorování zdrojů

# Node utilization
kubectl top nodes
kubectl top node <node-name>

# Pod utilization
kubectl top pods
kubectl top pods <pod-name>

Ladicí příkazy

# Check pod status
kubectl get pods
kubectl describe pod <pod-name>

# Check logs
kubectl logs <pod-name>
kubectl logs <pod-name> -c <container-name>  # Multi-container pods

# Check events
kubectl get events --sort-by=.metadata.creationTimestamp
kubectl events --for pod/<pod-name>            # Events for one object
kubectl get events --field-selector involvedObject.name=<pod-name>

# Port forwarding for debugging
kubectl port-forward pod/<pod-name> <local-port>:<pod-port>

Observabilita (Prometheus, Grafana, OpenTelemetry)

Observabilita není volitelná — zaveďte ji dřív, než si myslíte, že ji potřebujete. Tři vrstvy tvoří jeden celek:

Prometheus — metriky

De facto standard pro metriky v Kubernetes: pull-based scraping, time-series databáze, dotazovací jazyk PromQL a Alertmanager pro alerting.

Klíčové koncepty: counter vs. gauge vs. histogram, service discovery, recording rules. V K8s se typicky nasazuje přes kube-prometheus-stack, který automaticky scrapuje control plane, uzly a anotované pody.

# Install kube-prometheus-stack via Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

# Access Prometheus / Grafana locally
kubectl port-forward svc/monitoring-kube-prometheus-prometheus 9090:9090 -n monitoring
kubectl port-forward svc/monitoring-grafana 3000:80 -n monitoring

Užitečné PromQL vzory:

# CPU throttling (častý problém ze špatných limitů)
rate(container_cpu_cfs_throttled_seconds_total[5m])

# Pody blízko memory limitu (kandidáti na OOMKill)
container_memory_working_set_bytes / on(pod) kube_pod_container_resource_limits{resource="memory"} > 0.9

# Restarty kontejnerů za poslední hodinu
increase(kube_pod_container_status_restarts_total[1h]) > 0

Grafana — vizualizace

Vizualizační vrstva nad Prometheem (a Loki pro logy, Tempo pro traces). Cílem jsou dashboardy, které odhalují problémy, ne dashboardy, které jen dobře vypadají:

  • RED metoda pro služby: Rate (počet requestů), Errors (chybovost), Duration (latence)
  • USE metoda pro zdroje: Utilization, Saturation, Errors

Lepší jsou 4 panely, na které se někdo dívá, než 40 panelů, které nikdo nečte. Praktické tutoriály: grafana.com/tutorials.

OpenTelemetry — instrumentace

Vendor-neutrální standard pro traces, metriky a logy. Jedno SDK/API pro instrumentaci kódu, OTel Collector pro příjem/zpracování/export telemetrie — backend (Prometheus, Jaeger, Datadog…) lze vyměnit bez reinstrumentace aplikací.

OpenTelemetry vyhrálo válku standardů — učit se vendor-specifické agenty je dnes ztracený čas. Začněte na opentelemetry.io/docs.

# OTel Collector via Helm
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector -n observability --create-namespace \
  --set mode=deployment

GitOps a nasazování (Flux, Argo)

Princip GitOps

Git repozitář je jediný zdroj pravdy o stavu clusteru. GitOps controller v clusteru průběžně rekonciliuje skutečný stav s deklarovaným — ruční kubectl apply drift se automaticky vrátí zpět. Žádné kubectl apply z lokálu do produkce.

Flux

Minimalistický a kompozitní GitOps controller (CNCF graduated). Doporučuji pochopit Flux před Argem — učí čistý rekonciliační model. Dokumentace: fluxcd.io/docs.

# Bootstrap Flux against a GitLab repo
flux bootstrap gitlab --owner=<group> --repository=<repo> --branch=main --path=clusters/production

# Check reconciliation status
flux get kustomizations
flux get helmreleases

# Force reconciliation
flux reconcile kustomization <name> --with-source

# Suspend/resume (e.g. during incident)
flux suspend kustomization <name>
flux resume kustomization <name>

Argo projekt

Čtyři nástroje v jednom projektu (argoproj.github.io):

  • Argo CD — GitOps se silným UI, hlavní konkurent Fluxu
  • Argo Rollouts — progresivní nasazování: canary, blue-green, automatický rollback na základě metrik (integrace s Prometheem)
  • Argo Workflows — orchestrace jobů jako DAG, rozšířené v ML pipelinech
  • Argo Events — event-driven triggery
# Argo CD basics
argocd app list
argocd app sync <app-name>
argocd app diff <app-name>
argocd app rollback <app-name>

# Argo Rollouts
kubectl argo rollouts get rollout <name> --watch
kubectl argo rollouts promote <name>
kubectl argo rollouts abort <name>

Flux vs. Argo CD: většina týmů si vybere jeden z nich. Flux je minimalistický a skládatelný (vhodný jako infrastruktura pod platformou), Argo CD má silné UI a multi-tenancy (vhodné, když GitOps používají i vývojáři přes rozhraní). Argo Rollouts má hodnotu bez ohledu na to, který GitOps nástroj zvolíte.

Síťování

Síťové politiky

# Get network policies
kubectl get networkpolicies
kubectl describe networkpolicy <name>

# Apply network policy
kubectl apply -f network-policy.yaml

DNS a služby

# Service DNS format
<service-name>.<namespace>.svc.cluster.local

# Test DNS resolution
kubectl run test-pod --image=busybox:1.36 --rm -it -- nslookup <service-name>

Správa deploymentů

Operace s deploymenty

# Get deployments
kubectl get deployments
kubectl get deployment <deployment-name>
kubectl describe deployment <deployment-name>

# Scale deployment
kubectl scale deployment <name> --replicas=<count>

# Update deployment
kubectl set image deployment/<name> <container>=<new-image>
kubectl rollout status deployment/<name>

# Rollback deployment
kubectl rollout undo deployment/<name>
kubectl rollout undo deployment/<name> --to-revision=<number>

Rolling updates

# Check rollout status
kubectl rollout status deployment/<name>

# Pause/resume rollout
kubectl rollout pause deployment/<name>
kubectl rollout resume deployment/<name>

# View rollout history
kubectl rollout history deployment/<name>

Pozn.: Pro canary a blue-green nasazení s automatickým rollbackem podle metrik viz Argo Rollouts výše — nativní Deployment umí jen rolling update.

Správa služeb

Typy služeb

# ClusterIP (default)
kubectl create service clusterip <name> --tcp=<port>:<target-port>

# NodePort
kubectl create service nodeport <name> --tcp=<port>:<target-port> --node-port=<node-port>

# LoadBalancer
kubectl create service loadbalancer <name> --tcp=<port>:<target-port>

# ExternalName
kubectl create service externalname <name> --external-name=<external-name>

Objevování služeb

# Get services
kubectl get services
kubectl get svc
kubectl describe service <name>

# Test service connectivity
kubectl run test-pod --image=busybox:1.36 --rm -it -- wget <service-name>:<port>

Konfigurace a úložiště

Persistentní svazky

# Get PV/PVC
kubectl get pv
kubectl get pvc

# Create PVC
kubectl apply -f pvc.yaml

# Check storage classes
kubectl get storageclass

Správa Ingress

# Get ingresses
kubectl get ingress
kubectl describe ingress <name>

# Create ingress
kubectl create ingress <name> --rule="<host>/<path>=<service>:<port>"

Pokročilé operace

Namespacy

# Get namespaces
kubectl get namespaces
kubectl get ns

# Create namespace
kubectl create namespace <name>

# Switch context to namespace
kubectl config set-context --current --namespace=<name>

# Get resources in all namespaces
kubectl get pods --all-namespaces

Labely a selektory

# Label resources
kubectl label pods <pod-name> app=web
kubectl label nodes <node-name> disktype=ssd

# Select with labels
kubectl get pods -l app=web
kubectl get pods -l 'app in (web,api)'

# Remove labels
kubectl label pods <pod-name> app-

Kvóty zdrojů

# Get resource quotas
kubectl get resourcequotas
kubectl describe resourcequota <name>

# Create resource quota
kubectl create quota <name> --hard=cpu=2,memory=4Gi,pods=10

Bezpečnost

RBAC (Role-Based Access Control)

# Get roles/rolebindings
kubectl get roles
kubectl get rolebindings
kubectl get clusterroles
kubectl get clusterrolebindings

# Create service account
kubectl create serviceaccount <name>

# Bind role to user/serviceaccount
kubectl create rolebinding <name> --role=<role> --user=<user>

# Verify permissions
kubectl auth can-i create deployments --as=system:serviceaccount:<ns>:<sa>

Správa Secrets

# Get secrets
kubectl get secrets
kubectl describe secret <name>

# Create TLS secret
kubectl create secret tls <name> --cert=<cert-file> --key=<key-file>

# Create docker registry secret
kubectl create secret docker-registry <name> --docker-server=<server> --docker-username=<user> --docker-password=<pass>

Security contexts a Pod Security Standards

# Security context na úrovni kontejneru
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

# Vynucení Pod Security Standards na namespace
kubectl label namespace <name> pod-security.kubernetes.io/enforce=restricted

Trivy — skenování před nasazením (shift-left)

Jeden nástroj na CVE v imagích, misconfigurace IaC (K8s manifesty, Dockerfile, Terraform), detekci secrets a generování SBOM. Triviálně se zapojuje do GitLab CI — není výmluva ho nepoužívat. Dokumentace: trivy.dev.

# Scan container image for CVEs
trivy image <image>:<tag>

# Scan K8s manifests / Helm chart for misconfigurations
trivy config ./manifests/
trivy config ./chart/

# Scan running cluster
trivy k8s --report summary

# Fail CI on HIGH/CRITICAL
trivy image --exit-code 1 --severity HIGH,CRITICAL <image>:<tag>

Ukázka GitLab CI jobu:

container_scanning:
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

Falco — runtime detekce hrozeb

Druhá polovina bezpečnostního příběhu: Trivy brání nasazení známě špatného, Falco hlídá, co se děje po nasazení. Přes eBPF sleduje syscally a alertuje na podezřelé chování: shell spuštěný v kontejneru, neočekávané odchozí spojení, čtení citlivých souborů, eskalace privilegií. Nástroj, který si přejete mít před incidentem, ne po něm. Dokumentace: falco.org.

# Install Falco via Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco -n falco --create-namespace

# Watch alerts
kubectl logs -l app.kubernetes.io/name=falco -n falco -f

Helm (správce balíčků)

Používat ho budete, ať se vám líbí nebo ne — prakticky vše třetí strany (kube-prometheus-stack, ingress-nginx, cert-manager, Falco…) se distribuuje jako Helm chart. Dokumentace: helm.sh/docs.

Základní operace

# Repositories
helm repo add <name> <url>
helm repo update
helm search repo <keyword>

# Install / upgrade / rollback
helm install <release-name> <chart-name> -n <namespace> --create-namespace
helm upgrade <release-name> <chart-name>
helm upgrade --install <release-name> <chart-name>   # Idempotent (CI/CD friendly)
helm rollback <release-name> <revision>

# Inspect
helm list -A
helm status <release-name>
helm history <release-name>

# Uninstall
helm uninstall <release-name>

Hodnoty (values) a přepisy

# Show default values of a chart
helm show values <chart-name> > values.yaml

# Install with custom values
helm install <release-name> <chart-name> -f values.yaml
helm install <release-name> <chart-name> --set image.tag=1.2.3

# Show values of a deployed release
helm get values <release-name>

Ladění šablon

# Render templates locally WITHOUT installing (key debugging tool)
helm template <release-name> <chart-name> -f values.yaml

# Dry run against the cluster (validates against API server)
helm install <release-name> <chart-name> --dry-run --debug

# Lint chart
helm lint ./chart/

Go templating v YAML nemá nikdo rád, ale helm template + helm lint udělají z ladění chartů zvládnutelnou disciplínu.

Řešení běžných problémů

Reálné post-mortemy týmů na k8s.af (Kubernetes Failure Stories) učí víc než jakýkoli kurz — opakující se vzory: špatné resource limity (CPU throttling, OOMKill), DNS (je to vždycky DNS), expirace certifikátů a rozbité upgrady.

Problémy s pody

# Pod stuck in Pending
kubectl describe pod <pod-name>  # Check events
kubectl get nodes                # Check node capacity

# Pod CrashLoopBackOff
kubectl logs --previous <pod-name>  # Logs from the crashed run
kubectl describe pod <pod-name>     # Check exit codes (137 = OOMKill)

# Pod in ImagePullBackOff
kubectl describe pod <pod-name>  # Check image pull errors
kubectl get secrets              # Check registry credentials

Problémy se službami

# Service not accessible
kubectl get endpoints <service-name>  # Check if pods are selected
kubectl get pods -l <selector>        # Check pod labels

# DNS resolution issues
kubectl run test-pod --image=busybox:1.36 --rm -it -- nslookup <service-name>

Problémy s uzly

# Node NotReady
kubectl describe node <node-name>     # Check conditions

# Resource pressure
kubectl top nodes                     # Check resource usage
kubectl get pods -o wide              # Check pod distribution

Osvědčené postupy

  1. Limity zdrojů: Vždy nastavte requests/limits CPU a paměti — a sledujte throttling v Prometheu
  2. Health Checks: Implementujte readiness a liveness probes
  3. Rolling Updates: Pro nasazení bez výpadku; pro canary/blue-green použijte Argo Rollouts
  4. Správa Secrets: Nikdy neukládejte tajemství do kódu ani ConfigMap
  5. Síťové politiky: Implementujte síťovou segmentaci
  6. Observabilita: Prometheus + Grafana (RED/USE dashboardy) + OpenTelemetry instrumentace od začátku
  7. GitOps: Git jako zdroj pravdy (Flux nebo Argo CD), žádný ruční kubectl apply do produkce
  8. Zálohování: Pravidelně zálohujte etcd a persistentní data
  9. Bezpečnost: RBAC, security contexts, Pod Security Standards; Trivy v CI (shift-left) + Falco v runtime
  10. Pinované image tagy: Nikdy latest — vždy konkrétní verze nebo digest
  11. Aktualizace: Udržujte cluster i aplikace aktuální
  12. Dokumentace: Dokumentujte konfiguraci a procesy clusteru

Příklady YAML manifestů

Manifest Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
  - name: my-container
    image: nginx:1.27-alpine   # Pinned tag, never :latest
    ports:
    - containerPort: 80
    resources:
      limits:
        cpu: 100m
        memory: 128Mi
      requests:
        cpu: 50m
        memory: 64Mi
    securityContext:
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

Manifest Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 200m
            memory: 128Mi

Manifest Service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Cesta učení a certifikace

Doporučené pořadí:

  1. Kubernetes the Hard Way — jednou ručně, pro mentální model control plane
  2. roadmap.sh/kubernetes — mapa dovedností; odhalí slepá místa a pomůže naplánovat pořadí učení
  3. Základní kubectl praxe — tato příručka
  4. Helm — balíčkování; budete ho potřebovat pro vše ostatní
  5. Prometheus + Grafana — observabilita od začátku, ne až po prvním incidentu
  6. GitOps — Flux pro čistý rekonciliační model, pak Argo (CD, Rollouts, Workflows, Events)
  7. Trivy + Falco — bezpečnost build-time i runtime
  8. OpenTelemetry — instrumentace aplikací vendor-neutrálním standardem
  9. killer.sh — simulátor zkoušek CKA/CKAD/CKS; záměrně těžší než reálná zkouška (rozbité clustery, RBAC hádanky, etcd backup/restore); dvě sezení zdarma při registraci zkoušky u Linux Foundation

Průběžně: k8s.af (failure stories z reálných týmů) a cncf.io/projects (mapa ekosystému podle zralosti).

← Zpět na úvod