Kubernetes basics for testers (2026)

TL;DR

Kubernetes basics for testers means using kubectl to inspect pods, services, config, and rollouts so you can validate cloud-native apps and file high-signal bugs. Focus on namespaces, deployments, probes, logs, and CI deploy-then-test flows.

Key Takeaways

• Master get, describe, logs, exec, port-forward, and rollout status first.
• Pods are ephemeral; Deployments declare desired replicas and updates.
• Readiness probes control traffic; liveness probes restart containers.
• Events and --previous logs explain ImagePullBackOff and CrashLoopBackOff.
• Port-forward helps exploratory tests; Ingress paths matter for realism.
• Wait for rollouts before smoke tests to avoid flakes.
• Coordinate resources before load testing shared namespaces.

Kubernetes basics for testers are the practical cluster skills QA and SDET engineers need to validate cloud-native apps without becoming full-time platform engineers. In 2026, staging is often a namespace, test jobs run as pods, and failures show up as CrashLoopBackOff rather than a red JUnit icon. If you can read pod status, port-forward a service, inspect logs, and reason about ConfigMaps, probes, and rollouts, you debug faster and design better environment strategies.

This guide covers core objects, kubectl for QA workflows, how tests run in-cluster or against clusters, health probes, common failure modes, and interview Q&A. Pair with Docker basics for testers for container foundations and Docker Compose for test environments for local multi-service stacks before you graduate to full clusters.

TL;DR

Learn kubectl get/describe/logs/exec/port-forward first. That set solves most day-to-day tester needs.

1. Why Kubernetes Basics for Testers Matter

Testers touch Kubernetes when:

• The app under test deploys via Helm or GitOps to a namespace
• Ephemeral preview environments spin up per pull request
• Automation runs in-cluster as Jobs or CronJobs
• Failures are pod scheduling, probe, or config issues rather than pure code bugs
• Logs and metrics live behind cluster-centric tooling

Without Kubernetes literacy, QA opens a ticket for every log line. With literacy, you gather evidence: pod events, previous container logs, image tags, probe failures, and service endpoints. That evidence shortens MTTR and raises the quality of bugs you file.

Kubernetes is also a test design constraint. Rolling updates, multiple replicas, and eventual consistency change how you assert state. "Restart the server" becomes "roll the deployment" or "delete the pod and let the ReplicaSet recreate it."

2. Architecture Picture in Plain Language

Control plane schedules workloads and stores desired state (API server, scheduler, controllers, etcd). Nodes run kubelet and your pods. You almost always interact through the API using kubectl or a CI service account, not by SSHing to nodes first.

Desired state is declarative. You say "I want three replicas of api:1.4.2" and controllers converge reality toward that. Tests that race a rollout without waiting for readiness will flake. Waiting for rollout status is part of Kubernetes basics for testers.

kubectl rollout status deployment/api -n qa --timeout=180s

3. Install kubectl and Reach a Cluster

Install kubectl from official Kubernetes documentation for your OS. Obtain kubeconfig from your platform team (file merged into ~/.kube/config or KUBECONFIG env var). Never commit kubeconfigs with embedded credentials to app repos.

kubectl version --client
kubectl config get-contexts
kubectl config use-context staging-admin
kubectl get ns
kubectl get pods -n qa

If you use a cloud lab (kind, minikube, k3d) locally:

# example with kind (requires kind + docker)
kind create cluster --name qa-lab
kubectl cluster-info

Local clusters are perfect for learning objects safely. Corporate clusters need less experimentation and more read-only discipline.

4. Namespaces, Labels, and Finding Your App

kubectl get all -n qa
kubectl get pods -n qa -l app=payments
kubectl get deploy,svc,ingress -n qa

Labels are key/value pairs used for selection. Services select pods by labels. Your test docs should record namespace, common labels, and how to identify the build under test (image tag annotation, version endpoint, or ConfigMap).

kubectl get pods -n qa -o wide
kubectl describe pod <pod-name> -n qa

describe shows events: failed mounts, probe failures, image pull errors. Events are often the difference between "pod is broken" and "ImagePullBackOff on private registry auth."

5. Pods, Containers, Logs, and Exec

kubectl logs <pod> -n qa
kubectl logs <pod> -n qa -c <container>     # multi-container pod
kubectl logs <pod> -n qa --previous         # last crashed instance
kubectl logs -f deploy/api -n qa            # follow via pick of pods

Shell when policy allows:

kubectl exec -it <pod> -n qa -- /bin/sh

Distroless images may lack a shell; then prefer logs, debug sidecars, or ephemeral debug containers if your cluster version and policies enable them.

Copy files (for example, exported reports):

