Kubernetes testing: Čo potrebuješ vedieť o testovaní v K8s

Autor:  Michaela Kojnoková

Testovanie • 16 min. čítania • 30. 4. 2026

Autor:  Michaela Kojnoková •

Testovanie • 16 min. čítania • 30. 4. 2026

Kubernetes testing je testovanie aplikácií, konfigurácií a celého prostredia v Kubernetes klastri. Na rozdiel od klasického testovania ti nestačí overiť, že API vracia správny kód, ale overuješ aj orchestráciu, sieť, bezpečnosť, škálovanie a odolnosť celého systému. Spoznaj typy testov, prehľad nástrojov (KUTTL, Testkube, k6, Litmus), praktický CI/CD workflow a best practices, ktoré ti pomôžu s rýchlym nasadením bez prekvapení v produkcii.

Kubernetes (K8s) je dnes štandardom pre správu kontajnerizovaných aplikácií. Monolitické aplikácie nahradili mikroservisy, servery sa zmenili na kontajnery a správa infraštruktúry je dnes automatizovaná. V centre tohto posunu stojí Kubernetes – open-source platforma na orchestráciu kontajnerov, ktorá pomáha spravovať kontajnerizované aplikácie vo veľkom rozsahu.

Testovanie v Kubernetes preto nie je len o UI a API testoch. Overuješ, či celé prostredie drží pokope, či sa vie zotaviť po výpadku, či je bezpečné a zvládne loadové špičky bez výpadkov. Pribudnú aj nové vrstvy: service discovery, YAML manifesty, Helm charty, RBAC politiky a CI/CD pipeline napojená na klaster.

Čo je Kubernetes a prečo ho potrebuješ poznať

Kubernetes, označovaný aj ako K8s, je open-source systém na orchestráciu kontajnerov. Pomáha vývojárom, testerom aj DevOps tímom riadiť aplikácie tak, aby boli spoľahlivé, dostupné a škálovateľné – či už v cloude, dátovom centre alebo lokálne.

Kubernetes vs Docker: Aký je medzi nimi rozdiel?

Docker vytvára a spúšťa kontajnery – zabalené aplikácie s ich závislosťami. Kubernetes tieto kontajnery orchestruje. Rozhoduje, kde, kedy a koľko ich má bežať, ako medzi sebou komunikujú, ako sa obnovia po zlyhaní a ako sa škálujú podľa aktuálnej záťaže. Kubernetes vs Docker nie je otázka „čo je lepšie“ – v praxi ich používaš spolu.

Architektúra Kubernetes (Control Plane + Nodes)

Kubernetes sa skladá z dvoch hlavných častí – Control Plane a Nodes. Pre testera je dôležité rozumieť architektúre Kubernetes, pretože chyby môžu vzniknúť na ktorejkoľvek vrstve:

Z testerského pohľadu sa väčšina problémov v Kubernetes neprejavuje ako klasická aplikačná chyba, ale ako infraštruktúrny problém. Kubernetes Pod nenaštartuje kvôli zlým resource limitom, Service neroutuje traffic kvôli chybnému Selector labelu, alebo Kubernetes Ingress nefunguje kvôli chýbajúcej TLS konfigurácii. Preto je pochopenie architektúry základ pre efektívne debugovanie.

Základné pojmy v Kubernetes

Pri testovaní v Kubernetes sa stretneš najčastejšie s týmito pojmami:

Prečo testovať v Kubernetes?

Testovanie softvéru v Kubernetes klastri je odlišné od testovania na lokálnom stroji. Pribudne orchestrácia, siete, service discovery, environment premenné, Secrets a storage. Tu je päť hlavných dôvodov, prečo testovať systematicky.

1. Funkčnosť aplikácie v kontajnerovom prostredí

Aplikácia v kontajneri sa správa inak ako na laptope developera. V Kubernetes pribudne orchestrácia, siete, env premenné a Secrets. Testovaním overíš, že aplikácia beží správne, komunikuje s databázou a službami a správa sa v klastri tak, ako očakávaš.

2. Prevádzková spoľahlivosť a self-healing

