Kubernetes Operator und CRD erklärt

Ein Kubernetes Operator ist ein Controller, der eigene Betriebsaufgaben automatisch übernimmt, indem er auf eine Custom Resource Definition (CRD) reagiert. Die CRD erweitert die Kubernetes-API um einen eigenen Objekttyp, den du danach genauso wie ein eingebautes Objekt mit kubectl anlegen und abfragen kannst. Der Operator beobachtet Instanzen dieses Typs und sorgt dafür, dass der Cluster immer dem entspricht, was darin beschrieben steht.

Ich betreibe Kubernetes-Cluster in Produktion und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024), mit einem eigenen Kapitel zu CRDs und Operatoren. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.

Was eine Custom Resource Definition ist und wozu sie dient

Ohne CRD kennt Kubernetes nur seine eingebauten Objekte: Pod, Deployment, Service und so weiter. Eine CRD meldet dem API-Server einen neuen Objekttyp an, samt Namen, Struktur und Validierungsregeln. Danach verhält sich dieser Typ wie jedes andere Kubernetes-Objekt: Du kannst ihn mit kubectl anlegen, ändern, löschen und mit kubectl get auflisten.

Du könntest dieselben Informationen auch in einer ConfigMap ablegen, verlierst dabei aber drei Dinge, die eine CRD dir schenkt: eine Schema-Validierung, die falsche Eingaben schon beim Anlegen zurückweist, eine eigene, sprechende API statt eines generischen Key-Value-Speichers, und die Möglichkeit, dass ein Controller gezielt auf Änderungen genau dieses Typs reagiert. Genau diese dritte Eigenschaft ist die Grundlage für den Operator, um den es gleich geht.

Ein Beispiel aus der Praxis, das du wahrscheinlich schon im Cluster hast, ohne es zu merken: Der Prometheus-Operator bringt eigene CRDs wie ServiceMonitor und PrometheusRule mit. Du legst ein ServiceMonitor-Objekt an, statt eine Prometheus-Konfiguration von Hand zu editieren, und der Operator übersetzt das im Hintergrund in die passende Scrape-Konfiguration. Mehr dazu in Kubernetes Monitoring mit Prometheus.

Vom Schema zur eigenen Custom Resource

Angenommen, du willst wiederkehrende Backups einzelner Anwendungen im Cluster deklarativ beschreiben, statt jedes Backup als eigenes Cron-Skript zu pflegen. Dafür legst du zuerst eine CRD an, die den Objekttyp BackupSchedule beschreibt:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backupschedules.ops.example.com
spec:
  group: ops.example.com
  names:
    kind: BackupSchedule
    plural: backupschedules
    singular: backupschedule
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                target:
                  type: string
                cronSchedule:
                  type: string
                retentionDays:
                  type: integer
              required: ["target", "cronSchedule"]

Das Feld group bestimmt, unter welcher API-Gruppe der neue Typ läuft, names.kind ist der Name im CamelCase, den du in eigenen Manifesten benutzt, names.plural brauchst du später für kubectl get backupschedules. Unter schema legst du fest, welche Felder eine Instanz haben darf und welchen Typ sie haben müssen. Sobald diese CRD im Cluster liegt, kannst du eine konkrete Instanz anlegen:

apiVersion: ops.example.com/v1
kind: BackupSchedule
metadata:
  name: shop-datenbank
spec:
  target: "shop-postgres"
  cronSchedule: "0 3 * * *"
  retentionDays: 14

Ohne einen Controller, der diese Custom Resource liest, passiert an dieser Stelle noch nichts. Kubernetes speichert das Objekt und lässt es dich abfragen, führt aber selbst keine Backups aus. Das übernimmt erst der Operator.

Validierung in der CRD: Schema und CEL-Regeln

