Sec : 3 : Abs:Begginers : Kubernetes Concepts :

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

16. PODS

Before we are heading to understanding PODs , we would like to assume that the following has been setup already 

• At this point we assume that the application is already developed and build into Docker images 
• And it is available in a Docker repository like a Docker Hub so Kubernetes can pull it down. 
• We also assume that the Kubernetes cluster is already been setup and is working. 

This could be a single node setup or a multi-node setup doesn't matter . All the services need to be in a running state . As we discussed before with Kubernetes our ultimate aim is to deploy our application . In the form of containers in a set of machines that are configured as worker nodes in a cluster . However Kubernetes does not deploy containers directly on the  worker nodes. The containers are encapsulated into a kubernetes object known as pods . A Pod is a single instance of an application .

A Pod is the smallest object that you can create in Kubernetes. 

Here is the simplest of simplest  cases where you have a single node Kubernetes cluster with a single instance of your application running in a single Docker container encapsulated in a POD. What if the number of users accessing your application increase and you need to scale your application . You need a add additional instances to your web application to share the load . Now where would you spin up your applications . Do we bring up additional instances within the Pod - NOPE . We create new Pod altogether within the new instance of the same application . As you can see we have new instances of your web-application . You will have a new node added to the cluster to extend the cluster's Physical capacity . 

Also if you are wondering how we implement all of these to achieve load balancing between the containers etc .We will get into that in a later lecture . Now we are only trying to understand the basic concepts .

We just said that usually Pod's have one to one relationship with the containers .But are we restricted to having a single container in a single POD  ? Nope . A single POD can have multiple containers except for the fact that they are usually not multiple containers

If you are wondering how we implement all of these  how we can achieve load balancing between the containers etc we will get to that in a later lecture . Now we are only trying to understand the basic concepts. 

We just said PODs usually have a one to one relationship with the containers . But are we restricted to having a single container in a single pod ? NOPE.

A single POD can have multiple containers except that they are not multiple containers of the same kind . Sometimes you may have scenarios where you will have a helper container that might be doing some kind of supporting task for our web application such as processing a user and their data, such as processing a file uploaded by a user etc . And you need this helper container to live alongside your application container . In those cases you can have those containers part of the same POD. So that when a new application container is created the helper is also created and when it dies the helper also dies since they are part of the same POD.

The two containers can also communicate directly by referring directly to each other as localhost since they share the same network space plus they can share the same storage space as well . 

Understanding POD from a different angle.

Lets keep Kubernetes out of our discuss and simply talk about Docker Containers 

Lets assume we are developing a process or a script to deploy our application on a Docker host 

 

Then we will simply deploy our application using 

docker run python-app    // command

And the application runs fine. And our users are able to access it. When load increases we deploy more instances of our application by running the docker run commands many more time. This works fine and we are happy . But sometimes in future our application is further developed 

Lets assume we are only dealing with Docker and no Kubernetes. for the below instance.

to know which helper containers are connected to which app we need to maintain a map.

• We need to establish network connectivity between these containers ourselves using links and custom networks 
• We need to create sharable volumes , shared among the containers we need to maintain a map of that as well.
• And most importantly we need to monitor the state of application containers and when it dies manually kill the containers as well as it is no longer required.
• When a new container is deployed we need to deploy the new helper container as well.
  
  With Pods ,Kubernetes does all of the above for us automatically 

We just need to define what containers a pod consists of  and the containers in the same pod will have access to the same storage , same network namespace , and same fit as they will be created together and destroyed together. 

Even if your application is not so complicate and can exist in a single container , kubernetes requires you to create pods.

How to deploy Pods ?

Earlier we learned the kubectl run command 

What this command really does is it deploys a docker container by creating a pod. The below create an nginx application by downloading it from the docker hub and created a pod.

You can configure the Kubernetes to pull the image from the public docker hub or from the private hub within the organization. 

Kubectl get pods  // command lets you see the number of pods in the cluster.