PP
🚀 Platform Engineer Lektion 21/50 ~9 Min. Fortgeschritten

Resource Governance, Quotas und FinOps

Fairness, Chargeback, Showback und Kostenallokation auf Plattform-Ebene.

#finops #quotas
📝 Meine Notizen

Lernziele

Nach dieser Lektion kannst du die technische Seite der Resource Governance (ResourceQuotas, LimitRanges, PriorityClasses) mit der ökonomischen Seite (Kostenallokation, Showback, Chargeback) verbinden. Du verstehst, warum Requests — nicht Usage — die Cluster-Kosten treiben, wie man Kosten in Shared-Clustern fair zuordnet, und kannst begründen, wann Showback genügt und wann Chargeback nötig wird.

Das Problem: Im Shared-Cluster ist die Rechnung anonym

Das Shared-Modell aus Lektion 19 hat einen eingebauten Anreizfehler: Die Cloud-Rechnung kommt als ein Betrag beim Platform-Team an, während fünfzig Teams die Kosten verursachen. Niemand sieht den Preis seiner eigenen Entscheidungen — also fordert jedes Team großzügige Ressourcen an, „sicherheitshalber”. Das Resultat kennt jede Plattform: Cluster, die laut Requests zu 85 % belegt sind, laut tatsächlicher CPU-Nutzung aber bei 20 % dümpeln. Bezahlt werden die Nodes trotzdem — denn der Scheduler reserviert nach Requests, nicht nach Verbrauch.

Resource Governance hat deshalb zwei untrennbare Hälften: Mengensteuerung (wer darf wie viel beanspruchen?) und Kostentransparenz (wer erfährt, was sein Anspruch kostet?). Nur Quotas ohne Kostensicht erzeugt Verteilungskämpfe um willkürliche Limits; nur Kostenberichte ohne Durchsetzung erzeugt Berichte, die niemand liest.

Die Mechanik: Quotas, Limits, Prioritäten

Drei Kubernetes-Objekte bilden das Fundament, alle auf Namespace-Ebene und damit direkt an die Tenant-Struktur gekoppelt:

ResourceQuota deckelt die Summe pro Namespace — Rechenressourcen und Objektanzahlen:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-orders-quota
  namespace: team-orders
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 64Gi
    limits.cpu: "40"
    limits.memory: 96Gi
    persistentvolumeclaims: "10"
    services.loadbalancers: "2"

Wichtig fürs Verständnis: Die Quota wirkt bei der Admission — ein Pod, der sie sprengen würde, wird abgelehnt. Und sobald eine Quota für CPU/Memory existiert, müssen Pods Requests/Limits deklarieren, sonst werden sie verweigert.

LimitRange ergänzt Defaults und Grenzen pro Container — damit Pods ohne explizite Angaben sinnvolle Requests bekommen statt einer Ablehnung, und damit kein Einzelcontainer absurde Werte anfordert.

PriorityClasses regeln den Konfliktfall: Wenn der Cluster voll ist, verdrängt (preempted) der Scheduler niederpriore Pods zugunsten höherpriorer. Ein übliches Schema: platform-critical (Ingress, DNS, Monitoring) > production > batch/best-effort. Das macht Überbuchung beherrschbar: Batch-Workloads dürfen Restkapazität nutzen, fliegen aber raus, wenn Produktion sie braucht.

Die strategische Stellschraube dahinter ist die Overcommit-Politik: Limits über Requests zu erlauben (z. B. Limit = 2× Request) erhöht die Auslastung, kauft das aber mit Throttling- und OOM-Risiko unter Gleichzeitigkeitslast — eine bewusste Entscheidung pro Workload-Klasse, kein Naturgesetz.

Kostenallokation: aus einer Rechnung fünfzig machen

Showback und Chargeback brauchen zuerst eine technische Antwort: Wie zerlegt man die Kosten eines geteilten Nodes auf Tenants? Das Standardverfahren (umgesetzt etwa von OpenCost, dem CNCF-Projekt hinter Kubecost):

  1. Stundenpreis des Nodes aus der Cloud-Abrechnung holen.
  2. Anteil pro Pod berechnen — fair ist max(Request, Usage) pro Ressource: Wer viel reserviert und wenig nutzt, zahlt für die Reservierung (denn sie blockiert den Platz); wer über seine Requests hinaus verbraucht, zahlt für den Verbrauch.
  3. Idle-Kosten (gekaufte, aber niemandem zugeordnete Kapazität) und Shared-Kosten (Monitoring, Ingress, Control Plane) nach einem dokumentierten Schlüssel umlegen — proportional zur Nutzung oder als Grundgebühr pro Tenant.
  4. Aggregation über Labels: Das setzt voraus, dass jeder Workload ein team- bzw. Kostenstellen-Label trägt — weshalb Label-Pflicht per Admission Policy (Kyverno/OPA, Lektion 28) die unsexy Grundlage jeder FinOps-Initiative ist.

Damit zur Governance-Frage: Showback heißt, jedes Team sieht monatlich seine zugerechneten Kosten — ohne Budgetfolgen. Chargeback heißt, die Kosten werden tatsächlich auf die Kostenstelle des Teams gebucht. Die reife Reihenfolge ist fast immer: erst Monate von Showback (Daten validieren, Diskussionen führen, Vertrauen in die Zahlen aufbauen), dann — nur wenn die Organisation es braucht — Chargeback. Chargeback verändert Verhalten stärker, erzeugt aber auch stärkere Nebenwirkungen: Teams beginnen, um Allokationsschlüssel zu streiten, und Finance wird Stakeholder jeder Plattform-Architekturentscheidung. Viele Organisationen bleiben bewusst bei Showback plus Budget-Alerts — Verhaltensänderung entsteht oft schon durch Sichtbarkeit plus Management-Aufmerksamkeit.

Governance als Kreislauf, nicht als Mauer

Quotas und Kostenberichte entfalten Wirkung erst als Prozess:

  • Quota-Vergabe mit Begründung: Initiale Quotas aus dem Onboarding (Self-Service-Antrag mit Größenklasse, Lektion 16), Erhöhungen gegen einen leichten Nachweis („eure Usage liegt seit 4 Wochen bei 80 % der Quota” genügt) statt gegen politisches Gewicht.
  • Rightsizing-Schleife: Die wertvollste FinOps-Metrik im Cluster ist die Lücke zwischen Requests und tatsächlicher Nutzung. Berichte pro Team („eure CPU-Requests sind 5× eure P95-Nutzung — Einsparpotenzial X €/Monat”) plus Tooling-Hilfe (VPA-Empfehlungen) machen Optimierung zur Routinearbeit statt zum Projekt.
  • Plattform-Hebel nicht vergessen: Die größten Einsparungen liegen oft nicht bei den Tenants, sondern beim Platform-Team selbst — Spot-/Preemptible-Nodes für Batch-Klassen, Cluster-Autoscaling bzw. Karpenter-artige Node-Provisionierung, Reserved Instances/Savings Plans für die Grundlast. Governance gegenüber Teams ersetzt keine Kapazitätsarbeit (Lektion 24).

Praxis: Quota-Verhalten und Kostenrechnung erleben

In einem kind-Cluster:

kubectl create namespace tenant-a
kubectl apply -n tenant-a -f quota.yaml   # die ResourceQuota von oben, Werte klein wählen:
                                          # requests.cpu: "1", requests.memory: 1Gi

# 1. Pod ohne Requests → wird abgelehnt:
kubectl run test --image=nginx -n tenant-a
# Fehlermeldung lesen: "failed quota: must specify requests..."

# 2. Pod mit Requests innerhalb der Quota → läuft:
kubectl run test --image=nginx -n tenant-a \
  --overrides='{"spec":{"containers":[{"name":"test","image":"nginx",
  "resources":{"requests":{"cpu":"200m","memory":"128Mi"},
  "limits":{"cpu":"400m","memory":"256Mi"}}}]}}'

# 3. Quota-Verbrauch beobachten:
kubectl describe resourcequota -n tenant-a

Rechne anschließend eine Mini-Kostenallokation von Hand: Ein fiktiver Node kostet 100 €/Monat und hat 4 CPU-Kerne. Tenant A requested 2 Kerne und nutzt 0,5; Tenant B requested 1 und nutzt 1,2; der Rest ist idle. Verteile die 100 € nach max(Request, Usage) und entscheide, wie du die Idle-Kosten umlegst. Diese Handrechnung ist genau die Logik, die OpenCost automatisiert — und eine hervorragende Whiteboard-Antwort.

Typische Stolperfallen

Usage statt Requests optimieren: Wer nur auf CPU-Auslastungs-Dashboards schaut, übersieht, dass der Scheduler — und damit die Node-Anzahl und die Rechnung — von Requests bestimmt wird. Rightsizing heißt zuerst: Requests an die Realität anpassen.

Quotas ohne LimitRange: Sobald eine Quota aktiv ist, scheitern Pods ohne Request-Angaben. Ohne LimitRange-Defaults bricht das erste Tutorial-Deployment jedes neuen Teams — ein vermeidbarer Onboarding-Schmerz.

Chargeback vor Datenqualität: Wenn die ersten verrechneten Beträge auf lückenhaften Labels und strittigen Idle-Schlüsseln beruhen, diskutiert die Organisation monatelang über die Methode statt über Kosten. Showback-Phase ernst nehmen.

Kostenbericht ohne Handlungsempfehlung: „Ihr habt 12.000 € verbraucht” bewegt nichts. „Eure Top-3-Einsparungen: Requests von Service X halbieren (−800 €), Dev-Umgebung nachts skalieren (−400 €), …” bewegt — Berichte müssen Empfehlungen enthalten, sonst sind sie Rauschen.

Interview-Vorbereitung

Auf „Wie steuerst du Ressourcen und Kosten in einer Multi-Tenant-Plattform?” antwortest du zweispurig: Mechanik (ResourceQuota pro Tenant-Namespace, LimitRange für Defaults, PriorityClasses + Preemption für Überbuchung) → Ökonomie (Label-basierte Kostenallokation nach max(Request, Usage), Idle- und Shared-Kosten mit dokumentiertem Schlüssel) → Governance-Stufen (Showback zuerst, Chargeback nur bei organisatorischem Bedarf, Budget-Alerts dazwischen) → Kreislauf (Rightsizing-Berichte, Quota-Anpassung gegen Nachweis, Plattform-eigene Hebel wie Spot und Autoscaling).

Wahrscheinliche Follow-ups:

  • „Warum nach Requests abrechnen, wenn die Usage niedriger ist?” — Requests reservieren Kapazität und bestimmen das Scheduling; reservierter, ungenutzter Platz kostet real Geld und muss dem Verursacher sichtbar werden.
  • „Showback oder Chargeback?” — Showback als Default: geringere Reibung, meist ausreichende Verhaltenswirkung; Chargeback, wenn Budgetverantwortung dezentral liegt oder Compliance es verlangt — dann mit gehärteter Datenqualität.
  • „Ein Team braucht kurzfristig das Dreifache seiner Quota — was passiert?” — Self-Service-Antrag mit Begründung und schneller Bearbeitung; technisch ist die Erhöhung trivial, der Prozess muss es auch sein, sonst wird die Quota als Plattform-Willkür erlebt.
  • „Wie geht ihr mit Idle-Kosten um?” — transparent ausweisen statt verstecken; umlegen nach dokumentiertem Schlüssel und parallel durch Autoscaling und Rightsizing aktiv senken — Idle ist primär ein Platform-Team-Problem.

Zusammenfassung

Resource Governance verbindet Durchsetzung und Transparenz: ResourceQuotas, LimitRanges und PriorityClasses machen Ansprüche im Shared-Cluster fair und Überbuchung beherrschbar; Label-basierte Kostenallokation nach max(Request, Usage) macht aus einer anonymen Cloud-Rechnung Team-Verantwortung — erst als Showback, bei Bedarf als Chargeback. Der eigentliche Kostentreiber sind Requests, nicht Verbrauch, und die wirksamste Routine ist die Rightsizing-Schleife plus die Plattform-eigenen Hebel.

Quotas regeln, wie viel ein Tenant bekommt. Die nächste Lektion regelt, mit wem er reden darf: Netzwerk-Segmentierung und Zero-Trust-Design in Multi-Tenant-Plattformen.