Forem: Shivam Kumar

Kube-Proxy and CNI: The Backbone of Kubernetes Networking

Shivam Kumar — Sat, 03 Jan 2026 18:55:33 +0000

Kubernetes networking looks simple — every Pod gets an IP, and Services route traffic automatically.

Behind this simplicity are two core components that make everything work: CNI and kube-proxy.

Kube-Proxy

Kube-Proxy is a network proxy that runs on each node in the cluster. When a service is created, it sets up the necessary network rules to route incoming requests to one of the pods backing the service. This can involve IP tables, IPVS (IP Virtual Server), or other networking mechanisms depending on the configuration.

The major work of Kube-Proxy internally involves tasks like-

Kube Proxy makes services to actually route by handling routing to the pods.
Kube Proxy maintains the Service IP behaves like a stable endpoint, even the Pods are ephemeral. Kube-proxy translates the Service IP to a Pod IP using iptables or IPVS rules.
When a new service or endpoint is created, Kube Proxy sets up routing rules on the node. If a pod backing the service is deleted or a new pod is added, Kube-proxy updates the rules to maintain the service’s availability.
Kube-Proxy enables service-level traffic distribution by kernel networking rules (iptables or IPVS), allowing traffic sent to a Service IP to be forwarded to one of the backing Pods.
Without kube-proxy, Service IPs would exist but would not route traffic to Pods. kube-proxy wires Service IPs and ports to actual Pod endpoints.

Container Network Interface (CNI)

In Kubernetes, CNI is the standard way to provide networking to pods. The main purpose of CNI is to allow different networking plugins to be used with container runtimes. This allows Kubernetes to be flexible and work with different networking solutions

Assigns a unique IP to each Pod so that it can communicate within the cluster.
It will create and configure the Pod's network interface veth pair, then attach it inside the node's network namespace.
It sets up routing rules so that Pods can communicate with other Pods across nodes.

PostgreSQL WAL: The Backbone of Reliable and Scalable Databases

Shivam Kumar — Sat, 11 Oct 2025 19:43:49 +0000

Ever wondered how PostgreSQL survives crashes without losing a byte of data?

Databases can crash, servers can fail, but losing data is not an option. PostgreSQL achieves this reliability with its WAL(write-ahead log) mechanism.

WAL records every changes before it's applied to the database, ensuring consistency and enabling quick recovery. It is the log of changes made to the database cluster which is replayed either as part of the database recovery process when a database isn’t shutdown correctly (such as when a crash occurs), or is used by standbys to replay the changes to replicate the database.

Working of WAL in 4 Steps-

Step 1: When a change (INSERT, UPDATE, DELETE) occurs, PostgreSQL writes it to the WAL first.
Step 2: Only after the WAL is safely written, the change is applied to the main database files.
Step 3: If the database crashes, PostgreSQL can replay the WAL to recover all committed changes.
Step 4: WAL ensures data consistency, durability, and quick crash recovery.

Experimenting with WAL

Check your PostgreSQL data directory
SHOW data_directory;
I installed it using brew so its /opt/homebrew/var/postgresql@14
Navigate to the WAL directory
cd /opt/homebrew/var/postgresql@14/pg_wal

In pg_wal, files like 000000010000000000000001 are binary WAL segments that record all database changes before they are applied. The archive_status folder shows which WAL files are ready to be saved or backed up.

Get connected to your postgresql and run simple queries to create table and insert some data in it.

CREATE TABLE wal_demo (
    id SERIAL PRIMARY KEY,
    name TEXT
);

INSERT INTO wal_demo(name) VALUES ('Shivam'), ('PostgreSQL'), ('WAL TEST');

Watch live WAL logs in a separate terminal:
watch -n 1 "pg_waldump 000000010000000000000001 | tail -n 20"

The content is binary and not human-readable, but every query you run is logged in WAL, ensuring no data is lost if the database crashes.

Make WAL human-readable (Logical WAL)

To see the changes in WAL into Readable format we would need to make some changes. From your path /opt/homebrew/var/postgresql@14 we will change some content by nano postgresql.conf and then uncomment wal_level and make it to logical, restart your postgresql.
Now we will create a logical replication slot, its way to stream database modifications in a readable format instead of the raw binary WAL. Run the below query-
SELECT * FROM pg_create_logical_replication_slot('live_slot', 'test_decoding');

pg_create_logical_replication_slot is a PostgreSQL function that creates a logical replication slot.
live_slot is the name of replication.
test_decoding is built-in and outputs changes in a simple human-readable format.

