# Cluster-Grenzen & Betrieb

> Kubernetes als Plattform mit expliziten Verantwortungs-, Ressourcen- und Recovery-Grenzen statt als Sammlung von YAML-Dateien verstehen.

Track: [Kubernetes & Platform Operations](https://physar.tech/learn/kubernetes-platform-ops)  
Kanonische Fassung: https://physar.tech/learn/kubernetes-platform-ops/cluster-boundaries  
Stand: 2026-07-26

## Ein Cluster ist eine Plattform mit Grenzen, nicht nur ein Scheduler

### Workloads teilen Infrastruktur, nicht automatisch Vertrauen

Namespaces, RBAC, Network Policies, Resource Requests und Limits adressieren unterschiedliche Grenzen. Keine einzelne Einstellung macht Mandanten oder Teams automatisch isoliert; jede Schutzwirkung muss zur Bedrohung und zum Betriebsmodell passen.

_[Abbildung: Eine belastbare Plattform verbindet Identität, Kommunikation, Ressourcen und Wiederherstellung statt sich auf eine einzelne YAML-Einstellung zu verlassen.]_

> **Merksatz:** Kubernetes-Objekte sind Steuerflächen. Ihre Schutzwirkung entsteht erst aus der passenden Kombination und Durchsetzung.

### Scheduling ist eine Kapazitätsentscheidung

Requests beeinflussen die Platzierung und Planbarkeit; Limits begrenzen Verbrauch auf unterschiedliche Weise je Ressource. Ohne realistische Werte entstehen entweder unzuverlässige Nachbarschaftseffekte oder ungenutzte Kapazität.

|  |  |
| --- | --- |
| Request | Reservierungs- und Scheduling-Signal. |
| Limit | Obergrenze für Ressourcenverbrauch; kein Ersatz für Kapazitätsplanung. |
| Quota | Team- oder Namespace-Grenze gegen unbegrenzte gemeinsame Nutzung. |

> **Trade-off:** Enge Grenzen schützen andere Workloads, können aber einen kritischen Dienst drosseln oder verdrängen. Beobachtung und Priorisierung gehören dazu.

### Upgrade und Recovery sind Plattformarbeit

Kompatibilität und Abhängigkeiten prüfen → Änderung begrenzt durchführen → Workload- und Plattformsignale beobachten → **Rückweg oder Wiederherstellung testen**

Ein grüner Node oder ein laufender Pod beweist nicht, dass Daten, Ingress, Policies und Anwendungsabhängigkeiten wiederherstellbar sind.

### Gleich im Check

- Die richtige Kubernetes-Grenze für Identität, Netzwerk oder Ressourcen wählen
- Planbarkeit von reiner Laufzeitbegrenzung unterscheiden
- Ein Plattform-Upgrade mit überprüftem Rückweg entwerfen

## Quellen

- Kubernetes Documentation: Multi-tenancy — https://kubernetes.io/docs/concepts/security/multi-tenancy/
- Kubernetes Documentation: Resource Management — https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/