Why Containers
Suppose a developer developed an application. The developer gives it to the tester to check whether the application is working correctly in the local system. Now the tester will set up an environment from scratch to test the application. Once the application testing is done, it will be deployed on the production server. Again the production will set up an environment from scratch to hosting the application.
While hosting the application, the production team gets an error. The developer came to know that it is because of version conflicts. The developer also thinks that environment set up multiple times. When a developer wants to develop an application with different versions on the same OS. To avoid these things now the developer writes all dependencies in one file(i.e Docker image) to run the application. Now every team downloads this image and runs and tests it. Now you can focus more on application development.
To summarize what exactly container is read the below lines.
A container is a standard unit of software that packages up code and all it’s dependencies so the application runs quickly and reliably from one computing environment to another.
Why Kubernetes
To handle the few requests one container may sufficient so maintaining one container may not be a problem. Suppose Application gets more number of requests because of popularity. So to handle those requests now developer divides an application into microservices and makes into containers. Now maintaining the containers is difficult because of the below reasons.
We Can’t run many containers in one system so we need to buy the systems. Now we have to maintain these systems and containers. We need to find out the correct system based on the container resources. Have to check the health of containers and nodes. The container is ready but we need to check if the container is ready to serve the requests or not. How can we scale containers and nodes based on the requests? How can we distribute the traffic to the containers and nodes? How can we update the application without disturbing the running containers? How can we go back to the old version of the application if the new version is not working? How can we provide the persistence storage to the containers?
Are we looking for an automation process, container orchestration tool for the above problems and do you want to reduce the manual work. Here is the solution that is Kubernetes. Read the below lines to know what is Kubernetes
Kubernetes is an open-source Container Management tool which automates container deployment, container scaling and container load balancing.
Are you thinking about how the Kubernetes works? Here is the explanation of Kubernetes Architecture.
Kubernetes Cluster: Cluster consists of one or more nodes managed by Kubernetes. It may be physical or virtual on on-premise or cloud that hosts applications in the forms of containers. It mainly consists of Master Nodes and Worker Nodes.
MasterNode: MasterNode is responsible for managing the cluster, Storing the information regarding different nodes, Monitoring the Nodes, Planning which container goes where and moves the workload of the failed node to another worker node.
WorkerNode: WorkerNode is responsible for mainly running the application. For accessing the applications from the external world, we connect to nodes.
Now we explore the components of Master and Worker Nodes.
MasterNode Components:
Kube API Server: It is Primary management of Kubernetes. KubeAPI server is responsible for orchestrating all operations within the cluster. It exposes the Kubernetes API which is used by external users to perform management operations on the cluster as well as the various controllers to monitor the state of the cluster and make necessary changes required.
Controller Manager: This component on the master that runs controllers. They are Node Controller, Replication Controller, Endpoints Controller, Service Account and Token Controllers. At a high level, these controllers are responsible for the overall health of the entire cluster; it ensures that nodes are up and running all the time and the correct number of pods are running.
Etcd: Kubernetes uses Etcd for storing the cluster status and metadata, which includes the creation of any objects (pods, deployments, replication controllers, ingress etc…). It is a database that stores the information in the form key-value format.
Scheduler: Scheduler identifies the right node to place a container based on the container resource requirements, the worker node capacity or any other policies or constraints.
WorkerNode Components
Kubelet: Responsible for everything on the Worker Node. It communicates with the Master’s API server.
KubeProxy: Routes connections to the correct Pods. Also performs load balancing across Pods for a Service
Container Runtime: Downloads images and runs containers. For example, Docker is a Container Runtime.
Now we understand the Kubernetes architecture. Now We look into different installation methods of Kubernetes.
Play-with-k8s: Suppose you do not want to install Kubernetes in your system but you want to practice with Kubernetes. Then at that time, you can use Play-with-k8s.
MiniKube: MiniKube is ideal for someone who wants to install on their system but has very limited resources. MiniKube is a tool that makes it easy to run Kubernetes locally. Using MiniKube you do not have a MasterNode and WorkerNode architecture. You will get all Kubernetes components into one package so same system access Master and Worker Nodes.
Kubeadm: Do you want to configure MasterNode and WorkerNode real-time setup. You can use Kubeadm installation method.
Do you want to run Kubernetes on CloudPlatform so AWS provides Amazon Elastic Kubernetes Service(EKS), Google Cloud provides Google Kubernetes Engine(GKE), Microsoft provides Azure Kubernetes Service(AKS).
We got an overview of Kubernetes and now we will look into some of the Kubernetes concepts.
Kubernetes Concepts:
Pods: The Pod is the basic building block of Kubernetes. A Pod contains a group of one or more containers. Pods are ephemeral. They are intended to be restarted automatically when they die. Pods live on Worker Nodes.
Deployments: Defines the desired state for a set of replica pods, and works to maintain that state by creating, removing and modifying those pods.
ConfigMaps: Let’s take an example. Your front-end application container access the MongoDB container by using MongoDB URL. Assume your MongoDB application URL changed, so you have to change URL in a front end application. To avoid this problem you use ConfigMaps. ConfigMap is a key-value pair. Whenever URL changes just you have to do changes in ConfigMap. Refer the ConfigMap in the front-end application.
Secrets: Suppose do you want to pass sensitive data from one container to another container. By using Secrets you can achieve that. A secret is a Kubernetes object that stores sensitive data, such as password, keys, or tokens.
Probes: How can we check the container is healthy or not. The container is ready but how can we check that if the container is ready to serve the requests or not? By using probes we can solve the problem.
Rolling update and Rollbacks: Let’s assume you develop an application with a new feature, so you want to update an application without effect present application requests. By using Rolling update you can achieve that. Suddenly a new feature is not working as we expected. So do you want to go back to your old application? We can achieve this problem using Rollbacks.
Jobs and CronJobs: Suppose our container finish the process within 5 minutes so you don’t want to run application continuously and also want to execute every 10 minutes only. Then that time you can use Jobs and Cronjobs respectively.
Services: Do you want to expose an application to the outside world and communication between containers? If Pod dies then it loses the IP and creates another Pod with different IP in place of old Pod but how can application identifies both are same or not? By using Services we can achieve that.
Volumes: These provide storage to containers that are outside the container, and can, therefore, exist beyond the life of the container. Containers in a pod can share volumes, allowing them each to interact with the same files.
We know why, when, how to use Kubernetes. Now we also have to know that when should not use Kubernetes.
When should not use Kubernetes
1. An application makes use of a monolithic architecture
2. If you don’t have a team that’s willing to experiment and take risks then it’s probably not the choice for you
3. An application does not need in large scale
I hope now you have a better understanding of Kubernetes. So far we have discussed why Containers and why Kubernetes. We discussed Kubernetes concepts, architecture and when should not use Kubernetes. Do you have any doubts about this, feel free to reach out to us at Vitwit.
