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

Kubernetes Components

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.

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.

Kubernetes resources

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.

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.

Keeping production systems healthy and reliable is a challenge. Are your services running without problem? During high-traffic periods, can your system handle the load without bottlenecks or failures? What about dependencies? Is everything working fine with third-party depencies or is there an outage on cloud service provider? These are everyday challenges for DevOps and SRE teams alike.

Just like messy code gives clues about deeper issues (code smells), monitoring systems can have “monitoring smells.” when something isn’t right. These are signs that your monitoring setup isn’t as good as it should be. While I won’t be diving into how to build the perfect monitoring system. This article will explain what these smells are, how to notice them, and how to fix them.

I’ve done something.

Again.

My cat is on my lap, I’m listening to music with my headset, and I’m writing a blog post about how I moved my blog to another platform. Well, not another platform, actually. I moved it to old friend GitHub again.

This time, though, I developed something simple so I can manage my blog with my own solution.

Starting From the Beginning

What was the previous platform I was using? I was using Write.as. It’s a simple platform where you can share your posts on the Fediverse. The UI is minimal, and the main goal of the CMS platform is clear: just write and share your articles.