Kubernetes

This post is the second part of the series about Kubernetes. In the first part, we introduced the K8s and its basic concepts. Before you start creating services or scaling apps, it’s essential to understand the core components of Kubernetes. This post walks you through pods, containers, and deployments—what they are, how they work, and how they come together to keep your apps running smoothly. Local Setup To taste K8s, you do not need access to some fancy remote platform. You can test and play with it on your own machine. Right now, there are a lot of solutions that can help you run K8s locally: ...

Diving into the world of Kubernetes doesn’t need to be intimidating. This post will explain Kubernetes, why it matters, and how it fits into the modern application landscape. By the end, you’ll understand its core purpose and how it can make your development life more manageable. The target audience for this post is developers who are new to Kubernetes or those who work on a product that uses Kubernetes but do not have a deep understanding of it. ...

After building a Docker image faster, I wanted to build it for the K8s cluster. Running the container on the local machine isn’t the same as running it on a cluster. I’m packaging a Go application in my example. But the same principles apply to any other language. Starting Dockerfile I’m starting with the following Dockerfile(Dockerfile_1): ARG GO_VERSION=1.20.3 FROM golang:${GO_VERSION}-buster as builder WORKDIR /app COPY go.mod go.sum /app/ RUN go mod download -x COPY . /app/ RUN go build -o app FROM debian:buster WORKDIR /app COPY --from=builder /app/app /app/ ENTRYPOINT [ "/app/app" ] And I build it with the following command: ...

A Pod would be the smallest deployable unit one can create and manage inside Kubernetes(K8s). In practice, rarely you create a Pod directly. Instead, one would create a Deployment, a StatefulSet, a DaemonSet, a Job, or a CronJob. These are higher-level constructs that would create Pods for you. Here I’m covering common tasks that one would do with a Pod in daily work, like getting logs, opening a shell inside a container, debugging a Pod, etc. ...

There is an application running in a Kubernetes cluster. Goal is to protect this application from any modifications, except if those modifications are coming from predefined actor. Setup Requirements To start let’s set up the Kind cluster and Klock. I assume you already have installed Kind. Now let’s create a cluster and install all requirements: Create cluster: kind create cluster Install cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.2/cert-manager.yaml Install Klock : helm repo add rnemet https://rnemet.dev/helm-charts helm repo update helm install klock rnemet/klock Setup Scenario My application has one Pod and one ConfigMap. By default the Klock supports locking Deployments, Pods, Secrets, and ConfigMaps. So, I’m covered there. ...