Kong is different from Nginx ingress controller. Without a controller, you have to manually register the endpoint/service. You would want to by pass k8s service

Kong is different from Nginx ingress controller. Without a controller, you have to manually register the endpoint/service. You would want to by pass k8s service and use pod ip directly. That's why they do the kong ingress controller. The main difference is in plugin API. It's very easy to write plugin for Kong. The second is where data is persisted. Kong stores data in db. Therefore they can do something with it. Ingress controller in 0.21 has dynamic backend, they basically hold an in memory objects for api routing rule. Kong shines when you have complex logic routing, want to leverage their API keys authentication. Such as you can easily expose a service, with API key store in db. Where as you have to write a logs of `auth access` rule and store key in configmap/env in Nginx ingress. Nginx ingress config is all about watching configmap/annotations and re-generate config. Such as when new service are added, the config is generated(When new pods are added/remove they use Lua to routing so no more reload in there). In Kong, these are seamless, no reload. All data are stored in either Postgres/Cassandra. That's said, Kong is very nice but it adds more overhead than a simple Nginx ingress.