Top Kubernetes interview questions of 2026: A beginners guide

Having been around for a decade, the world's most popular container orchestrator has set a standard for how we run containers at scale. According to the CNCF, cloud-native adoption has reached 98% across organizations, showing that Kubernetes adoption is not slowing down.

Whether you are looking to land your first kubernetes role or you are experienced and are looking to brush up on your knowledge, we’ve put together the top questions to learn more about Kubernetes.

What is Kubernetes?

Kubernetes is an open-source system for managing containerized applications. It is the most widely used orchestrator for cloud-native, reliable and scalable distributed systems.

Sometimes, you will see 'Kubernetes' refered to as 'k8s'. Simply put, k8s is just an abbreviation of Kubernetes. It represents the 10-letter word 'Kubernetes', which has 8-letters situated between the ‘K’ and ‘S’. To explore more about k8s

What is container orchestration?

This is usually one of the first questions in a Kubernetes interview. The interviewer wants to see that you understand the overall layout, not just a list of component names. Structuring your answer around how the pieces relate to each other shows that you can do more than memorizing documentation.

Kubernetes is primarily split into the control plane and worker nodes.

On the worker nodes, which is where your pods actually end up running, the key components include:

• Kubelet: The agent running on each node that talks to the control plane. It receives instructions from the API server and makes sure the containers in its pods are running as expected.
• Kube-proxy: Handles networking on each node. It maintains network rules that allow pods to communicate with each other and with services outside the cluster.
• Container runtime: The software responsible for actually running containers (such as containerd or CRI-O).

The control plane, which is responsible for making decisions about the cluster and responding to events (like a pod crashing or a new deployment being created), consists of:

• Kube-apiserver: The central point of communication. Every component in the cluster, including kubectl commands, talks to the cluster through this API.
• etcd: A key-value store that holds all cluster state. When you create a deployment or a service, that information lives in etcd.
• Kube-scheduler: Watches for newly created pods that have no node assigned and selects a suitable node for them to run on, based on resource availability and constraints.
• Controller manager: A collection of controllers bundled into a single process. Each controller watches for a specific type of resource and works to move the current state toward the desired state. For example, the ReplicaSet controller ensures the correct number of pod replicas are running.

Answering this way, by grouping components under where they run and what role they serve, tells the interviewer you understand the architecture as a system rather than treating it as a flat list of terms.

What problems does Kubernetes solve, and why not just run containers directly?

This question tests whether you understand the gap between running containers on a single machine and running them reliably in production. Anyone can do docker run. The interviewer wants to know why that stops being enough.

When you run containers at scale, you quickly run into problems that a container runtime alone does not handle. Kubernetes exists to fill that gap. Specifically, it takes care of:

Why do people use Kubernetes?

Kubernetes has become an essential system for containerized applications, allowing a maintained process of running application infrastructures. This has made containers an essential element for packaging your code along with the libraries and dependencies for the smooth running of your application. Containers ensure that there is no application downtime for users. This is possible because of rolling updates, which is the default deployment strategy for Kubernetes.

When you try to update an application, you don’t update all the instances of your application at once. It will result in an application outage where service will not be available during the period when the older version of your instances is down, and newer versions are up. In Kubernetes, you don’t destroy all your instances; rather, you take down one older version of an instance at a time and bring up a newer version. This results in a seamless update of your application as the application never goes down during the process.

Are there other ways to interact with Kubernetes?

kubectl is the primary command-line tool for communicating with a Kubernetes cluster. You use it to create and manage resources, inspect cluster state, view logs, and debug running workloads. Under the hood, every kubectl command translates into an HTTP request to the Kubernetes API server.

And that detail matters, because kubectl is just one client. Other ways to interact with Kubernetes include:

• The Kubernetes API directly: Since the API server exposes a REST API, you can make requests to it using curl or any HTTP client. This is common in automation scripts and CI/CD pipelines where you need programmatic access.
• Client libraries: Kubernetes has official client libraries for languages like Go, Python, Java, and others. These are useful when you are building tooling or controllers that need to interact with the cluster from within your own code.
• The Kubernetes Dashboard: A web-based UI that gives you a visual overview of the cluster. It is helpful for getting a quick picture of what is running, though most day-to-day work tends to happen through kubectl or automation.
• Infrastructure-as-code tools: Tools like Helm, Kustomize, or even Terraform can manage Kubernetes resources declaratively. These sit on top of the API and are useful when you want to version, template, or package your deployments.

