Skip to main content

The Promise and Challenges of Kubernetes Multi-Tenant

· 5 min read

In today's business landscape, managing cloud and server resources is becoming increasingly unwieldy as companies diversify and scale. While powerful, Kubernetes lacks native support for multi-tenancy - the ability to securely isolate multiple tenant workloads. This gap creates deployment friction for teams and missed efficiency opportunities for enterprises.

This article explores the value proposition of multi-tenant Kubernetes, implementation hurdles, and potential solutions to unlock its benefits.

The Potential of Multi-Tenant Kubernetes

Multi-tenancy refers to an architecture allowing multiple users or "tenants" to share resources from the same system while keeping data isolated and secure. For Kubernetes, this means running workloads from different teams on a shared cluster without risk of resource conflicts, data leaks, or security issues.

Diagram of single vs multi-tenant Kubernetes

Pain Points of Single-Tenant Setups

Consider an enterprise Kubernetes cluster used by 20 internal departments. Without multi-tenancy, several pain points emerge:

  1. Inefficiency - Deployments get bottlenecked through cluster administrators, hampering velocity.
  2. Underutilization - Workloads cannot mix, leading to resource stranding.
  3. Sprawl - Lacking isolation allows cluster entanglement over time.
  4. Limitations - Fixed single-tenant structure strains under changing demands.

Comparison table of single vs multi-tenant Kubernetes

The Multi-Tenant Advantage

Conversely, effective multi-tenancy unlocks greater cloud agility:

  1. Organization - Teams self-manage resources without wasteful allocation conflicts.
  2. Velocity - Services rapidly provision without administrative bottlenecks.
  3. Efficiency - Cluster administrators focus holistically rather than application-by-application.
  4. Resilience - Workload isolation enhances stability despite diverse deployments.

In the Kubernetes (K8s) landscape, establishing a multi-tenant architecture is a complex endeavor, transcending the mere application of namespaces and involving an array of technical intricacies.

Challenge 1: Curbing Over-Privilege Risks

Central to a multi-tenant K8s framework is the strict regulation of user permissions. In scenarios where a cluster is shared among several users, overly privileged individuals can pose a serious threat. Prohibitions against accessing server nodes or executing node-level commands, such as kubectl get node, are essential. Further, it's crucial to curtail other high-risk activities, including the activation of container privileged modes, and sharing of host filesystems, ports, and networks.

Sealos addresses these concerns through a multi-faceted isolation approach. It employs OpenEBS for block-level storage isolation, Firecracker and Cloud Hypervisor for computational isolation, and Cilium for network isolation, ensuring that the activities of one tenant do not adversely affect others.

Challenge 2: User Identity, Authorization, and Namespace Ties

Inherent to K8s is the absence of a native user management framework. This necessitates the creation of a user identity system, integration with external user management platforms, and issuance of unique kubeconfig files or tokens. Moreover, it's imperative to forge a multifaceted linkage between users and namespaces, coupled with the distribution of tailored permissions.

Image Depicting User-Namespace Association

Sealos's framework enables administrators to effectively slot users into designated namespaces and regulate their roles, thereby achieving a granular control over permissions. This guarantees that users access only the resources they are legitimately permitted to use.

Image Illustrating User Permissions Management

Image Showcasing User Role Control

Challenge 3: Metering and Managing Quotas

A critical aspect of multi-tenancy in K8s is the equitable distribution and meticulous tracking of resource usage, including CPU, memory, disk, and network utilization. Managing excess usage and differentiating between internal and external network traffic are particularly challenging, as is accurately attributing traffic to specific containers and tenants.

Utilizing eBPF technology, Sealos adeptly monitors network traffic, correlating it with tenant information and storing it in a database for precise billing and resource management. For compute and storage resources, Sealos relies on controllers to gather and administer relevant data, ensuring efficient resource oversight.

Extreme Multi-Tenancy - The Sealos Challenge

In the realm of multi-tenancy, Sealos embarks on an ambitious journey, operating within the unpredictable confines of a public network. This scenario invites any developer to join and partake in a communal Kubernetes cluster, which inherently raises substantial security and stability risks.

The method adopted by Sealos brings forth distinct benefits: cost-effectiveness, as it negates the need for users to independently build and manage their clusters, leading to significant cost reductions in cloud services. It also enhances resource utilization, allowing container operations on a smaller scale, thereby leveraging the platform’s flexibility and resources. Crucially, establishing strong isolation in such a public network setting can bolster security and stability.

Nevertheless, Sealos is confronted with a series of formidable challenges:

Challenge 1: Overcoming Gateway Limitations The substantial user base of Sealos generates immense traffic, pushing the boundaries of many mainstream open-source gateways. A single user update can potentially impact the entire user base, as systems like Nginx require configuration reloads. Moreover, specific well-known gateways, which remain unnamed, struggle with issues like CPU overload and delays in configuration effectiveness. Sealos has proactively engaged with upstream communities for potential improvements.

Challenge 2: Addressing Runtime Isolation Strong isolation is critical for ensuring security in Sealos's multi-tenant environment, but current mainstream runtime environments fall short of meeting these requirements. For example, Firecracker's inadequate GPU support presents a significant limitation for high-performance computing applications.

Challenge 3: Ensuring Storage Isolation A paramount concern for Sealos is the isolation of tenant data to prevent unauthorized access or data breaches. The goal is to implement block-level storage isolation, a challenging but necessary endeavor.

Challenge 4: Network Metering and Contention Management Managing and accurately metering network resources is essential in a multi-tenant infrastructure. Sealos is committed to distributing these resources fairly, particularly in situations where resource contention occurs, to ensure that all users have fair and efficient access to network resources.


Only with the advancement and maturity of multi-tenancy can the true essence of a cloud be actualized, harnessing over ninety percent of its inherent capabilities. Facing the complexities and unpredictabilities of the public internet, Sealos excels by providing secure and isolated multi-tenant environments. It achieves this while ensuring efficiency and reducing operational costs. The underlying technology Sealos uses is elegantly designed, catering perfectly to businesses where a single cloud platform is shared among all developers.