DEV Community: Babji-Sheik

What happens when your cluster runs out of CPU? — The unsolved DevOps paradox

Babji-Sheik — Tue, 11 Nov 2025 19:18:29 +0000

🧩 What happens when your cluster runs out of CPU? — The unsolved DevOps paradox

We often define our Kubernetes pods with CPU requests, limits, and autoscaling policies.

The cluster scales pods up and down automatically — until one day, the cluster itself runs out of capacity. 😅

That’s when I started wondering:

💭 If the cluster’s total CPU resources hit the ceiling — what’s really the right move?

Should we just offload the pain to a managed cloud provider like AWS EKS or GKE and “dust our hands off”?
Or should we design our own autoscaling layer for the nodes and manage scale at the infrastructure level manually?
Is there a better middle ground where we balance cost, control, and elasticity?

It’s easy to autoscale pods, but not so easy to autoscale infrastructure.

And at large scale, this becomes a real DevOps riddle — one that teams still debate every day.

🧠 The Thought Behind It

Kubernetes gives us Horizontal Pod Autoscalers (HPA), and cloud providers give us Cluster Autoscalers — but how do we decide which strategy wins in the long run?

When CPU usage spikes across all nodes:

Pods start pending 💤
Scheduler runs out of available CPU slots
Costs skyrocket if we naïvely scale nodes
And custom workloads might need preemption or priority rules

🔍 The Question

If your cluster maxes out its CPU, what’s the smartest and most sustainable scaling strategy — and why?

Rely on cloud-managed autoscaling (e.g. GKE, EKS, AKS)?
Build your own cluster-level autoscaler?
Or do something totally new (like hybrid bursting, edge + cloud orchestration)?

🧩 My Take

There’s no single right answer — that’s why I’m calling it a DevOps Millennium Problem.

It’s where operations meets mathematics:

balancing resources, latency, and cost in an infinite scaling loop.

So what do you think?

If you hit 100% CPU cluster-wide — what’s your next move?

Deploying a Node.js App on Kubernetes with Minikube

Babji-Sheik — Tue, 11 Nov 2025 19:13:32 +0000

published: true
description: "From Docker to Kubernetes — how I built, deployed, debugged, and verified a Node.js app locally using Minikube on Windows. A full hands-on DevOps learning experience."
tags: ["devops", "kubernetes", "docker", "node", "git", "minikube", "windows"]

cover_image: "https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fq4x1xx7y9p8vyt3z8im.png"

🚀 My DevOps Journey: Node.js + Kubernetes (Minikube) on Windows

A personal hands-on walkthrough of Docker, Kubernetes, and Git — how I containerized and deployed a Node.js app locally using Minikube, explored versioning, debugging, and real DevOps workflows.

🌱 Why I Did This

I wanted to move beyond tutorials and actually build and debug something real with Kubernetes.

So I set up Minikube on Windows, deployed a Node.js web app, managed Docker containers, and learned how everything connects — from YAML to running pods.

This project became a deep dive into how DevOps engineers really work.

🧩 Project Overview

Here’s what I built and tested:

🐳 Containerized a Node.js app using Docker
☸️ Deployed it inside Kubernetes (Minikube) cluster
🔗 Exposed the app externally using NodePort
🧪 Verified version metadata (version.json) like in real CI pipelines
🧰 Managed everything using Git + PowerShell on Windows 11 Home

⚙️ Tools I Used

Category	Tools & Versions
OS	Windows 11 Home
Runtime	Node.js (LTS)
Containers	Docker
Cluster	Kubernetes (Minikube v1.37.0)
Base Image	kicbase:v0.0.48
Version Control	Git + GitHub
Testing	Go (iso_test.go concept)

🧱 Step 1: Setting up Minikube

I started my cluster using Docker as a driver:

minikube start

Minikube downloaded the base image (kicbase:v0.0.48) and booted a control-plane node.

Everything ran on Windows Home — no Hyper-V needed.

🐳 Step 2: Dockerize the Node.js App

I wrote a simple Node.js server (app.js):

const http = require("http");
const PORT = 3000;
const server = http.createServer((req, res) => {
  res.end("Hello from Node.js running inside Kubernetes!");
});
server.listen(PORT, () => console.log(`Server running on port ${PORT}`));

Then, I created a Dockerfile:

FROM node:18-alpine
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]

Built the image:

docker build -t node-k8s-demo .

☸️ Step 3: Deploy on Kubernetes

Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-k8s-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: node-k8s
  template:
    metadata:
      labels:
        app: node-k8s
    spec:
      containers:
      - name: node-k8s
        image: node-k8s-demo
        ports:
        - containerPort: 3000

Service YAML

apiVersion: v1
kind: Service
metadata:
  name: node-k8s-service
spec:
  type: NodePort
  selector:
    app: node-k8s
  ports:
  - port: 3000
    targetPort: 3000
    nodePort: 30080

Applied configs:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

🌐 Step 4: Expose and Access the App

Used Minikube to expose it externally:

minikube service node-k8s-service

✅ Output:

NAMESPACE │       NAME       │ TARGET PORT │            URL            
default   │ node-k8s-service │ 3000        │ http://192.168.49.2:30080

Then, visiting http://192.168.49.2:30080 opened my app 🎉

