Case: Rate Limiting und Fairness

Lernziele

Nach dieser Lektion kannst du den Fairness-Case „Ein Team frisst den ganzen Cluster — Designe Rate Limiting und faire Ressourcenverteilung” im Interview durchspielen: Du unterscheidest API-Rate-Limits, Kubernetes-Quotas, Scheduler-Fairness und Queueing, erklärst den Noisy-Neighbor-Effekt und skizzierst ein mehrstufiges Modell aus Soft Limits, Hard Quotas und Priorisierung.

Das Szenario: Montagmorgen, alles hängt

Die Aufgabe: „Wir haben 50 Teams auf drei Shared EKS-Clusters. Letzte Woche hat das ML-Team 400 GPU-Pods gescheduled — alle anderen Deployments pending. Designe ein System für faire Ressourcenverteilung und Rate Limiting.”

Das ist kein reines Kubernetes-Problem — es ist ein Governance- und Scheduling-Problem. Wer im Interview nur ResourceQuota sagt, lövt die Hälfte. Du brauchst Schichten: wer darf wie viel reservieren (Quota), wer darf wie schnell anfordern (Rate Limit), und was passiert bei Knappheit (Priorität, Preemption, Queue).

Anforderungen klären: Wo genau ist unfair?

1. Welche Ressource ist knapp? CPU, Memory, GPUs, API-Server-Rate (etcd), Ingress-Durchsatz, CI-Runner-Kapazität? Der ML-Fall deutet auf GPU-Nodes — andere Limits greifen nicht.
2. Burst vs. Sustained: Ein Team deployt 400 Pods in 5 Minuten (Burst) oder hält sie dauerhaft (Sustained)? Maßnahmen unterscheiden sich.
3. Prioritäten: Hat prod Vorrang vor dev? Hat das Payments-Team Vorrang vor dem internen Dashboard? Wer entscheidet — und ist das dokumentiert?
4. Sichtbarkeit: Sehen Teams ihre Quota-Auslastung, bevor sie crashen? Ohne Dashboards ist Fairness nur Bestrafung.
5. Escape Hatch: Darf ein Team temporär über Quota — mit Genehmigung? Wie?

Architektur: Vier Schichten der Fairness

Schicht 1 — Kubernetes ResourceQuota + LimitRange (Basis).

• Pro Namespace: max CPU/Memory Requests, max Pods, max PVCs, max GPU (nvidia.com/gpu).
• LimitRange: Default-Requests/Limits pro Container — verhindert BestEffort-Pods, die den Scheduler verwirren.
• Problem: Quota ist statisch. Ein Team mit großzügiger Quota kann trotzdem alles blockieren, wenn es die Quota ausnutzt.

Schicht 2 — PriorityClasses und Preemption.

• system-cluster-critical > production > development > batch.
• Bei Knappheit: niedrigere Priorität wird preempted. ML-Batch-Jobs bekommen batch-Priority — prod-APIs bleiben scheduled.
• Trade-off: Preemption ist brutal — Pods werden gekillt. Nur für klar getrennte Workload-Klassen.

Schicht 3 — Admission Rate Limiting (API-Server-Schutz).

• Ein Team, das 400 Deployments in einer Minute anlegt, flutet den API-Server — unabhängig von Node-Kapazität.
• Kyverno/Gatekeeper: Max Pods pro Minute pro Namespace (via Policy mit Audit → Enforce).
• Validating Webhook: Reject wenn count(pods in namespace) + new > threshold in rolling window.
• Alternative: ResourceQuota mit Object Count (pods, deployments) — einfacher, weniger granular.

Schicht 4 — Spezial-Ressourcen: GPU/Spot Pools.

• Dedizierte Node Pools mit Taints: workload=gpu:NoSchedule, workload=ml-batch:NoSchedule.
• Kueue / Volcano / YuniKorn für Batch-Scheduling: Jobs in Queue, Fair-Share-Algorithmus über Teams (DRF — Dominant Resource Fairness).
• Karpenter/Cluster Autoscaler: Max Nodes pro Pool — harte Obergrenze für ML-Burst.

