---
tags:
- k8s
- l1
- flashcard-deck
- multi-tenancy
---
<!-- wiki:breadcrumb:start -->
[Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [Multi-Tenancy Patterns](../../../../library/portal/topics.md) | **Domain:** Kubernetes
<!-- wiki:breadcrumb:end -->

id	category	difficulty	tags	question	answer	source_path
multi-tenancy/000ac789603a	multi-tenancy	easy	multi-tenancy, models	What are the three Kubernetes multi-tenancy models and their isolation levels?	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.\n\nRemember: Soft(namespaces+RBAC)=cheap. Hard(separate clusters)=secure but expensive.	training/library/topics/multi-tenancy/primer.md
multi-tenancy/b86435da8f0e	multi-tenancy	easy	multi-tenancy, quotas	Why are resource quotas not optional in a multi-tenant Kubernetes cluster?	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.\n\nRemember: Models: namespace-per-tenant, cluster-per-tenant, vCluster(middle ground).	training/library/topics/multi-tenancy/primer.md
multi-tenancy/279805c8d0d3	multi-tenancy	easy	multi-tenancy, network-policy	What is the first network policy you should create in every tenant namespace?	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.\n\nRemember: K8s multi-tenancy: ResourceQuotas + NetworkPolicies + RBAC. "QNR."	training/library/topics/multi-tenancy/primer.md
multi-tenancy/5c3ea97b0076	multi-tenancy	medium	multi-tenancy, limit-range	What is the difference between ResourceQuotas and LimitRanges, and how do they work together?	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.\n\nRemember: Multi-tenancy = isolation at network, resource, and access levels.	training/library/topics/multi-tenancy/primer.md
multi-tenancy/91a803cfc3a9	multi-tenancy	medium	multi-tenancy, rbac	What should tenant RBAC roles include and exclude in a namespace-per-tenant model?	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.\n\nRemember: K8s multi-tenancy: ResourceQuotas + NetworkPolicies + RBAC. "QNR."	training/library/topics/multi-tenancy/primer.md
multi-tenancy/9a162d6a8a92	multi-tenancy	medium	multi-tenancy, priority-class	Why are priority classes important in a multi-tenant cluster and what is a recommended hierarchy?	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.\n\nRemember: Models: namespace-per-tenant, cluster-per-tenant, vCluster(middle ground).	training/library/topics/multi-tenancy/primer.md
multi-tenancy/045eb85c124e	multi-tenancy	medium	multi-tenancy, network-policy, cni	What is the critical prerequisite for network policies to actually work in a Kubernetes cluster?	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.\n\nRemember: Multi-tenancy = isolation at network, resource, and access levels.	training/library/topics/multi-tenancy/primer.md
multi-tenancy/06f3c0b51705	multi-tenancy	hard	multi-tenancy, provisioning	What resources should be created as a unit when onboarding a new tenant, and why should this be automated?	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.\n\nRemember: Models: namespace-per-tenant, cluster-per-tenant, vCluster(middle ground).	training/library/topics/multi-tenancy/primer.md
multi-tenancy/b8dcd9d2d88d	multi-tenancy	hard	multi-tenancy, blast-radius	How does each isolation mechanism reduce the blast radius of a tenant mistake or compromise?	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.\n\nRemember: Soft(namespaces+RBAC)=cheap. Hard(separate clusters)=secure but expensive.	training/library/topics/multi-tenancy/primer.md
multi-tenancy/e65209163168	multi-tenancy	hard	multi-tenancy, vcluster	When should you upgrade from namespace-per-tenant to virtual clusters, and what does vCluster provide?	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.\n\nRemember: K8s multi-tenancy: ResourceQuotas + NetworkPolicies + RBAC. "QNR."	training/library/topics/multi-tenancy/primer.md

<!-- wiki:related:start -->
---

## Wiki Navigation

### Related Content

- [Multi-Tenancy Patterns](../../../../library/topics/multi-tenancy/index.md) (Topic Pack, L2) — Multi-Tenancy Patterns

<!-- wiki:related:end -->
