DEV Community: Shashank Morappanavar

🚫 Kubernetes Ingress-NGINX Deprecation: Why You Should Stop Using It & What to Choose Instead

Shashank Morappanavar — Sat, 15 Nov 2025 11:16:00 +0000

For years, Ingress-NGINX was the default choice for exposing Kubernetes applications.
It was simple, open-source, widely supported, and became the “standard” way for beginners to run ingress traffic.

But the Kubernetes world has changed — Ingress-NGINX is no longer recommended, and many organizations have already moved away from it. Even the maintainers have reduced active support, major features are frozen, and the project has publicly acknowledged serious architectural limitations.

This article explains:
Why Ingress-NGINX is being deprecated
What changed in Kubernetes networking
History behind maintainers stepping away
Technical limitations
Better alternatives to migrate to

📉 1. Why We Are Deprecating Ingress-NGINX

1.1. The project has reached a maintenance bottleneck

Ingress-NGINX is an extremely complex controller built on top of NGINX’s Lua subsystem, template rendering, and custom patches. Over time:

Maintaining compatibility with upstream NGINX became harder

Patching security vulnerabilities required deep C-level knowledge

Very few contributors had the necessary expertise

Maintainers themselves stated that the project has a very small active maintainer base and cannot guarantee long-term updates.

1.2. NGINX (upstream) did not collaborate actively

Key reasons maintainers mentioned:

Lack of official support from NGINX Inc.

Breaking changes in NGINX requiring heavy rewrites

No guarantee of long-term API compatibility

Because of this, the project constantly lagged behind upstream NGINX releases.

1.3. Ingress API became too limiting

Kubernetes' built-in Ingress API is intentionally minimal. It does not support:

Advanced routing

Authentication flows

Canary deployments

Rate limiting

Circuit breaking

Traffic splitting

mTLS

TCP/UDP routing

To support these, Ingress-NGINX had to build hundreds of annotations, which became impossible to maintain.

Users ended up with:

nginx.ingress.kubernetes.io/proxy-body-size: "0"
nginx.ingress.kubernetes.io/rewrite-target: "/"
nginx.ingress.kubernetes.io/ssl-redirect: "false"
...
(50 more annotations)

This complexity is exactly why Kubernetes introduced Gateway API.

1.4. The future of Kubernetes Networking → Gateway API
Gateway API (GA since 2023) replaces Ingress.

It provides:

Standardized CRDs beyond Ingress

Better extensibility for vendors

First-class support for L4/L7 traffic controls

Cleaner routing

Cross-namespace & multi-tenant support

No annotations hack

Ingress-NGINX cannot evolve into Gateway API cleanly — it’s stuck with the old model.

1.5. Performance & architectural limitations

NGINX-based controllers have:

High memory consumption

Less efficient multi-tenant isolation

Slow reload times (config reloads entire NGINX)

No native support for modern protocols (HTTP/3, gRPC-web, etc.)

Modern proxies like Envoy outperform NGINX heavily in Kubernetes-native environments.

🕰️ 2. History: Why Maintainers Stopped / Reduced Support

Phase 1: 2016–2019

Ingress-NGINX was the most popular ingress option because:

Kubernetes did not have Gateway API

Only a few ingress controllers existed

NGINX was stable and familiar

Phase 2: 2020–2022 — The “Annotation Hell" Era

Dev teams struggled maintaining 100+ annotations.
Features were overlapping, incompatible, or buggy.

Phase 3: 2023 — Gateway API announced stable

Ingress API became a legacy interface.

Controller maintainers openly discussed:

“Ingress is too limiting
We cannot implement advanced traffic controls
Gateway API will replace this.”

Phase 4: 2024-2025 — Reduced active maintenance
Maintainers publicly noted:

Huge backlog of issues

Not enough skilled contributors

Major CVEs pending for months

Nginx upstream incompatibilities

Move toward Kubernetes-native proxies

While not “archived”, the project is effectively in slow maintenance mode — not evolving and not future-proof.

🚫 3. Technical Reasons You Should Stop Using Ingress-NGINX

3.1. Annotations are fragile and vendor-specific

Your configuration is locked to NGINX.
If you switch controller → everything breaks.

