When to use kong ingress?

Kubernetes
#1

Hey,

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!

#2

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.

#3

Thanks!

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

#4

Hi,

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

#5

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.

#6

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:

#7

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.

#8

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

#9

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

1 Like