DEV Community: Madhav Nakra

Istio and the Sidecar Pattern: What I Learned About Service Mesh Fundamentals

Madhav Nakra — Mon, 27 Jul 2026 16:39:00 +0000

If you work with Kubernetes long enough, you eventually hit a wall that has nothing to do with your application code. Your services are deployed, your pods are healthy, but you still have no good answer to questions like: Is traffic between these two services encrypted? What happens if one service starts failing? Can I roll out a new version to just 10% of users without touching my app code?

That wall is exactly where a service mesh comes in, and it's what pushed me to spend some time this week going through istio-guide, a repository by Abhishek Veeramalla that walks through Istio fundamentals for DevOps engineers. Here's what I took away from it, structured the way it clicked for me rather than as a glossary.

The problem a service mesh is solving

In a monolith, calling another part of your system is a function call. In microservices, it's a network call, and network calls fail, get slow, and get intercepted. Every team ends up needing the same things: retries, timeouts, load balancing, encrypted traffic between services, and some way to see what's actually happening when something breaks.

You could build all of that into every service. Or you could push it into the infrastructure layer, so no application code has to change. That's the pitch of a service mesh: a dedicated layer that handles service-to-service communication, security, and observability, sitting underneath your application rather than inside it.

Sidecars: how the mesh gets into your pods

The mechanism that makes this possible is the sidecar pattern. A sidecar is just a second container running alongside your main application container in the same pod, sharing its network namespace. In Istio's case, that sidecar is an Envoy proxy, and every bit of traffic in and out of your application container gets routed through it first.

This is the part that reframed things for me: your application never talks to the network directly anymore. It talks to a proxy that happens to live right next to it. That proxy is what enforces encryption, applies traffic rules, and reports metrics, all without your code knowing the mesh exists.

Admission controllers: how the sidecar actually shows up

The natural next question is: who's adding this second container to my pod? I never wrote it into my deployment YAML.

That's where admission controllers come in. In Kubernetes, an admission controller sits between the API server and etcd, intercepting requests to create or modify objects before they're persisted, and it can either reject them or mutate them on the way through. Istio ships a mutating webhook that watches for new pods and injects the Envoy sidecar container into them automatically, as long as the namespace is labeled for injection.

Seeing this connection was honestly the most useful part of going through the repo. Admission controllers and sidecars are often taught as separate Kubernetes topics, but in Istio they're the same mechanism: the sidecar isn't magic, it's a mutating admission webhook doing its job at pod creation time.

mTLS: the payoff you get almost for free

Once every service has a proxy sitting in front of it, mutual TLS becomes a configuration problem instead of an engineering problem. With mTLS enabled, both sides of a connection present a certificate, so a service isn't just encrypting traffic, it's proving its identity to the service it's talking to. No certificate management inside application code, no library to bolt on. It's the sidecars handling the handshake on your service's behalf.

Traffic management: routing without touching deployments

This is where Istio moves from "nice security layer" to genuinely useful for day-to-day operations. Three pieces work together here:

VirtualServices define how requests to a service get routed, which is what makes canary releases and A/B testing possible without spinning up separate infrastructure.
DestinationRules define the policy for traffic once it's been routed to a specific version, things like load balancing algorithm and TLS settings.
Circuit breaking sets thresholds on error rate or latency, and once a service crosses them, the mesh stops sending it requests instead of letting failures cascade through the system.

None of these require changes to the services themselves. It's all configuration sitting at the mesh layer.

Gateways and observability

Gateways are how external traffic gets into the mesh in the first place, acting as the ingress and egress points between the outside world and everything running inside. And because every request already passes through an Envoy proxy, observability comes almost as a side effect: distributed tracing, metrics, and logging are available without instrumenting each service individually.

Service mesh vs. Ingress: a distinction worth being precise about

This one is easy to blur, so it's worth stating plainly. An Ingress controller manages traffic coming into the cluster from outside, things like SSL termination and HTTP routing at the edge. A service mesh operates one layer deeper, governing how services inside the cluster talk to each other. They solve different problems, and most real setups end up using both rather than treating them as alternatives.

What's next

