Kubernetes ResourceQuota: Memory-Limits steuern 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 16.09.2026

TL;DR: kubernetes resourcequota kurz erklärt

Eine ResourceQuota begrenzt die Summe der Requests und Limits im Namespace. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) trennt diesen Deckel vom einzelnen Container-Limit. Ohne Memory-Limit kann ein Prozess den Node ausräumen. CPU-Limits drosseln, sie töten seltener. Kubecost misst, setzt nichts.

Das Problem: Sie messen Verbrauch und lassen den Node weich

Das Dashboard zeigt CPU und Memory. Finance sieht eine Zahl. Der Nachbar-Namespace startet einen Batch ohne Memory-Limit.

Dann frisst ein Prozess den Node. Eviction trifft nicht nur den Schuldigen. Scheduling auf Requests hilft nicht, wenn Limits fehlen. CPU ohne Limit ist oft verhandelbar. Memory ohne Limit ist grob fahrlässig. Kunden sagen das in Reviews genau so.

Genau hier sitzt kubernetes resourcequota. Die Schicht ist Policy: die Summe im Namespace darf ein hartes Maximum nicht überschreiten. LimitRange setzt Defaults, damit ein nacktes Deployment nicht ohne Limit landet.

Wir sehen das als Lücke, nicht als fehlendes Kosten-Tool. Kubecost oder OpenCost erklären, wer verbraucht. Sie verhindern nicht, dass der Verbrauch den Nachbarn umwirft. Zwei Schichten.

Pexon Consulting schneidet Limits deshalb als Review-Frage: wo fehlt Memory-Limit, wo fehlt der Namespace-Deckel, wer darf ohne Limit deployen.

Was deckelt eine ResourceQuota – und was deckelt sie nicht?

Eine ResourceQuota begrenzt die Summe der Requests und Limits im Namespace. Sie ersetzt weder Container-Memory-Limits noch ein Kosten-Dashboard.

Die Kubernetes-Doku (Resource Quotas, Stand 1.36, gelesen 16.09.2026) trennt requests.memory und limits.memory. Request ist Scheduling. Limit ist Deckel. memory ohne Präfix zählt wie requests.memory. Pods in terminalem Zustand zählen nicht zur Summe.

Was kubernetes resourcequota ausdrücklich nicht ist:

1. Kein per-Container-Limit. Das setzt resources.limits am Container, oder LimitRange als Default.
2. Kein Showback. Kubecost allokiert Verbrauch. Quota verhindert Überbuchung im Namespace.
3. Keine drei Umgebungen. Drei Namespaces auf einer Control Plane sind keine drei Cluster.
4. Kein Hosting-Preis. Dieser Text verkauft keinen Tarif.

Offizielle Referenzen: Resource Quotas und Limit Ranges. Keine erfundenen Eviction-Schwellen.

# Schicht, keine Installationsanleitung. Werte an Ihren Namespace anpassen.
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "40"

Steht Quota auf CPU oder Memory, verlangt die API Requests oder Limits an jedem neuen Pod. Fehlen sie, kann Admission ablehnen. LimitRange füllt Defaults, bevor das passiert.

Seit Kubernetes 1.36 gilt dasselbe für In-Place-Resize: eine Resize, die die Namespace-Summe sprengt, wird abgelehnt. Das ist Frische, kein Grund, Quota wegzulassen.

Warum ist ein fehlendes Memory-Limit gefährlicher als ein fehlendes CPU-Limit?

Die kurze Antwort: Memory ohne Limit kann den Node ausräumen. CPU ohne Limit drosselt später, tötet seltener.

Request ist die Reservierung für den Scheduler. Limit ist die Kappe zur Laufzeit. Überschreitet ein Container das Memory-Limit, kommt OOMKill. Überschreitet er das CPU-Limit, drosselt der CFS-Quota. Der Prozess lebt. Der Nachbar merkt CPU-Mangel, nicht einen toten Node.

Deshalb unsere klare Empfehlung: Memory-Limit an jedem Fach-Workload. CPU-Limit oft ~ oder bewusst weicher, wenn das Team Latency kennt und den Trade-off trägt. „CPU-Limit immer gleich Memory-Limit“ ist Folie, kein Betrieb.

Wann wir davon abraten: pauschal CPU-Limits auf 50m in einem API-Namespace, weil jemand eine Tabelle kopiert hat. Das erzeugt Throttling und Ticketlärm, nicht Sicherheit.

LimitRange setzt min, max und Default. Ohne LimitRange und ohne Quota landet ein nacktes Deployment ohne Memory-Limit. Dann ist der Node weich, bis der erste Batch kommt.

Wann reicht LimitRange, wann brauchen Sie Quota plus Showback?

