NGINX Ingress Controller: Kubernetes Traffic Routing

Understanding the NGINX Ingress Controller

NGINX Ingress Controller is the official Ingress Controller for Kubernetes, built and maintained by the NGINX team at F5. It runs as a pod in your cluster, watching Ingress and its own VirtualServer/VirtualServerRoute resources to reconfigure the NGINX load balancer — handling host/path routing, TLS termination, and load balancing for Websocket, gRPC, TCP, and UDP. It's a different codebase from kubernetes/ingress-nginx.

Key Features for Kubernetes Traffic

• ✓Content-based routing via standard Ingress: host-based routing (e.g., foo.example.com vs bar.example.com) and path-based routing (e.g., /serviceA vs /serviceB).
• ✓TLS/SSL termination configured per hostname.
• ✓VirtualServer and VirtualServerRoute custom resources for traffic splitting and advanced content-based routing beyond what the Ingress spec supports.
• ✓The TransportServer resource covers TCP, UDP, and TLS Passthrough traffic.
• ✓Load balancing for Websocket and gRPC applications in addition to HTTP.
• ✓Extra NGINX/NGINX Plus behavior exposed through annotations and the ConfigMap resource, without needing a custom resource for every tweak.

Installing the Ingress Controller

The README doesn't paste install commands directly — it points to a Helm chart or a set of Kubernetes manifests, both linked from the docs, so treat those pages as the source of truth for exact steps. What is confirmed: the current stable release is 5.5.4, and its images are published to DockerHub, the GitHub Container registry, the Amazon ECR Public Gallery, and Quay.io (NGINX Plus images come from F5's own container registry, or you build your own from source). The README stresses that the image, the manifests/Helm chart, and the docs you follow all need to match versions — pairing an edge image with the 5.5.4 manifests, for example, isn't supported. After installing, the README's own next step is configuring a simple app either through the plain Ingress resource (its Cafe example) or the VirtualServer resource (its basic-configuration example).

Configuring Ingress and Advanced Routing

Two configuration paths exist side by side. The plain Ingress resource handles host- and path-based routing plus per-hostname TLS termination — the same shape as any Kubernetes Ingress, extended with annotations and a ConfigMap resource when you need to reach past the Ingress spec's own fields. VirtualServer and VirtualServerRoute are the second path, purpose-built for traffic splitting and content-based routing the plain Ingress object can't express, and the README ships a basic-configuration example for that route. For traffic that isn't HTTP at all, the TransportServer resource handles TCP, UDP, and TLS Passthrough. Beyond routing shape, the controller load-balances Websocket and gRPC traffic the same way it does HTTP. Every example referenced lives in the repo's examples/ directory, alongside the fuller configuration-examples docs.

Distinguishing from Other NGINX Ingress Options

Frequently Asked Questions

The problem it solves

Kubernetes' built-in Ingress resource only standardizes the basics — host/path routing and per-hostname TLS — and leaves protocols like gRPC, raw TCP/UDP, and traffic-splitting patterns like canary releases outside its spec entirely. NGINX Ingress Controller exists to close that gap for people already running NGINX: it implements the standard Ingress object, then layers its own VirtualServer/VirtualServerRoute and TransportServer custom resources on top so those un-standardized cases don't require bolting on a second, unrelated load balancer.

Best use cases

• •Running production HTTP(S) ingress for services on Kubernetes where the team already standardizes on NGINX and wants vendor support behind it.
• •Splitting traffic — canary or blue-green style routing — via VirtualServer/VirtualServerRoute when plain Ingress's simple path/host matching isn't enough.
• •Load balancing non-HTTP protocols — Websocket, gRPC, raw TCP/UDP — through one controller instead of bolting on a separate L4 load balancer.
• •TLS Passthrough for workloads that need to terminate TLS themselves rather than at the ingress, handled through the TransportServer resource.
• •Teams on NGINX Plus who want a commercial support contract tied directly to their ingress layer.

Who should try it — and who should skip

Reach for NGINX Ingress Controller if your team already standardizes on NGINX, needs routing beyond what plain HTTP Ingress can express — traffic splitting, gRPC, raw TCP/UDP — or wants a straight line to NGINX Plus's commercial support. Skip it if you just need basic HTTP routing with no existing NGINX preference, since you'd be learning the VirtualServer/VirtualServerRoute CRDs on top of standard Ingress for capabilities you may not need, or if you're already deep in kubernetes/ingress-nginx and don't want a second, differently-configured controller running alongside it.

Related repositories