Kubernetes Interview Questions and Answers

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. To understand what Kubernetes is good for, let's look at some examples: You would like to run a certain application in a container on multiple different locations. Sure, if it's 2-3 servers/locations, you can do it by yourself but it can be challenging to scale it up to additional multiple location. Performing updates and changes across hundreds of containers Handle cases where the current load requires to scale up (or down)

Problem

And what are they used for?

Solution

Docker and Kubernetes are complementary. Docker provides an open standard for packaging and distributing containerized applications, while Kubernetes provides for the orchestration and management of distributed, containerized applications created with Docker. In other words, Kubernetes provides the infrastructure needed to deploy and run applications built with Docker.

Kubernetes is designed to be resilient to any individual node failure, master or worker. When a master fails the nodes of the cluster will keep operating, but there can be no changes including pod creation or service member changes until the master is available. When a worker fails, the master stops receiving messages from the worker. If the master does not receive status updates from the worker the node will be marked as NotReady . If a node is NotReady for 5 minutes, the master reschedules all pods that were running on the dead node to other available nodes.

Namespaces allow you split your cluster into virtual clusters where you can group your applications in a way that makes sense and is completely separated from the other groups (so you can for example create an app with the same name in two different namespaces). When using the default namespace alone, it becomes hard over time to get an overview of all the applications you manage in your cluster. Namespaces make it easier to organize the applications into groups that makes sense, like a namespace of all the monitoring applications and a namespace for all the security applications, etc. Namespaces can also be useful for managing Blue/Green environments where each namespace can include a different version of an app and also share resources that are in other namespaces (namespaces like logging, monitoring, etc.). Another use case for namespaces is one cluster, multiple teams. When multiple teams use the same cluster, they might end up stepping on each others toes. For example if they end up creating an app with the same name it means one of the teams overriden the app of the other team because there can't be too apps in Kubernetes with the same name (in the same namespace).

Pods are ephemeral. They are not designed to run forever, and when a Pod is terminated it cannot be brought back. In general, Pods do not disappear until they are deleted by a user or by a controller. Pods do not "heal" or repair themselves. For example, if a Pod is scheduled on a node which later fails, the Pod is deleted. Similarly, if a Pod is evicted from a node for any reason, the Pod does not replace itself.

DaemonSets are used in Kubernetes when you need to run one or more pods on all (or a subset of) the nodes in a cluster. The typical use case for a DaemonSet is logging and monitoring for the hosts. For example, a node needs a service (daemon) that collects health or log data and pushes them to a central system or database.

As the name suggests you can use daemon sets for running daemons (and other tools) that need to run on all nodes of a cluster. These can be things like cluster storage daemons (e.g. Quobyte, glusterd, ceph, etc.), log

collectors (e.g. fluentd or logstash), or monitoring daemons (e.g. Prometheus Node Exporter, collectd, New Relic
agent, etc.)

A Pending pod is one that cannot be scheduled onto a node. Doing a kubectl describe pod will usually tell you why. kubectl logs can also be helpful. There are several common reasons for pods stuck in Pending: The pod is requesting more resources than are available, a pod has set a request for an amount of CPU or memory that is not available anywhere on any node. eg. requesting a 8 CPU cores when all your nodes only have 4 CPU cores. Doing a kubectl describe node on each node will also show already requested resources. There are taint s that prevent a pod from scheduling on your nodes. The nodes have been marked unschedulable with kubectl cordon There are no Ready nodes. kubectl get nodes will display the status of all nodes.

An Ingress Controller is a pod that can act as an inbound traffic handler. It is a HTTP reverse proxy that is implemented as a somewhat customizable nginx. Among the features are HTTP path and service based routing and SSL termination.

The master node is the most vital component responsible for Kubernetes architecture It is the central controlling unit of Kubernetes and manages workload and communications across the clusters The master node has various components, each having its process. They are: ETCD Controller Manager Scheduler API Server

ETCD (Cluster store)

1. This component stores the configuration details and essential values
2. It communicates with all other components to receive the commands and work in order to perform an action
3. It also manages network rules and posts forwarding activity Controller Manager
4. It is responsible for most of the controllers and performs a task
5. It is a daemon which runs in a continuous loop and is responsible for collecting and sending information to API server
6. The key controllers handle nodes, endpoints, etc. Scheduler
7. It is one of the key components of the master node associated with the distribution of workload
8. The scheduler is responsible for workload utilization and allocating pod to a new node
9. The scheduler should have an idea of the total resources available as well as resources allocated to existing workloads on each node

Some examples of reasons you’d use a StatefulSet include: A Redis pod that has access to a volume, but you want it to maintain access to the same volume even if it is redeployed or restarted A Cassandra cluster and have each node maintain access to its data A webapp that needs to communicate with its replicas using known predefined network identifiers

When using Kubernetes, most of the time you don’t care how your pods are scheduled, but sometimes you care that pods are deployed in order, that they have a persistent storage volume, or that they have a unique, stable network identifier across restarts and reschedules. In those cases, StatefulSets can help you accomplish your

