I set up a few Kubernetes clusters preparing for the CKA exam and discovered that upon reboot, my control plane node didn’t work. Running any kubectl command I get:
The connection to the server 192.168.1.57:6443 was refused - did you specify the right host or port?
This is a common error message that can result from numerous issues but I started troubleshooting by seeing if the kubelet process was running with ps aux | grep kube. Nothing…no kubelet service running. Then I looked at /var/log/syslog and I found the problem — swap was back on!
In Part 1, we created the Kubernetes cluster by running kubeadm init on the control plane node. In part 2 we’ll add a node to an existing cluster that will be capable of running pods which is apparently a possible CKA exam scenario (see cluster ik8s):
The new CKA 2020 for Kubernetes v1.19 blueprint has an objective to, “Use Kubeadm to install a basic cluster.” While I haven’t taken the CKA v1.19 exam yet, based on the exam environment from Linux Foundation (image below), it doesn’t appear that creating a brand new cluster will be necessary in the exam. Instead, cluster ik8s is missing a node and I assume the task will involve gathering the information to add the node to the cluster.
While I’m not an advanced Linux user, I’m comfortable navigating a Linux filesystem. But the lack of a GUI always gave me a bit of anxiety when trying to find where a binary or config file lives. To amplify that frustration, while preparing for the CKA 1.19 exam, I realized that Kubernetes doesn’t store things in one directory so to help myself visualize and remember the directories better, I made the below graphic that illustrates the directories that are necessary for troubleshooting a Kubernetes cluster. In this post, we’ll explore how Kubernetes uses each directory and it’s importance for the CKA.
The final module of the Cluster Architecture, Installation, and Configuration is Implement etcd backup and restore. Let’s quickly perform the actions we need to complete this step for the exam.
Perform a Backup of etcd
While it’s still early and details of the CKA v1.19 environment aren’t known yet, I’m anticipating a small change to how etcd backup and restore is performed. If you’ve been preparing for the CKA before the September 2020 change to Kubernetes v1.19, you may know be familiar with the environment variable export ETCDCTL_API=3 to ensure you’re using version 3 of etcd’s API, which has the backup and restore capability. However, Kubernetes v1.19 ships with etcd 3.4.9 and in etcd 3.4.x, the default API version is 3 so this process is no longer necessary! If etcdctl version returns a version lower than 3.4.x, you will still need to set the API version to 3 for performing backup and restore operations.
As part of my goal to obtain the Certified Kubernetes Administrator (CKA) certification, I went through the Kubernetes documentation to find the specific links that map to the domain knowledge objectives for the v1.19 exam.
I’ve been slowly working towards CKA and there is a significant change to the curriculum with the recent announcement from the Cloud Native Computing Foundation (CNCF) that the Certified Kubernetes Administrator (CKA) exam curriculum will be updated in September 2020 to cover Kubernetes v1.19. The v1.19 curriculum is a huge change from the v1.18 curriculum I’ve been studying and I prepared this comparison to help with my studies and hope it provides some clarity to those in a similar situation as me.
Kubernetes v1.19 hasn’t been finalized yet but there will certainly be new features, added commands, and others deprecated as part of the update. But that’s not the only change — the exam curriculum is also changing a lot!
I must admit that I wasn’t on the Kubernetes bandwagon from beginning. However, I’ve seen it mature rapidly over the last 4 years with an expanding ecosystem and high rate of adoption that has given me confidence that there is a future with Kubernetes and now is the time to invest in learning it. Here are the 3 things I observed over the last 12-18 months to solidify that now is the time for me to focus on becoming a Kubernetes expert:
Cloud Native Landscape Explosion
The Cloud Native Computing Foundation (CNCF) began publishing the CNCF Cloud Native Landscape back in 2016 to illustrate the projects and enterprise software that are part of the cloud native ecosystem and community. The Cloud NativeLandscape graphic originally contained three projects: Kubernetes, Prometheus, and Opentracing. Today, it includes over 48 (not including CNCF member/non-member products and projects)! Observing this type of growth signals heavy investment by organizations and individuals to improving core functionality of Kubernetes or filling gaps in the ecosystem.