Eine reine Typprüfung reicht selten aus. In diesem Beispiel willst du verhindern, dass jemand eine Aufbewahrungsfrist von null oder mehreren tausend Tagen einträgt, oder einen ungültigen Cron-Ausdruck. Neben Ober- und Untergrenzen für Zahlen unterstützt Kubernetes seit einigen Releases zusätzlich Regeln in der Common Expression Language (CEL), die im Schema unter x-kubernetes-validations stehen und Feldwerte gegeneinander prüfen können, etwa ob ein Enddatum nach einem Startdatum liegt.

Für das Feld retentionDays sieht eine einfache Grenzwertregel so aus:

retentionDays:
  type: integer
  minimum: 1
  maximum: 365

Damit weist der API-Server jede Custom Resource zurück, deren Aufbewahrungsfrist außerhalb dieses Bereichs liegt, noch bevor sie im Cluster gespeichert wird. Wer die CR anlegt, bekommt den Fehler sofort zurück, nicht erst wenn der Operator später daran scheitert. Details zu den Validierungsmöglichkeiten stehen in der Kubernetes-Dokumentation zu Custom Resources.

Was ein Kubernetes Operator ist: Controller und Reconciliation

Hier ist die Abgrenzung wichtig, die am häufigsten verwischt: Eine CRD allein ist noch kein Operator. Sie beschreibt nur den Objekttyp und dessen Regeln, sie tut nichts. Erst der Controller, der den gewünschten Zustand aus der Custom Resource mit dem tatsächlichen Zustand im Cluster abgleicht, macht aus einer CRD einen Operator. Beides zusammen, Objekttyp und abgleichender Controller, ergibt das Operator Pattern; fehlt der zweite Baustein, hast du eine gut validierte Datenablage im Cluster und sonst nichts.

Der Operator selbst ist kein Kubernetes-Objekt, sondern eine Anwendung, die im Cluster läuft und über die Kubernetes-API auf Änderungen an deiner Custom Resource lauscht. Sobald eine BackupSchedule angelegt, geändert oder gelöscht wird, tritt der Controller in Aktion und vergleicht den gewünschten Zustand aus der CR mit dem, was tatsächlich im Cluster existiert, hier zum Beispiel einen laufenden CronJob für das Backup.

Dieser Vergleich und das anschließende Angleichen heißt Reconciliation, dieselbe Schleife, die auch ein ReplicaSet nutzt, um die Anzahl laufender Pods nachzuregeln. Ein Operator wendet dieses Muster nur auf einen Bereich an, den du selbst definiert hast: Er legt bei Bedarf den CronJob an, aktualisiert ihn bei einer geänderten Aufbewahrungsfrist und entfernt ihn wieder, wenn die BackupSchedule gelöscht wird. Damit verschwindet die Logik, die sonst in einem separaten Skript oder einer manuellen Routine leben würde, komplett im Cluster selbst. Wie du einen eigenen Operator entwickelst, zeigt die Kubernetes-Dokumentation zum Operator Pattern.

Operator oder Helm? Wann du welches Werkzeug brauchst

Helm und Operatoren werden häufig verwechselt, weil beide mit Kubernetes-Anwendungen zu tun haben. Der Unterschied liegt im Zeitpunkt, zu dem sie aktiv werden.

Frage	Helm	Operator
Was es tut	rendert Templates und wendet sie einmalig an	überwacht den Zustand fortlaufend und regelt ihn nach
Wann es reicht	der Zustand bleibt nach dem Rollout stabil, bis zum nächsten Upgrade	der Zustand muss sich selbst reparieren, etwa nach einem Ausfall
Typisches Beispiel	ein Chart für eine zustandslose Webanwendung	ein Datenbank-Cluster mit automatischem Failover
Entwicklungsaufwand	Templates und Werte schreiben, kein eigener Code	ein eigener Controller, meist mit Kubebuilder oder dem Operator SDK

