NGINX Ingress Controller

Introduction

Kubernetes uses kube-proxy to expose Services and provide load balancing. The implementation is at the transport layer. When it comes to Internet applications, where a bucket-load of information is generated, forwarding needs to be more fine-grained, precisely and flexibly controlled by policies and load balancers to deliver higher performance.

This is where Ingresses enter. Ingresses provide application-layer forwarding functions, such as virtual hosts, load balancing, SSL proxy, and HTTP routing, for Services that can be directly accessed outside a cluster.

Kubernetes has officially released the Nginx-based Ingress controller. CCE NGINX Ingress Controller uses community templates and images. This add-on generates Nginx configuration and stores the configuration using ConfigMaps. The configuration will be written to Nginx pods through the Kubernetes API. In this way, the Nginx configuration is modified and updated. For details, see How Nginx Ingress Works.

You can visit the open-source community for more information.

• When installing NGINX Ingress Controller, you can specify Nginx parameters. These parameters take effect globally and are contained in the nginx.conf file. You can search for the parameters in ConfigMaps. If the parameters are not included in ConfigMaps, the configurations will not take effect.
• After the add-on is installed, you can interconnect the Ingress you create on the CCE console with Nginx and set Nginx Ingress functions using Annotations. For details about the supported annotation fields, see Annotations.
• Do not manually modify or delete the load balancer and listener that is automatically created by CCE. If the load balancer or listener is deleted, the workload will be abnormal. If you have modified or deleted them by mistake, uninstall NGINX Ingress Controller and re-install it.

How Nginx Ingress Works

An Nginx Ingress consists of the Ingress object, Ingress Controller, and Nginx. Ingress Controller assembles Ingress into the Nginx configuration file (nginx.conf) and reloads Nginx to make the configuration changes apply. When Ingress Controller detects that a pod in a Service changes, it dynamically changes the upstream server group configuration of Nginx. In this case, the Nginx process does not need to be reloaded. Figure 1 shows how an Nginx Ingress works.

• An Ingress is a group of access rules that forward requests to specified Services based on domain names or URLs. Ingresses are stored in etcd and can be added, deleted, modified, and queried through APIs.
• Ingress Controller monitors the changes of resource objects such as Ingresses, Services, endpoints, secrets (mainly TLS certificates and keys), nodes, and ConfigMaps in real time and automatically performs operations on Nginx.
• Nginx implements load balancing and access control at the application layer.

Figure 1 How Nginx Ingress works

Constraints

• Dedicated load balancers with private IP addresses bound and used for network load balancing (load balancing over TCP or UDP) should be selected.
• During the upgrade of NGINX Ingress Controller, 10s is reserved for deleting NGINX Ingress Controller deployed on the backend servers associated with a load balancer.
• The timeout duration for the graceful exit of NGINX Ingress Controller is 300s. If the timeout duration is longer than 300s during the upgrade of the NGINX Ingress Controller, persistent connections will be disconnected, and connectivity will be interrupted for a short period of time.

Prerequisites

Before creating a workload, you must have an available cluster. If no cluster is available, create one by performing the operations in Buying a CCE Autopilot Cluster.

Installing the Add-on

1. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane on the left, choose Add-ons. Locate NGINX Ingress Controller on the right and click Install.
2. On the Install Add-on page, configure the specifications.

   Table 1 NGINX Ingress Controller specifications

   Parameter	Description
   Pods	You can adjust the number of add-on instances as required.
   Containers	You can adjust the container specifications of an add-on instance as required.

3. Configure the add-on parameters.
   • Load Balancer: Select a dedicated load balancer. If no load balancer is available, create one. The load balancer has at least two listeners, and ports 80 and 443 are not occupied by listeners.
   • Admission Check: If this option is enabled, an admission check will be performed on the configuration of Nginx Ingresses. If the configuration files the admission check, requests to the Ingresses will be intercepted. For details about verification, see Access Control.
     

     • Admission checks slow down the responses to Ingress requests.
     • Admission checks are only available for the add-on v2.4.1 or later.
   • Nginx Parameters: Configuring the nginx.conf file will affect all managed Ingresses. You can search for related parameters through ConfigMaps. If the parameters you configured are not included in the options listed in ConfigMaps, the parameters will not take effect.

     For example, you can use the keep-alive-requests parameter to describe how to set the maximum number of requests for keeping active connections to 100.

     {
         "keep-alive-requests": "100"
     }

   • Default 404 Service: By default, the 404 service provided by the add-on is used. To customize the 404 service, enter the namespace/service name. If the service does not exist, the add-on installation will fail.

4. Click Install.

Components