What are Persistent Volumes and Persistent Volume Claims?

Storage in Kubernetes trips people up because it introduces a layer of indirection that does not exist when you are working with a single server. The interviewer is checking that you understand how Kubernetes separates the provisioning of storage from the consumption of it.

This separation exists for a good reason. It allows cluster administrators to manage the infrastructure side of storage (what is available, where it lives, how it performs) while developers only need to declare what their application needs. The two sides are decoupled, which makes it easier to move workloads between environments without rewriting storage configuration.

In practice, most teams use StorageClasses to handle this automatically. When a PVC is created, the StorageClass provisions a matching PV on the fly, so no one has to manually create volumes ahead of time.

What are StatefulSets, and when would you use one over a Deployment?

This question checks whether you understand that not all workloads are interchangeable. The interviewer wants to see that you know the difference between applications that can be freely scaled and replaced versus those that need a stable identity and a persistent state.

A StatefulSet is a Kubernetes workload controller designed for applications that need to maintain state across restarts or scaling events. Databases are the classic example. Unlike a Deployment, where pods are treated as identical and disposable, a StatefulSet gives each pod a stable, unique identity. This means:

• Pods are created and deleted in a predictable order, not all at once.
• Each pod gets a persistent hostname that survives rescheduling (for example, mysql-0, mysql-1, mysql-2).
• Each pod can be associated with its own dedicated storage that follows it even if it moves to a different node.

How is Kubernetes related to Docker?

For many years, Docker was the default container runtime in Kubernetes. However, this changed when Kubernetes removed direct Docker support (known as dockershim) in version 1.24. From that point on, Kubernetes moved fully to runtimes that implement the Container Runtime Interface (CRI), such as containerd and CRI-O. This highlights an important point: Kubernetes is not tied to any single container runtime.

Docker still plays an important role in the broader ecosystem. It is widely used to build, package, and distribute applications and their dependencies as container images. Those images follow the OCI (Open Container Initiative) standard, which means they can be run by any compliant runtime — including the CRI-based runtimes used by Kubernetes. So you can continue building images with Docker and run them on Kubernetes without issue.

The key distinction is that Docker focuses on building and running containers, while Kubernetes is designed to orchestrate containers at scale. They address different layers of the container stack and are often used together, but Kubernetes does not depend on Docker itself to operate.

What is the difference between a pod and a container?

A container is a standard software unit that packages the code along with its libraries and dependencies. This helps to ensure that the application can run quickly and efficiently. Besides packaging, containers help build, ship, deploy, and scale your application with ease. On the other hand, a pod is a group of containers with shared storage and network resources. A pod is the smallest deployable unit that can be created and managed within the Kubernetes ecosystem. In other words, on Kubernetes, containers run in pods.

How do containers within a pod communicate with each other?

Communication between pods is different. Each pod gets its own unique IP address, and pods can reach each other directly using those IPs without NAT (Network Address Translation). This is a core requirement of the Kubernetes networking model: every pod must be able to communicate with every other pod across the cluster using its real IP address.

However, Kubernetes itself does not implement this networking. Instead, it delegates that responsibility to a CNI (Container Network Interface) plugin. The CNI is a standard that defines how networking should be configured for containers, and the actual implementation is handled by a plugin you install on the cluster. Common examples include:

• Calico: Widely used, supports network policies for controlling traffic between pods.
• Flannel: A simpler option that provides basic overlay networking.
• Cilium: Uses eBPF for high-performance networking and advanced observability.

Without a CNI plugin, pods on different nodes would have no way to reach each other. The plugin is responsible for assigning IP addresses to pods, setting up routes between nodes, and ensuring that the flat networking model Kubernetes expects is actually in place.

Understanding the role of the CNI shows the interviewer that you know Kubernetes defines the rules for networking, but relies on external components to enforce them.

What is a DaemonSet?

This question often comes in the form of "how would you run a service on every node in the cluster without using a Deployment?" If you hear that phrasing, the answer is a DaemonSet.

A DaemonSet ensures that a copy of a specific pod runs on every node in the cluster (or a defined subset of nodes). When a new node is added to the cluster, the DaemonSet automatically schedules a pod on it. When a node is removed, that pod is cleaned up.

