An Ingress is an API object that provides Layer 7 load balancing to manage external access to Services in a Kubernetes cluster. This topic introduces Ingresses, and describes how an Ingress controller works and how to use an Ingress controller.
Table of contents
What is an Ingress
In a Kubernetes cluster, an Ingress functions as an access point that exposes Services in the cluster. It distributes most of the network traffic that is destined for the Services in the cluster. An Ingress is a Kubernetes resource object that is used to enable external access to Services in a Kubernetes cluster. You can configure routing rules for an Ingress to route network traffic to backend pods of different Services.
You can configure only HTTP traffic routing rules on Ingresses. Ingresses do not support advanced features such as load balancing algorithms and session affinity. To enable these features, you must configure them on Ingress controllers.
Nginx Ingress Controller
Container Service for Kubernetes (ACK) provides the NGINX Ingress controller that is optimized based on the open source version. The NGINX Ingress controller provided by ACK is compatible with the open source version and supports all the annotations provided by the open source version. You can install the NGINX Ingress controller when you create an ACK cluster.
How the NGINX Ingress controller works
Ingresses can work as normal only if you deploy an NGINX Ingress controller in the cluster to parse the routing rules of the Ingresses. After the NGINX Ingress controller receives a request that matches a routing rule, the NGINX Ingress controller routes the request to a corresponding backend Service. The backend Service then forwards the request to pods. In a Kubernetes cluster, Services, Ingresses, and the NGINX Ingress controller work in the following process:
A Service is an abstraction of a backend application that runs on a set of replicated pods.
An Ingress contains reverse proxy rules. It controls to which Service pods HTTP or HTTPS requests are routed. For example, requests are routed to different Service pods based on the hosts and URL paths in the requests.
The NGINX Ingress controller is a reverse proxy program that parses Ingress rules. If changes are made to the Ingress rules, the NGINX Ingress controller updates the Ingress rules accordingly. After the NGINX Ingress controller receives a request, it redirects the request to Service pods based on the Ingress rules.
The NGINX Ingress controller acquires Ingress rule changes from the API server and dynamically generates configuration files, such as nginx.conf. These configuration files are required by a load balancer, such as NGINX. Then, the NGINX Ingress controller reloads the load balancer. For example, the NGINX Ingress controller runs the nginx -s load command to reload NGINX and generates new Ingress rules.
The NGINX Ingress controller can create Server Load Balancing (SLB) instances for Services of the LoadBalancer type. The SLB instances are used to expose Services in Kubernetes clusters. Ingress rules are then used to control to which Services requests are routed.
References
ALB Ingress Controller
The Application Load Balancer (ALB) Ingress controller is compatible with the NGINX Ingress controller, and provides improved traffic routing capabilities based on ALB instances. The ALB Ingress controller supports complex routing, automatic certificate discovery, and HTTP, HTTPS, and QUIC protocols. The ALB Ingress controller meets the requirements of cloud-native applications for ultra-high elasticity and balancing of heavy traffic loads at Layer 7.
ALB instances that serve Ingresses are fully managed by the ALB Ingress controller. To avoid service interruptions caused by Ingress errors, we recommend that you do not modify these ALB instances in the ALB console. For more information about the quotas related to ALB, see Limits.
How the ALB Ingress controller works
The ALB Ingress controller retrieves the changes to Ingresses from the API server and dynamically generates AlbConfig objects when Ingresses changes are detected. Then, the ALB Ingress controller performs the following operations in sequence: create ALB instances, configure listeners, create Ingress rules, and configure backend server groups. The Service, Ingress, and AlbConfig objects interact with each other in the following ways:
- A Service is an abstraction of an application that is deployed in a group of replicated pods.
- An Ingress contains reverse proxy rules. It controls to which Services HTTP or HTTPS requests are routed. For example, an Ingress routes requests to different Services based on the hosts and URLs in the requests.
- An AlbConfig object is a CustomResourceDefinition (CRD) object that the ALB Ingress controller uses to configure ALB instances and listeners. An AlbConfig object corresponds to one ALB instance.
References
MSE Ingress Controller
MSE Ingresses are developed based on MSE cloud-native gateways and provide a more powerful method to manage ingress traffic. MSE Ingresses are compatible with NGINX Ingresses and are compatible with more than 50 annotations defined in NGINX Ingresses. MSE Ingresses are suitable for more than 90% of scenarios of NGINX Ingresses. MSE Ingresses support canary releases of multiple service versions at the same time and provides flexible service governance capabilities and comprehensive security protection. MSE Ingresses can meet requirements for traffic governance in scenarios in which a large number of cloud-native distributed applications are used.
Introduction
For more information about the features of MSE Ingresses, see the following topics:
How MSE Ingresses work
Components
MSE Ingress controller
The MSE Ingress controller is not a network data plane, but is a control plane that manages MSE cloud-native gateways and their configurations. The MSE Ingress controller does not process any service requests. The MSE Ingress controller works as a traffic bypass to manage MSE cloud-native gateways that process service traffic.
You must install the MSE Ingress controller component in your ACK or ACK Serverless cluster, use the MseIngressConfig CRDs provided by this component to manage cloud-native gateways based on annotations, and configure Ingress resource monitoring items for the gateways.
For more information about how to install the MSE Ingress controller component, see Manage components.
MSE cloud-native gateways: MSE cloud-native gateways are created based on the MseIngressConfig CRD that you configured. An MSE cloud-native gateway consists of a control plane and a data plane.
Control plane: monitors resources such as Ingresses, Ingress classes, and Services in an associated ACK cluster. After the resources are parsed, the parsed resource configurations are sent to the gateway data plane in real time.
Data plane: implements traffic governance. The data plane processes external requests based on the governance rules that are sent from the control plane, and routes the requests to your destination backend Service.
Implementation
The MSE Ingress controller monitors the resource that is defined by an MseIngressConfig CRD in an ACK cluster and dynamically maintains the lifecycle of the cloud-native gateway that corresponds to the resource and the association between the gateway and ACK cluster in real time.
The control plane of the cloud-native gateway obtains the changes of Ingress resources by using the API server of the associated ACK cluster, and dynamically updates the routing rules of the gateway. After the cloud-native gateway receives a request, the gateway matches the request with an Ingress routing rule and routes the request to the pod that corresponds to the backend Service based on the matched routing rule.
In a Kubernetes cluster, Services, Ingresses, Ingress classes, MseIngressConfigs, and MSE Ingress controller work in the following process:
Service: an abstraction of an application that is deployed in a group of replicated pods.
Ingress: a set of reverse proxy rules. An Ingress specifies the Service to which HTTP or HTTPS requests are routed. For example, an Ingress routes requests to different Services based on the hostnames and URLs in the requests.
Ingress class: a description of the Ingress processor. An Ingress class is used to declare the implementation of an Ingress processor in a Kubernetes cluster. The Ingress resources that are associated with the Ingress class are parsed by the Ingress processor. You must associate an MseIngressConfig CRD with the Parameter field of the Ingress class to implement the traffic management rule that is specified in the parsed Ingress resource description.
MseIngressConfig: a CRD that is provided by the MSE Ingress controller. An MseIngressConfig CRD provides basic information about a cloud-native gateway.
MSE Ingress Controller: a control plane that manages MSE cloud-native gateways and their configurations. The MSE Ingress controller is not a network data plane. The MSE Ingress controller is used to monitor Ingress resources defined by MseIngressConfig CRDs in a cluster and coordinate MSE cloud-native gateways to implement the traffic management rule that is specified in the parsed Ingress resource description.
The following figure shows how the MSE Ingress controller works.
