100 Kubernetes Interview Questions That Will Land You Any Kubernetes Job

This blog post is a collection of Kubernetes interview questions that will help you get the job of your dream. Make sure you memorize a short answer and can provide a detailed explanation in your own words.

Our goal was to make this guide as technical and detailed as possible. We assume you already know what Kubernetes is, are familiar with general ideas of containerization, and understand the benefits of these technologies. Therefore, we omit generic questions and dive right into detailed, practical, and low-level questions, which are more likely to be asked during a Kubernetes interview.

You can use this as a roadmap for your interview preparation or as a last-minute knowledge check.

Expand to reveal the answer and further related questions ????????????

Kubernetes Interview Questions – Part 1 – Kubernetes Architecture

kubernetes interview questions - kubernetes architecture

As of September 2022, the latest version of Kubernetes is 1.25, also called “Combiner”.
However, it is crucial to understand that Kubernetes is still in active development, and new versions are released every several months.

The control plane components work together to coordinate the activities of a Kubernetes cluster. The control plane is responsible for managing the cluster’s state, ensuring that its desired configuration is always maintained.

The Kubernetes data plane is the part of a cluster responsible for running the workloads. In other words, all nodes in a cluster belong to a data plane.

What are the main Kuberenets components?

For a complete and working Kubernetes cluster, you will need the following components:

  • API Server;
  • etcd;
  • kubelet;
  • kube-proxy;
  • Scheduler;
  • Controller Manager;
  • Cloud Controller Manager;
  • Container Runtime.

The API Server is the heart and soul of the Kubernetes control plane. It exposes the Kubernetes API and acts as a gateway, providing the API for all other components and external clients.

Etcd is a key-value store that is being used for holding configuration data, state data, and metadata. Kubernetes uses etcd to save information such as the list of nodes in the cluster, the desired state of all workloads that are running in the cluster, and cluster events.

Kubelet is a Kubernetes agent that runs on each node in a Kubernetes cluster. Its role is to ensure that all pods scheduled on the node are running and healthy.

Kube-proxy is a networking service that runs on each node in a Kubernetes cluster. It is responsible for maintaining network rules on the node and provides services such as port forwarding and load balancing for Kubernetes services.

The scheduler is a Kubernetes control plane component that assigns newly created pods to nodes in a cluster. It tracks various parameters such as resource requirements, hardware constraints, and affinity rules, taking them into account during scheduling decisions.

The Controller Manager is a Kubernetes component that manages controllers.

The Kubernetes controller is an infinite loop that watches the state of the API object and makes required changes ensuring that its observed state matches the desired state.

Cloud Controller Manager is a dedicated Kubernetes component that manages cloud-specific controllers.

A container runtime provides the low-level components needed to launch and run containers. It sets up the underlying kernel primitives, such as namespaces and control groups, and provides a high-level API for container management.

The following Container runtimes are supported by Kubernetes:

  • containerd;
  • CRI-O;
  • Docker Engine;
  • Mirantis Container Runtime;

The Kubernetes Control plane components are:

  • API Server;
  • etcd;
  • Scheduler;
  • Controller Manager;
  • Cloud Controller Manager;

The Kubernetes Data Plane components are:

  • kubelet;
  • kube-proxy;
  • Container Runtime;

Part 2 – Kubernetes API

The component responsible for providing access to Kubernetes API is called API Server.

We can interact with Kubernetes API through the following tools:

  • kubectl;
  • rest API using kubectl proxy;
  • rest API by passing an authentication token directly;
  • official client libraries.

The current workloads will continue to run. However, neither clients nor internal Kubernetes components would be able to interact with the Kubernetes API and record any changes in the state of a cluster.

The main Kubernetes API objects are:

  • Pod
  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Service
  • Ingress
  • ConfigMap
  • Secret
  • PersistentVolume
  • PersistentVolumeClaim
  • StorageClass
  • Namespace
  • ServiceAccount
  • Role
  • RoleBinding
  • ClusterRole
  • ClusterRoleBinding

A Pod is the thinnest Kubernetes abstraction. It consists of one or more containers that share storage and network settings with each other. Containers within a pod always run together on the same node with a shared context.