Chyby v YAML manifestoch, zlé limity CPU a RAM, chýbajúce readiness a liveness probes, nesprávne network policies alebo service routovanie vedia zložiť produkciu. Testy tieto chyby nájdu skôr, než sa prejavia ako incident. Kubernetes má samoliečenie (self-healing) – ak Pod zlyhá, automaticky ho nahradí novým. Ale to funguje len vtedy, keď sú správne nastavené probes a limity.

3. Výkon a škálovanie (HPA)

Pod záťažou musí aplikácia aj klaster reagovať správne. Testovaním identifikuješ bottlenecks, overíš správanie Horizontal Pod Autoscaler (HPA), reakciu na špičky a to, či storage a sieť nebudú brzdiť. Bez záťažových testov sa o limitoch dozvieš až v produkcii.

4. Bezpečnosť a prístupové politiky

Kubernetes poskytuje Role-Based Access Control (RBAC), ktorý určuje, kto a k čomu má prístup. Bez testovania bezpečnostných politík riskuješ nezabezpečené endpointy a únik dát. Testy RBAC a Network Policies sú v regulovaných odvetviach povinnosťou.

5. CI/CD integrácia a konfigurácie

V modernom vývoji sa softvér nasadzuje niekoľkokrát za deň. Testy integrované do CI/CD pipeline zachytia regresie pred nasadením. Validácia YAML manifestov, Helm chartov a konfigurácií je prvá línia obrany. Lacnejší defekt nájdeš v pipeline ako v produkcii.

Testovanie17 min.

31. 10. 2024

Úloha a vplyv DevOps na testovanie

V tomto článku sa pozrieme na to, čo je DevOps a akú úlohu a vplyv má na testovanie softvéru.

Typy testov v Kubernetes

Testovanie v Kubernetes pokrýva široké spektrum od statickej analýzy manifestov až po chaos experimenty. Tu je prehľad hlavných typov testov a ich účel.

Konfiguračné a statické testy (linting)

Lintovanie a testovanie pravidiel nad manifestmi pomáhajú odhaliť chyby ešte pred nasadením. Overuješ YAML manifesty, Helm charty, RBAC, sieťové politiky, resource limity, secrets a storage väzby. Nástroje ako Conftest, kube-linter a kube-score ti pomôžu chyby nájsť skôr, než sa dostanú do klastra. Typicky testovanými objektmi sú Kubernetes Deployment (resource limity, image tag), Ingress (TLS, annotations) a Namespace (label politiky).

Príklad Conftest politiky:

package main
deny[msg] {
  input.kind == "Deployment"
  not input.spec.template.spec.containers[_].resources
  msg = "Containers must have resource limits"
}
 
// Spustenie:
// conftest test my-deployment.yaml

Funkčné a integračné testy

Overujú komunikáciu medzi mikroservismi a databázami, často v dočasnom klastri. Vhodné na testovanie eventov, queue, transakcií a API kontraktov. End-to-end testy simulujú reálne používateľské toky naprieč službami a validujú celý biznis tok, logging, metriky a chybové stavy.

Nástroje: KUTTL (deklaratívny testovací harness pre operátory), Chainsaw (E2E sekvencie s assertmi), Testkube (Kubernetes-native orchestrátor, ktorý vie spúšťať Postman, Cypress, k6 priamo v klastri).

Testovanie výkonu a záťaže

Load tests – Kubernetes: Záťažové testy v Kubernetes simulujú reálnu prevádzku aj extrémy. Sleduješ throughput, latenciu, chybovosť, 95. a 99. percentil a overuješ automatické škálovanie. Výsledky vizualizuješ v Grafana cez Prometheus metriky. Je to kombinácia, ktorá ti dá úplný prehľad o správaní systému pod tlakom.

Čo overuje záťažový test v Kubernetes:

• Throughput a latencia: koľko requestov za sekundu zvládne aplikácia a ako rýchlo odpovedá
• HPA správanie: škáluje Horizontal Pod Autoscaler správne? Pridáva Pody včas alebo až keď je neskoro?
• Resource limity: nestane sa, že Pod spotrebuje pridelenú RAM a Kubernetes ho reštartuje (OOMKilled)?
• Sieťová priepustnosť: komunikujú mikroservisy dostatočne rýchlo aj pod záťažou?
• Cold start: ako dlho trvá, kým nový Pod začne obsluhovať requesty po horizontálnom škálovaní?

Príklad záťažového testu s k6:

