Kubernetes5. April 2025Michael Hettwer9 min read

Kubernetes Resource Model (KRM): Praxisleitfaden für strukturierte Deployments

Warum KRM mehr ist als YAML: ein konsistentes Modell für Ressourcen, Policies und Automatisierung — mit klaren Mustern für Teams, die Kubernetes sauber betreiben wollen.

Kubernetes ist längst mehr als ein Scheduler. In der Praxis scheitern Teams jedoch oft nicht an Kubernetes selbst, sondern an inkonsistenten Resource-Definitionen, unklaren Ownership-Regeln und fehlender Wiederholbarkeit. Genau hier setzt das Kubernetes Resource Model (KRM) an: ein sauberes, deklaratives Modell für Ressourcen, das GitOps, Policies und Automatisierung auf eine belastbare Grundlage stellt.

Was ist KRM?

KRM beschreibt die Art und Weise, wie Kubernetes-Ressourcen definiert, validiert und über Lebenszyklen hinweg verwaltet werden. Im Kern geht es um strukturierte API-Objekte, klare Schemas und die Möglichkeit, Regeln über Ressourcen hinweg konsistent anzuwenden. KRM ist kein einzelnes Tool, sondern ein Modell, das mit Standard-Kubernetes-APIs, CRDs und Policy-Engines zusammenarbeitet.

Warum KRM Teams Zeit spart

Weniger Drift: Ressourcen werden deklarativ und reproduzierbar aus Git ausgerollt
Bessere Governance: Policies validieren Ressourcen vor dem Merge oder beim Apply
Klare Ownership: Namespaces, Labels und Konventionen machen Verantwortlichkeiten sichtbar
Skalierbare Automatisierung: Tools wie Kustomize und Config Sync nutzen das gleiche Modell

Ein minimales KRM-Grundmuster

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: prod
  labels:
    app: api
    team: platform
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.8.2
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Das Beispiel wirkt banal, zeigt aber die zentrale Idee: klare Metadaten, eindeutige Labels und explizite Ressourcen. In KRM denken Sie Ressourcen als API-Objekte mit definiertem Verhalten, nicht als lose YAML-Snippets.

Policies als Guardrails

KRM wird erst wirklich mächtig, wenn Policies systematisch durchgesetzt werden. Ob mit Kyverno, OPA/Gatekeeper oder native ValidatingAdmissionPolicies: Sie definieren Regeln wie "jedes Deployment braucht Limits" oder "nur genehmigte Registries". Das Ergebnis ist weniger unkontrollierter Wildwuchs und mehr Verlässlichkeit.

KRM + GitOps: ein stabiler Betriebsmodus

GitOps-Workflows funktionieren besonders gut, wenn Ressourcen konsistent modelliert sind. KRM liefert die Struktur, GitOps liefert den Prozess. Gemeinsam entsteht ein Betriebsmodus, in dem Änderungen nachvollziehbar, überprüfbar und rollbacksicher sind.

Tipp:

Starten Sie klein: definieren Sie Labels, Namespaces und Ressourcen-Limits als nicht verhandelbare Standards. Ergänzen Sie dann Policies, die diese Regeln durchsetzen. Die meisten Teams sehen bereits nach zwei Wochen deutlich weniger Incidents durch fehlerhafte Deployments.

Praktische nächsten Schritte

Definieren Sie ein verbindliches Label-Schema (app, team, env, owner)
Führen Sie Ressourcen-Requests und -Limits für alle Deployments ein
Setzen Sie eine Policy-Engine ein und starten Sie mit 2–3 harten Regeln
Organisieren Sie Repos nach Umgebungen (dev/staging/prod) mit klaren Ordnerstrukturen
Nutzen Sie Kustomize oder Helm, aber halten Sie die resultierenden Objekte KRM-konform

KRM ist nicht "mehr Bürokratie", sondern ein stabiler Rahmen, der Komplexität reduziert. Wer Kubernetes im Maßstab betreibt, profitiert massiv von einem konsistenten Ressourcenmodell — unabhängig davon, welche Tools darüber laufen.

Wie KI die Linux-Server-Administration transformiert