A ReplicaSet is a group of identical pods with the same label selector. A ReplicaSet ensures that a specified number of pod replicas are running at any given time. If a pod dies, the ReplicaSet automatically replaces it with a new one.

A deployment is a Kubernetes object that encapsulates a ReplicaSet and provides declarative updates (i.e. desired state management) for Pods.

The main difference between a Deployment and a ReplicaSet is that a Deployment manages a ReplicaSet, and a ReplicaSet only manages Pods.

A StatefulSet is a special type of Deployment that manages a set of identical Pods that are scaled together. Pods in a StatefulSet have a fixed identity(pod name) that is maintained across restarts.

A DaemonSet runs a copy of a Pod on each node of a cluster. When a node is added to the cluster, the DaemonSet schedules a Pod there. When a node is removed, those Pods are deleted.

A namespace is a logical entity used to segregate resources within a Kubernetes cluster. Each namespace is isolated from other namespaces and provides a unique scope for resources within the cluster.

Kubernetes resources that are namespaced:

  • Pods
  • ReplicationControllers
  • Deployments
  • Services
  • Secrets
  • ConfigMaps
  • Roles
  • RoleBindings
  • PersistentVolumeClaims

Kubernetes resources that are not namespaced:

  • Nodes
  • Events
  • PersistentVolumes
  • ClusterRoles
  • ClusterRoleBindings

The top-level properties of a Kubernetes API object are:

  • apiVersion;
  • kind;
  • metadata;
  • spec;
  • status;

Kubernetes apiVersion is a string that specifies the API version to use

The examples of apiVersions are:

  • apps/v1
  • batch/v1
  • v1
  • alpha

Kubernetes API kind represents an object in the Kubernetes system; for example, Deployment is a kind. Each object kind has a different set of attributes and behaviors.

Kubernetes metadata is data that describes Kubernetes objects. Metadata often store information that is not part of the object’s core properties.

The examples of the metadata fields are:

  • name;
  • namespace;
  • UID;
  • resourceVersion;
  • generation;
  • creationTimestamp and deletionTimestamp;
  • labels;
  • annotations.

The UID is an identifier that is used to distinguish between objects with the same name that have been deleted and recreated.

The resourceVersion field is used by clients to find out when objects have changed.

The creationTimestamp and deletionTimestamp are fields representing the date when the object was created or deleted.

Labels are key-value pairs that are used to organize and categorize objects.

Annotations are the key-value fields that are used by external tooling to store and retrieve arbitrary metadata about the object.

The spec is an API field containing information about a Kubernetes object’s desired state.

The status field indicates the current status of the resource. For example, a pod’s status might include information about its current phase, what containers are running in the pod, and the pod’s IP address.

The Kubernetes API verb is a set of operations that can be performed on a Kubernetes resource.

Kubernetes supports the following API verbs:

  • get
  • create
  • apply
  • update
  • patch
  • delete
  • proxy
  • list
  • watch

Kubernetes Interview Questions – Part 3 – RBAC and Security

kubernetes interview questions - kubernetes security

The RBAC stands for Role-Based Access Control. This mechanism allows you to manage permissions for users and groups within a Kubernetes cluster. With RBAC, you can define who has access to what and under which conditions.

There are the following components of Kubernetes RBAC:

  • Role;
  • RoleBidning;
  • ClusterRole;
  • ClusterRoleBinding,

A role is a definition of a set of permissions that can be applied to one or more users or service accounts.

A RoleBinding is an object that allows you to bind a role or a cluster role to a user or a service account.

A ClusterRole is the same as a role but cluster-wide. Permissions assigned via cluster role are not limited by any namespace.

A ClusterRoleBinding is the same as a role, but cluster-wide and used with cluster roles.

The AAA in Kubernetes stands for:

  • Authentication
  • Authorization
  • Admission

Authentication is the procedure of verifying that someone is who they say they are.

Authorization is verifying that someone has the right to perform an action or access a resource.

In Kubernetes, Admission is a process of validating and admitting a resource into the cluster. Admission controllers are Kubernetes components that intercept requests to the Kubernetes API before the persistence of the object in etcd.

“kubectl auth can-i” is a command that will check if the user has permission to perform an action on a resource.

