Robin Werner, Kubernetes-Consultant bei Pexon Consulting | 11 Min. Lesezeit | 29.08.2026
TL;DR
Namespaces schneiden Sie entlang genau einer Achse: Teams, Services oder Umgebungen. Wer zwei Achsen mischt, erbt RBAC-Chaos und undichte NetworkPolicies. Für regulierte AKS-Plattformen 2026 gilt die klare Regel: eine Default-Achse, Isolation über ResourceQuota und Policy, physischen Cluster-Sprawl bewusst klein halten.
Namespaces schneiden scheitert an gemischten Achsen
Die meisten AKS-Plattformen scheitern nicht am CNI und nicht am Ingress. Sie scheitern daran, dass niemand die Achse festlegt, entlang derer Namespaces geschnitten werden. Ein Team bekommt team-payments, parallel entsteht svc-ledger, dazu env-staging und irgendwann payments-staging-team-a. Auditoren fragen danach nach Isolation, FinOps nach Kostenstellen, Security nach NetworkPolicies, die niemand pflegen kann, weil die Namenskonvention keine Aussage mehr hat.
Namespaces schneiden ist eine Governance-Entscheidung, keine YAML-Übung. Der Namespace ist die kleinste sinnvolle Isolationseinheit in Kubernetes: RBAC bindet daran, ResourceQuota bindet daran, NetworkPolicy bindet daran, und die meisten Cost-Exports gruppieren darüber. Wenn die Achse unklar ist, werden alle drei Steuerungsinstrumente weich. Die Quota-Zeile allein reicht nicht: Memory-Limits und ResourceQuota trennen Container-Deckel und Namespace-Summe.
Wir sehen das Muster besonders bei Greenfield-Plattformen in regulierten Branchen. Eine Genossenschaftsbank im Greenfield startete mit „ein Namespace pro Deployment“, landete bei 80 Namespaces ohne Owner und brauchte drei Monate, um Ownership und Quotas nachzuziehen. Der Schaden lag nicht in Azure-Kosten, sondern in Audit-Nacharbeit und Deploy-Blockaden.
Unsere Position dazu ist unmissverständlich: Eine Plattform ohne dokumentierte Namespace-Achse ist nicht „flexibel“. Sie ist unsteuerbar. Die Achse muss vor dem ersten Production-Workload stehen, nicht danach.
Drei Achsen im Vergleich: Teams, Services, Umgebungen
Bevor Sie Labels und Helm-Charts diskutieren, wählen Sie eine Primärachse. Sekundäre Information gehört in Labels, nicht in neue Namespaces.
Teams als Achse. Sinnvoll, wenn Product-Teams End-to-End liefern und ein Platform-Team Standards setzt. Der Namespace wird zum Vertrag: Quota, Policy, Logging-Labels und On-Call-Route gehören dem Team. Shared-Platform-Dienste (ingress, observability, cert-manager) bleiben in Platform-Namespaces mit strikter Deny-by-Default-Policy.
Services als Achse. Sinnvoll, wenn Domänen klar und langlebig sind und Teams sich häufiger ändern als Services. Der Preis ist Inflation: 40 Services bedeuten 40 Namespaces plus Policy-Sets. Ohne automatisierte Policy-Templates (Kyverno, OPA Gatekeeper) kippt der Betrieb.
Umgebungen als Achse. Sinnvoll als grobe Trennung, wenn Sie wenige Teams haben und Stages hart trennen wollen. Als alleinige Achse in großen Organisationen reicht sie nicht: prod wird zur Müllhalde ohne Ownership. Environments gehören dann eher als Label oder als zweites Cluster/Schutzzone, nicht als einzige Namespace-Logik.
Klare Meinung: Für den DACH-Mittelstand mit Product-Teams und AKS ist der Team-Schnitt in 2026 der Default. Service-Schnitt nur, wenn Domänen wirklich stabiler sind als Org-Charts. Environment-only vermeiden, sobald mehr als zwei Delivery-Teams parallel deployen.
Was in den Namespace gehört: Quota, NetworkPolicy, RBAC
Ein Namespace ohne Steuerungsobjekte ist nur ein Ordner. Isolation entsteht erst, wenn drei Dinge zusammen sitzen:
- ResourceQuota und LimitRange begrenzen CPU, Memory und Objektzahlen. Ohne Quota kann ein Team den Node-Pool leersaugen.
- NetworkPolicy (ideal Deny-by-Default) begrenzt den Ost-West-Verkehr. Auf AKS mit Kubernetes 1.29+ und Azure CNI Powered by Cilium sind NetworkPolicies First-Class und performanter als ältere Azure-CNI-Pfade ohne Cilium-Dataplane.
- RBAC bindet Menschen und Service-Accounts an den Namespace. ClusterRoleBindings auf
edit/adminfür ganze Gruppen sind der klassische Compliance-Fail.
Beispiel für einen Team-Namespace mit Quota und einer restriktiven Default-Deny-NetworkPolicy. Das Muster läuft auf AKS mit Azure CNI Powered by Cilium:
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-payments-quota
namespace: team-payments
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
limits.cpu: "40"
limits.memory: 80Gi
pods: "80"
persistentvolumeclaims: "20"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: team-payments
spec:
podSelector: {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-ingress-and-same-ns
namespace: team-payments
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: platform-ingress
- podSelector: {}Anwenden und prüfen:
kubectl apply -f team-payments-baseline.yaml
kubectl -n team-payments get resourcequota,networkpolicy
kubectl auth can-i create deployments -n team-payments --as=system:serviceaccount:team-payments:deployerWas nicht in den Namespace gehört: Cluster-weite Controller, Node-DaemonSets und die Illusion, dass Namespace gleich Tenant-Härte ist. Microsoft formuliert das in den AKS-Best-Practices zur Cluster-Isolation klar: Namespaces sind die logische Isolationsgrenze; physischen Cluster-Sprawl sollen Sie bewusst klein halten und nur dort skalieren, wo Soft-Multi-Tenancy nicht reicht (Compliance-Härte, Blast-Radius, Admin-Grenze).
Für Zero-Trust jenseits der Namespace-Grenze, etwa mTLS und Identity zwischen Services, greift später die Ebene Service Mesh und Zero Trust. Mesh ersetzt den Namespace-Schnitt nicht. Er setzt ihn voraus.
Wann der Team-Schnitt die richtige Default-Wahl ist
Wir empfehlen den Team-Schnitt, wenn mindestens drei der folgenden Punkte zutreffen:
- Product-Teams deployen selbstständig und tragen Incidents.
- FinOps braucht Kostenstellen pro Delivery-Einheit, nicht pro Microservice.
- Platform stellt Standards (Baseline-Policy, Observability, Ingress), Apps bleiben im Team-Namespace.
- Org-Chart ist stabiler als die Service-Liste (klassisch im Mittelstand).
- Auditoren fragen nach Ownership und Zugriffspfaden, nicht nach Pod-Namen.
Unter diesen Bedingungen wird der Namespace zum Betriebsvertrag. Labels wie service=ledger und env=prod bleiben sekundär. Stages können Sie über Labels, separate Deployments oder – wenn Schutzzonen es erzwingen – über getrennte Cluster lösen. Die Cluster-Anzahl selbst ist ein anderes Thema; hier geht es nur darum, dass die Namespace-Achse nicht die Cluster-Frage ersetzen darf und umgekehrt.
Gegenbeispiel: Ein reines Environment-Modell (dev/test/prod) mit fünf Teams im selben prod-Namespace. RBAC wird entweder zu grob (alle dürfen alles in prod) oder zu fein (RoleBindings pro Deployment, niemand pflegt sie). NetworkPolicies werden zu Ausnahmelisten. Das ist der Zustand, den wir in Reviews am häufigsten zurückbauen.
Meinung ohne Weichspüler: Environment-Namespaces als alleinige Achse sind 2026 in regulierten AKS-Landschaften nur noch für sehr kleine Plattform-Teams vertretbar. Sobald Ownership und Kosten zählen, gewinnen Teams.
Wann Service- oder Environment-Schnitt besser passt
Service-Schnitt wählen, wenn Domänen langfristig stabil sind, Teams rotieren und Sie ohnehin Policy-as-Code automatisieren. Dann ist svc-ledger langlebiger als team-xyz. Voraussetzung: ein Generator für Quota und NetworkPolicy, sonst erstickt das Platform-Team an Ticketarbeit. Ohne Automation ist Service-Schnitt oft Eitelkeit, kein Betriebskonzept.
Environment-Schnitt wählen, wenn Sie bewusst Stages hart trennen und nur ein oder zwei Delivery-Teams haben. Dann kann prod als Namespace funktionieren, solange Ownership über Labels und GitOps-Repos eindeutig bleibt. Sobald ein drittes Team dazukommt, kippt das Modell.
Hybride Schnitte (team-payments-prod) wirken pragmatisch und werden teuer. Sie verdoppeln die Achsen in einem Namen und erzeugen kombinatorische Explosion: jedes neue Team mal jede Stage. Labels lösen das sauberer. Wenn Compliance echte Härte zwischen Stages fordert, ist das eine Schutzzonen- und oft Cluster-Frage, keine Rechtfertigung für Namespace-Kombinatorik.
Zur Einordnung von Betriebsaufwand und Kostenstrukturen jenseits des Namespace-Schnitts hilft der Beitrag zu Kubernetes-Cluster-Kosten 2026. Hier bleibt der Fokus bewusst auf der logischen Achse.
Frische 2026: Cilium auf AKS und weniger Cluster-Sprawl
Zwei Entwicklungen machen den Namespace-Schnitt 2026 relevanter, nicht weniger.
Erstens: Azure CNI Powered by Cilium ist auf AKS für aktuelle Kubernetes-Versionen (1.29+) der empfohlene Netzwerkpfad, wenn Sie NetworkPolicies ernst nehmen. Cilium liefert eBPF-basierte Enforcement und bessere Observability der Policy-Hits. Wer Namespaces schneidet, ohne Policy-Stack und CNI-Fähigkeit zu koppeln, baut Papiertiger-Isolation.
Zweitens: Soft-Multi-Tenancy über Namespaces bleibt der Microsoft-Default für die meisten Workloads. Die Operator-Guidance betont logische Isolation zuerst und warnt vor unnötigem physischem Sprawl. Das deckt sich mit dem, was wir in regulierten Reviews sehen: Jeder zusätzliche Cluster verdoppelt Upgrade-, Identity- und Observability-Pfade. Wie die logische Isolation in vier Schichten aussieht und ab wann Cluster Nummer zwei doch fällig wird, steht auf der Seite zu Multi-Tenant auf Kubernetes.
Laut CNCF Annual Survey 2025 betreiben rund 82 Prozent der Container-Nutzer Kubernetes bereits produktiv. Die Plattformfrage verschiebt sich damit von „ob“ zu „wie steuern“. Laut CloudMagazin 2026 liegt der Operations-Overhead grob beim Faktor 1,7 pro zusätzlichem Cluster. Das ist eine Branchenbeobachtung, keine Pexon-Messreihe, aber sie erklärt, warum Namespace-Disziplin vor Cluster-Vermehrung kommen muss.
Wenn Sie unsicher sind, ob Ihr aktueller Schnitt auditfest ist, lohnt ein gezielter Kubernetes Cluster Review mit Fokus auf Namespace-Konvention, Quota-Abdeckung und Policy-Lücken. Die Hub-Seite zur Kubernetes-Beratung ordnet den Schnitt in den übrigen Plattform-Aufbau ein.
Häufig gestellte Fragen
Reicht ein Namespace pro Team für Production und Staging?
Nur wenn Stages über Labels, separate Deployments oder getrennte Schutzzonen klar getrennt sind und NetworkPolicies den Traffic begrenzen. Viele regulierte Setups trennen Production physisch oder zumindest in einer eigenen Schutzzone. Der Team-Namespace ersetzt diese Härte nicht, er organisiert Ownership innerhalb der Zone.
Was ist der Unterschied zwischen Namespace-Isolation und Cluster-Isolation?
Namespace-Isolation ist logisch: RBAC, Quota, NetworkPolicy. Cluster-Isolation ist physisch: eigene Control Plane, eigene Node-Pools, eigene Blast-Radius-Grenze. Microsoft empfiehlt, Sprawl zu minimieren und Clustersplitting nur dort, wo Soft-Tenancy nicht reicht. Der Namespace-Schnitt ist die Entscheidung davor.
Brauchen wir Kyverno oder Gatekeeper für den Namespace-Schnitt?
Ab einer Handvoll Teams praktisch ja. Ohne Policy-as-Code driftet die Baseline (Quota, Deny-Ingress, Pflicht-Labels) innerhalb weniger Sprints. Der Schnitt definiert die Achse; die Policy-Engine hält sie.
Wie benennen wir Shared Services wie Ingress oder Monitoring?
Eigene Platform-Namespaces mit restriktiver NetworkPolicy und engem RBAC. Application-Teams bekommen Leserechte oder definierte Ingress-Wege, keine Admin-Rechte auf Platform-Namespaces. Shared ohne Quota ist der häufigste FinOps- und Security-Blindspot.
Können wir später von Environment- auf Team-Schnitt migrieren?
Ja, aber planen Sie es als Projekt: Workload-Umzug, DNS/Ingress, Secrets, Quotas und Policy-Rewrite. Besser ist, die Achse vor dem zweiten Delivery-Team festzuziehen. Nachträgliche Migration ist machbar, selten billig an Kalenderzeit.
Nächster Schritt
Wenn Ihre Namespace-Konvention heute noch „historisch gewachsen“ heißt, treffen Sie zuerst die Achsen-Entscheidung: Teams, Services oder Umgebungen. Alles andere (Labels, Mesh, zusätzliche Cluster) baut darauf auf. Wir spiegeln den Schnitt gegen Ihre Schutzzonen und Compliance-Anforderungen, ohne aus dem Namespace-Thema eine Cluster-Anzahl-Debatte zu machen.
Verwandte Themen
