Kubernetes Interview Questions

A container shares the host machine's operating system kernel and only packages an application and its dependencies, making it lightweight and fast to start. A VM virtualizes an entire computer, including its own OS, making it heavier and slower. Kubernetes manages containers because their lightweight, fast-starting nature fits the frequent scaling and rescheduling Kubernetes needs to do.

The control plane manages the cluster's overall state, including the API server, the scheduler, and the controller manager. Worker nodes actually run the containerized workloads themselves, each running a kubelet agent that communicates with the control plane and manages containers on that specific node.

A node is a single machine, physical or virtual, that's part of a Kubernetes cluster and actually runs workloads. A cluster typically includes several worker nodes, giving Kubernetes room to actually distribute and reschedule workloads across them as needed.

The API server is the central entry point for every interaction with the cluster, whether from kubectl, another internal component, or an external tool. Every single change to the cluster's actual state goes through the API server first, which is exactly why it's often described as the cluster's own front door.

An imperative approach directly issues a command describing an action, like kubectl create, telling Kubernetes exactly what to do right now. A declarative approach instead describes the desired end state in a file and lets Kubernetes figure out how to actually reach it, which is why kubectl apply, the more commonly recommended approach, works declaratively rather than imperatively.

kubectl is the command-line tool used to actually interact with a Kubernetes cluster, creating, inspecting, updating, and deleting resources by communicating directly with the cluster's own API server. It's the primary way most people actually work with Kubernetes day to day.

A Pod is the smallest deployable unit in Kubernetes, typically wrapping one container, though it can technically hold more than one closely related container that genuinely need to share resources like network and storage. Kubernetes schedules and manages Pods directly, rather than managing individual containers on their own.

A Pod groups containers that genuinely need to share the same network namespace and storage volumes, letting them communicate over localhost and share files easily, which wouldn't be possible if they were scheduled as genuinely separate, unrelated units. Most Pods do just wrap a single container, but the Pod abstraction supports that multi-container case when it's genuinely needed.

A multi-container Pod runs more than one container together, sharing the same network and storage. A sidecar container, like a logging agent that reads and forwards logs from the main application container, is a genuinely common use case, since it needs direct access to the main container's own log files.

The Pod itself is genuinely lost, since it was tied to that specific node. If the Pod was managed by a higher-level controller, like a Deployment, Kubernetes automatically schedules a genuinely new replacement Pod on a different, healthy node instead. A Pod created directly with no controller managing it simply stays gone.

Pending (the Pod has been accepted but isn't running yet), Running (at least one container is actually running), Succeeded (every container completed successfully and won't restart), and Failed (at least one container terminated with an actual failure). These phases give a quick, high-level view of a Pod's genuine current state.

A container restart happens within the exact same Pod, on the exact same node, typically because the container itself crashed. Rescheduling creates a genuinely new Pod, possibly on a completely different node, typically because the original Pod (or its entire node) is genuinely gone and needs to be replaced entirely.

An init container runs to completion before any of a Pod's regular containers actually start, commonly used to perform a setup task, like waiting for a dependency to become available, or downloading a configuration file the main container genuinely needs. Unlike regular containers, which run concurrently, init containers run one at a time, in the order they're actually defined, and the Pod's main containers won't start until every init container has genuinely finished successfully.

A Deployment manages a set of identical Pods, ensuring a genuinely specified number of replicas are actually running at all times, and it handles rolling out an update to a genuinely new version smoothly. It solves the problem of manually creating, monitoring, and replacing individual Pods by hand, which doesn't genuinely scale for real applications.

A ReplicaSet ensures a genuinely specified number of identical Pod replicas are actually running at any given time. A Deployment manages ReplicaSets on your behalf, creating a genuinely new ReplicaSet whenever you actually update the Pod template, which is what enables Deployment's own rolling update capability.

kubectl scale deployment my-app --replicas=5 tells Kubernetes to actually ensure five Pod replicas are running for that Deployment, and Kubernetes automatically creates or removes Pods as needed to genuinely reach that specified target.

A rolling update gradually replaces old Pods with genuinely new ones, a few at a time, rather than replacing every Pod all at once, which would genuinely cause a full outage during the actual update. A Deployment handles this automatically when its Pod template is updated, controlled by settings like maxUnavailable and maxSurge.