A ServiceAccount is an account used by a workload to interact with the Kubernetes API. Service accounts give processes the ability to perform a certain set of actions within a cluster.

A SecurityContext is a setting that defines security settings, privilege, and access control settings for a Pod.

Security context settings include:

  • User Id and Group Id;
  • SELinux settings;
  • Container privileges;
  • Linux capabilities.

Part 4 – Kubernetes Networking

kubernetes interview questions - kubernetes networking

Kubernetes Services are a way to expose an application running on a set of Pods via a network. A service defines a collection of pods and a collection of networking rules for accessing them.

The following types of Services exist in Kubernetes:

  1. ClusterIP;
  2. NodePort;
  3. LoadBalancer;
  4. ExternalName.

The ClusterIP service is a service that exposes an application running on a set of Pods to other applications within the same cluster.

The NodePort service is a ClusterIP service with a manually specified port (the NodePort) that is opened on every node in the cluster. When a client requests a NodePort service, the request is automatically routed to one of the nodes in the cluster, and that node proxies the request to the Service.

The LoadBalancer service makes a service accessible to external clients. When created, Kubernetes creates an external load balancer (if the cloud provider supports it) and maps the service to the load balancer.

The ExternalName service maps a service to an external DNS name. This can be used to access services such as an external database or an API.

An Ingress is an API object responsible for routing external traffic to services within a Kubernetes cluster.

An ingress controller is a set of resources running inside a Kubernetes cluster and implementing a backend for ingress functionality.

Some examples of popular ingress controllers are:

  • Contour
  • Nginx Ingress controller
  • Ambassador
  • AWS Load Balancer controller

The CNI, or a Container Network Interface, is a set of plugins used for configuring network interfaces in Kubernetes pods. CNI is the operating system component that routes the actual network request to a container.

The most popular CNI are:

  • Flannel
  • Calico
  • Cillium
  • Weave Net
  • Canal

The network policy is an API object that defines how Pods and Services are allowed to communicate with each other and other the network.

The following CNI drivers support network policy:

  • Calico
  • Cillium
  • Weave Net
  • Canal

The following CNI driver does not support network policy:

  • Flannel

The “pause” container is a special container that is not visible via Kubernetes API. It holds the network namespace for the pod. Kubernetes creates pause containers to acquire the respective pod’s IP address and set up the network namespace for all other containers that join that pod. Due to the pause container, crashed and restored containers within a Pod maintain the same IP address.

A sidecar proxy is a container that is deployed alongside a primary container providing it with additional networking functionality. It intercepts all the network requests sent by the primary container and provides features such as encryption, request routing, and observability. A sidecar proxy is one of the main building blocks for a service mesh.

A service mesh is an infrastructure layer that allows you to manage communication between microservices. It handles things like routing, load balancing, and service discovery, and can provide features like observability, security, and resiliency.

The most popular service meshes are:

  • Istio;
  • Linkerd;
  • Consul.

Kubernetes Interview Questions – Part 5 – Configuration, Deployment, and Resource Management

The main options for passing configuration information into a Kubernetes Pod are:

  • ConfigMap
  • Secret

A ConfigMap is an API object that acts as a dictionary of key-value pairs that store configuration data for your application.

A Secret is an API object similar to ConfigMap but designed for storing sensitive data.

By default, Secrets are not encrypted. Instead, they are just base64-encoded.

You can use downward API to inject any information about a Pod into a container within this pod. This includes things like:

  • name;
  • namespace;
  • labels;
  • any other metadata or spec field.

The main ways of managing resources assigned to a container are:

  • Requests and limits
  • Limit ranges

We can use requests and limits to control:

  • CPU;
  • Memory;
  • Hugepages;

Resources specified in the requests field must be reserved for a container. The kube-scheduler uses this information to decide which node to place the Pod on. The Pod will be scheduled only if a Node has enough resources to accommodate the request.

When limits are specified, a container is not allowed to use more resources than what is set in the limit.

Kubernetes evaluates requests and limits settings and assigns a so-called Quality of Service class or QoS.

The following QoS classes exist in Kubernetes:

  • Guaranteed
  • Burstable
  • BestEffort

