Kubernetes

Docker runs a container on a host. Kubernetes (K8s) runs thousands across a fleet of machines — scheduling them, restarting failures, scaling on load, and rolling out new versions with zero downtime.

You declare the desired state (“3 replicas of this image”); Kubernetes continuously reconciles reality to match it.

• Self-healing — a crashed Pod is recreated; a dead node’s Pods are rescheduled.
• Horizontal scaling — add/remove replicas by hand or automatically on CPU/metrics.
• Rolling updates & rollback — ship a new version gradually, revert instantly if it’s bad.
• Service discovery & load balancing — stable names and traffic spreading across replicas.

A cluster = a control plane (the brain) + worker nodes (where Pods run).

• Pod — the smallest unit: one (or a few tightly-coupled) containers sharing a network/IP and storage. Pods are ephemeral — they come and go with new IPs.
• ReplicaSet — keeps N identical Pods running.
• Deployment — manages ReplicaSets to give you rolling updates and rollbacks; what you actually write for stateless apps.
• StatefulSet — for stateful apps (databases) needing stable identity and storage; DaemonSet — one Pod per node (agents); Job/CronJob — run-to-completion / scheduled tasks.

apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3                 # desired state
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: myapp:1.2
          ports: [{ containerPort: 3000 }]

Pods are ephemeral with changing IPs, so you never talk to a Pod directly. A Service gives a stable virtual IP + DNS name and load-balances across the matching Pods.

Ingress sits in front of Services as an HTTP(S) router — host/path rules, TLS termination — so many apps share one external entry point instead of one LoadBalancer each.

• ConfigMap — non-sensitive config (URLs, feature flags) injected as env vars or mounted files. Keeps config out of the image.
• Secret — same idea for sensitive data (passwords, tokens, TLS keys); base64-encoded and access-controlled (enable encryption-at-rest / external secret stores in prod).
• Namespaces — virtual partitions of one cluster (e.g. dev, staging, test) for isolation and quotas.

env:
  - name: LOG_LEVEL
    valueFrom: { configMapKeyRef: { name: app-config, key: log_level } }
  - name: DB_PASSWORD
    valueFrom: { secretKeyRef: { name: db-secret, key: password } }

K8s keeps apps healthy using probes — periodic checks the kubelet runs against each container.

• Liveness — “is it alive?” Fails → container is restarted. Catches deadlocks.
• Readiness — “can it serve traffic?” Fails → Pod is pulled from the Service’s load balancer (but not killed). Catches warm-up/dependency waits.
• Startup — guards slow-starting apps so liveness doesn’t kill them prematurely.

readinessProbe:
  httpGet: { path: /healthz, port: 3000 }
  initialDelaySeconds: 5
  periodSeconds: 10

• Manual scale — kubectl scale deploy/web --replicas=5.
• HPA (Horizontal Pod Autoscaler) — adds/removes replicas automatically on CPU/memory/custom metrics.
• Rolling update — the default: replace Pods gradually so there’s no downtime; kubectl rollout undo reverts.
• Resource requests/limits — requests guide scheduling; limits cap usage (over the memory limit → the container is OOM-killed).

kubectl set image deploy/web web=myapp:1.3   # trigger a rolling update
kubectl rollout status deploy/web            # watch it
kubectl rollout undo  deploy/web             # roll back if bad

Where an SDET actually touches K8s:

• Ephemeral test environments — spin up a namespace (or a whole throwaway cluster) per branch/PR, deploy the app, run E2E, tear it down.
• Local clusters — kind (Kubernetes-in-Docker) or minikube to run a real cluster in CI or on your laptop.
• kubectl for debugging — get, describe, logs, exec, port-forward are your triage toolkit when a test deployment misbehaves.
• Helm — templated, versioned manifests (“charts”) so the same deploy is parameterized across dev/test/prod.

kubectl get pods -n test                 # what's running
kubectl describe pod web-xyz -n test     # events: why is it pending/crashing?
kubectl logs -f web-xyz -n test          # app output
kubectl port-forward svc/web 8080:80     # hit the service locally for a test