You can access this page also inside the Remote Desktop by using the icons on the desktop

  • Score
  • Questions and Answers
  • Preview Questions and Answers
  • Exam Tips
answers

CKAD Simulator Kubernetes 1.30

https://killer.sh

 

 

 

Question 1 | Namespaces

 

The DevOps team would like to get the list of all Namespaces in the cluster. Get the list and save it to /opt/course/1/namespaces.

 

Answer:

The content should then look like:

 

 

Question 2 | Pods

 

Create a single Pod of image httpd:2.4.41-alpine in Namespace default. The Pod should be named pod1 and the container should be named pod1-container.

Your manager would like to run a command manually on occasion to output the status of that exact Pod. Please write a command that does this into /opt/course/2/pod1-status-command.sh. The command should use kubectl.

 

Answer:

Change the container name in 2.yaml to pod1-container:

Then run:

Next create the requested command:

The content of the command file could look like:

Another solution would be using jsonpath:

To test the command:

 

 

Question 3 | Job

 

Team Neptune needs a Job template located at /opt/course/3/job.yaml. This Job should run image busybox:1.31.0 and execute sleep 2 && echo done. It should be in namespace neptune, run a total of 3 times and should execute 2 runs in parallel.

Start the Job and check its history. Each pod created by the Job should have the label id: awesome-job. The job should be named neb-new-job and the container neb-new-job-container.

 

Answer:

Make the required changes in the yaml:

Then to create it:

Check Job and Pods, you should see two running parallel at most but three in total:

Check history:

At the age column we can see that two pods run parallel and the third one after that. Just as it was required in the task.

 

 

Question 4 | Helm Management

 

Team Mercury asked you to perform some operations using Helm, all in Namespace mercury:

  1. Delete release internal-issue-report-apiv1

  2. Upgrade release internal-issue-report-apiv2 to any newer version of chart bitnami/nginx available

  3. Install a new release internal-issue-report-apache of chart bitnami/apache. The Deployment should have two replicas, set these via Helm-values during install

  4. There seems to be a broken release, stuck in pending-install state. Find it and delete it

 

Answer:

Helm Chart: Kubernetes YAML template-files combined into a single package, Values allow customisation

Helm Release: Installed instance of a Chart

Helm Values: Allow to customise the YAML template-files in a Chart when creating a Release

 

1.

First we should delete the required release:

 

2.

Next we need to upgrade a release, for this we could first list the charts of the repo:

Here we see that a newer chart version 9.5.2 is available. But the task only requires us to upgrade to any newer chart version available, so we can simply run:

Looking good!

INFO: Also check out helm rollback for undoing a helm rollout/upgrade

 

3.

Now we're asked to install a new release, with a customised values setting. For this we first list all possible value settings for the chart, we can do this via:

Huge list, if we search in it we should find the setting replicaCount: 1 on top level. This means we can run:

If we would also need to set a value on a deeper level, for example image.debug, we could run:

Install done, let's verify what we did:

We see a healthy deployment with two replicas!

 

4.

By default releases in pending-upgrade state aren't listed, but we can show all to find and delete the broken release:

Thank you Helm for making our lifes easier! (Till something breaks)

 

 

Question 5 | ServiceAccount, Secret

 

Team Neptune has its own ServiceAccount named neptune-sa-v2 in Namespace neptune. A coworker needs the token from the Secret that belongs to that ServiceAccount. Write the base64 decoded token to file /opt/course/5/token.

 

Answer:

Since K8s 1.24, Secrets won't be created automatically for ServiceAccounts any longer. But it's still possible to create a Secret manually and attach it to a ServiceAccount by setting the correct annotation on the Secret. This was done for this task.

If a Secret belongs to a ServiceAccont, it'll have the annotation kubernetes.io/service-account.name. Here the Secret we're looking for is neptune-secret-1.

This shows the base64 encoded token. To get the encoded one we could pipe it manually through base64 -d or we simply do:

Copy the token (part under token:) and paste it using vim.

File /opt/course/5/token should contain the token:

 

 

Question 6 | ReadinessProbe

 

Create a single Pod named pod6 in Namespace default of image busybox:1.31.0. The Pod should have a readiness-probe executing cat /tmp/ready. It should initially wait 5 and periodically wait 10 seconds. This will set the container ready only if the file /tmp/ready exists.