Schicht 5 — Plattform-API Rate Limits (Self-Service).

• Backstage/Crossplane API: max N Environments pro Tag pro Team.
• GitOps: Argo CD Application Set mit Max-Parallelism pro AppProject.

Whiteboard-Reihenfolge: Quota (Kapazität) → Priority (Knappheit) → Rate Limit (Burst) → Queue (Batch) → Dedizierte Pools (Spezial-Hardware).

Einwände des Interviewers

„Quotas sind zu starr — Teams wachsen.” — Quota-Review quartalsweise + Self-Service-Antrag für Erhöhung mit automatischer Cost-Center-Prüfung. Start konservativ, erweitern mit Daten.

„Preemption killt ML-Jobs mitten in Training.” — Checkpointing ist Team-Verantwortung; Plattform liefert Priority + Spot-Pool. Training gehört auf Batch-Queue, nicht auf Shared-Prod-Nodes.

„50 Teams — wer pflegt 50 Quota-YAMLs?” — Tier-Modell: Small/Medium/Large Quota-Presets. Team bekommt Tier beim Onboarding, nicht individuelle Zahlen.

„Ist das nicht FinOps?” — Überlappt. Fairness ist kurzfristig (Scheduler), FinOps langfristig (Kosten). Showback-Daten helfen bei Quota-Debatten — verlinke beides.

Praxis

45 Minuten, Whiteboard. Diese fünf Punkte müssen vorkommen:

1. Noisy-Neighbor-Problem präzise benennen (GPU-Burst vs. API-Flood)
2. ResourceQuota + LimitRange als Baseline
3. PriorityClass/Preemption für prod vs. batch
4. Rate Limiting auf Admission-Ebene (Policy oder Webhook)
5. Dedizierter Pool + Queue für Batch/GPU (Kueue o.ä.)

Zusatzübung (10 Minuten): Namespace team-ml hat Quota 100 GPU, 80 belegt. Team will 400 Pods à 1 GPU schedulen. Was passiert mit und ohne Queue — skizziere beide Pfade.

Typische Stolperfallen

Nur Quota, kein Rate Limit. Team bleibt unter Quota, flutet aber API-Server — etcd latency steigt, ganzer Cluster leidet.

Preemption ohne Priority-Klassen-Kommunikation. Teams verstehen nicht, warum Pods verschwinden — Adoption bricht.

Globale Quota statt Tier-Presets. 50 individuelle YAMLs — unwartbar.

GPU-Problem mit CPU-Quota lösen. Ressourcen-Typ muss zur Maßnahme passen.

Interview-Vorbereitung

Kernbotschaft: „Fairness auf Shared Platforms ist mehrschichtig: Quotas für Kapazität, Priorities für Knappheit, Rate Limits für Burst, Queues für Batch — plus dedizierte Pools für Spezial-Hardware.”

Rechne mit diesen Follow-ups:

• „Kueue oder native Kubernetes?” — Kueue (CNCF) für Job-Queueing mit Fair-Share; native reicht für einfache Quota+Priority.
• „Wie zeigst du Teams ihre Auslastung?” — Grafana Dashboard pro Namespace: Quota used/limit, pending pods, preemption events.
• „Was machst du zuerst?” — ResourceQuota + LimitRange + GPU-Taint-Pool — 80 % des Schmerzes in einer Woche.

Zusammenfassung

Der Fairness-Case verlangt Schichten statt eines Silver Bullets: Quota begrenzt Reservierung, Priority regelt Knappheit, Rate Limits schützen den API-Server, Queues fair-sharen Batch — und Spezial-Hardware braucht eigene Pools. In der nächsten Lektion drehst du den Spieß um: Wie onboarded ein neues Team in 15 Minuten statt 15 Tagen?