When to use kong ingress?


We want to deploy kong as an API gateway (we will need to create consumers dynamically).
Is kong ingress is a valid use case for that? or it’s more solution for service mesh?
I don’t know wheater to deploy kong as a pod or as ingress.

Thanks for the help!

That depends on how you would like to configure Kong – using Ingress API of k8s or via REST calls to Kong’s Admin API.

In either cases, creating consumers dynamically is supported.


So the main difference between the two is the the configuration part?


Is it possible to deploy it as ingress and still use REST calls to create consumers dynamically?

Yes, if you use Kong Ingress Controller0.5.0 and Kong 1.1+

From the 0.5.0 changelog:

Tagging support : All entities managed by Kong Ingress Controller in Kong’s database are now tagged and the controller manages only a subset of Kong’s configuration. Any entity created via Kong’s Admin API will not be automatically deleted by the Ingress Controller.

Hope that helps.

Correct, Kong Ingress Controller is simply a different way of configuring Kong.

Can I say if my microservices are deployed in same name space I should use K8s Ingress.
And if I want to use third party API hosted publicly, I should not go for KongIngress?

Please correct me :slight_smile:

That’s not entirely correct. If you need fine-grained control over the proxy behavior, more than what the Ingress API offers, you will need to use KongIngress resource.

So if I start using KongIngress - it can access my cluster local namespaced services + external services?

KongIngress has nothing to do with it.
With the regular Ingress, you can use local + external service.

1 Like