Czernobog

My experience with Certified Kubernetes Administrator (CKA)

Tue, 24 Sep 2024 14:57:14 +0530

My Journey Through the Certified Kubernetes Administrator (CKA) Exam

I recently took on the challenge of the Certified Kubernetes Administrator (CKA) exam, and it was a real learning experience. As someone who’s been dabbling in Kubernetes for a while, I figured it was time to test my skills and see if I could get that certification. Here’s how it went down and what I learned along the way.

What is the CKA?

For those who might not be familiar, the CKA certification is designed by the Cloud Native Computing Foundation (CNCF) in partnership with The Linux Foundation. The goal is to test your practical skills in managing Kubernetes clusters. This exam is hands-on, which means you’re not just answering multiple-choice questions—you’re actually working on a live Kubernetes environment.

My Preparation Journey

I started my prep by going through some basic Kubernetes concepts like pods, deployments, services, namespaces, etc., just to refresh my memory. I realized that Kubernetes is such a vast ecosystem that I needed to focus on the core components—etcd, kubelet, kube-proxy, scheduler, and controller manager—because they form the backbone of any Kubernetes cluster.

I also went through the official CKA curriculum and did some exercises using platforms like Killercoda and Killer Shell. These sites offer free* interactive Kubernetes environments, which are great for practicing in a real-world scenario.

One thing that really helped me was setting up my own lab environment. I set up a multi-node cluster using Kubeadm and Calico. If you’re working on your own computer you can use something like Minikube. It is great for single-node clusters, but if you want to get the feel of managing a real cluster, setting up a multi-node cluster with Kubeadm on cloud is a must. I used Google Cloud for this. I setup 3 medium sized VM instances with 2vCPU, 4GB ram and 10GB disk space. I installed kubeadm, kubectl, kubelet, Calico and other resources on each node manually and used the kubeadm join command to connect each node to the controlplane.

The Exam Experience

Once I felt confident, I booked the exam. The exam is proctored online, and they have some strict rules. For example, you can’t have multiple monitors, and there’s a system check to ensure your environment is secure. You’ll be monitored the entire time, so keep that in mind.

The exam is broken down into several domains, with each section focusing on specific skills, like:

Cluster Architecture, Installation, and Configuration
Workloads & Scheduling
Services & Networking
Storage
Troubleshooting

Each task in the exam is weighted differently, and you have to complete them within a certain time frame (but I won’t get into details about timing, since that’s not what this post is about).

Sample Questions and How I Approached Them

To give you a better idea of what the exam is like, here are a few sample questions that resemble the kind of stuff you’ll face. I’ll also explain my approach to solving them.

Sample Question 1:

“Create a pod using a specific image and expose it via a service.”

This one was straightforward. I used kubectl run to create the pod with the image specified in the question, and then used kubectl expose to create a service for it. Here’s what the command looked like:

kubectl run my-pod --image=nginx --restart=Never

kubectl expose pod my-pod --port=80 --target-port=80 --type=ClusterIP

Pretty simple, but you need to be careful with the details like the port numbers and service types.

Sample Question 2:

“Troubleshoot a pod that is stuck in the CrashLoopBackOff state.”

I encountered a few troubleshooting questions like this. The first thing I did was check the pod’s logs to see if there were any error messages:

kubectl logs <pod-name>

Then, I inspected the pod’s events:

kubectl describe pod <pod-name>

From the logs and events, you can often figure out if there’s an issue with the container itself, or maybe there’s a missing secret or config map. In my case, the pod had an incorrect environment variable, which I fixed by editing the deployment:

kubectl edit deployment <deployment-name>

Sample Question 3:

“Configure a network policy to restrict access to certain pods.”

This one was a bit trickier. Network policies are super important in Kubernetes for controlling traffic between pods. To solve this, I created a NetworkPolicy resource and applied it to the correct namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-traffic
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: allowed-app

You have to be very clear about which pods are allowed to talk to each other and ensure your policy is applied to the right namespace.

Sample Question 4:

“Back up the etcd cluster data.”

etcd is the heart of Kubernetes—it stores all the cluster data. The exam may ask you to back up the etcd data. Here’s how I did it:

ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