3.2. Lack of advanced traffic management

Compared to modern ingress options, NGINX lacks:

Canary releases

Weighted routing

Retry policies

Circuit breakers

mTLS per route

Traffic shadowing

3.3. Scaling causes full reloads
Every config change → restarts the entire NGINX worker group.

This causes:

latency spikes

dropped connections

slow rollouts

3.4. No native multi-tenant support

NGINX has no concept of:

cross-namespace routing

delegated traffic governance

namespace isolation policies

Gateway API fixes this.

⭐ 4. Best Alternatives to Ingress-NGINX (2025)

✅ 1. Envoy-based Proxies
Istio Gateway / Envoy Gateway

Best for:

Microservices

Zero-downtime routing

Advanced L7 traffic engineering

Benefits:

Native Gateway API support

No reloads (Envoy is xDS-based)

mTLS, retries, canaries, traffic splitting built-in

✅ 2. Traefik

Best for:

Simpler environments

Kubernetes dashboards

High-performance basic routing

Benefits:

Native Gateway API support

Auto TLS

No reloads

Simple CRDs

✅ 3. HAProxy Ingress / HAProxy Gateway

Best for:

High performance

Low latency

Large-scale clusters

Benefits:

Mature HAProxy engine

Strong Gateway API roadmap

✅ 4. NGINX Gateway Fabric (New – replaces Ingress-NGINX)

NGINX Inc. now maintains this instead of Ingress-NGINX.

Benefits:

Built for Gateway API

Modern architecture

Actively maintained

No annotations

Why it’s better:

Ingress-NGINX → old, annotation hack
NGINX Gateway Fabric → new, clean, Kubernetes-native

📦 5. If You Still Use Ingress-NGINX, What Should You Do?

Short-term

Lock your version

Apply CVE patches manually

Avoid complex annotations

Long term (Recommended)

Plan migration to a Gateway API controller

Choose Envoy Gateway or NGINX Gateway Fabric

Begin rewriting Ingress rules → Routes + Gateways

📝 Conclusion

Ingress-NGINX served the Kubernetes community incredibly well for years.
But the world of cloud-native routing has evolved:

The Ingress API is outdated

NGINX architecture doesn’t fit modern service mesh needs

Maintainers cannot keep up

Gateway API is the future

If you're starting a new project in 2025 or planning an upgrade — do not use Ingress-NGINX.
The ecosystem is moving forward, and so should your architecture.

Shell Script to Rotate Logs, Extract Errors, and Alert Developers via Email (with Datadog Integration)

Shashank Morappanavar — Sun, 27 Jul 2025 12:55:31 +0000

Production apps generate thousands of log lines every day. If not managed properly:

Logs eat up disk space.
Critical errors get buried in noise.
Developers find out about issues too late.

So, I built a shell-powered automation that:

Rotates and archives logs daily
Extracts ERROR logs from gzipped archives
Emails those errors to developers
Sends success/failure status to Datadog Logs

Use Case:

Imagine your app (Invoice) runs in production and writes logs to /var/log/invoice/. Every night, you want to:

Rotate those logs and gzip them
Save them to /var/backups/logs/invoice/YYYY-MM-DD
Extract only ERROR lines
Email the developers a copy of that error log
Push a status message to Datadog for audit and alerts

The Script

#!/bin/bash
set -euo pipefail

APP_NAME="invoice"
LOG_DIR="/var/log/$APP_NAME"
ARCHIVE_DIR="/var/backups/logs/$APP_NAME"
TODAY=$(date +%F)
ERROR_FILE="/tmp/${APP_NAME}_errors_$TODAY.log"
EMAIL_SUBJECT="[$APP_NAME] Errors Detected - $TODAY"
DEVELOPER_EMAILS=("dev1@example.com" "dev2@example.com")
DD_API_KEY="your_datadog_api_key"
DD_LOG_TAG="error-alert"

mkdir -p "$ARCHIVE_DIR/$TODAY"