The repo isn't just a README, it's got hands-on folders for admission controllers, install and setup, mTLS, and traffic management, so the next step for me is working through those labs directly instead of just reading. Concepts like circuit breaking and canary routing make a lot more sense once you've broken something on purpose and watched the mesh react.

If you're working with Kubernetes and haven't looked into service mesh concepts yet, I'd genuinely recommend starting with this repo. It doesn't try to cover every corner of Istio, it just gets the fundamentals straight, which turned out to be exactly what I needed.

Deploying a Dockerized Node.js Application on Kubernetes 🚀

Madhav Nakra — Tue, 09 Jun 2026 21:08:21 +0000

After containerizing an application with Docker, the next logical step is deploying it on Kubernetes.

Kubernetes helps automate application deployment, scaling, networking, and management of containerized workloads. Instead of manually running containers, Kubernetes ensures your application remains available and can easily scale when needed.

In this guide, we'll deploy a Docker image of a Node.js application on Kubernetes using a Deployment and a Service.

Prerequisites

Before starting, make sure you have:

Docker installed
Kubernetes cluster running (Docker Desktop Kubernetes, Minikube, Kind, EKS, etc.)
kubectl configured
A Docker image pushed to Docker Hub

In my case, the image was:

madhavnaks/node-app:latest

Why Kubernetes?

Running a container using Docker is straightforward:

docker run -p 3000:3000 madhavnaks/node-app:latest

However, in production environments we need much more than simply running a container.

Kubernetes provides:

High availability
Self-healing containers
Load balancing
Service discovery
Horizontal scaling
Rolling updates

This makes it the industry standard for container orchestration.

Understanding the Kubernetes Architecture for This Deployment

For this deployment, we'll use two Kubernetes resources:

Deployment

A Deployment is responsible for:

Creating Pods
Maintaining desired replica count
Recreating failed Pods automatically
Managing updates and rollbacks

Service

A Service provides a stable network endpoint for Pods.

Since Pod IPs change frequently, Services allow applications and users to communicate reliably with Pods.

Deployment and Service Manifest

Create a file named:

app.yaml

Add the following configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-app

spec:
  replicas: 2

  selector:
    matchLabels:
      app: node-app

  template:
    metadata:
      labels:
        app: node-app

    spec:
      containers:
        - name: node-app
          image: madhavnaks/node-app:latest

          ports:
            - containerPort: 3000

---

apiVersion: v1
kind: Service

metadata:
  name: node-app

spec:
  selector:
    app: node-app

  type: NodePort

  ports:
    - port: 123
      targetPort: 3000
      nodePort: 32000

Understanding the Deployment Configuration

Replica Count

replicas: 2

Kubernetes will maintain two running Pod instances of the application.

If one Pod crashes, Kubernetes automatically creates another one to maintain the desired state.

Docker Image

image: madhavnaks/node-app:latest

Kubernetes pulls the image directly from Docker Hub and uses it to create containers.

Container Port

containerPort: 3000

This specifies the port on which the Node.js application listens inside the container.

Understanding the Service Configuration

The Service exposes our Pods to network traffic.

Service Port

port: 123

This is the port exposed by the Kubernetes Service inside the cluster.

Target Port

targetPort: 3000

Traffic arriving at the Service is forwarded to port 3000 inside the container.

NodePort

nodePort: 32000

This exposes the application outside the cluster.

Requests reaching:

<Node-IP>:32000

are forwarded to:

Service Port → Target Port → Container

which means:

32000 → 123 → 3000

Deploying the Application

Apply the manifest:

kubectl apply -f complete.yaml

Expected output:

deployment.apps/node-app created
service/node-app created

Verify the Deployment

Check Deployments:

kubectl get deployments

Example output:

NAME       READY   UP-TO-DATE   AVAILABLE
node-app   2/2     2            2

Check Pods:

kubectl get pods

Example:

NAME                        READY   STATUS
node-app-xxxxx              1/1     Running
node-app-yyyyy              1/1     Running

Notice that Kubernetes created two Pods because we specified:

replicas: 2

Check Services:

kubectl get svc

Example:

