- TechOps Examples
- Posts
- Kubernetes Multi Tenancy Models
Kubernetes Multi Tenancy Models
Govardhana M K
November 08, 2025
In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
👋 👋 A big thank you to today's sponsor PROTON MAIL
Free email without sacrificing your privacy
Gmail is free, but you pay with your data. Proton Mail is different.
We don’t scan your messages. We don’t sell your behavior. We don’t follow you across the internet.
Proton Mail gives you full-featured, private email without surveillance or creepy profiling. It’s email that respects your time, your attention, and your boundaries.
Email doesn’t have to cost your privacy.
👀 Remote Jobs
Supabase is hiring a Multigres Deployment Engineer
Remote Location: Worldwide
Eight Sleep is hiring a Senior ML Operations (MLOps) Engineer
Remote Location: Worldwide
📚️ Resources
Looking to promote your company, product, service, or event to 57,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
Kubernetes Multi Tenancy Models
To understand multi tenancy, you first need to know how Kubernetes handles a request. When you run kubectl apply to create a Deployment, the API server takes over. It checks if the request is valid, confirms who you are, and makes sure you have permission. Then it saves the Deployment details into etcd, the cluster’s database.
After that, the Deployment controller sees the new Deployment and creates a matching ReplicaSet. The ReplicaSet makes sure the right number of pods are running. If any pods are missing, it creates them and updates etcd.
Now the scheduler comes in. It finds the new pods that don’t have a node yet, looks at all available nodes, and picks the best one for each pod.
Catch here. This is only metadata at this point. No containers are running yet. The actual execution starts when the kubelet on a worker node notices a pod has been assigned to it. It contacts the API server, fetches the pod details, prepares the runtime, and starts the containers.
The problem is, Kubernetes doesn't separate users or teams by default. Every request, no matter who sends it, goes through the same API server. All the data ends up in the same etcd. And every kubelet handles pods the exact same way, no matter who created them.
And the same control plane manages workloads from all teams.
That’s why building real isolation in Kubernetes needs more than the default setup. This is where multi tenancy begins to matter.
Kubernetes Multi Tenancy Approaches:
Soft Isolation: Suitable for internal use within a single organization where multiple teams share the same Kubernetes cluster.
Hard Isolation: Ideal for scenarios where the cluster serves multiple external organizations or clients.
Approach 1: Namespace Based Multi Tenancy
In this model, multiple teams share a single Kubernetes cluster. Each team gets a namespace, but the control plane, etcd, and worker nodes are all shared.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
Already a paying subscriber? Sign In.
Paid subscriptions get you:
- • Access to archive of 250+ use cases
- • Deep Dive use case editions (Thursdays and Saturdays)
- • Access to Private Discord Community
- • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- • Quarterly 1:1 'Ask Me Anything' power session