Using Kubernetes namespace to isolate users. Is this architecture adapted?
I want to analyse a solution to isolate environment dedicated to each user (or client in my case).
Each client has a private environment:
- webui
- mongodb database
- 3 microservice for the application dedicated for the API
All the clients will be running the same application on the same version.
Why I think this is a good solution?
- Facilate to restrict quota by namespace
- Isolate strictly by user, for security, etc..
- Easy to scale
- ...
I don't know if this architecture is adapted, i can have 1000 user in same cluster so 1000 namespaces.
I don't know if this is the right way to think. It would be great to have any feedback or any person can help complete this approach?
Similar Questions
1 Answer
You can definitely do this. Although, Kubernetes does not provide any mechanism to isolate running pods across namespaces. A pod in one namespace can contact another pod. To achieve network-level isolation amongst namespaces, you would need to use something like Calico.
Calico and Kubernetes has been used by many private parties to support multi-tenant architectures (basically the scenario you describe). I have personally used it to scale to 100+ clients (each running 1 database + redis and 10+ services).
Kubernetes has a 1000 pods per node restriction. So for your 1000 clients (assuming each running 3 services + 1 DB) you would need atleast 4 nodes to support this architecture.
I'm not an expert on these technologies. But all of this technology is quite new and rapidly changing, so this comes with its own share of advantages and disadvantages. So I cannot say that this will work or not work. This field is so involved and complicated, I guess, you have to dirty your knees to find out.
For us we have not yet hit a roadblock. But we are moving away from this architecture and hosting the cluster on the client's infrastructure. This has made our architecture much simpler and easier to maintain and reason about.