The Pod should run the command touch /tmp/ready && sleep 1d, which will create the necessary file to be ready and then idles. Create the Pod and confirm it starts.

 

Answer:

Search for a readiness-probe example on https://kubernetes.io/docs, then copy and alter the relevant section for the task:

Then:

Running k get pod6 we should see the job being created and completed:

We see that the Pod is finally ready.

 

 

Question 7 | Pods, Namespaces

 

The board of Team Neptune decided to take over control of one e-commerce webserver from Team Saturn. The administrator who once setup this webserver is not part of the organisation any longer. All information you could get was that the e-commerce system is called my-happy-shop.

Search for the correct Pod in Namespace saturn and move it to Namespace neptune. It doesn't matter if you shut it down and spin it up again, it probably hasn't any customers anyways.

 

Answer:

Let's see all those Pods:

The Pod names don't reveal any information. We assume the Pod we are searching has a label or annotation with the name my-happy-shop, so we search for it:

We see the webserver we're looking for is webserver-sat-003

Change the Namespace to neptune, also remove the status: section, the token volume, the token volumeMount and the nodeName, else the new Pod won't start. The final file could look as clean like this:

Then we execute:

It seems the server is running in Namespace neptune, so we can do:

Let's confirm only one is running:

This should list only one pod called webserver-sat-003 in Namespace neptune, status running.

 

 

Question 8 | Deployment, Rollouts

 

There is an existing Deployment named api-new-c32 in Namespace neptune. A developer did make an update to the Deployment but the updated version never came online. Check the Deployment history and find a revision that works, then rollback to it. Could you tell Team Neptune what the error was so it doesn't happen again?

 

Answer:

We see 5 revisions, let's check Pod and Deployment status:

Let's check the pod for errors:

Someone seems to have added a new image with a spelling mistake in the name ngnix:1.16.3, that's the reason we can tell Team Neptune!

Now let's revert to the previous version:

Does this one work?

Yes! All up-to-date and available.

Also a fast way to get an overview of the ReplicaSets of a Deployment and their images could be done with:

 

 

Question 9 | Pod -> Deployment

 

In Namespace pluto there is single Pod named holy-api. It has been working okay for a while now but Team Pluto needs it to be more reliable.

Convert the Pod into a Deployment named holy-api with 3 replicas and delete the single Pod once done. The raw Pod template file is available at /opt/course/9/holy-api-pod.yaml.

In addition, the new Deployment should set allowPrivilegeEscalation: false and privileged: false for the security context on container level.

Please create the Deployment and save its yaml under /opt/course/9/holy-api-deployment.yaml.

 

Answer

There are multiple ways to do this, one is to copy an Deployment example from https://kubernetes.io/docs and then merge it with the existing Pod yaml. That's what we will do now:

Now copy/use a Deployment example yaml and put the Pod's metadata: and spec: into the Deployment's template: section:

To indent multiple lines using vim you should set the shiftwidth using :set shiftwidth=2. Then mark multiple lines using Shift v and the up/down keys.

To then indent the marked lines press > or < and to repeat the action press .

Next create the new Deployment:

and confirm it's running:

Finally delete the single Pod:

 

 

Question 10 | Service, Logs

 

Team Pluto needs a new cluster internal Service. Create a ClusterIP Service named project-plt-6cc-svc in Namespace pluto. This Service should expose a single Pod named project-plt-6cc-api of image nginx:1.17.3-alpine, create that Pod as well. The Pod should be identified by label project: plt-6cc-api. The Service should use tcp port redirection of 3333:80.

Finally use for example curl from a temporary nginx:alpine Pod to get the response from the Service. Write the response into /opt/course/10/service_test.html. Also check if the logs of Pod project-plt-6cc-api show the request and write those into /opt/course/10/service_test.log.

 

Answer

This will create the requested Pod. In yaml it would look like this:

Next we create the service:

Expose will create a yaml where everything is already set for our case and no need to change anything:

We could also use create service but then we would need to change the yaml afterwards:

Check the Service is running:

Does the Service has one Endpoint?

Or even shorter:

