Preventing Noisy and Nosy Neighbors Infographic
0 likes91 views
The document discusses the challenges of noisy and nosy neighbors in multi-tenant environments using EKS, AKS, or GKE, highlighting the importance of centralized governance for application scalability and performance. It outlines best practices for platform teams, including categorizing namespaces, enabling RBAC, and applying resource quotas to ensure effective multi-tenancy management. The combination of D2iQ Kubernetes platform with these cloud services can help mitigate visibility, management, and security complexities.
Preventing Noisy and Nosy Neighbors Infographic
- 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