Hi and welcome to the solution video where we will troubleshoot failures with the work of node as soon
as you click on the quiz portal.
We'll give you a message that it's breaking something.
So let's wait for the actual question to load up before we start our troubleshooting exercise.
While it loads the question let's look at the official documentation for troubleshooting clusters
so this particular document might be handy when you want to troubleshoot issues with Master or worker
nodes in this specific lab.
We are looking at what can node related issues.
So the two things that you would have to check is cube bullet and cube proxy because those are the two
Cuban covenants specific competence which are running on the worker node so we'll be focusing mainly
on these two services it looks like the first question has loaded up.
So we have to fix the broken cluster to see if it's really broken.
Let's run the cube CTO get nodes come on
so you can see that this is a two node cluster that has one master and there is a node 0 1 worker which
is now not ready state to troubleshoot further.
Let's use a search into that specific node
so first thing we will do is check the cube led process
so in this case it doesn't look like a process for cube it is running.
Let's check the cube let's service the real use system CDL status cube bullet
now in this case you can see that the cube lets serves as dead
tool has been rotated so there is no additional logs that you can see we can try to look for additional
logs using dash L but sometimes that's not really useful.
What we can try to do is restart the cube let service and see if that works
so now after resetting the cube let's service it's back to an active state
let's see if the node 0 1 goes back to really state with just starting the cube let's service so I'll
go back to the master node and I'll run cube still get nodes so looks like in this case the node 0 one
is back to already state after restarting the cube let service let's validate of that ze correct answer
okay that was successful so let's go on to the next question the cluster is broken again investigate
and fix the issue
so if I run cube city you'll get nodes you can see that node 0 1 as again back to not ready state yet
another command that you can make use of ice cube CDL describe node now this might not give you in-depth
details as to why the node has failed but in some cases if there are issues with the hardware with the
specifications of the nodes or one or the will Conan it can provide you some meaningful insights here
as well but in this case it doesn't look like there is anything specific related to the current issue
and the cube deal described node so we'll have to assess each into node 0 1
as before.
Let's try to run our status for the Cuban it service
I can see that the lip service is in an activating state.
It's not dead or inactive.
Looks like it's not just able to start
case when we can use general CTO to troubleshoot further related to the service
here.
I'm going to run General TTL Dash you killed like I'll scroll down to the bottom by pressing shift.
G and here I can see an error that it's unable to load the client see a file which is supposed to be
located at a DC it is speaking I the wrong see a hyphen file does knows such file or directory.
So now let's look at the cube left configuration by default.
This is located at EDC system de sys cube led dot servers Dottie and in this key since it's created
use in Cuba IDM there is a custom service definition file located in this directory
if you open this file you'll see that it has references to other configuration files such as cube config
and the actual configuration used by cube blade
let's check the cube blade configuration file
if you open this file and check the client see a file you can see the incorrect part let's check if
this part as valid or not.
So the CIA dot CRT file is located under a DC Governor the Speaker I
so let's correct that with the naked blade configuration.
Now once we have made this change we'll have to do a system CDL daemon reload
and once that's complete we can do a restart of the Q Let's service
now the cube lit as an actor or running state.
Let's go back to my dorm astronaut and check the status
not 0 1 is now back to already state
the cluster is broken again.
This is the third and final question we're allowed to do the same thing as before troubleshoot why the
cluster is broken.
If you're on the same command you can see that node 0 1 is now back to not ready.
Let's see if anything is listed within the cube C to describe command
doesn't look like there is anything meaningful related to the area that we are seeing.
So let's again go back to North 0 1
and as before.
Let's run our systems EDL status cube let the skids it is active and running but you can see a few errors
one of the errors that you would see is that it's getting a connection timeout or a connection refused
error DCP 1 7 2 dot 17 0 0 0 22 votes 6 5 5 3 Let's check the journals we deal
it's also complaining of the same error there is a connection refused to the IP 172 dot seventeen dot
zero dot 22 and port six Phi Phi three so the cube bullet is trying to communicate to the API server
here and it's fairly straight away if you remember the concepts the default cube apex of a port user
6 4 4 3 we can validate this by running cube CDL cluster in 4 so here you can see that the correct port
as 172 dots only nodes order 22 6 4 4 3
so let's assess you know 0 1 and check out the configuration for Cuba let as before let's go to the
default cube so this definition file
and let's check the Q config the cube config is where the details for the API server stored
now if you look at the service section you can see that the port is incorrect let's correct that and
restart the cube let's service as before let's reload and restart.
Let's go back to the most known and get the status of the nodes
now it's back to a release date
so that seems to have fixed the cluster.
Thank you for joining me in this video.
I hope that you found it useful and I'll see you in the next one.