The Guaranteed QoS class will be assigned if:

  • Every Container in the Pod has memory limits and memory requests.
  • Every Container in the Pod has memory limits equal to memory requests.
  • Every Container in the Pod has CPU limits and CPU requests.
  • Every Container in the Pod has CPU limits equal to CPU requests.

The Burstable QoS class will be assigned if:

  • The Pod does not fall under the criteria for QoS class Guaranteed.
  • At least one Container in the Pod has a memory or CPU request or limit.

The BestEffort QoS class is assigned if Containers in the Pod don’t have any memory, CPU limits, or requests.

A limit range is a setting that is applied on a namespace level and enforces additional resource usage constraints.

The LimitRange allows to:

  • Constrain on a minimum and maximum resource usage per Pod or Container in a namespace.
  • Constrain on a minimum and maximum storage request per PersistentVolumeClaim in a namespace.
  • Enforce a ratio between request and limit for a resource in a namespace.
  • Set default request and limit for resources in a namespace and automatically inject them to Containers.

A pod will hang in a pending state unless the requested resources become available.

A container will be throttled if it tries to use more CPU than the limit assigned to it.

Currently, there is no way to throttle memory usage. This means a container will be killed with the OOMKilled status and restarted.

The most popular solutions for managing Kubernetes manifests are:

  • helm
  • kustomize
  • jsonnet

Helm is a Kubernetes package manager that allows configuring and managing Kubernetes applications more easily.

kustomize is a tool for customizing Kubernetes resources. It can be used to create, edit, and delete resources and to apply patches.

jsonnet is a tool for generating JSON files, including Kubernetes manifests.

GitOps is a practice for managing software deployments and infrastructure changes using git repositories. GitOps involves using a git repository as the source of truth for both your application code and your infrastructure code. This approach allows you to use the same tools and workflows for managing both codebases and makes it easy to track changes and rollbacks.

The most popular GitOps tools are:

  • ArgoCD
  • FluxCD

Part 6 – Scheduling

Kubernetes scheduling refers to the process of allocating Pods to nodes in a Kubernetes cluster. This process is responsible for ensuring that all Pods in a are scheduled to run on available nodes.

The Kubernetes component responsible for scheduling Pods is the Scheduler.

After a Pod is created, the scheduler determines which Node has enough resources to run the Pod. After that, the scheduler modifies the nodeName field of a Pod specification. After that, kubelet on a selected Node picks up a manifest and creates all the containers specified in a Pod.

Existing workloads will continue to run, while new Pods will remain unscheduled.

You can instruct a Pod to run on a particular Node by using any of these:

  • node selector with node labels;
  • node affinity;
  • the nodeName field;
  • Pod topology spread constraints;

You can add the nodeSelector field to the definition of your Pod and provide the labels you want the target to have. Kubernetes only schedules the Pod to nodes that have each of the labels you specify.

Node affinity is very similar to nodeSelector. It also allows you to constrain nodes your Pod can be scheduled on based on node labels, but a little more flexible.

The nodeName field is a more direct way of node selection. If the nodeName field is not empty, the scheduler ignores the Pod, and the kubelet on the named node tries to place the Pod on that node. Using nodeName overrides using nodeSelector or affinity and anti-affinity rules.

You can use taints to prevent certain Pods from being scheduled on a Node

You can use tolerations to instruct a Pod to ignore taints.

To prevent two pods from running on the same Node, you can use podAntiAffinity.
To instruct two Pods to run on the same Node, you can use podAffinity.

For both nodeAffinity and podAffinity, there are two types of affinity rules:

  • requiredDuringSchedulingIgnoredDuringExecution
  • preferredDuringSchedulingIgnoredDuringExecution

The hard rule. The scheduler can’t schedule the Pod unless it is satisfied.

The soft rule. The scheduler will attempt to find a node that meets the criteria. If no matching nodes are available, the scheduler still schedules the Pod.

Kubernetes Interview Questions – Part 7 – Storage

kubernetes interview questions - kubernetes storage

What storage options exist in Kubernetes?

The storage abstractions of Kubernetes are:

  • Volume
  • PersistentVolume
  • PersistentVolumeClaim
  • StorageClass

A volume is a directory that stores data used by a pod. Volumes are attached to pods and exist as long as the pod does. A single Kubernetes volume can be shared by multiple containers within a single Pod.

