What's the official attitude to Kong admin API in kubernetes

Hi, I’m a new Kong user, and this is a question that really puzzles me.

When I’m reading Kong docs from official website, all docs/guides are talking about Admin API to configure Kong. I took some time to learn it and thought I’ll be ready to really use it.

Then when I was trying to deploy Kong to Kubernetes, all info goes to a Github project. The configuration talks about CRD all of a sudden. But what’s relationship with admin api? I don’t see any doc talking about what’s going on with admin api. Is it still supported? Are we encouraged to use CRD instead? Has CRD been mature enough to cover what all admin api does?

Searched the forum/issues and saw there are really many users like me looking for the missing admin api. Finally saw a comment saying that admin api should not be used in kubernetes case as it will be overwritten by ingress-controller. I thought I got the conclusion. But later, saw a newer comment saying it won’t be overwritten since 0.5 and again there’s no any doc saying anything about exposing the admin api.

So really want to know the official attitude about the admin api in Kubernetes.

Are we encouraged to use CRD? Has CRD been mature enough to cover what all admin api does?
Will there be any use/functional difference/missing features for admin api from what’s described in official website doc? Could we provide doc to expose admin api for both http and https?

Thanks a lot!

Thank you for the detailed post.

I totally understand your frustration and every point that you make above is accurate and perfectly reasonable.

I’ll try to explain the reason for the way it exists today:

Kong is a highly configurable piece of software that is deployed in a wide variety of installations and architectures.
Before Kubernetes became mainstream, Kong was completely configured using Admin API. Over the last couple of years, 2019 specifically, Kubernetes has taken over and we have seen high-adoption of our CRD based approach, aka Kong’s Ingress Controller. Even though the adoption of Kubernetes and our CRDs is growing very rapidly, it is still far from the traditional way to use Kong, via the Admin API.

And then there is the platform agnosticism side of Kong. Kong is designed to run on any platform of your choice. We treat Kubernetes specially because there is a very high demand and Kong adds a lot of value to the Kubernetes ecosystem by providing native-integrations with it. Every feature of Kong, works the same way, be it Kong running outside or inside Kubernetes.

The official recommendation is to use CRDs and Ingress Controller to configure Kong when running on Kubernetes, to leverage Kubernetes functionalities and increase automation in your infrastructure.

Kong’s CRDs provide full-coverage of the Admin API, meaning, you can use all the features of Kong, that you can use with Admin API.

Here a couple of documents that provide some relation between CRDs and Admin API:


It is possible to use Kong on Kubernetes with the Admin API (without CRDs) if that makes sense in your use-case.

While documentation exists, I admit that the way we present it is not ideal and needs work.
Hope this helps and let me know if you have any more questions.

Thank you very much for the answer. It’s much clearer to me now.
BTW. the docs don’t mention Admin API. It might help people to add something.

I would rather put it a bit differently.

  1. Use Ingress Controller + Kong on K8s + CRDs when you have to configure kong for a lot of plugins, ingresses/services, routes, consumers, etc. for about 5k resources, where 1 resource equals 1 CRD. Beyond this scale, you will probably stress the ingress-controller + Kong in keeping track of all the configs and ensuring efficient sync.

  2. Use Kong backed with a DB if you are anywhere beyond that irrespective of whether you are on K8s or not.

I hope my understanding is right, although I might be a bit wrong on the numbers above wrt 5k.
Hopefully, this helps you design your platform better. I am in 1 right now, but might have to move to 2 down the line.

1 Like

@hbagdi In my case, consumers need to added/removed dynamically by an k8s app in Go. Which is the recommended way?

  1. KongConsumer CRD via kubernetes “client-go”, or
  2. Restfully via Admin API

Restfully via Admin API will be simpler if you have a lot of consumers (more than a few thousands).


© 2019 Kong Inc.    Terms  •  Privacy  •  FAQ