Hey everybody.
Welcome back.
In the last video, we deployed a containerized grade submission portal application.
And in this video we're going to do the same for the grade submission API.
So ultimately we're going to have a grade submission API pod that runs a containerized grade submission
API app.
The app was programmed to serve requests on port 3000.
So we're going to set up a container port 3000, which will which the pod will automatically expose
for internal traffic within the Kubernetes cluster and within the pod.
We're also going to specify the resource requirements for this containerized app to run properly.
Uh, the minimum amount of resources that this container app that this containerized app needs in order
to function.
Okay.
So without too much preamble, let's just dive right into it, because we did something very similar
to that in the previous video within the section one folder, create a new file called Great Submission
API pod dot YAML.
Once again we go ahead and say pod and using the Kubernetes extension, we can auto generate the skeleton
for a pod.
I'm going to zoom in for you okay.
Remember that when we're creating a pod, first we define the pod metadata.
So starting with the name, there's usually a 1 to 1 relationship between the pod and the containerized
app that it's running.
So we'll call the name simply Great Submission API.
All right.
And remember we use labels to identify and categorize our pod into distinct groups which helps for querying
later on.
So it's important that first we specify the name of the cloud native app that this microservice, if
you will, belongs to.
Remember, we stick with the labeling convention app dot kubernetes.io followed by the application name
that this great submission API belongs to.
So that would be the great submission app.
All right.
And now we get more granular.
So I'm going to say once again app.kubernetes.io using this labeling convention slash components.
So we get even more granular now because now we specify uh the component within the application architecture
that this API belongs to.
So remember the um, the great submission portal was the front end.
It provides the user interface that the client will interact with.
The great Submission API will be managing whatever data the client submits in the back end.
So accordingly this will be the back end.
All right.
And finally, the last label I'm going to use to identify the specific instance, the specific microservice.
So that would be the great submission API.
Okay.
So this is one way that we can use to define the metadata for a pod.
Okay.
Now we specify the runtime requirements of our pod, the containerized app that it's going to be running.
The container will be the great submission API.
Okay.
And the image from which this container will be created I recently uploaded to my Docker Hub.
Let me just pull it up for you right now.
Uh, for some reason it's not pulling up.
Well, there it is.
So if you go to Docker Hub, right.
My name is slim 087.
And you can find this repo right over here, are slim 087 Kubernetes Course Grade Submission API.
If you're too lazy to go to Docker Hub, you can just write this down.
And what that's going to do is pull the image that captures the grade submission API code and all the
dependencies that that code needs in order to run after the image has been pulled.
The container brings that image to life by by actually running the application by creating a running
process.
And now let's assume that we're deploying this pod within a Kubernetes cluster with many, many nodes,
not just the one node.
Our laptop.
We'll assume we're doing things on AWS.
The resources that we request for the containerized app will ultimately determine which node this pod
gets scheduled on, the one that can most comfortably, in this case, provision 128 maybe, maybe bytes
of memory.
And we'll just say the same number for the CPU 128 Millicores of CPU.
Okay.
And now remember that because memory is incompressible, we want to specify a limit so that we don't
exceed the amount of memory that was initially allocated to it.
Okay.
So um, this is the minimum guaranteed amount of memory that our container will be given upon it being
scheduled on the node.
And this limits the amount of memory that can be consumed by this containerized app to be the exact
amount that it was initially allocated.
Okay, and remember that because CPU is a compressible resource, we don't want to place a limit on
that.
If there is extra CPU, we want this containerized app to be able to use it if it needs to.
Okay, now these numbers should be suitable for this really simple, great submission API app that I
coded up myself and packaged up into an image.
But ultimately the numbers that you choose will depend on load testing that you and your team end up
doing on this app and monitoring its performance metrics.
Now this app, this great submission API, it was when I coded it, it was programmed to serve requests
on port 3000.
So we want to create a matching container port 3000.
All right.
So container port 3000.
If you're curious to see the application itself just give me one second.
So this here is the app that was packaged up into an image.
And it was configured to listen on port 3000.
So we create a container port 3000 where it can serve these requests.
And the pod will automatically, uh, expose this container port for internal traffic within the Kubernetes
cluster, which we're ultimately going to port forward to a static port on our machine later on.
All right.
And that's pretty much it.
But I don't want to beat around the bush.
Let's go ahead and deploy.
What's it called?
The health checker as well.
So similar to before.
We have the pattern where the pod, which is named after the main containerized microservice that it's
running.
And we're also going to have another container running within this pod, which is a health checker that
basically cannot exist without this microservice being there with it.
All right.
So we're going to deploy a great submission API health checker that continuously monitors the health
endpoint of the great submission API.
And we need to deploy it in the same pod because containers that are in the same pod, they share the
same network namespace.
So it can easily connect to the Great Submission API using localhost.
That's how the application was programmed.
So we're going to make sure that it's in the same pod.
See it's making requests to localhost 3000 at the great submission APIs health endpoint.
So we want to make sure it's in the same pod.
And another reason why it's in the same pod is because this health checker cannot exist without the
great submission API.
So when we create the pod, when we delete the pod, we want to make sure that the health checker is
deleted and created with the Great Submission API.
Okay.
Um, it is a sidecar app.
It simply enhances the functionality of the main app that is running within this pod.
So we can go ahead and just copy this.
So containers allows us to specify an array of containers that can run within the pod.
The next one I'm going to run is the grade submission API health checker.
All right.
And this code, which you don't need, I've already built a Docker image out of it and uploaded it to
my local to my Docker Hub registry.
Okay so great submission Kubernetes course.
Great submission API health checker.
Go to my Docker Hub repo by going to Docker Hub.
Click writing my username and then finding this specific repo.
You can copy the following great submission API health checker.
So from this image we're going to create a great submission API health checker container.
This is not a web application.
All it's going to be doing is making requests to the Great Submission API itself, which is a web app,
and we can go ahead and finalize this right now.
I'll go ahead and say kubectl apply dash f.
Great submission portal pod.
Uh, no.
Great submission.
API pod.
We're going to deploy a pod that's running to containers.
I don't have Docker running at the moment, so let me just snap my fingers and it will in a sec.
Okay cool.
Let's try this again.
It's going to take a while because I just started up my Docker engine.
Beautiful.
Let's say kubectl we're going to get all the pods in the default namespace.
I'll talk about namespaces later, but let's get all the pods that we've deployed so far.
Um, the great submission portal.
Weird.
Let me try it again.
Okay, so there was an error in the great submission API pulling one of the images.
Um, our slim 087 kubectl describe will describe the pod grid submission API.
See what's happening.
Failed to pull image.
Kubernetes course grid submission API.
Latest not found.
Okay, let me go to my repositories.
See, I'm glad I got this bug because I was able to debug in front of you.
Because sometimes people get errors in Kubernetes and they're too scared to troubleshoot because they
think it's something really, really serious.
But if you just describe the pod, you'll find out that it's not that serious.
So there was a problem pulling this image if I go to tags.
Ah okay.
So we need to pull our slim 087 Kubernetes core is great submission API stateless.
That is the tag that we should be using.
If you don't specify an image tag, it's going to default to pulling latest.
A latest tag doesn't exist in this repo.
So we're going to say stateless okay.
Let me try this again I'm going to delete the pod great submission API.
Give it some time.
Normally it doesn't take this long.
That is what it is.
Okay.
You can delete now.
There you go.
All right.
Now we'll say kubectl apply dash f grade submission API pod.
All right.
I'm going to give it a second.
Should be good now.
Kubectl get pods.
All right.
So we've got two pods.
Both of them have two containers each that are running the grade submission API has the great submission
API containerized service running and its corresponding health checker that is constantly making requests
to its port 3000.
As this diagram depicts.
All right.
Now, what I'll do is I'll clear the output.
Create another terminal.
This terminal, what it's going to do is, um, stream the logs in real time for the pod grade submission
API.
Within the grade submission API health checker.
Okay, so we're streaming the logs for this containerized sidecar application.
And as you can see, the great submission API sidecar is continuously making localhost requests to our
great submission API at its health endpoint, essentially monitoring our great submission API app.
And every time it's getting a status of healthy.
So because the sidecar is telling me that the great submission API microservice is healthy, um, I'm
not going to bother port forwarding the pod port 3000 to a static port on my local machine, because
I don't need to troubleshoot the great submission API.
Uh, the sidecar is already monitoring it and it's telling me that everything is healthy.
So the last thing we want to do is right now we have two pods, one with a great submission portal microservice,
one with a great submission API microservice.
And when you have two separate pods, they're automatically separated at the network level because of
the network namespace.
The network namespace is a logical construct in Kubernetes that essentially isolates Kubernetes resources
at the network level.
And some way, somehow we want the great submission portal when it receives submitted data from the
client to forward that data to the Great Submission API, which is going to manage the submitted great
data in the back end.
Okay.
It's going to manage its storage somehow.
We need to get these two containers to talk to each other, and that's going to be the focus of the
next section.
I'll see you there.