Multiple kong instances installation with only one postgres database

#1

Are you tried to have multiple instances of kong installed but all of them pointing to the same Postgres database?

I want to set up in one kubernetes cluster, multiples environments of some web application of this way:

  • dev.mydomain.org to development environment
  • sandbox.mydomain.org to the sandbox environment
  • production.mydomain.org to the production environment

Currently, I have the dev.mydomain.org with the following resources

  • a kong installation (include kong-ingress-controller)
    • Kong Postgres database
  • My application service installed via helm chart pulled from Azure Container Registry.

If I would have the sandbox.mydomain.org and production.mydomain.org environments, inside the same cluster, what is the best approach to deploying them?

Do I need to deploy another set of resources similar to my dev.mydomain.org environment, this means the sandbox and productions environments each one with their own kong database?

I suppose that we could to use a kong-ingress-controller to manage multiple domains like my sandbox, development, and production instances.

Currently, my my-ingress-application resource is pointing to my kong-ingress-controller, via kong-proxy public IP address:

⟩ kubectl get ingress my-ingress-application
NAME                           HOSTS                                ADDRESS          PORTS     AGE
my-ingress-application   dev.mydomain.org   51.144.180.168   80, 443   103m
[I] 


⟩ kubectl get svc/kong-proxy -n kong
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
kong-proxy   LoadBalancer   10.0.174.245   51.144.180.168   80:31166/TCP,443:31525/TCP   3h42m
[I] 
⟩ 

I have one doubt in order to have only one database to all these environments.
Should each of them to be configured in only one ingress resource?
This means of this way:

apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
   name: kong-ingress-config
   namespace: default
proxy:
   protocols:
      - http
      - https
   path: /
route:
   methods:
      - POST
      - GET
   strip_path: false
   preserve_host: true
 ---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress-application
  #namespace: default
  annotations:
    kubernetes.io/ingress.class: "kong"
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod # letsencrypt-staging

    # We are indicating the KongIngress resource
    configuration.konghq.com: kong-ingress-config

    certmanager.k8s.io/acme-challenge-type: http01
    kubernetes.io/tls-acme: "true"
    certmanager.k8s.io/acme-http01-edit-in-place: "true"
spec:
  rules:
 # DEV ENVIRONMENT
  - host: dev.mydomain.org
    http:
      paths:
        - path: "/"
          backend:
            serviceName: myapp
            servicePort: 80
  # SANDBOX ENVIRONMENT
  - host: sandbox.mydomain.org
    http:
      paths:
        - path: "/"
          backend:
            serviceName: myapp
            servicePort: 80  
  tls:
  - hosts:
    - dev.mydomain.org
    - sandbox.mydomain.org
    - production.mydomain.org 
    secretName: letsencrypt-prod #letsencrypt-staging

So, is possible that my my-ingress-application resource could to have multiple hosts pointing the same kong-ingress-controller (kong-proxy) and using the same secretName ?
Maybe something like this: ?

⟩ kubectl get ingress my-ingress-application
    NAME                           HOSTS              ADDRESS             PORTS    AGE
    my-ingress-application   dev.mydomain.org         51.144.180.168   80, 443    103m
                             sandbox.mydomain.org     51.144.180.168   80, 443    103m
                             production.mydomain.org  51.144.180.168   80, 443    103m
[I] 

Could to be this a correct approach?

0 Likes

#2

I’d advise to not mix up production and dev ingress controllers.
Please consider using multiple Ingress controllers in your cluster and use the ingress.class annotation.

1 Like

#3

Yes, I think that indirectly I’ve replicated the purpose of this question in this one Multiple kong-ingress-controller compete to taking over of the ingress process and communication with cert-manager
If you want we can close this question.

0 Likes