As I’ve noted in earlier posts, containers predate Kubernetes. Docker brought them into the mainstream by making image build and runtime management almost trivial. For a development team the first obvious win was reproducibility – build an image once and run it on a developer laptop, a CI runner, or a production node without changing a line of code. The “works on my machine” problem simply went away. But once you start running dozens or hundreds of containers, the question becomes: how do you schedule them, monitor them, network them and recover from failures? That is the problem Kubernetes solves.

Photo and screenshot from Unsplash.

The Kubernetes API is the central hub that powers everything in a Kubernetes cluster (see the official docs: Kubernetes API concepts). It is a collection of HTTP endpoints that allow users, applications, and internal components to communicate with the cluster and manage its resources. Every interaction you have with Kubernetes, whether you realize it or not, goes through this API. It acts as the gateway between you and the cluster, processing requests and translating them into actions that create, modify, or delete resources. Without the API, there would be no way to tell Kubernetes what you want it to do or to check the current state of your applications.

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.

This Christmas break was very fruitful for me. I had a really good holiday which i am able to refresh and I was able to read some books which i had been in my mind last few months. The Wisdom of Crowds by James Surowiecki is one of them. The book is built around one powerful idea. When an ordinary group is set up in the right way, its combined judgment can be better than the judgment of a single expert or even a small team of experts. At first, this feels surprising, because many of us assume the best decisions usually come from the experts on that topic. But Surowiecki shows that, under the right conditions, a mixed group of people can be surprisingly accurate.

We only realize the absence of some things in our lives when we encounter them for the first time. A void we thought was normal for years suddenly makes us say “I have been deprived of this all along”. Is it possible to feel the absence of something you have never had? Sometimes, the lack of something only makes sense when you truly see its presence.

TL;DR

Dev containers turn a complex setup guide into code and give every person the same working environment. They help when your project is not simple, when people use different operating systems, or when you fight works on my machine bugs. They can slow things down and add extra upkeep if the project is already easy to run. Use them only when they remove real pain.

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.

This is one of those topics where everyone seems to have a slightly different view and most of them are valid. That’s the beauty of computer science: there’s rarely a single right answer. You’ve probably come across some of the many answers out there, and I won’t dive into all of them here. It’s simply too much to cover in a single article. I want to share my perspective here. For other viewpoints, you can explore online resources and read different takes on the subject.