In this video, we're going to go through the mock exam.
There are about 12 questions to be done in about one hour
or a bit more than one hour.
This one is a fairly simpler mock exam compared to the others.
As and when you go through the different mock exams,
the difficulty increases.
Let's get started.
The first question is to deploy a pod named nginx-pod
using the nginx:alpine image.
That's pretty simple and straightforward.
First, let's see if the environment is set up in a way that we want.
Alias for kubectl is not set.
Also, let's check if auto-completion is set up.
There seems to be-- Auto-completion is set up.
Now, one of the common questions that we get is if auto-completion
is enabled in the exam environment.
Now, one of the thing is if it's not mentioned
in the next foundation documentation about the Kubernetes exams,
then nobody is supposed to answer that question.
Here's what I would suggest,
you don't have to worry about whether it's enabled or not,
because either way,
it's super easy to enable it in a few seconds.
The first thing that you can do is first type K
and see if the kubectl alias is set.
In this case, it's not set.
The other thing you can do is run a kubectl get, and then hit tab twice
and see if auto-competition is set up.
This means that auto-compilation is set.
Either ways, what you could do is, if it's set or not,
you could just go to the Kubernetes documentation pages
and search for kubectl cheat.
Then select the kubectl cheat sheet and just copy and paste this.
It would take about five seconds to get that done.
That would enable auto-completion
and this would enable the alias as well as--
This is important for the auto-completion to work with the alias K.
Then when you're on K, you get kubectl,
and then you have auto-completion as well.
That would take about 5 to 10 seconds.
I would recommend just doing that if you need auto-completion
and alias at the beginning of an exam.
Let's get started.
The first question is to deploy a pod named
nginx-pod using the nginx:alpine image.
For this, we run the kubectl run command.
We'll try to stick to imperative commands as much as we can,
just so it's faster and easier to get things done.
We're going to do a kubectl run, and the pod name is nginx-pod.
I'm just going to copy and paste that.
Then we have image and the image is nginx:alpine.
Then we always verify what we did.
We do a get pod and we see that the pod is created and it's also running.
We'll also describe the pod
and make sure that the image is in nginx:alpine.
Let's proceed.
The next one is to deploy a messaging pod using
the redis:alpine image with the labels set to tier=msg.
If you're not sure about the options for setting labels,
you can quickly take a look at the help.
Here you have labels.
We can even just copy and run this command.
The pod name has to be messaging,
and the image name,
redis:alpine, and the label
is tier=msg.
Let's verify that.
We have the messaging pod.
It uses the redis:alpine image.
The label is also set to tier=msg.
Let's just make sure that it's in a running state.
Yes. It's in a running state.
The next question is to create a namespace named this.
That's easy as well.
We do a kubectl create namespace, this.
Then we do a kubectl get namespace.
That's created.
Now, get the list of nodes in JSON format
and store it in a file at this location.
We know to get a list of nodes, we have kubectl get nodes.
What we want is to get the list of nodes in a JSON format.
We need to use the option -o JSON.
This is in the JSON format, and all we need to do
is redirect that to this particular path.
Let's just verify that it has that information.
The next question is to create a messaging service to expose
the messaging application within the cluster on port 6379.
Here, we know that we have the messaging pod
and we don't have a service for that.
The goal is to create a service called messaging service
to expose the messaging application,
which is the messaging pod within the cluster.
Says within the cluster,
that's basically a service type of cluster IP and on port 6379.
Let's do kubectl expose command, and we can take a look at the help.
We want to do a kubectl expose and then pod,
the name of the pod, and the port.
That's basically what we are going to do.
Kubectl expose pod messaging.
Port is 6379,
but also remember that we need to specify a name for the service.
For that, we have to use the name option.
That's how we create that.
Let's do a get svc, and we see that we have a messaging service
and it is cluster IP.
The port is 6379.
Let's also make sure that
it used the right labels.
Tier=msg is the one.
The most important thing is the endpoints.
It has the endpoints.
You can verify if that is the endpoint
of the messaging pod by looking at the IP here.
It's 10.244.0.6.
10.244.0.6.
The pod numbers are correct as well.
That seems to be good.
The next question is to create a deployment named hr-web-app
using the image kodekloud/webapp-color with two replicas.
Let's do a kubectl create deployment.
The name of the deployment is hr-web-app using the image.
Image is web-app-color and replicas is two.
Let's verify that.
We have a deployment.
It's called hr-web-app.
They're not ready yet.
We want to make sure they're ready,
but we can just look at
that in detail just to know it's used the right image.
That's the right image, and replicas is two and there are two available.
That's good.
Now, create a static pod named static-busybox
on the controlplane node that uses the busybox image
and the command sleep 1000.
We know that for static pods, we create as a normal pod,
so we do a kubectl run.
The pod name is static-busybox
on the controlplane node that uses a busybox image.
Image is equal to busybox and the command.
We have to specify the command.
For that, we do a dash dash command.
We've learned that before specifying a command or argument,
we add the double dash.
That way, everything after that is the command.
Now, the command is sleep and 1000.
Now, we don't want to create this because this is not a normal pod.
It's going to be a static pod.
We're going to get the YAML output for it.
We're going to do a dash dash dryrun equals client.
Always remember dryrun option
has to be before this because it's an option
of the kubectl utility and it has to be in a YAML format.
That's that.
Now, what we want to do is we'll redirect
that output to a file called
static-busybox.yaml.
Let's check that file.
This file is [?].
It has the required information.
It has the busybox image.
It has the sleep 1000 command.
All looks good.
Now, all we need to do is move this file to the directory
where you have the static pod details.
This will be etc, Kubernetes, manifest.
That's the file.
That's the location.
Or you can save time by just specifying the complete path right here.
Let's see if it's created the pod.
We have static-busybox controlplane
and describe pod.
It's in the running state so that's good.
If you do a describe we can see that it has the sleep 1000 command
and it has the busybox image.
The next one is to create a pod in the finance namespace
named temp-bus with the image.
That's easy.
Kubectl run temp-bus.
Let me copy that.
It has to use image redis:alpine,
and it has to be in the namespace finance.
Let's check the pods in the finance namespace to see
that we indeed have the temp-bus pod.
We will describe
the finance namespace.
We see that it indeed is using the redis:alpine image.
That's good.
The next question says
that there's a new application, orange, deployed.
There is something wrong with it.
Identify and fixed the issue.
Let's check the pods.
We see that there is an orange pod
and it's in an Init:CrashLoopBackOff state.
Now, we have seen this CrashLoopBackOff state,
and it's usually something wrong with the pod
or the process running inside the pod crashing.
If there's this init text that you see before the status,
then that indicates the issues with the init container.
This tells us that there's one container on the pod,
but there's also an init container
and it's the init container that's crashing.
We can take a closer look at the pod by running
the kubectl describe pod orange command.
We'll do a kubectl describe pod orange command.
We see indeed there are two containers.
There's the actual container here,
but then there's also the init container here.
If you look at it here,
we are seeing that there's an issue with the init container.
It says pod initializing and it's waiting,
and there seems to be something wrong with this.
We could look at the logs of this
by running a kubectl logs command against this.
We're going to do a kubectl logs.
The pot's orange, but we'll also specify the init container service.
When you run that, you see that it says the command sleeeep is not found.
There is indeed something wrong with that.
If we look at pod again, and if you look at the command
that's drawn to initialize this service, we see that the command
has an incorrect command sleeeep here, so that needs to be fixed.
Let's go ahead and try and fix that.
Let's do a kubectl edit pod orange.
We go down
and we remove these and fix the command.
It's now sleep.
Let's save that.
You're not allowed to save that.
Let's do a kubectl replace force minus F.
It'll delete the pod and recreate it.
It's back.
Let's check the status now.
It's in an initializing state.
Let's watch the status.
It's now in a running state already.
That's the fix for that.
Let's move on to the next question.
The next question is to expose the hr-web-app as a service
at hr-web-app service on port 30082
on the nodes on the cluster.
There are a few things here.
The service that we want to expose is hr-web-app.
The service name should be hr-web-app-service,
and on port 30082 on the node, so that means it's a NodePort.
We want to exposed the application on the ports on the node.
This is the NodePort, and the application is on 8080.
Let's first look at the application that we have.
We're going to do a kubectl get deploy,
and we see that we have the hr-web-app service.
To create a service-- Sorry.
We have the hr-web-app deployment.
To create a service,
we do the kubectl expose command so we can expose this deployment.
We specify deploy and the name of the deployment, so that's hr-web-app.
Then we want to specify a name for the service.
We use the --name=
and then we specify this name.
Then this is also a NodePort service,
so we're going to do a type NodePort.
Then the port that this application is exposed on is just port 8080.
We cannot specify NodePort on this command.
That's something that we know.
We'll have to just create the service like this,
and then later go and edit the NodePort.
If you have specified everything else, so the name of the service,
the type NodePort, and the port itself,
as well as the deployment hr-web-app, that should be sufficient.
Let's take a look at the service.
We have the hr-web-app service and it's off type NodePort.
The NodePort isn't correct but this port is correct.
We can also just verify if it has detected
the endpoints.
It has indeed has the two endpoints,
which are the two pods for the deployment.
All of that looks good.
The only thing that we need to do is edit.
We're going to do a kubectl edit service hr-web-app.
Then we're going to go in here and change the NodePort to 30082.
Let's save that.
Okay, that's done.
Let's do a kubectl get service, and we see that the port is now 30082.
Okay.
That's good for that question.
Let's move on to the next.
The next one is to use a JS0N pathway query to retrieve the osImage
of all the node and store it in a file.
The osImages are under the nodeInfo section
under the status of each node.
We know that to get the nodes, we run the kubectl get nodes command.
If we look at it in the JSON format, -o JSON,
we get all of this information.
The next task is to extract the osImages, the osImage property,
from the nodeInfo section under the status section.
There's a lot of information here, but if you look at it, so you have--
This is the JSON document.
You have items, and inside items is an array and each one is a node.
Currently, there's just one node.
You have node.
You have the document.
You have items.
Under items, you have nodes.
From what's given here,
what we want is under the status section under nodeInfo section.
You have the nodeInfo section, and then you have the osImage,
and the nodeInfo section is actually under the status section.
This is how it is.
This is the entire document, and then you have items.
Then items is an array,
and then within each array, you have status.
Within each item in the array you have status,
and under the status section you have nodeInfo,
and under that you have the osImage.
We want to extract osImage of all the nodes.
For that, what we have to do is, we're going to use the JSON path.
Within the kubectl cheat sheet, we have a JSON path section.
Let's try and find that.
Something like this.
Instead of JSON, we're going to do a JSON path.
As we discussed, we have items, so that's good.
Then the star is for all the nodes.
Within items, each item is a node.
We want to extract this information for all the nodes,
so that's why this star.
Then we'll just follow
the hierarchy that we found.
We have status and then we have nodeInfo,
and then we have the osImage.
That's that.
That's how it's to retrieve the osImages.
If there are multiple nodes,
the single command would just capture the osImage of all those nodes
and this star out here.
We then redirect this to this file.
Then we verify our work by looking at the file, and we see that it indeed
has that information that we requested.
That's that question.
The next one is to create a persistent
volume with the given specification.
To create a persistent volume, there is no imperative command,
so we're going to search
for persistent volume here and we'll get this.
If you look at it here in the subsections,
we have persistent volumes here,
and this is going to give you a good template that you can use.
I'm going to use this template and most likely till here.
I'm going to create my v1 pv.yaml.
I paste the template
and then I'm just going to modify each one.
We have pv analytics.
The storage is going to be 100Mi.
Volume mode, there's no volume mode specified so we don't need that.
Access mode is ReadWriteMany, so that's many.
The claim policy is not given here so we're going to get rid of that.
Storage class name isn't requested as well so we can get rid of that.
The only other thing is host path, so the host path.
The path for this is what is given here.
Pv analytics is the name, 100 Mi is the capacity,
requested access mode is ReadWriteMany,
and the host path is pv data analytics.
That's good.
Let's create a file.
Let's make sure it's created.
We have Pv analytics, pv, the write capacity, ReadWriteMany,
and the rest is okay.
Let's also just make sure the host path is set correctly.
We have the source which I've typed host path
and the path is pv data analytics.
That's about it.
Let's end the exam and wait for the results.
That's 100%.
Well, thanks for watching.