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 method does not adapt to Kubernetes declarative management. Therefore, Cloud Native API Gateway launched Kong Ingress Controller in a Kubernetes cluster environment, which covers all aspects of the original admin API. Kong Ingress Controller not only proxies traffic to the Kubernetes clusters but also implements all features provided by Cloud Native API Gateway, such as plugin configuration, load balancing, and health check.
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.
