Introduction to Cloud Native API Gateway Ingress Controller
Cloud Native API Gateway generally manages resources, including services, routes, plugins, and consumers through the admin API. After resource rules are defined, Cloud Native API Gateway distributes routes and controls requests to upstream services based on the rules.
In a Kubernetes cluster environment, the Admin API approach is not well-suited to the declarative management style of Kubernetes. Therefore, Kong introduced Kong Ingress Controller for Kubernetes cluster environments, which covers all aspects of the original Admin API. Consequently, Kong Ingress Controller not only proxies traffic entering the Kubernetes cluster but also implements all features provided by Kong, such as plugin configuration, load balancing, and health checks.
The following figure shows how it works.
After Kong Ingress Controller is installed, it monitors Kubernetes cluster changes and updates Cloud Native API Gateway to respond to these changes, thereby proxying all traffic correctly. In addition, Cloud Native API Gateway is updated dynamically based on information synchronized from Kong Ingress Controller to respond to changes, such as scaling, configuration adjustment, and faults in the Kubernetes cluster.
Correspondence Between Kubernetes Resources and Cloud Native API Gateway Resources
Kong Ingress Controller synchronizes resources configured in the Kubernetes cluster to Cloud Native API Gateway and generates Cloud Native API Gateway resources so that the existing mechanism of Cloud Native API Gateway can be used for gateway operations. The resource mapping is as follows:
Kubernetes service: corresponds to services and upstream services of Cloud Native API Gateway.
Kubernetes Pod: corresponds to the targets of Cloud Native API Gateway.
Kubernetes Ingress: corresponds to routes of Cloud Native API Gateway.
The following table describes the mapping relationship between Kubernetes versions and Kong Ingress Controller versions
