Hello and welcome to this lecture on Khubani Despots.
Before we head into understanding part, we would like to assume that the following have been set up
already at this point, we assume that the application is already developed and built into darker images
and it is available on a darker repository like Docker Hub, so this can pull it down.
We also assume that the company, this cluster has already been set up and is working.
This could be a single node set up or a multi node setup.
Doesn't matter.
All the services need to be in a running state.
As we discussed before with Coburn, it is our ultimate aim is to deploy our application in the form
of containers on a set of machines that are configured as worker nodes in a cluster.
However, it is does not deploy containers directly on the worker notes.
The containers are encapsulated into a commonalties object known as pods.
A pod is a single instance of an application.
A pod is the smallest object that you can create in Cuba unless.
Here we see the simplest of simplest cases where you have a single node carbonate as cluster with a
single instance of your application running in a single dock or container encapsulated in a pod.
What if the number of users accessing your application increase and you need to scale your application,
you need to add additional instances of your Web application to share the load.
Now, where would you pin up additional instances?
Do we bring up new container instance within the same pod?
No, we create new pod altogether with a new instance of the same application.
As you can see, we now have two instances of our Web application running on two separate pods on the
same kobrin at a system or node.
What if the user base further increases and your current node has no sufficient capacity?
Well, then you can always deploy additional pods on a new node.
In the cluster, you will have a new node added to the cluster to expand the clusters physical capacity.
So what I'm trying to illustrate in this slide is that pods usually have a one to one relationship with
containers running your application to scale up.
You create new pods and to scale down.
You delete existing pod.
You do not add additional containers to an existing pod to scale your application.
Also, if you're wondering how we implement all of this and how we achieve load balancing between the
containers, etc., we will get into all of that in a later lecture.
For now, we are only trying to understand the basic concepts.
We just said that parts usually have a one to one relationship with the containers, but are we restricted
to having a single container in a single pod?
No, a single pod can have multiple containers, except for the fact that they're usually not multiple
containers of the same kind.
As we discussed in the previous slide.
If our intention was to scale our application, then we would need to create additional pods.
But sometimes you might have a scenario where you have a helper container that might be doing some kind
of supporting task for our Web application, such as processing a user, enter data, processing a file
uploaded by the user, etc. and you want these helper containers to live alongside your application
container.
In that case, you can have both of these 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 with each other directly
by referring to each other as localhost, since they share the same network space.
Plus they can easily share the same storage space as well.
If you still have doubts in this topic, I would understand if you did, because I did the first time
I learned these concepts, we could take another shot at understanding parts from a different angle.
Let's for a moment keep commentators out of our discussion and talk about simple docker containers,
let's assume we were developing a process or a script to deploy our application on a Docker host.
Then we would first simply deploy our application using a simple token python at command and the application
runs fine and our users are able to access it.
When the load increases, we deploy more instances of our application by running the docker run commands
many more times.
This works fine and we are all happy now sometime in the future.
Our application is further developed, undergoes architectural changes and grows and gets complex.
We now have a new helper container that helps our web application by processing or vetting data from
elsewhere.
These helper containers maintain a one to one relationship with our application container and thus needs
to communicate with the application containers directly and access data from those containers.
For this, we need to maintain a map of what app and help our containers are connected to each other,
we would need to establish network connectivity between these containers ourselves using links and custom
networks.
We would need to create shareable volumes and shared among the containers.
We would need to maintain a map of that as well.
And most importantly, we would need to monitor the state of the application container.
And when it dies, Manolete kill the helper container as well as it's no longer required.
When a new container is deployed, we would need to deploy the new helper container as well with part
cabinet, as does all of this for us.
Automatically we just need to define what containers a port consists of and the containers in a part
by default will have access to the same storage, the same network namespace and same fate as in.
They will be created together and destroyed together.
Even if our application didn't happen to be so complex and we could live with a single container Cuban,
it is still requires you to create pods.
But this is good in the long run as your application is now equipped for architectural changes and scale
in the future.
However, also note that multiple containers are a rare use case and we are going to stick to single
containers per pod in this course.
This is now look at how to deploy pods.
Earlier, we learned about the cube control run command, what does command really does is it deploys
a docker container by creating a pod.
It first creates a pod automatically and deploys an instance of the engine X docker image.
But where does it get the application image from or that you need to specify the image name using the
image parameter, the application image.
In this case, the Engine X image is downloaded from the repository Docker hub, as we discussed, is
a public repository where latest images of various applications are stored.
You could configure cabernets to pull the image from the public or a private repository within the organization.
Now that we have a port created, how do we see the list of ports available?
The control jet parts command helps us see the list of pods in our cluster, in this case, we see the
pod is in a container creating state and soon changes to a running state when it is actually running.
Also, remember that we haven't really talked about the concepts on how a user can access the Ingenix
Web server, and so in the current state, we haven't made the Web server accessible to external users.
You can access it internally from the node.
But for now, we will just the how to deploy a pod.
And later, in a later lecture, once we learn about networking and services, we will get to know how
to make the service accessible to end users.
Well, that's it for this lecture.
Head over to a demo and I will see you in the next one.