[No Audio]
When you specify a Pod, you can optionally specify
how much CPU and memory or RAM each container needs.
When containers have resource requests
specified, the scheduler can make better decisions
about which nodes to place Pods on.
And when containers have their limits specified, containers
can make sure that the nodes don't crash.
Let's start out with getting a list of Pods. Let's open
the file resource-pod.yaml.
And there we go, the file seems larger than previous Pod YAMLs
that we have used. But don't worry, instead
of 1, we have 2 containers this time. One is
MySQL database container, whereas the other is
frontend WordPress container. The Pods name is front end.
First of all, let's go through the
obvious things like name of the containers, images
being used, environment variable setup, and
metadata of the Pod. Once all of those are out of
the way, we have resources field, in both of the
containers. This field is used to provide limits
of resource per container and request per
container, resources, our memory and CPU. As you
can see, we have provided pretty little amount of
resources to both of the containers were resource
limit is 128 megabytes and request limit is just
64 megabytes. Let's see what happens when we try
to create such a Pod, let's save and exit this file.
As usual, run kubectl create -f command
followed by the file name, and the Pod is created.
Let's list the Pods out. Hmm, it seems like the
Pod is still in the container creation state.
Let's give it a bit of time. Well, it seems like
the containers are still being created.
Or in other words, they have not been created yet.
Why is that? Let's take a look at the description a bit.
Alright, so the Pod is not ready because the
containers are still being created. As you can see
our Pod is following resource limitations quite
strictly. Let's list the Pods again. Hmm, only 1
out of 2 containers is ready and the Pod is in
CrashLoopBackOff status. Let's see what's the
problem here. When we run kubectl describe
command again, we can clearly see that the state
of database container is terminated. And the
reason for that is OOMKilled, which stands for
Out Of Memory Killed. Troubleshooting this isn't much
difficult. It clearly suggests that the resource
allocation limits that we have provided are just
not sufficient enough for this container to run.
Whereas on the other hand, the WordPress container
is running properly. Even when we look at the
events, all of the events regarding WordPress
containers seems to have gone well. But in case of
MySQL database container, the image was pulled
successfully, but the container could not start
because the resources were just not enough and if
you notice, both of these containers are scheduled
on the same node, because they are in the same Pod.
So when we are running more than one containers in a Pod,
they will be scheduled on the same node.
But let's not distract from our main objective,
we need to figure out a way to make sure that both of
these containers are running smoothly in this Pod.
For now, let's delete our frontend pod using
kubectl delete pods command followed by the name of the Pod.
There can be one or more pods that we
want to delete, but in this case, we just want to
delete frontend and it seems to be deleted.
Let's get back to the YAML file of our frontend pod and
increase the resource limits for our containers.
Instead of 128 MB we are changing it to 1 gigabyte.
And while we're at it, let's do the same
with WordPress container as well.
Let's save the file and exit nano and let's try to create the Pod again.
And when we list the Pod, Viola! it didn't
even take 11 seconds and our Pod along with both
of its containers is in Running state.
When we describe it using kubectl describe, we can
clearly see that the resource limits have changed.
All of the events regarding both of the containers
of our Pod went smoothly.