02
Jun 2020
CKA exam guide
|
Tags |
On Computer Technology
This post covers the knowledge component of the CKA exam.
For generic exam tactics for the exam, I recommend you read my post on CKA / CKAD exam tactics.
To my surprise, there is a good amount of overlap between the CKAD and CKA exam. This is probably good news for people who have spent time preparing for the CKAD exam. Of course, the situation may change in the future.
Therefore, CKAD knowledge should be considered prerequisite for CKA and I recommend you to read my CKAD exam guide for pointers on CKAD specific knowledge. Other than for emphasis, I will not be repeating the content in that post here.
I have read many CKA guides that encourage candidates preparing for the CKA exam to go through Kubernetes The Hard Way several times to get a firm knowledge of Kubernetes to prepare for the exam.
Having done that and been through the CKA exam, I will say that it is not necessary. In fact, Kubernetes The Hard Way is overkill for the CKA exam.
At no point during the exam did I make use of knowledge that I gained exclusively from Kubernetes The Hard Way.
Instead, during preparation, I found myself trying (and failing) to memorize the Common Name, Organization and Subject Alternative Names of the many certificates required by a k8s cluster, as well as trying to gain familiarity with a bunch of command line flags (and their values) for the control plane binaries.
The sheer number of details (and certificates) would be too much for most people to handle.
NOTE: This is not a criticism of Kubernetes The Hard Way. In fact, I highly recommend any serious Kubernetes administrator to do it a few times for knowledge and to appreciate how much custom Kubernetes distributions do for you under the hood, especially cloud based k8s such as GKE, EKS and similar.
The following list is not exhaustive. But they lie outside the purview of CKAD and belong more to the realm of Kubernetes administrators than users. I was not familiar with a good amount of it until I started preparing for the exam.
nodeSelectorkubectl top po and kubectl top node)kubectl get componentstatuses)While some of the information here is available in the official docs and other guides, I choose to cover it here because I find it pretty important and feel I can do better in some aspects.
Service DNS names follow the convention <SERIVCENAME>.<NAMESPACE>.service.cluster.local
Suppose there is a service named web in the apps namespace.
A Pod in the same namespace as the service can refer to the service using the service’s name itself. Eg web.
A Pod in a different namespace has to specify the namespace as well. Eg. web.apps. Alternatively, it can also use the full DNS name of web.apps.service.cluster.local.
Pod DNS names follow the convention <POD IP>.<NAMESPACE>.pod.cluster.local , where <POD IP> is the Pod’s IP address with all the . characters replaced with -.
To get a Pod DNS name, first, you will have to get the IP address of the Pod in question. This can be done using kubectl get po -o wide and further narrowed down if you know the Pod name or select using label(s).
Assuming the Pod IP is 10.244.0.112 and is in the apps namespace, the DNS name of the Pod is 10-244-0-112.apps.pod.cluster.local.
For some unknown reason, this is missing from the most recent (1.18) English Kubernetes docs. I used to be able to find it in (I believe) the 1.13 docs but now it does not seem available. That said, you can still find it on:
For etcd, you must be familiar with how to take snapshot and restore snapshot. It should be sufficient to familiarize yourself with the contents of this doc: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
For systemctl, you should minimally be familiar with how to start, stop, restart and view the status of services, list services and edit service files. The following is a short cheatsheet that assumes you run the commands as root:
# view service status
systemctl status servicename
# start service
systemctl start servicename
# stop service
systemctl stop servicename
# restart service
systemctl restart servicename
# shows the systemctl file for a service
systemctl cat servicename
# edit systemctl file service file
systemctl edit --full servicename
# specify vim as the editor
EDITOR=vim systemctl edit --full servicename
# List services
systemctl list-units
systemctl list-units --all
# Enable a service (so it will automatically run on system boot)
systemctl enable servicename
# Disable a service (so it will not run automatically on system boot)
systemctl disable servicename
We use journalctl to get logs from services run by systemd. For CKA, you may need to use it to view logs for control plane components or kubelet. Below is a cheatsheet of useful commands:
# View logs from service
journalctl -u servicename
# Don't use a pager to view the logs, just direct to standard output
journalctl -u servicename --no-pager
# View logs from service with UTC timestamps
journalctl -u servicename --utc
# View logs from service but in current boot
journalctl -u servicename -b
# View logs in JSON format
journalctl -u servicename -o json
journalctl -u servicename -o json-pretty
The openssl command line is notorious for being very confusing due to how it defies many command line flag conventions and its generally obtuse documentation.
If you have done Kubernetes The Hard Way or used cfssl, you will find that cfssl offers a much better user experience. Hence, you may be tempted to go down the cfssl route and memorize cfssl commands.
However, when I did the actual comparison, there is less memory work required for openssl commands as compared to cfssl, because despite the much better command line docs from cfssl, one has to memorize at least 2 JSON files for cfssl.
Hence I recommend memorizing openssl commands. Thankfully, there are only a few:
# VERY IMPT: Inspect details of a cert
openssl x509 -in example.crt -noout -text
# Generate RSA private key (final argument is number of bits. Eg. 2048, 4096)
openssl genrsa -out example.key 2048
# Create CSR (Certificate Signing Request) from private key
openssl req -new -key example.key -out example.csr
# Create a cert from the CSR. The cert will be signed with a CA cert
openssl x509 -req -in child.csr -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -out child.crt
This is probably optional:
# Create self signed cert (most likely won't need this)
openssl x509 -req -in example.csr -signkey example.key -out example.crt -days 365
I would like to emphasize that you must memorize the following command for viewing the details of an x509 certificate:
openssl x509 -in example.crt -noout -text
Because you may need to inspect the Common Name, Expiry Date, CA, Subject Alternative Name and other details of certificates.
I personally tried this: https://github.com/David-VTUK/CKA-StudyGuide
But I do not find it sufficient for the CKA exam.
Unlike for CKAD, there are much less free practice resources for CKA. This is because there is significantly more work required to setup clusters that mimick scenarios similar to those in the CKA exam and people who do that will want to (and should be) compensated for their effort.
Therefore, I will recommend you to prepare by purchasing the course in the next section.
This is the only paid course I purchased to prepare for CKA and the only one I will recommend: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/
Yes, it’s Mumshad Mannambeth again. If you have read my CKAD exam guide, I recommended his CKAD course there. For CKA, I strongly recommend his CKA course for the lab practices because you will get to go through many different scenarios and clusters which require different debugging methods and solutions. It also showed me many gaps in my knowledge when it comes to the CKA exam.
Having gone through the exam, I would say that the course over prepares one for the exam. But heck, it was fun debugging those clusters. And it is better to over prepare than to under prepare.
Disclaimer: I am not paid to advertise for his course. The lab practices are just fantastic and the lack of free viable alternatives (unlike CKAD) makes it an even more attractive deal.
Unlike the CKAD exam which I believe seasoned users of k8s can pass even without much preparation work, I highly doubt most people can pass the CKA without preparing for it. Exception being people who have setup and maintained bare metal Kubernetes clusters for a long time.
This is due to the higher bar required (74% compared to 66% for CKAD) as well as the much greater breadth that even seasoned administrators may not be familiar with. Despite more time available for the CKA exam (3 hours compared to 2 hours for CKAD), the additional 1 hour of time is not sufficient if one is clueless about what to do.
Disclaimer: Opinions expressed on this blog are solely my own and do not express the views or opinions of my employer(s), past or present.