NAME         TYPE       CLUSTER-IP      PORT(S)
node-app     NodePort   10.x.x.x        123:32000/TCP

Accessing the Application

To access the application:

http://localhost:32000

Or:

http://<Node-IP>:32000

depending on your Kubernetes setup.

The request flow looks like:

User
   │
   ▼
NodePort (32000)
   │
   ▼
Service Port (123)
   │
   ▼
Target Port (3000)
   │
   ▼
Node.js Container

Benefits of Using a Deployment

Deployments provide several production-grade capabilities:

Self-Healing

If a Pod crashes:

kubectl delete pod <pod-name>

Kubernetes automatically creates a replacement Pod.

Scaling

Increase replicas easily:

replicas: 5

Apply again:

kubectl apply -f complete.yaml

Kubernetes creates additional Pods automatically.

Rolling Updates

When a new Docker image version is pushed:

image: madhavnaks/node-app:v2

Applying the updated manifest performs a rolling update with minimal downtime.

Key Takeaways

✅ Deployments manage Pods automatically

✅ Replica count ensures high availability

✅ Services provide stable networking

✅ NodePort exposes applications outside the cluster

✅ Kubernetes continuously maintains the desired state of the application

Conclusion

Deploying a containerized application on Kubernetes is a major step toward building production-ready cloud-native applications.

Using a Deployment and Service, Kubernetes can automatically manage application availability, networking, scaling, and recovery without manual intervention.

Once you're comfortable with these fundamentals, the next topics to explore are ConfigMaps, Secrets, Ingress, Persistent Volumes, and Helm Charts.

Happy Learning and Happy Kubernetes! 🚀

From Dockerfile to Docker Hub: A Complete Beginner's Guide to Docker 🚀

Madhav Nakra — Tue, 02 Jun 2026 21:06:56 +0000

Containerization has become a fundamental skill for DevOps Engineers, Cloud Engineers, and Software Developers.

However, many beginners learn Docker commands without understanding the complete workflow behind them.

Questions like:

What exactly is a Docker Image?
How does a Dockerfile become a running Container?
Why do we push images to Docker Hub?
How do organizations deploy the same application everywhere?

are common when starting out.

In this blog, we'll build a simple Node.js application, containerize it using Docker, run it locally, and finally push the image to Docker Hub.

By the end of this guide, you'll understand the complete Docker workflow used in real-world DevOps environments.

Docker Workflow Overview

flowchart LR
    A[Application Code] --> B[Dockerfile]
    B --> C[Docker Build]
    C --> D[Docker Image]
    D --> E[Docker Run]
    E --> F[Docker Container]
    D --> G[Docker Push]
    G --> H[Docker Hub]

This is the same workflow followed by developers and DevOps teams worldwide.

What Are We Building?

We'll create a simple Node.js application that returns:

A welcome message
Environment information
Container hostname

This helps us verify that our application is actually running inside a Docker container.

Project Structure

.
├── Dockerfile
├── app.js
└── package.json

Step 1: Create the Node.js Application

app.js

const express = require("express");
const app = express();

const PORT = process.env.PORT || 3000;
const ENV = process.env.ENV_VALUE || "No env set";
const HOSTNAME = process.env.HOSTNAME || require("os").hostname();

app.get("/", (req, res) => {
  res.json({
    message: "Hello from Simple App (Node)",
    env: ENV,
    container: HOSTNAME
  });
});

app.listen(PORT, () =>
  console.log(`Node Hello listening on ${PORT}`)
);

package.json

{
  "name": "hello-app-node",
  "version": "1.0.0",
  "main": "app.js",
  "dependencies": {
    "express": "^5.2.1"
  }
}

Application Architecture

flowchart LR
    User --> Browser
    Browser --> Container
    Container --> NodeJS
    NodeJS --> JSONResponse

Whenever a user accesses the application, the request reaches the containerized Node.js application, which returns a JSON response.

Step 2: Create the Dockerfile

A Dockerfile is simply a blueprint that tells Docker how to build an image.

FROM node:24-slim

WORKDIR /app

COPY package*.json ./

RUN npm install --production

COPY . .

EXPOSE 3000

CMD ["node", "app.js"]

Understanding the Dockerfile

Base Image

FROM node:24-slim

We start with an official lightweight Node.js image from Docker Hub.

Working Directory

WORKDIR /app

Creates and switches to the /app directory inside the container.

Copy Dependency Files

COPY package*.json ./

Copies package files first.

This is considered a Docker best practice because Docker can cache dependency layers and speed up future builds.

Install Dependencies

RUN npm install --production

Installs only production dependencies.

Copy Application Source Code

COPY . .

Copies the entire project into the container.

Expose Application Port

EXPOSE 3000

Documents that the application listens on port 3000.

Start the Application

CMD ["node", "app.js"]

Runs the Node.js application when the container starts.

What Happens During Docker Build?

flowchart TD
    A[Dockerfile]
    --> B[Pull Node Base Image]
    --> C[Create Working Directory]
    --> D[Copy package.json]
    --> E[Install Dependencies]
    --> F[Copy Application Code]
    --> G[Create Image Layers]
    --> H[Docker Image Ready]

Docker executes each instruction sequentially and creates image layers.

Step 3: Build the Docker Image

Run:

docker build -t madhavnaks/node-app .

Let's understand this command:

docker build

Builds an image from a Dockerfile.

-t

Assigns a tag to the image.

madhavnaks/node-app

Image name.

Current directory containing the Dockerfile.

After a successful build you'll see output similar to:

=> naming to docker.io/madhavnaks/node-app

Docker has now created an image locally on your machine.

Step 4: Verify the Image

To see locally available images:

docker images

Example output:

REPOSITORY                TAG       IMAGE ID       SIZE
madhavnaks/node-app       latest    42c936686000   234MB

At this point, the image exists but is not running.

Docker Image vs Docker Container

Many beginners confuse these two concepts.

Think of it like this:

Docker Image = Blueprint
Docker Container = Running Application

flowchart LR
    A[Docker Image]
    --> B[Container 1]

    A --> C[Container 2]

    A --> D[Container 3]

A single image can create multiple containers.

Step 5: Run a Container

Now let's start our application.

docker run -d --name node-app -p 3001:3000 madhavnaks/node-app

Understanding the Command

Detached Mode

-d

Runs the container in the background.

Container Name

--name node-app

Assigns a friendly name to the container.

Port Mapping

-p 3001:3000

Maps:

Host Port      → Container Port
3001           → 3000

The application listens on port 3000 inside the container but is accessible on port 3001 from your machine.

Step 6: Verify the Container

Check running containers:

docker ps

Expected output:

CONTAINER ID   IMAGE                 STATUS
10265698c978   madhavnaks/node-app   Up

Step 7: Access the Application

Open:

http://localhost:3001

Expected response:

{
  "message": "Hello from Simple App (Node)",
  "env": "No env set",
  "container": "10265698c978"
}

Notice the hostname.

The hostname corresponds to the container ID, proving the application is running inside Docker.

Step 8: Login to Docker Hub

Before pushing images, authenticate with Docker Hub.

docker login

Example:

Login Succeeded

Docker is now authorized to push images to your repository.

Why Push Images to Docker Hub?

Docker Hub acts as a centralized registry.

flowchart LR
    A[Developer Machine]
    -->|Push| B[Docker Hub]

    B -->|Pull| C[Server]

    B -->|Pull| D[Kubernetes Cluster]

Once an image is pushed, it can be pulled and run from anywhere.

Step 9: Push the Image

Push the image to Docker Hub:

docker push madhavnaks/node-app

Example output:

latest: digest: sha256:d1081ec542f521e100bd886943c13ab7568c663b56e36200e6d846163975f979

This confirms that the image has been successfully uploaded.

Step 10: Verify on Docker Hub

Visit your Docker Hub account.

You should now see:

madhavnaks/node-app

listed under repositories.

You can even share the image with others.

Anyone can now run:

docker pull madhavnaks/node-app

docker run -p 3001:3000 madhavnaks/node-app

without needing your source code.

Real-World DevOps Workflow

In production environments, the workflow usually looks like this:

flowchart LR
    A[Developer Writes Code]
    --> B[GitHub]

    B --> C[CI/CD Pipeline]

    C --> D[Docker Build]

    D --> E[Docker Hub]

    E --> F[Kubernetes Cluster]

This is exactly how modern DevOps teams package and deploy applications.

Key Takeaways

✅ Dockerfile defines how an image should be built

✅ Docker Build creates an image

✅ Docker Run creates a container

✅ Docker Hub stores and distributes images

✅ One image can create multiple containers

✅ Containerization ensures consistency across environments

Conclusion

In this guide, we covered the complete Docker workflow from source code to Docker Hub.

We learned how to:

Create a Dockerfile
Build a Docker image
Run a container
Verify application execution
Push images to Docker Hub
Understand how images move through real-world DevOps pipelines

Mastering these Docker fundamentals is the first step toward advanced topics like Docker Compose, Kubernetes, Helm, CI/CD pipelines, and cloud-native deployments.

If you're learning DevOps, try containerizing applications in different languages such as Python, Java, Go, or .NET to strengthen your understanding of Docker.

Happy Containerizing! 🚀

Configuring AWS CLI on Ubuntu for Local Machine ☁️🐧

Madhav Nakra — Thu, 21 May 2026 17:26:05 +0000

When people start learning AWS, they usually focus only on installing the AWS CLI.
But installing it is just the first step.

To actually interact with AWS services from your Ubuntu machine, you also need to configure AWS credentials properly.

In this guide, we’ll go through the complete setup process for AWS CLI on Ubuntu — from installation to configuration and verification.

Why AWS CLI?

AWS CLI allows you to manage AWS services directly from your terminal.

You can:

Launch EC2 instances
Upload files to S3
Configure IAM
Manage EKS clusters
Automate cloud operations using scripts

Instead of clicking through the AWS Console every time, AWS CLI helps automate everything efficiently.

Step 1: Update Packages

First, update your system packages:

sudo apt update

This ensures your package manager has the latest repository information.

Step 2: Install Required Dependencies

Install curl and unzip:

sudo apt install unzip curl -y

These tools are required to download and extract the AWS CLI installer.

Step 3: Download AWS CLI v2 Installer

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

This downloads the latest AWS CLI v2 package for Ubuntu/Linux systems.

Step 4: Unzip the Installer

unzip awscliv2.zip

This extracts the installation files.

Step 5: Run the Install Script

sudo ./aws/install

AWS CLI will now be installed on your machine.

Step 6: Verify Installation

Check whether AWS CLI is installed successfully:

aws --version

Example output:

Step 7: Configure AWS CLI

Now comes the important part — configuration.

Run:

aws configure

You’ll be asked for:

AWS Access Key ID
AWS Secret Access Key
Default region name
Default output format

Example:

AWS Access Key ID [None]: AKIAXXXXX
AWS Secret Access Key [None]: ********
Default region name [None]: ap-south-1
Default output format [None]: json

You can generate Access Keys from:

AWS Console → IAM → Users → Security Credentials → Create Access Key

Step 8: Verify Configured Profiles

To check configured AWS profiles and settings:

aws configure list

This helps verify whether your credentials and region are configured correctly.

Step 9: View Stored Credentials

AWS stores credentials locally inside the .aws directory.

Check credentials file:

cat ~/.aws/credentials

Check config file:

cat ~/.aws/config

Understanding the Files

credentials file

Stores:

Access Key ID
Secret Access Key

Example:

[default]
aws_access_key_id = XXXXX
aws_secret_access_key = XXXXX

config file

Stores:

Default region
Output format

Example:

[default]
region = ap-south-1
output = json

Important Security Tip ⚠️

Never share:

Access Key ID
Secret Access Key
.aws/credentials file

Also, add .aws/ to .gitignore if you're working inside projects.

Conclusion

Installing AWS CLI is easy, but properly configuring it is what actually enables you to work with AWS services from your local Ubuntu machine.

Once configured, you can automate cloud operations directly from the terminal and integrate AWS into scripts, CI/CD pipelines, and DevOps workflows.

If you're starting your cloud or DevOps journey, AWS CLI is one of the most essential tools to learn 🚀