Kubernetes / Plattform-Design
Multi-Tenant
Kubernetes-Plattformen
Ihr Managed Kubernetes Cluster ist die Grundlage. Darauf entwerfen wir eine Multi-Tenant-Plattform für Ihre Organisation, mit isolierten Tenants, Policies als Code und einem gemeinsamen Helm Chart.
Multitenancy & Isolation
Isolation auf Namespace-Ebene mit RBAC, Quotas, Netzwerk-Policies und Pod Security. Jedes Team erhält seinen eigenen Blast Radius.
Smarte Leitplanken
Kyverno setzt Policies als Code durch, dazu kommen Admission Control, Image Policies und Audit Logging. Die Regeln gelten automatisch für jeden Tenant.
Einheitliches Tenancy-Toolkit
Ein Helm Chart rendert alle Tenant-Ressourcen: Namespaces, Policies, Secrets, Registries und RBAC. ArgoCD synchronisiert sie in den Cluster, optionale Operators übernehmen besondere Lifecycle-Schritte.
Multi-Tenant-Architektur
Auf Ihrem Managed Cluster entwerfen wir eine Architektur in Schichten: Onboarding, Authentifizierung, Tenant-Isolation, Policy Enforcement, Plattform-Services und Observability.
GitOps · Helm · Pull Request Workflow
Tenant-Provisionierung
Sobald Ihr Managed Cluster läuft, ist Multi-Tenancy die nächste Aufgabe. Wir entwerfen darauf eine Provisionierungsschicht, sodass ein neues Team nicht mehr wochenlang auf Tickets wartet.
Wir entwerfen und integrieren ein Tenant Helm Chart für Ihre Organisation, das alle benötigten Ressourcen aus einer values.yaml rendert. ArgoCD synchronisiert die gerenderten Manifeste in den Cluster. Für Lifecycle-Schritte, die das Chart nicht abdeckt, bauen wir Operators:
Secrets Management
ClusterSecretStores und Vault-Pfade pro Tenant, automatisch gerendert
Container Registry
Registry-Projekte mit dedizierten Pull Secrets und Image Policies
Netzwerk-Policies
Cilium-basierte Namespace-Isolation, über Helm-Values konfiguriert
Kyverno Policies
Tenant-spezifische Admission-Regeln, Image Allow-Lists, Ressourcen-Limits
Monitoring
Tenant-spezifische Dashboards, Alerts und Log-Aggregation
ArgoCD gleicht den Soll-Zustand laufend ab. Löscht jemand eine Policy oder konfiguriert ein Secret falsch, erkennt ArgoCD die Abweichung und stellt die aus dem Helm Chart gerenderte Baseline wieder her.
GitOps mit smarten Leitplanken
Jede Änderung läuft über Git. ArgoCD spielt sie ein, Kyverno prüft sie dabei gegen Ihre Policies.
feature/team-beta→mainPolicy-as-Code
Kyverno-Policies
Admission Control
Validate & Mutate
Image Policies
Signierte Images
Pod Security
Restricted-Profil
Audit Trail
Audit-Logs
Compliance
ISO 27001 · GDPR
Self-Service Onboarding
Wir entwerfen den Onboarding-Flow so, dass ein neues Team innert Minuten definiert und in Betrieb ist.
Definieren
Das Platform-Team schreibt eine values.yaml für den Tenant: Namespaces, Quotas, RBAC, Netzwerk-Policies, Secrets, Registry-Zugriff.
Deployen
Die GitOps-Pipeline nimmt die Änderung auf. ArgoCD rendert das Helm Chart und synchronisiert alle Tenant-Ressourcen in den Cluster.
Betreiben
Teams arbeiten selbstständig innerhalb ihrer Leitplanken. ArgoCD erkennt Drift und hält den Cluster im Zustand, der in Git definiert ist.
Ein neues Team kommt per Pull Request auf die Plattform.
In der Praxis: Multi-Plattform Container-Architektur
Das Design funktioniert über alle Deployment-Modelle hinweg. Dasselbe Tenant Helm Chart und dieselben Leitplanken gelten, wo immer Ihre Workloads laufen.
Natron Cloud
Managed Kubernetes auf Schweizer Infrastruktur: Wir betreiben Cluster, Plattform und Tenancy.
Natron Flex Stack
Dasselbe Plattform-Design betreiben wir als dedizierte Private Cloud auf Ihrer Hardware.
Bring Your Own Cloud
Wir setzen das Plattform-Design auf Ihrer Infrastruktur um: Azure, GCP oder On-Premise.
Gemeinsame Plattform-Services
Ein Tenancy-Modell
Dasselbe Tenant Helm Chart läuft auf Natron Cloud, Flex Stack und BYOC. Plattform-Unterschiede sind Schalter in der values.yaml, Operators kommen bei Bedarf als Add-ons dazu.
Zentrale Registry
Eine Container Registry versorgt alle Plattformen. Flex-Stack- und BYOC-Cluster ziehen ihre Images von dort, sodass nichts doppelt gepflegt wird.
Umgebungsparität
Test-, Integrations- und Produktions-Cluster haben dieselbe Architektur, sodass sich ein Release in jeder Stufe gleich verhält.
Network-First Design
Jeder Cluster bekommt einen eigenen Adressraum. So lassen sich Cluster später verbinden, ohne das Netz umzubauen.
Ingress NGINX End of Life: Warum wir noch nicht zu Gateway API gewechselt haben
- Warum wir Gateway API trotz 5 Jahren Entwicklung vorerst verschoben haben
- Über 20 Controller anhand von 6 gewichteten Kriterien evaluiert
- Schritt-für-Schritt-Migration mit vollständiger Annotations-Übersetzungstabelle