A shared Kubernetes cluster runs workloads for several MSP clients on one cluster, usually separated by namespaces, access policies, network rules, and resource controls. A per-client cluster gives each customer a separate control plane, worker environment, lifecycle, and failure boundary.
Use a shared cluster when clients can accept a common platform, the MSP retains administrative control, and standardized policies can provide the required isolation. Use a per-client cluster when a customer needs cluster-admin access, privileged workloads, an independent upgrade schedule, a contractual dedicated boundary, or a smaller blast radius than a shared control plane can provide. Many MSPs scale best with a tiered model rather than one universal answer.
Shared and per-client clusters optimize different boundaries
The decision is not simply cheap versus expensive.
| Model | Primary optimization | Main trade-off |
|---|---|---|
| Shared cluster | Density, standardization, and lower duplicated operations | Wider shared failure and policy boundary |
| Shared cluster with dedicated node pools | Better compute placement inside one platform | Control plane and cluster lifecycle remain shared |
| Per-client cluster | Isolation, lifecycle independence, and clearer accountability | More duplicated infrastructure and operating work |
| Several shared clusters by tier or risk | Smaller blast radius without one cluster per customer | More clusters to operate than a single shared model |
A shared cluster makes the namespace, identity, policy, and workload placement model responsible for tenant separation. A per-client cluster moves more of that separation to the cluster boundary itself.
Neither option removes the need for security, observability, backups, resource planning, or incident ownership.
Use seven questions to choose the tenancy model
What level of tenant trust exists?
Kubernetes documentation distinguishes between cooperative tenants and tenants that may need stronger protection from one another.
A shared cluster is easier to justify when:
- the MSP operates every workload;
- clients do not receive cluster-admin access;
- workloads follow a standard security baseline;
- privileged containers and host-level access are prohibited;
- clients accept a common cluster lifecycle.
A per-client cluster is safer when one customer must be treated as untrusted by another or when the client controls workloads that the MSP cannot fully constrain.
Who needs administrative control?
Cluster-admin access reaches beyond one namespace. It can affect cluster-wide resources, admission controls, custom resource definitions, networking, storage, and other tenants.
Use a separate cluster when a client needs:
- cluster-admin privileges;
- custom admission controllers;
- cluster-wide operators or CRDs with uncertain impact;
- privileged DaemonSets;
- host networking or host filesystem access;
- custom CNI, CSI, or policy components.
Namespaces are not a substitute for a separate administrative boundary.
Can clients share one upgrade and maintenance rhythm?
A shared cluster has one Kubernetes version and one cluster-level maintenance lifecycle. Clients may run different application versions, but the underlying platform moves together.
Choose a per-client cluster when a customer needs:
- a delayed or accelerated Kubernetes upgrade;
- a customer-specific maintenance window;
- a different add-on version;
- independent testing and approval;
- a separate rollback or decommission timeline.
Shared clusters reward standardization. Dedicated clusters support divergence.
How large can the blast radius be?
A cluster-level networking error, admission-policy mistake, failed upgrade, exhausted control-plane dependency, or broken shared add-on can affect every tenant in a shared cluster.
Per-client clusters reduce cross-client impact, but they create more independent systems that can drift or fail separately.
The correct question is:
Is the MSP more prepared to manage one larger shared failure domain or many smaller operational surfaces?
How different are workload profiles?
Similar workloads are easier to place together. Highly variable workloads create fairness and noisy-neighbor risks.
Review:
- CPU and memory bursts;
- storage latency and throughput;
- network behavior;
- pod density;
- database and queue dependencies;
- scheduled jobs;
- privileged or hardware-specific requirements.
Dedicated node pools may solve compute-placement or performance concerns while keeping the control plane shared. They do not provide a fully independent cluster lifecycle.
How should costs be allocated?
Shared clusters improve utilization, but chargeback requires measurement. Per-client clusters provide clearer resource ownership, but duplicate minimum infrastructure and operations.
What does the customer contract promise?
The technical design must match the service language.
“Dedicated environment,” “isolated cluster,” “customer-controlled maintenance,” and “separate administrative boundary” are stronger promises than “logically isolated workloads.” Do not sell a namespace boundary as a dedicated cluster.
Hard-stop conditions usually require a per-client cluster
A per-client cluster is normally the safer default when any of these conditions apply:
- The contract explicitly requires a dedicated cluster.
- The client requires cluster-admin access.
- The client runs privileged or host-level workloads.
- The client needs independent Kubernetes or add-on versions.
- The client requires a separate maintenance and upgrade approval process.
- A cluster-wide incident must not affect another customer.
- The environment may later be transferred to the client.
- The workload uses cluster-wide extensions that cannot be safely standardized.
- The client’s security review does not accept soft multi-tenancy.
These are architectural boundaries, not problems that should be hidden behind more namespace policy.
Shared clusters need layered tenant isolation
A shared cluster is not secure merely because every client has a namespace.
Namespaces organize the tenancy model
Use a predictable namespace structure for each client and environment. Avoid placing unrelated tenants in the same namespace.
A naming pattern might distinguish:
client-a-production client-a-staging client-b-production
Namespaces improve organization and allow namespaced policies, but some Kubernetes resources remain cluster-scoped.
RBAC must follow least privilege
Kubernetes RBAC uses Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings to control API access.
For shared clusters:
- grant namespaced permissions where possible;
- avoid broad wildcard permissions;
- restrict access to secrets;
- separate human and workload identities;
- review service-account permissions;
- tightly limit ClusterRoleBindings;
- keep cluster-admin access with a small, accountable operator group.
A client user should not be able to enumerate or modify another client’s resources.
NetworkPolicy should deny unintended traffic
Kubernetes allows pod-to-pod communication unless the network implementation and policies restrict it.
Use a deny-by-default model, then explicitly allow:
- ingress from approved gateways;
- service-to-service paths within the tenant;
- required database, cache, queue, and DNS traffic;
- controlled egress to approved external services.
Confirm that the cluster networking implementation actually enforces NetworkPolicy. Creating policy objects is not enough when the network layer does not apply them.
ResourceQuota and LimitRange protect fairness
Resource quotas limit namespace consumption. Limit ranges can set or constrain resource requests and limits.
Use them to control:
- total CPU and memory requests;
- total CPU and memory limits;
- pod count;
- storage claims;
- object counts where appropriate;
- default container requests and limits.
Quotas protect the platform only when workloads declare resources realistically and the MSP monitors actual usage beside requested capacity.
Admission and pod security controls protect the cluster
Shared tenancy needs rules for:
- privileged containers;
- host namespaces;
- hostPath volumes;
- unsafe capabilities;
- unsigned or unapproved images;
- required labels and ownership;
- approved registries;
- resource requirements;
- security contexts.
One tenant’s deployment should not gain host-level access that weakens every other tenant’s boundary.
Secrets and identities must stay tenant-specific
Use separate service accounts, secrets, external credentials, and automation identities for each client.
Do not reuse one database credential, object-storage key, deployment token, or registry credential across tenants merely because the workloads share a cluster.
Storage needs an explicit tenant boundary
Persistent volumes, snapshots, backups, storage classes, and restore workflows must preserve tenant ownership.
Confirm:
- which client owns each volume;
- whether dynamic provisioning can cross namespaces incorrectly;
- who can create or attach storage;
- how snapshots and restores are authorized;
- what happens to persistent data during offboarding.
Observability must not leak client data
Shared logging and monitoring can expose namespace names, request paths, labels, log content, or customer identifiers.
Create tenant-aware access rules and retention policies. Client dashboards should not reveal another tenant’s workloads or operational events.
Dedicated node pools are a middle boundary, not a dedicated cluster
A dedicated node pool can help when one client needs:
- reserved compute capacity;
- different node sizes;
- workload placement controls;
- reduced compute noisy-neighbor risk;
- taints, tolerations, and affinity rules;
- specialized performance characteristics.
The model still shares:
- the control plane;
- cluster-wide networking and policy components;
- cluster version and upgrade process;
- cluster-scoped extensions;
- many observability and operational systems;
- cluster-level incident risk.
Use dedicated node pools when the problem is compute placement or capacity ownership. Use a per-client cluster when the problem is administrative, lifecycle, trust, or failure isolation.
Several shared clusters can reduce risk without one cluster per client
MSPs with many customers often need more than the two extreme choices.
A practical grouping model may create separate shared clusters by:
- production and non-production;
- service tier;
- client risk profile;
- workload type;
- region;
- regulated and non-regulated workloads;
- internal platform version.
This limits blast radius and upgrade complexity without duplicating a full cluster for every small customer.
Avoid arbitrary grouping. Each cluster should have a documented reason, owner, lifecycle, and client-assignment rule.
Shared clusters scale better when the service is standardized
A shared model is usually strongest when the MSP sells a repeatable platform rather than a custom cluster for every account.
Good candidates have:
- similar deployment patterns;
- common ingress, monitoring, and security controls;
- predictable resource profiles;
- a shared Kubernetes version policy;
- no client cluster-admin access;
- standard backup and recovery expectations;
- clear resource quotas and support limits.
The commercial offer should explain what is shared, what is isolated, which actions the client can perform, and what happens during maintenance or a platform incident.
Per-client clusters scale better when independence is part of the product
A dedicated cluster becomes easier to justify when the customer is paying for:
- a separate operational boundary;
- independent upgrades and maintenance;
- dedicated worker capacity;
- customer-specific add-ons;
- clearer billing and asset inventory;
- simpler transfer or termination;
- reduced cross-client blast radius;
- stronger administrative isolation.
The MSP must still standardize cluster creation, monitoring, upgrades, backup checks, access reviews, and retirement. Otherwise, dedicated clusters become a fleet of inconsistent snowflakes.
Compare the operating workload, not only infrastructure cost
Per-client clusters duplicate more than compute.
A useful cost model includes:
Worker capacity + control-plane or HA choices + persistent storage + ingress and networking + backups and recovery + monitoring and logging + security tooling + upgrade and support labor + spare capacity
Shared-cluster chargeback
Allocate cost using a combination of:
- requested CPU and memory;
- actual CPU and memory use;
- persistent storage;
- backup consumption;
- external services;
- dedicated node-pool capacity;
- support tier;
- exceptional operational work.
Requested resources matter because they reserve scheduling capacity even when actual usage is low.
Per-client chargeback
A dedicated cluster makes direct infrastructure ownership clearer, but the MSP should still price:
- minimum cluster footprint;
- high-availability choices;
- monitoring and backup coverage;
- upgrade labor;
- incident response;
- unused reserved headroom.
Do not use historical VM prices in an evergreen tenancy guide. Verify current Kubernetes and supporting-service prices on the live Raff pages.
Onboarding and offboarding expose the real operational difference
Shared-cluster onboarding
A repeatable client onboarding workflow should create:
- namespaces;
- resource quotas and limit ranges;
- RBAC bindings and service accounts;
- deny-by-default network policy;
- approved ingress and egress rules;
- secrets and external credentials;
- storage and backup ownership;
- monitoring, logs, and alerts;
- labels for cost and ownership;
- validation that another tenant remains inaccessible.
Per-client onboarding
A dedicated workflow should create:
- the cluster and network boundary;
- node pools and scaling limits;
- access and kubeconfig ownership;
- baseline policies and add-ons;
- ingress, DNS, and certificates;
- storage and recovery configuration;
- monitoring and alert routing;
- upgrade and maintenance ownership;
- asset and billing records;
- a tested handover or recovery process.
Offboarding
Shared-cluster offboarding requires careful removal of namespace resources, persistent volumes, secrets, identities, backups, logs, DNS, and external integrations without affecting other tenants.
Per-client clusters are easier to identify as one asset boundary, but the MSP must still export required data, revoke access, preserve agreed retention, and verify deletion before destroying the cluster.
Upgrade strategy changes with the tenancy model
A shared cluster forces clients onto a common platform schedule. Use:
- supported-version policy;
- pre-production validation;
- maintenance communication;
- add-on compatibility testing;
- workload disruption budgets;
- rollback and recovery planning.
Per-client clusters allow different schedules but multiply the number of upgrade campaigns. Track version age, maintenance status, failed upgrades, and exceptions centrally.
A customer-specific version exception should have an owner and expiry date. Permanent exceptions become operational debt.
Incident response follows the boundary you choose
Shared cluster
An incident may affect several tenants. The MSP needs:
- tenant-aware impact assessment;
- cluster-level and namespace-level telemetry;
- communication rules for multiple clients;
- evidence that unaffected tenants remain isolated;
- a controlled way to suspend one tenant’s workload if it threatens the platform.
Per-client cluster
Impact is easier to assign to one customer, but responders must search across more clusters and configurations.
Central inventory, monitoring, access, and runbooks are essential. Isolation does not help when the team cannot quickly find the affected cluster or understand its differences.
Backups and disaster recovery remain workload decisions
A separate cluster does not automatically provide disaster recovery. A shared cluster does not automatically prevent tenant-specific restoration.
Define recovery for:
- databases;
- persistent volumes;
- object data;
- secrets and configuration;
- cluster manifests;
- external DNS and integrations;
- client-specific recovery order.
Back up state according to the system that owns it. Test restore and client-level recovery independently of cluster recreation.
A tiered MSP offer usually scales best
A practical service catalog can use three levels.
| Service tier | Boundary | Suitable clients |
|---|---|---|
| Standard | Shared cluster with namespace, RBAC, policy, and quota isolation | Cooperative workloads following one platform standard |
| Isolated compute | Shared cluster with dedicated node pool plus tenant policies | Clients needing reserved capacity or stronger placement separation |
| Dedicated | Separate cluster, network, lifecycle, and access boundary | Clients needing independent administration, upgrades, or contractual isolation |
The tier names are commercial choices. The technical description must remain precise.
From an MSP service-design perspective, the important step is to define the boundary before setting the price. Otherwise, the platform team may promise dedicated behavior from shared infrastructure or absorb dedicated-cluster operations inside a standard-tier margin.
How this applies on Raff
Raff’s current Kubernetes offering provides managed Kubernetes clusters with worker-node pricing, node pools, optional high availability, monitoring, private cluster networking, and worker-pool autoscaling. Verify current capabilities and prices on the live Kubernetes product page.
A shared-cluster Raff model can use:
- one Kubernetes cluster;
- one namespace set per client and environment;
- strict RBAC and service-account boundaries;
- deny-by-default NetworkPolicy;
- quotas and limit ranges;
- dedicated node pools where compute separation is justified;
- tenant-aware monitoring and backup ownership.
A per-client Raff model can use:
- one cluster per customer;
- the cluster’s own network boundary;
- customer-specific node pools and scaling limits;
- separate access, maintenance, monitoring, and recovery records;
- live pricing for the complete cluster footprint.
Do not claim that a shared namespace has the same boundary as a separate cluster. Do not assume that separate clusters eliminate the need for policies, backups, least privilege, or operational standardization.