kubectl cp qa/<pod>:/tmp/report.xml ./report.xml

6. Deployments, ReplicaSets, and Rollouts

A Deployment owns ReplicaSets, which own pods. Scaling:

kubectl scale deploy/api --replicas=3 -n qa

Rollout history:

kubectl rollout history deploy/api -n qa
kubectl rollout undo deploy/api -n qa

Testers validate rollouts by watching readiness, running smoke tests during deploy, and checking that old pods terminate cleanly. Canary and blue/green patterns add routing complexity; coordinate with platform on how traffic splits before asserting cross-version behavior.

7. Services, Port-Forward, and Ingress

Pods die and change IPs. Services provide stable virtual IPs and DNS names inside the cluster (api.qa.svc.cluster.local style names depending on setup).

From your laptop, reach a service without public Ingress:

kubectl port-forward svc/api 8080:80 -n qa
# hit http://localhost:8080 from host tests

Port-forward is excellent for manual exploratory testing and local automation against a remote namespace. It is not a load testing strategy; throughput and fidelity differ from real Ingress paths.

Ingress (or modern gateways) expose HTTP routes. Testers should know the external base URL, TLS termination point, and whether path-based routing differs from local Compose setups. Broken Ingress annotations present as 404s that look like app bugs.

8. ConfigMaps, Secrets, and Environment Drift

kubectl get configmap -n qa
kubectl describe configmap app-config -n qa
kubectl get secret -n qa

Many "works in dev only" bugs are config drift: wrong feature flag, DB URL, or queue name. Compare ConfigMaps between environments (without printing secret values into tickets). Confirm which keys your app expects and whether a release forgot to update Helm values.

Never paste production secrets into Slack or test management tools. Reference secret names and key identifiers only.

9. Health Probes and Why Tests Time Out

Kubernetes uses:

• livenessProbe: restart container when dead
• readinessProbe: remove pod from Service endpoints when not ready
• startupProbe: give slow apps time before liveness kicks in

If readiness is strict, a Service may have zero endpoints during migrations; tests see connection failures. If liveness is too aggressive, pods restart under load and create flaky suites.

kubectl describe pod <pod> -n qa | sed -n '/Conditions:/,/Events:/p'
kubectl get endpoints -n qa

When filing bugs, include probe configuration summaries and restart counts (kubectl get pods RESTARTS column). That is high-signal Kubernetes basics for testers in incident channels.

10. Jobs, CronJobs, and Test Runners In-Cluster

Batch tests or data seeders often run as Jobs:

apiVersion: batch/v1
kind: Job
metadata:
  name: api-smoke
  namespace: qa
spec:
  template:
    spec:
      containers:
        - name: k6
          image: grafana/k6:0.54.0
          args: ["run", "/scripts/smoke.js"]
          volumeMounts:
            - name: scripts
              mountPath: /scripts
      restartPolicy: Never
      volumes:
        - name: scripts
          configMap:
            name: k6-smoke-scripts
  backoffLimit: 1

Apply and inspect:

kubectl apply -f job-smoke.yaml
kubectl wait --for=condition=complete job/api-smoke -n qa --timeout=300s
kubectl logs job/api-smoke -n qa

CI may instead run tests outside the cluster against an Ingress URL. Both models are valid. In-cluster runners reduce network hops and DNS surprises; out-of-cluster runners match real client paths more closely for edge testing.

11. Resource Limits, QoS, and Performance Test Caution

CPU and memory requests/limits affect scheduling and throttling. Performance tests against a namespace with tiny limits measure the limits, not the product. Coordinate resource quotas before load tests. See designing a load model and finding a performance bottleneck.

kubectl describe pod <pod> -n qa | grep -A5 Limits
kubectl top pod -n qa   # if metrics-server exists

OOMKilled in restarts is a tester-visible signal: memory leak or undersized limit. Capture it in the defect.

12. RBAC Reality for QA Accounts

You may have namespace-scoped read access plus limited exec. Some clusters deny pods/exec entirely. Learn what your service account can do:

kubectl auth can-i get pods -n qa
kubectl auth can-i create jobs -n qa
kubectl auth can-i exec into pods -n qa

Design automation to succeed under least privilege: prefer logs and HTTP probes over privileged debug.

13. Comparing Local Docker Compose vs Kubernetes for QA

Use Compose for fast local loops. Use Kubernetes environments for integration that depends on Ingress, sidecars, service mesh behavior, or cloud IAM bindings. Skipping Compose entirely slows developers; skipping k8s validation misses class of defects.

14. Debugging Playbook for Common Symptoms

ImagePullBackOff: registry auth, wrong tag, network policy. Check events.

CrashLoopBackOff: app exits on start; logs --previous, missing env, DB not ready.

