Noisy and nosy 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. 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.

1. Preventing Noisy
and Nosy Neighbors
in Multi-tenant Environments with EKS,AKS,or GKE
Noisy and nosy neighbors aren’t exclusive to just your physical living
space. In an enterprise environment, a lack of centralized governance
and federated management of EKS, AKS, or GKE clusters can limit
application scalability and performance. Learn about these multi-
tenancy issues and how to effectively solve them.
Enterprise
A single company that has many
tenants using AKS, EKS, or GKE
and would like to share cluster and
administrative resources.
Tenant
A single application/service team
developing a single workload in a
shared AKS, EKS, or GKE cluster.
Platform Team
Manages AKS, EKS, or GKE clusters
and defines the amount of resources
each tenant team can use.
Who’s Who
in an Enterprise Multi-Tenant Environment
The Impact of Noisy and
Noisy Neighbors
Noisy Neighbor Sharing a cloud cluster
with multiple tenants
Nosy Neighbor Lack of centralized
governance
unable to identify tenants,
configure access to resources,
perform compliance checks.
negatively impacts the
bandwidth and performance
of workloads.
As an enterprise adopts new cloud clusters,it can
introduce all kinds of complexities around visibility,
management,and security.
Reducing the Risk Noisy and Noisy Neighbors
Below are some best practices for platform teams to safely and efficiently
set up multiple multi-tenant clusters in the public cloud.
STEP 1
Categorize Namespaces
STEP 3
Enable RBAC
STEP 2
Determine Cluster Personas
STEP 4
Isolate Namespaces using Network
Categorize namespaces to separate workloads,
tenants, and applications so that updates
and changes are contained within a specific
namespace and doesn’t impact bandwidth or
performance.
Create cluster personas using Roles and
RoleBindings in RBAC to lock out nosy neighbors
and restrict unnecessary network access.
Create a hierarchy of cluster personas that
specifies their responsibilities and account
privileges. This is the first step to enabling Role-
Based Access Control (RBAC) in Kubernetes.
Apply a default network policy to all tenant
namespaces, which blocks access from
unwanted neighbors.
STEP 5
Improve Resource Utilization with
Resource Quotas
Apply resource quotas to each namespace to
control and limit computing resources, such as
CPU and memory, so that neighbors have access
to the shared resources they agreed upon.
DKP with AKS,EKS,
or GKE Clusters
A Winning Combination for Effective Multi-
Cluster and Multi-Tenant Management
For enterprises, using D2iQ Kubernetes Platform (DKP)
with EKS, AKS, or GKE together can simplify Kubernetes
multi-tenancy and reduce the risk of noisy and nosy
neighbors. When combined, they provide centralized
governance and user access controls to enable consistent
multi-cluster, multi-cloud and multi-tenant management.
To learn more about Kubernetes multi-tenancy, download
the ebook,“The Art of Winning: Leveraging Kubernetes in
the Public Cloud to Deliver a Unified DevOps Experience.”
© 2021 D2iQ, Inc. All Rights Reserved.
Download Ebook