kubectl rollout undo deployment my-app reverts the Deployment back to its previous, genuinely known-good revision, using the actual rollout history Kubernetes automatically keeps for every Deployment by default.

A bare Pod has genuinely no automatic recovery at all. If it crashes or its node fails, it's simply gone. A Deployment continuously monitors its managed Pods and automatically creates a genuinely new replacement if one goes missing or fails, which is exactly why almost no real production workload runs as a bare Pod.

A Service provides a genuinely stable network endpoint for accessing a set of Pods, even as those specific Pods are created, destroyed, and rescheduled with genuinely changing IP addresses over time. It solves the problem of other applications needing a reliable, genuinely consistent way to actually reach a group of Pods, without needing to track each individual Pod's own, genuinely constantly-changing IP address.

ClusterIP, the default, exposes a Service only within the cluster itself. NodePort exposes it on a genuinely static port on every node, reachable from outside the cluster. LoadBalancer provisions an actual external load balancer, typically through a cloud provider, to genuinely expose the Service publicly.

A Service uses a label selector, matching Pods whose labels genuinely match the selector's own defined criteria. Any Pod with a matching label automatically becomes part of that Service's genuine set of backend targets, regardless of which specific Deployment or ReplicaSet actually created it.

A label is a genuinely arbitrary key-value pair attached to a Kubernetes object, like a Pod, used to organize and select resources. A Service's own label selector, for instance, uses labels to figure out which specific Pods it should actually route traffic to.

Kubernetes automatically creates a genuine DNS entry for every Service, letting other Pods reach it simply by its own name, like my-service, rather than needing to know its actual, genuinely dynamic IP address at all. This is handled by an internal DNS service, typically CoreDNS, running genuinely inside the cluster itself.

A Pod's IP address genuinely changes every single time that Pod is recreated or rescheduled. A Service's IP address (or its DNS name) stays genuinely stable for the entire life of the Service itself, regardless of how many times the actual underlying Pods behind it come and go.

A ConfigMap stores non-sensitive configuration data, like a feature flag or an application setting, genuinely separate from the actual container image itself. This lets you change configuration without needing to rebuild and redeploy an entirely new container image just for a genuinely small configuration change.

A Secret stores genuinely sensitive data, like a password or an API key, similarly to a ConfigMap but with additional handling intended specifically for sensitive values, like being base64-encoded and, in most setups, encrypted at genuine rest. A ConfigMap is meant for non-sensitive configuration data that doesn't genuinely need that same extra level of protection.

A ConfigMap's values can be mounted as genuinely individual files inside a container's filesystem, or exposed as environment variables directly within the container, both configured in the Pod's own specification referencing that specific ConfigMap by name.

Base64 encoding is genuinely just a reversible encoding format, not actual encryption, so anyone with access to a Secret object can trivially decode it back to its original, genuinely plain-text value. Real protection genuinely comes from encrypting Secrets at rest in etcd and tightly controlling exactly who has actual access to read them at all.

If the ConfigMap is genuinely mounted as a file (rather than as an environment variable), an update to that ConfigMap eventually propagates to the mounted file inside the running Pod automatically, though the application itself typically genuinely needs to be written to actually detect and reload that changed file, since Kubernetes doesn't genuinely restart the Pod on its own just because the ConfigMap changed.

kubectl get pods lists every Pod in the genuinely current namespace. Adding -o wide shows additional detail, like each Pod's own node and IP address, and -n namespace-name targets a genuinely specific namespace other than the default one.

kubectl logs pod-name prints that Pod's actual container logs. Adding -f follows the logs genuinely live, similar to tail -f, and --previous shows the logs from a genuinely previous instance of the container if it has already actually restarted.

kubectl describe pod pod-name shows genuinely detailed information, including recent events, which very often directly reveals exactly why a Pod is stuck, like insufficient genuine resources on any available node, or a container image that genuinely couldn't actually be pulled.

kubectl delete pod pod-name removes that specific Pod. If it's genuinely managed by a Deployment (through a ReplicaSet), the Deployment's controller notices the actual replica count has dropped below what's genuinely expected and automatically creates a genuinely new replacement Pod right away.

kubectl apply -f my-config.yaml creates the resource described in that file if it genuinely doesn't already exist, or updates it to genuinely match the file's contents if it already does, making apply the standard, genuinely preferred way to manage Kubernetes resources declaratively.