Pending pods: insufficient CPU/memory, node selectors, taints, PVC issues.

Service works by port-forward but not externally: Ingress/DNS/TLS problems.

Intermittent 503: readiness flaps, zero endpoints during rollouts.

kubectl get events -n qa --sort-by=.lastTimestamp | tail -n 30

Include timestamps, image digests, and correlation IDs in bugs. Platform engineers trust precise cluster evidence.

15. Safe Test Data and Cleanup in Shared Namespaces

Shared QA namespaces rot: leftover PVCs, orphan Jobs, leftover feature flags. Practices:

• Unique resource names per test run (suffix PR number)
• Time-to-live labels if your platform supports reapers
• Explicit teardown scripts after e2e suites
• Prefer ephemeral namespaces per PR when cost allows

kubectl delete job -l ci-run=$RUN_ID -n qa

Cleanup is part of being a good multi-tenant tester, not optional polish.

16. CI Integration: Deploy Then Test

Typical pipeline:

1. Build image, push registry
2. Deploy to qa via Helm/GitOps
3. kubectl rollout status
4. Run smoke (Postman/k6/Playwright) against Ingress URL
5. Publish results; on failure dump kubectl get pods and logs artifacts

kubectl get pods -n qa -o wide > pods.txt
kubectl logs -l app=api -n qa --tail=200 > api-logs.txt

This artifact pattern turns "pipeline red" into actionable diagnostics. Align with add CI to a test framework for the test runner side.

17. Kubernetes Basics for Testers: What to Defer

You can defer deep expertise in CNI plugins, custom schedulers, and operator Go code. Focus first on objects, kubectl evidence gathering, rollout waiting, config drift, and probe behavior. Expand into Helm values, network policies, and mesh retries when your product's failures demand it.

Kubernetes basics for testers is a bounded skill set: enough to validate and communicate, not enough to own the control plane.

18. Helm Values and What Testers Should Review

Many teams install apps with Helm. You do not need to author charts on day one, but you should read values files for the environment under test.

helm list -n qa
helm get values my-app -n qa
helm history my-app -n qa

Check image tags, replica counts, resource limits, feature flags, and dependency versions. A failed QA cycle often traces to "chart default" values that differ from the Compose file developers use locally. Record the release revision number in test reports so bugs map to a deploy artifact.

When you suspect a values mistake, compare helm get values across qa and staging (redacting secrets). Diffing configuration is a core habit in Kubernetes basics for testers.

19. NetworkPolicies and "It Works With Port-Forward"

NetworkPolicies may allow port-forward paths or certain namespaces while blocking pod-to-pod calls your tests assume. Symptoms: timeouts only for in-cluster clients, successful laptop port-forward, empty responses through mesh.

kubectl get networkpolicy -n qa
kubectl describe networkpolicy <name> -n qa

You may lack rights to change policies. Still, describing them elevates the bug from "API broken" to "egress to payments namespace denied." That accuracy is why platform teams welcome tester kubectl skills.

20. Ephemeral Debug Containers and Distroless Images

Production-like images often omit shells and package managers. If kubectl exec fails because /bin/sh is missing, ask whether ephemeral debug containers are enabled:

kubectl debug -it <pod> -n qa --image=busybox:1.36 --target=<container>

Availability depends on cluster configuration and RBAC. Prefer non-invasive techniques first: logs, metrics, /health endpoints, and event timelines. Debug containers are powerful and easy to misuse on shared environments; clean up sessions and avoid installing random tools into long-lived namespaces.

21. Practical Week-Long Learning Plan

Day 1: Install kubectl, explore namespaces, get/describe pods on a lab cluster.

Day 2: Break a sample Deployment intentionally (bad image tag), practice reading Events and fixing tags.

Day 3: Add readiness probes to a sample app, watch endpoints empty during failures.

Day 4: Port-forward a Service, run a small API test suite against localhost.

Day 5: Apply a Job that runs a smoke script, collect logs, delete the Job.

Day 6: Simulate a rollout and run smoke only after rollout status.

Day 7: Document your company staging map: namespaces, labels, Ingress URLs, who owns quotas.

By day seven, Kubernetes basics for testers should feel operational rather than theoretical. Keep a personal cheatsheet of the twenty commands you actually use.

22. Sample Smoke Script Against a Cluster URL

#!/usr/bin/env bash
set -euo pipefail
NS=${NS:-qa}
DEPLOY=${DEPLOY:-api}
BASE_URL=${BASE_URL:?set BASE_URL to ingress url}

kubectl rollout status "deploy/${DEPLOY}" -n "$NS" --timeout=180s
curl -fsS "$BASE_URL/health" | tee health.json
curl -fsS -o /dev/null -w "%{http_code}\n" "$BASE_URL/ready"