This makes DaemonSets the right choice for workloads that need to be present everywhere, such as:

• Log collectors like Fluentd or Filebeat that need to gather logs from every node.
• Monitoring agents, such as a Prometheus node exporter, need to report metrics from each machine.
• Network plugins such as the CNI components which must be running on every node for pod networking to function.

The key difference from a Deployment is intent. A Deployment lets you say "run N replicas somewhere in the cluster," and the scheduler decides where. A DaemonSet says, "run exactly one replica on every eligible node."

What are requests and limits?

Central to Kubernetes resource management are requests and limits. The interviewer is checking that you understand how Kubernetes decides where to place pods and what happens when a container tries to use more resources than it should.

What are QoS classes?

This is usually a follow-up to questions about requests and limits, as Kubernetes automatically assigns a Quality of Service class to each pod based on how those values are configured.

The default QoS class is BestEffort, which is assigned when a pod has no requests or limits set at all. This is the lowest priority class. Other classes include:

The QoS class matters most during node pressure events. When a node starts running out of memory, Kubernetes decides which pods to evict first. BestEffort pods are evicted first, then Burstable, and Guaranteed pods are evicted last. Understanding this helps you make informed decisions about how to configure requests and limits for workloads of different importance.

What is a Pod Disruption Budget?

This would often come phrased as "if you wanted to ensure that a certain number of pods are always available during maintenance or voluntary disruptions, how would you do it?"

A Pod Disruption Budget (PDB) lets you tell Kubernetes the minimum number of pods in a group that must remain available at any given time during voluntary disruptions. Voluntary disruptions include things like node drains, cluster upgrades, or autoscaler scale-downs. They do not cover involuntary disruptions like hardware failures or kernel crashes.

You define a PDB by specifying either a minAvailable or maxUnavailable value alongside a label selector that matches the pods you want to protect. For example, if you have 5 replicas of a service and set minAvailable: 3, Kubernetes will block any voluntary disruption that would bring the available count below 3.

This is particularly important in production environments where you are running rolling cluster upgrades or need to drain nodes for maintenance. We go into detail about Pod Disruption Budgets in this article.

What is GitOps, and how does it relate to Kubernetes?

When answering this question, you want to be mindful of the fact tha,t as much as GitOps tooling exists, it is first and foremost a methodology for deploying and managing applications using Git as the single source of truth.

GitOps is an approach where you declare the desired state of your infrastructure and applications in a Git repository, and an automated process ensures that the actual state of your cluster matches what is defined in Git. If a developer wants to change a deployment, they open a pull request. Once merged, the change gets applied to the cluster automatically.

The core principles are:

• The entire desired state of the system is described declaratively and stored in Git.
• Any change to the system goes through Git, giving you a full audit trail and the ability to roll back by reverting a commit.
• An agent running in the cluster continuously compares the desired state in Git with the actual state in the cluster. If something drifts (for example, someone manually edits a resource with kubectl), the agent detects this and reconciles it back to what Git says it should be.

This last point is what separates GitOps from a standard CI/CD pipeline that pushes changes to a cluster. In GitOps, the cluster pulls its own state from Git and self-corrects, rather than relying on an external system to push updates.

Common tools that implement this pattern include:

What is RBAC in Kubernetes?

RBAC (Role-Based Access Control) is how Kubernetes controls who can do what within a cluster. This is a common interview question because it touches on security, multi-tenancy, and operational maturity. The interviewer wants to see that you understand not just the concept but how the pieces fit together in practice.

A good place to start is from the perspective of checking permissions. The command kubectl auth can-i lets you verify whether a given user or service account has permission to perform a specific action. For example:

kubectl auth can-i create deployments --namespace production

This returns a simple yes or no. It is a useful debugging tool when someone reports they cannot perform an action, and it is also a good way to audit what access exists in the cluster. You can also impersonate other users to check their permissions:

kubectl auth can-i get secrets --as system:serviceaccount:default:my-app

The permissions that can-i checks against are defined through four key RBAC resources:

A practical pattern is to define a ClusterRole once (for example, a "read-only" role that can list and get most resources) and then bind it at the namespace level using a RoleBinding where needed. This avoids duplicating Role definitions across namespaces.