This command saves a snapshot of etcd’s current state to a file. It’s good to know how to restore the snapshot as well, in case something goes wrong with the cluster.

What I Learned

The CKA exam isn’t about memorizing commands; it’s about understanding Kubernetes inside out. You need to know how things work behind the scenes, and practice is essential. I also realized that reading the Kubernetes documentation is super helpful. There’s no shame in using the docs during the exam—you’re allowed to refer to them, and it’s often faster than second-guessing yourself.

Post-Exam Reflection

Looking back, the experience was decent. Not only did I get to test my knowledge, but I also learned a ton along the way. Kubernetes is powerful, and getting certified is a great way to show that you understand the inner workings of this complex system.

If you’re thinking about taking the CKA, my advice would be: practice as much as possible in a real environment. Set up clusters, break things, and fix them.

Good luck to anyone preparing for the CKA—you’ve got this!

My Amateur Experience with Kubernetes

Sun, 02 Apr 2023 16:29:26 +0530

Introduction

Recently, I had to work on a project that required me to learn Kubernetes within 30 days. This was not the typical way to learn Kubernetes, as I had to learn it on my own, due to work-related requirements. In this article, I will share my experience and the journey that I took to learn Kubernetes.

Getting Started with Minikube: My first Kubernetes installation was done using a VM instance. I had Virt-Manager on my system, as I was preparing for RHCSA. I started Minikube by running the command minikube dashboard instead of minikube start which was not technically correct, but it worked for me. I watched it run with all those emojis and stuff, which was both exciting and kind of dorky.

Learning MySQL and Springboot: Instead of starting with the basics of Kubernetes, I dived right in and started with MySQL and Springboot. I looked up some basic how-to guides on deploying MySQL and Springboot in Kubernetes, which recommended using the Spring Initializr to create a Springboot application. All I had to do was click on generate.

Creating a Docker Image: To create a custom Docker image, I used Docker. There is already an OpenJDK image available on Docker Hub, so I made sure I had the right JDK version (in my case, JDK 8), and I chose a lightweight image based on Alpine Linux. I wrote a Dockerfile that pulled the base image of JDK8-Alpine, copied my Springboot application into the image, and exposed the necessary ports. I created a Docker image with the command docker build -t <dockerhub-username>/custom-image and I had the Docker image ready with me. To test it out, I created a simple docker-compose.yml file and ran the command “docker-compose up -d,” which launched it in detached mode. I checked the webpage by going to http://localhost:<port> and checked if it’s working or not.

Creating a Kubernetes Manifest: I followed the rest of the guide by creating a Kubernetes manifest. I thought that typing the whole manifest instead of copy/pasting might give me some insight into how to type a manifest, but it didn’t work out as planned. I kept getting errors due to missing indentation or white space that I might have added by mistake. Typing the manifest with so many indentations felt like a nightmare. Eventually, I just deleted what I typed and replaced it by copying and pasting it from the tutorial I was following. And it worked!

Adding Angular Application: Now that I had the Springboot in Kubernetes, I decided to do the same with Angular application. I went to search for a tutorial with Angular Springboot in Kubernetes and followed it. Since everything was already there in the tutorial, it was fairly easy but took a bit of trial and error to get the Angular application working.

Learning New Concepts: There were some concepts that I didn’t know yet, like what services are, or what NodePort or ClusterIP are, but I didn’t care for now. I blindly followed the tutorial and got the Angular application working as well. I then tried again with a different tutorial, and it was during this time that I got a bit of a hang of it and started to understand what I was doing.

Starting the Project and Setting up the Database: So, I finally got to the real deployment this time. I was given the task to build a docker image and deploy it. It was quite exciting to get hands-on experience with something practical like this. The good thing was that I didn’t have to worry too much about messing up because it was all being done locally on my laptop using minikube. However, I was on a tight deadline and had to work quickly.

To start off, I created a mysql manifest. I didn’t bother with creating secrets or anything like that. I simply used the variables like root password, db_HOST, and all that in the manifest as one does in docker-compose.yml. I know that’s not the right way to do it, but I was feeling the pressure and had to get things done by the end of the day. It turns out that I needed an exact copy of the database for the spring application to work. I had to use the kubectl port-forward command and install DBeaver to access it. With the help of my colleague, we set up the database, which frankly was kind of annoying. Why would anyone require a database as a dependency?

