Kong Ingress Controller vs Kong deployment

Kubernetes
1

Hi Kong Nation,

We are deciding on some kong deployment decisions, and wondering how the community prefers.

Currently, we have a kong ingress controller and a legacy kong as a simple k8s deployment. The requests kind of hop from kong ingress controller to legacy kong to internal services.

We can either merge these two kong (i.e. move all the plugins and consumers into the kong ingress controller), or we keep what we have now.

Is it recommended to setup many plugins within the ingress controller? Lots of the consumers and custom plugins may be coupled with the application’s model. On one hand, I like how simple we can add annotations to the ingress/services and codify the routes; on the other hand, I also like to have a very thin kong ingress controller (just like nginx ingress controller) and decouple consumer-based plugins to a dedicated kong deployment.

What do you think?

Thanks,
Zhuojie

2

Thank you for the great question!
This is not the first time someone is asking this and this remains a case-by-case decision.

Can you quantify?

The answer depends on the following things:

  • How is your ops pipeline setup? Do you use k8s for other products you use and like using kubectl way of doing things or do you use a separate configuration management for each product?
  • How often do your consumers and their associated plugins change? How many consumers do you have? This is to prevent overloading k8s itself.

I think the setup you’ve is a very good balance. I’d make sure that all consumer specific plugins live in the legacy Kong and everything else is configured via CRDs and annotation.