Nginx-ingress

NGINX is the heart of the modern web, powering half of the world’s busiest sites and applications. The company’s comprehensive application delivery platform combines load balancing, content caching, web serving, security controls, and monitoring in one easy-to-use software package.

You may be interested in our ingress comparison article.

What is an ingress?

An Ingress is a Kubernetes resource that lets you configure an HTTP load balancer for your Kubernetes services. Such a load balancer usually exposes your services to clients outside of your Kubernetes cluster. An Ingress resource supports:

Exposing services:

• Via custom URLs (for example, service A at the URL /serviceA and service B at the URL /serviceB).
• Via multiple hostnames (for example, foo.example.com for one group of services and bar.example.com for another group).
• Configuring SSL termination for each exposed hostname.
• See the Ingress User Guide to learn more.

What is an Ingress Controller?

An Ingress controller is an application that monitors Ingress resources via the Kubernetes API and updates the configuration of a load balancer in case of any changes. Different load balancers require different Ingress controller implementations. Typically, an Ingress controller is deployed as a pod in a cluster. In the case of software load balancers, such as NGINX, an Ingress controller is deployed in a pod along with a load balancer.

NGINX Ingress Controller

We provide an Ingress controller for NGINX and NGINX Plus that supports the following Ingress features:

• SSL termination
• Path-based rules
• Multiple host names

We provide the following extensions to our Ingress controller:

• Websocket, which allows you to load balance Websocket applications.
• SSL Services, which allows you to load balance HTTPS applications.
• Rewrites, which allows you to rewrite the URI of a request before sending it to the application.
• Session Persistence (NGINX Plus only), which guarantees that all the requests from the same client are always passed to the same backend container.
• Support for JWTs (NGINX Plus only), which allows NGINX Plus to authenticate requests by validating JSON Web Tokens (JWTs).

Release 1.3.0 :

Release 1.3.0 includes:

• Prometheus support – You can now export NGINX Plus metrics to Prometheus, the most commonly used monitoring solution for Kubernetes.
• Improved Helm charts – This release extends our previously released Helm chart with support for additional Ingress controller parameters and deployment options.
• Improved mergeable Ingress resources – Make multi‑tenant deployments easier and more scalable by enabling different teams to independently manage Ingress resources for different paths of the same web application. Release 1.3.0 adds support for NGINX Plus dynamic reconfiguration and delegated JSON Web Token (JWT) authentication per path.
• Easier management of custom templates – The NGINX Ingress Controller generates NGINX configuration using templates. You now use a ConfigMap to modify the templates quickly and easily.
• Health checks – NGINX Plus active health checks are now supported.
• Status reporting – The Ingress controller now reports its public IP address in the status metrics reported for an Ingress resource.

What is the NGINX Ingress Controller for Kubernetes?

The NGINX Ingress controller for Kubernetes is a daemon that runs alongside NGINX Open Source or NGINX Plus instances in a Kubernetes environment. The daemon monitors Ingress resources (requests for external connectivity) for services deployed in Kubernetes. It then automatically configures NGINX or NGINX Plus to route and load balance traffic to these services.

Multiple NGINX Ingress controller implementations are available. The official NGINX implementation is high‑performance, production‑ready, and suitable for long‑term deployment. Compared to the community NGINX‑based offering, we focus more on maintaining stability across releases than on feature velocity. We provide full technical support to NGINX Plus subscribers at no additional cost, and NGINX Open Source users benefit from our focus on stability and supportability.

NGINX Ingress Controller 1.3.0 Features in Detail

Prometheus Support

Prometheus is the most commonly deployed monitoring and alerting system in Kubernetes environments. Release 1.3.0 adds support for a lightweight Prometheus exporter which publishes metrics from the NGINX Plus API for consumption by Prometheus.

Improved Helm Charts

Helm is an optional package manager for Kubernetes, and we added a basic Helm chart in release 1.2.0. This release improves the Ingress controller Helm chart with a number of additions, including the ability to:

• Deploy the new Prometheus exporter with the Ingress controller
• Publish the Ingress controller pods as a service to configure external access to them
• Configure various command‑line arguments of the Ingress controller
• Enable active health checks in NGINX Plus
• Enable role‑based access control (RBAC)

Improved Mergeable Ingress Resources

Mergeable Ingress resources are an important capability of the NGINX Ingress Controller, designed to make it easier to create and manage Ingress resources in a multi‑tenant fashion. This feature, introduced in release 1.2.0, is now improved with support for dynamic reconfiguration in NGINX Plus, and support for delegated JWT authentication, where different authentication settings are defined for different paths in a single Ingress resource.

Mergeable Ingress resources enable you to publish a single “master” Ingress resource which defines a virtual server, along with optional TLS parameters, and to then merge “minion” resources into the master. A minion resource contains the path definitions for a particular virtual server. Multiple minions can be deployed, and the NGINX Ingress controller automatically merges these with the master to create a single configuration.

In addition, any annotations that are defined at the global level within a minion only apply to the paths defined by that minion, making it much easier to customize the Ingress policy for each path independently.

This means that if several teams wish to publish their services through the same listen port, they do not need to coordinate to create a single Ingress resource. They can instead develop their Ingress resources and policies independently, and the NGINX Ingress Controller merges them automatically.

Easier Management of Customized Templates

The NGINX Ingress Controller generates NGINX configuration from Ingress resources, using a number of rules, defined in the main (global) and the Ingress (per‑virtual‑server) templates that map Ingress resources to NGINX configuration.

With release 1.3.0, it’s now possible to customize these templates using a ConfigMap. This is a more convenient alternative to baking the templates into the Ingress controller container image and redeploying it each time you need to change the templates. You should find this useful in a development environment, where you need to make modifications to the templates and test them quickly.

NGINX Plus Health Checks

The health checks in NGINX Plus provide an end‑to‑end way to detect and route around failures in the pods that make up a service. Unlike the standard Kubernetes readiness probes, when NGINX Plus performs a health check, it also verifies that the load balancer has network connectivity to each of the instances in the service. Therefore, by using NGINX Plus health checks in addition to the standard Kubernetes health checks, you can detect application errors more quickly, and even detect connectivity issues that the Kubernetes checks do not.

NGINX Plus health checks run the standard Kubernetes readiness probes, sending requests to a defined URL on each pod of a service and verifying that the response meets predefined criteria.

Status Reporting

The status metrics for an Ingress resource now include the public address (IP address or DNS name) of the Ingress controller, through which the services of that Ingress resource are publicly accessible.