Yes, endpoint there! Finally we check the connection using a temporary Pod:

Great! Notice that we use the Kubernetes Namespace dns resolving (project-plt-6cc-svc.pluto) here. We could only use the Service name if we would also spin up the temporary Pod in Namespace pluto .

And now really finally copy or pipe the html content into /opt/course/10/service_test.html.

Also the requested logs:

 

 

Question 11 | Working with Containers

 

During the last monthly meeting you mentioned your strong expertise in container technology. Now the Build&Release team of department Sun is in need of your insight knowledge. There are files to build a container image located at /opt/course/11/image. The container will run a Golang application which outputs information to stdout. You're asked to perform the following tasks:

 

NOTE: Make sure to run all commands as user k8s, for docker use sudo docker

 

  1. Change the Dockerfile. The value of the environment variable SUN_CIPHER_ID should be set to the hardcoded value 5b9c1065-e39d-4a43-a04a-e59bcea3e03f

  2. Build the image using Docker, named registry.killer.sh:5000/sun-cipher, tagged as latest and v1-docker, push these to the registry

  3. Build the image using Podman, named registry.killer.sh:5000/sun-cipher, tagged as v1-podman, push it to the registry

  4. Run a container using Podman, which keeps running in the background, named sun-cipher using image registry.killer.sh:5000/sun-cipher:v1-podman. Run the container from k8s@terminal and not root@terminal

  5. Write the logs your container sun-cipher produced into /opt/course/11/logs. Then write a list of all running Podman containers into /opt/course/11/containers

 

Answer

Dockerfile: list of commands from which an Image can be build

Image: binary file which includes all data/requirements to be run as a Container

Container: running instance of an Image

Registry: place where we can push/pull Images to/from

 

1.

First we need to change the Dockerfile to:

 

2.

Then we build the image using Docker:

There we go, built and pushed.

 

3.

Next we build the image using Podman. Here it's only required to create one tag. The usage of Podman is very similar (for most cases even identical) to Docker:

Built and pushed using Podman.

 

4.

We'll create a container from the perviously created image, using Podman, which keeps running in the background:

 

5.

Finally we need to collect some information into files:

This is looking not too bad at all. Our container skills are back in town!

 

 

Question 12 | Storage, PV, PVC, Pod volume

 

Create a new PersistentVolume named earth-project-earthflower-pv. It should have a capacity of 2Gi, accessMode ReadWriteOnce, hostPath /Volumes/Data and no storageClassName defined.

Next create a new PersistentVolumeClaim in Namespace earth named earth-project-earthflower-pvc . It should request 2Gi storage, accessMode ReadWriteOnce and should not define a storageClassName. The PVC should bound to the PV correctly.

Finally create a new Deployment project-earthflower in Namespace earth which mounts that volume at /tmp/project-data. The Pods of that Deployment should be of image httpd:2.4.41-alpine.

 

Answer

Find an example from https://kubernetes.io/docs and alter it:

Then create it:

Next the PersistentVolumeClaim:

Find an example from https://kubernetes.io/docs and alter it:

Then create:

And check that both have the status Bound:

Next we create a Deployment and mount that volume:

Alter the yaml to mount the volume:

We can confirm it's mounting correctly:

 

 

Question 13 | Storage, StorageClass, PVC

 

Team Moonpie, which has the Namespace moon, needs more storage. Create a new PersistentVolumeClaim named moon-pvc-126 in that namespace. This claim should use a new StorageClass moon-retain with the provisioner set to moon-retainer and the reclaimPolicy set to Retain. The claim should request storage of 3Gi, an accessMode of ReadWriteOnce and should use the new StorageClass.

The provisioner moon-retainer will be created by another team, so it's expected that the PVC will not boot yet. Confirm this by writing the log message from the PVC into file /opt/course/13/pvc-126-reason.

 

Answer

Head to https://kubernetes.io/docs, search for "storageclass" and alter the example code to this:

Now the same for the PersistentVolumeClaim, head to the docs, copy an example and transform it into:

Next we check the status of the PVC :

This confirms that the PVC waits for the provisioner moon-retainer to be created. Finally we copy or write the event message into the requested location:

 

 

Question 14 | Secret, Secret-Volume, Secret-Env

 