Building the Spring Boot Application and Docker Image: After that, one of my colleagues provided me with a pre-built jar file of the Spring Boot application. I used the same Dockerfile that I had used in PART I for building the spring boot application. I used the split window feature in VSCode and used the tutorial spring boot manifest as a template. I followed it thoroughly, but soon I realized that there was an issue. The spring boot application required a custom URL. After searching online for a bit, I added a variable as an argument in the Dockerfile, re-created the docker image, and pushed it to Docker Hub. This way, I could add the spring datasource details and change them as required.

Deploying the Spring Boot Manifest and Troubleshooting: Deploying a Spring boot manifest was really annoying. Typing the manifest was not that bad, but there was a minor issue where although the Springboot application was deployed, it kept crashing for some reason. I checked the logs, and I kept getting the error message “communication link failure”. This basically meant that Springboot application was not able to access the database on MySQL. I spent two days straight with one of my colleagues who has worked on the application to figure out the issue. (She is a java developer and barely knows how Kubernetes worked) but I must say, she also spent some time with me to understand the fundamentals of Kubernetes and she is very smart (just wanted to give her a shoutout.). Anyways, we finally found the issue in the JDBC URL, which was missing the “&allowpublickeyretrieval” string at the end. As soon as I added this to the MySQL database in Kubernetes and tried again, it worked. It was very frustrating, but the satisfaction that we got when it finally worked made me feel kind of invincible, and being the noob I am, I wanted more of it.

I didn’t have the complete setup for the application and I knew it would take days to set up. So, my colleague provided me with a pre-built jar file. After that, I created a docker image of the Angular application and deployed it on Docker using a simple docker-compose.yml file to check if it worked.

Once I verified that the application was working in Docker, I created a kubernetes manifest for the Angular application with a service for it. This was a significant milestone for me as I had to go through many tutorials to understand the process. However, I faced an unexpected issue when I deployed the kubernetes manifest and checked the website with kubectl port-forward. Although the website was accessible, there was no data in it.

I spent a considerable amount of time investigating the issue and trying different solutions to resolve it, but nothing worked. I eventually realized that I might need an ingress service to fetch the details from the database. It was not an easy fix, and I had to search for creating an ingress service between the Spring Boot and Angular applications. During the process, I encountered another challenge where I could only access the website if I used the command kubectl port-forward. I wanted to access the website without using that command every time, so I had to deal with a load balancer as well.

Creating the ingress was a bit challenging, and I had to seek help from (another shout-out) Deaddy who assisted me in understanding the process. After successfully deploying the ingress, I could see all the data, and the website was now dynamic instead of static, which was a great achievement. I also deployed the load balancer, which allowed me to access the website directly using the IP Address and port.

Finally, I edited my hosts file and assigned a domain name to the URL, and now I had an actual website working on Kubernetes (without an SSL certificate). It was a thrilling experience to overcome the challenges and deploy the Angular application on Kubernetes, and I was happy to have achieved my goal.

Challenges

These are some of the challenges I faced while learning Kubernetes:

Lack of understanding of Kubernetes basics: Directly diving in to MySQL and Springboot before learning the basics of Kubernetes. This approach may have made it difficult to understand how Kubernetes works and how it can be used to manage containers effectively.

Copying instead of understanding: I had difficulty with creating Kubernetes manifests and eventually copying and pasting them from a tutorial. While this approach may work initially, it may be challenging to modify or debug Kubernetes manifests without a fundamental understanding of them.

Trial and error approach: I used a trial and error approach to get the Angular application working in Kubernetes. While this may have been successful, it is a time-consuming and inefficient approach to problem-solving.

Time constraints: I had to learn Kubernetes within 30 days, which may have put pressure on me resulting in to take shortcuts or not fully understand the concepts before moving on to the next step. This may have affected the overall quality of the learning experience too.

Conclusion

In conclusion, this experience has taught me a lot about the importance of attention to detail and taking the time to properly configure each aspect of the application.

It was also my first time working with a team and this also made me more productive in general and I had a lot of fun working on it.

While it was frustrating at times, the feeling of satisfaction when everything finally came together was worth it. I am excited to continue learning and expanding my skills in this field.