Introduction to Kubernetes
In this blog post, I will explain some of the features of Kubernetes and the need for a container orchestration tool.
With the ever-growing userbase of different applications, organisations are shifting from monolithic backends to Microservices architecture. Due to the shift to a Microservices architecture, development teams face challenges running, managing and updating various applications deployed inside containers. Such situations are where Kubernetes shines. It is an open-source container orchestration tool developed by Google, and anyone interested in DevOps or developing backend APIs must learn about it.
Why is Kubernetes very widely used?
High availability
Kubernetes can achieve high availability by replicating its components such that there is no single point of failure. There is a high probability for a single master cluster to fail, whereas with a multi-master cluster if one master node fails, the other nodes keep the cluster up and running.
Scalability
Kubernetes provides features like replication controllers, schedulers, and load-balancing techniques out of the box. It also has networking that allows the spawning of multiple new pods and nodes in a cluster, allowing the application to scale up when there are usage spikes.
Disaster recovery
There may be scenarios where having a backup of the application is mandatory. Applications providing banking services or other applications necessary for critical infrastructure to function smoothly must be highly available, and in case of a network failure or a bug introduced in the latest deployment or a natural disaster, critical services must be restored as quickly as possible. Therefore it is essential to back up the etcd storage and persistent volumes (in the case of stateful containers).
Some of the frequently used Kubernetes Components
Nodes and Pods
A pod is an abstraction over a container and is the smallest unit of Kubernetes. On creating a deployment on Kubernetes, it spawns pods with containers inside them. Each pod is associated with a node and remains there until termination or deletion. In case of anode failure, identical pods get generated on other available nodes in a cluster.
A Kubernetes node is a physical or virtual machine on which the pods run. Nodes are managed by the control plane, and each node can contain multiple pods.
Every node runs at least:
Kubelet -> is a process responsible for communication between the Kubernetes control plane and the node.
A container runtime environment, like Docker. It is responsible for pulling images from the registry, unpacking the container and running the application.
Kubernetes Service and Ingress
Services in Kubernetes are an abstraction to help expose groups of Pods over a network. A service object defines a logical set of endpoints along with a policy about how to make those pods accessible.
Ingress acts as an entry point for the cluster and can be used to control how web traffic reaches the workload. Ingress is not a service type.
ConfigMap and Secret
ConfigMap contains the external configuration of your application. Parts of the external configuration can be database usernames and passwords, which must be stored in another Kubernetes component called secrets. Secrets are similar to ConfigMaps but are specifically intended to hold confidential data.
Kubernetes Volumes
Kubernetes volumes come in handy when data is to be stored persistently. Kubernetes supports many kinds of volumes, and a pod can use any number of volume types simultaneously. Simply put, a volume is a directory with some data available to the containers in a pod.