Service account tokens are how pods authenticate to the API server. Every pod in Kubernetes runs under a service account, and by default it gets the default service account in its namespace. That default account typically has very limited permissions.

Since Kubernetes 1.24, service account tokens are no longer automatically mounted as long-lived secrets. Instead, Kubernetes uses bound, time-limited tokens projected into the pod. This is worth mentioning because it shows awareness of how token management has tightened over recent versions.

What is a LoadBalancer in Kubernetes?

This question checks whether you understand how traffic from outside the cluster reaches your applications. We touched on this briefly when discussing Service types, but the interviewer may want you to go deeper.

A LoadBalancer is a Service type that provisions an external load balancer, typically through your cloud provider. When you create a Service with type: LoadBalancer, Kubernetes asks the underlying infrastructure (Civo, GCP, Azure, etc.) to spin up a load balancer that routes external traffic to the correct set of pods.

Each LoadBalancer Service gets its own external IP address. This works well when you have a small number of services to expose, but it becomes expensive and hard to manage as the number grows. Every service gets a separate load balancer, each with its own IP and associated cloud cost.

What is an Ingress?

This is a common follow-up to the LoadBalancer question, and the interviewer is not only checking whether you understand the difference but also whether you can identify when a LoadBalancer alone is not sufficient.

An Ingress is a Kubernetes resource that manages external HTTP and HTTPS traffic and routes it to different services within the cluster based on rules you define. Instead of provisioning a separate load balancer for every service, you deploy a single Ingress controller (such as NGINX Ingress Controller or Traefik) behind one LoadBalancer, and then define routing rules that direct traffic based on hostnames or URL paths.

For example, you could configure an Ingress so that:

• api.example.com routes to your API service
• app.example.com routes to your frontend service
• app.example.com/docs routes to a documentation service

This gives you a single entry point to the cluster with flexible routing, TLS termination, and other HTTP-level features, all managed declaratively through Kubernetes resources.

However, Ingress has its limitations. The resource spec is relatively simple and does not natively support things like traffic splitting, header-based routing, or fine-grained control over how different teams manage their own routing. Much of this functionality ends up being handled through provider-specific annotations, which reduces portability between Ingress controllers.

What is the Gateway API?

This would usually come in the form of "why would you pick Ingress over the Gateway API (or vice versa)?" The answer here is less technical and more organizational.

The Gateway API is a newer Kubernetes standard for managing traffic routing into and within a cluster. It was designed to address the limitations of Ingress by providing a more expressive, extensible, and role-oriented model.

Where Ingress uses a single resource for everything, the Gateway API splits responsibilities across multiple resources:

The Gateway API also natively supports features like traffic splitting, header matching, and cross-namespace routing without relying on annotations.

What are CRDs in Kubernetes?

A Custom Resource Definition (CRD) is a way to extend the Kubernetes API with your own resource types. Out of the box, Kubernetes knows about resources like Pods, Services, and Deployments. A CRD lets you define something entirely new, for example, a Database or Certificate resource, and Kubernetes will treat it like any other native resource. You can create, list, update, and delete instances of it using kubectl.

On its own, a CRD just stores data in the API. It does not do anything until you pair it with a controller that watches for those resources and acts on them.

What is a Kubernetes controller?

A controller is a loop that watches the current state of a resource and works to bring it in line with the desired state. This is the core pattern behind how Kubernetes operates.

Kubernetes ships with many built-in controllers. For example:

• The Deployment controller watches Deployment resources and ensures the correct number of ReplicaSets and pods exist, handling rollouts and rollbacks.
• The ReplicaSet controller ensures the right number of pod replicas are running at any given time.
• The Job controller manages pods that are expected to run to completion and tracks whether they succeeded or failed.

Each of these follows the same pattern: observe the desired state, compare it to what is actually running, and take action to reconcile any differences.

What is an Operator, and how is it different from a controller?

The Operator pattern was pioneered by CoreOS (later acquired by Red Hat) as a way to encode operational knowledge into software. The idea was that managing complex stateful applications like databases, message queues, or monitoring systems requires domain expertise that goes beyond what basic Kubernetes controllers handle. An Operator captures that expertise in code.

