Many organizations today are relying on the power of Kubernetes to manage their cloud-native workloads more efficiently. Increased adoption of microservices architecture across organizations has led to a surge in containers and orchestration tools like Kubernetes. This also means that demand for Kubernetes experts is at an all-time high, and you could earn at least 10-20% more money if you pursued a Kubernetes career path over a standard DevOps career.
So you can see why it’s in your best interests to position yourself as a Kubernetes expert in your next job interview. This means more than simply having a good understanding of the architecture—you have to know the kinds of questions you might be asked in an interview.
In this article, we’ll help you ace that interview by going through the most common questions that interviewers are likely to test your Kubernetes knowledge with.
Basic Kubernetes Architecture
It is quite possible that you will be asked to explain Kubernetes architecture during your interview. Basically, Kubernetes follows a client-server architecture, where its clusters are made up of master and worker nodes.
Master Node Components
The master node works as the server-side component, and worker nodes act as the client. In simple terms, a master node is a “brain,” or the central nervous system of your cluster, and worker nodes are the various body parts that act according to the instructions received from the brain.
The master node consists of the following components:
These components form the control plane for the Kubernetes cluster. For your production workloads, you typically run multiple control planes and worker nodes spanning across multiple computers to provide fault-tolerance and high availability.
Let’s look at each of these components in detail.
It acts as the gateway or an interface for all your cluster communication, internal or external. External clients can interact with the cluster via kuber-apiserver using the REST API or kubetcl. Worker nodes also communicate to the master node using the same API exposed by kuber-apiserver. For HA, you can run and scale <terminal inline>kube-apiserver<terminal inline> horizontally on multiple nodes.
A Kubernetes cluster consists of metadata, objects, cluster configuration, the desired state of the cluster, and other such information that needs to be stored somewhere reliably. <terminal inline>etcd<terminal inline> is a highly available distributed key-value store, and acts as a storage for persisting this information. Any interaction to <terminal inline>etcd<terminal inline> is via the <terminal inline>kube-apiserver<terminal inline> for checking the state of the cluster or getting any metadata.
This component runs the controller process. A controller process is a non-terminating loop that tracks the system’s state through an API server. It makes sure that the current state of the cluster matches the declared desired state. Here are some of the different types of controllers available:
- Node controller
- DaemonSet controller
- Deployment controller
- Namespace controller
This component manages the scheduling of pods on the worker nodes. A <terminal inline>kube-scheduler<terminal inline> picks up a newly created pod or an unscheduled pod waiting for scheduling to schedule the pod on the node that meets the requirement or is optimal for that particular pod.
As the name suggests, the <terminal inline>cloud-control-manager<terminal inline> is responsible for managing the controller provided by cloud providers. As a result, Kubernetes can provide a standardized experience among different cloud providers because of <terminal inline>cloud-control-manager<terminal inline>.
Worker Node Components
We have discussed the master node components and now let’s talk about the components for the worker node. A worker node can be a physical or virtual machine and is primarily responsible for running containers, reporting health-related data back to master nodes, and managing access to containers through network proxies. These components are:
<terminal inline>kubelet<terminal inline> is an agent that runs on every worker node of the Kubernetes cluster. It’s primary job is to manage containers in a pod and make sure that they are running as per the <terminal inline>PodSpecs<terminal inline>(YAML or JSON object). <terminal inline>kubelet<terminal inline> agent directly communicates with the control plane through <terminal inline>kube-apiserver<terminal inline> and executes action on the node on its behalf.
<terminal inline>kube-proxy<terminal inline> as the name suggests acts as a network proxy which is available on all the nodes of your cluster. <terminal inline>kube-proxy<terminal inline> facilitates the communication between containers running on different nodes of the cluster from both inside and outside of the cluster.
Container runtime is a software installed on each node of your cluster that is required for running containers inside your pods. Docker, containerd, CRI-O are some of the popular container runtime interfaces. However support for Docker as a container runtime on Kubernetes is deprecated and will be removed in future.
Kubernetes Core Concepts
You have built some understanding about the Kubernetes internals and the components that build up its architecture. But, there are many other important topics or concepts that can come during a Kubernetes interview. For example, the interviewer might ask about a pod?. How will you expose your Pods for external access? What are deployments?
This section will go through some of the essential concepts and topics typically asked in an interview.
- What is a pod?
- What are ReplicaSets?
- What are DaemonSets?
- What are Deployments?
- What are StatefulSets?
- What is a Kubernetes Service?
- What are Namespaces?
- What are ConfigMaps?
- What are Secrets?
- What are PersistentVolumes?
- What are PersistentVolumeClaims?
- How would you explain Liveness and Readiness Probes?
What Is a Pod?
In non-technical terms, a pod is a group of closely related whales. Likewise, in Kubernetes, a pod is a group of related containers. Kubernetes considers pods as the smallest unit of work besides containers. So your containers live inside a pod, and Kubernetes deploys a pod to a node. A pod can contain many containers, but as the pod is the replication unit in Kubernetes, you’ll often want to adopt a single container per pod strategy. For example, if you need to scale your containers individually, you have to use this strategy.
If you are unsure if two containers should go inside a pod, follow this rule: If two containers have different scaling needs and can work without needing each other, put them in different pods.
What Are ReplicaSets?
A <terminal inline>ReplicaSet<terminal inline> ensures that a declared number of pods are running at any given time. In other words, it guarantees the availability of a specified number of identical pods.
What Are DaemonSets?
<terminal inline>DaemonSets<terminal inline> are helpful when we have to run a pod on all or a subset of the nodes. It is typically used for log collections and node monitoring.
What Are Deployments?
Deployments are Kubernetes objects that provide declarative updates to pods and <terminal inline>ReplicaSets<terminal inline>. Think of Deployment like a pod manager that can manage and create pods separately. You describe the desired state through <terminal inline>ReplicaSets<terminal inline>in the YAML or JSON Deployment object, and <terminal inline>Deployment Controller<terminal inline> changes the actual state to the desired state in a controlled manner. <terminal inline>Deployments<terminal inline> are typically used for the deployment of stateless applications.
What Are StatefulSets?
StatefulSets are used for deploying stateful applications on Kubernetes. They are similar to <terminal inline>Deployments<terminal inline>; the only difference being that pods are created with unique names and ordering. <terminal inline>StatefulSets<terminal inline> are helpful in workloads that require storage volumes to persist data, i.e., databases such as mysql or mongo database. <terminal inline>StatefulSets<terminal inline> should be used when your workloads require ordered deployment, scaling, and deletion.
What Is a Kubernetes Service?
Pods are transient by nature and get destroyed or restarted for various reasons (nodes being down, resource issues, etc.). Every time a pod comes up, it gets a new IP address. So you definitely cannot use the direct IP address of the pods to access them. The Kubernetes Service component solves this problem by providing stable or static IP addresses and a DNS hostname for your pods running in the cluster. Kubernetes Service also provides LoadBalancing among the pods. So, for example, you might be running three replicas of your application, then the Service component makes sure that request gets served by any pod replica. You can also use the service for external communication.
Kubernetes Service can be broadly classified into the following categories.
<terminal inline>ClusterIP<terminal inline> is the default service type. As the name suggests, the service declared as <terminal inline>ClusterIP<terminal inline> is not exposed for external communications but allows cluster-level communication among different services.
<terminal inline>NodePort<terminal inline> service type uses the IP address of your Kubernetes node. This service type allows External clients to communicate with the cluster. We can use it in production, but you will have to manually manage the IP address, which is cumbersome.
LoadBalancer type exposes the service externally using a cloud provider’s load balancer. You don’t have to manage the IP address of all the cluster nodes with this approach compared to <terminal inline>NodePort<terminal inline>. The downside is that you have a <terminal inline>LoadBalancer<terminal inline> per service, increasing your cloud resource usage.
Ingress is not a service type but a reverse proxy. It acts as a gateway for your cluster and different internal services. NGINX Ingress controller is typically used as a single <terminal inline>LoadBalancer<terminal inline> in most Kubernetes installations. It will keep your cloud bills in check as you have a single load-balancer instead of per service. In the case of <terminal inline>Ingress<terminal inline>, the flow will be like a request from the browser. Then the ingress controller redirects it to internal service, and then finally, the service redirects it to the pod where your application is running as a container.
What Are Namespaces?
Namespaces allows you to divide your Kubernetes cluster resources among multiple users. For example, all objects created by the Kubernetes system are part of the <terminal inline>kube-system<terminal inline> namespace. You can list the available namespaces by using the kubectl command <terminal inline>kubectl get namespace<terminal inline>.
What Are ConfigMaps?
ConfigMaps are Kubernetes objects used to provide configuration information to containers in the form of environment variables, command-line arguments, or through a file. ConfigMaps decouple environment-specific configuration from your container images. As a result, it makes your container images more portable. You can create ConfigMaps using the following kubectl command.
In this case, name is the configmap name and data can be directories, files, or literal values.
What Are Secrets?
<terminal inline>Secrets<terminal inline> are Kubernetes objects that make sensitive information available to your containers. Here sensitive information includes credentials, SSH keys, or TLS certificates. You can go to this link to know more about secrets and their types.
What are PersistentVolumes?
<terminal inline>PersistentVolumes<terminal inline> are Kubernetes cluster resources used to store data, and its’ lifecycle is not tied to a pod and exists independently of pods. Meaning the data will still be available if a pod gets deleted or restarted. PVs are typically backed by a network storage system such as NFS or EBS. An everyday use case for using <terminal inline>PersistentVolumes<terminal inline> is with stateful applications like Databases.
What Are PersistentVolumeClaims?
<terminal inline>PersistentVolumeClaims<terminal inline> is a request for storage by a user, and this request is met by binding the PVC to a persistent volume. PVC acts as an abstraction layer over the storage system. For pods to start using <terminal inline>PersistentVolumes<terminal inline> it needs to be claimed via PVC, and this claim is referenced in the pod spec. Pods consume node resources like CPU, memory; similarly, PVC consumes PV resources.
How Would You Explain Liveness and Readiness Probes?
<terminal inline>Probe<terminal inline> is a periodic health check done by <terminal inline>kubelet<terminal inline> on a container. <terminal inline>Liveness Probe<terminal inline> tells whether the container is running or not. If the <terminal inline>Liveness Probe<terminal inline> failed container is restarted as per the restart policy. <terminal inline>Readiness Probe<terminal inline> indicates whether the container is ready to accept the requests or not. If the <terminal inline>Readiness Probe<terminal inline> fails, the pod is removed from the service load balancers.
What Tools Are Commonly Used with Kubernetes?
It’s important to be familiar with the tools used in the Kubernetes landscape, for development and monitoring.
- minikube: a single node functional Kubernetes cluster typically used for local development work. You can install it on macOS, Windows, or Linux operating systems. Learn more about minikube here.
- kubectl: a command-line tool used for running the command on your Kubernetes cluster. You can use it to accomplish various tasks such as deploying your applications, creating service, knowing about the state of your cluster, deployment, service, pod, etc.
- kubeadm: helps to install and secure a Kubernetes cluster quickly. It takes care of installing the required components while conforming to the configuration best practices for your Kubernetes cluster.
- kubeconfig: a configuration file that contains information about your clusters, users, namespace, and authentication mechanism. By default, it is available in <terminal inline>$HOME/.kube<terminal inline> directory, and you change it to point to another file using the KUBECONFIG environment variable or <terminal inline>--kubeconfig<terminal inline> flag. <terminal inline>kubectl<terminal inline>uses the <terminal inline>kubeconfig<terminal inline> file to determine which cluster to use for running any commands.
- kubecontext: a group of access parameters containing information related to your cluster, user, and namespace and defined inside your <terminal inline>kubeconfig<terminal inline> file. <terminal inline>kuebctl<terminal inline> checks the current context defined in the <terminal inline>kubeconfig<terminal inline> file and runs the command against the active cluster. You can change the context using <terminal inline>kubectl<terminal inline> command <terminal inline>kubectl config use-context minikube<terminal inline>.
- Heapster: used for container cluster monitoring and performance analysis. The GitHub repository is retired and no longer in active development.
- Kubernetes dashboard: a web-based Kubernetes UI that can be used to manage cluster resources. It provides an overview of cluster resources, applications running, etc.
- cAdvisor: monitors resource usage and analyzes the performance of the container. It is integrated with the <terminal inline>kubelet<terminal inline> binary. It operates at the node level and collects statistics about CPU, memory, disk, and network for all containers running on that node.
- Prometheus: an open-source monitoring and alerting tool. It provides many features such as pull-based metrics, built-in Alertmanager, integration with Kubernetes, to name a few. Prometheus uses metrics provided by <terminal inline>cAdvisor<terminal inline>. Since it is a pull-based monitoring system, it can pull metrics from Kubernetes replicas when you scale up and scrape them when a node gets failed, or pod restarted on a different node.
- Grafana: an open-source dashboard tool. Since it is a dashboard, it requires some data sources to display data on the UI. For this purpose, it comes with the integration of metrics-based monitoring tools like Prometheus. It also supports a Kubernetes plugin to monitor Kubernetes cluster performance.
Now that we’ve given you the ultimate crash course into Kubernetes, you should be able to handle any question an interviewer throws at you. With confidence, you’ll be able to talk about Kubernetes architecture components, essentially concepts such as deployments, pods, services, and ingress, and development and monitoring tools.
But there’s always more to learn about Kubernetes. Here is a list of some additional resources that might come in handy for your interview preparation: