Forem: Gaurav Tayade

Stop Copy-Pasting kubectl Commands to Debug Pods

Gaurav Tayade — Sat, 11 Apr 2026 06:48:22 +0000

Every time a pod crashes, you run the same 5 commands. There's a better way.

The pain

It's 2 AM. Your on-call phone fires. A pod in production is crashing.

You SSH in, open your terminal, and start the ritual:

kubectl get pods -n nxs-demo-bad
kubectl describe pod crash-loop-demo -n nxs-demo-bad
kubectl logs crash-loop-demo -n nxs-demo-bad --previous
kubectl get events -n nxs-demo-bad --sort-by='.lastTimestamp'
kubectl top pod crash-loop-demo -n nxs-demo-bad

You get walls of output. You scan through it manually. You try to piece together what went wrong. You copy the error into Google. You find a Stack Overflow answer from 2019.

This is the reality for most engineers debugging Kubernetes. Not because they don't know what they're doing — but because the tooling makes you do all the work yourself.

Here's what a real broken namespace looks like:

$ kubectl get pods -n nxs-demo-bad

NAME              READY   STATUS             RESTARTS         AGE
crash-loop-demo   0/1     Error              68 (5m20s ago)   22h
image-pull-demo   0/1     ImagePullBackOff   0                22h
oom-demo          0/1     CrashLoopBackOff   95 (30s ago)     22h
pending-demo      0/1     Pending            0                22h

4 pods broken. 4 different problems. Where do you even start?

What's actually happening

When a pod crashes, the information you need is spread across three places:

Logs — what the application printed before it died
Events — what Kubernetes did (pulled image, scheduled, killed)
Describe — the pod spec, resource limits, exit codes

You have to gather all three, read them together, and mentally correlate them to find the root cause. For experienced engineers this takes 5-10 minutes. For developers who don't live in kubectl every day, it can take much longer.

The new way

I built nxs — an open-source CLI that does all of this in one command.

nxs k8s debug --pod crash-loop-demo -n nxs-demo-bad

That's it. nxs automatically:

Fetches the pod logs (including --previous for crashed containers)
Fetches kubectl describe output
Sends both to AI for root cause analysis
Returns: what broke, why, and exact fix commands

Here's the real output from running it against that broken pod:

╔══════════════════════════════════════════════════════════╗
║  ⚡ nxs                                        v2.0.0  ║
║     Kubernetes deep-dive debugger                        ║
╚══════════════════════════════════════════════════════════╝

────────────────────────────────────────────────────────────
  ☸  KUBERNETES DETECTED
────────────────────────────────────────────────────────────

📋 SUMMARY

  The pod 'crash-loop-demo' is crashing in a loop due to an error
  in the container. The container exits with a non-zero exit code
  after failing to find a configuration file.

🔍 ROOT CAUSE

  1. The container exits with code 1 — the config file
     /etc/app/config.yaml does not exist inside the container.
  2. Kubernetes repeatedly restarts the container due to its
     restart policy, leading to CrashLoopBackOff.
  3. No ConfigMap or volume is mounted to provide the config file.

💡 FIX STEPS

  1. Ensure the required config file is mounted via a ConfigMap.
  2. Verify the container command matches what exists in the image.
  3. Adjust restart policy or fix the application error handling.

💻 REMEDIATION COMMANDS

  ┌─ shell ────────────────────────────────────────────────────────┐
  │ 1. kubectl describe pod crash-loop-demo -n nxs-demo-bad        │
  │ 2. kubectl logs crash-loop-demo -n nxs-demo-bad                │
  │ 3. kubectl exec -it crash-loop-demo -n nxs-demo-bad -- /bin/sh │
  └─────────────────────────────────────────────────────────────────┘

Plain English. Root cause numbered. Commands ready to copy.
No manual log reading. No Googling. No Stack Overflow.

It also works with piped logs

If you already have the logs, just pipe them:

# From a file
nxs k8s debug pod-error.log

# From kubectl directly
kubectl logs my-pod --previous | nxs k8s debug --stdin

# Full describe + logs combined
kubectl describe pod my-pod | nxs k8s debug --stdin

Debug an entire deployment at once

Got a deployment with 3 replicas all crashing? Instead of checking each pod:

nxs k8s debug --deployment my-app -n production

nxs fetches logs and describe from all pods in the deployment concurrently and analyzes them together — so you get one diagnosis instead of three.

Works without an AI key

No API key? No problem. nxs has a smart mock mode that pattern-matches common errors (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending) and returns accurate responses without any AI call.

To add a free Groq key (recommended — much more accurate):

nxs config --setup
# Groq is free: console.groq.com

Install

npm install -g @nextsight/nxs-cli

Requirements: Node.js 18+, kubectl configured

What's next

This is article 1 in the "DevOps in 1 Command" series.

Next up: How I catch OOMKills before they happen in production — using nxs predict to surface at-risk pods before Kubernetes kills them.

nxs is open source. Star it on GitHub: https://github.com/gauravtayade11/nxs

Install: npm install -g @nextsight/nxs-cli

Building a Production-Ready SonarQube Scanner Plugin for Devtron CI/CD

Gaurav Tayade — Mon, 23 Mar 2026 11:06:14 +0000

Building a Production-Ready SonarQube Scanner Plugin for Devtron CI/CD

How to build a reusable, secure, and language-agnostic SonarQube scanner plugin that enforces code quality gates across all application pipelines in Devtron.

TL;DR

Built a custom Devtron plugin for SonarQube scanning
Works across all languages (Java, Python, JS, TS, Go)
Enforces Quality Gates and blocks deployments on failure
Zero token exposure in pipeline logs
One plugin reusable across all apps with minimal config

Introduction

When managing multiple application pipelines using Devtron an open-source Kubernetes-native CI/CD platform, teams often need a consistent way to enforce code quality standards across all applications without asking every team to set up SonarQube from scratch.

The challenge? Devtron's native SonarQube plugin can have limitations. This post walks through building a custom production-ready, reusable plugin that solves these challenges.

Why Build a Custom Plugin

Native plugin limitations - The built-in Devtron SonarQube plugin may have authentication issues
No modification access - You cannot modify Devtron's native plugins
Reusability - One plugin all teams can use without writing their own scripts
Security - Proper secret handling and token validation before every scan

Architecture Overview

Devtron CI Pipeline
        |
        |-- Pre-build Stage
        |   |-- SonarQube Scanner Plugin (custom)
        |       |-- Container Image  <- sonar-scanner binary
        |       |-- Shell Script     <- logic
        |       |-- sonar-project.properties <- per app repo
        |
        |-- Build Stage
        |   |-- Docker Image Build
        |
        |-- Post-build Stage
            |-- Deploy

Key Insight: Separate the binary from the logic. The container image carries the sonar-scanner binary, while the shell script mounted at runtime by Devtron contains all the logic. This means you can update the script without rebuilding the image!

The Container Image

FROM alpine:3.20

RUN apk add --no-cache \
    curl unzip openjdk17-jre bash \
    nodejs npm libstdc++ libgcc \
    && rm -rf /var/cache/apk/*

RUN curl -sSLo /tmp/sonar.zip \
    "https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-6.2.1.4610-linux-x64.zip" && \
    unzip -q /tmp/sonar.zip -d /opt && \
    mv /opt/sonar-scanner-6.2.1.4610-linux-x64 /opt/sonar-scanner && \
    rm /tmp/sonar.zip && \
    rm -rf /opt/sonar-scanner/jre && \
    sed -i 's/use_embedded_jre=true/use_embedded_jre=false/' \
    /opt/sonar-scanner/bin/sonar-scanner

ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk
ENV PATH="/opt/sonar-scanner/bin:/usr/lib/jvm/java-17-openjdk/bin:$PATH"
ENV SONAR_SCANNER_OPTS="-Dsonar.nodejs.executable=/usr/bin/node"

Common Gotchas

1. Alpine needs BOTH libstdc++ AND libgcc

Missing either causes:

Error loading shared library libstdc++.so.6: No such file or directory

2. Never use $(which node) in ENV instruction

# Wrong
ENV SONAR_SCANNER_OPTS="-Dsonar.nodejs.executable=$(which node)"

# Correct
ENV SONAR_SCANNER_OPTS="-Dsonar.nodejs.executable=/usr/bin/node"

The Shell Script

Script Flow

1. Strip trailing slash from URL
2. Validate required variables
3. Security checks (token format, HTTPS)
4. Connectivity check
5. Token authentication via API
6. Source code validation
7. Run sonar-scanner
8. Check Quality Gate via API
9. Report status in logs

Security Handling

# Never print the token
set +x

# Validate token BEFORE scan
AUTH=$(curl --silent -u "$SONAR_TOKEN:" \
  "$SONAR_HOST_URL/api/authentication/validate")

if ! echo "$AUTH" | grep -q '"valid":true'; then
  echo "Token authentication FAILED!"
  exit 1
fi

# Filter token from scanner output
/opt/sonar-scanner/bin/sonar-scanner $SCANNER_ARGS 2>&1 | \
  grep -v "sonar.token" | \
  grep -v "sonar.login"

Fix Trailing Slash Issue

SonarQube returns HTML instead of JSON when the URL has a trailing slash causing auth to fail even with a valid token!

# Always strip trailing slash first
SONAR_HOST_URL=$(echo "$SONAR_HOST_URL" | sed 's:/*$::')

Quality Gate Control

# FAIL_ON_QUALITY_GATE=false is useful for onboarding legacy projects
FAIL_ON_QUALITY_GATE="${FAIL_ON_QUALITY_GATE:-true}"

if [ "$QG_STATUS" = "ERROR" ]; then
  if [ "$FAIL_ON_QUALITY_GATE" = "false" ]; then
    echo "WARNING: Quality Gate failed but pipeline continues"
  else
    exit 1
  fi
fi

Devtron Plugin Configuration

Plugin Form Settings

Field	Value
Task Name	SonarQube Scanner with Quality Gate
Plugin ID	sonarqube-scanner-quality-gate
Version	1.0.0
Mount Code At	/scripts/sonar-scan.sh
Command	/bin/sh
Args	/scripts/sonar-scan.sh
Mount Code to Container	Yes

Input Variables

Variable	Type	Required	Default
SONAR_TOKEN	Secret	Yes	-
SONAR_HOST_URL	String	Yes	-
SONAR_PROJECT_KEY	String	Yes	-
SONAR_PROJECT_NAME	String	No	Same as key
SONAR_SOURCES	String	No	/sourcecode
SONAR_JAVA_BINARIES	String	No	.
SONAR_EXCLUSIONS	String	No	-
BRANCH_NAME	String	No	-
QUALITY_GATE_TIMEOUT	String	No	300
FAIL_ON_QUALITY_GATE	String	No	true

Always use Secret type for SONAR_TOKEN - tokens appear in plain text in logs when using String type!

Per-App Configuration

Each app just needs one file added to its repo root.

JavaScript/TypeScript:

sonar.projectKey=my-app
sonar.projectName=My App
sonar.sources=src
sonar.exclusions=**/node_modules/**,**/coverage/**,**/*.test.js
sonar.javascript.lcov.reportPaths=coverage/lcov.info
sonar.sourceEncoding=UTF-8

Python:

sonar.projectKey=my-python-app
sonar.projectName=My Python App
sonar.language=py
sonar.python.version=3
sonar.sources=.
sonar.exclusions=**/__pycache__/**,**/*.pyc,**/venv/**
sonar.python.coverage.reportPaths=coverage.xml
sonar.sourceEncoding=UTF-8

Java Maven:

sonar.projectKey=my-java-app
sonar.projectName=My Java App
sonar.sources=src/main/java
sonar.java.binaries=target/classes
sonar.tests=src/test/java
sonar.sourceEncoding=UTF-8

Project Onboarding Automation

For each new project we automate everything via SonarQube API:

sh sonar-onboard.sh

# Output:
# Project created: my-app
# Group created: my-app-developers
# User added to group
# Permissions assigned
# Project set to PRIVATE
#
# CI TOKEN: sqa_xxxxxxxxxxxxx
# Add to Devtron as SONAR_TOKEN secret

Challenges and Solutions

Challenge	Solution
Native plugin auth issues	Custom shell script plugin
Token exposed in logs	set +x and grep filter
Trailing slash in URL	Strip with sed first
Alpine missing C++ libs	Add libstdc++ and libgcc
Node.js path issue	Hardcode /usr/bin/node
Quality Gate blocking new projects	FAIL_ON_QUALITY_GATE=false
/bin/sh vs /bin/bash	Full POSIX sh compatible script

Results

One plugin reusable across all apps and languages
Zero token exposure in pipeline logs
Consistent quality gates across all teams
New app onboarded in under 10 minutes
Flexible gradual adoption with FAIL_ON_QUALITY_GATE

What's Next

Coverage reports (JaCoCo, pytest-cov, lcov)
Branch and PR analysis
Slack notifications on Quality Gate failure
Custom Grafana dashboard for scan trends

Resources

If this helped you drop a reaction and share with your team!

I got paranoid about online tools logging my secrets — so I built my own

Gaurav Tayade — Wed, 18 Mar 2026 06:17:41 +0000

A few months ago a teammate accidentally pasted production AWS credentials
into an online JSON formatter. Nothing happened — but it could have.

That moment stuck with me. How many times had I pasted a JWT, a .env file,
or a Dockerfile into some random tool without thinking about it? Those sites
are free because they can afford to be. Your data might be the product.

So I stopped using them and built my own: DevsTool.

What it is

DevsTool is a collection of 19 developer and
DevOps utilities that run entirely in your browser. No backend, no accounts,
no data collection. The only thing that ever leaves your machine is the URL
you're on.

The tools I use most as a DevOps engineer

K8s Manifest Generator

Fill in a form — name, image, replicas, resource limits, env vars — and get
a ready-to-apply Deployment + Service YAML. Handles ConfigMap, Ingress, and
HPA too. No more copying boilerplate from Stack Overflow.

CIDR / Subnet Calculator

Enter a CIDR block like 10.0.0.0/24 and instantly see the network address,
broadcast, first/last host, total IPs, and usable hosts. Has a binary
visualizer showing which bits are network vs host, and an IP-in-range checker.
Essential for VPC planning.

Secret Scanner

Paste any text — code, config, logs — and it scans for 20+ credential
patterns: AWS access keys, GitHub tokens, GCP service account keys, Azure
connection strings, Stripe keys, Discord tokens, and more. All regex, all
client-side.

Log Formatter

Paste JSON logs and it parses them into a structured view with level badges,
timestamps, and expandable JSON payloads. Filter by error/warn/info/debug,
search across lines, and scroll horizontally for long lines. You can also
upload a .log file directly.

Dockerfile Linter

Checks 12 best-practice rules: pinned base images, no apt-get without
--no-install-recommends, COPY over ADD, non-root USER, and more.

Other tools

JSON Formatter (Monaco editor), JWT Decoder, YAML Validator, ENV Parser,
Diff Checker, Markdown Preview, Cron Builder, Git Command Builder,
Base64/URL Encoder, UUID Generator, Timestamp Converter, Port Reference,
HTTP Headers inspector.

How it's built

Next.js 15 App Router, fully static except the HTTP Headers proxy
Tailwind CSS v4
Monaco Editor (via CDN to avoid Turbopack worker bundling issues)
⌘K command palette for jumping between tools instantly
Shareable links — tool state is base64url-encoded in the URL, no server involved

The secret scanner is just a list of compiled regexes run against the input
on every keystroke. The K8s generator is a form that builds a YAML string —
no server, no templating engine.

Why client-side matters

When you paste a JWT into a tool, you're potentially exposing:

The algorithm and signing key hint
User IDs, roles, and permissions encoded in the payload
Token expiry (useful for timing attacks)

When you paste a .env file, you're potentially exposing every secret your
app uses. Running these tools in the browser means the data never travels
over a network. There's nothing to intercept, nothing to log.

The project is open source: github.com/gauravtayade11/devstool

Live: devstool.vercel.app

Would love feedback — especially on what DevOps tools you'd want added next.

I Built an Open-Source Kubernetes Dashboard - Here's What I Learned

Gaurav Tayade — Tue, 02 Dec 2025 05:24:34 +0000

Why Another K8s Dashboard?

I know what you're thinking - "There's already Lens, K9s, Rancher..."

Here's the thing: I wanted something that:

Runs in a browser (no local installation)
Has built-in safety guards (block dangerous commands)
Deploys easily to the cluster itself
Is completely open-source

So I built NexOps.

The 30-Second Demo

git clone https://github.com/gauravtayade11/nexops.git
docker-compose up -d

Open http://localhost:3000

That's it. You're in.

What Makes It Different

1. Browser-Based kubectl with Safety Guards

Run kubectl commands in your browser, but dangerous ones are blocked:

dangerous_patterns = [
    'delete --all',
    'delete namespace',
    '--force --grace-period=0',
    'rm -rf /',
]

No more accidental cluster wipes.

2. Real-Time Everything

Live cluster health
Streaming pod logs
Container exec sessions
Event monitoring

3. Team-Friendly

Give developers cluster visibility without:

Installing kubectl locally
Sharing kubeconfig files
Full admin access

Technical Challenges

The hardest part? Making it work with Docker Desktop's Kubernetes.

When your app runs in a container, localhost:6443 refers to the container, not your Mac. The fix: use kubernetes.docker.internal.

Tech Stack

Layer	Technology
Backend	FastAPI (Python 3.11)
Frontend	React 18 + TypeScript
Styling	Tailwind CSS
Container	Docker + nginx

What's Next

[ ] WebSocket for real-time logs
[ ] Multi-cluster support
[ ] RBAC integration
[ ] Helm chart UI

Try It Out

GitHub: https://github.com/gauravtayade11/nexops

Star ⭐ if you find it useful!

What K8s tools do you use? I'd love to hear in the comments!

Automating PostgreSQL Backups on Kubernetes with CronJobs & Persistent Storage

Gaurav Tayade — Tue, 01 Apr 2025 06:21:02 +0000

Automate PostgreSQL Database Backups in Kubernetes with CronJobs and Azure File Share

Tired of manually backing up your PostgreSQL database? Automate the process using Kubernetes CronJobs, ConfigMaps, Persistent Volumes, and a lightweight PostgreSQL client Docker image.

In this step-by-step guide, you’ll learn how to:

✅ Create a Docker image with postgresql-client to perform backups.

✅ Use Kubernetes ConfigMaps to manage your backup script.

✅ Set up Persistent Volumes (PV & PVC) for storage.

✅ Automate backups using CronJobs with retention policies.

🛠 Prerequisites

Before getting started, ensure you have:

✔ A Kubernetes cluster on Azure Kubernetes Service (AKS) or another Kubernetes environment.

✔ kubectl installed and configured.

✔ A running PostgreSQL database in Kubernetes.

✔ Azure CLI installed for managing Azure resources.

✔ Docker installed to build and push images.

✔ A DockerHub or private container registry to store the backup image.

✔ Azure File Share created for storing backups persistently.

💡 Azure File Share will be used as persistent storage for backups.

Let’s get started! 🚀

💡 Why Automate PostgreSQL Backups?

Manual backups are risky — you might forget, or worse, data loss could occur before you act. With this Kubernetes-native solution, backups run automatically on a schedule, ensuring:

✔ Reliability — No missed backups!

✔ Security — Stored in Persistent Volumes (PVC).

✔ Efficiency — Old backups are deleted after 7 days.

🔧 Step 1: Build & Push the PostgreSQL Backup Docker Image

We’ll create a lightweight Docker image that only installs postgresql-client. This avoids unnecessary overhead from a full PostgreSQL installation.

📌 Dockerfile

# Use the official Ubuntu base image
FROM ubuntu:latest  
# Install PostgreSQL client
RUN apt-get update && \
    apt-get install -y postgresql-client && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*  
# Set default command  
CMD ["psql", "--version"]

🛠 Build & Push the Image

docker build -t your-dockerhub-username/postgres-backup:latest .
docker push your-dockerhub-username/postgres-backup:latest

🔹 Replace your-dockerhub-username with your actual DockerHub username.

Step 2: Create Persistent Storage for Backups (PV & PVC)

We’ll store backups in an Azure File Share-backed Persistent Volume (PV & PVC).

📌 PersistentVolume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgresql-backup-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  azureFile:
    secretName: ""  # Add your secret here
    secretNamespace: "" 
    shareName: ""  # Add your Azure File Share name here
    readOnly: false

📌 PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgresql-backup-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeName: postgresql-backup-pv

🔹 Modify shareName and secretName based on your Azure setup.

Apply these:

kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml

📜 Step 3: Create ConfigMap for Backup Script

We need to mount the backup.sh script inside the CronJob container. Instead of hardcoding it, let’s use a ConfigMap.

📌 backup.sh (Backup Script)

#!/bin/bash
NAMESPACE=${NAMESPACE:-"default"}
POSTGRES_SVC=${POSTGRES_SVC}
POSTGRES_USER=${POSTGRES_USER}
POSTGRES_DB=${POSTGRES_DB}
BACKUP_DIR="/backup"
DATE=$(date +"%Y-%m-%d")
BACKUP_FILE="${BACKUP_DIR}/${POSTGRES_DB}_${DATE}.sql"
TAR_FILE="${BACKUP_DIR}/${POSTGRES_DB}_${DATE}.tar.gz"
POSTGRES_PASS=${POSTGRES_PASS}
# Perform the backup
PGPASSWORD="$POSTGRES_PASS" pg_dump -h "$POSTGRES_SVC" -U "$POSTGRES_USER" -d "$POSTGRES_DB" -F c -f "$BACKUP_FILE"
# Compress the backup
if [ $? -eq 0 ]; then
  tar -czf "$TAR_FILE" -C "$BACKUP_DIR" "$(basename "$BACKUP_FILE")"
  rm -f "$BACKUP_FILE"
  echo "Backup completed: $TAR_FILE"
else
  echo "Backup failed!"
  exit 1
fi
# Delete backups older than 7 days
find "$BACKUP_DIR" -type f -name "${POSTGRES_DB}_*.tar.gz" -mtime +7 -exec rm -f {} \;

📌 Create ConfigMap

kubectl create configmap backup-script --from-file=backup.sh
🔹 This mounts backup.sh in the CronJob without modifying the container.

⏳ Step 4: Automate Backups with a Kubernetes CronJob

The CronJob runs the backup script every night at 12:30 AM(UTC).

📌 CronJob YAML

apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgresql-backup
spec:
  schedule: "30 0 * * *"  # Runs daily at 12:30 AM UTC
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: postgresql-backup
              image: your-dockerhub-username/postgres-backup:latest   #update the values
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args:
                - |
                  cp /scripts/backup.sh /tmp/backup.sh
                  chmod +x /tmp/backup.sh
                  until pg_isready -h "$POSTGRES_SVC" -U "$POSTGRES_USER"; do
                    echo "Waiting for PostgreSQL to be ready..."
                    sleep 5
                  done
                  echo "Running backup script..."
                  /tmp/backup.sh
              env:
                - name: POSTGRES_SVC
                  value: "your-postgres-service"   #update the values
                - name: POSTGRES_USER
                  valueFrom:
                    secretKeyRef:
                      name: your-secret        #update the values
                      key: POSTGRES_USER
                - name: POSTGRES_PASS
                  valueFrom:
                    secretKeyRef:
                      name: your-secret        #update the values
                      key: POSTGRES_PASSWORD
                - name: POSTGRES_DB
                  value: "your-database"       #update the values
              volumeMounts:
                - name: backup
                  mountPath: /backup
                - name: script-volume
                  mountPath: /scripts
          restartPolicy: OnFailure
          volumes:
            - name: backup
              persistentVolumeClaim:
                claimName: postgresql-backup-pvc
            - name: script-volume
              configMap:
                name: backup-script

🔹 Replace your-dockerhub-username and your-postgres-service with actual values.

🛠 Apply CronJob

kubectl apply -f cronjob.yaml

🚀 Wrapping Up

Congratulations! 🎉 You have successfully automated PostgreSQL backups on Kubernetes using:

✔ Dockerized PostgreSQL client for backup execution.

✔ ConfigMaps to manage scripts.

✔ Persistent Storage (PV & PVC) to retain backups.

✔ CronJobs to schedule automated backups.

💬 What’s Next?

Want to take your PostgreSQL backup automation to the next level?

Hire me on Fiverr for customized solutions tailored to your needs!

Have any questions or improvements? Drop a comment below!
🔥 Have you automated PostgreSQL backups yet? Let me know in the comments! 🚀

Automating EKS Deployment with Terraform: A Step-by-Step Guide

Gaurav Tayade — Wed, 05 Mar 2025 17:40:49 +0000

Introduction

Managing Kubernetes clusters on AWS can be complex, but Terraform simplifies infrastructure provisioning. In this blog, I’ll walk you through how I automated the deployment of an EKS cluster with IAM roles, node groups, and an ALB controller using Terraform.

Why Terraform for EKS?

Terraform provides Infrastructure as Code (IaC), making infrastructure repeatable and scalable. By using Terraform to deploy EKS, you:

Avoid manual configurations
Ensure consistency across environments
Automate infrastructure creation and scaling

Project Overview

This Terraform script accomplishes the following:

Creates an IAM role for the EKS control plane
Deploys an EKS cluster
Sets up an IAM role for worker nodes
Configures an EKS node group with private subnets
Adds an SSH key pair for remote access
Deploys an AWS Load Balancer Controller

Project Structure

To keep the Terraform code modular, we will create a separate vars.tf file to store all the required variables.

Directory Structure:

terraform-eks/
│-- main.tf
│-- variables.tf
│-- outputs.tf
│-- terraform.tfvars
│-- alb-ing-iam_policy.json
│-- providers.tf
|-- alb-ingress.tf
**

Terraform Script Breakdown

1. Create a Variables File (variables.tf)

variable "aws_region" {
  type        = string
  description = "AWS Region"
  default     = "us-east-1"
}

variable "vpc_id" {
   type        = string
   description = "AWS VPC Id"
   sensitive   = true
}

variable "aws_private_subnets" {
    type        = list(string)
    description = "List of Subnets"
    sensitive   = true
}

variable "cluster_version" {
  type        = number
  description = "EKS Cluster Version"
  default     = 1.31
}

2. Define Terraform Variables File (terraform.tfvars)

aws_region = "us-east-1"
vpc_id = "vpc-************"
aws_private_subnets = aws_private_subnets = ["private-subnet-1", "private-subnet-1"]
cluster_version = 1.31

3. Defining Local Variables in main.tf

locals {
  name = "eks-demo"
  common_tag = {
    Env = "Dev"
  }
}

4. Creating IAM Policy for ALB Ingress Controller

resource "aws_iam_policy" "alb_ingress_policy" {
  name        = "${local.name}-ALBEksControllerPolicy"
  description = "IAM policy for ALB Ingress Controller"
  policy      = file(var.alb_ingress_policy_file)
}

5. Creating IAM Role for ALB Ingress Controller

resource "aws_iam_role" "alb_ingress_role" {
  name               = "${local.name}-ALBEksControllerRole"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "eks.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })
}

6. Attaching IAM Policy to Role

resource "aws_iam_role_policy_attachment" "alb_ingress_policy_attachment" {
  policy_arn = aws_iam_policy.alb_ingress_policy.arn
  role       = aws_iam_role.alb_ingress_role.name
  depends_on = [
    aws_iam_policy.alb_ingress_policy,
    aws_iam_role.alb_ingress_role
  ]
}

7. Creating Kubernetes Service Account for ALB Controller

resource "kubernetes_service_account" "alb_ingress_sa" {
  metadata {
    name      = "alb-ingress-controller"
    namespace = "kube-system"
    annotations = {
      "eks.amazonaws.com/role-arn" = aws_iam_role.alb_ingress_role.arn
    }
  }
  depends_on = [ aws_iam_role_policy_attachment.alb_ingress_policy_attachment, aws_eks_cluster.eks_cluster ]
}

8. Deploying AWS Load Balancer Controller with Helm

resource "helm_release" "alb_ingress_controller" {
  name       = "alb-ingress-controller"
  repository = "https://aws.github.io/eks-charts"
  chart      = "aws-load-balancer-controller"
  namespace  = "kube-system"
  set = [ 
    {
      name  = "clusterName"
      value = aws_eks_cluster.eks_cluster.name
    },
    {
      name  = "serviceAccount.create"
      value = "false"
    },
    {
      name  = "serviceAccount.name"
      value = kubernetes_service_account.alb_ingress_sa.metadata[0].name
    },
    {
      name  = "ingressClass"
      value = "alb"
    },
    {
      name  = "vpcID"
      value = var.vpc_id
    },
    {
      name  = "region"
      value = var.aws_region
    }
  ]
  depends_on = [ kubernetes_service_account.alb_ingress_sa ]
}

Complete Deployment Flow

Clone the repository:

git clone https://github.com/gauravtayade11/terraform-eks-alb.git

Initialize Terraform:

terraform init

Validate the configuration:

terraform validate

Apply Terraform to create resources:

terraform apply -auto-approve

Verify the cluster:

aws eks --region us-east-1 update-kubeconfig --name eks-demo-cluster
kubectl get nodes

Conclusion

With this Terraform script, we:

Created an EKS cluster
Configured IAM roles and node groups
Set up a scalable node group
Installed an AWS Load Balancer Controller

Using Terraform ensures repeatability, scalability, and automation. Feel free to try this setup and modify it to match your needs. 🚀

Check out the complete code on GitHub: GitHub Repository

Let me know in the comments if you have any questions or improvements! 👇