kubectl create creates a genuinely new resource and fails with an error if that resource already exists. kubectl apply is genuinely declarative, creating the resource if it doesn't exist, or updating it to actually match the given file if it already does, which is why apply is generally preferred for ongoing, repeatable management.

StatefulSet Pods get a genuinely stable, predictable network identity (a consistent hostname) and, if configured, their own dedicated persistent storage that follows that specific Pod across a rescheduling event. StatefulSet Pods are also genuinely created and terminated in a defined, sequential order, rather than all at once in genuinely no particular order.

A DaemonSet ensures exactly one copy of a specific Pod runs on every single node (or a genuinely selected subset of nodes) in the cluster. A genuinely common use case is a logging agent or a monitoring agent that needs to actually run on every single node to collect data from it directly.

A Job runs a Pod (or several Pods) to genuine completion for a one-off task, like a batch data-processing script, and considers itself done once that task genuinely finishes successfully. A Deployment instead keeps its Pods genuinely running continuously and indefinitely, restarting them if they ever stop, since it's meant for a long-running service, not a one-off task.

A CronJob creates a genuinely new Job on a defined, recurring schedule, using standard cron syntax. It solves the genuine problem of needing a task to run periodically, like a nightly backup or a report generation script, without needing an external, genuinely separate scheduling system running entirely outside the cluster.

An Ingress manages external HTTP and HTTPS access to Services within the cluster, letting you define genuinely more sophisticated routing rules, like routing based on a specific hostname or URL path, all through a single, genuinely shared entry point. A plain Service alone, especially a LoadBalancer, typically provisions a genuinely separate external load balancer for each individual Service, which gets expensive and unwieldy at any real scale.

An Ingress resource on its own is genuinely just a set of routing rules. An Ingress Controller, like NGINX Ingress or Traefik, is the genuinely actual component that reads those rules and implements the real routing behavior. Without an Ingress Controller genuinely running in the cluster, an Ingress resource has genuinely no real effect at all.

A NetworkPolicy controls which Pods are genuinely allowed to communicate with which other Pods, effectively acting as a firewall genuinely operating at the Pod level. By default, Kubernetes allows genuinely all Pods to communicate with all other Pods, and a NetworkPolicy is used to explicitly restrict that when genuinely needed, like isolating a genuinely sensitive database Pod so only specific, approved application Pods can actually reach it.

CoreDNS, running genuinely inside the cluster, automatically creates a DNS record for every Service, letting a Pod reach it using a predictable name like my-service.my-namespace.svc.cluster.local, or genuinely just my-service if it's actually within the exact same namespace.

A regular ClusterIP Service load-balances traffic across its backing Pods through one genuinely single, stable virtual IP. A headless Service genuinely returns the individual IP addresses of every single backing Pod directly through DNS instead, which is commonly used with a StatefulSet where a client genuinely needs to actually address a specific individual Pod directly, rather than any interchangeable one.

A Persistent Volume represents an actual piece of storage in the cluster, provisioned either manually by an administrator or genuinely dynamically on demand. It solves the problem of a container's own local filesystem being genuinely temporary, since anything written there is genuinely lost the moment the container is restarted or rescheduled.

A PVC is a genuine request for storage made by a user or an application, specifying how much storage is genuinely needed and what access mode it requires. Kubernetes then binds that PVC to a matching, genuinely available Persistent Volume, either an existing one or one dynamically provisioned specifically to actually satisfy that particular claim.

A StorageClass defines a genuine type of storage available in the cluster, like a specific cloud provider's SSD-backed storage, and enables dynamic provisioning, automatically creating a genuinely new Persistent Volume on demand whenever a PVC requests that specific storage class, rather than requiring an administrator to manually pre-provision every single volume ahead of time.

ReadWriteOnce allows genuinely read-write access from a single node at a time. ReadOnlyMany allows genuinely read-only access from multiple nodes simultaneously. ReadWriteMany allows genuinely read-write access from multiple nodes at the exact same time, though not every genuine storage backend actually supports that particular mode.