In practical terms, an Operator is a controller paired with one or more CRDs. The CRD defines the application-level resource (for example, a PostgresCluster), and the controller contains the logic for managing the full lifecycle of that application: provisioning, scaling, backups, upgrades, and failure recovery.

So the difference is one of scope. Every Operator is a controller, but not every controller is an Operator. A controller reconciles the state for a given resource. An Operator does the same thing but embeds application-specific operational logic that would otherwise require a human administrator to perform manually.

What is Helm?

Helm describes itself as a package manager for Kubernetes. In the same way you might use apt or yum to install software on a Linux machine, Helm lets you package, version, and install applications on a Kubernetes cluster.

A Helm package is called a chart. A chart contains all the Kubernetes manifests needed to run an application (Deployments, Services, ConfigMaps, etc.) along with a values.yaml file that lets you customize the configuration without editing the manifests directly. For example, a single chart for a web application could be deployed across staging and production by passing in different values for replica count, image tag, or resource limits.

Charts can be shared through repositories, and many open source projects publish official Helm charts. This means you can deploy something like PostgreSQL or Prometheus with a single command and customize it through values rather than writing manifests from scratch.

How does Kustomize differ from Helm, and when would you pick one over the other?

This often comes up as a follow-up to Helm questions. The interviewer wants to see that you understand there is more than one approach to managing Kubernetes manifests and that each has trade-offs.

Kustomize takes a different approach. Instead of templates with placeholder values, you write plain Kubernetes YAML and then apply patches and overlays to modify it for different environments. There is no templating language involved. You start with a base set of manifests and then layer on changes using a kustomization.yaml file that specifies what to add, remove, or override.

For example, your base might define a Deployment with 2 replicas and a default image tag. Your production overlay would patch the replica count to 5 and swap in the production image. The base manifests remain valid Kubernetes YAML at all times, which makes them easier to read and validate.

What are Admission Controllers?

Admission controllers sit in the request path between the API server receiving a request and the resource being persisted to etcd. They intercept requests to create, update, or delete resources and can either modify or reject them before anything is written.

There are two types:

• Mutating admission controllers can modify the incoming request. For example, automatically injecting a sidecar container into every pod, adding default resource limits, or attaching labels that your organization requires.
• Validating admission controllers check whether a request meets certain criteria and reject it if it does not. For example, blocking any pod that tries to run as root, or ensuring every Deployment has a specific annotation.

Mutating controllers always run first, then validating controllers run against the final version of the resource. This ordering matters because validation should check what will actually be persisted, including any changes made by mutation. Kubernetes ships with several built-in admission controllers, but you can also define your own policies using tools like OPA/Gatekeeper or Kyverno, which let you write custom validation and mutation rules without building a webhook from scratch.

What is a sidecar container?

A sidecar is an additional container that runs alongside your main application container within the same pod. Because they share the same network namespace and can share storage volumes, the sidecar can complement the main container without the application needing to know about it.

A prevailing use case is log collection. Your application writes logs to a shared volume, and a sidecar container running something like Fluentd or Filebeat reads from that volume and forwards the logs to a centralized system. The application itself does not need any logging library or integration. It just writes to disk, and the sidecar handles the rest.

What is a service mesh?

This often comes in the form of "tell me about Istio or Linkerd" or "why would you use a service mesh?" The interviewer is trying to understand whether you know the actual use case for a service mesh and can articulate when it is and is not worth the added complexity.

A service mesh itself is simply a dedicated infrastructure layer that manages communication between services within your cluster. It works by deploying a proxy (typically Envoy) as a sidecar alongside each pod. These proxies handle all network traffic between services, giving you a consistent way to apply policies and observe communication without modifying application code.

The capabilities a service mesh provides include:

Historically, service meshes gained traction because ingress controllers lacked many of these features natively. If you needed traffic splitting, mutual TLS between internal services, or detailed observability, a mesh was often the only practical option.

However, with the Gateway API maturing and supporting features like traffic splitting, header-based routing, and cross-namespace routing out of the box, the justification for adopting a mesh purely for traffic management is harder to make than it used to be. The Gateway API covers a growing portion of what teams previously needed a mesh for.

Where a service mesh still holds clear value is in mTLS enforcement across all service-to-service communication and deep observability at the network layer. If your organization has strict security requirements around encryption in transit or you need granular visibility into how services communicate, a mesh addresses those needs in a way that the Gateway API does not.