You need to make changes on an existing Pod in Namespace moon called secret-handler. Create a new Secret secret1 which contains user=test and pass=pwd. The Secret's content should be available in Pod secret-handler as environment variables SECRET1_USER and SECRET1_PASS. The yaml for Pod secret-handler is available at /opt/course/14/secret-handler.yaml.

There is existing yaml for another Secret at /opt/course/14/secret2.yaml, create this Secret and mount it inside the same Pod at /tmp/secret2. Your changes should be saved under /opt/course/14/secret-handler-new.yaml. Both Secrets should only be available in Namespace moon.

 

Answer

The last command would generate this yaml:

Next we create the second Secret from the given location, making sure it'll be created in Namespace moon:

We will now edit the Pod yaml:

Add the following to the yaml:

There is also the possibility to import all keys from a Secret as env variables at once, though the env variable names will then be the same as in the Secret, which doesn't work for the requirements here:

Then we apply the changes:

Instead of running delete and create we can also use recreate:

It was not requested directly, but you should always confirm it's working:

 

 

Question 15 | ConfigMap, Configmap-Volume

 

Team Moonpie has a nginx server Deployment called web-moon in Namespace moon. Someone started configuring it but it was never completed. To complete please create a ConfigMap called configmap-web-moon-html containing the content of file /opt/course/15/web-moon.html under the data key-name index.html.

The Deployment web-moon is already configured to work with this ConfigMap and serve its content. Test the nginx configuration for example using curl from a temporary nginx:alpine Pod.

 

Answer

Let's check the existing Pods:

Good so far, now let's create the missing ConfigMap:

This should create a ConfigMap with yaml like:

After waiting a bit or deleting/recreating (k -n moon rollout restart deploy web-moon) the Pods we should see:

Looking much better. Finally we check if the nginx returns the correct content:

Then use one IP to test the configuration:

For debugging or further checks we could find out more about the Pods volume mounts:

And check the mounted folder content:

Here it was important that the file will have the name index.html and not the original one web-moon.html which is controlled through the ConfigMap data key.

 

 

Question 16 | Logging sidecar

 

The Tech Lead of Mercury2D decided it's time for more logging, to finally fight all these missing data incidents. There is an existing container named cleaner-con in Deployment cleaner in Namespace mercury. This container mounts a volume and writes logs into a file called cleaner.log.

The yaml for the existing Deployment is available at /opt/course/16/cleaner.yaml. Persist your changes at /opt/course/16/cleaner-new.yaml but also make sure the Deployment is running.

Create a sidecar container named logger-con, image busybox:1.31.0 , which mounts the same volume and writes the content of cleaner.log to stdout, you can use the tail -f command for this. This way it can be picked up by kubectl logs.

Check if the logs of the new container reveal something about the missing data incidents.

 

Answer

Add a sidecar container which outputs the log file to stdout:

Then apply the changes and check the logs of the sidecar:

This will cause a deployment rollout of which we can get more details:

Check Pod statuses:

Finally check the logs of the logging sidecar container:

Mystery solved, something is removing files at random ;) It's important to understand how containers can communicate with each other using volumes.

 

 

Question 17 | InitContainer

 

Last lunch you told your coworker from department Mars Inc how amazing InitContainers are. Now he would like to see one in action. There is a Deployment yaml at /opt/course/17/test-init-container.yaml. This Deployment spins up a single Pod of image nginx:1.17.3-alpine and serves files from a mounted volume, which is empty right now.

Create an InitContainer named init-con which also mounts that volume and creates a file index.html with content check this out! in the root of the mounted volume. For this test we ignore that it doesn't contain valid html.

The InitContainer should be using image busybox:1.31.0. Test your implementation for example using curl from a temporary nginx:alpine Pod.

 

Answer

Add the InitContainer:

Then we create the Deployment:

Finally we test the configuration:

Beautiful.

 

 

Question 18 | Service misconfiguration

 

There seems to be an issue in Namespace mars where the ClusterIP service manager-api-svc should make the Pods of Deployment manager-api-deployment available inside the cluster.

You can test this with curl manager-api-svc.mars:4444 from a temporary nginx:alpine Pod. Check for the misconfiguration and apply a fix.

 

Answer

