If you are working in field of software engineering you would have definitely heard about kubernetes. This blog comes from my recent experience of deploying application on kubernetes in one of my project.
In this article series i am trying to put every “why’s” and “how” which I got while learning kubernetes. I didn’t find everything in one place so trying to put it down for other people with same hope. So if you are looking for getting started with kubernetes and want understanding of why it’s there, how it came into picture, and how it works you are at right place. :D
In this article series we will discuss the following things:
- History: Traditional Approach for deployment
- Virtual machines and Containers
- What is Kubernetes
- Kubernetes Architechture and working
Lets not start with what is kubernetes, but rather start with when did kubernetes comes in picture and why we even need it. ;)
1. Traditional Approach for deployment
So long long long back, not much long :p but ya initial years, there used to be servers on which we use have our application running. Server is nothing but a computer ( a specialized computer or software application that offers services, data, or resources to other software applications, following specific protocols and often running continuously). You can run only one application on a physical server because OS on this system didn’t have capability to run multiple app securely. Even if you run multiple app on a physical server there is instance when one app takes most of resource and other will underperform.
Problem with this approach : Most of hardware resources where un utilised and its difficult for organisation to maintain different physical server.
So we as engineer always tries to optimise things. As a good developer you should always be taking care of optimising resources. There come a concept of virtualisation. We create a new layer on top of host operating system known as hypervisor. Now you can create many virtual machine on top of it in which you can run different operating system and application on top of those OS. Each VM is a full machine running all components including its own operating system on top of virtualised hardware. With the help of virtual machines organizations can install multiple OS and create multiple environments on the same physical machine/server.
Virtual machines use hypervisors to communicate between the guest operating system(virtual machine) and the host operating system. It coordinates resource sharing, so the virtual machine runs in isolation alongside several others on the same hardware.
This virtualisation allows better utilisation of hardware resources in physical server, better scalability as app can be added or updated easily and it reduce hardware cost. VMs are good and it solves infrastructure problems by letting organizations get more out of servers.
problem with this approach: Though vm are really great for solving problems with server, vm are slow and take a lot of time to boot.
Containerised App
Containers were created to package and run applications in a predictable and repeatable way across multiple environments. Instead of recreating the environment, you package the application to run on all types of physical or virtual environments. Software developers create and deploy container images (images are nothing but files containing the necessary information to run the application). Container images are read-only and cannot be altered by the computer system. This is similar to giving a fish with fishpot to your friend instead of creating fishpot for them in your friend’s house.
Containers use a container engine or container runtime which acts as an intermediary agent between the containers and the host operating system, providing and managing system resources that the application needs. Docker is the most popular open-source container engine. Like vm that virtualise hardware containers virtualize the operating system so the application can run independently on any platform.
Virtual machine we saw before, their image files are larger in size (in GB) as they contain their own operating system.
Benefits with containers are:
- Container files are lightweight, (in MB).
- It only package the resources required to run a single application.
- Containers as they are lightweight, they take up less space and are easier to scale.
The best combination people generally use these days is, you can have one server, in one server you can create multiple vms and in each vms you can run one or more containers.
Containers are good way to bundle and run your app. In prod environment you need to manage the container that run the app and make sure that there is no application downtime. If the container go down, other need to be started. Wouldn’t it be easier if it is handled by a system? Thats how kubernetes came into picture. :)
Kubernetes
If you want to understand it very quickly and easily, it is like an conductor in orchestra. You deploy your application to cloud but thats not the end of your work. You need to manage your application and need to make sure it is up and running. You also need to make sure that it is accessible by outside, it should be able to handle load. All this can be easily managed by one and only our friend “Kubernetes”.
Kubernetes also known as K8s is just like an orchestrator for containers. It is known as container orchestrator engine. It takes care of scaling, handling failure of app, provides deployment pattern and much more. It can easily manage redeployment of your system.
Benefits of Kubernetes:
- Load Balancing: If traffic to a container is high, K8s can load balance and distribute the network traffic so that deployment is stable.
- Storage Orchestration: It allows to mount storage of your choice like local storage or public cloud provider storage. eg. If you are running a container and it goes down and new one comes up, if there is not a shared storage like from local or public cloud, you will lose your storage. Storage is from outside and not inside the container.
- Automated Rollout and rollbacks: You tell desired state of app to kubernetes and it can change actual state to desired state a controlled rate.
3.i. Automated Rollout: This allows you to update your application or service with new versions or changes automatically (gradually replacing the old version with the new one). Kubernetes can control how many new instances are created, monitor their health, and make sure the rollout is smooth and controlled.
3.ii. Rollbacks: In case there are issues or errors with the new version during a rollout, Kubernetes provides a mechanism for automated rollbacks. It can quickly revert to the previous working version of your application to minimize downtime and disruptions, ensuring the reliability of your services.
4. Self healing: K8s restart container that fails, replace and kill containers that don’t respond to your user defined health check.
5. Secret and config management: K8s let you store and manage sensitive information, password, auth token, ssh keys. You can deploy and update secrets and application configuration without rebuilding your container images and without exposing secrets in app configuration. (Let me tell you a story for this where this feature is really saviour in next blog.)
Docker is very simple platform and doesn’t support enterprise level support like load balancer, firewall, autoscale, autohealing, api gateway support, networking, security.
So, this was the history of deployment approaches and how kubernetes comes in picture and how helpful it is for managing deployments. Knowing history is helpful because you should always question the existence of things, that why it is there at first place :) . That’s it for this blog.
In next part we will see the architecture of kubernetes in detail that will help you understand the different components in kubernetes and how they work together, post that we will see example of how we can create a kubernetes cluster and how can we deploy our app on it. Hope you get understanding of kubernetes and why and how it came in picture. See you in next blog. Till then keep reading and keep upskilling. :)