In der Praxis schließen sich beide nicht aus. Ein Operator wird häufig selbst über ein Helm Chart installiert, weil das Chart die Installation der CRD und des Controllers übernimmt, während der Operator danach die eigentliche Betriebslogik trägt. Mehr zu Helm selbst steht in Helm Charts erklärt: Pakete für Kubernetes.

Praxisbeispiel: der Postgres-Operator von Zalando

Ein Operator, der zeigt, wie viel Betriebsarbeit ein gutes CRD-Design abnehmen kann, ist der quelloffene Postgres-Operator von Zalando. Statt eine Postgres-Datenbank als StatefulSet von Hand zu betreiben und Skripte für Nutzeranlage, Rechteverwaltung und Failover selbst zu schreiben, beschreibst du mit einer Custom Resource nur noch die Anzahl der Instanzen, die gewünschten Datenbanken und Nutzer sowie die Postgres-Version. Der Controller des Operators übernimmt den Rest: Er legt die Instanzen an, verwaltet Zugriffsrechte und kümmert sich um den Failover, wenn eine Instanz ausfällt.

Genau das ist der Kern des Operator Patterns: Wiederkehrende, expertenlastige Betriebsaufgaben wandern aus dem Kopf einzelner Menschen in eine Custom Resource, die jeder im Team lesen und ändern kann, ohne die Details der Postgres-Administration zu kennen.

Häufige Fragen

Was ist eine Custom Resource Definition in Kubernetes?

Eine Custom Resource Definition erweitert die Kubernetes-API um einen eigenen Objekttyp mit eigenem Schema. Nach der Anmeldung verhält sich dieser Typ wie ein eingebautes Kubernetes-Objekt: Du legst Instanzen davon an, fragst sie mit kubectl ab und Kubernetes validiert sie gegen das Schema aus der CRD.

Was ist das Operator Pattern in Kubernetes?

Das Operator Pattern beschreibt einen Controller, der auf eine Custom Resource reagiert und den tatsächlichen Zustand des Clusters kontinuierlich an den gewünschten Zustand angleicht, den die Custom Resource beschreibt. Es überträgt damit menschliches Betriebswissen in automatisierten Code, der im Cluster läuft.

Brauche ich einen Operator oder reicht Helm?

Reicht ein einmaliges Ausrollen aus, das danach stabil bleibt, reicht Helm. Muss sich eine Anwendung selbst reparieren, etwa bei einem Datenbank-Failover oder einer nötigen Versionsmigration, brauchst du einen Operator, der kontinuierlich mitläuft, statt nur beim Rollout aktiv zu sein.

Kann ich eine CRD ohne eigenen Operator nutzen?

Ja. Eine CRD allein gibt dir schon eine validierte, eigene API und einen Speicherort im Cluster, ganz ohne Controller. Nützlich wird das aber erst richtig, sobald etwas auf Änderungen reagiert, sonst bleibt die Custom Resource nur ein aufwendig beschriebenes, aber wirkungsloses Objekt.

Wie du weitermachst

Wenn du CRDs im Cluster einsetzt, lohnt sich auch ein Blick darauf, wer sie anlegen darf: In Admission Controller und Policies steht, wie du zusätzliche Regeln für Objekte im Cluster durchsetzt, auch für eigene Custom Resources. Und wenn ein Operator wie der Prometheus-Operator schon Teil deines Monitorings ist, findest du den passenden Einstieg in Kubernetes Monitoring mit Prometheus.

Mein Vorschlag für den Einstieg: Schau dir mit kubectl get crd an, welche CRDs schon in deinem Cluster liegen, oft mehr, als du denkst, weil viele Werkzeuge sie im Hintergrund installieren. Das gibt dir ein Gefühl dafür, wie verbreitet das Muster längst ist.

Ausführlich mit allen Beispielen, von der Validierung bis zur Architektur eines eigenen Controllers, steht das in Kapitel 5 meines Kubernetes-Praxisbuchs bei Rheinwerk.