Kubernetes Ingress

In simple terms, Kubernetes Ingress is like a smart receptionist for your cluster. When you deploy applications inside Kubernetes, they are usually hidden from the outside world. To let users access your website or API, you need a safe and efficient doorway. Instead of giving every single app its own expensive public IP address (LoadBalancer), Ingress gives you a single entry point. It smartly looks at the incoming request (like www.devsecopsguru.in/app1) and routes the traffic to the exact right place inside your cluster.

Imagine a huge corporate building (your Kubernetes Cluster). Inside, there are hundreds of different departments (your Pods/Services).

If you just use a standard LoadBalancer, it is like building a dedicated physical door from the street straight into the HR department, another door for IT, and another for Sales. That gets expensive and messy!

Ingress is the grand main reception lobby. There is only one main door (one IP address). When a visitor (an HTTP request) walks in, the smart receptionist (the Ingress Controller) looks at their ID card and the floor directory (Ingress Rules), and guides them to the exact right elevator and floor they need to reach.

Key Details to Remember

Here is your quick-revision cheat sheet before an interview or certification exam!

• Ingress Object: A simple YAML file that holds the routing rules (e.g., if path is /billing, go to billing-service).
• Ingress Controller: The actual brain/software (like NGINX or Traefik) that reads the YAML and actively routes the traffic.
• Layer 7 Load Balancing: Ingress operates at the HTTP/HTTPS level (Application Layer), allowing smart routing based on URLs and headers.
• SSL/TLS Termination: Ingress can decrypt HTTPS traffic at the edge, saving your backend pods from doing the heavy cryptographic lifting.
• Default Backend: A fallback service that catches all traffic that doesn’t match any of your defined rules (usually displays a 404 error page).

Feature	ClusterIP	NodePort	LoadBalancer	Ingress
Accessibility	Internal only	External (via Node IP)	External (Cloud IP)	External (Smart HTTP/S Routing)
Cost	Free	Free	High (1 IP per service)	Very Low (Shares 1 IP)
OSI Layer	Layer 4 (TCP/UDP)	Layer 4 (TCP/UDP)	Layer 4 (TCP/UDP)	Layer 7 (HTTP/HTTPS)
Best For	Internal Pod-to-Pod talk	Dev/Test setups	Exposing a single massive app	Exposing multiple web apps/APIs

If you are a beginner, you need to understand the building blocks perfectly. Let’s break down the foundation:

1. The Problem: By default, Pods get dynamic internal IPs. Services group these Pods and give them a stable internal IP (ClusterIP). But the outside world still cannot see them.
2. The Basic Solutions: You could use NodePort (opens a port like 30080 on every node) or LoadBalancer (asks AWS/GCP to spin up an expensive external load balancer).
3. The Ingress Solution: You deploy an Ingress Controller (which is just another Pod, usually running NGINX). You expose only this Controller using a single Cloud LoadBalancer. Then, you write Ingress API rules to say: “Hey NGINX, if traffic comes for domain.com/appA, send it to Service A. If it comes for domain.com/appB, send it to Service B.”

---

The Architecture: How Ingress Works

To make Ingress work in your Kubernetes cluster, you need two things: a rulebook and someone to read and enforce that rulebook.

1. The Ingress Resource: A set of routing rules defined by the developer (written in YAML) that dictates how traffic should flow based on HTTP/HTTPS hostnames and paths.
2. The Ingress Controller: A specialized reverse proxy and load balancer (like NGINX, Traefik, or HAProxy) running inside the cluster. It constantly monitors the Kubernetes API server for Ingress resources and actively enforces their rules.

Think of building a new house.

• The Ingress Resource is the Architect’s Blueprint. It beautifully describes where the doors, windows, and rooms should be. But a blueprint on a piece of paper cannot protect you from the rain.
• The Ingress Controller is the Construction Crew. They look at the blueprint, bring the bricks and cement, and actually build the walls and doors.

Without the construction crew (Controller), your blueprint (Resource) is just a piece of paper doing nothing!

