Skip to main content

CKAD Practice Exam – Part 3

Hands-On Lab

 

Photo of Will Boyd

Will Boyd

DevOps Team Lead in Content

Length

01:30:00

Difficulty

Intermediate

This lab is designed to help prepare for the kinds of tasks and scenarios encountered during the Certified Kubernetes Application Developer (CKAD) exam. Here, there is an opportunity to practice debugging applications in Kubernetes. We will locate a problem in the Kubernetes cluster and fix it.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

CKAD Practice Exam - Part 3

The scenario

Our company has a Kubernetes cluster that is running several pods and services. A service called oauth-provider in the gem namespace has stopped working. Our task is to investigate the service and determine what is causing the problem, save some relevant data for future analysis, and then fix the problem.

  • The broken service is oauth-provider. It is located in the gem namespace.
  • Identify which Kubernetes object is broken and causing the service to fail. Save the name of the object in the file /usr/ckad/broken-object-name.txt.
  • Save the object's summary data in JSON format to the file /usr/ckad/broken-object.json.
  • Edit the object to fix the problem.
  • The oauth-provider service is a NodePort service listening on port 30080, so we can test it using curl localhost:30080.

Note that there may be other objects in the cluster which appear to be broken. Our task is to identify what specifically is causing the oauth-provider service to fail. Ignore any object which doesn't affect the oauth-provider service.

Get logged in

Use the credentials and server IP in the hands-on lab overview page to log in with SSH.

Identify the broken object and save its name and summary data

First, let's make sure things are in fact broken:

[user@host]$ curl localhost:30080

Okay, something is in fact broken. Now we have to figure out which object it is. Let's become root so that we can write to the file:

[user@host]$ sudo -i

Describe the broken service:

[root@host]# kubectl describe service oauth-provider -n gem

Note that the service's selector selects pods with the label role: oauth.

Get a list of pods with labels in order to locate the pod(s) selected by the service:

[root@host]# kubectl get pods --all-namespaces --show-labels

Note that the pod called bowline has the role: oauth label.

Save the name of the broken pod in a text file. We can use whichever text editor we like:

[root@host]# vi /usr/ckad/broken-object-name.txt

Put the word bowline in there.

Save the JSON summary data for the broken pod to the specified file:

[root@host]# kubectl get pod bowline -n gem -o json > /usr/ckad/broken-object.json

Fix the problem

Examine the broken pod more closely:

[root@host]# kubectl describe pod bowline -n gem

Based on the event log and pod status, it appears something may be wrong with the pod image. Look at the pod's container image, which appears to be misspelled. Edit the pod:

[root@host]# kubectl edit pod bowline -n gem

Fix the image name by changing it to nginx:1.15.9. It's currently misspelled as ninx:1.15.9.

Verify that the pod is now working:

[root@host]# kubectl get pod bowline -n gem

Test the broken service to make sure it is working:

[root@host]# curl localhost:30080

Conclusion

We fixed it! That little spelling error in our pod image caused a big problem, but we tracked it down and corrected the issue. Congratulations!