import http from 'k6/http';
import { check, sleep } from 'k6';
export let options = { vus: 50, duration: '2m' };
export default function () {
  const res = http.get(__ENV.API_URL);
  check(res, { 'status 200': r => r.status === 200 });
  sleep(1);
}

k6 vieš spustiť priamo v klastri, metriky posiela do Prometheus a Grafana ti ich zobrazí v reálnom čase. Pre JMeter v Kubernetes použi Kubernetes Job alebo Testkube.

Chaos engineering a testovanie odolnosti

Úmyselne rozbíjaš veci a sleduješ, či sa systém zotaví. Zabíjaš Pody, spomaľuješ sieť, simuluješ výpadok nódov a kontroluješ, či funguje self-healing a fallbacky.

Probes sú kľúčové – liveness probe reštartuje Pod pri zacyklení, readiness probe odoberie Pod z load balancera ak nie je pripravený, startup probe dá aplikácii čas na inicializáciu. Bez správne nastavených probes je chaos engineering chaosom bez kontroly.

Nástroje: Litmus (Chaos Engineering platforma pre Kubernetes, CNCF projekt), Kube-monkey (náhodné zabíjanie Podov podľa pravidiel).

Odporúčame ti…

Chaos experimenty spúšťaj najprv v stagingu s definovaným „steady state“ – čo má systém robiť za normálnych podmienok. Bez tohto bodu porovnania nevieš, či sa systém správa správne alebo nie.

Bezpečnostné testy

RBAC testovanie, Network Policies, skenovanie image kontajnerov. Overenie, že kontajnery nebežia ako root a majú obmedzené capabilities. V regulovaných odvetviach (poistné systémy, finančné služby) je bezpečnostné testovanie povinnou súčasťou každého releasu.

Základný kubectl príkaz na overenie RBAC oprávnení:

# Overenie, či má service account prístup k resource
kubectl auth can-i get pods --as=system:serviceaccount:default:my-sa
 
# Zoznam všetkých RBAC rolí v namespace
kubectl get rolebindings,clusterrolebindings -n my-namespace
 
# Audit - kto má prístup k Secrets
kubectl get rolebindings -o json | jq '.items[] | select(.roleRef.name=="secret-reader")'

Testovanie22 min.

29. 11. 2024

Penetračné testovanie – penetration testing: fázy, typy, metódy, nástroje a príklady scenárov

V tomto článku sa dozvieš, čo je penetračné testovanie a aké sú fázy, typy, metódy, nástroje a príklady scenárov pen testingu.

Testcontainers: testovanie s reálnymi závislosťami

Testcontainers je knižnica, ktorá umožňuje písať testy s reálnymi závislosťami ako databázy, fronty alebo iné služby a bez mockovania. Každá závislosť beží v skutočnom Docker kontajneri, ktorý sa spustí pred testom a automaticky zastaví po jeho skončení.

Prečo je to dôležité pre Kubernetes testera? Pretože rozdiel medzi mockom a skutočnou databázou je obrovský. Mock nevráti rovnaké chybové správy, nespráva sa rovnako pri connection timeout a nikdy ťa neprekvapí race condition. Testcontainers ti dá reálne správanie pri zachovaní rýchlosti unit testu.

Kedy použiť Testcontainers vs. plný K8s klaster

Pripravili sme pre teba prehľadné porovnanie, kedy použiť Testcontainers a kedy Kubernetes.

Odporúčaná stratégia: Testcontainers pre integračné testy v PR pipeline, Kubernetes cluster pre E2E, záťažové a chaos testy v stagingu. Ušetríš čas aj peniaze.

Odporúčame ti…

Ak tím prechádza z mockovaných testov na Testcontainers, začni s databázou. Je to najjednoduchší prípad a rozdiel v pokrytí chýb pocítiš okamžite. Až keď tímu Testcontainers dôveruje, pridávaj ďalšie závislosti ako message broker, cache, externé API.

Ako debugovať zlyhávajúce testy v Kubernetes

Testy v Kubernetes zlyhávajú inak ako klasické testy. Chyba nie je vždy v kóde. Môže byť v konfigurácii, sieti, resource limitoch alebo v samotnom stave klastra. Tu je systematický postup, ako sa k tomu postaviť.

Základné kubectl príkazy pre testera

Tieto príkazy budeš používať najčastejšie pri diagnostike zlyhaní:

