Eine Custom Resource Definition (CRD) ist die offizielle Möglichkeit, die Kubernetes-API um neue Objekttypen zu erweitern. Sobald eine CRD angelegt ist, stellt der API-Server einen neuen REST-Endpunkt bereit, über den sich die passenden Custom Resources anlegen und abfragen lassen.
Aufbau einer CRD
Eine CRD wird selbst als YAML-Manifest über die API-Gruppe apiextensions.k8s.io/v1 definiert (stabil seit Kubernetes 1.16). Der Name folgt dem Schema plural.gruppe, etwa prometheuses.monitoring.coreos.com. Wichtige Felder:
- group: die API-Gruppe, z. B.
monitoring.coreos.com - scope:
NamespacedoderCluster– entscheidet, ob die Instanzen pro Namespace oder clusterweit leben - names: Plural, Singular,
kindund optionale Kurznamen - versions: Versionsliste, z. B.
v1mitservedundstorage - openAPIV3Schema: legt die erlaubten Felder fest und validiert jede Instanz
Was der API-Server daraus macht
Für jede Version der CRD erzeugt der kube-apiserver einen eigenen REST-Pfad. Optional lassen sich Subressourcen aktivieren: status für den vom Controller geschriebenen Ist-Zustand und scale für die Anbindung an die automatische Skalierung. Wer sehr spezielle Validierung oder eigene Authentifizierung braucht, kann statt einer CRD auch den API-Aggregations-Layer nutzen – für die meisten Fälle ist die CRD aber der einfachere Weg.
Die eigentliche Arbeit mit den neuen Ressourcen übernimmt meist ein Kubernetes Operator, der CRDs und Instanzen überwacht. Zugriffsrechte steuert Kubernetes RBAC.