How One Platform Team Tamed 30 Product Teams on a Single Kubernetes Cluster
A B2B SaaS company's platform team built a multi-tenant Kubernetes platform using namespaces, Kyverno, and Crossplane, cutting provisioning time from days to minutes and halving incident rate.
Containers & K8s · advanced · 12 min read · 2266 words · By Sandip Das · Published
Composite scenario: built from common industry patterns; the figures are illustrative.
What this covers
- The Situation
- The Problem
- Constraints
- Options Considered
- The Solution
- Implementation
- Results
- What Went Wrong Along the Way
- Lessons Learned
- Apply It Yourself
Key numbers
| Metric | Before | After |
|---|---|---|
| New service provisioning time | 11 working days | 22 minutes (median) |
| Platform team reactive toil | 61% of sprint capacity | 19% of sprint capacity |
| Noisy-neighbour P1/P2 incidents | 3 per quarter | 0 in first two quarters |
| Containers running as root | 14 of 30 teams | 0 (policy-enforced) |
| Orphaned AWS resource cost | $34,000 per quarter | $2,100 per quarter |
Key components
- Kyverno — Admission controller that mutates and validates every pod spec to enforce security baselines and resource limits across all tenant namespaces.
- Crossplane — Kubernetes-native infrastructure provisioner that lets teams declare AWS resources (RDS, S3) as custom resources and detects console drift.
- Argo CD — GitOps engine that syncs tenant Git repositories to namespace-scoped Kubernetes resources, providing an immutable audit trail for SOC 2.
- Backstage Scaffolder — Developer portal that renders new-service templates into pull requests, removing the platform team from the provisioning critical path.
- Karpenter — Node lifecycle manager that replaced Cluster Autoscaler to eliminate scale-down thrashing on bursty workload patterns.
- Namespace-per-team isolation — Tenancy boundary enforced by ResourceQuota, LimitRange, and NetworkPolicy objects, providing cost attribution and blast-radius containment.
The Situation
This is a composite scenario assembled from patterns observed across multiple organisations; all figures are illustrative and chosen for internal consistency, not to represent any single company.
The organisation is a 420-person B2B SaaS company selling workflow-automation software to mid-market enterprises. Engineering is split into 30 product teams, each of two to six engineers, shipping features independently. The platform team is five people: two senior engineers, two mid-level, one SRE. Infrastructure runs on AWS in three regions (us-east-1, eu-west-1, ap-southeast-1). The pre-existing stack was a mix of hand-rolled ECS task definitions, a handful of self-managed EC2 instances, and a growing graveyard of CloudFormation stacks that only two people understood.
By late 2023 the company had 38 microservices in production and was adding roughly four per quarter. Each service needed its own RDS instance or shared schema, S3 buckets, IAM roles, and a CI/CD pipeline. The platform team was the single bottleneck for every new service.
The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.
Topics: kubernetes, multi-tenancy, platform-engineering, containers, devops, gitops
Related case studies
- How a B2B SaaS Platform Halved Kubernetes Compute Costs with Karpenter and Right-Sized Workloads
- How a B2B SaaS Platform Upgraded 40 Kubernetes Clusters Across Three Versions Without an Outage
- How a B2B SaaS Team Migrated a Rails Monolith to EKS With Zero Downtime
- How a New Telemetry Service Took Down OpenAI's Kubernetes API Servers and DNS in December 2024
- The Pi Day Outage: How a Renamed Kubernetes Node Label Took Reddit Down for Five Hours