DEV Community: Laxman Patel

CNI Demystified: The Backbone of Kubernetes Networking

Laxman Patel — Wed, 01 Oct 2025 06:04:30 +0000

People can get puzzled when they need to choose one of the available networking solutions for Kubernetes. As you can see there are a lot of solutions.

Most of the mentioned solutions include container network interface (CNI) plug-ins. These are the cornerstones of Kubernetes networking, and it is essential to understand them to make an informed decision which networking solution to chose. It is also useful to know some details about the internals of your preferred networking solution. This way, you will be able to choose what Kubernetes networking features you need, analyze networking performance / security / reliability, and troubleshoot low-level issues.

Some basics behind CNI

When Kubernetes starts up your pod (a logical group of containers), something it will do is create a “infra container” – this is a container that has a shared network namespace (among other namespaces) that all the containers in the pod share.

This means that any networking elements you create in that infra container will be available to all the containers in the pod. This also means that as containers come and go within that pod, the networking stays stable.

If you have a running Kubernetes (which has some pods running), you can perform a docker ps and see containers that often running with gcr.io/google_containers/pause-amd64 image, and they’re running a command that looks like /pause.In theory this is a lightweight enough container that it “shouldn’t really die” and should be available to all containers within that pod.

As Kubernetes creates this infra container, it also will call an executable as specified in the /etc/cni/net.d/*conf files.

If you want even more detail, you can checkout the CNI specification itself.

The official documentation outlines a number of requirements that any CNI plugin implementation should support. Rephrasing it in a slightly different way, a CNI plugin must provide at least the following two things:

Connectivity - making sure that a Pod gets its default eth0 interface with IP reachable from the root network namespace of the hosting Node.
Reachability - making sure that Pods from other Nodes can reach each other directly (without NAT)

Configuring a CNI plug-in

While it’s not required – you probably want to have a Kubernetes environment setup for yourself where you can experiment with deploying the plugins in Kubernetes. In my case, I used a two EC2 instances on AWS with a master and worker node. Both are of the type: t2medium

master[ip-10-0-0-210] ; worker[ip-10-0-10-51]

Using kubeadm to deploy Kubernetes

We will be using kubeadm to configure and run Kubernetes components on our EC2. You can follow the script from the Github to setup the cluster. Once done, to check what subnets are allocated from the pod network range to both master and worker nodes

$ kubectl describe node ip-10-0-0-210 | grep PodCIDR
PodCIDR:                     10.244.0.0/24

$ kubectl describe node ip-10-0-10-51| grep PodCIDR
PodCIDR:                     10.244.1.0/24

As you can see from the output, the whole pod network range (10.244.0.0./20) has been divided into small subnets, and each of the nodes received its own subnets. This means that the master node can use any of the 10.244.0.0–10.244.0.255 IPs for its Pods, and the worker node uses 10.244.1.0–10.244.1.255 IPs.

NAME            STATUS   ROLES           AGE   VERSION
ip-10-0-0-210   NotReady    control-plane   34m   v1.31.5
ip-10-0-10-51   NotReady    <none>          20m   v1.31.5

Step 1 : Creation of the plugin configuration file

The first thing you should do is create the plug-in configuration. Save the following file as /etc/cni/net.d/10-bash-cni-plugin.conf

{
        "cniVersion": "0.4.0", #  version of the CNI specification
        "name": "mynet",       #  name of the plugin
        "type": "bash-cni",    #  plugin written in Bash
        "network": "10.244.0.0/20",
        "subnet": "10.244.0.0/24" # node-cidr-range
}

This must be done on both master and worker nodes. Don’t forget to replace <node-cidr-range> with 10.244.0.0/24 for the master and 10.244.1.0./24 for the worker. It is also very important that you put the file into the /etc/cni/net.d/ folder.

kubelet uses /etc/cni/net.d/ to discover CNI plug-ins.

The first three parameters in the configuration (cniVersion, name, and type) are mandatory.

cniVersion is used to determine the CNI version used by the plugin
name is just the network name
type refers to the file name of the CNI plug-in executable.

The network and subnet parameters are our custom parameters, they are not mentioned in the CNI specification, and later we will see how exactly they are used by the bash-cni network plug-in.

Step 2 : Preparation of a network bridge on both master and worker VMs

The bridge network is a device that aggregates network packets from multiple network interfaces. A bridge is analogous to a network switch.

The bridge can also have its own MAC and IP addresses, so each container sees the bridge as another device plugged into the same network. We reserve the 10.244.0.1 IP address for the bridge on the master VM and 10.244.1.1 for the bridge on the worker VM. The following commands can be used to create and configure the bridge with the cni0 name:

$ sudo brctl addbr cni0
$ sudo ip link set cni0 up
$ sudo ip addr add <bridge-ip>/24 dev cni0

These commands create the bridge, enable it, and then assign an IP address to it. The last command also implicitly creates a route, so that all traffic with the destination IP belonging to the pod CIDR range, local to the current node, will be redirected to the cni0 network interface.

Step 3 : Creation of the plugin binary

The plug-in’s binary format must be placed in the /opt/cni/bin/ folder, its name must be exactly the same as the type parameter in the plug-in configuration (bash-cni), and its contents can be found in the Github-repo After you put the plug-in in the correct folder, don’t forget to make it executable by running sudo chmod +x bash-cni.) This should be done on both master and worker VMs.

The /opt/cni/bin folder stores all the CNI plug-ins.

The CNI plugin binary has 5 main commands :

ADD: This command is invoked by the container runtime to create a new network interface for a container.
DEL: This command is used to delete a network interface when a container is removed.
CHECK: This command checks whether a given configuration is valid and operational.
VERSION: This command retrieves the version of the CNI plugin being used.
GC (Garbage Collection): This command is used to clean up unused resources or stale configurations.

Step 4 : Testing the plugin

Now, if you execute the kubectl get node command, you can see that both nodes should go to the “Ready” state. So, let’s try to deploy an application and see how it works. But before we’re able to do this, we should “untaint” the master node. By default, the scheduler will not put any pods on the master node, because it is “tainted.” But we want to test cross-node container communication, so we need to deploy some pods on the master, as well as on the worker. The taint can be removed using the following command.

$ kubectl taint nodes ip-10-0-0-210 node-role.kubernetes.io/control-plane:NoSchedule-
ip-10-0-0-210 untainted

NOTE : Make sure you install nmap on both of your nodes.

Next, let’s use this test deployment to validate the CNI plug-in.

$ kubectl apply -f https://github.com/Imlucky883/cni-plugin/blob/main/manifests/master-deploy.yaml

Here, we are deploying four simple pods. Two goes on the master and the remaining two on the worker. (Pay attention to how we are using the nodeName property to tell the pod, where it should be deployed.) On both master we have two pods running NGINX while on the worker nodes we have two pods running BUSYBOX with sleep command. Now, let’s run kubectl get pod to make sure that all pods are healthy and then get the pods IP addresses. As I checked the containers were in the PendingState, after I described the pods I got to know that the error was with CNI.

I was getting the below error when I checked the error log of the plugin at /var/log/bash-cni.log

Error: any valid address is expected rather than "(10.244.0.1)".
CNI command: DEL
stdin: {"cniVersion":"0.4.0","name":"mynet","network":"10.244.0.0/20","subnet":"10.244.0.0/24","type":"bash-cni"}
CNI command: ADD
stdin: {"cniVersion":"0.4.0","name":"mynet","network":"10.244.0.0/20","subnet":"10.244.0.0/24","type":"bash-cni"}
Allocated container IP: 10.244.0.61

After surfing the online for more than 1 hour, I found that the way nmap generates IP addresses includes extra characters like parentheses. I added tr -d '()' to the plugin script which actually fixed the issue and now IP’s were allocated to the Pods. Below is the command that I added in the /opt/cni/bin/bash-cni

all_ips=($(nmap -sL $subnet | grep "Nmap scan report" | awk '{print $NF}' | tr -d '()'))

Now I checked the Pod status and both the pods are successfully been allocated a IP.

$ kubectl get pods -o wide

busybox-deployment-787d986855-dxq7z   1/1     Running   0          22s   10.244.1.2   ip-10-0-10-51   <none>           <none>
busybox-deployment-787d986855-jxtx9   1/1     Running   0          22s   10.244.1.3   ip-10-0-10-51   <none>           <none>
nginx-deployment-6b874d4659-bmnk9     1/1     Running   0          30m   10.244.0.3   ip-10-0-0-210   <none>           <none>
nginx-deployment-6b874d4659-pkn2n     1/1     Running   0          30m   10.244.0.2   ip-10-0-0-210   <none>           <none>

Now the objective is to test the connectivity between pod-pod, pod-node & pod-external connectivity.

$ kubectl exec -it busybox-deployment-787d986855-dxq7z -- sh

/ ping 10.0.10.51 # can ping own host
PING 10.0.10.51 (10.0.10.51): 56 data bytes
64 bytes from 10.0.10.51: seq=0 ttl=64 time=0.070 ms
64 bytes from 10.0.10.51: seq=1 ttl=64 time=0.071 ms

$ ping 10.0.0.210 # can’t ping different host 
PING 10.0.0.210 (10.0.0.210): 56 data bytes

$ ping 10.244.0.2 # can ping a pod on the same host
64 bytes from 10.244.0.2: seq=0 ttl=64 time=0.092 ms
64 bytes from 10.244.0.2: seq=1 ttl=64 time=0.055 ms

$ ping 10.244.1.3 # can’t ping a pod on a different host
PING 10.244.1.3 (10.244.1.3): 56 data bytes

$ ping 108.177.121.113 # can’t ping any external address
PING 110.234.16.223 (110.234.16.223): 56 data bytes

As you can see, the only thing that actually works is a pod to pod and Pod to host communication.

Case 1 : Can’t ping external address

The fact that our container can’t reach the Internet should be no surprise for you. Our containers are located in a private subnet (10.244.0.0/24).

In order to fix this, we should set up a network address translation (NAT) on the host VM. NAT is a mechanism that replaces a source IP address in the outcoming package with the IP address of the host VM. The original source address is stored somewhere else in the TCP packet. When the response arrives to the host VM, the original address is restored, and a package is forwarded to the container network interface. You can easily setup NAT using the following two commands:

$ sudo iptables -t nat -A POSTROUTING -s 10.244.0.0/24 ! -o cni0 -j MASQUERADE # on master

$ sudo iptables -t nat -A POSTROUTING -s 10.244.1.0/24 ! -o cni0 -j MASQUERADE # on worker

Pay attention that here we are NATing only packages with the source IP belonging to the local pod subnet, which are not meant to be sent to the cni0 bridge. The ! -o cni0 condition in the iptables rule ensures that NAT is not applied to traffic intended to stay within the cluster (i.e., traffic sent to other pods via the cni0 bridge). Only traffic leaving the cluster and heading to external destinations is NATed.

Case 2 : Can’t ping pod on the other host

Pods on different host can’t talk to each other. If you think about it, this makes a perfect sense. If we are sending a request from the 10.244.0.4 Pod to the 10.244.1.3 Pod, we never specified that the request should be routed through the 10.0.10.51 host. Usually, in such cases, we can rely on the ip route command to setup some additional routes for us. If we carried out this experiment on some bare-metal servers directly connected to each other, we could do something like this:

$ ip route add 10.244.1.0/24 via 10.0.10.51 dev enX0 # run on master 
$ ip route add 10.244.0.0/24 via 10.0.0.210 dev enX0 # run on worker

PriorityClass in Kubernetes: The VIP Pass for Your Pods

Laxman Patel — Wed, 01 Oct 2025 05:47:09 +0000

Imagine you're at an airport, and there's a long queue at security. But suddenly, a VIP with a priority pass walks straight through a special lane, skipping the entire line. Kubernetes has a similar system for pods—it’s called PriorityClass! 🚀

In this article, we’ll break down what PriorityClass is, why it matters, and when you should use it to keep your Kubernetes workloads running smoothly.

What is PriorityClass?

PriorityClass is a Kubernetes feature that assigns priority levels to different pods. It helps the scheduler decide which pods should be scheduled first and which ones should be evicted when resources are limited.

Think of it as a VIP pass for workloads—critical pods get scheduled first, while less important ones may have to wait or even be evicted if resources run out.

How it Works

Each PriorityClass has a numeric value.
The higher the value, the more important the pod is.
If the cluster runs out of resources, lower-priority pods may get evicted to make room for higher-priority ones.
You can also set preemption policies to decide whether a pod should evict lower-priority ones or not.

Why is PriorityClass Helpful?

Kubernetes works best when resources are efficiently managed. PriorityClass helps by**:**

✅ Ensuring critical workloads always run (e.g., system monitoring, security agents)

✅ Preventing resource starvation for high-importance services

✅ Handling overload situations by gracefully evicting low-priority pods

✅ Improving cluster resilience by making sure essential services don’t get disrupted

Without PriorityClass, all pods are treated equally, which can lead to important services getting stuck in a pending state while non-essential ones consume resources.

When Should You Use PriorityClass?

Here are some real-world scenarios where PriorityClass is a lifesaver:

🔹 Critical System Services : Monitoring, logging, and security services should always be running. Assigning them a high-priority class ensures they don’t get evicted when the cluster is under pressure.

🔹 Multi-Tenant Clusters : If multiple teams share a Kubernetes cluster, you might want to prioritize production workloads over development or testing environments.

🔹 Failover & Disaster Recovery : During failovers, critical services need to come back online ASAP. Using PriorityClass ensures your key services recover before anything else.

How to Implement PriorityClass in Kubernetes ?

Below workflow best explains the working of Priorityclass :-

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "High priority class for critical services"

value: 1000000 → Higher value means higher priority.
preemptionPolicy: PreemptLowerPriority → This pod can evict lower-priority pods if resources are tight.
globalDefault: false → This is not the default priority (you must explicitly assign it to pods).

apiVersion: v1
kind: Pod
metadata:
  name: low-priority-pod
spec:
  containers:
    - name: apache
      image: apache2

Assigning PriorityClass to a Pod

apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  priorityClassName: high-priority
  containers:
    - name: nginx
      image: nginx

Now, whenever critical-app is deployed, Kubernetes will give it priority over lower-priority pods.

Important Things to Note

To mark a Pod as critical, set priorityClassName for that Pod to system-cluster-critical or system-node-critical.
system-node-critical is the highest available priority, even higher than system-cluster-critical
All the control-plane components are marked with the system-node-critical as you can see below :-

nodeName: kind-control-plane
  preemptionPolicy: PreemptLowerPriority
  priority: 2000001000
  priorityClassName: system-node-critical

preemptionPolicy field in a PriorityClass resource can take two possible values:
1. PreemptLowerPriority (default) : This allows preemption, meaning that if a pod using this priority class is scheduled but there aren't enough resources, it can evict (preempt) lower-priority pods to make space.
2. Never : This disables preemption, meaning that if there aren't enough resources, the pod will remain in a pending state instead of evicting lower-priority pods.
A static pod marked as critical can't be evicted. However, non-static pods marked as critical are always rescheduled.

DaemonSets in Kubernetes - The Silent Guardians of Your Cluster 🛡️

Laxman Patel — Wed, 01 Oct 2025 05:34:28 +0000

Kubernetes is a bustling ecosystem of pods, services, and deployments. But what about those tasks that need to run on every node in your cluster?

Enter DaemonSets—the unsung heroes of Kubernetes. In this article, we’ll explore what DaemonSets are, why they’re essential, and how to use them effectively.

� The Problem: Node-Level Tasks in Kubernetes

Imagine you need to:

Run a logging agent on every node.
Deploy a monitoring tool like Prometheus Node Exporter.
Ensure a security agent is always present on all nodes.

Using a regular Deployment or Pod won’t cut it because:

You can’t guarantee a pod will run on every node.
Scaling manually is tedious and error-prone.
New nodes won’t automatically get the required pods.

This is where DaemonSets come to the rescue.

🛠️ What Are DaemonSets?

A DaemonSet is a Kubernetes controller that ensures a copy of a pod runs on every node (or a subset of nodes) in your cluster. If a new node is added, the DaemonSet automatically schedules a pod on it. If a node is removed, the pod is garbage-collected.

Key features:

Node-Level Coverage: Runs a pod on every node (or specific nodes using labels).
Automatic Scaling: Scales with your cluster—no manual intervention needed.
Self-Healing: If a pod is deleted, the DaemonSet recreates it.
Resource Efficiency: Ensures only one pod runs per node (unless overridden).

🎯 Why Are DaemonSets Needed?

Node-Specific Tasks: Perfect for logging, monitoring, and security agents.
Cluster-Wide Consistency: Ensures every node has the required software.
Automatic Scaling: Handles node additions and removals seamlessly.
Resource Optimization: Avoids over-provisioning by running only one pod per node.

🛠️ How to Use DaemonSets

Let’s create a DaemonSet to deploy a logging agent on every node in your cluster.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logging-agent
  namespace: kube-system
  labels:
    app: logging-agent
spec:
  selector:
    matchLabels:
      name: logging-agent
  template:
    metadata:
      labels:
        name: logging-agent
    spec:
      containers:
      - name: logging-agent
        image: fluent/fluentd:latest
        resources:
          limits:
            memory: "200Mi"
            cpu: "100m"
          requests:
            memory: "100Mi"
            cpu: "50m"
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

selector: Matches the pods managed by this DaemonSet.
template: Defines the pod specification.
tolerations: Allows the DaemonSet to run on master nodes (optional).

Apply the DaemonSet:

kubectl apply -f daemonset.yaml

Now, a logging-agent pod will run on every node in your cluster. If you add or remove nodes, the DaemonSet will handle it automatically.

🧩 Advanced Use Cases

Node-Specific Workloads: Use node labels to run DaemonSets on specific nodes.

Example: Run a GPU monitoring tool only on GPU-enabled nodes.
Custom Taints and Tolerations: Control which nodes the DaemonSet can run on.
Rolling Updates: Update DaemonSet pods in a controlled manner using updateStrategy.

🎯 Key Takeaways

DaemonSets ensure a pod runs on every node in your cluster.
They’re perfect for node-specific tasks like logging, monitoring, and security.
They scale automatically with your cluster and handle node changes seamlessly.
Use them to maintain consistency and efficiency across your nodes.

So, the next time you need to run a pod on every node, think DaemonSets—your silent guardians in the Kubernetes world. 🛡️

LimitRange and Resource Quotas: Taming Kubernetes Resource Chaos 🚀

Laxman Patel — Wed, 01 Oct 2025 05:26:59 +0000

Kubernetes is a powerful orchestration tool, but with great power comes great responsibility. Imagine a scenario where one greedy pod consumes all the CPU and memory, leaving other pods starving. Or a namespace where resources are over-allocated, causing cluster-wide performance issues. Sounds like a nightmare, right? Enter LimitRange and ResourceQuota—Kubernetes' dynamic duo for resource management. In this article, we’ll dive into what they are, why they’re essential, and how to use them effectively.

� The Problem: Resource Anarchy in Kubernetes

In a Kubernetes cluster, multiple teams and applications share the same resources. Without proper governance, chaos ensues:

Resource Hogging: A single pod can monopolize CPU and memory, starving others.
Over-Provisioning: Developers might request excessive resources "just to be safe," leading to wasted capacity.
Under-Provisioning: Pods might not get enough resources, causing crashes or poor performance.
Namespace Sprawl: One namespace could consume all available resources, leaving nothing for others.

This is where LimitRange and ResourceQuota come to the rescue.

🛠️ What Are LimitRange and ResourceQuota?

1. LimitRange: Setting Boundaries for Pods and Containers

Think of LimitRange as a bouncer at a club. It enforces rules on how much CPU, memory, and storage each pod or container can request or use. It ensures that no single pod or container goes overboard.

Key features:

Sets minimum and maximum resource limits for CPU and memory.
Defines default requests and limits if not specified by the user.
Prevents resource starvation by ensuring fair usage.

2. ResourceQuota: Governing Namespace-Level Resources

While LimitRange focuses on individual pods, ResourceQuota operates at the namespace level. It’s like a budget manager for your Kubernetes namespace, ensuring that no single namespace consumes all the cluster resources.

Key features:

Limits the total amount of CPU, memory, and storage a namespace can use.
Controls the number of objects (pods, services, secrets, etc.) in a namespace.
Prevents resource exhaustion across the cluster.

� Why Are They Needed?

Fair Resource Allocation: Ensures that all applications get their fair share of resources.
Cost Optimization: Prevents over-provisioning, saving cloud costs.
Stability and Performance: Avoids resource contention, ensuring smooth cluster operations.
Multi-Tenancy: Enables safe sharing of clusters across teams or projects.
Compliance: Helps meet organizational policies and SLAs.

🛠️ How to Use LimitRange and ResourceQuota

1. LimitRange in Action

Let’s create a LimitRange to enforce resource constraints in a namespace.

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: my-namespace
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "256Mi"
    max:
      cpu: "1"
      memory: "1Gi"
    min:
      cpu: "50m"
      memory: "128Mi"

default: If no resource limits are specified, these values are applied.
defaultRequest: The minimum resources a container will request.
max and min: The upper and lower bounds for resource usage.

Apply the LimitRange:

kubectl apply -f limitrange.yaml

Now, any pod in the my-namespace namespace will be bound by these limits.

2. ResourceQuota in Action

Next, let’s create a ResourceQuota to limit the total resources in a namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: my-namespace
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "2Gi"
    limits.cpu: "4"
    limits.memory: "4Gi"
    pods: "10"
    services: "5"
    secrets: "10"

requests.cpu/memory: Total requested CPU and memory.
limits.cpu/memory: Total limit for CPU and memory.
pods/services/secrets: Limits the number of these objects in the namespace.

Apply the ResourceQuota:

kubectl apply -f resourcequota.yaml

Now, the my-namespace namespace is capped at the specified resource limits.

🧩 Combining LimitRange and ResourceQuota

When used together, LimitRange and ResourceQuota provide a robust resource management framework:

LimitRange ensures individual pods don’t exceed resource bounds.
ResourceQuota ensures the namespace as a whole stays within its budget.

For example, if a namespace has a ResourceQuota of 2 CPU and a LimitRange with a max CPU of 1 per pod, you can’t create more than 2 pods with the maximum CPU limit.

🚀 Real-World Use Case: Multi-Tenant Clusters

Imagine a SaaS platform where each customer gets a dedicated namespace. Without LimitRange and ResourceQuota, one customer’s misconfigured application could consume all cluster resources, affecting others. By enforcing resource limits and quotas, you ensure fair usage and isolate performance issues.

🎯 Key Takeaways

LimitRange enforces resource limits at the pod/container level.
ResourceQuota governs resource usage at the namespace level.
Together, they ensure fair resource allocation, cost optimization, and cluster stability.
Use them to tame resource chaos and build reliable, multi-tenant Kubernetes clusters.

Kubernetes Probes: The Secret to Self-Healing Applications 🚑

Laxman Patel — Wed, 01 Oct 2025 05:18:31 +0000

Imagine deploying an application in Kubernetes, only to find that some pods randomly stop working, others become unresponsive, and traffic still gets routed to a dead service. Nightmare, right? 😱 This is where Kubernetes Probes come to the rescue!

In this article, we'll explore why probes are essential, what happens if you don’t use them, and how you can leverage different types of probes—liveness, readiness, and startup probes—to make your applications more resilient and self-healing. We’ll also cover different ways to implement probes using HTTP, gRPC, TCP, and exec checks. By the end, you'll be a probe expert! 💡

🚀 Why Do We Need Probes in Kubernetes?

Kubernetes runs applications as containers, but unlike traditional applications, containers don’t always behave predictably. They might:

Crash unexpectedly (due to memory leaks, panics, etc.).
Become unresponsive while still running.
Take too long to start due to heavy initialization tasks.

Without probes, Kubernetes has no idea whether your application is healthy or not! As a result, it may keep sending traffic to a broken pod or fail to restart a crashed application.

What Happens If We Don’t Use Probes?

🚨 Scenario 1: A Dead Application Still Gets Traffic

A web server crashes but remains in a "running" state.
Kubernetes still routes traffic to it, causing users to get errors.
Customers get frustrated, and you lose business. 😭

🚨 Scenario 2: A Slow-Starting App Gets Killed Prematurely

Your application takes 60 seconds to initialize.
Kubernetes thinks it’s dead and restarts it over and over.
Your app never becomes available, even though it was working fine! 🙃

🚨 Scenario 3: A Pod Crashes but Never Gets Restarted

Your backend service crashes due to a memory leak.
Kubernetes doesn’t detect it and never restarts it.
The entire system slowly fails because of one bad pod. 🔥

🛠️ Types of Kubernetes Probes

Kubernetes provides three types of probes to prevent these issues:

Probe Type	Failure Action
Liveness Probe	Kubelet restarts the container if the probe fails.
Readiness Probe	Kubelet removes the pod from the service endpoint (no traffic sent to it).
Startup Probe	If the probe fails, the pod is killed and restarted.

🕵️‍♂️ Exploring Different Probe Methods

Kubernetes offers multiple ways to check container health:

1️⃣ HTTP Probe - Ideal for Web Applications 🌍

Use Case: Check if a web server is responding.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5 ------------> the wait period before kubelet starts checking
  periodSeconds: 10 -----------------> kubelet checks again after 10sec period
  failureThreshold: 3 ---------------> kubelet restarts container after 3 consecutive failure

✅ Kubernetes sends an HTTP request to /healthz. If the response is 200 OK, the pod is healthy. If not, Kubernetes restarts it.

2️⃣ gRPC Probe - Perfect for Microservices 🔗

Use Case: Check if a gRPC service is alive.

livenessProbe:
  grpc:
    port: 50051
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

✅ Kubernetes makes a gRPC health check request. If the service responds, it's considered healthy. If not, it's restarted.

3️⃣ TCP Probe - Great for Databases and TCP-Based Services 📡

Use Case: Check if a database (e.g., PostgreSQL) is accepting connections.

livenessProbe:
  tcpSocket:
    port: 5432
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

✅ Kubernetes tries to establish a TCP connection. If successful, the pod is healthy. If it fails, Kubernetes restarts the container.

4️⃣ Exec Probe - Custom Commands for Complex Applications 🛠️

Use Case: Run a script inside the container to verify health.

livenessProbe:
  exec:
    command:
      - cat
      - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

✅ Kubernetes executes a command inside the container. If the command runs successfully (exit code 0), the pod is healthy. Otherwise, Kubernetes restarts it.

💡
The Kubelet communicates with the container runtime (e.g., Docker, containerd, CRI-O) to execute probe commands inside containers. If the probe fails, Kubelet instructs the runtime to restart or remove the pod from service.

🏆 Best Practices for Using Probes

✅ Use Readiness Probes for External Dependencies

If your service depends on a database, only mark it as ready after it establishes a DB connection.

✅ Use Startup Probes for Slow-Starting Apps

If your application initializes slowly, a startup probe prevents it from getting restarted too early.

✅ Set Reasonable Probe Timeouts

Don’t check too frequently—this can cause unnecessary restarts.

✅ Always Test Your Probes

Deploy your application and ensure the probes behave as expected.

🎯 Conclusion

Kubernetes Probes are a powerful feature that makes your applications more resilient, self-healing, and production-ready. Without them, you risk serving broken services to users, premature restarts, or complete application failure.

By using liveness, readiness, and startup probes, combined with HTTP, gRPC, TCP, or exec methods, you can ensure your Kubernetes workloads stay healthy and responsive. 🚀

RBAC in Kubernetes: Understanding Roles, and RoleBindings 🔐

Laxman Patel — Wed, 01 Oct 2025 05:02:08 +0000

Kubernetes is a powerful platform for managing containerized applications, but with great power comes the need for granular access control.

Enter Role-Based Access Control (RBAC)—a security mechanism that allows you to define who can do what in your cluster. In this article, we’ll dive into Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings, explore their different combinations, and explain why ClusterRole with RoleBinding is possible but not the other way around.

� The Problem: Managing Access in Kubernetes

In a Kubernetes cluster, you might have:

Developers who need access to specific namespaces.
Admins who require cluster-wide privileges.
CI/CD tools that need limited permissions to deploy applications.

Without proper access control:

Users or services might have more permissions than they need, leading to security risks.
It’s difficult to enforce the principle of least privilege.
Auditing and compliance become challenging.

This is where RBAC comes into play.

🛠️ What Are Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings?

1. Role: Namespace-Specific Permissions

A Role defines a set of permissions (e.g., get, list, create) for resources within a specific namespace.

Example Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

2. RoleBinding: Granting Roles to Users or Groups

A RoleBinding binds a Role to a user, group, or service account within a specific namespace.

Example RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: pod-reader-binding
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

3. ClusterRole: Cluster-Wide Permissions

A ClusterRole defines permissions for resources across the entire cluster (including non-namespaced resources like Nodes or PersistentVolumes).

Example ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

4. ClusterRoleBinding: Granting ClusterRoles to Users or Groups

A ClusterRoleBinding binds a ClusterRole to a user, group, or service account across the entire cluster.

Example ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

🧩 Different Combinations of Roles and Bindings

Role Type	Binding Type	Scope	Use Case
Role	RoleBinding	Namespace-specific	Granting access to resources within a specific namespace (e.g., dev team).
ClusterRole	RoleBinding	Namespace-specific	Granting cluster-wide permissions but limiting them to a specific namespace.
ClusterRole	ClusterRoleBinding	Cluster-wide	Granting cluster-wide permissions (e.g., cluster admins).
Role	ClusterRoleBinding	Not Allowed	Roles are namespace-specific and cannot be bound cluster-wide.

🚀 Why ClusterRole with RoleBinding is Possible (But Not the Other Way Around)

1. ClusterRole with RoleBinding

A ClusterRole can be bound to a RoleBinding within a specific namespace. This allows you to:

Define cluster-wide permissions (e.g., for a set of resources).
Apply those permissions only to a specific namespace.

Example: A ClusterRole for managing Pods across the cluster can be bound to a RoleBinding in the default namespace, granting Pod management permissions only in that namespace.

2. Role with ClusterRoleBinding is Not Allowed

A Role is namespace-scoped, meaning it only applies to resources within a specific namespace. Binding it to a ClusterRoleBinding (which is cluster-wide) would create ambiguity:

Which namespace should the Role apply to?
How should the Role’s permissions be enforced across the cluster?

This is why Kubernetes does not allow this combination.

🎯 When to Use Each Combination

Role + RoleBinding:

Use for namespace-specific access (e.g., granting a developer access to the dev namespace).
ClusterRole + RoleBinding:

Use for namespace-specific access with cluster-wide permissions (e.g., granting a CI/CD tool access to Deployments in the staging namespace).
ClusterRole + ClusterRoleBinding:

Use for cluster-wide access (e.g., granting cluster admin privileges).

📚 Best Practices

Principle of Least Privilege: Grant only the permissions users or services need.
Use Namespaces: Isolate resources and permissions using namespaces.
Audit Regularly: Review Roles, ClusterRoles, and their bindings periodically.
Avoid Wildcards: Be specific with permissions (e.g., avoid verbs: ["*"] unless absolutely necessary).

ConfigMaps and Secrets: Managing Configuration and Sensitive Data in Kubernetes 🔐

Laxman Patel — Wed, 01 Oct 2025 03:22:00 +0000

Kubernetes is all about running applications at scale, but how do you manage configuration data and sensitive information like passwords or API keys?

Enter ConfigMaps and Secrets—two powerful tools that help you decouple configuration and sensitive data from your application code. In this article, we’ll explore what ConfigMaps and Secrets are, how they work, when to use each, and how to use them effectively in your Kubernetes clusters.

� The Problem: Configuration and Sensitive Data in Kubernetes

When deploying applications, you often need to:

Configure application settings like environment variables, configuration files, or command-line arguments.
Manage sensitive data like passwords, API keys, or TLS certificates.

Hardcoding these values into your application or container images is a bad idea because:

It makes your application inflexible and environment-specific.
It exposes sensitive data, creating security risks.
It requires rebuilding and redeploying your application for every configuration change.

This is where ConfigMaps and Secrets come into play.

🛠️ What Are ConfigMaps and Secrets?

1. ConfigMaps: Managing Non-Sensitive Configuration Data

A ConfigMap is a Kubernetes object that stores non-sensitive configuration data in key-value pairs. It allows you to decouple configuration from your application code, making your application more portable and easier to manage.

Key features:

Stores configuration data as key-value pairs or files.
Can be injected into pods as environment variables or configuration files.
Ideal for non-sensitive data like environment settings, URLs, or feature flags.

2. Secrets: Managing Sensitive Data

A Secret is a Kubernetes object designed to store sensitive information like passwords, API keys, or TLS certificates. Secrets are similar to ConfigMaps but are specifically designed for sensitive data.

Key features:

Stores sensitive data as key-value pairs or files.
Data is base64-encoded (not encrypted by default).
Can be injected into pods as environment variables or mounted files.
Ideal for sensitive data like database credentials, OAuth tokens, or TLS certificates.

🎯 When to Use ConfigMaps vs. Secrets

Use Case	ConfigMap	Secret
Environment Variables	Non-sensitive data (e.g., app settings)	Sensitive data (e.g., database passwords)
Configuration Files	Non-sensitive config files	Sensitive config files (e.g., TLS certs)
Command-Line Arguments	Non-sensitive arguments	Sensitive arguments
Data Encoding	Plain text	Base64-encoded
Security	Not secure	More secure (but not encrypted by default)

🛠️ How to Use ConfigMaps and Secrets

1. Creating a ConfigMap

Let’s create a ConfigMap to store non-sensitive configuration data.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  APP_COLOR: blue
  APP_ENV: production
  config.json: |
    {
      "logLevel": "debug",
      "timeout": "30s"
    }

data: Stores key-value pairs or files.
APP_COLOR and APP_ENV: Simple key-value pairs.
config.json: A configuration file stored as a multi-line string.

Apply the ConfigMap:

kubectl apply -f configmap.yaml

2. Creating a Secret

Now, let’s create a Secret to store sensitive data.

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
  namespace: default
type: Opaque
data:
  DB_USERNAME: dXNlcm5hbWU=  # base64-encoded "username"
  DB_PASSWORD: cGFzc3dvcmQ=  # base64-encoded "password"

data: Stores base64-encoded key-value pairs.
type: Opaque: The default type for generic secrets.

Apply the Secret:

kubectl apply -f secret.yaml

🧩 Injecting ConfigMaps and Secrets into Pods

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app-container
    image: busybox:latest
    command: [ "/bin/sh", "-c", "env" ]
    # Method 1: Injecting ConfigMap and Secret data as environment variables [2]
    env:
    - name: APP_COLOR
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_COLOR
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_ENV
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: DB_USERNAME
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: DB_PASSWORD
    # Method 2: Mounting ConfigMap and Secret as Volumes [2]
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
    - name: secret-volume
      mountPath: /etc/secrets
  volumes:
  - name: config-volume
    configMap:
      name: app-config
  - name: secret-volume
    secret:
      secretName: app-secret

🚀 Real-World Use Cases

ConfigMaps:

Storing environment-specific configurations (e.g., dev, staging, prod).
Managing feature flags or application settings.

Secrets:

Storing database credentials or API keys.
Managing TLS certificates for HTTPS.

📚 Best Practices

Use ConfigMaps for Non-Sensitive Data: Avoid storing sensitive information in ConfigMaps.
Use Secrets for Sensitive Data: Always use Secrets for sensitive information, and consider enabling encryption at rest for added security.
Avoid Hardcoding: Never hardcode configuration or sensitive data in your application code or container images.
Use Namespaces: Isolate ConfigMaps and Secrets using namespaces for better organization and security.

� Key Takeaways

ConfigMaps are for non-sensitive configuration data.
Secrets are for sensitive information like passwords and API keys.
Both can be injected into pods as environment variables or mounted files.
Use them to decouple configuration and sensitive data from your application code.

By leveraging ConfigMaps and Secrets, you can build more portable, secure, and maintainable applications in Kubernetes. 🚀

The Offset Reset Dilemma: Avoiding Surprise Replays in Kafka

Laxman Patel — Thu, 18 Sep 2025 06:43:23 +0000

A consumer needs an offset (a bookmark) to know where to start reading from a partition. Normally:

Kafka stores the last committed offset in _consumer_offsets. When you restart a consumer, it resumes from that committed offset.

But… what if there is no valid offset for a partition?
That’s where auto.offset.reset kicks in.

🚨 When Does “no valid offset” Happen?

New consumer group (first time this group subscribes to a topic → no committed offsets exist yet).
Offsets got deleted (Kafka has a retention policy for committed offsets — e.g., offsets.retention.minutes).
Offset is invalid (maybe pointing to data that was deleted due to log retention).

⚙️ auto.offset.reset Options

1. earliest

Start reading from the beginning of the log (smallest available offset).
Consumer will replay all historical data.
Good for batch jobs, data pipelines, or when you really want everything (e.g., reindexing a search database).

2. latest

Start reading from the end of the log (largest offset).
Consumer ignores past data → only gets new messages arriving after it joined.
Good for real-time dashboards or monitoring, where you don’t care about history.

📌 Why is this Important?

If you forget this setting, you can accidentally replay millions of messages when you didn’t intend to.
Conversely, you might miss data if you start from latest in a system that needs history.

How Data is Stored in Kafka: JSON vs Avro Explained

Laxman Patel — Wed, 17 Sep 2025 07:13:40 +0000

If you’re new to Kafka, you’ve probably asked yourself:

“When a producer sends a record, what does Kafka actually store on disk? Is it JSON? Avro? Hex? Bytes??”

I recently went down this rabbit hole myself — so here’s a breakdown of what really happens behind the scenes.

First Principles: Kafka Stores Bytes

Let’s clear the air first:

Kafka doesn’t know or care about JSON, Avro, Protobuf, POJOs, or unicorns 🦄. It only deals in byte arrays (byte[]).

Producer sends: byte[] key, byte[] value
Broker writes to log: byte[]
Consumer reads: byte[]

Everything else (JSON, Avro, Protobuf, String) is just a serialization format layered on top.

Serialization vs Encoding

Two words that get thrown around a lot:

Serialization = turning an in-memory object (like a Java POJO) into a storable/transmittable format.
Encoding = mapping characters into bytes (e.g., UTF-8 for text).

👉 JSON uses both. Avro is pure serialization.

How is data actually stored

Case 1: JSON in Kafka

Imagine a Java POJO: User{name="Lucky", age=30}

Steps

Serialize to JSON string

{
"name":"Lucky",
"age":30
}

Encode string in UTF-8 → bytes

[0x7B, 0x22, 0x6E, 0x61, ...]

(In hex: 7B 22 6E 61 6D 65 22 3A 22 4C )

Producer sends the above byte[] to Kafka.
Kafka stores raw bytes in its log

When you xxd the Kafka log file, you’ll see that hex dump.

👉️ Takeaway

JSON → text → UTF-8 encoding → bytes → Kafka.
It’s human-readable but bulky and slower to parse.

Case 2: Avro in Kafka

Same POJO: User{name="Lucky", age=30}

Steps

Serialize directly to Avro binary format
- Field values are encoded as compact bytes following the Avro schema.
- Example output (simplified): [0x08, 0x4C, 0x75, 0x63, 0x6B, 0x79, 0x3C]
Producer sends byte[] to Kafka
Kafka stores raw bytes in its log

No intermediate “string” or UTF-8 step.

👉️ Takeaway

Avro → compact binary → bytes → Kafka.
It’s efficient, schema-driven, and faster to deserialize.

JSON vs Avro: Side-by-Side

Step	JSON	Avro
Serialization	POJO → JSON text	POJO → Avro binary
Encoding	UTF-8 needed (text → bytes)	Not needed (already binary)
Size	Larger (e.g., `{"name":"Lucky"}`)	Smaller, compact
Readability	Human-readable	Not human-readable
Schema enforcement	Optional	Strict (via Avro schema)

Wrap-Up

When people ask “Does Kafka store JSON or Avro?”, the real answer is:

👉 Neither. Kafka stores raw bytes.
👉 JSON/Avro/Protobuf are just contracts between producer and consumer.

So next time you see a Kafka hex dump like:

7B 22 6E 61 6D 65 22 3A 22 4C 75 63 6B 79 22 7D

…you’ll know: that’s just your data, encoded and serialized, resting in Kafka’s logs waiting for the next consumer.

How I Built a Python CLI for Blazing-Fast Crypto Exchange Price Notifications

Laxman Patel — Wed, 13 Aug 2025 14:07:02 +0000

We’ve all been there — staring at a price chart, switching tabs, doing other work… and boom — the market moves.
You come back, and it’s either a missed profit or an unnecessary loss.

That was me, multiple times, while trading on Delta Exchange. Delta Exchange offers a great trading experience but lacks real-time custom alerts for specific price points.

I knew I couldn’t sit and watch the chart all day.

I wanted a fast, resource-efficient, and reliable way to track prices and trigger alerts without constantly refreshing charts or relying on third-party apps.

Tech Stack Used

Python – Core programming language.
WebSocket – For real-time price streaming.
JSON – To store and manage alert configurations.
Plyer – For cross-platform desktop notifications.

Backend Logic

Here’s how the tool works under the hood:

Connect to Delta Exchange WebSocket feed to get real-time price data.
Compare latest price with stored alert conditions from a local JSON file.
Trigger an alert when the price crosses the target threshold.
Mark the alert as “triggered” so it’s not repeatedly fired.
Send notifications via:
- Desktop notification using Plyer.
- Email notification for remote alerts.

Why WebSocket Instead of REST API?

Initially, I considered using the REST API for fetching prices, but there were a few drawbacks:

REST is pull-based – I’d have to make repeated requests to get the latest price.
This leads to API rate limits and unnecessary network usage.
Even with short intervals, REST polling introduces latency in updates.

On the other hand, WebSocket:

Pushes data in real-time as soon as the price changes.
Reduces server load and network calls.
Ensures alerts trigger instantly without delays.

For a price alert system, real-time updates are critical — so WebSocket was the obvious choice.

Sample Output

Future Developments

While the CLI works perfectly for my needs, I plan to:

Containerize the application with Docker for easy deployment.
Create a web-based UI for broader accessibility and a better user experience.

If you trade on Delta Exchange (or any platform without great alerting), I highly recommend building something like this. It’s not just about automation — it’s about peace of mind.

Checkout my project repo on GitHub

🚀 How I Hosted a Website Locally Using NGINX + Cloudflare Tunnel + Custom Domain

Laxman Patel — Thu, 31 Jul 2025 13:16:53 +0000

Two days ago, I bought a .cfd domain for ₹89 on impulse. I didn’t have a hosting plan. No VPS. No static IP. No plan, really.

But I did have one goal:

👉 "Can I host a secure, public-facing website straight from my local machine... without exposing my IP or touching router configs?"

Turns out, yes. Yes, I can. Here's how — and more importantly, why I did it this way.

🧠 The Problem Space

I wanted:

To run a simple NGINX-powered static site
No monthly hosting bills
HTTPS (because insecure URLs scream "hobby project")
And ideally, a solution that "just works" — no duct tape

But I didn’t have:

A static IP
Control over my ISP’s router for port forwarding
Budget for VPS hosting

🧪 My First Thought: Ngrok?

Of course, I thought of Ngrok. It's the OG local tunnel tool. Dead simple. Plug and play.

But there were issues:

Free version rotates URLs — not great for a custom domain
Their custom domain support is behind a paid plan
Limited concurrent tunnels

I needed more control. I wanted my domain to point to my machine — directly and reliably.

☁️ Enter: Cloudflare Tunnel

I was already using Cloudflare for DNS, so I dug deeper and found cloudflared.

This tool lets you:

Expose your local server to the internet securely
Use your own domain name
Terminate HTTPS at the edge (no messing with certs)
Skip firewall config, port forwarding, and NAT struggles

And it’s 100% free.

🛠️ The Stack I Used

What	Tool Used	Why I Picked It	Alternatives Considered
Domain	`.cfd` from Hostinger	Cheap (₹89) + DNS manageable	Namecheap
Web Server	NGINX on Ubuntu	Lightweight, battle-tested	Apache, Caddy
Tunnel	`cloudflared` (FIPS)	Secure, free, native domain support	Ngrok, LocalTunnel
DNS Provider	Cloudflare	Fast, robust, full control	GoDaddy, Namecheap

🔧 How I Did It (The Short Version)

Bought the domain: goobara.cfd (because why not?)
Pointed its NS records to Cloudflare
Waited ~2 hours for DNS propagation (it will test your patience)
Installed cloudflared
Created and configured a tunnel

   cloudflared tunnel create goobara
   cloudflared tunnel route dns goobara goobara.cfd
   cloudflared tunnel run goobara

6.Set up NGINX to serve localhost:80
7.Boom — goobara.cfd was live!

🧠 A Few "Aha!" Moments

curl -H "Host: goobara.cfd" http://localhost became my best friend.
My site didn’t work initially — turns out, I hadn’t removed Hostinger's default DNS records (rookie mistake).
Even though cloudflared showed success, DNS propagation + caching can cause confusion. Always verify with:dig goobara.cfd +short

💡 Why This Setup Rocks

No need for public IP
No Certbot / Let's Encrypt headaches
Minimal attack surface (everything is proxied through Cloudflare)
Zero cost hosting for hobby projects, dashboards, or even staging apps