# Stav všetkých Podov v namespace
kubectl get pods -n my-namespace
 
# Detail Podu - udalosti, dôvod zlyhania, reštarty
kubectl describe pod my-pod-name -n my-namespace
 
# Logy Podu (prípadne konkrétneho kontajnera)
kubectl logs my-pod-name -n my-namespace
kubectl logs my-pod-name -c my-container -n my-namespace
 
# Logy predchádzajúcej inštancie (ak Pod reštartoval)
kubectl logs my-pod-name --previous -n my-namespace
 
# Spusti shell v bežiacom kontajneri
kubectl exec -it my-pod-name -n my-namespace -- /bin/sh
 
# Zisti stav Deploymentu
kubectl rollout status deployment/my-app -n my-namespace

Najčastejšie príčiny zlyhaní testov v K8s

• CrashLoopBackOff: Pod sa spustí, spadne a Kubernetes ho opakovane reštartuje. Najčastejšia príčina: zlá konfigurácia, chýbajúci Secret alebo ConfigMap, alebo aplikácia spadne pri štarte.
• Pending Pod: Pod čaká na nasadenie. Príčina: klaster nemá dostatok CPU/RAM, alebo Node selector nezodpovedá žiadnemu Node.
• ImagePullBackOff: Kubernetes nevie stiahnuť Docker image. Príčina: nesprávny tag, privátny registry bez pull secret, alebo sieťový problém.
• OOMKilled: Pod bol zabitý kvôli prekročeniu pamäťového limitu. Príčina: memory limit je príliš nízky, alebo aplikácia má memory leak.
• Connection refused/timeout v testoch: Service nie je dostupná. Príčina: zlý Selector label, chýbajúci Port v Service definícii, alebo Network Policy blokuje traffic.

Odporúčame ti…

Keď test zlyhá s nejasnou chybou, prvý príkaz je vždy kubectl describe pod. Sekcia Events na konci výstupu ti povie presne, čo sa stalo. Napríklad prečo Pod nenaštartoval, prečo bol zabitý, prečo obraz nešlo stiahnuť. Je to rýchlejšie ako čítať logy.

Nástroje na testovanie v Kubernetes

Kubernetes testing tools pokrývajú rôzne aspekty od lintingu až po chaos engineering.

Nástroje na konfiguračné testy

Pozri si prehľad nástrojov na konfiguračné testy podľa ich účelu a využitia:

Nástroje na E2E a integračné testy

Nástroje na výkon a chaos

Praktický workflow testovania v CI/CD

Testovanie v Kubernetes sa najlepšie integruje priamo do CI/CD pipeline. Tu je 9 krokov, ktoré pokrývajú celý cyklus od buildu až po produkciu:

1. Build Docker image: Vytvorí image, taguje s commit SHA pre sledovateľnosť.
2. Statický a security scan imagov: Nástroje ako Trivy alebo Snyk odhalia zraniteľnosti v base image ešte pred deployom.
3. Deploy na dočasné prostredie v klastri: Efemérny Kubernetes namespace izolovaný pre daný PR alebo branch.
4. Spusti API a integračné testy: KUTTL, Chainsaw alebo Testkube orchestrujú testy priamo v klastri.
5. Prebehni conftest, kube-linter, kube-score nad manifestmi: Zachytí chýbajúce resource limity, zlé security kontexty.
6. Spusti vybrané load testy a HPA check: k6 s 50 virtuálnymi používateľmi, over, že HPA škáluje správne.
7. Voliteľne chaos experiment v stagingu: Litmus zabije náhodný Pod a sleduj, či sa systém zotaví.
8. Deploy do produkcie s canary alebo progressive rollout: Nasaď 10 %, sleduj metriky, potom 100 %.
9. Post-deploy smoke test a observabilita: Prometheus zbiera metriky, Grafana zobrazí dashboardy, alerting pri anomáliách.

Pre nastavenie pipeline odporúčame Jenkins alebo GitHub Actions. Oddeľ rýchle smoke a sanity testy od plných sád, paralelizuj testy podľa domén a ukladaj reporty, logy a metriky ako artefakty buildu.

Ukážka jednoduchého GitHub Actions workflow pre K8s testovanie:

