Core Concepts
1. What is the difference between a Pod and a Deployment?
A Pod is the smallest deployable unit in Kubernetes: one or more containers sharing network and storage. A Deployment manages a ReplicaSet which maintains a desired number of Pod replicas. Use Deployments for stateless workloads; they handle rolling updates and rollbacks automatically. You rarely create bare Pods in production because they are not rescheduled if the node fails.
2. What happens when a node runs out of memory?
The kubelet uses the oom_score_adj Linux kernel value to prioritize which processes to kill. Pods that exceed their requests are killed first by the OOM killer. This is why setting accurate resource requests is critical for cluster stability. The kubelet also evicts Pods proactively when node memory crosses the soft eviction threshold, starting with the lowest QoS class.
3. What are the three Quality of Service classes and how are they assigned?
Kubernetes assigns each Pod a QoS class based on its resource specification. Guaranteed requires every container to set equal requests and limits for both CPU and memory. Burstable applies when at least one container has a request but the limits do not match. BestEffort is for Pods with no requests or limits set. During node pressure, BestEffort Pods are evicted first and Guaranteed last.
4. What is the role of etcd in a cluster?
etcd is the distributed key-value store that holds the entire cluster state: every object, its spec, and its status. The API server is the only component that talks to etcd directly. Losing etcd without a backup means losing the cluster's desired state, so regular snapshots with etcdctl snapshot save are essential for disaster recovery.
5. What is the difference between a ReplicaSet and a StatefulSet?
A ReplicaSet keeps a set of identical, interchangeable Pods running, with random names and no stable identity. A StatefulSet gives each Pod a stable, ordered name (such as web-0, web-1), a stable network identity, and its own persistent volume. Use StatefulSets for databases and clustered systems where ordinal identity and storage matter.
Networking
6. How does a Service route traffic to Pods?
A Service uses label selectors to find matching Pods and maintains an Endpoints object (or EndpointSlices in modern clusters). kube-proxy on each node programs iptables or IPVS rules to forward traffic to any healthy Pod endpoint, load-balancing across replicas. The Service gets a stable ClusterIP so clients never need to track changing Pod IPs.
7. What are the differences between ClusterIP, NodePort, and LoadBalancer Service types?
ClusterIP exposes the Service only inside the cluster on a virtual IP. NodePort opens a static port on every node so external traffic can reach the Service through any node IP. LoadBalancer provisions an external load balancer through the cloud provider and routes to the NodePort underneath. Each type builds on the previous one.
8. How does DNS resolution work inside a cluster?
CoreDNS runs as a Deployment and serves cluster DNS. A Service named api in namespace prod resolves to api.prod.svc.cluster.local. Pods get this search domain injected into /etc/resolv.conf, so in-namespace lookups can use the short name. Headless Services (with clusterIP: None) return the individual Pod A records instead of a single virtual IP.
9. What does a NetworkPolicy do and what happens without one?
A NetworkPolicy controls which Pods can talk to each other based on labels, namespaces, and ports. Without any policy, all Pods can reach all other Pods, which is fully open by default. The moment a Pod is selected by at least one policy, traffic not explicitly allowed is denied. NetworkPolicies only take effect if the CNI plugin (Calico, Cilium) supports them.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-from-other-ns
spec:
podSelector: {}
policyTypes: [Ingress]
ingress:
- from:
- podSelector: {}
10. What is an Ingress and how does it differ from a Service?
An Ingress is an HTTP and HTTPS routing layer that maps hostnames and paths to backend Services. A Service operates at L4 (TCP/UDP), while an Ingress operates at L7 and can do host-based routing, path rewriting, and TLS termination. An Ingress does nothing without an Ingress controller (NGINX, Traefik) running to implement the rules.
Storage
11. What is the difference between a PersistentVolume and a PersistentVolumeClaim?
A PersistentVolume (PV) is a piece of storage in the cluster, provisioned by an admin or dynamically by a StorageClass. A PersistentVolumeClaim (PVC) is a user's request for storage with a size and access mode. The claim binds to a matching volume, decoupling the Pod from the underlying storage details so workloads stay portable.
12. What does a StorageClass enable?
A StorageClass defines a provisioner and parameters for dynamic volume creation. When a PVC references a StorageClass, the cluster creates a matching PV automatically instead of requiring a pre-provisioned one. This is how cloud disks, like EBS or Persistent Disk, are created on demand. A default StorageClass is used when a PVC omits the field.
13. What are the common access modes for volumes?
ReadWriteOnce (RWO) allows the volume to be mounted read-write by a single node. ReadOnlyMany (ROX) allows many nodes to mount it read-only. ReadWriteMany (RWX) allows many nodes to mount it read-write, which most block storage does not support and typically requires a network file system. ReadWriteOncePod restricts the mount to a single Pod.
14. How do you retain data when a PVC is deleted?
The PV's persistentVolumeReclaimPolicy controls this. With Retain, the underlying volume and its data survive PVC deletion and must be cleaned up manually. With Delete, the volume is removed along with the claim. Production databases usually set Retain to guard against accidental data loss.
Scheduling & Resources
15. How does the scheduler decide where to place a Pod?
The scheduler runs two phases: filtering and scoring. Filtering eliminates nodes that cannot run the Pod (insufficient resources, unmatched node selectors, untolerated taints). Scoring ranks the remaining nodes by spread, affinity, and resource balance, then the highest-scoring node wins. The Pod is then bound to that node.
16. What is the difference between a node taint and a Pod toleration?
A taint is applied to a node to repel Pods that do not tolerate it, for example node-role.kubernetes.io/control-plane:NoSchedule. A toleration is set on a Pod to allow (but not require) scheduling onto a tainted node. Taints and tolerations work together to dedicate nodes to specific workloads.
kubectl taint nodes node1 dedicated=gpu:NoSchedule
17. What is the difference between nodeSelector, node affinity, and pod affinity?
nodeSelector is a simple hard match on node labels. Node affinity is a richer version supporting required and preferred rules with operators like In and NotIn. Pod affinity and anti-affinity schedule Pods relative to other Pods, useful for co-locating a cache with its app or spreading replicas across zones.
18. What is the difference between resource requests and limits?
A request is the amount of CPU or memory the scheduler reserves for a container; it guarantees that capacity. A limit is the hard ceiling the container cannot exceed. Exceeding a memory limit triggers an OOM kill, while exceeding a CPU limit causes throttling rather than termination. Requests drive scheduling, limits enforce isolation at runtime.
19. How does the Horizontal Pod Autoscaler work?
The HPA queries metrics (CPU, memory, or custom metrics through the metrics API) and adjusts the replica count of a Deployment or StatefulSet to hit a target utilization. It reads observed usage on a control loop, computes the desired replicas, and scales within configured min and max bounds. It needs the metrics-server installed to read resource metrics.
Security & RBAC
20. How does RBAC authorization work?
RBAC grants permissions through Roles and ClusterRoles, which list allowed verbs on resources. A RoleBinding or ClusterRoleBinding ties that Role to a subject: a user, group, or ServiceAccount. Roles are namespace-scoped while ClusterRoles are cluster-wide. Permissions are purely additive, with no deny rules, so a subject can do anything its bindings allow.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
21. What is a ServiceAccount and how do Pods use it?
A ServiceAccount provides an identity for processes running in a Pod. Each Pod gets a default ServiceAccount unless one is specified. Since Kubernetes 1.24, tokens are short-lived projected volumes rather than long-lived secrets, and the API server validates them through the TokenRequest API. Bind a ServiceAccount to a Role to grant the Pod API access.
22. What is the difference between authentication and authorization in the API server?
Authentication answers who you are, using client certificates, bearer tokens, or OIDC. Authorization answers what you can do, typically through RBAC. A request also passes through admission controllers, which can mutate or validate it before persistence. All three stages must pass for a request to reach etcd.
23. What does a Pod Security Standard enforce?
Pod Security Standards define three profiles: privileged, baseline, and restricted. The built-in Pod Security Admission controller enforces them per namespace through labels, replacing the deprecated PodSecurityPolicy. The restricted profile blocks privilege escalation, requires non-root users, and drops Linux capabilities. You can run it in enforce, audit, or warn mode.
24. How do you store sensitive data in Kubernetes?
Secrets hold sensitive values, base64-encoded and mounted as files or environment variables. By default they are only base64-encoded in etcd, not encrypted, so enable encryption at rest with an EncryptionConfiguration and restrict RBAC access. For stronger security, integrate an external secrets manager through the Secrets Store CSI driver.
Observability & Troubleshooting
25. A Pod is stuck in Pending. How do you diagnose it?
Run kubectl describe pod and read the Events section. Pending usually means the scheduler cannot place the Pod: insufficient CPU or memory on any node, an unbound PVC, or a nodeSelector and taint mismatch. Check node capacity with kubectl describe nodes and confirm a matching node exists.
kubectl describe pod my-pod -n default
kubectl get events --sort-by=.lastTimestamp
26. What does CrashLoopBackOff mean and how do you fix it?
CrashLoopBackOff means a container keeps starting and exiting, so the kubelet backs off restarting it with growing delays. Inspect logs from the previous run with kubectl logs --previous to see why it died. Common causes are a failing command, a missing config or secret, or a failing liveness probe killing a slow-starting app.
kubectl logs my-pod --previous
27. What is the difference between liveness, readiness, and startup probes?
A liveness probe restarts a container that is alive but stuck. A readiness probe removes a Pod from Service endpoints when it cannot serve traffic, without restarting it. A startup probe protects slow-starting apps by disabling the other probes until the app is up. Misconfigured liveness probes are a frequent cause of restart loops.
28. How do you debug a Pod that has no shell or debugging tools?
Use ephemeral debug containers, which attach a temporary container into a running Pod's namespaces without restarting it. This is the supported way to troubleshoot distroless or minimal images that ship no shell. The debug container shares the process and network namespace of the target.
kubectl debug -it my-pod --image=busybox --target=app
29. How do you check why a node is NotReady?
Run kubectl describe node and review the Conditions and Events. A NotReady status often comes from a stopped kubelet, a broken CNI plugin, disk or memory pressure, or loss of API server connectivity. Check the kubelet logs on the node itself with journalctl -u kubelet to confirm the root cause.
Workloads & Controllers
30. What is the difference between a Job, a CronJob, and a DaemonSet?
A Job runs a Pod to completion and retries on failure, ideal for batch tasks. A CronJob creates Jobs on a schedule using cron syntax, for recurring work like backups. A DaemonSet ensures a copy of a Pod runs on every node (or a labeled subset), which suits log collectors and node agents. Each controller targets a distinct workload pattern.
Top comments (0)