The actual data genuinely persists, independent of the Pod's own lifecycle, which is the entire genuine point of using persistent storage in the first place. Whether the underlying Persistent Volume itself is also genuinely deleted when the PVC is removed depends on that specific PV's own reclaim policy, either Retain (keep the data) or Delete (also genuinely delete the actual underlying storage).

A liveness probe periodically checks whether a container is genuinely still functioning correctly. If it genuinely fails repeatedly, Kubernetes restarts that specific container, on the genuine assumption that it's stuck in some kind of broken, unrecoverable state that a genuine restart would actually fix.

A readiness probe checks whether a container is genuinely ready to actually accept traffic. If it fails, Kubernetes removes that specific Pod from a Service's genuine backend pool without actually restarting the container itself, unlike a failed liveness probe, which genuinely does trigger a restart.

A container can genuinely be alive and running, satisfying its liveness probe, while still not actually being ready to serve real traffic yet, like during a slow startup process still loading a large in-memory cache. A readiness probe specifically prevents traffic from being sent to it too early, before it's genuinely actually ready.

A resource request specifies the genuine minimum amount of CPU or memory a container needs, used by the scheduler to actually decide which node has enough genuinely available capacity to run it. A resource limit specifies the genuine maximum a container is allowed to actually use, and exceeding a memory limit typically gets that container genuinely killed and restarted.

Helm is a package manager for Kubernetes, letting you define, install, and upgrade a genuinely complex application, made up of many individual Kubernetes resources, as one genuinely single, cohesive unit called a chart. It solves the genuine problem of manually managing a large, growing collection of genuinely separate YAML files by hand for every single deployment.

A chart is a genuinely packaged collection of Kubernetes resource templates, along with a values file specifying genuinely configurable defaults. It typically contains templates for Deployments, Services, ConfigMaps, and any other resources the actual application genuinely needs, parameterized so the exact same chart can be genuinely reused across multiple different environments.

helm install my-release my-chart installs the specified chart, creating every Kubernetes resource it genuinely defines, using the chart's own default configuration values unless you actually override them with a genuinely separate values file or a command-line flag.

helm upgrade my-release my-chart applies any actual changes in the chart (or its provided values) to the genuinely already-running release, and Helm keeps a real revision history, letting you roll back with helm rollback if that genuine upgrade actually causes a problem.

Required node affinity (requiredDuringSchedulingIgnoredDuringExecution) is a genuinely hard constraint, the Pod simply won't be scheduled at all if no matching node is genuinely available. Preferred node affinity is a genuinely soft preference, the scheduler will genuinely try to honor it but will still schedule the Pod elsewhere if it genuinely has to.

A taint is applied to a node, marking it as generally unsuitable for Pods unless they genuinely, specifically tolerate that particular taint. A toleration is applied to a Pod, explicitly stating it can genuinely be scheduled onto a node with a genuinely matching taint. Together they let you genuinely reserve specific nodes for specific, particular workloads.

A PDB specifies the genuine minimum number (or percentage) of Pods from a given application that must actually remain available during a genuinely voluntary disruption, like a node being deliberately drained for maintenance. It solves the genuine problem of a maintenance operation accidentally taking down too many replicas of a genuinely critical application all at once.

Pod anti-affinity prevents Pods matching a specific label from being genuinely scheduled together on the exact same node (or in the same genuine failure zone). A genuinely common use case is spreading a Deployment's own replicas across genuinely different nodes, so a single node failure doesn't genuinely take down every single replica of that application at once.

It first filters out nodes that genuinely can't satisfy the Pod's own requirements, insufficient resources, a genuinely unmatched node affinity rule, an untolerated taint, then scores the genuinely remaining eligible nodes based on a set of priority functions, actually selecting the node with the genuinely highest overall score.

RBAC controls exactly what genuine actions a specific user or service account is allowed to actually perform on which specific Kubernetes resources. It solves the genuine problem of needing fine-grained, genuinely least-privilege access control across a cluster, rather than every single user or service genuinely having full, unrestricted admin access to everything.

A Role grants genuinely specific permissions scoped to just one particular namespace. A ClusterRole grants permissions that can genuinely apply cluster-wide, across every namespace, or can genuinely be used for cluster-scoped resources that don't actually belong to any single namespace at all.

A Service Account provides an identity specifically for a process genuinely running inside a Pod to actually authenticate against the Kubernetes API, like a controller or an application that genuinely needs to actually call the API itself. A regular user account instead represents an actual, genuine human interacting with the cluster, typically through kubectl.

