Kubernetes

Hello there. In the previous article we reviewed Kubernetes and its resources and we talked about how to manage a resource. That was a basic introduction to Kubernetes. In this article we will dive deeper into Kubernetes and start discussing its architecture.

Image source: kubernetes.io

From the image I shared above, Kubernetes has cluster components that handle container orchestration. These are the control plane and the worker nodes. Let’s focus on the control plane and the worker nodes and review how they work.

Now that we have defined Kubernetes and reviewed its history, let us look at Kubernetes resources. Kubernetes resources are the basic building blocks that represent the desired state of the cluster. You can think of them as objects stored in the Kubernetes API. There are many types of Kubernetes objects. They describe which containerized applications run, what resources those applications can use, and the policies that control their behavior.

Resources can be grouped in different ways. A useful approach is to group them by function.

Two weeks ago there was a discount on Linux Foundation exams, so I bought the KCNA (Kubernetes and Cloud Native Associate) exam because it looked like a good starting point. I wanted a short, focused review about 30 pages of notes to study before the exam, but I could not find a reliable one, so I made my own.

I will publish a series of posts about KCNA (and later CKA) as a short study guide. In this first post I explain what the KCNA exam covers, how it works, and how to prepare. Later posts will cover each topic with short explanations and key points. I will use simple language and keep the content short and practical.

At my company, we’ve been having discussions about finding the best local development environment for our engineering teams. We noticed that inconsistent development setups were slowing down our productivity. So I decided to dig deeper and research the best solutions.

In this article, I’ll share what I discovered during my investigation.

Many development teams face the same challenge: inconsistent local environments. Some developers use Docker, others prefer Minikube, and a few try connecting directly to shared clusters. The result? Everyone runs into the same frustrating issues: setups that don’t match, hours wasted on "it works on my machine" problems, and slow feedback when testing code.