APIG Ingress is an enterprise-grade product based on the open source gateway Higress. It is compatible with Nginx Ingress and designed for API management and microservice scenarios.
Ingress concepts
In a Kubernetes cluster, an Ingress serves as an access point to expose internal services. It provides Layer 7 load balancing and handles most of the traffic directed to services within the cluster. An Ingress is a Kubernetes resource object that manages how external clients access services inside the cluster. You can configure an Ingress resource with forwarding rules to route requests to the backend pods of different Services based on request content. Standard Ingress resources support only HTTP traffic rules and do not include advanced features such as load balancing algorithms or session affinity. These capabilities require a specific Ingress implementation, such as Nginx Ingress or APIG Ingress.
Features of APIG Ingress
How to use APIG Ingress
APIG Ingress delivers powerful traffic management capabilities built on the cloud-native API gateway. As an upgrade to MSE Cloud Native Gateway, it is compatible with Nginx Ingress and over 50 of its annotations, covering more than 90% of Nginx Ingress use cases. APIG Ingress supports canary releases across multiple service versions, flexible traffic governance, and comprehensive security protection to meet the demands of large-scale, cloud-native distributed applications. In addition to Nginx Ingress compatibility, APIG Ingress introduces additional annotations to enhance traffic governance and security. For more information, see Advanced usage of APIG Ingress.
After you deploy the APIG Controller in a cluster, the component listens for ApigConfig resources. It dynamically manages the lifecycle of cloud-native API gateway instances, global parameter configurations, and listener options for Ingress resources. The cloud-native API gateway listens to and converts Ingress resources from the Kubernetes cluster into the necessary traffic governance configurations to expose internal services. For detailed steps, see Create and use an APIG Ingress to expose services.
APIG Ingress is an upgraded version of MSE Ingress. In regions where both APIG Ingress and MSE Ingress are supported, the ACK console displays only APIG Ingress options. This change does not affect existing MSE Ingress users, who can continue to create and manage their MSE Ingresses. To use MSE Ingress, submit a ticket to contact the APIG team.
How APIG Ingress works
Components
APIG Controller:
The APIG Controller is a control plane, not a network data plane. It manages cloud-native API gateway instances and their configurations. The APIG Controller does not process any service traffic. It operates in bypass mode and manages the cloud-native API gateway instances that handle the actual service traffic.
In the cluster, install the APIG Controller component. Use the ApigConfig Custom Resource Definition (CRD) provided by the component to declaratively manage cloud-native API gateway instances and set the listener options of the gateway for Ingress resources.
Cloud-native API gateway:
The APIG Controller creates the cloud-native API gateway based on the configured ApigConfig resource. The gateway consists of a control plane and a data plane.
Control plane: The control plane listens for resources such as Ingress, IngressClass, and Service in the associated container service cluster. It parses these resources and sends the resulting configurations to the data plane in real time.
Data plane: The data plane implements the traffic governance configurations. It processes external requests based on the rules from the control plane and forwards the requests to the backend target services.
How it works
The APIG Controller listens for ApigConfig resources created in the cluster. It dynamically maintains the lifecycle of the corresponding cloud-native API gateway instance and the association between the gateway and the container service cluster in real time.
The control plane of the cloud-native API gateway retrieves Ingress resource changes from the API server of the associated container service cluster. It then dynamically updates the routing rules for the gateway. When the cloud-native API gateway receives a request, it matches the request with the Ingress forwarding rules and forwards it to the pods of the corresponding backend Service.
In Kubernetes, the relationship between Service, Ingress, IngressClass, ApigConfig, and the APIG Controller is as follows:
Service: An abstraction of a real backend service. A Service can represent multiple identical backend services.
Ingress: A set of reverse proxy rules that specify which Service an HTTP or HTTPS request should be forwarded to. For example, requests can be forwarded to different services based on the host and URL path in the request.
IngressClass: Describes an Ingress processor implementation in a Kubernetes cluster. Ingress resources associated with this IngressClass are parsed by that processor. You must also use the Parameter field of the IngressClass to associate an ApigConfig (a cloud-native API gateway). This gateway then implements the traffic management rules described in the parsed Ingress resource.
ApigConfig: A CRD provided by the APIG Controller. It describes the basic information of a cloud-native API gateway instance.
APIG Controller: Not a network data plane, but a control plane that manages cloud-native API gateway instances and configurations. The APIG Controller listens for ApigConfig resources in the cluster and coordinates the cloud-native API gateway instance to implement the traffic management rules described in the Ingress resources.
The following figure shows how the APIG Controller works.
References
To learn how to install the APIG Controller, see Manage the APIG Controller component.
For information about APIG Ingress versions, see APIG Ingress version guide.
For the regions where APIG Ingress is available, see Supported regions.