The multi-tenant / single-tenant requirement in every project, involving AKS or not comes more often.

What’s The Buzz

The requirement you get based on tenancies will be like – you have developed a web application which can be catered for multiple clients. You have infrastructure to support the load or requests, however few of the clients will get security concerns over sharing the infrastructure. The infrastructure will be –

• Computation components like Kubernetes, Computers/VMs/EC2 etc.,
• Database – will have data for all the clients combined, distinguished by client based attribute.
• Single tenant – where each entity (based on how client decides) will have separate and it’s own infrastructure components.
• Multi tenant – where every clients/entities will be in same infrastructure.

The requirements from some clients will be to avoid the security concerns, and also the noisy architecture. So the options laid out in this blog, should be helpful for you to choosing the appropriate option.

AKS (Azure Kubernetes Service) Options

In this blog, we are going to discuss on multi-tenancy options in AKS.

The upstream components (like application g/w, APIM etc.,) and downstream components (like database) of AKS are not part of this blog’s scope.

With respect to multi-tenancy in AKS, we have few options

Option A (Single AKS)

Applications will be deployed in namespaces, created based on each environment. Here the infrastructure is shared.

Option B (Hybrid)

We can have one AKS for each environment. In this, a separate name-space will be created for the clients who needs single-tenancy, and rest of the clients will be in a one common namespace. This will be repeated for all the AKS, corresponds to each environments. The network policies will help in getting the demarcations clearly.

Option C (Dedicated)

The third option is the most secured option, but however the most costliest option. Yes – we can have one single AKS for each client. In this case we can have all the environments for that client deployed in the same AKS, where as each environment is differentiated by the namespace. However this still be a costliest option, as we are not sure how many AKS we will be creating.

Comparisons

Attributes	Option A – Single AKS	Option B – Hybrid	Options – Dedicated
Sharing	Infra shared along with Kubernetes components as well	Infra shared but namespace based demarcation. Who ever is ok with sharing, will be place in a common namespace.	No sharing, so more secured than all the other options.
Security	Since infra + Kubernetes components shared, less secured than other two.	The namespace based security policies will be useful and enforce security. However infra being shared.	This is more secured option that any other options. This will be worthful, only if the data also being maintained separately.
Cost	Most cost effective option, if the clients are ok.	The best possible amicable solution for both single-tenant requiring client and for those clients ok with sharing.	Costliest option as we have to dedicate separate AKS. For better working, needs to have dedicated upstream and downstream resources – so this adds extra cost.
Effort	The effort will be simpler and we can get the product to market sooner	Little tough in the first setup (first environment), but after that it will be a repeating tasks for other environments.	Effort will be simple as it’s going to be repeat of set one client, but sometimes based on client demand the effort will be high.
Billing the infraThese are purely suggestions. You can decide, how to bill based on your requirement.	Billing the client for the infra will be little tricky, as infra being shared across the clients. It’s always comes down as equal share of billing, when analyze.	Here also billing will be tricky as we are sharing the infra, but we can divide the billing by namespace.	The billing will be straight forward as we get extract based on each resource, which is AKS in this case.