name: K8s Test Pipeline
on: [push, pull_request]
jobs:
  test:
	runs-on: ubuntu-latest
	steps:
  	- uses: actions/checkout@v3
  	- name: Setup kubectl
    	uses: azure/setup-kubectl@v3
  	- name: Lint manifests
    	run: |
      	kube-score score k8s/*.yaml
      	conftest test k8s/*.yaml
  	- name: Deploy to ephemeral namespace
    	run: |
      	kubectl create namespace pr-${{ github.event.number }}
      	helm upgrade --install app ./chart -n pr-${{ github.event.number }}
  	- name: Run integration tests
    	run: kubectl kuttl test --namespace pr-${{ github.event.number }}
  	- name: Cleanup
    	if: always()
    	run: kubectl delete namespace pr-${{ github.event.number }}

Testovanie16 min.

5. 9. 2024

Continuous testing v DevOps a agilnom vývoji

V tomto článku sa dozvieš, čo je continuous testing, aké má výhody, výzvy pri jeho nasadení, tipy a tooly, ktoré môžeš využiť pri testovaní.

Efemérne prostredia a shift left/right

Efemérne prostredia sú krátkodobé izolované deploymenty vytvorené pre každý pull request alebo branch. Každý vývojár dostane vlastné prostredie v klastri bez toho, aby kolidoval s ostatnými. Po merge sa prostredie automaticky zruší.

Ako to funguje v praxi:

1. Pre každý PR vytvoríš dedikovaný Namespace s názvom podľa PR čísla (napríklad pr-142).
2. Helm alebo Kustomize nasadí aplikáciu s konfiguráciou pre dané prostredie.
3. CI/CD pipeline spustí základný smoke test a integračné testy.
4. Preview URL sprístupní prostredie na manuálne overenie a code review.
5. Po merge alebo zatvorení PR sa Namespace automaticky vymaže.

Výhody efemérnych prostredí:

• Skoršie zachytenie integračných chýb
• Nulová kolízia medzi vývojármi
• Menšie náklady než trvalé prostredie

Nevýhody efemérnych prostredí:

• Vyšší overhead na správu: Každý PR vyžaduje plnohodnotný deploy, čo môže predĺžiť CI/CD pipeline.

Shift left znamená presun testov čo najskôr do vývoja: Statická analýza manifestov v PR, unit a kontraktné testy na lokálnom stroji, integračné testy v efemérnych prostrediach ešte pred mergom do main branche. Čím skôr nájdeš chybu, tým lacnejšie ju opravíš.

Shift right je opak – kontinuálne testovanie priamo v prevádzke. Syntetické sondy overujú dostupnosť 24/7, canary deployment nasadí novú verziu len pre 5 % traffic a sleduje chybovosť, feature flagy umožňujú A/B testovanie bez nového deployu. Oba prístupy sa dopĺňajú a spolu pokrývajú celý životný cyklus aplikácie.

Testovanie18 min.

23. 9. 2024

QAOps – budúcnosť testovania softvéru

V tomto článku sa dozvieš čo je QAOps, aké sú jeho výhody, výzvy a aký je rozdiel medzi DevOps a QAOps.

Best practices pre Kubernetes testing

Súbor osvedčených postupov, ktoré ti pomôžu udržiavať kvalitu v Kubernetes prostredí:

• Infra a app testy ako kód, verzované v Gite.
• Lintuj manifesty a politiky pred každým deployom (conftest, kube-score).
• Definuj minimálne požiadavky na resources a limity pre každý Pod.
• Používaj Pod Disruption Budgets a stratégie rolloutov.
• Izoluj test dáta a seeduj ich pred behom. Každý test musí začínať v čistom stave.
• Loguj request ID a sleduj trace naprieč službami (distributed tracing).
• Nespúšťaj kontajnery ako root a obmedz capabilities.
• Plánuj pravidelné chaos a DR cvičenia aspoň raz za štvrťrok.
• Meraj a reportuj SLO a chybovosť testov cez Prometheus a Grafana.
• Buduj knižnice zdieľaných helperov pre testy. Neopakuj sa.

V regulovaných odvetviach (poistné systémy, finančné služby) je dôležité mať testovanie zdokumentované a auditovateľné – každý test run s časovou pečiatkou, výsledkami a logovacím kontextom.

Zdieľaj článok

Kubernetes testing: Čo potrebuješ vedieť o testovaní v K8s

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn