Multi-tenant Kubernetes platform for regulated workloads
Product teams each requested their own cluster to guarantee isolation, leaving the platform team maintaining many similar environments.
This is an illustrative reference design describing how Protogenies approaches this class of problem. It is not a named client engagement, and it contains no performance claims.
What has to be solved
Cluster count drives upgrade and security burden, while teams still need credible isolation and self-service.
Technical constraints
- Workload isolation must be demonstrable
- Upgrades cannot require per-team coordination each time
- Platform changes must be auditable
Approach
A smaller number of shared clusters with namespace-per-tenant isolation, network policy, resource quotas, admission control and GitOps delivery of both platform and tenant workloads.
Implementation
- 01Cluster and tenancy design with an isolation rationale per control
- 02GitOps repository structure separating platform and tenant scopes
- 03Network policy defaults, quotas and admission policies
- 04Per-tenant observability with scoped dashboards and alerts
- 05Scheduled upgrade runbook exercised in a non-production cluster
Technology stack
Expected qualitative outcomes
- Self-service namespaces provisioned through review rather than tickets
- Fewer clusters to patch, upgrade and monitor
- Isolation controls that can be shown to a reviewer
- Platform and tenant state reproducible from git
Things to weigh up
- Some regulatory positions still require physical cluster separation
- Shared control planes need clear noisy-neighbour limits
Talk to the engineers who would do the work
Bring your current architecture, constraints and the problem you are trying to solve. We will tell you what we would change first, what it depends on, and where we would start.