Configuring Ingress Controllers with NGINX for Production Traffic

Overview and What You Will Learn

Without an Ingress Controller, exposing services in Kubernetes means creating a separate cloud load balancer for every single service — expensive, unmanageable, and impossible to maintain at scale. This lab walks you through deploying and configuring the NGINX Ingress Controller on a production Kubernetes cluster, setting up path-based and host-based routing, enabling SSL termination, and applying rate limiting to protect your services.

By the end of this guide you will be able to:

• Deploy the NGINX Ingress Controller using Helm on a production cluster
• Configure host-based and path-based routing rules for multiple services
• Terminate SSL using Kubernetes TLS secrets and cert-manager
• Apply rate limiting and connection throttling annotations to protect APIs
• Troubleshoot common Ingress misconfiguration issues with real kubectl commands

Why This Matters in Production

Consider Razorpay running dozens of internal microservices — payments, dashboard, settlements, webhooks, and reporting. Without Ingress, each service needs its own cloud load balancer IP, multiplying infrastructure costs and SSL certificate management overhead. A single NGINX Ingress Controller handles all external traffic through one IP, routes it to the correct service based on hostname or path, terminates SSL centrally, and applies security policies uniformly.

At the scale of platforms like PhonePe or CRED, a misconfigured Ingress can mean routing payment traffic to the wrong backend, or leaving an internal admin service accidentally exposed to the public internet. Getting Ingress right is a fundamental production skill.

Core Principles

How traffic flows through an NGINX Ingress Controller:

Key components every engineer must understand:

• Ingress Controller — the actual NGINX pod that processes routing rules. Must be deployed separately — Kubernetes does not ship with one by default.
• Ingress Resource — the YAML object that defines the routing rules. Useless without a running controller to read and apply them.
• IngressClass — tells Kubernetes which controller should process a given Ingress resource. Critical when running multiple controllers in one cluster.
• Annotations — NGINX-specific configuration applied per Ingress resource to enable SSL redirect, rate limiting, custom timeouts, and more.

Detailed Step-by-Step Practical Lab

Step 1 — Deploy NGINX Ingress Controller Using Helm

REMEMBER THIS

**Remember:** The `EXTERNAL-IP` shown above is what your DNS records must point to. All your domain names (api.razorpay.in, dashboard.razorpay.in) should have A records pointing to this single IP.

Step 2 — Create a Basic Ingress Resource with Path-Based Routing

Step 3 — Enable SSL with cert-manager and Let's Encrypt

PLACEMENT PRO TIP

**Tip:** If the certificate stays in `False` state for more than 5 minutes, check the CertificateRequest and Order objects: `kubectl describe certificaterequest -n production` — it will show exactly which ACME challenge step failed.

Step 4 — Apply Rate Limiting to Protect APIs

Step 5 — Configure Host-Based Routing for Multiple Domains

COMMON MISTAKE / WARNING

**Security:** Never expose admin dashboards through a public Ingress without IP whitelisting. Add `nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8,YOUR_OFFICE_IP/32"` to the admin Ingress annotation block to restrict access to known IPs only.

Step 6 — Verify and Troubleshoot the Ingress

Production Best Practices & Common Pitfalls

• Always run at least 2 replicas of the Ingress Controller with a PodDisruptionBudget. A single controller pod is a single point of failure for all cluster traffic.
• Use externalTrafficPolicy: Local on the Ingress Controller service to preserve the real client IP in access logs — essential for rate limiting and security auditing.
• Set resource requests and limits on the Ingress Controller pods. An unthrottled controller under traffic spike can OOMKill and drop all traffic simultaneously.
• Always use IngressClass explicitly. Relying on the legacy kubernetes.io/ingress.class annotation causes unpredictable behaviour in newer Kubernetes versions.
• Separate Ingress resources per service rather than one monolithic Ingress. Smaller resources are easier to audit, roll back, and debug independently.

COMMON MISTAKE / WARNING

**Common Mistake:** Creating an Ingress resource without installing an Ingress Controller first. The Ingress object will be accepted by the API server with no errors but traffic will never be routed. Always confirm the controller is running with `kubectl get pods -n ingress-nginx` before creating Ingress resources.

Quick Reference & Troubleshooting Commands