We have Kong EE running and are running into a little manageability problem.
When deploying Kong Ingress Controller, and pointing it at a Kong EE installation, it will add all Ingress definitions into the default workspace.
We have different tenants, and need to separate them by workspace.
Currently, if you want to push a certain ingress resource to a certain workspace, you have to deploy a separate kong-ingress-controller, override the ingress class with --ingress-class= and then override the workspace name with --kong-workspace=.
Then if you want an ingress to be part of workspace a you have to add an annotation on the Ingress resource for kubernetes.io/ingress.class: XXX
This does not scale when using this for many teams.
We had an idea of possibly using another annotation on the Ingress resource, to specify the workspace it needs to be pushed to such as:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: some-ingress
annotations:
workspace.konghq.com: XXX # Here we can specify the workspace name for where this ingress should be registered in Kong EE
spec: ...
This would remove the need to run multiple ingress controllers for different workspaces.
In normal circumstance without the annotation, push to the default workspace, and with the ingress controller being workspace aware, if it finds the annotation, just push to that workspace.
Have you considered splitting by namespace i.e. map each Kubernetes Namespace to a Workspace in Kong? That has low-overhead and doesn’t require any changes to Ingress resources.
Since you are using Kong Enterprise, please reach out to our Support channel for this at support.konghq.com.
I like replying here to include some community as well
Our use case would actually have multiple namespaces per tenant.
But even if there were only one namespace, how would one map to workspace ? Currently it is only possible with deploying an extra ingress controller, specifying the workspace name to the command.
Our use case would for instance have 2 service running across 2 namespaces, registering to one workspace as two services.
It has not been implemented yet because the ingress-class workaround works for most users. Functionally, the workspace annotation and ingress class annotation are same. Operationally, the ingress-class annotation has a little bit of overhead because you have to deploy another controller (not another DB or proxy node) for it to work.
What you are proposing here is fair and is technically possible.
How many workspaces are you expecting for your use-case?
We are at the moment expecting about 8 workspaces per environment for different teams.
There are a number of environments, which compounds the number of ingress controllers.
For the most part the deployment is automated, so deploying many is not too much of a shlep, but I do think the workspace annotation could be a much better fit for cases where we want to automate the workspaces
I also think a lot of bigger deployments which use EE, would probably have many many workspaces depending on how much granularity they need, and specifying a workspace annotation would be of great benefit over deploying a new ingress controller.
We plan to use an admission controller to control access to these workspace annotations, so only certain teams can apply to certain workspaces, propagating the RBAC control down into the cluster
I totally see where you are coming from and I’ve taken a note of this and I’ll be tracking it internally.
Until this feature comes to reality, you should use a controller per workspace.
Harry
