nginx-ingress
NGINX is the heart of the modern web, powering half of the world’s busiest sites and applications. The company’s…
- Ingress
- 6.9K
NGINX is the heart of the modern web, powering half of the world’s busiest sites and applications. The company’s…
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.
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:
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.
We provide an Ingress controller for NGINX and NGINX Plus that supports the following Ingress features:
We provide the following extensions to our Ingress controller:
Release 1.3.0 includes:
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.
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.
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:
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.
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.
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.
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.
Tell us about a new Kubernetes application
Never miss a thing! Sign up for our newsletter to stay updated.
Discover and learn about everything Kubernetes
