> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/kubernetes/composable-clusters-for-multi-tenancy-in-kubernetes.md).

# Composable clusters for multi-tenancy in Kubernetes

Explore WEKA’s multi-tenancy with composable clusters, ensuring full resource isolation and optimal performance through Kubernetes-driven deployment.

## Overview

{% hint style="info" %}
**Two different multi-tenancy models exist. This page describes composable clusters.**

* **Composable clusters**, described here, give each tenant its **own cluster** on shared hardware, with dedicated hosts, drives, cores, and memory. Isolation is physical resource partitioning.
* **Native multi-tenancy** gives each tenant a logically isolated environment **inside a single cluster**, sharing CPU, memory, and drives, with isolation enforced through network spaces, quotas, and per-tenant QoS. See [Native multi-tenancy management](/operation-guide/weka-native-multi-tenancy-management.md).

Choose composable clusters when a tenant needs dedicated hardware, and native multi-tenancy otherwise. For the full comparison, see [Choose an isolation model](/operation-guide/weka-native-multi-tenancy-management.md#choose-an-isolation-model).
{% endhint %}

WEKA enables multi-tenancy by allowing multiple cluster deployments to share the same hardware while maintaining full resource isolation. This is achieved through a Kubernetes Operator that facilitates the composition of resource sets (including hosts, drives, cores, and memory) into independent clusters.

The process of creating these composable clusters is efficient, taking only a few minutes. Each cluster is allocated dedicated resources, ensuring consistent performance without interference from other tenants.

<div data-with-frame="true"><figure><img src="https://2924606337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqDcZwR9zamxPsY03oTOq%2Fuploads%2Fgit-blob-ad4741a218bd1771d5445c7c40297c579d81fe4e%2Fweka-multi-tenancy-concept.png?alt=media" alt="" width="563"><figcaption><p>WEKA composable clusters for multi-tenancy concept</p></figcaption></figure></div>

### Key benefits

* **Full resource isolation:** WEKA’s composable cluster model ensures complete isolation across drives, processors, and memory, providing a higher level of security than traditional multi-tenant models that rely on process isolation while sharing hardware resources. This architecture strengthens security boundaries, mitigates risks associated with legacy designs, and ensures both isolation and performance requirements are met.
* **Scalability and performance:** WEKA’s multi-tenant architecture is aligned with [NCP guidelines](#user-content-fn-1)[^1], including the common network reference architecture. Service providers can benefit from all of WEKA's scalability and performance in a multi-tenant deployment without compromise, while also simplifying network management and optimizing hardware utilization.
* **Enhanced security:** WEKA clusters leverage multiple layers of security. It employs a comprehensive encryption model, with both cluster-wide and per-filesystem customizations, which are fully supported in multi-tenant environments. Tenant management uses least-privileges role definitions to integrate with modernities like Kubernetes and CSI. Multi-tenancy encryption protect file and object data, and sensitive metadata such as file names and timestamps, with only the file size remaining unencrypted. Features such as Organizations add additional delegations within tenant clusters and help protect end user data from administrators while clients maintain full control over encryption management. This approach provides a higher level of protection than traditional models, ensuring data security and compliance.
* **Simplified management:** The WEKA Operator simplifies deployment and management of the WEKA Data Platform. It automates routine storage operations and enhances cluster resilience using custom resources. Real-time monitoring tools provide insights into usage and performance, enabling proactive management and seamless resource expansion.
* **Cost optimization and efficiency:** WEKA maximizes hardware utilization, reduces infrastructure costs, and streamlines configuration to minimize administrative overhead. This approach optimizes resource efficiency while lowering operational expenses.

## Composable clusters for multi-tenancy deployment at a glance

1. The WEKA Operator monitors the current state of the Kubernetes cluster.
2. When there are changes to WEKA custom resource definitions, the Operator applies the changes to the running Kubernetes cluster.
3. The changes are composed sets of resources, which bring about the creation of a new cluster, perform an expansion or contraction of an existing cluster, decommission a cluster, or perform an upgrade.

<div data-with-frame="true"><figure><img src="https://2924606337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqDcZwR9zamxPsY03oTOq%2Fuploads%2F6ChgcXC6cb2cop30VZ5u%2FComposable_clusters.png?alt=media&amp;token=de339dad-67a1-46ce-94a7-4ac6f5e4d0a9" alt=""><figcaption><p>Composable clusters for multi-tenancy deployment at a glance</p></figcaption></figure></div>

### Resource partitioning across Kubernetes nodes

Composable clusters can use only a subset of Kubernetes nodes.

Apply these placement rules:

* Each cluster can use a different number of Kubernetes nodes.
* Each cluster must use a distinct set of Kubernetes nodes.

For example, cluster 1 can use 12 nodes. Cluster 2 can use 6 different nodes. Cluster 3 can use another 6 different nodes.

## Summary

WEKA’s multi-tenant architecture delivers a highly secure, scalable, and cost-efficient solution for service providers and enterprises. Composable clusters deliver full resource isolation and automated management to meet the ever-evolving demands of modern AI, ML, and high-performance computing environments.

For detailed deployment procedures and day-2 operations see:

* [WEKA Operator deployments](/kubernetes/weka-operator-deployments.md)
* [Deploy Composable Clusters on Kubernetes using the CDM](/kubernetes/weka-operator-deployments/cloud-deployment-manager-kubernetes-deployment-types/deploy-composable-clusters-on-kubernetes-using-the-cdm.md)
* [Monitor, scale, and maintain the cluster](/kubernetes/weka-operator-day-2-operations.md)

[^1]: **NCP (NVIDIA Cloud Platform)**: A framework or set of guidelines for designing scalable, high-performance, and multi-tenant network architectures. It includes a common network reference architecture to ensure interoperability, optimize resource utilization, and simplify network management.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.weka.io/kubernetes/composable-clusters-for-multi-tenancy-in-kubernetes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.