objective. It manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods. StatefulSets are valuable for applications that require one or more of the following. Stable, unique network identifiers. Stable, persistent storage. Ordered, graceful deployment and scaling. Ordered, automated rolling updates.

When pods contain multiple containers, communications, and data sharing between them is simplified. Since all containers in a pod share the same network namespace, they can locate each other and communicate via localhost. Pods can communicate with each other by using another pods IP address or by referencing a resource that resides in another pod. Pods can include containers that run when the pod is started, say to perform initiation required before the application containers run. Additionally, pods simplify scalability, enabling replica pods to be created and shut down automatically based on changes in demand.

Pods can be used in two main ways: Pods that run a single container. The simplest and most common Pod pattern is a single container per pod, where the single container represents an entire application. In this case, you can think of a Pod as a wrapper. Pods that run multiple containers that need to work together. Pods with multiple containers are primarily used to support colocated, co-managed programs that need to share resources. These colocated containers might form a single cohesive unit of service—one container serving files from a shared volume while another container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity. Each Pod is meant to run a single instance of a given application. If you want to run multiple instances, you should use one Pod for each instance of the application. This is generally referred to as replication. Replicated Pods are created and managed as a group by a controller, such as a Deployment.

Containers run in an isolated process (usually in it's own namespace). This means that by default the container will not be aware of other containers. Additionally, it will not be aware of the systems files, network interfaces,

and processes. While this can greatly help with portability of the software it does not solve several production issues such as microservices, container discovery, scalability, disaster recovery, or upgrades. Adding a container orchestrator can greatly reduce the complexity in production as these tools are designed to resolve the issues outlined above. For example, Kubernetes is built to allow containers to be linked together, deploy containers across an entire network, scale and load balance the network based on container resource consumption, and allow upgrades of individual containers with no downtime. If you are only running a single container or two containers together you are correct in that an orchestrator may be unnecessary and add unneeded complexity.

Docker is a container engine, it makes you build and run usually no more than one container at most, locally on your PC for development purposes. Docker Compose is a Docker utility to run multiple containers and let them share volumes and networking via the docker engine features, runs locally to emulate service composition and remotely on clusters. Docker Compose is mostly used as a helper when you want to start multiple Docker containers and don't want to start each one separately using docker run ... . Docker Swarm is for running and connecting containers on multiple hosts. It does things like scaling, starting a new container when one crashes, networking containers. Kubernetes is a container orchestration platform, it takes care of running containers and enhancing the engine features so that containers can be composed and scaled to serve complex applications (sort of PaaS, managed by you or cloud provider). Kubernetes' goal is very similar to that for Docker Swarm but it's developer by Google.

In the quality assurance (QA) environments, we can get away with running containers on a single host to develop and test applications. However, when we go to production, we do not have the same liberty, as we need to ensure that our applications: Are fault-tolerant Can scale, and do this on-demand Use resources optimally Can discover other applications automatically, and communicate with each other Are accessible from the external world Can update/rollback without any downtime. Container orchestrators are the tools which group hosts together to form a cluster, and help us fulfill the requirements mentioned above. Nowadays, there are many container orchestrators available, such as: Docker Swarm: Docker Swarm is a container orchestrator provided by Docker, Inc. It is part of Docker Engine. Kubernetes: Kubernetes was started by Google, but now, it is a part of the Cloud Native Computing Foundation project. Mesos Marathon: Marathon is one of the frameworks to run containers at scale on Apache Mesos. Amazon ECS: Amazon EC2 Container Service (ECS) is a hosted service provided by AWS to run Docker containers at scale on its infrastructrue. Hashicorp Nomad: Nomad is the container orchestrator provided by HashiCorp.

Kubernetes uses etcd to store all its data – its configuration data, its state, and its metadata. etcd lets any of the nodes in the Kubernetes cluster read and write data. Because Kubernetes is a distributed system that runs on one master and several worker nodes – that database needs to be distributed. So etcd is a distributed database. By default, the Etcd is exposed on the master nodes of a Kubernetes cluster on the port 2379.

If you apply a change to a Deployment with the --record flag then Kubernetes stores the previous Deployment in its history. The kubectl rollout history deployment command will show prior Deployments. The last Deployment can be restored with the kubectl rollout undo deployment command. In progress Deployments can also be paused and resumed. When a new version of a Deployment is applied, a new ReplicaSet object is created which is slowly scaled up while the old ReplicaSet is scaled down. You can look at each ReplicaSet that has been rolled out with kubectl get replicaset . Each ReplicaSet is named with the format -, so you can also do kubectl describe replicaset .

A Kubernetes cluster is a set of node machines for running containerized applications. If you’re running Kubernetes, you’re running a cluster. At a minimum, a cluster contains a worker node and a master node. A worker node is a virtual machine or a physical server that serves as a worker for running the applications. It contains from: Kubelet - an agent responsible for node communication with the master. Kube-proxy - load balancing traffic between app components Container runtime - the engine runs the containers (Podman, Docker, ...) It's recommended to have at least 3 nodes in Kubernetes production environment. The master node coordinates all the workflows in the cluster: Scheduling applications Managing desired state Rolling out new updates

Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in your cluster.

Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod's resources. Pods also contain shared networking and storage resources for their containers

Pods represent the processes running on a cluster. By limiting pods to a single process, Kubernetes can report on the health of each process running in the cluster. Pods have: a unique IP address (which allows them to communicate with each other)

persistent storage volumes (as required)

configuration information that determine how a container should run. Although most pods contain a single container, many will have a few containers that work closely together to execute a desired function.

Containers within a pod share networking space and can reach other on localhost . For instance, if you have two containers within a pod, a MySQL container running on port 3306 , and a PHP container running on port 80 , the PHP container could access the MySQL one through localhost:3306 .

The purpose of Kubernetes is to make it easier to organize and schedule your application across a fleet of machines. At a high level it is an operating system for your cluster. Basically, it allows you to not worry about what specific machine in your datacenter each application runs on. Additionally it provides generic primitives for health checking and replicating your application across these machines, as well as services for wiring your application into micro-services so that each layer in your application is decoupled from other layers so that you can scale/update/maintain them independently.

A container runtime is the part of your container environment in charge of the creation and basic features of your containers. The obvious one is Docker, but you can also find Containerd, CRI-O and other as runtime for your containers. An orchestrator, by contrast, will not exactly create your container (ie, an orchestrator is not the technology used to create them). An orchestrator will use your container runtime to manage them. In a way, it's a layer around your container runtime wich allow finer usages, such as scaling, multi host deployments, load balancing... The most famous orchestrators would be Kurbenetes and Docker Swarm.

Yes, a regular pod can use a persistent volume. However, sometimes you have multiple pods that logically form a "group" ad each individual in the group has an identity. For example, for a database cluster one is the master and two are followers and each of the followers communicates with the master letting it know what it has and has not synced. So the followers know that "db-x-0" is the master and the master knows that "db-x-2" is a follower and has all the data up to a certain point but still needs data beyond that. So there is a few things you can't easily get from a regular pod:

1. A predictable name: you want to start your pods telling them where to find each other so they can form a cluster, elect a leader, etc. but you need to know their names in advance to do that. Normal pod names are random so you can't know them in advance.
2. A stable address/DNS name: you want whatever names were available in step (1) to stay the same. If a normal pod restarts (you redeploy, the host where it was running dies, etc.) on another host it'll get a new name and a new IP address.
3. A persistent link between an individual in the group and their persistent volume: if the host where one of your database master was running dies it'll get moved to a new host but should connect to the same persistent volume as there's one and only 1 volume that contains the right data for that "individual". So, for example, if you redeploy your group of 3 database hosts you want the same individual (by DNS name and IP

address) to get the same persistent volume so the master is still the master and still has the same data, replica1 gets it's data, etc. StatefulSets solve these issues because they provide:

1. Stable, unique network identifiers.
2. Stable, persistent storage.
3. Ordered, graceful deployment and scaling.
4. Ordered, graceful deletion and termination.

You can set up an HA cluster: With stacked control plane nodes, where etcd nodes are colocated with control plane nodes. A stacked HA cluster is a topology where the distributed data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by kubeadm that run control plane components. This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster with external etcd nodes, and simpler to manage for replication. However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.

![]
(https://d33wubrfki0l68.cloudfront.net/d1411cded83856552f37911eb4522d9887ca4e83/b94b2/images/kube
adm/kubeadm-ha-topology-stacked-etcd.svg)

With external etcd nodes, where etcd runs on separate nodes from the control plane. An HA cluster with external etcd is a topology where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components. This topology decouples the control plane and etcd member. It therefore provides an HA setup where losing a control plane instance or an etcd member has less impact and does not affect the cluster redundancy as much as the stacked HA topology. However, this topology requires twice the number of hosts as the stacked HA topology. A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.

Taints are used to repel Pods from specific nodes. Instead of applying the label to a node, we apply a taint that tells a scheduler to repel Pods from this node if it does not match the taint. Only those Pods that have atoleration for the taint can be let into the node with that taint. Taints together with tolerations allow for more fine-grained control over Pods eviction and anti-affinity than custom node anti-affinity with logical operators. Currently, the following conditions and taints are supported: OutOfDisk — True if there is insufficient free space on the node for adding new Pods. The taint node.kubernetes.io/out-of-disk is added if the condition’s value is True . Ready — False if the node is not healthy and is not accepting Pods and is Unknown if the node controller has not heard from the node in the last node-monitor-grace-period (default is 40 seconds). A taint node.kubernetes.io/not-ready is added if this condition is False and the taint node.kubernetes.io/unreachable is added If the condition is Unknown MemoryPressure — True if the node memory is low; otherwise False . The taint node.kubernetes.io/memory-pressure is added if the value is True . PIDPressure — True if there are too many processes on the node; otherwise False . DiskPressure — True if the disk capacity is low; otherwise False . The taint node.kubernetes.io/disk- pressure is added if the condition is True NetworkUnavailable — True if the network for the node is not correctly configured, otherwise False . The taint node.kubernetes.io/network-unavailable is added if the condition is True .