Eine Custom Resource (benutzerdefinierte Ressource) ist ein Objekt, das die Kubernetes-API um eigene Typen erweitert. Damit lassen sich fachliche Dinge direkt in Kubernetes abbilden – etwa eine Datenbank, ein Monitoring-Ziel oder ein Zertifikat – statt sie nur lose in Skripten zu verwalten.

Definition und Instanz

Zwei Begriffe gehören zusammen: Die Custom Resource Definition (CRD) legt den Typ fest – vergleichbar mit einer Schablone. Die Custom Resource selbst ist die konkrete Instanz: Wie ein einzelnes Buch, das nach der Vorlage „Buch“ entsteht. Ohne CRD kann keine Custom Resource angelegt werden.

So sieht eine Custom Resource aus

Eine Custom Resource ist eine normale YAML-Datei mit apiVersion, kind und metadata. Im spec steht der gewünschte Zustand, den der zuständige Controller auswertet:

apiVersion: monitoring.example.com/v1
kind: Prometheus
metadata:
  name: produktion
spec:
  replicas: 2
  retention: 14d

Den status schreibt der Controller – zum Beispiel Kubernetes Operator – zurück, damit der Ist-Zustand sichtbar wird.

Wie native Objekte

Custom Resources verhalten sich wie eingebaute Objekte: Sie erscheinen in kubectl, unterliegen RBAC-Regeln, lassen sich mit Labels und Selectoren auswählen und können von Wächtern beobachtet werden. Meist leben sie in einem Namespace und werden über den kube-apiserver gespeichert.