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 walk through the most common questions that interviewers are likely to ask to test your Kubernetes knowledge.
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.
Kube-apiserver
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 Kube-apiserver horizontally on multiple nodes.
Etcd
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. Etcd is a highly available distributed key-value store, and acts as a storage for persisting this information. Any interaction to Etcd is via the Kube-apiserver for checking the state of the cluster or getting any metadata.
Kube-control-manager
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
Kube-scheduler
This component manages the scheduling of pods on the worker nodes. A Kube-scheduler 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.
Cloud-control-manager
As the name suggests, the Cloud-control-manager 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 Cloud-control-manager.
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:
Kubelet
Kubelet is an agent that runs on every worker node of the Kubernetes cluster. Its primary job is to manage containers in a pod and make sure that they are running as per the PodSpecs(YAML or JSON object). Kubelet agent directly communicates with the control plane through Kube-apiserver and executes an action on the node on its behalf.
Kube-proxy
Kube-proxy as the name suggests acts as a network proxy that is available on all the nodes of your cluster. Kube-proxy facilitates the communication between containers running on different nodes of the cluster from both inside and outside of the cluster.
Container runtime
Container runtime is 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 of the Kubernetes internals and the components that build up its architecture. But, there are many other important topics or concepts that can come up 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 ReplicaSet 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?
DaemonSets 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 ReplicaSets. Think of Deployment like a pod manager that can manage and create pods separately. You describe the desired state through ReplicaSets in the YAML or JSON Deployment object, and Deployment Controller changes the actual state to the desired state in a controlled manner. Deployments 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 Deployments; the only difference being that pods are created with unique names and ordering. StatefulSets are helpful in workloads that require storage volumes to persist data, i.e., databases such as mysql or mongo database. StatefulSets 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:
Clusterip
Clusterip is the default service type. As the name suggests, the service declared as Clusterip is not exposed for external communications but allows cluster-level communication among different services.
Nodeport
Nodeport 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
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 Nodeport. The downside is that you have a Loadbalancer per service, increasing your cloud resource usage.
Ingress
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 Loadbalancer 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 Ingress, 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 kube-system namespace. You can list the available namespaces by using the kubectl command kubectl get namespace.
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?
Secrets 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?
PersistentVolumes 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 PersistentVolumes is with stateful applications like Databases.
What are PersistentVolumeClaims?
PersistentVolumeClaims 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 PersistentVolumes 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?
Probe is a periodic health check done by Kubelet on a container. Liveness Probe tells whether the container is running or not. If the Liveness Probe failed container is restarted as per the restart policy. Readiness Probe indicates whether the container is ready to accept the requests or not. If the Readiness Probe 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
$HOME/.kubedirectory, and you change it to point to another file using the KUBECONFIG environment variable or--kubeconfigflag.kubectluses thekubeconfigfile 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
kubeconfigfile.kuebctlchecks the current context defined in thekubeconfigfile and runs the command against the active cluster. You can change the context usingkubectlcommandkubectl config use-context minikube. - 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
Kubeletbinary. 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
cAdvisor. 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.
Conclusion
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:
- Kubernetes Official Documentation
- The Illustrated Children’s Guide to Kubernetes
- Kubernetes Tutorials & Learning Resources
If you're also looking for an internal tooling platform that makes it easy to build custom workflows and UIs, then check out Airplane. Airplane is the developer platform for building custom internal tools. With Airplane, you can transform scripts, queries, APIs, and more into custom Tasks and Views.
To try it out, sign up for a free account or book a demo.
