Kubernetes Interview Questions and Answers

Both manage Pods, but they make different guarantees.

Deployment:

• Manages stateless, interchangeable replicas identified by a random suffix.
• Supports rolling updates and rollbacks, and Pods are created and deleted in any order.
• Uses a ReplicaSet under the hood.

StatefulSet:

• Manages stateful workloads with stable identity. Pods get ordinal names such as web-0 and web-1, stable network identities through a headless Service, and stable PersistentVolumeClaims.
• Pods are created, scaled, and deleted in order, which matters for clustered databases.

apiVersion: apps/v1
kind: StatefulSet
metadata: {name: db}
spec:
  serviceName: db
  replicas: 3
  template: {spec: {containers: [{name: db, image: postgres:16}]}}

Use Deployments for stateless web apps and StatefulSets for databases, queues, and anything needing stable storage or ordering.

Kubernetes gives stable access to moving Pods through Services and DNS.

• A Service selects Pods by label and gets a stable virtual IP, the ClusterIP, and a DNS name.
• kube-proxy programs iptables or IPVS rules on each node so traffic to the ClusterIP is load-balanced to healthy endpoints.
• Endpoints, or EndpointSlices, are updated by the control plane as Pods become ready or are removed.
• CoreDNS resolves service names in the form service.namespace.svc.cluster.local. Short names work within the same namespace.

Service types:

• ClusterIP: internal only, the default.
• NodePort: exposes a port on every node.
• LoadBalancer: provisions an external load balancer.
• ExternalName: aliases an external DNS name.

kubectl get svc,endpoints
nslookup api.default.svc.cluster.local

Headless Services with clusterIP set to None return Pod IPs directly, which is useful for StatefulSets.

A Service exposes a set of Pods at the transport layer; an Ingress exposes HTTP and HTTPS routes into the cluster at the application layer.

• Service: stable virtual IP and DNS, layer 4 load balancing over TCP and UDP. Types are ClusterIP, NodePort, LoadBalancer, and ExternalName. It cannot route by host or path.
• Ingress: layer 7 rules that map hostnames and URL paths to Services, with TLS termination. It requires an Ingress controller, such as nginx, Traefik, or the AWS ALB controller, to be installed. Ingress itself only describes routing.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: {name: web}
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend: {service: {name: web, port: {number: 80}}}

Use a Service for internal and non-HTTP traffic, and add an Ingress or the newer Gateway API for HTTP routing and TLS.

Probes let Kubernetes decide a container's health and readiness.

• readinessProbe: whether the Pod should receive traffic. Failing it removes the Pod from Service endpoints but does not restart it. Use it while warming up or when a dependency is down.
• livenessProbe: whether the container is alive. Failing it restarts the container. Use it to recover from deadlocks, not for dependency failures.
• startupProbe: gives slow-starting apps time to boot. Until it succeeds, liveness and readiness are disabled, preventing restart loops.

livenessProbe:
  httpGet: {path: /healthz, port: 8080}
  initialDelaySeconds: 10
  periodSeconds: 10
readinessProbe:
  httpGet: {path: /ready, port: 8080}

Set realistic thresholds. An aggressive liveness probe causes cascading restarts, and a missing readiness probe sends traffic to unready Pods. Prefer HTTP checks that test real dependencies.

The Horizontal Pod Autoscaler, or HPA, scales the number of Pod replicas based on observed metrics.

• The metrics-server, or a custom or external adapter, supplies metrics. The HPA controller polls every 15 seconds by default.
• The desired replica count is currentReplicas multiplied by the ratio of the current metric to the target metric, clamped by minReplicas and maxReplicas.
• Metrics can be CPU, memory, or custom metrics such as requests per second or queue depth.

kubectl autoscale deployment web --cpu-percent=70 --min=2 --max=10
kubectl get hpa

Important points:

• Pods must have resource requests set or CPU utilisation is undefined.
• Add stabilisation windows and scale-down delay to avoid flapping.
• HPA scales Pods, not nodes, so combine it with the cluster autoscaler so new Pods can schedule.
• For event-driven workloads, KEDA scales on external metrics such as queue length.

Both decouple configuration from container images, but they differ in intent and handling.

• ConfigMap: non-sensitive key-value data or files. Consume it as environment variables or mounted volumes.
• Secret: sensitive data such as passwords, tokens, and certificates. Stored base64-encoded, and by default not encrypted at rest unless you enable encryption or use a KMS provider. Restrict access with RBAC.

apiVersion: v1
kind: ConfigMap
metadata: {name: app-config}
data:
  LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata: {name: app-secret}
type: Opaque
stringData:
  DB_PASSWORD: change-me

kubectl create configmap app-config --from-file=config.yaml
kubectl create secret generic app-secret --from-literal=DB_PASSWORD=change-me

Mount as volumes when you want automatic updates; environment variables do not refresh. Avoid committing Secrets to Git, and use External Secrets or Sealed Secrets instead.