Note: Creating an Ingress resource without an active Ingress Controller will do absolutely nothing. The resource is just a blueprint; the controller is the engine.

Key Details to Remember

• The Dependency Rule: An Ingress Resource is completely useless without a running Ingress Controller.
• The Resource: A declarative YAML file defining hosts, paths, and backend services.
• The Controller: A reverse proxy (like NGINX) packaged in a Pod that constantly watches the Kubernetes API for new rules.
• Dynamic Updates: When you update an Ingress Resource, the Controller automatically reloads its configuration in real-time without dropping traffic.

Feature	Ingress Resource	Ingress Controller
What is it?	A set of routing rules (YAML)	A running software application (Pod)
Who makes it?	Created by Developers/Engineers	Installed by Cluster Administrators
Function	Tells what should happen	Does the actual work of how it happens
Examples	kind: Ingress YAML	NGINX, Traefik, HAProxy

For a strong foundation, you need to understand the exact flow of how these two components talk to each other:

1. You write the YAML: You create a file named my-ingress.yaml specifying that traffic for devsecopsguru.in should go to the frontend-service.
2. You apply it: You run kubectl apply -f my-ingress.yaml.
3. API Server Stores It: The Kubernetes API server saves this rule in its etcd database.
4. The Watcher: The Ingress Controller (which is already running in your cluster) has a continuous “watch” open with the API server.
5. The Update: The API server immediately notifies the Ingress Controller: “Hey, a new rule was just added!”
6. The Action: The Ingress Controller reads the rule, updates its own routing table (for example, regenerating its NGINX configuration file), and smoothly reloads itself to start routing the new traffic.

For DevSecOps Architects, the architecture gets much more interesting when we look at production-grade implementations.

Under the Hood of the Controller

• Informer Pattern: Controllers use the Kubernetes client-go SharedInformer cache. They don’t constantly poll the API server; instead, they maintain a local cache of Ingress, Service, and Endpoint objects, receiving event-driven updates to minimize API load.
• Endpoint Routing: Advanced controllers (like NGINX Ingress or AWS ALB Controller) often bypass kube-proxy and ClusterIP entirely. They read the Kubernetes Endpoints API and route traffic directly to the Pod IPs. This removes an extra hop of network translation (iptables/IPVS), significantly reducing latency.
• Leader Election: In a highly available (HA) setup, you will run multiple replicas of the Ingress Controller. To prevent race conditions when updating cluster statuses (like writing the LoadBalancer IP back to the Ingress object), the controllers use Kubernetes Leases for leader election. Only the leader updates the API status, while all replicas process data-plane traffic.

Essential Architect Tools

• ExternalDNS: Automatically creates DNS records in AWS Route53 or Cloudflare based on the hostnames defined in your Ingress Resources.

Key Components

1. API Server: The central nervous system storing the Ingress rules.
2. Ingress Resource: The declarative ruleset.
3. Ingress Controller Pods: The data-plane workers routing the traffic.
4. Cloud LoadBalancer: The external Layer 4 entry point that funnels public internet traffic to the Controller Pods.

• Benefit – Separation of Concerns: Developers only need to worry about writing simple Ingress YAMLs for their apps. The Platform Team manages the complex Ingress Controller deployment and security.
• Best Practice – IngressClasses: Always use the ingressClassName field in your Ingress resources. In production, you might run an internal NGINX controller for private APIs and a public Traefik controller for your website. The class tells Kubernetes exactly which controller should handle which blueprint.

Problem	Root Cause	Solution
Ingress created, but no address is assigned.	You forgot to install the Ingress Controller, or the controller’s Service isn’t getting an IP from the cloud provider.	Ensure the controller is running (kubectl get pods -n ingress-nginx). Check if its LoadBalancer service is pending.
Controller Reload Spikes.	If you have thousands of Ingress resources, updating one can cause the controller to reload its entire config, causing CPU spikes and dropped connections.	Use controllers that support dynamic configuration without full reloads (like Envoy-based controllers or Traefik), or tune NGINX worker shutdown parameters.
Conflicting Rules.	Two developers create an Ingress Resource requesting the exact same hostname and path.	The controller behavior is often undefined (it might pick the oldest one). Implement admission controllers (like OPA Gatekeeper or Kyverno) to prevent overlapping rules from being applied.