A PersistentVolume is an API object that represents a piece of storage in the cluster.

A PersistentVolumeClaim is a request for storage created by a user. It is similar to a Pod – Pods consume node resources, and PVCs consume PV resources.

There are two ways PVs may be provisioned: static provisioning and dynamic provisioning.

A cluster administrator creates persistent volumes manually.

The cluster will dynamically provision a volume exclusively for the persistent volume claim using a storage class if none of the static persistent volumes match a PersistentVolumeClaim.

A StorageClass provides a way to define the “class” of storage they want for their applications. Which is later can be used for dynamic provisioning – creating a PersistentVolumeClaim without having to manually create a PersistentVolume.

PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:

  • local – local storage devices mounted on nodes;
  • nfs – Network File System (NFS) storage;
  • cephfs – CephFS volume;
  • fc – Fibre Channel (FC) storage.

Part 8 – Troubleshooting Kubernetes

kubernetes interview questions - kubernetes troubleshooting

To debug a Pod, you can do the following:

  • Use kubectl describe pod to fetch details of the pod;
  • Use kubectl logs to obtain logs from the failed pod;
  • Exact into a container using the “kubectl exec” command;
  • Connect an ephemeral container using the “kubectl debug” command.

To obtain logs from a Kubernetes Pod, you can use the “kubectl logs” command.

There are no logs yet since the Pending container is not scheduled and hasn’t started yet. This means we can’t use “kubectl logs”. Instead, “kubectl describe” should be used.

The CrashLoopBackOff is an error state in Kubernetes where a container continuously restarts but never succeeds in staying up for more than a few seconds. This can be caused by a number of factors, such as a misconfigured container or a bug in the application code.

That happens when a ReplicaSet is unable to create a Pod. You need to run “kubectl describe replicaset” to get more details about the reason for that issue.

The debug container is an ephemeral container that can be attached alongside the failed container you wish to debug. This is useful when your primary container does not have utilities that are required for debugging installed in it.

Kubernetes Interview Questions – Part 9 – Kubernetes Operators

A Kubernetes Operator is a way of packaging, deploying, and managing a Kubernetes application. An Operator is essentially a human operator but embodied in a piece of software. It makes use of the Kubernetes API to automate the management of an application.

The main building blocks of an operator are:

  • Custom Resource Definition and Custom Resource;
  • Controller.

A custom resource is a primary option to extend the Kubernetes API. It allows adding new resource types that are not available by default in a Kubernetes cluster.

A Custom Resource Definition (CRD) is a manifest defines a custom resource.

A Kubernetes controller is a loop that watches the state of the API object or the Custom Resource and makes necessary changes ensuring that the observed state of the API object matches the desired one.

The Kubernetes Operator Framework is a set of tools and practices for simplifying the development and distribution of Kubernetes Operators.

A set of tools that helps to start developing an Operator project from scratch is called Operator SDK. It includes predefined APIs, some standard functions, and code generators.

Operator Lifecycle Manager is a tool that runs inside a Kubernetes cluster and provides functionality for interacting with Kubernetes Operators. It is mainly used for the installation and upgrading of Operators.

OperatorHub is an open catalog of publicly available operators.

Before We Finish

Memorizing questions without having a proper understanding isn’t usually effective. Make sure you can explain each and every concept mentioned in this article in your own words.

Also, you should never forget about practice. Focusing on learning theory and implementing it in a real environment will produce the best result.

If this list of Kubernetes interview questions helped you, please support our effort by sharing the article with your friends and colleagues. Our mission is to help as many people as possible to get a better life by landing high-paying jobs in Kubernetes, Cloud-Native, and DevOps.

You can contribute your own question and get featured by filling out the form ????????????
Contribute Your Question

Shot-out to contributors and reviewers: Vladimir Mukhin, Ekaterina Krasnova, Geoffrey Israel Chinedu

You can find other interesting articles on our blog: https://yourdevopsmentor.com/blog/

Apply for individual mentorship here: https://yourdevopsmentor.com/apply/

Originally published Sep 13, 2022 7:07:27 PM (updated September 20 2022 )

Leave a Reply

Your email address will not be published. Required fields are marked *