🔍 What is K8s?
Kubernetes, also known as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications.
Open-source container orchestration tool
Developed by Google
Helps you manage containerized applications in different deployment environments (like physical machines, virtual machines, or cloud env.)
🔍 The need for a container orchestration tool?
Trends from monolith to microservices
Increased usage of containers
Demand for a proper way of managing thousands of containers
Containers offer the perfect host for small independent applications. After the increased usage of container technologies now managing those multiple containers across multiple environments using scripts and self-made tools can be complex which leads to the need for some container orchestration tool and then Kubernetes comes into the picture.
🔍 What features do K8s offer?
High Availability or no downtime: application is always accessible by the user.
Scalability or high Performance (scale out automatically): application loads fast and users have a very high response rate from the application
Disaster recovery- if infrastructure has some problems like data is lost or the server explodes, a containerized application can be brought back to the latest state after recovery.
🔍 K8s Components
Let's learn about some of the components of K8s:
Clusters
Master node & Worker node
Pods
Services
Ingress
Config map
Secrets
Volumes
Deployment & Replica set
Before jumping over these components directly, let's take a case of some javascript application with a simple database and now let's look at how each component of K8s helps you to deploy our application and what is the role of each of the components.
🎯 Cluster
K8s lets you deploy containers on a set of nodes called a cluster.
A cluster is a set of master components that control the system as a whole & a set of worker nodes that run containers.
🎯 Pod
The smallest unit of the K8s cluster
It's an abstraction layer over a container and can contain a group of containers
It creates a running environment or layer on top of the container
The main reason for this abstraction layer is K8s wants to abstract away the container runtime. So we don't have to directly work with container technology.
Each Pod is meant to run one application container inside of it. You can also run multiple containers inside one Pod but that's usually the case when there is one main application container and many helpers containers or services that need to be run inside that container.
Each Pod contains a unique IP address using which they can communicate with each other. This is an internal IP address.
- One important thing about Pod is that they can die very easily and if that happens new Pod is created in its place and a new IP address is assigned to them which may be inconvenient if we are communicating with our database using that IP address because we now have to adjust it every time new Pod restarts. To tackle this problem another component of K8s comes into the picture called Services.
🎯 Services
It's a static IP address or permanent IP address that can be attached to each Pod.
A service groups a set of pods together & provides a stable endpoint for them.
The lifecycle of pods and services is not connected so even if the pod dies, the service and its IP address will stay the same.
🎯 Ingress
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
The role of Ingress is to maintain the DNS routing configurations.
This enables you to access your application through a browser. For this, you need to create an external service. External service is a service that opens communication through external sources.
But we don't want our database to be accessible through public request so for that we will create an internal service.
🎯 Config Maps
Pods communicate with each other using services. For example, our application will have a database endpoint using which we can communicate with our databases but where should we configure this endpoint??
Config map provides external configuration to your application or some other services that you use and in K8s you just connect it to the Pod so that pod gets the data that configMap contains. So in future, if we change the name of a service or endpoint for that service we just need to update the configMap.
Configuration may also contain the credentials of the database or any other private information which cannot be stored in a plain text format so for that we will use Secret.
🎯 Secret
Just like config maps but used to store secret data.
It's not stored in a plain text format but in a base64 encoded format.
This may contain things like credentials, passwords, certificates etc. which you don't want other people to have access to.
We will connect this secret to the pods so that pods can have access to that information.
🎯 Volumes
We have a database which our application uses and it regenerates some data but if the database pod gets restarted, the data would be lost but we want our data to be persistent for the long term. So to avoid this scenario here comes the role of Volumes.
It attaches physical storage to a hard drive to your pod and that storage could be either on a local machine meaning the same server node where the pod is running or it could be on the remote storage meaning outside of the K8s cluster maybe cloud storage.
This is used to overcome the problem of data loss whenever pods get restarted.
K8s cluster explicitly doesn't manage any data persistence so taking a backup of the data is the responsibility of the user.
🎯 Deployments & Replica Set
Till now our application is running perfectly fine and the user can access it through a browser but what happens if my application pods die or crash or we have to restart the pod because we have built a new container image? This will cause a downtime where a user cannot reach my application. So that is exactly where the advantage of distributed systems and containers comes into the picture.
- Instead of relying on 1 application pod or 1 database pod, we will replicate everything on multiple servers. So we would have another node where a replica or clone of our application would run which will also be connected to the same service.
Service also acts as a load balancer. It will catch the request and forward it to whichever pod is least busy.
To create a replica we'll define a blueprint for My-App pod and specify how many replicas of that pod you would like to run. That blueprint is called Deployment.
In K8s we will not directly work with pods instead we will create deployments where we can specify how many replicas we actually want. You can also scale up or scale down the number of replicas you want.
In the case of the database pod, we will create its replica also but here is a catch:- We can't replicate a database using a deployment because the database has a state. If we clone or replicate the database they would all need to access the same shared data storage and there you would need some kind of mechanism that manages which pods are currently writing to that storage and which pod is currently reading from that storage to avoid data inconsistencies. This is managed by Stateful Set.
Deployments for stateLESS Apps.
Stateful Set for stateFUL Apps or databases.
🔍 Wrap Up!!
That's all for this article. Thank you for your time!! Let's connect to learn and grow together.
Latest comments (0)