LimitRange reicht, wenn ein Team den Namespace allein besitzt und Defaults gesetzt sind. Sobald zwei Teams denselben Cluster teilen, brauchen Sie Quota. Sonst bucht das lautere Team den Rest weg.

Showback (Kubecost, OpenCost) kommt dazu, wenn Finance oder Leitung eine Zahl will. Die Zahl ersetzt den Deckel nicht. Wer nur misst, erklärt den Ausfall hinterher. Wer nur deckelt und nie misst, streitet über den Wert der Quota.

Drei beschriftete Namespaces ersetzen Quota nicht. Auch Dev braucht einen Deckel. Wir haben das als eigene Plane-Frage, nicht als zweiten Artikel hier.

DataForSEO nannte am 16.09.2026 für kubernetes resourcequota 20 Suchen, LOW. Die Prio kommt aus Reviews und VoC, nicht aus Head-Term-Volumen. Memory-Limit haben wir nicht extra gekauft.

Wie prüfen Sie Limits und Quota in einem Cluster Review?

Vier Fragen, keine Installationsschritte.

1. Welche Deployments laufen ohne Memory-Limit? Das ist die weiche Stelle, nicht die fehlende Kubecost-Lizenz.
2. Steht LimitRange im Namespace, oder hoffen Sie auf Disziplin im YAML?
3. Welche ResourceQuota gilt, für Requests und für Limits getrennt?
4. Wer sieht Overflow: Admission (Pod kommt nicht) oder erst das Dashboard?

Wenn Quota fehlt und Memory-Limits lückenhaft sind, ist der Cluster messbar und trotzdem offen. Pexon Consulting schreibt das als Finding. Der Managed Service trägt denselben Deckel im Alltag, wenn Betrieb das Thema ist, nicht nur der einmalige Schnitt.

Was wir nicht anfassen: eine zweite AKS-Money-Page, ein Kubecost-Klon, Hosting-Preise, erfundene Prozent „CPU reicht immer“. Focus bleibt kubernetes resourcequota.

AKS-Aufbau bleibt die Angebotsseite Azure AKS Consulting. Dieser Text ist Policy, nicht der Plattform-Verkauf.

LimitRange und ResourceQuota gehören zusammen, sonst lehnt Admission Pods ab, die niemand mit Defaults versorgt hat. Erst Default, dann Summe. Umgekehrt erzeugt die Quota Tickets statt Schutz.

Requests ohne Limits sind für CPU oft tragbar. Requests ohne Memory-Limit sind die Variante, die den Node weich lässt. Wir sehen das in Reviews als Muster: YAML hat requests.memory, limits.memory fehlt, LimitRange fehlt, Quota fehlt. Das Dashboard ist trotzdem grün, weil niemand die Summe sprengt, bis der Batch kommt.

Was wir in lebenden Clustern häufiger sehen als „Quota fehlt komplett“: eine Quota nur auf pods und CPU, Memory unbegrenzt. Oder Quota-Werte, die größer sind als der Node-Pool. Dann ist das Objekt da und der Deckel wirkungslos.

Pexon Consulting bleibt beim Review. Wir zählen fehlende Memory-Limits und prüfen, ob die Quota Requests und Limits getrennt setzt. Wir verkaufen keinen Hosting-Tarif und keinen zweiten AKS-Hero. kubernetes resourcequota bleibt Policy.

Häufig gestellte Fragen

Ist ein Limit dasselbe wie ein Request?

Nein. Request ist Scheduling. Limit ist Deckel zur Laufzeit. Ohne Request rät der Scheduler falsch. Ohne Memory-Limit kann der Prozess den Node füllen. Quota summiert beides im Namespace, ersetzt keines von beiden.

Was kostet eine ResourceQuota im Betrieb?

Das Objekt ist Teil von Kubernetes, ohne Lizenz. Geld sitzt in der Pflege der Werte und im Streit, wer den Deckel setzen darf. Der Einstieg bei uns ist der 45-Minuten-Cluster-Check, kein Preis für YAML.

Reichen Memory-Limits ohne ResourceQuota?

Kommt darauf an. Ein Team, ein Namespace, saubere Limits: oft ja. Zwei Teams auf einem Cluster: nein. Dann bucht der Nachbar die Summe weg, auch wenn jeder eigene Limits hat.

Ersetzt Kubecost die Quota?

Nein. Kubecost misst und allokiert. Quota und Limit setzen. Wer nur Showback kauft, erklärt den Noisy Neighbor hinterher. Das ist die teurere Variante.

Brauchen Dev-Namespaces einen Deckel?

Ja. Dev ohne Quota ist der Namespace, in dem jemand „kurz“ ohne Limit startet. Drei Planes ersetzen das nicht. Auch Dev braucht eine Summe.

Nächster Schritt

Verwandte Themen