Wire this after deploy steps in CI. It is not a full regression pack, but it catches the class of "pods running yet not serving" issues that pure unit tests miss.

23. Multi-Container Pods and Sidecars

Pods may include sidecars for proxies, log shippers, or authentication helpers. When tests fail with mysterious 403s or mTLS errors, the business container might be fine while the sidecar is misconfigured.

kubectl get pod <pod> -n qa -o jsonpath='{.spec.containers[*].name}{"\n"}'
kubectl logs <pod> -n qa -c istio-proxy   # example name; use your real sidecar

Always identify container names before declaring "the API pod is broken." Kubernetes basics for testers include knowing which container owns the port you call and which container owns the logs you need.

24. PersistentVolumeClaims and Stateful Test Data

Stateful apps use PVCs. Deleting a pod does not always delete data; deleting a PVC might. Testers who reset environments must know whether the database volume survives.

kubectl get pvc -n qa
kubectl describe pvc <pvc> -n qa

Design data strategies explicitly: ephemeral databases rebuilt each run versus persistent shared datasets. Undocumented persistence is a flake factory for integration suites.

25. Image Tags Versus Digests

Floating tags such as api:latest undermine reproducibility. Testers should prefer immutable tags or digests when filing bugs and when verifying what ran.

kubectl get pod <pod> -n qa -o jsonpath='{.status.containerStatuses[*].imageID}{"\n"}'

Include imageID in defect reports. Two engineers saying they tested "1.4" might still run different digests if retags occurred. Kubernetes basics for testers includes treating image identity as part of the environment contract, not optional metadata.

26. Coordinating With GitOps

If Argo CD or Flux applies desired state, manual kubectl edit changes may be overwritten. Prefer changing Git values for durable fixes. For temporary diagnostics, know whether your cluster allows break-glass edits and how long until reconciliation reverts them.

Ask platform for read-only access to the Application status and last sync time. A failed QA cycle after "deploy" sometimes means GitOps never successfully synced the commit you think you tested.

Interview Questions and Answers

Q: What is a pod versus a deployment?

A pod is the smallest runnable unit of one or more containers. A Deployment maintains a desired number of pod replicas and manages rolling updates through ReplicaSets.

Q: How do you get logs from a crashed container?

kubectl logs <pod> --previous (and -c for a specific container) fetches logs from the previous instance after a restart.

Q: Why might a Service have no endpoints?

No pods match the selector, or matching pods are not Ready (failing readiness probes), often during rollouts or misconfig.

Q: What is kubectl port-forward used for in testing?

To tunnel from your machine to a pod or service for exploratory or automated tests without exposing a public route.

Q: Difference between liveness and readiness probes?

Liveness restarts unhealthy containers. Readiness controls whether the pod receives Service traffic. Confusing them causes restarts or traffic to broken instances.

Q: How do you confirm a new version is deployed?

Check Deployment image fields, pod image IDs, rollout status, and an application version endpoint or build metadata.

Q: How should QA run load tests against Kubernetes apps?

Coordinate capacity, avoid tiny quotas, prefer realistic Ingress paths, watch pod restarts and throttling, and separate generator location from SUT namespace when needed.

Common Mistakes

• Treating pods as durable pets instead of cattle.
• Racing tests before rollout readiness.
• Ignoring Events and only reading app logs.
• Port-forwarding for performance tests and trusting the numbers.
• Printing Secrets into tickets or CI logs.
• Assuming Compose networking equals cluster DNS and Ingress.
• Not capturing --previous logs on CrashLoopBackOff.
• Load testing shared QA without resource coordination.
• Leaving orphan Jobs and PVCs after pipelines.
• Using cluster-admin kubeconfigs in app CI when namespace-scoped accounts suffice.
• Filing "API down" without endpoints/probe evidence.
• Forgetting multi-container pods need -c for the right logs.

Conclusion

Kubernetes basics for testers focus on evidence and environment control: namespaces, pods, deployments, services, config, probes, and kubectl workflows that feed better bugs and stabler automation. Learn the core commands, wait for rollouts, and design tests that respect ephemeral pods and readiness.

Next, practice on a local kind/minikube lab, then map the same commands onto your company staging namespace. When containers are still fuzzy, shore up foundations with Docker basics for testers before you dive deeper into cluster networking.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Docker basics for testers (2026)
• Docker for QA Tutorial for Beginners (2026)
• Espresso basics for testers: A Practical Guide (2026)
• Gatling basics for testers: Step by Step (2026)
• Git for QA Tutorial for Beginners (2026)
• Git rebase vs merge for testers (2026)