First let's get an overview:

Everything seems to be running, but we can't seem to get a connection:

Ok, let's try to connect to one pod directly:

The Pods itself seem to work. Let's investigate the Service a bit:

Endpoint inspection is also possible using:

No endpoints - No good. We check the Service yaml:

Though Pods are usually never created without a Deployment or ReplicaSet, Services always select for Pods directly. This gives great flexibility because Pods could be created through various customized ways. After saving the new selector we check the Service again for endpoints:

Endpoints - Good! Now we try connecting again:

And we fixed it. Good to know is how to be able to use Kubernetes DNS resolution from a different Namespace. Not necessary, but we could spin up the temporary Pod in default Namespace:

Short manager-api-svc.mars or long manager-api-svc.mars.svc.cluster.local work.

 

 

Question 19 | Service ClusterIP->NodePort

 

In Namespace jupiter you'll find an apache Deployment (with one replica) named jupiter-crew-deploy and a ClusterIP Service called jupiter-crew-svc which exposes it. Change this service to a NodePort one to make it available on all nodes on port 30100.

Test the NodePort Service using the internal IP of all available nodes and the port 30100 using curl, you can reach the internal node IPs directly from your main terminal. On which nodes is the Service reachable? On which node is the Pod running?

 

Answer

First we get an overview:

(Optional) Next we check if the ClusterIP Service actually works:

The Service is working great. Next we change the Service type to NodePort and set the port:

We check if the Service type was updated:

(Optional) And we confirm that the service is still reachable internally:

Nice. A NodePort Service kind of lies on top of a ClusterIP one, making the ClusterIP Service reachable on the Node IPs (internal and external). Next we get the internal IPs of all nodes to check the connectivity:

On which nodes is the Service reachable?

On both, even the controlplane. On which node is the Pod running?

In our case on cluster1-node1, but could be any other worker if more available. Here we hopefully gained some insight into how a NodePort Service works. Although the Pod is just running on one specific node, the Service makes it available through port 30100 on the internal and external IP addresses of all nodes. This is at least the common/default behaviour but can depend on cluster configuration.

 

 

Question 20 | NetworkPolicy

 

In Namespace venus you'll find two Deployments named api and frontend. Both Deployments are exposed inside the cluster using Services. Create a NetworkPolicy named np1 which restricts outgoing tcp connections from Deployment frontend and only allows those going to Deployment api. Make sure the NetworkPolicy still allows outgoing traffic on UDP/TCP ports 53 for DNS resolution.

Test using: wget www.google.com and wget api:2222 from a Pod of Deployment frontend.

 

Answer

 

INFO: For learning NetworkPolicies check out https://editor.cilium.io. But you're not allowed to use it during the exam.

 

First we get an overview:

(Optional) This is not necessary but we could check if the Services are working inside the cluster:

Then we use any frontend Pod and check if it can reach external names and the api Service:

We see Pods of frontend can reach the api and external names.

Now we head to https://kubernetes.io/docs, search for NetworkPolicy, copy the example code and adjust it to:

Notice that we specify two egress rules in the yaml above. If we specify multiple egress rules then these are connected using a logical OR. So in the example above we do:

Let's have a look at example code which wouldn't work in our case:

In the yaml above we only specify one egress rule with two selectors. It can be translated into:

Apply the correct policy:

And try again, external is not working any longer:

Internal connection to api work as before:

 

 

Question 21 | Requests and Limits, ServiceAccount

 

Team Neptune needs 3 Pods of image httpd:2.4-alpine, create a Deployment named neptune-10ab for this. The containers should be named neptune-pod-10ab. Each container should have a memory request of 20Mi and a memory limit of 50Mi.

Team Neptune has it's own ServiceAccount neptune-sa-v2 under which the Pods should run. The Deployment should be in Namespace neptune.

 

Answer:

Now make the required changes using vim:

Then create the yaml:

To verify all Pods are running we do:

 

 

Question 22 | Labels, Annotations

 

Team Sunny needs to identify some of their Pods in namespace sun. They ask you to add a new label protected: true to all Pods with an existing label type: worker or type: runner. Also add an annotation protected: do not delete this pod to all Pods having the new label protected: true.

 

Answer

