Is nested setup of Kong for Kubernetes a bad practice?

Questions
1

In our scenario, we need

  • a Kong with DB for basic auth management. This is because we have an increasing number of customers, thus we don’t want to maintain them in a declarative yaml.
  • a Kong in DB-less mode. This is for the routing part where declarative yaml is better than DB.

Question is - Is it a bad practice to have a nested Kong setup? If so, what’s the recommendation to our scenario.

Thanks,

T

2

You can chose to run a single DB where you are configuring everything except consumers and their credentials in a declarative fashion. And then use the Admin API to configure consumers and their credentials dynamically.

3

So is that a yes that even I setup Kong for Kubernetes with a DB, I can still use declarative configuration, correct?

4

Yes. You can configure everything except Consumers and credentials using CRDs and configure consumers using the admin API.

5

I’ve successfully created k4k with Cassandra (we already have a Cassandra running, so just making use of it) using helm and following values.yaml:

image:
  repository: kong
  tag: 2.2
env:
    database: cassandra
    cassandra_contact_points: cassandra.infrastructure
    cassandra_username: cassandra
    cassandra_password: temppassword123!
admin:
    enabled: true
    http:
        enabled: true
        servicePort: 8001
        containerPort: 8001
ingressController:
    installCRDs: false

And then I applied this ingress.yaml

apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: demo
      namespace: vi
      annotations:
        kubernetes.io/ingress.class: kong
    spec:
      rules:
      - http:
          paths:
          - path: /search
            backend:
              serviceName: demo
              servicePort: 80

However when I curl $PROXY_IP/search, I get

{"message":"no Route matched with those values"}

How do I know if it’s really using declarative config or still trying to look for that path in the DB?

Thanks!

6

Nevermind. I found the issue.

I re-installed Kong for Kubernetes, without realizing that the DB does not get removed along with it. After re-install, any new configure cannot be written to the database due to following error in ingress-controller

"failed to update kong configuration: inserting target into state: entity already exists"

I removed the database from Cassandra before re-install, and it worked fine.

Guess this is a bug that has to be fixed.