Custom Resource Definitions (CRDs) in Kubernetes ermöglichen es Benutzern, eigene Ressourcentypen zu definieren und die native API-Erweiterung zu nutzen, um diese neben Standardressourcen wie Pods, Services und Deployments zu verwalten. CRDs erweitern die Kubernetes-API, ohne dass ein eigener API-Server erforderlich ist.
Ein CRD ist ein API-Objekt, das ein Schema für eine benutzerdefinierte Ressource festlegt, einschließlich Felder und Datentypen. Nach der Installation im Kubernetes-Cluster können Benutzer Instanzen dieser Ressource ähnlich den Standardressourcen erstellen und verwalten.
Die Erstellung eines CRD beinhaltet:
kubectl apply -f.CRDs bieten:
CRDs erfordern ordnungsgemäße Verwaltung und Versionierung für Kompatibilität und Sicherheit. Es ist wesentlich, sich an die Kubernetes-Dokumentation und Best Practices zu halten, um eine resiliente und wartbare Implementierung zu sichern.
In der Regel dienen CRDs nur als Schema die von Controllern/Operator flankiert werden. Es gibt aber durchaus auch Anwendungsfälle in Kubernetes, bei denen Sie wirklich nur eine Custom Resource Definition (CRD) benötigen, ohne zusätzliche Programmierung eines Controllers oder Operators. Diese Anwendungsfälle sind typischerweise einfacher und dienen hauptsächlich dazu, Konfigurationsdaten zu speichern und abzufragen. Hier einige Beispiele:
Konfigurationsdaten speichern: Sie könnten eine CRD verwenden, um Konfigurationsdaten für Ihre Anwendungen zu speichern. Die CRD definiert das Format dieser Konfigurationsdaten, und die Anwendungen können die Daten direkt aus den Custom Resources abrufen.
Deklarative API-Erweiterung: Wenn Sie eine deklarative Schnittstelle benötigen, um bestimmte Informationen in Ihrem Cluster zu speichern und abzurufen, kann eine CRD nützlich sein. Beispielsweise könnten Sie eine CRD für die Speicherung von Umgebungsspezifischen Metadaten erstellen.
Gateway zu externen Ressourcen: Sie könnten eine CRD verwenden, um Informationen über externe Ressourcen zu speichern, wie Datenbanken oder Dienste, die außerhalb des Kubernetes-Clusters gehostet werden. In diesem Fall dient die CRD als eine Art Verzeichnis oder Gateway.
Einfache Status- oder Ereignisprotokollierung: Für grundlegende Protokollierungszwecke, wie das Erfassen von Statusinformationen oder Ereignissen in Ihrem Cluster, könnte eine CRD ausreichen. Hierbei dient die CRD als Speicher für diese Informationen.
In diesen Szenarien agiert die CRD als eine Art strukturiertes Speichermedium innerhalb des Kubernetes-Clusters. Die eigentliche “Logik” – wie die Daten verwendet werden, oder wie auf Änderungen reagiert wird – würde in den Anwendungen oder Diensten liegen, die diese Custom Resources nutzen. Zur Erinnerung: Solche CRDs bieten ohne zugehörige Controller oder Operatoren keine Automatisierung oder Verwaltungsfunktionen für die in ihnen gespeicherten Ressourcen.
Ein konkretes Beispiel wäre eine CRD, die dazu verwendet wird, Konfigurationsdaten ähnlich wie eine ConfigMap zu speichern, jedoch mit einer benutzerdefinierten Struktur. Dies könnte beispielsweise für die Speicherung von Anwendungs- oder Umgebungskonfigurationen genutzt werden.
Stellen Sie sich vor, Sie erstellen eine CRD namens
AppConfig, die spezifische Konfigurationsparameter für
verschiedene Anwendungen in Ihrem Cluster speichert.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: appconfigs.mycompany.com
spec:
group: mycompany.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: appconfigs
singular: appconfig
kind: AppConfigEin Beispiel für eine AppConfig-Ressource könnte wie folgt aussehen:
apiVersion: mycompany.com/v1
kind: AppConfig
metadata:
name: myapp-config
namespace: default
spec:
databaseUrl: "jdbc:mysql://example.com:3306/mydb"
featureFlags:
enableFeatureX: true
enableFeatureY: falseUm auf die in der AppConfig gespeicherten Daten
zuzugreifen, können Sie die Kubernetes API nutzen, ähnlich wie Sie es
mit einer ConfigMap tun würden. Sie können kubectl
verwenden, um die Daten abzufragen:
kubectl get appconfig myapp-config -o yamlDieser Befehl gibt die Konfigurationsdaten der AppConfig
namens myapp-config im YAML-Format aus.
In Ihrer Anwendung müssten Sie die Kubernetes-API ansprechen, um
diese Custom Resources zu lesen. Dies könnte durch den Kubernetes-Client
in Ihrer Programmiersprache erfolgen. Die Anwendung würde dann die
Konfigurationsdaten aus der AppConfig-Ressource abrufen und
entsprechend verwenden.
Der Hauptvorteil einer solchen CRD gegenüber einer ConfigMap liegt in der Möglichkeit, eine stärker strukturierte und spezifische API für Ihre Konfigurationsdaten zu definieren. Sie können genau festlegen, welche Datenfelder vorhanden sein müssen, und eventuell Validierungen oder Schemata definieren, was bei einer ConfigMap nicht möglich ist.
In diesem Beispiel dient die CRD hauptsächlich als strukturierter Datenspeicher innerhalb des Kubernetes-Clusters, ohne dass zusätzliche Automatisierung oder Managementlogik erforderlich ist.
Die Installation einer Custom Resource Definition (CRD) in einem
Kubernetes-Cluster erfolgt in der Regel durch das
kubectl apply-Kommando, welches das YAML-Manifest der CRD
auf den Cluster anwendet.
Hier sind die Schritte, um eine CRD zu installieren:
Erstellung des CRD-YAML-Manifests: Schreiben Sie das YAML-Manifest, das die CRD beschreibt, wie im vorherigen Beispiel gezeigt.
Anwendung der CRD auf den Cluster:
kubectl apply -f <crd-manifest.yaml> aus, wobei
<crd-manifest.yaml> der Dateipfad zur YAML-Datei der
CRD ist.kubectl apply -f crd.yamlDieser Befehl sendet das CRD-Manifest an den Kubernetes-API-Server, der die CRD verarbeitet und im etcd-Speicher des Clusters registriert.
Überprüfung der CRD-Installation:
kubectl get crd <name-of-crd>Ersetzen Sie <name-of-crd> mit dem Namen, den Sie
im Feld metadata.name Ihrer CRD definiert haben.
Erstellung von Instanzen der benutzerdefinierten Ressource:
kubectl apply anwenden.kubectl apply -f example-resource.yamlDurch diesen Prozess erweitert die CRD das Kubernetes-API-Schema und ermöglicht es dem Cluster, die neue Ressourcenart zu verwalten. Änderungen an der Definition einer CRD sollten mit Bedacht vorgenommen werden, insbesondere in Produktionsumgebungen, da sie bestehende Ressourcen beeinflussen können.