Understanding Kubernetes Multi-Tenancy

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to the deep dive use case edition.

👀 Remote Jobs

• Avalanche is hiring a DevOps Engineer

  Remote Location: Worldwide

• IronOrbit is hiring a Network Engineer

  Remote Location: Worldwide

Looking to promote your company, product, service, or event to 46,000+ Cloud Native Professionals? Let's work together. Advertise With Us

🧠 DEEP DIVE USE CASE

Understanding Kubernetes Multi-Tenancy

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

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 archieve of 170+ 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