🧪 Step 5: Version Verification (ISO Test Concept)

From a real Minikube test example (iso_test.go):

{
  "iso_version": "v1.37.0-1758198818-20370",
  "kicbase_version": "v0.0.48",
  "minikube_version": "v1.37.0",
  "commit": "a4f96d0469d67330691be52a99ff1f91e31ba77f"
}

I learned how build metadata (ISO version, commit IDs) ensures consistency in CI/CD — just like in real production releases.

🔧 Step 6: Debugging, Logs & Restarts

Things didn’t always go perfectly.

Sometimes the tunnel didn’t start → fixed by restarting Minikube
Verified pods using kubectl get pods
Checked logs with kubectl logs <pod>
Cleaned up with kubectl delete -f <file>

This taught me real DevOps problem-solving, not just running commands.

🧾 Step 7: Git & Documentation

I documented everything in Git and GitHub:

git init
git add .
git commit -m "Node.js Kubernetes demo setup"
git branch -M main
git remote add origin https://github.com/<your-username>/<repo>.git
git push -u origin main

Also added .gitignore and this detailed README.md (you’re reading the same content now 😉).

💡 What I Learned

Kubernetes architecture & Minikube internals
Docker image creation & reusability
YAML configuration & rolling updates
Exposing services via NodePort
Debugging tunnels and IP routing
CI version validation (version.json check)
Proper Git commits and repo structuring
Documenting DevOps work cleanly

📚 Full Stack of What I Explored

✅ Minikube lifecycle

✅ Docker build, run, inspect

✅ Kubernetes Deployments & Services

✅ NodePort & local networking

✅ ISO versioning and metadata validation

✅ Windows compatibility handling

✅ Git workflows

✅ Debugging tunnels and pods

✅ CI/CD thinking & test verification

🧠 Final Thoughts

This wasn’t just a “Minikube tutorial.”

It was my complete DevOps learning journey — from writing code to deploying and validating it inside a Kubernetes cluster, all on Windows.

I learned that real DevOps is not about memorizing commands — it’s about understanding how every piece connects.

🧑‍💻 Author

If you found this post helpful, drop a ❤️ or comment your Minikube experience!

Why Secure Messaging Matters: From Packets to Private Keys

Babji-Sheik — Sun, 13 Jul 2025 21:54:58 +0000

In an age where every thought, plan, and joke we share zips through countless routers and servers, it’s critical to understand why end-to-end encryption isn’t just “nice to have” — it’s a necessity.

Messaging and Its Importance
Whether you’re coordinating a product launch, sharing family photos, or trading secrets, messaging underpins all modern collaboration. It’s the lifeblood of teams, communities, and relationships.
The Inevitability of Connecting to the Internet
Today, everyone and everything is online: smartphones, IoT sensors, laptops, even fridges. Our global appetite for connectivity means messaging systems must be robust, reliable, and—most importantly—secure.
TCP/IP, Packet Exchanges, and the Internet Path
Every message you send is chopped into packets that traverse TCP/IP networks, hop between Internet Exchange Points (IXPs), and finally reach your recipient’s ISP.

Packets can be routed through dozens of autonomous networks.

Every hop is a potential eavesdrop point if data isn’t encrypted.

A Secure System with WebSockets We use WebSockets to maintain a persistent, bidirectional channel between client and server. This lets us:

Push messages instantly

Detect lost connections and re-establish them

Layer encryption directly on the socket without extra HTTP overhead

Lightweight, Customized Code Bloat kills performance and widens the attack surface. Our entire stack is:

Slim—just the essentials for messaging

Tailored—no generic libraries, only custom-audited crypto

Fast—low latency even on mobile networks

Secure Communication from End to End
With zero-knowledge servers, your plaintext never touches our infrastructure. We only see ciphertext—garbage without the keys.
Why Elliptic Curve Ed25519?
Performance: Extremely fast signing and verification

Security: 128-bit security level, resistant to known attacks

Key Size: Small public/private keys make mobile sync trivial
Ed25519 is the gold standard for modern public-key crypto.

Lessons from Alan Turing’s Enigma Turing broke the Enigma by exploiting implementation flaws. We learned:

“A cipher is only as strong as its weakest link.”
That’s why our key generation, exchange, and management follow battle-tested best practices—no manual rotors here.

Not Even “God” Can Decode Without Your Private Key
Without your private key, decryption is mathematically impossible. There are no backdoors, no “master keys,” and no secret exemptions—only your device holds the power to read your messages.
The Case for Personal Communication Platforms
Companies owe it to their users—and themselves—to own their communication stack:

Privacy by design instead of retrofitted security

Full control over data flows and retention policies

Trust that no third party can intercept or monetize your chats

Bottom line: In a world wired end-to-end, your messages deserve bulletproof protection. That’s why our chat system embraces WebSockets, Ed25519, zero-knowledge servers, and a lightweight custom codebase. Because real privacy isn’t an option—it’s the only standard that matters.

Just a food for thought.

🧨 Tailwind CSS Install Nightmare: “npx error could not determine executable to run”

Babji-Sheik — Tue, 22 Apr 2025 05:58:17 +0000

Going through this, I will let you know when I have the fix
;-)