Explain Pods, Deployments and Services in Kubernetes from a tester's point of view

SDETs rarely administer clusters, but if the system under test runs on Kubernetes you need enough of the model to read failures, reach services and understand why a test hit a half-deployed version.

Pod

A Pod is the smallest thing Kubernetes schedules: one or more containers that share a network namespace (same IP, can talk over localhost) and can share volumes. Usually it is one application container, sometimes with a sidecar such as a proxy or log shipper. Pods are ephemeral: when a node dies or a new version rolls out, Pods are replaced with new ones that have new names and IPs. Never hard-code a Pod IP in a test.

Deployment

A Deployment declares the desired state: “run 3 replicas of image orders:1.4.2”. Through a ReplicaSet it keeps that many Pods running, replacing crashed ones (self-healing), and performs rolling updates when the image changes, gradually starting new Pods and terminating old ones. It also supports rollback.

For testing, a rolling update means that for a short window both versions serve traffic. A test suite that starts the moment the deploy command returns may hit old Pods. Wait for the rollout to finish first.

Service

A Service gives a stable virtual IP and DNS name (for example orders.qa.svc.cluster.local, or just orders from the same namespace) in front of whichever Pods match its label selector, and load-balances between them. Types include ClusterIP (internal only, the default), NodePort and LoadBalancer; an Ingress or Gateway usually exposes HTTP routes externally.

Probes

Readiness probes decide whether a Pod receives Service traffic; liveness probes decide whether to restart it. A missing or shallow readiness probe is a common reason tests see 502/503 errors right after deployment.

Commands I actually use

kubectl get pods -n qa -l app=orders
kubectl rollout status deployment/orders -n qa --timeout=180s
kubectl describe pod orders-6d9f7c9b8-x2k4q -n qa     # events, restarts, probe failures
kubectl logs deployment/orders -n qa --since=15m
kubectl logs orders-6d9f7c9b8-x2k4q -n qa --previous   # logs from the crashed container
kubectl port-forward svc/orders 8080:80 -n qa         # reach an internal service locally

How this helps in testing

• Gate test runs on kubectl rollout status so you test the new version only.
• When a test fails with 5xx, check restarts (CrashLoopBackOff, OOMKilled) and logs before blaming the test.
• Use namespaces to understand environment boundaries; qa and staging may share a cluster.

What interviewers look for

• Accurate definitions and how the three relate (Deployment creates Pods, Service routes to them by label).
• Awareness that Pods are ephemeral and rolling updates mix versions.
• Practical kubectl debugging skills.