Was ist das Kubernetes Resource Model?
Wer Kubernetes betreibt, arbeitet täglich mit dem Kubernetes Resource Model (KRM) – oft ohne es beim Namen zu nennen. KRM ist das fundamentale Paradigma hinter Kubernetes: alles, was im Cluster existiert, ist eine deklarative Ressource – beschrieben in YAML oder JSON, gespeichert im API-Server, kontrolliert durch Controller.
Das klingt zunächst abstrakt, hat aber weitreichende Konsequenzen: für die Art, wie man mit Kubernetes arbeitet, wie man es erweitert, und warum GitOps damit so gut funktioniert.
Die Grundstruktur einer KRM-Ressource
Jede Kubernetes-Ressource – egal ob built-in oder custom – folgt demselben Schema:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: production
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:1.2.3Vier Felder sind immer vorhanden:
- –apiVersion: Gruppenname und Version (z.B.
apps/v1,v1,batch/v1) - –kind: Der Ressourcentyp (Deployment, Service, ConfigMap, ...)
- –metadata: Name, Namespace, Labels, Annotations
- –spec: Der gewünschte Zustand – das Herzstück der Ressource
Dazu kommt status, das vom Controller befüllt wird und den aktuellen Ist-Zustand beschreibt. Dieser Bereich wird nie manuell gesetzt.
Die Reconciliation Loop: Das entscheidende Muster
Der Mechanismus, der KRM zum Leben erweckt, ist die Reconciliation Loop. Jeder Kubernetes-Controller arbeitet nach demselben Prinzip:
1. Beobachte den Ist-Zustand der Ressource (Status)
2. Vergleiche ihn mit dem Soll-Zustand (Spec)
3. Führe Aktionen aus, um den Ist-Zustand an den Soll-Zustand anzupassen
4. Wiederhole kontinuierlich
Daraus ergeben sich zwei wichtige Eigenschaften:
Idempotenz: kubectl apply kann beliebig oft ausgeführt werden – das Ergebnis ist immer der deklarierte Zustand. Das macht Deployments sicher und wiederholbar.
Selbstheilung: Wenn ein Pod abstürzt oder ein Node ausfällt, erkennt der Controller die Abweichung und reagiert ohne manuellen Eingriff.
Der API-Server als zentrale Wahrheitsquelle
Alle Ressourcen leben im etcd-Cluster hinter dem API-Server. Der API-Server ist dabei mehr als ein Datenspeicher: er validiert Ressourcen gegen ihr Schema, führt Admission-Webhooks aus und benachrichtigt Controller über Änderungen via Watch-Mechanismus.
Das hat eine wichtige Konsequenz: Der API-Server ist die Single Source of Truth. Nicht die Festplatte eines Nodes, nicht ein lokales YAML-File – sondern der API-Server. Was dort steht, gilt.
Custom Resource Definitions (CRDs)
Das KRM ist erweiterbar. Mit Custom Resource Definitions (CRDs) können eigene Ressourcentypen definiert werden, die sich wie native Kubernetes-Objekte verhalten:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: databases.mycompany.io
spec:
group: mycompany.io
versions:
- name: v1alpha1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
engine:
type: string
enum: [postgres, mysql]
version:
type: string
scope: Namespaced
names:
plural: databases
singular: database
kind: DatabaseSobald diese CRD installiert ist, kann man Ressourcen vom Typ Database anlegen – und ein eigener Controller (Operator) implementiert die Reconciliation-Logik dafür.
Operators: KRM in der Praxis
Das Operator-Pattern nutzt CRDs und eigene Controller, um komplexe, zustandsbehaftete Anwendungen zu managen. Bekannte Beispiele: Prometheus Operator, Strimzi (Kafka), Zalando Postgres Operator.
Die Idee dahinter: Das Betriebswissen für eine Anwendung – wie man sie installiert, skaliert, upgraded, ein Backup einspielt – wird in einen Controller kodiert, der nach dem KRM-Muster arbeitet. Das Ergebnis: Infrastruktur als Code auf einem höheren Abstraktionslevel.
KRM und GitOps
Die Stärke des KRM liegt in seiner natürlichen Eignung für GitOps: Da der gewünschte Zustand vollständig als deklarative Ressourcen beschreibbar ist, lässt er sich direkt in Git verwalten.
Tools wie Flux und Argo CD nutzen genau das: Sie beobachten ein Git-Repository und gleichen den Cluster-Zustand kontinuierlich mit dem Repository ab – nach demselben Reconciliation-Prinzip, nur auf einer höheren Ebene.
Praktischer Nutzen:
- –Vollständige Änderungshistorie über Git
- –Pull-Request-basierte Reviews für Infrastrukturänderungen
- –Automatisches Rollback durch Revert im Repository
- –Klare Trennung zwischen Quellcode und Deployment-Zustand
KRM-Funktionen: Transformation von Manifesten
Ein weniger bekannter Aspekt von KRM ist das Konzept der KRM-Funktionen – definiert im Rahmen von Projekten wie kpt. Eine KRM-Funktion ist ein Container, der eine Liste von Ressourcen als Input nimmt, sie transformiert oder validiert, und das Ergebnis zurückgibt.
Das ermöglicht eine pipeline-artige Verarbeitung von Kubernetes-Manifesten vor dem Deployment: Schema-Validierung, Injektion von Labels, Generierung von Ressourcen aus Templates, Sicherheitschecks.
Was das für den Alltag bedeutet
Das KRM ist kein akademisches Konzept – es hat direkte Auswirkungen auf die tägliche Arbeit:
- –Helm und Kustomize erzeugen am Ende KRM-konforme Manifeste. Wer das Modell versteht, debuggt einfacher.
- –RBAC in Kubernetes ist selbst als KRM-Ressource abgebildet (Role, ClusterRole, RoleBinding).
- –Netzwerkrichtlinien, PodDisruptionBudgets, HorizontalPodAutoscalers – alles KRM-Ressourcen, alle nach demselben Muster.
- –Wer einen eigenen Operator schreiben will, muss die Reconciliation Loop und das Status-Spec-Muster verstanden haben.
Fazit
Das Kubernetes Resource Model ist das konzeptionelle Fundament von Kubernetes. Wer es verinnerlicht hat – die deklarative Natur, die Reconciliation Loop, die Erweiterbarkeit über CRDs – versteht warum Kubernetes so funktioniert wie es funktioniert, und kann effizienter damit arbeiten.
Für Teams, die Kubernetes produktiv betreiben, lohnt es sich, dieses Fundament explizit zu machen: in Onboarding-Materialien, in Architecture Decision Records, in Code Reviews von Manifesten.
Bei Fragen zu Kubernetes-Architektur oder Operator-Entwicklung – schreiben Sie mir.