Announcing NGINX Ingress Controller for Kubernetes Release 1.3.0
We are pleased to announce release 1.3.0 of the NGINX Ingress Controller for Kubernetes. This represents a milestone in the development of our supported solution for Ingress load balancing on Kubernetes platforms, including Amazon Elastic Container Service for Kubernetes (EKS), the Amazon Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift, IBM Cloud Private, Diamanti, and others.
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.
For more information, please see the documented example.
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.
For more information, please refer to the custom templates documentation.
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.
Check out the NGINX Plus Health Checks documentation for an example.
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. This address is now reported in the ADDRESS column of the output from the kubectl get ingress command, as shown below:
$ kubectl get ingresses
NAME HOSTS ADDRESS PORTS AGE
cafe-ingress cafe.example.com 1.2.3.4 80, 443 2mSee the documentation for configuring this feature.
Getting Started with the Ingress Controller
If you’d like to find out more about the NGINX Ingress controller for Kubernetes, check out these resources:
- On‑demand webinar: NGINX Ingress Controller: Getting Started
- For users familiar with Kubernetes, the Installation Instructions and Example sections in our GitHub repo
The NGINX Ingress controller supports both NGINX Open Source and NGINX Plus, and is a supported alternative to the community Ingress controller. A feature comparison for the two controllers is available here.
The main design goal of the NGINX Ingress Controller is to maintain performance and compatibility across releases. We provide full technical support to NGINX Plus subscribers at no additional cost, and open source users also benefit from the focus on long‑term stability and supportability.
The post Announcing NGINX Ingress Controller for Kubernetes Release 1.3.0 appeared first on NGINX.
Source: Announcing NGINX Ingress Controller for Kubernetes Release 1.3.0
Leave a Reply