If we would only like to get pods with certain labels we can run:

We can use this label filtering also when using other commands, like setting new labels:

Or we could run:

Let's check the result:

Looking good. Finally we set the annotation using the newly assigned label protected: true:

Not requested in the task but for your own control you could run:

 

preview

CKAD Simulator Preview Kubernetes 1.30

https://killer.sh

This is a preview of the full CKAD Simulator course content.

The full course contains 22 questions and scenarios which cover all the CKAD areas. The course also provides a browser terminal which is a very close replica of the original one. This is great to get used and comfortable before the real exam. After the test session (120 minutes), or if you stop it early, you'll get access to all questions and their detailed solutions. You'll have 36 hours cluster access in total which means even after the session, once you have the solutions, you can still play around.

The following preview will give you an idea of what the full course will provide. These preview questions are not part of the 22 in the full course but in addition to it. But the preview questions are part of the same CKAD simulation environment which we setup for you, so with access to the full course you can solve these too.

The answers provided here assume that you did run the initial terminal setup suggestions as provided in the tips section, but especially:

 

These questions can be solved in the test environment provided through the CKAD Simulator

 

Preview Question 1

In Namespace pluto there is a Deployment named project-23-api. It has been working okay for a while but Team Pluto needs it to be more reliable. Implement a liveness-probe which checks the container to be reachable on port 80. Initially the probe should wait 10, periodically 15 seconds.

The original Deployment yaml is available at /opt/course/p1/project-23-api.yaml. Save your changes at /opt/course/p1/project-23-api-new.yaml and apply the changes.

Answer

First we get an overview:

To note: we see another Pod here called holy-api which is part of another section. This is often the case in the provided scenarios, so be careful to only manipulate the resources you need to. Just like in the real world and in the exam.

Next we use nginx:alpine and curl to check if one Pod is accessible on port 80:

We could also use busybox and wget for this:

Now that we're sure the Deployment works we can continue with altering the provided yaml:

Add the liveness-probe to the yaml:

Then let's apply the changes:

Next we wait 10 seconds and confirm the Pods are still running:

We can also check the configured liveness-probe settings on a Pod or the Deployment:

 

 

Preview Question 2

Team Sun needs a new Deployment named sunny with 4 replicas of image nginx:1.17.3-alpine in Namespace sun. The Deployment and its Pods should use the existing ServiceAccount sa-sun-deploy.

Expose the Deployment internally using a ClusterIP Service named sun-srv on port 9999. The nginx containers should run as default on port 80. The management of Team Sun would like to execute a command to check that all Pods are running on occasion. Write that command into file /opt/course/p2/sunny_status_command.sh. The command should use kubectl.

Answer

Then alter its yaml to include the requirements:

Now create the yaml and confirm it's running:

Confirmed, the AGE column is always in important information about if changes were applied. Next we expose the Pods by created the Service:

Using expose instead of kubectl create service clusterip is faster because it already sets the correct selector-labels. The previous command would produce this yaml:

Let's test the Service using wget from a temporary Pod:

Because the Service is in a different Namespace as our temporary Pod, it is reachable using the names sun-srv.sun or fully: sun-srv.sun.svc.cluster.local.

Finally we need a command which can be executed to check if all Pods are runing, this can be done with:

To run the command:

 

 

Preview Question 3

Management of EarthAG recorded that one of their Services stopped working. Dirk, the administrator, left already for the long weekend. All the information they could give you is that it was located in Namespace earth and that it stopped working after the latest rollout. All Services of EarthAG should be reachable from inside the cluster.

Find the Service, fix any issues and confirm it's working again. Write the reason of the error into file /opt/course/p3/ticket-654.txt so Dirk knows what the issue was.

Answer

First we get an overview of the resources in Namespace earth:

First impression could be that all Pods are in status RUNNING. But looking closely we see that some of the Pods are not ready, which also confirms what we see about one Deployment and one replicaset. This could be our error to further investigate.

Another approach could be to check the Services for missing endpoints:

Service earth-3cc-web doesn't have endpoints. This could be a selector/label misconfiguration or the endpoints are actually not available/ready.

Checking all Services for connectivity should show the same (this step is optional and just for demonstration):

