Kubernetes Interview Questions and Answers: Architecture, Probes, Deployment, and Management

Note: The following Q&A are the author's own summary; corrections welcome.

1. What is Kubernetes? Explain your understanding.

Answer: Kubernetes is an open‑source system for automating deployment, scaling, and management of containerized applications. It provides container orchestration for production environments.

K8s was launched by Google and originates from Borg, an internal system used for 15 years.

2. What are the components of the K8s architecture?

Answer: Like most distributed systems, a K8s cluster requires at least one master node and multiple worker nodes.

Master node: exposes the API, schedules workloads, and manages nodes.

Worker node: runs a container runtime (Docker, rkt, etc.) and the kubelet agent that communicates with the master; also runs auxiliary components such as logging, monitoring, and service discovery.

K8s architecture details

Master components (do not run workloads):

Kubectl – command‑line client.

API Server – the central entry point for all resource operations, handling authentication, authorization, discovery, etc.

Controller‑manager – maintains cluster state (fault detection, autoscaling, rolling updates, …).

Scheduler – assigns Pods to suitable nodes according to scheduling policies.

etcd – distributed key‑value store that holds the entire cluster state.

Node components:

Kubelet – manages the lifecycle of containers on the node, handles volumes and networking, and reports status to the master. It also performs automatic restart of failed containers.

Kube‑proxy – implements Service load‑balancing and internal service discovery.

Container runtime – software that runs containers (e.g., Docker).

Pod – the smallest deployable unit; may contain one or more containers that share network and IPC namespaces while keeping separate UIDs, mounts, and PIDs.

3. Difference between container‑based and host‑based application deployment

Containers start in seconds, are portable (“write once, run anywhere”), but require careful handling of persistent data. They also provide isolation between services.

4. How does Kubernetes monitor Pod health?

K8s provides three probe types for Pod health checks:

livenessProbe – determines if a container is alive; if it fails, kubelet may restart the container.

readinessProbe – indicates whether a Pod is ready to receive traffic; failing probes remove the Pod from Service endpoints.

startupProbe – gives slow‑starting containers extra time before liveness/readiness checks begin.

All probes share common parameters such as initialDelaySeconds , periodSeconds , timeoutSeconds , and successThreshold .

Each probe can be implemented via three methods:

exec – runs a command inside the container (example YAML shown).

httpGet – sends an HTTP request; any 2xx‑3xx response is considered healthy (example YAML shown).

tcpSocket – attempts a TCP connection to the specified port (example YAML shown).

5. How to control a rolling update

Use kubectl explain deploy.spec.strategy.rollingUpdate to view parameters:

maxSurge – maximum number of Pods above the desired replica count during an update (percentage or absolute number, default 1).

maxUnavailable – maximum number of Pods that may be unavailable during the update.

6. Image pull policies

K8s supports three policies, viewable via kubectl explain pod.spec.containers :

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

Never – never pull; only use a locally‑present image.

IfNotPresent – pull only if the image is not already present on the node.

7. Pod status values

Running – containers are created and at least one is executing.

Pending – the Pod has been accepted but is waiting for scheduling or image download.

Unknown – the control plane cannot obtain the Pod’s status.

8. Pod restart policies

Always – default; restart the Pod whenever it terminates.

OnFailure – restart only if the container exits with a non‑zero status.

9. Purpose of a Service

A Service provides a stable network endpoint for a set of Pods, enabling service discovery and load‑balancing.

10. Commands for version rollback

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

11. Labels and label selectors

Labels group resources for easier management. Selectors filter resources based on label equality or set‑based operators (In, NotIn, Exists).

Examples of selector syntax are provided in YAML.

12. Common label categories

Release (stable, canary, beta)

Environment (dev, qa, production, op)

App (ui, as, pc, sc)

Tier (frontend, backend, cache)

Partition (customerA, customerB)

Track (daily, weekly)

13. Ways to view labels

# kubectl get pod --show-labels
# kubectl get pod -L env,tier
# kubectl get pod -l env,tier

14. Adding, modifying, deleting labels

# Add label
kubectl label pod label-pod abc=123
# Modify label
kubectl label pod label-pod abc=456 --overwrite
# Delete label
kubectl label pod label-pod abc-
# Node label examples omitted for brevity

15. DaemonSet characteristics

A DaemonSet runs exactly one Pod on every node; it does not support a replicas field. Typical use cases include log collection and node monitoring.

16. Job resource

A Job runs a finite task to completion; parallelism and completions can be tuned (example YAML shown).

17. Pod lifecycle phases

Pending

Running

Succeeded

Failed

Unknown

18. Pod creation workflow

Client submits a Pod manifest to the API server.

API server notifies the controller‑manager to create the object.

Controller‑manager stores the Pod spec in etcd.

kube‑scheduler selects a suitable node and binds the Pod.

kubelet on the chosen node launches the containers and reports status.

19. What happens when a Pod is deleted?

The API server marks the Pod for termination (default 30 s graceful period). kubelet removes the Pod from Service endpoints, runs any pre‑stop hooks, sends SIGTERM, and after the grace period sends SIGKILL.

20. What is a Service?

Because Pod IPs are mutable, a Service gives a stable virtual IP and DNS name, routing traffic to a set of Pods via load‑balancing.

21. How does service registration work?

When a Pod starts, it learns the cluster’s Service definitions so it can reach other Services by name.

22. Accessing Pods from outside the cluster

Use a Service of type NodePort , which opens the same port on every node (e.g., 30000) and forwards traffic to the backing Pods.

23. Persistent storage options

Three main mechanisms:

emptyDir – temporary directory that lives as long as the Pod runs; useful for scratch space or sharing data between containers.

hostPath – mounts an existing directory from the node into the container; creates tight coupling between Pod and node.

PersistentVolume (PV) – cluster‑wide storage resource with access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) and reclaim policies (Recycle, Retain, Delete). A PersistentVolumeClaim (PVC) requests a PV of a given size and access mode.

For brevity, the original promotional sections and QR‑code images have been omitted.