Installing kong on k8s with DB

Installation/Setup
1

The installation guide here : https://docs.konghq.com/1.4.x/kong-for-kubernetes/install/ says :

We do not recommend using Kong with Cassandra on Kubernetes deployments, as the features covered by Kong’s use of Cassandra are handled by other means in Kubernetes.

This does not talk about any issues. Are there any if kong is still installed on k8s backed by Cassandra?

2

The Ingress Controller performs a lot of reads on the database and a burst of writes when things change. If you can guarantee a stable Cassandra cluster to back Kong, then there should be no problem.

Out of curiosity, could you elaborate on the reason of using Cassandra for Ingress Controller use-case?

3

@hbagdi wouldn’t you need a DB in order to leverage plugins like OAuth 2.0? The use-case I’m thinking of is you want the declarative syntax of Kong Ingress for managing routes/plugins/etc. but want the scalability of Cassandra for storing/refreshing tokens.

Is it possible for Kong to be configured using Kong Ingress to store configurations in the k8s control plane but still have plugins like OAuth 2.0 backed by a DB (Postgres or Cassandra)?

4

@hbagdi Not looking to use kong as ingress controller to k8s yet! Before we actually use kong as an ingress controller to k8s, we would want to deploy it as a service on k8s leveraging the authentication plugin and have phase-wise migrations of services to kong.

  1. Are there any issues you see with approach?
  2. Kong would be k8s service in this case with moderate to high load on auth plugin. AFAIK, the basic auth plugin caches basic auth credentials on kong nodes, so load on DB shouldn’t be high. Please correct me if wrong.

@mike.roth +1. I had the same question that I asked a few months back, but couldn’t follow up on the same. Kong ingress controller and custom CRDs

5

Yes. That is supported. And exactly for those reasons.

I’d recommend using Cassandra only if there is a real use case. If you have less a, let’s say arbitrarily, a billion tokens, you can still use Postgres even for a very highly concurrent traffic pattern.

No. This is a widely used pattern.

That’s correct.

6

The choice of cassandra in our case is primarily for fault tolerance and HA. I understand that load can very well be handled by postgres itself, but an API gateway needs HA. What would be the reasons for preferring postgres over cassandra?

7

Operational simplicity. Use boring technology as much as possible.

If fault tolerance and HA are the only reasons, you should consider a master slave design for Postgres.