Hello and welcome to the solution video for the practice lab for troubleshooting control plane competence
so the first question the cluster is broken.
We tried deploying an application but it's not working troubleshoot and fix the issue.
So for this practice lab we'll have to repeatedly try and figure out issues with controlled plane competence
in the master node and fix it so the first question let's check the existing deployments in this cluster
so you can see that a deployment called app has been created.
But the pod is in a pending state
let's run describe against the port which is in the pending state
so you can see that the inmate uses engine X Alpine the status as spending that doesn't seem to be any
other issue with this port.
So if you remember from the theory and from the lectures the company which is responsible for scheduling
apart onto a worker node as the governor is scheduler you can read more about it from the Covenant is
documentation search for scheduler and you can see that the default scheduler is called queue by phone
scheduler which runs as part of the control plane let's check the scheduler status by running a CubeSat
he'll get ports in the cube system namespace
now straight away you will observe that the cube scheduler master is in a crash loop back off state
now let's check the logs for the governor the scheduler
if you scroll all the way to the bottom you will see that there's a warning with an error failed to
set container cube scheduler error response and below that you can see that the starting container process
was not found in the path and the process name as cube hyphen scheduler and you can see that scheduler
is spelled incorrectly so we'll have to fix this by updating the command and the cube scheduler pod
definition file
he'll also observe that the cube scheduler is appended by the word master which is the node where it's
running.
So this is a handy little tip which confirms that the pod is created as a static pod for any static
pod the pod name is appended by the name where the pod is running.
So in this case it's running on Master because it's a controlled plane competent so we can assume that
this is a static pod another way to confirm this as by checking air for static pod directory has been
configured in the cube it
to do this let's check these service configuration for the cube let's service so I'm going to the default
service directory here under ATC system the system Kublai dots service and looks like there is a custom
cube HDMI configuration created for the Q blade service and that has an additional argument for the
new blade configuration which is stored on the war lip Q blade slash conflict Dot.
Let's search for static port and legal and its documentation so to create a static port you can see
that a static port part has to be defined with a leakage blade configuration file.
So let's search for this field within the configuration file
so in this case you can see that the static port path is slash EDC slash Governor this slash manifest.
This is the default location for static ports which are created by QB the.
So let's go to the spot and check the Cuban net as scheduler pod definition file
so here you can see that within the command section the name of the scheduler is incorrect.
So let's correct that and save the file as soon as you save the file.
Make any changes to Cuba any scheduler dot Yammer within the static pod but it will recreate the pod
you can see that the cube scheduler master has been recreated 3 seconds ago.
Now that the scheduler is up and running the application port should soon be scheduled onto a a node.
Now you can see that it's another release date
let's validate the answer
for the next question.
We have to scale the deployment to to port so I'll make use of cube CDL scale deployment app with replicas
as equal to to
two looks like that has not vote but let's continue
so for the third question even though the deployment was skill 2 to the number of boards does not seem
to increase investigate and fix the issue inspect the competent responsible for managing deployments
and replica sets.
So again going back to the theory and if you watch the lectures you would have known that the competent
responsible for managing deployments and replicas set as the Covenant as controller manager so let's
go back and check the control plane competence in the coop system namespace and check the status
now in this case the cube controller manager M. is also in a crash loop back off state.
Now again this pod is appended with the name of the node which is M..
So this is also most likely to be a static pod.
We're already in the static pod directory.
But first let's check the logs by running a cube CDL describe against the cube controller manager
Let's run a cube CDL logs against the Q control manager we did not get any meaningful information from
CubeSat still describe but from the logs you can see that it's trying to load a file call EDC government
is controller or manager dash X X X X dot com conf and it's not able to find such a file or directory
now going back to the location where it's trying to face the file there is no file called controller
manager dash X is X dot com.
Instead there is a file called controller manager dot conf
so let's update the port definition file for cube controller manager and correct the file name
too this is the cube config widgets feeling too fine so let's corrector.
Finally
as before as soon as you make a change the port will be redeployed as you can see it's right now in
appending state but soon it will go to a running state.
Now let's check our deployment
as you can see it is now scaling to two replicas let's validate the answer and move on to the next question.
Something is wrong with scaling again.
We just tried scaling the deployment to three replicas but it's not happening so it's safe to assume
that the cube controller manager is broken again
and you can see that the cube controller manager part is now back to a crash loop back off state.
So let's do the same thing as before.
First let's run describe against that part
it doesn't seem like you're getting a lot of information related to the error here.
So let's run a cube CTA log
now.
In this case you're seeing that it is unable to load DC file which should be EDC given it is speaking.
I don't see it on CRT.
So this is from the container log so let's see how the container is making use of this file
so I'm going back to the port definition file for the cube cube controller.
Manager
before that let's make sure that we're on the correct path.
So we are.
And it is equal than it is manifest directory which as the static port part
the CIA file as a D.C. covenant is picky.
I don't see year old CRT so I'm just going to copy this and try to see where this is configured.
And again it is used in the command and as they see it on CRT.
Now let's scroll down and try to make sense of how this is actually used.
Now if you scroll down you'll see that the pod has a mount part with the name key hyphen silhouettes
which makes use of the amount but ADC covenant is large PGI on the container.
Now let's look at how the kid Ivan inserts volume has been configured
so if you search for kids I find certs within the same pod definition file you'll see that it is created
as a host part so the volume refers to the part EDC covenant is slash wrong.
PGI directory within the master node but looks like this part itself is wrong.
Now if you go back to EDC slash given it is there is a wrong B.K. I territory here and it's got no seed
or CRT file within it.
The correct directory should be slash ADC governorates slash picky I
as you can see that as the correct directory which has the C certificate.
Now let's go back and edit the queue controller manager
and we will fix the part for Kate's iPhone so its volume
and as soon as I've made that change the cube controller manager has been redeployed.
Now you can see that the total replica is up and running.
So let's validate the answer.
Congratulations you have successfully finished this lap.
I hope that you found the solution video useful.
I'll see you and the next one.
Thank you.