Solving Key Multi-tenancy Challenges in the Public Cloud | D2iQ

Nobody wants to deal with annoying neighbors. Whether it’s the neighbor who always knows everyone’s business or the one who turns up their music late at night, both types of neighbors can have a negative impact on your living environment and daily life. Obnoxious neighbors aren't exclusive to just your physical living space, but in the public cloud where there are multiple Kubernetes clusters (EKS, AKS, or GKE) and multiple users (or tenants) with the need for cluster access. 

Typically an enterprise environment will have two or more application or service teams that are developing a single workload in a shared AKS, EKS, or GKE cluster and a platform team who manages these clusters and defines the amount of resources each tenant team can use. As the number of clusters grow, it can be difficult to know where clusters exist and how they are performing. Even on a single public cloud, clusters may exist in different environments, and the platform team isn’t even aware of these things. 

Noisy and nosy neighbors occur when there is a lack of centralized governance and federated management of AKS, EKS, or GKE clusters. Noisy neighbors are created when tenants unintentionally or intentionally monopolize the bandwidth or performance of other tenant’s workloads in a shared cluster. On the other hand, nosy neighbors are created when platform teams are unable to identify tenants, configure their access to resources, and perform compliance checks, which introduces security risks. Both types of neighbors impose several multi-tenancy challenges that, if not handled correctly, can lead to an increase in operational overhead, management complexity, and additional costs.

Here are four capabilities in Kubernetes that can help address these multi-tenancy challenges:
 

1. Namespaces 

The central element of isolation in Kubernetes is a Namespace and can solve for noisy and nosy neighbor issues. Typically, every tenant, workload, and application on your cloud Kubernetes platform needs a single, dedicated namespace. By creating isolation, updates and changes are contained within a specific namespace and won’t impact cluster bandwidth and performance. 

2. Roles and RoleBindings
Within a namespace, correct configuration of Role-Based Access Control (RBAC) is critical for security isolation and explicit-approval authorization. Operational access to each namespace is managed through Roles and RoleBindings. Roles align with operational responsibilities, which determine which actions (called verbs in Kubernetes) can be taken on various resources by their type. RoleBindings associates tenants to each Role. By using Roles and RoleBindings in RBAC, your platform team can restrict unnecessary network access to nosy neighbors. 

3. NetworkPolicy
A best practice to isolate each tenant and address the nosy neighbor issue is to apply a default Network Policy to all tenant namespaces, which blocks access from other namespaces. When needed, the policy can be revised to open specific application ports within the cluster to other pods in other namespaces.

4. ResourceQuota
The noisy neighbor problem can also be mitigated by leveraging a ResourceQuota that can be defined on each namespace, with fixed CPU and Memory allocation. When needed, this quota can be revised to expand or reduce the resources available to each application, thus ensuring that one application cannot consume so much of a cluster’s compute or storage capacity that it affects its neighbor applications. 

Managing multiple AKS, EKS, or GKE clusters in multi-tenant environments in the public cloud can be a daunting task, but it doesn’t have to be so hard. Check out our latest infographic to learn more about noisy and nosy neighbors and the best practices to solve for these multi-tenancy challenges and other issues.