Lets insert some data in our table created before.

INSERT INTO wal_demo(name) VALUES ('Shivam Live Test5');
INSERT INTO wal_demo(name) VALUES ('Shivam Live Test6');

We will now verify if we can see our changes in readable form or not using the command psql -U shivamkumar -d postgres -c "SELECT * FROM pg_logical_slot_get_changes('live_slot', NULL, NULL);"

You should now see the inserted rows in a readable format, confirming that WAL changes are being tracked and streamed successfully.

With WAL in action, PostgreSQL never misses a beat—your data is always safe and sound.

Creating custom kubernetes controller in Go

Shivam Kumar — Sat, 24 Aug 2024 23:25:39 +0000

Before Implementing custom controller in Go let's first understand what is Kubernetes Controller and Customer Resource Definition (CRD)

Kubernetes Controller

A Kubernetes Controller is component of control plane that continuously monitors state of kubernetes cluster and takes action to ensure that the actual state of cluster matches the desired state.It makes changes attempting to move current state closer to desired state.

Customer Resource Definition (CRD)

Custom Resource Definition (CRD) is a way to extend the Kubernetes API to create our own custom resources. These custom resources can represent any kind of object which we want to manage within our Kubernetes cluster.

Creating own Custom Resource Definition (CRD)

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: my-crds.com.shivam.kumar
spec:
  group: com.shivam.kumar
  names:
    kind: my-crd
    plural: my-crds
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            apiVersion:
              type: string
            kind:
              type: string
            metadata:
              type: object
            spec:
              type: object
              properties:
                description:
                  type: string

Apply this file using the kubectl command and when we see the available crds in our cluster we can see the crd which we created-

Creating Custom Resource (CR)

apiVersion: com.shivam.kumar/v1
kind: my-crd
metadata:
  name: my-custom-resource
spec:
  description: "My CRD instance"

Apply this file using the kubectl command

Now let's move on to create own custom controller

Creating custom kubernetes controller

package main

import (
    "context"
    "fmt"
    "path/filepath"

    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
    "k8s.io/apimachinery/pkg/runtime"
    "k8s.io/apimachinery/pkg/runtime/schema"
    "k8s.io/apimachinery/pkg/watch"
    "k8s.io/client-go/dynamic"
    "k8s.io/client-go/rest"
    "k8s.io/client-go/tools/cache"
    "k8s.io/client-go/tools/clientcmd"
    "k8s.io/client-go/util/homedir"
)

func main() {
    var kubeconfig string
    if home := homedir.HomeDir(); home != "" {
        kubeconfig = filepath.Join(home, ".kube", "config")
    }

    config, err := clientcmd.BuildConfigFromFlags("", kubeconfig)
    if err != nil {
        fmt.Println("Falling back to in-cluster config")
        config, err = rest.InClusterConfig()
        if err != nil {
            panic(err.Error())
        }
    }

    dynClient, err := dynamic.NewForConfig(config)
    if err != nil {
        panic(err.Error())
    }

    thefoothebar := schema.GroupVersionResource{Group: "com.shivam.kumar", Version: "v1", Resource: "my-crds"}

    informer := cache.NewSharedIndexInformer(
        &cache.ListWatch{
            ListFunc: func(options metav1.ListOptions) (runtime.Object, error) {
                return dynClient.Resource(thefoothebar).Namespace("").List(context.TODO(), options)
            },
            WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) {
                return dynClient.Resource(thefoothebar).Namespace("").Watch(context.TODO(), options)
            },
        },
        &unstructured.Unstructured{},
        0,
        cache.Indexers{},
    )

    informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
        AddFunc: func(obj interface{}) {
            fmt.Println("Add event detected:", obj)
        },
        UpdateFunc: func(oldObj, newObj interface{}) {
            fmt.Println("Update event detected:", newObj)
        },
        DeleteFunc: func(obj interface{}) {
            fmt.Println("Delete event detected:", obj)
        },
    })

    stop := make(chan struct{})
    defer close(stop)

    go informer.Run(stop)

    if !cache.WaitForCacheSync(stop, informer.HasSynced) {
        panic("Timeout waiting for cache sync")
    }

    fmt.Println("Custom Resource Controller started successfully")
    <-stop
}

Now when we build this Go Program and run it-
go build -o k8s-controller .
./k8s-controller

Now whenever we add, update or delete custom resource created above we get active logs of it in our terminal. so this means our controller is monitoring our CRD.