• Kubernetes: Ingress Controllers
• NGINX Ingress Architecture Explained

For production-grade systems, a simple NGINX setup is not enough. An architect must design for high availability, security, observability, and scale.

Production-Grade Architecture Decisions

• High Availability (HA): Never run a single replica of an Ingress Controller. Deploy it as a Deployment or DaemonSet with multiple replicas spread across different Availability Zones (AZs) using podAntiAffinity.
• Security (WAF Integration): Embed a Web Application Firewall directly into the Ingress layer. ModSecurity or NGINX App Protect can block SQL injection, XSS, and zero-day vulnerabilities before they ever reach your application pods.
• Automated TLS/SSL: Do not manage certificates manually. Integrate cert-manager to automatically provision and renew Let’s Encrypt certificates directly via Ingress annotations (kubernetes.io/tls-acme: "true").
• Advanced Routing (Canary/Blue-Green): Modern ingress controllers allow traffic splitting. You can route exactly 5% of traffic to a new “Canary” version of your app by simply tweaking Ingress annotations.

The Future: Gateway API Kubernetes has introduced the Gateway API, which is the evolutionary successor to Ingress. It splits responsibilities into different personas (Infrastructure Provider, Cluster Operator, Application Developer) and natively supports advanced features like header-based routing, traffic mirroring, and TCP/UDP routing without needing messy annotations. If you are architecting a cluster for 2026 and beyond, you must evaluate the Gateway API alongside traditional Ingress!

Key Components

1. Ingress Resource: The YAML definition of your routing rules.
2. Ingress Controller: The reverse proxy (NGINX, Envoy, HAProxy) executing the rules.
3. Default Backend: The catch-all service for unhandled routes.
4. IngressClass: Used to specify which controller should process the rules (essential when running multiple controllers in one cluster).

Key Characteristics

• Layer 7 Routing: Understands HTTP verbs, URLs, and cookies.
• Decoupled: The rules are decoupled from the infrastructure provisioning.
• Extensible: Heavily customizable via annotations (e.g., rate-limiting, CORS, URL rewrites).

Use Cases

• Hosting multiple microservices under a single domain name.
• Offloading SSL decryption to reduce CPU load on application pods.
• Implementing sticky sessions for legacy applications.
• A/B testing new website features based on user headers.

Benefits

• Cost-Effective: Consolidates multiple cloud load balancers into one.
• Centralized Security: One place to apply SSL certs and WAF rules.
• Simplified Client Access: Users only need to know one domain name.

Best Practices

• Namespaces: Keep your Ingress resources in the same namespace as the Services they route to (Ingress cannot route across namespaces natively without advanced configurations).
• Rate Limiting: Always apply rate-limiting annotations to protect your APIs from DDoS attacks or runaway scripts.
• Timeouts: Configure proxy-read and proxy-send timeouts appropriately to prevent hung connections from consuming all proxy worker threads.
• Observability: Expose Prometheus metrics from your Ingress controller and set up alerts for 5xx error rates and high latency.

Limitations

• Namespace Restriction: Standard Ingress cannot route traffic to a Service in a different Namespace. (Solution: Use ExternalName services or upgrade to Gateway API).
• Annotation Hell: Advanced logic requires dozens of controller-specific annotations, leading to vendor lock-in.

Common Issues & Solutions

Problem	Root Cause	Solution
502 Bad Gateway	The Ingress Controller cannot reach the application Pod.	Check if the target Pod is running and passing its Readiness Probe. Verify the servicePort matches the Service exactly.
404 Not Found	The request URL does not match any rule, hitting the default backend.	Check your pathType (Prefix vs Exact) and ensure the host header in your curl or browser matches the YAML.
Too Many Redirects	HTTP to HTTPS redirection loop.	Ensure your cloud load balancer isn’t decrypting SSL and sending HTTP to the Ingress while the Ingress is trying to force HTTPS. Check ssl-redirect annotations.
Changes not applying	Controller is ignoring the Ingress resource.	Ensure ingressClassName is specified correctly in the spec, matching your installed controller.

Ingress vs. LoadBalancer vs. NodePort

Understanding when to use Ingress requires comparing it against the other methods for exposing services:

Feature	NodePort	LoadBalancer	Ingress
How it Works	Opens a static port (30000-32767) on every node in the cluster.	Provisions a cloud provider’s external load balancer (e.g., AWS ALB, GCP Load Balancer).	Acts as a smart router in front of your services, using a single external IP.
Routing	Layer 4 (TCP/UDP). No routing logic.	Layer 4 (TCP/UDP). Distributes traffic evenly.	Layer 7 (HTTP/HTTPS). Path-based and host-based routing.
Cost & Scalability	Low cost, but highly unscalable and difficult to manage port conflicts.	Expensive. Requires a dedicated load balancer per service exposed.	Highly cost-effective. One load balancer can serve dozens of services.
Best For	Local development, quick debugging. Not for production.	Exposing a single, high-traffic service or non-HTTP traffic.	Production environments with multiple microservices and HTTP/HTTPS traffic.

---

Core Routing Concepts

Ingress acts as a super-smart traffic cop for your Kubernetes cluster. Instead of setting up a new LoadBalancer for every single application (which gets very expensive), you use one Ingress Controller. You can tell this controller to route traffic in two main ways:

1. Host-Based Routing: You look at the domain name the user typed (like api.devsecopsguru.in vs app.devsecopsguru.in) and send them to different apps.
2. Path-Based Routing: You use a single domain name, but look at the end of the URL (like devsecopsguru.in/billing vs devsecopsguru.in/checkout) to send them to the right place.

Key Details to Remember

• Consolidation: Ingress allows you to squeeze dozens of microservices behind a single public IP address.
• Name-Based Virtual Hosting: The technical term for Host-Based routing. It relies on the HTTP Host header sent by the user’s browser.
• Microservice Split: Path-based routing is the absolute best way to break down an old, heavy monolithic application piece by piece.
• Order Matters: Ingress controllers read rules from top to bottom. Always put your most specific paths first!

Feature	Host-Based Routing	Path-Based Routing
What it checks	The domain name (e.g., api.example.com)	The URL suffix (e.g., example.com/api)
Best Used For	Completely separate applications or environments	Different modules of the exact same application
DNS Setup	Requires multiple DNS records pointing to the same IP	Requires only one DNS record
TLS/SSL Certificates	Requires a Wildcard cert or multiple SANs	Can use a single standard SSL certificate

Ingress allows you to consolidate traffic rules. You can route external traffic to different microservices based on specific parameters.

1. Host-Based Routing (Name-Based Virtual Hosting): This method routes traffic to different backend services based on the domain name requested by the client, even if both domains point to the exact same external IP address. The Ingress Controller inspects the Host header of the incoming HTTP request.

• api.example.com → Routes to the api-service
• app.example.com → Routes to the frontend-service

2. Path-Based Routing: This routes traffic based on the URL path following the domain name. It is highly effective for splitting up a monolithic domain into discrete microservices without the user ever knowing they are talking to different backend servers.

• example.com/billing → Routes to the billing-service
• example.com/checkout → Routes to the checkout-service

At a production level, simple routing isn’t enough. You will encounter complex scenarios requiring advanced DevSecOps configurations.

Advanced Architect Considerations

