Introduction To Kubernetes

With containerization gaining popularity over time and revolutionizing the process of building, shipping, and maintaining applications, it became the need of the hour to effectively manage these containers. Many tools were introduced to manage the lifecycle of these containers in large-scale systems. These tools were called container orchestration tools.

An orchestration tool takes care of provisioning and deployment, allocation of resources, load balancing, service discovery, high availability, and other important aspects of any system. By using container orchestration tools like Docker Swarm, Kubernetes, etc. we can easily describe the configurations such as volume mounts, env variables, image source, CPU, Memory configuration, etc., and use them as blueprints for creating containers.  

In this article, we will take a look at the basic components of Kubernetes.

Basic Components of Kubernetes

Cluster

As the name suggests, a cluster is a set that consists of master and worker Nodes. It has at least one master node and can have one or many worker nodes. A master node consists of a control plane to manage the worker nodes. The control plane has several components which make the decisions such as scheduling, life cycle management, etc.

The components of the control plane are Kube-APIserver, etcd, kube schedular, kube-controller-manager, cloud-controller-manager.

Some components of the control plane run on each node. These components are kubelet, kube-proxy, container-runtime.

We will dive deeper into these components in PART-2 of this blog series.

Node

The containers placed in pods are run on Kubernetes worker nodes. Each node has the necessary configuration and runtime environment to support the containers running in the pod. Nodes are managed by the control plane.

Pod

A pod is the smallest deployable unit in Kubernetes. Pods run within a node. A node can have one or many pods running inside. Each pod can have one or more containers running within. Containers running within the same pod can interact using a localhost network but the same is not true for inter-pod communication since they run in isolated environments and have no idea about each other.

Deployment

These are improved versions of replication controllers. They manage replica set deployment. A pod uses the deployment as a blueprint. Deployment describes all the basic details for a pod to be created such as name, memory, CPU, volume mounts, env variables, number of replicas to run at a time, image from which container will be created, etc.

Service

Kubernetes pods are dynamic. They get created and destroyed frequently. Every time a new pod is created, it has a new name and address in the Kubernetes node. So, it becomes impossible to communicate between pods using the physical address or IP of pods. To solve this issue, Kubernetes services are created. A service defines the policies to access a logical set of pods.

Secret

Secrets are used to stored sensitive information securely. This can be anything such as DB credentials or service account details. It is always advisable to store this information in secrets instead of hardcoding it in K8s configuration files.

Persistent Volume

Persistent volumes can be used to mount any external storage drive to a particular location on the container. This is usually done to keep the containers stateful. There are many types of persistent volume supported by Kubernetes which can be found in an official document in detail.

Persistent Volume Claim

It can be described as a request from the user for some storage. We can configure the properties of Persistent Volume needed using the claims. Similar to pod (consuming node resources), claims consume Persistent Volumes. Volumes can be provisioned dynamically or statically depending on our configuration of claims.

We have barely scratched the surface with the above article. We will see many more details and practical exercises in the upcoming articles on this topic.