Kubernetes Interview Guide: Architecture, Pods, Probes, Rolling Updates, Services, Labels, and Data Persistence

Kubernetes (K8s) is an open‑source system for automating deployment, scaling, and management of containerized applications. It originated from Google’s Borg project and provides container orchestration for production environments.

The cluster consists of at least one Master node and multiple Worker (Node) nodes. The Master hosts components such as kubectl , API Server , controller‑manager , scheduler , and etcd . Worker nodes run a container runtime (e.g., Docker), the kubelet agent, kube‑proxy , and host the actual Pods.

Pods are the smallest deployable units; a Pod may contain one or more containers that share network and IPC namespaces while keeping separate UIDs, mount points, and PIDs. Containers start in seconds, enable portable deployment, and simplify data‑persistence considerations.

Pod Health Probes

K8s offers three probe types for pod health monitoring:

livenessProbe – restarts a container when it becomes unhealthy.

readinessProbe – removes a pod from a Service’s endpoints until it is ready.

startupProbe – gives slow‑starting containers extra time before other probes act.

All probes share parameters such as initialDelaySeconds , periodSeconds , timeoutSeconds , and successThreshold . They can be implemented via three methods:

1) Exec

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

2) HttpGet

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        scheme: HTTP
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

3) TcpSocket

spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Rolling Updates

Control parameters can be inspected with:

# kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge defines how many extra pods may be created during an update (percentage or absolute number, default 1). maxUnavailable limits the number of pods that may be unavailable during the rollout.

Image Pull Policy

The imagePullPolicy field accepts three values:

Always – pull the image on every pod start (default for :latest tags).

IfNotPresent – pull only when the image is not present locally (default for non‑latest tags).

Never – never pull; use only a local image.

Pod States and Restart Policies

Pod phases include Running , Pending , Succeeded , Failed , and Unknown . Restart policies are Always (default) and OnFailure .

Service

A Service provides a stable virtual IP and DNS name for a set of Pods, enabling load‑balanced access and decoupling client code from pod IP changes. Service registration is handled automatically by the API server.

Version Rollback

# kubectl apply -f httpd2-deploy1.yaml --record
# kubectl rollout history deployment httpd-deploy1
# kubectl rollout undo deployment httpd-deploy1 --to-revision=1

The revisionHistoryLimit field controls how many old ReplicaSet versions are retained.

Labels and Selectors

Labels are key‑value pairs attached to objects for grouping and selection. Selectors can be equality‑based (e.g., app=nginx ) or set‑based (e.g., in , notin , exists ). Example selector syntax:

selector:
  matchLabels:
    app: nginx
  matchExpressions:
  - {key: name, operator: In, values: [zhangsan, lisi]}
  - {key: age, operator: Exists, values: }

DaemonSet and Job

A DaemonSet ensures a single Pod runs on every node (useful for log collection or node monitoring). A Job runs batch tasks to completion; parallelism and completions can be tuned:

spec:
  parallelism: 2
  completions: 8
  template:
    ...

Pod Lifecycle

Pod phases progress through Pending → Running → Succeeded/Failed → Unknown . Detailed creation flow: client → API server → controller‑manager → etcd → scheduler → kubelet → pod execution. Deletion triggers graceful termination (default 30 s), removal from Service endpoints, execution of pre‑stop hooks, and finally SIGKILL if needed.

Data Persistence

Three primary mechanisms:

emptyDir – temporary storage tied to the pod’s lifetime.

hostPath – mounts a directory from the host node (tight node‑pod coupling).

PersistentVolume (PV) / PersistentVolumeClaim (PVC) – abstracts storage (NFS, cloud disks, etc.) with access modes ReadWriteOnce , ReadOnlyMany , ReadWriteMany and reclaim policies Recycle , Retain , Delete .

PVCs request storage size and match PVs by access mode and storage class.

For further details, refer to the official Kubernetes documentation.