• The Rewrite Target Problem: When you route example.com/billing to the billing-service, the backend pod receives the request as /billing. If your Node.js or Python app is only listening on the root /, it will throw a 404 error! You must use annotations like nginx.ingress.kubernetes.io/rewrite-target: /$1 to strip the path before it hits the pod.
• Regex Path Matching: You aren’t limited to simple prefixes. By setting pathType: ImplementationSpecific or Exact and using annotations (e.g., nginx.ingress.kubernetes.io/use-regex: "true"), you can route traffic using complex Regular Expressions (like capturing user IDs in the URL).
• Wildcard Hosts: You can use wildcard domains (e.g., *.devsecopsguru.in) in your rules. This is fantastic for multi-tenant SaaS applications where every customer gets their own subdomain automatically mapped to a specific namespace or service.

1. Path Types: Kubernetes requires you to define a pathType. The most common are Prefix (matches /billing and /billing/history) and Exact (matches only /billing, not /billing/history). This distinction prevents major routing bugs.
2. Server Name Indication (SNI): When doing Host-Based routing with HTTPS, the Ingress Controller uses SNI to figure out which SSL certificate to present to the client before the HTTP request is even decrypted.
3. Combinations: You do not have to pick just one! You can perfectly combine Host and Path routing (e.g., api.example.com/v1/ goes to Service A, while api.example.com/v2/ goes to Service B).

Industry Standard Tools

• ExternalDNS: Automates the creation of DNS records for your Host-Based routing directly into AWS Route53, Google Cloud DNS, or Cloudflare.
• cert-manager: For Host-based routing, you need SSL for every domain. Cert-manager can automatically issue Let’s Encrypt Wildcard certificates using DNS01 challenges.

DevSecOps Best Practices for Ingress

Securing the entry point of your cluster is a primary defense-in-depth strategy. When configuring Ingress, adhere to these security principles:

• SSL/TLS Termination: Never transmit unencrypted traffic over the internet. Configure your Ingress to handle TLS termination. This offloads the decryption burden from your application pods and centralizes certificate management.
• Implement a WAF (Web Application Firewall): Many Ingress controllers (like NGINX or AWS ALB) support WAF integrations. This protects backend services from common OWASP Top 10 vulnerabilities like SQL injection and cross-site scripting (XSS) before the traffic ever reaches the pod.
• Enforce Rate Limiting: Prevent DDoS attacks and brute-force attempts by applying rate-limiting annotations directly to the Ingress resource, restricting how many requests a single IP can make per second.
• Strict Path Matching: Avoid overly permissive path rules. Use Exact path matching where possible instead of Prefix to prevent unintended exposure of internal application directories.

Key Components

• Host Header: The crucial HTTP header that makes name-based virtual hosting possible.
• Path Definition: The URI string defined in the YAML.
• PathType: Strict rules on how the controller interprets the path string (Prefix, Exact, ImplementationSpecific).

Use Cases

• Host-Based: Hosting dev.app.com, qa.app.com, and prod.app.com on the same cluster to save cloud costs.
• Path-Based: Serving a React frontend from / and a Go backend API from /api.

Benefits

• Extreme cost efficiency (one LoadBalancer for 50+ services).
• Clean, human-readable URLs.
• Centralized traffic management.

Best Practices

• Trailing Slashes: Be extremely careful with trailing slashes. /billing and /billing/ can sometimes be treated differently depending on the controller. Standardize your approach!
• Default Backend: Always define a custom default backend to catch traffic that doesn’t match your Host or Path rules so users get a branded 404 page instead of an ugly default NGINX error.

Problem	Root Cause	Solution
Path Overlap (Routing to wrong service)	You defined /app and /app/v2 but put /app first. The controller caught it early.	Define your most specific, longest paths first in the YAML rules array.
Backend App throws 404	The app receives the full Ingress path (e.g., /api) but only knows how to serve /.	Use the rewrite-target annotation to strip the prefix before sending traffic to the pod.
Host-based routing not working locally	Your local machine’s DNS doesn’t know what app.local is.	You must manually add an entry to your /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts) mapping the domain to your Minikube/Cluster IP.

• https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types
• https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting
• https://kubernetes.github.io/ingress-nginx/examples/rewrite