A namespace divides a single cluster into genuinely separate virtual sub-clusters, letting different teams or environments share the same physical cluster while keeping their own resources genuinely organized and isolated from each other by name. Resource quotas, RBAC rules, and network policies are all commonly scoped to a specific namespace.

It enforces genuine security standards on Pods at the moment they're actually created, like preventing a container from genuinely running as the root user, or blocking a container from mounting a genuinely sensitive host path. It addresses the genuine problem of a Pod's own configuration accidentally, or intentionally, weakening the cluster's overall real security posture.

Enable encryption at rest for Secrets stored in etcd, ensure genuinely all API traffic uses TLS (which is Kubernetes's own default), and tightly restrict RBAC permissions so only genuinely specific service accounts and users that actually need a given Secret can actually read it at all.

etcd is a distributed, genuinely consistent key-value store holding the entire cluster's actual state, every Pod, Service, ConfigMap, and more. It's genuinely critical because if etcd genuinely becomes unavailable or loses data, the cluster genuinely loses its own memory of what it's actually supposed to be running, which is exactly why etcd is typically run as a genuinely resilient, replicated cluster of its own, with regular backups.

Upgrade the control plane components first, then upgrade worker nodes one at a time (or in genuinely small batches), draining each node of its Pods before actually upgrading it, letting Kubernetes reschedule those Pods onto genuinely still-available nodes in the meantime, rather than upgrading every single node all at once simultaneously.

An HA control plane runs multiple genuinely replicated instances of the API server, scheduler, and controller manager, along with a genuinely multi-node etcd cluster, so the control plane keeps functioning correctly even if one specific control plane node genuinely fails. A genuinely production cluster needs this since a single control plane failure would otherwise genuinely take down the cluster's own ability to actually schedule or manage anything at all.

Check kubectl describe on a genuinely affected Pod first, since it usually directly reveals the actual reason, insufficient resources across every available node, an unmatched affinity rule, or an actual issue with the scheduler or the control plane itself. I'd also check overall genuine cluster resource utilization and the health of the control plane components themselves.

Cluster autoscaling adds or removes genuinely entire nodes from the cluster based on whether currently-pending Pods genuinely can't be scheduled due to insufficient overall resources. Horizontal Pod Autoscaling instead adjusts the genuine number of Pod replicas for a specific workload based on observed metrics like CPU usage, operating at a genuinely different, more granular level than cluster-wide node scaling.

Analyze actual current resource utilization trends and genuinely project forward based on expected growth, rather than a purely arbitrary, rough estimate. Cluster autoscaling can genuinely help absorb unexpected demand automatically, but it still needs sufficient genuinely available cloud provider quota and capacity actually configured ahead of time to actually work correctly when it's genuinely needed.

An Operator encodes genuinely specific operational knowledge for managing a complex, stateful application, like a database, including tasks like backup, recovery, and safe version upgrades, that go genuinely well beyond a simple Deployment or StatefulSet's own basic capabilities. It solves the problem of genuinely encoding a human operator's own accumulated expertise directly into automated, repeatable code.

A CRD extends the Kubernetes API itself with a genuinely new, custom resource type specific to a particular application, like a Database resource representing an actual database instance. An Operator typically watches for changes to its own genuinely corresponding CRD instances and takes the actual real actions needed to genuinely reconcile the cluster's real state to match what that custom resource actually specifies.

A service mesh, like Istio or Linkerd, handles service-to-service communication concerns, load balancing, retries, encryption, observability, at the infrastructure layer, typically through a lightweight proxy sidecar container automatically injected into every Pod. It integrates with Kubernetes by genuinely operating alongside the Pods and Services already actually running in the cluster.

GitOps treats a Git repository as the genuine single source of truth for a cluster's desired state, with a tool like Argo CD or Flux continuously watching that repository and automatically applying any change to actually match the live cluster's own real state to it. It solves the genuine problem of configuration drift, where a cluster's genuinely actual state slowly diverges from what's genuinely documented anywhere.

I'd weigh the genuine operational complexity of running that specific stateful application well inside Kubernetes, backup, failover, version upgrades, against the real cost and any genuine flexibility trade-offs of a managed service instead. For a genuinely widely-used stateful system, like a relational database, a managed service often genuinely wins unless there's a genuinely specific, compelling reason to run it inside the cluster instead.

Use namespaces to genuinely isolate each team's own resources, ResourceQuotas to prevent any single team from genuinely consuming more than their genuinely fair share of overall cluster resources, and NetworkPolicies to actually restrict cross-namespace network traffic where it genuinely isn't needed at all.

Migrate incrementally, starting with the applications that would genuinely benefit most, or that are genuinely easiest to migrate first, rather than attempting to move everything all at once in one single, large, disruptive effort. I'd also invest early in genuinely shared tooling and documented patterns so each subsequent team's own migration goes noticeably faster than the very first one did.

I check whether resource requests and limits are genuinely set sensibly, whether the actual health checks (liveness and readiness probes) are genuinely meaningful rather than just superficially present, and whether the design accounts for genuine node or zone failure, beyond just the genuinely happy path where everything simply works correctly.

Automate what can genuinely be automated, required resource limits and health checks enforced through Pod Security Admission or an admission webhook, so standards aren't purely a matter of individual opinion during manual review. For conventions that genuinely resist full automation, I'd document the handful of decisions that actually matter most, along with the real reasoning behind each one.

I'd weigh the genuine operational burden of managing the control plane and etcd yourself against the real cost and any genuine flexibility trade-offs a managed offering introduces. For genuinely most organizations, a managed offering is the right call, since self-managing a control plane rarely provides genuine, differentiated value worth the real, ongoing operational cost.

I'd check overall node resource pressure first, since widespread restarts across genuinely unrelated applications often point to a genuinely shared underlying cause, like memory pressure on specific nodes triggering the kernel's own out-of-memory killer, rather than each individual application genuinely, independently having its own separate bug.

Track node and Pod resource utilization, Pod restart counts, and control plane component health, alerting on meaningful deviation from an established, genuine baseline rather than only on an outright, hard failure. I'd also specifically monitor etcd's own health closely, since etcd issues can genuinely cascade into much broader, cluster-wide problems if left unaddressed.

Treat the chart's actual configurable values as a genuine contract with every consuming team. Adding a genuinely new optional value is generally safe. Changing or removing an existing one needs a documented deprecation period and direct, proactive communication before actual removal, rather than a silent breaking change that quietly breaks another team's deployment with no warning at all.

I'd raise the memory limit as an immediate, short-term mitigation if that's genuinely safe to do, to actually stop the immediate, real user impact, before digging into root cause. Then I'd investigate whether it's a genuine memory leak in the application itself, or simply an actual limit that was set too conservatively low relative to the application's own genuinely real, normal memory usage pattern.

Start from actual current resource utilization trends and load-test genuinely representative workloads at a realistically scaled-up volume, rather than a purely theoretical calculation. I'd also verify the underlying cloud provider has sufficient genuine quota available for the cluster to actually scale to that expected size when it's genuinely needed.

This is a judgment question interviewers use to see how you reason under genuine uncertainty, not to test a specific textbook fact. A strong answer names the actual constraint that forced the decision, the realistic options that were genuinely on the table, why you picked one knowing it wasn't guaranteed to be right, and what you'd do differently with what you know now.

I'd walk through an actual incident, or a near-miss, caused by a missing or genuinely poorly-set resource limit together, showing concretely how it actually affected other workloads sharing the exact same node, rather than simply explaining resource management as an abstract best practice on its own.

I wouldn't lead with GitOps as an abstract best practice. I'd point to a specific, real, already-experienced incident where manual, undocumented cluster changes caused a genuine configuration drift issue, and show concretely how a GitOps workflow would have actually prevented that exact same specific problem from happening in the first place.

I'd bring the actual, concrete resource requirements and genuine isolation needs of that specific application into the discussion, rather than a general, abstract preference for one approach over the other. Most disagreements like this genuinely resolve once both sides are looking at the same concrete constraints together, instead of arguing from differing, unstated assumptions.

I'd translate the investment into terms leadership already tracks: the hours currently spent by each team independently solving the same deployment and configuration problems, and the specific incidents caused by inconsistent, ad hoc deployment practices across teams. Framed as time recovered and risk reduced across the whole organization, it competes far better for prioritization than framed as a general infrastructure improvement.