What is the career path for learning Configuring Ingress Controllers with NGINX for Production Traffic?

Mastering Configuring Ingress Controllers with NGINX for Production Traffic enables engineering opportunities in DevOps, SRE, and cloud platform automation.

Configuring Ingress Controllers with NGINX for Production Traffic | DevOps Network

Q: How long does it take to learn Configuring Ingress Controllers with NGINX for Production Traffic?

Most students gain core proficiency in Configuring Ingress Controllers with NGINX for Production Traffic in 2–3 weeks of active hands-on labs.

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:

◈ DIAGRAM

External User Request (https://api.razorpay.in/v1/payments)
        │
        ▼
Cloud Load Balancer (single external IP — provisioned by cloud provider)
        │
        ▼
NGINX Ingress Controller Pod (reads Ingress rules from API server)
        │
        ├─► Host: api.razorpay.in + Path: /v1/payments
        │       └─► payments-service:4000
        │
        ├─► Host: api.razorpay.in + Path: /v1/dashboard
        │       └─► dashboard-service:8080
        │
        └─► Host: admin.razorpay.in
                └─► admin-service:9000 (internal only)

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

Bash

1# Add the official ingress-nginx Helm repository
2helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
3helm repo update
4 
5# Deploy NGINX Ingress Controller into its own namespace
6helm install ingress-nginx ingress-nginx/ingress-nginx \
7  --namespace ingress-nginx \
8  --create-namespace \
9  --set controller.replicaCount=2 \
10  --set controller.nodeSelector."kubernetes\.io/os"=linux \
11  --set controller.service.externalTrafficPolicy=Local
12 
13# Verify the controller pods are running
14kubectl get pods -n ingress-nginx
15 
16# Get the external IP assigned by the cloud load balancer
17kubectl get service ingress-nginx-controller -n ingress-nginx
18# NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)
19# ingress-nginx-controller   LoadBalancer   10.96.12.100   34.93.45.201     80:31080/TCP,443:31443/TCP

📌 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

YAML

1# ingress-basic.yaml — route traffic to two backend services
2apiVersion: networking.k8s.io/v1
3kind: Ingress
4metadata:
5  name: razorpay-api-ingress
6  namespace: production
7  annotations:
8    nginx.ingress.kubernetes.io/ssl-redirect: "true"           # Force HTTPS
9    nginx.ingress.kubernetes.io/use-regex: "true"              # Enable regex paths
10    nginx.ingress.kubernetes.io/proxy-body-size: "10m"         # Max request body size
11    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"    # Connection timeout seconds
12    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"       # Read timeout seconds
13spec:
14  ingressClassName: nginx                # Must match your installed IngressClass
15  rules:
16    - host: api.razorpay.in
17      http:
18        paths:
19          - path: /v1/payments
20            pathType: Prefix
21            backend:
22              service:
23                name: payments-service
24                port:
25                  number: 4000
26          - path: /v1/dashboard
27            pathType: Prefix
28            backend:
29              service:
30                name: dashboard-service
31                port:
32                  number: 8080
33          - path: /v1/webhooks
34            pathType: Prefix
35            backend:
36              service:
37                name: webhook-service
38                port:
39                  number: 5000

Bash

1kubectl apply -f ingress-basic.yaml
2 
3# Verify Ingress was created and has an address
4kubectl get ingress -n production
5# NAME                    CLASS   HOSTS              ADDRESS          PORTS   AGE
6# razorpay-api-ingress    nginx   api.razorpay.in    34.93.45.201    80, 443   2m

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

Bash

1# Install cert-manager for automatic SSL certificate provisioning
2helm repo add jetstack https://charts.jetstack.io
3helm repo update
4 
5helm install cert-manager jetstack/cert-manager \
6  --namespace cert-manager \
7  --create-namespace \
8  --set installCRDs=true
9 
10# Verify cert-manager pods are running
11kubectl get pods -n cert-manager

YAML

1# cluster-issuer.yaml — configure Let's Encrypt production certificate issuer
2apiVersion: cert-manager.io/v1
3kind: ClusterIssuer
4metadata:
5  name: letsencrypt-production
6spec:
7  acme:
8    server: https://acme-v02.api.letsencrypt.org/directory
9    email: rahul@devopsnetwork.in          # Must be a real monitored email
10    privateKeySecretRef:
11      name: letsencrypt-production-key
12    solvers:
13      - http01:
14          ingress:
15            class: nginx

Bash

1kubectl apply -f cluster-issuer.yaml

YAML

1# ingress-ssl.yaml — Ingress with automatic SSL certificate
2apiVersion: networking.k8s.io/v1
3kind: Ingress
4metadata:
5  name: razorpay-api-ingress
6  namespace: production
7  annotations:
8    nginx.ingress.kubernetes.io/ssl-redirect: "true"
9    cert-manager.io/cluster-issuer: "letsencrypt-production"   # Auto-provision SSL
10spec:
11  ingressClassName: nginx
12  tls:
13    - hosts:
14        - api.razorpay.in
15        - dashboard.razorpay.in
16      secretName: razorpay-tls-secret     # cert-manager stores the cert here
17  rules:
18    - host: api.razorpay.in
19      http:
20        paths:
21          - path: /
22            pathType: Prefix
23            backend:
24              service:
25                name: payments-service
26                port:
27                  number: 4000
28    - host: dashboard.razorpay.in
29      http:
30        paths:
31          - path: /
32            pathType: Prefix
33            backend:
34              service:
35                name: dashboard-service
36                port:
37                  number: 8080

Bash

1kubectl apply -f ingress-ssl.yaml
2 
3# Watch the SSL certificate being issued — takes 60-120 seconds
4kubectl get certificate -n production -w
5# NAME                   READY   SECRET                  AGE
6# razorpay-tls-secret    True    razorpay-tls-secret     90s

💡 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

YAML

1# ingress-ratelimit.yaml — protect the payments API from abuse
2apiVersion: networking.k8s.io/v1
3kind: Ingress
4metadata:
5  name: payments-ingress-protected
6  namespace: production
7  annotations:
8    nginx.ingress.kubernetes.io/ssl-redirect: "true"
9    cert-manager.io/cluster-issuer: "letsencrypt-production"
10 
11    # Rate limiting — critical for payment APIs
12    nginx.ingress.kubernetes.io/limit-rps: "20"              # Max 20 requests/second per IP
13    nginx.ingress.kubernetes.io/limit-connections: "10"       # Max 10 concurrent connections per IP
14    nginx.ingress.kubernetes.io/limit-burst-multiplier: "5"  # Allow bursts up to 100 rps briefly
15 
16    # Security headers
17    nginx.ingress.kubernetes.io/configuration-snippet: |
18      more_set_headers "X-Frame-Options: DENY";
19      more_set_headers "X-Content-Type-Options: nosniff";
20      more_set_headers "Referrer-Policy: strict-origin-when-cross-origin";
21spec:
22  ingressClassName: nginx
23  tls:
24    - hosts:
25        - api.razorpay.in
26      secretName: razorpay-tls-secret
27  rules:
28    - host: api.razorpay.in
29      http:
30        paths:
31          - path: /v1/payments
32            pathType: Prefix
33            backend:
34              service:
35                name: payments-service
36                port:
37                  number: 4000

Step 5 — Configure Host-Based Routing for Multiple Domains

YAML

1# ingress-multidomain.yaml — separate domains to separate services
2apiVersion: networking.k8s.io/v1
3kind: Ingress
4metadata:
5  name: razorpay-multidomain-ingress
6  namespace: production
7  annotations:
8    nginx.ingress.kubernetes.io/ssl-redirect: "true"
9    cert-manager.io/cluster-issuer: "letsencrypt-production"
10spec:
11  ingressClassName: nginx
12  tls:
13    - hosts:
14        - api.razorpay.in
15        - admin.razorpay.in
16        - webhooks.razorpay.in
17      secretName: razorpay-multidomain-tls
18  rules:
19    - host: api.razorpay.in              # Public API — internet facing
20      http:
21        paths:
22          - path: /
23            pathType: Prefix
24            backend:
25              service:
26                name: public-api-service
27                port:
28                  number: 4000
29 
30    - host: admin.razorpay.in            # Admin panel — restrict via firewall rules
31      http:
32        paths:
33          - path: /
34            pathType: Prefix
35            backend:
36              service:
37                name: admin-service
38                port:
39                  number: 9000
40 
41    - host: webhooks.razorpay.in         # Webhook receiver — high timeout needed
42      http:
43        paths:
44          - path: /
45            pathType: Prefix
46            backend:
47              service:
48                name: webhook-service
49                port:
50                  number: 5000

⚠️ 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

Bash

1# Check Ingress resource status and backend addresses
2kubectl describe ingress razorpay-api-ingress -n production
3 
4# Check NGINX Ingress Controller logs for routing errors
5kubectl logs -n ingress-nginx \
6  -l app.kubernetes.io/name=ingress-nginx \
7  --tail=100 -f
8 
9# Test routing from inside the cluster using a debug pod
10kubectl run curl-test --image=curlimages/curl -it --rm -n production -- sh
11 
12# Inside the debug pod — test internal routing
13curl -H "Host: api.razorpay.in" http://10.96.12.100/v1/payments

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: 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

Command	Purpose
`kubectl get ingress -n <ns>`	List all Ingress resources and their addresses
`kubectl describe ingress <name> -n <ns>`	Full Ingress config with backend endpoint status
`kubectl get ingressclass`	List available IngressClass controllers in cluster
`kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx`	NGINX controller logs for routing errors
`kubectl get certificate -n <ns>`	SSL certificate issuance status
`kubectl describe certificaterequest -n <ns>`	Debug failed SSL certificate provisioning
`kubectl get events -n ingress-nginx --sort-by='.lastTimestamp'`	Ingress controller event timeline
`helm upgrade ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx`	Upgrade NGINX Ingress Controller version
`kubectl exec -it <nginx-pod> -n ingress-nginx -- nginx -t`	Validate generated NGINX config inside controller

Syncing Data

Configuring Ingress Controllers with NGINX for Production Traffic

Configuring Ingress Controllers with NGINX for Production Traffic

Overview and What You Will Learn

Why This Matters in Production

Core Principles

Detailed Step-by-Step Practical Lab

Step 1 — Deploy NGINX Ingress Controller Using Helm

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

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

Step 4 — Apply Rate Limiting to Protect APIs

Step 5 — Configure Host-Based Routing for Multiple Domains

Step 6 — Verify and Troubleshoot the Ingress

Production Best Practices & Common Pitfalls

Quick Reference & Troubleshooting Commands

Resources

Explore More in Kubernetes Workload Management

Troubleshooting Kubernetes Pod OOMKilled and CrashLoopBackOff Errors

Managing Kubernetes Secrets with Vault and ConfigMaps

Scaling Deployments with Horizontal Pod Autoscaler (HPA)

Implementing Role-Based Access Control (RBAC) in Kubernetes