log_to_datadog() {
  local message="$1"
  curl -X POST "https://http-intake.logs.datadoghq.com/v1/input" \
    -H "Content-Type: application/json" \
    -H "DD-API-KEY: $DD_API_KEY" \
    -d "{
      \"ddsource\": \"shell-script\",
      \"service\": \"$APP_NAME\",
      \"hostname\": \"$(hostname)\",
      \"message\": \"$message\",
      \"tags\": [\"env:prod\",\"task:$DD_LOG_TAG\"]
    }" >/dev/null 2>&1
}

send_error_email() {
  for email in "${DEVELOPER_EMAILS[@]}"; do
    mailx -s "$EMAIL_SUBJECT" -a "$ERROR_FILE" "$email" <<EOF
Hi Dev,

Errors were detected in today's logs for [$APP_NAME].

Please check the attached error log file for investigation.

Regards,
Automated Log Monitor
EOF
  done
}

echo " Rotating logs for $APP_NAME..."
if compgen -G "$LOG_DIR/*.log" > /dev/null; then
  find "$LOG_DIR" -type f -name "*.log" -exec gzip {} \;
  mv "$LOG_DIR"/*.gz "$ARCHIVE_DIR/$TODAY"
  echo " Rotated logs to $ARCHIVE_DIR/$TODAY"
  log_to_datadog " [$APP_NAME] Logs rotated successfully at $TODAY"
else
  echo " No logs to rotate."
  log_to_datadog "[$APP_NAME] No logs found for rotation on $TODAY"
fi

echo " Extracting errors..."
find "$ARCHIVE_DIR/$TODAY" -name "*.gz" -exec zgrep "ERROR" {} \; > "$ERROR_FILE" || true

if [ -s "$ERROR_FILE" ]; then
  echo " Found error logs. Sending alert..."
  send_error_email
  log_to_datadog " [$APP_NAME] Errors found and emailed to developers on $TODAY"
else
  echo "No errors found."
  log_to_datadog "[$APP_NAME] No errors found in logs on $TODAY"
  rm -f "$ERROR_FILE"
fi

Schedule It With Cron

`# /etc/cron.d/log-monitor
0 2 * * * /opt/scripts/rotate-and-alert-errors.sh >> /var/log/log-monitor.log 2>&1

How This Helps DevOps & Developers

Proactive Monitoring
No more “surprise bugs” — devs get error logs before users notice.
Disk-space Hygiene
Logs are rotated and compressed, preventing overflow.
Observability
All operations are visible in Datadog Logs. You can create monitors, dashboards, or anomaly alerts.

Conclusion

Build once, run forever
Alert smartly, not noisily
Give developers what they need, when they need it

🚀 How to Deploy Any WordPress Web App Using Docker

Shashank Morappanavar — Mon, 05 May 2025 04:58:38 +0000

If you're a developer or WordPress enthusiast looking to containerize your website for portability and ease of deployment, this step-by-step guide will walk you through the entire process—from setup to containerization.

📦 Prerequisites

Docker & Docker Compose installed
A basic WordPress website (with custom plugins/themes if any)
(Optional) Exported WordPress content in .xml format

📁 Project Structure

Start by creating a working directory:

wordpress-docker/
├── Dockerfile
├── wp-content/
│   └── plugins/
│       └── hello-world-sample/
├── wp-data.xml     # (optional) exported WordPress content
└── docker-compose.yml

🐳 Dockerfile for WordPress
Create a Dockerfile to extend the official WordPress image and include your custom plugin:

FROM wordpress:6.5-php8.1-apache

##Copy your plugin into the WordPress plugin directory
COPY wp-content/plugins/hello-world-sample /var/www/html/wp-content/plugins/hello-world-sample

##Fix permissions (optional)
RUN chown -R www-data:www-data /var/www/html/wp-content/plugins/hello-world-sample

🧩 Docker Compose File
Create docker-compose.yml to set up both WordPress and MySQL:

version: '3.8'

services:
  wordpress:
    build: .
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: wp_pass
      WORDPRESS_DB_NAME: wp_db
    volumes:
      - wordpress_data:/var/www/html

  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: wp_db
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: wp_pass
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - db_data:/var/lib/mysql

volumes:
  wordpress_data:
  db_data:

🚀 Launch WordPress
Run this to build and start the containers:

docker-compose up --build

Your site will be available at:
http://ec2-ip/wordpress