Notice that we use here for example earth-2x3-api-svc.earth. We could also spin up a temporary Pod in Namespace earth and connect directly to earth-2x3-api-svc.

We get no connection to earth-3cc-web.earth:6363. Let's look at the Deployment earth-3cc-web. Here we see that the requested amount of replicas is not available/ready:

To continue we check the Deployment yaml for some misconfiguration:

We change the readiness-probe port, save and check the Pods:

Running, but still not in ready state. Wait 10 seconds (initialDelaySeconds of readinessProbe) and check again:

Let's check the service again:

We did it! Finally we write the reason into the requested location:

 

tips

CKAD Tips Kubernetes 1.30

In this section we'll provide some tips on how to handle the CKAD exam and browser terminal.

 

Knowledge

 

CKAD Preparation

Read the Curriculum

https://github.com/cncf/curriculum

Read the Handbook

https://docs.linuxfoundation.org/tc-docs/certification/lf-handbook2

Read the important tips

https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad

Read the FAQ

https://docs.linuxfoundation.org/tc-docs/certification/faq-cka-ckad

 

Kubernetes documentation

Get familiar with the Kubernetes documentation and be able to use the search. Allowed links are:

NOTE: Verify the list here

 

The Test Environment / Browser Terminal

You'll be provided with a browser terminal which uses Ubuntu 20. The standard shells included with a minimal install of Ubuntu 20 will be available, including bash.

Laggin

There could be some lagging, definitely make sure you are using a good internet connection because your webcam and screen are uploading all the time.

Kubectl autocompletion and commands

Autocompletion is configured by default, as well as the k alias source and others:

kubectl with k alias and Bash autocompletion

yq and jqfor YAML/JSON processing

tmux for terminal multiplexing

curl and wget for testing web services

man and man pages for further documentation

Copy & Paste

There could be issues copying text (like pod names) from the left task information into the terminal. Some suggested to "hard" hit or long hold Cmd/Ctrl+C a few times to take action. Apart from that copy and paste should just work like in normal terminals.

Score

There are 15-20 questions in the exam. Your results will be automatically checked according to the handbook. If you don't agree with the results you can request a review by contacting the Linux Foundation Support.

Notepad & Skipping Questions

You have access to a simple notepad in the browser which can be used for storing any kind of plain text. It might makes sense to use this for saving skipped question numbers. This way it's possible to move some questions to the end.

Contexts

You'll receive access to various different clusters and resources in each. They provide you the exact command you need to run to connect to another cluster/context. But you should be comfortable working in different namespaces with kubectl.

 

PSI Bridge

Starting with PSI Bridge:

  • The exam will now be taken using the PSI Secure Browser, which can be downloaded using the newest versions of Microsoft Edge, Safari, Chrome, or Firefox

  • Multiple monitors will no longer be permitted

  • Use of personal bookmarks will no longer be permitted

The new ExamUI includes improved features such as:

  • A remote desktop configured with the tools and software needed to complete the tasks

  • A timer that displays the actual time remaining (in minutes) and provides an alert with 30, 15, or 5 minute remaining

  • The content panel remains the same (presented on the Left Hand Side of the ExamUI)

Read more here.

 

Terminal Handling

 

Be fast

Use the history command to reuse already entered commands or use even faster history search through Ctrl r .

If a command takes some time to execute, like sometimes kubectl delete pod x. You can put a task in the background using Ctrl z and pull it back into foreground running command fg.

You can delete pods fast with:

 

Vim

Be great with vim.

Settings

In case you face a situation where vim is not configured properly and you face for example issues with pasting copied content you should be able to configure via ~/.vimrc or by entering manually in vim settings mode:

The expandtab make sure to use spaces for tabs.

Toggle vim line numbers

When in vim you can press Esc and type :set number or :set nonumber followed by Enter to toggle line numbers. This can be useful when finding syntax errors based on line - but can be bad when wanting to mark&copy by mouse. You can also just jump to a line number with Esc :22 + Enter.

Copy&Paste

Get used to copy/paste/cut with vim:

Indent multiple lines

To indent multiple lines press Esc and type :set shiftwidth=2. First mark multiple lines using Shift v and the up/down keys. Then to indent the marked lines press > or <. You can then press . to repeat the action.