Kubernetes · Intermediate interview

A Deployment runs interchangeable, stateless replicas. A StatefulSet runs Pods with stable identities and stable per-Pod storage and ordered rollout — for databases and clustered stateful apps that need persistent identity. A DaemonSet runs one Pod per node, for node-level agents like log collectors or monitoring. You pick based on whether Pods are fungible, identity-bearing, or per-node.

Labels are key/value tags on objects; selectors query them. This loose coupling is how a Service finds its Pods (its selector matches Pod labels), how a Deployment manages its ReplicaSet's Pods, and how you group resources for operations. Instead of hard references, Kubernetes matches by labels, so adding a Pod with the right labels makes it part of the set automatically.

A Job runs Pods until a task completes successfully (with retries and parallelism), for batch work like migrations or processing. A CronJob schedules Jobs on a cron schedule, for recurring tasks like backups or reports. Unlike Deployments, they're meant to finish rather than run forever.

A request is what a container is guaranteed and what the scheduler uses to place the Pod on a node with enough capacity. A limit is the hard ceiling — exceeding the memory limit gets the container OOM-killed, and CPU is throttled at its limit. Requests affect scheduling and QoS class; limits cap consumption. Setting them well prevents both resource starvation and noisy-neighbor problems.

nodeSelector and node affinity attract Pods to nodes with certain labels (e.g. GPU nodes); pod affinity/anti-affinity co-locate or spread Pods relative to each other (e.g. spread replicas across zones). Taints repel Pods from nodes unless the Pod has a matching toleration, reserving nodes for specific workloads. Together they give you control over where Pods land for performance, isolation, and availability.

The HPA watches a metric — typically CPU/memory utilization or custom/external metrics — and adjusts a Deployment's replica count to keep the metric near a target. It scales out under load and back in when idle, within min/max bounds. It relies on the metrics server and on Pods having resource requests set, and complements (not replaces) cluster autoscaling that adds nodes.

A PersistentVolume (PV) is a piece of cluster storage; a PersistentVolumeClaim (PVC) is a Pod's request for storage of a certain size and access mode. Kubernetes binds a PVC to a suitable PV, decoupling Pods from the underlying storage details. The Pod mounts the PVC, so its data survives Pod restarts and rescheduling.

A StorageClass defines a 'type' of storage (e.g. fast SSD) and a provisioner. With dynamic provisioning, creating a PVC that references a StorageClass automatically creates the backing PV on demand (a cloud disk, for instance), instead of an admin pre-creating PVs. It makes storage self-service and is how stateful workloads get volumes in cloud clusters.

They use a StatefulSet with volumeClaimTemplates, which gives each Pod its own stable PVC and a stable network identity, so Pod web-0 always reattaches to its own volume even after rescheduling. This stable identity-plus-storage is what databases and clustered systems need, unlike a Deployment where Pods are interchangeable and share nothing persistent by default.

A liveness probe detects a hung container and restarts it. A readiness probe decides whether a Pod should receive traffic — failing it removes the Pod from Service endpoints without killing it, useful during warmup or temporary dependency loss. A startup probe gives slow-starting apps time before liveness kicks in. Using the right combination prevents both routing to unready Pods and killing healthy-but-slow ones.

On a Deployment's RollingUpdate strategy, maxUnavailable caps how many Pods can be down during the rollout and maxSurge how many extra can be created above the desired count. Tuning these trades rollout speed against capacity — for example maxUnavailable 0 with maxSurge 1 keeps full capacity but rolls slower. Readiness probes gate the rollout so new Pods must be ready before old ones are removed.

Namespaces partition a cluster into virtual sub-clusters for isolation, organization, and applying resource quotas and policies per team or environment. RBAC (Role-Based Access Control) grants permissions via Roles/ClusterRoles bound to users or service accounts, so principals get least-privilege access to specific resources and verbs. Together they let many teams and workloads share a cluster safely.