Kubernetes / Platform Design
Multi-Tenant
Kubernetes Platforms
Your managed Kubernetes cluster is the foundation. On top of it we design a multi-tenant platform for your organization, with isolated tenants, policies as code and one shared Helm chart.
Multitenancy & Isolation
Namespace-level isolation with RBAC, quotas, network policies, and pod security. Each team gets its own blast radius.
Smart Guardrails
Kyverno enforces policies as code, plus admission control, image policies and audit logging. The rules apply to every tenant automatically.
Unified Tenancy Toolkit
One Helm chart renders all tenant resources: namespaces, policies, secrets, registries and RBAC. ArgoCD syncs them to the cluster, and optional operators cover custom lifecycle steps.
Multi-Tenant Architecture
On top of your managed cluster we design an architecture in layers: onboarding, authentication, tenant isolation, policy enforcement, platform services and observability.
GitOps · Helm · Pull Request Workflow
Tenant Provisioning
Once your managed cluster runs, the next task is multi-tenancy. We design a provisioning layer on top of it, so onboarding a new team no longer takes weeks of tickets.
We design and integrate a tenant Helm chart for your organization that renders every required resource from one values.yaml. ArgoCD syncs the rendered manifests to the cluster. For lifecycle steps the chart cannot cover, we build operators:
Secrets Management
ClusterSecretStores and Vault paths per tenant, rendered automatically
Container Registry
Registry projects with dedicated pull secrets and image policies
Network Policies
Cilium-based namespace isolation, configured via Helm values
Kyverno Policies
Per-tenant admission rules, image allow-lists, resource limits
Monitoring
Tenant-scoped dashboards, alerts, and log aggregation
ArgoCD reconciles the desired state continuously. If someone deletes a policy or misconfigures a secret, ArgoCD detects the drift and restores the baseline rendered from the Helm chart.
GitOps with Smart Guardrails
Every change goes through Git. ArgoCD applies it, and Kyverno checks it against your policies before it lands.
feature/team-beta→mainPolicy-as-Code
Kyverno policies
Admission Control
Validate & mutate
Image Policies
Signed images only
Pod Security
Restricted profile
Audit Trail
Audit logs
Compliance
ISO 27001 · GDPR
Self-Service Onboarding
We design the onboarding flow so a new team is defined, deployed and operating within minutes.
Define
The platform team writes a tenant values.yaml: namespaces, quotas, RBAC, network policies, secrets, registry access.
Deploy
The GitOps pipeline picks up the change. ArgoCD renders the Helm chart and syncs all tenant resources to the cluster.
Operate
Teams work on their own within the guardrails. ArgoCD watches for drift and keeps the cluster in the state defined in Git.
A new team joins the platform with one pull request.
In Practice: Multi-Platform Container Architecture
The design works across deployment models. The same tenant Helm chart and guardrails apply wherever your workloads run.
Natron Cloud
Managed Kubernetes on Swiss infrastructure: we operate the cluster, platform and tenancy.
Natron Flex Stack
We run the same platform design as a dedicated private cloud on your hardware.
Bring Your Own Cloud
We deploy the platform design on your infrastructure: Azure, GCP or on-premise.
Shared Platform Services
One Tenancy Model
The same tenant Helm chart works on Natron Cloud, Flex Stack and BYOC. Platform differences are toggles in the values file, and operators come as add-ons where needed.
Centralized Registry
One container registry serves all platforms. Flex Stack and BYOC clusters pull images from it, so nothing is duplicated.
Environment Parity
Test, integration and production clusters share the same architecture, so a release behaves the same in every stage.
Network-First Design
Every cluster gets its own address space, so clusters can be connected later without renumbering.
Ingress NGINX Retirement: Why We Didn't Switch to Gateway API Yet
- Why we postponed Gateway API despite 5 years of spec development
- 20+ controllers evaluated across 6 weighted criteria
- Step-by-step migration with annotation translation table