Skip to content

Multi Tenancy

← Back to all decks

16 cards — 🟢 3 easy | 🟡 4 medium | 🔴 3 hard

🟢 Easy (3)

1. What are the three Kubernetes multi-tenancy models and their isolation levels?

Show answer Namespace per tenant (isolation: 2/5, lowest cost, simplest), Virtual Cluster per tenant using tools like vCluster (isolation: 4/5, moderate cost, tenants get their own API server), and Dedicated Cluster per tenant (isolation: 5/5, highest cost, maximum isolation). Namespace per tenant is the right starting point for most teams.

Remember: Soft(namespaces+RBAC)=cheap. Hard(separate clusters)=secure but expensive.

2. Why are resource quotas not optional in a multi-tenant Kubernetes cluster?

Show answer Without quotas, one namespace can consume every CPU core and byte of memory in the cluster. A single tenant's runaway deployment can starve all other tenants. Once a ResourceQuota exists in a namespace, every pod must declare resource requests and limits or be rejected, forcing tenants to think about their resource needs.

Remember: Models: namespace-per-tenant, cluster-per-tenant, vCluster(middle ground).

3. What is the first network policy you should create in every tenant namespace?

Show answer A default-deny-all policy with an empty podSelector and both Ingress and Egress policyTypes. This ensures no pods can communicate with anything by default. Then add explicit allow rules for intra-namespace traffic, DNS egress (port 53 UDP/TCP), and ingress from the ingress controller namespace.

Remember: K8s multi-tenancy: ResourceQuotas + NetworkPolicies + RBAC. "QNR."

🟡 Medium (4)

1. What is the difference between ResourceQuotas and LimitRanges, and how do they work together?

Show answer ResourceQuotas cap the total resources for an entire namespace (e.g., total 40Gi memory). LimitRanges constrain individual containers and pods (e.g., max 8Gi per container, default 512Mi). LimitRanges also inject default resource specs into pods that omit them, acting as a safety net so even forgetful tenants get sensible defaults instead of unbounded allocation.

Remember: Multi-tenancy = isolation at network, resource, and access levels.

2. What should tenant RBAC roles include and exclude in a namespace-per-tenant model?

Show answer Include: get/list/watch/create/update/patch/delete on pods, deployments, services, configmaps, jobs, cronjobs. Allow reading secrets but not creating/deleting. Allow pods/log and pods/exec. Exclude: ClusterRole bindings, access to nodes/namespaces/persistentvolumes (cluster-scoped), escalate/bind verbs on roles (privilege escalation), and access to secrets in kube-system.

Remember: K8s multi-tenancy: ResourceQuotas + NetworkPolicies + RBAC. "QNR."

3. Why are priority classes important in a multi-tenant cluster and what is a recommended hierarchy?

Show answer Without priority classes, pod eviction under resource pressure is arbitrary — your monitoring stack could be evicted alongside batch jobs. Recommended hierarchy: system-critical (1000000) for cluster infrastructure, tenant-production (100000) for production workloads, tenant-development (10000, globalDefault) for dev/staging, tenant-burst (1000, preemptionPolicy: Never) for best-effort workloads that are evicted first.

Remember: Models: namespace-per-tenant, cluster-per-tenant, vCluster(middle ground).

4. What is the critical prerequisite for network policies to actually work in a Kubernetes cluster?

Show answer Network policies require a CNI that supports them, such as Calico, Cilium, or Weave. If you use a CNI that does not enforce network policies (e.g., default kubenet), the NetworkPolicy objects exist in the API but have zero effect — traffic flows unrestricted between all pods despite the policies being defined.

Remember: Multi-tenancy = isolation at network, resource, and access levels.

🔴 Hard (3)

1. What resources should be created as a unit when onboarding a new tenant, and why should this be automated?

Show answer Create as a unit: Namespace, ResourceQuota (compute and object limits), LimitRange (per-container defaults and caps), NetworkPolicy (default-deny plus explicit allows), Role (tenant-developer), RoleBinding (team to role), ServiceAccount (for CI/CD), and PriorityClass reference. Automate with a controller, Helm chart, or Crossplane composition — manual provisioning does not scale past five tenants and leads to drift.

Remember: Models: namespace-per-tenant, cluster-per-tenant, vCluster(middle ground).

2. How does each isolation mechanism reduce the blast radius of a tenant mistake or compromise?

Show answer Without quotas: one runaway tenant consumes all cluster compute. With quotas: constrained to allocation. Without default-deny network policy: tenant can reach all pods in the cluster. With default-deny: isolated to own namespace. With ClusterRoleBinding: tenant reads all secrets cluster-wide. With namespace-scoped Role: tenant reads only their own secrets. Multi-tenancy is the intersection of all mechanisms — skipping any one widens the blast radius.

Remember: Soft(namespaces+RBAC)=cheap. Hard(separate clusters)=secure but expensive.

3. When should you upgrade from namespace-per-tenant to virtual clusters, and what does vCluster provide?

Show answer Upgrade when tenants need to install their own CRDs, need independent cluster-admin access, or when namespace-level isolation is insufficient (cluster-scoped resources are shared, compromised API server affects everyone). vCluster creates lightweight, isolated Kubernetes API servers inside the host cluster — each tenant sees their own cluster with their own control plane while workloads run on shared nodes.

Remember: K8s multi-tenancy: ResourceQuotas + NetworkPolicies + RBAC. "QNR."