Auf einen Blick: Kubernetes Custom Resource Definitions (CRDs) ermöglichen es Nutzern, benutzerdefinierte API-Objekte zu erstellen und so die Funktionalität von Kubernetes zu verbessern. Dieser Leitfaden beschreibt die Erstellung, Verwaltung und Nutzung von CRDs.
- CRDs definieren benutzerdefinierte Ressourcen innerhalb von Kubernetes.
- Die Erstellung eines CRD erfordert die Angabe seiner Metadaten, Version und des Geltungsbereichs.
- Benutzerdefinierte Controller können für einen deklarativen Ansatz hinzugefügt werden.
In diesem Beitrag werden wir über benutzerdefinierte Ressourcendefinitionen (CRDs) sprechen. Wir werden folgendes besprechen:
- Was CRDs sind
- Wie sie verwendet werden
- Wie man sie erstellt
- Ein paar Tipps und Tricks
Um es zu verstehen: Ich nehme an, du hast Vorkenntnisse in Kubernetes, kubectl und hast Minikube laufen.
CRD-Konzepte in K8S
Um zu verstehen, was CRD ist, müssen wir ein paar Konzepte in Kubernetes durchgehen:
- Eine Ressource ist ein Endpunkt in der k8s-API, der es ermöglicht, ein API-Objekt jeglicher Art zu speichern.
- Eine benutzerdefinierte Ressource ermöglicht es dir, eigene API-Objekte zu erstellen und deine eigene Art zu definieren, wie Pod, Deployment, ReplicaSet usw.
Custom Resource ermöglicht es Ihnen, die Kubernetes-Funktionalität zu erweitern, indem Sie jede Art von API-Objekt hinzufügen, das für Ihre Anwendung nützlich ist. Custom Resource Definition ist das, womit Sie eine benutzerdefinierte Ressource definieren. Dies ist eine leistungsstarke Möglichkeit, Kubernetes-Fähigkeiten über die Standardinstallation hinaus zu erweitern.
Wie man ein CRD erstellt
Das untenstehende Manifest zeigt ein Beispiel für CRD crd.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: appconfigs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: appconfigs
singular: appconfig
kind: AppConfig
shortNames:
- ac
Lassen Sie uns erklären, was die obige CRD erzeugen wird:
- Die ersten beiden Zeilen definieren, was die API-Version ist, und wir sagen, wir wollen eine benutzerdefinierte Ressourcendefinition erstellen.
- Das Metadatenfeld hilft uns, den Namen der Ressource zu definieren. In unserem Fall appconfigs (Plural).
- Die Spec-Gruppe hilft uns, den Gruppennamen zu definieren.
- Die Spec-Version hilft uns, die Version zu definieren. Wir sagen, es ist v1, und wir wollen, dass diese Version unsere Speicherversion ist.
- Wie Sie sehen, können wir eine Version unseres CRD definieren, und nur eine Version kann gleichzeitig eine Speicherversion sein, also behalten Sie das im Hinterkopf. Wir haben dann sichergestellt, dass dieses CRD namespaced und nicht clusterweit ist. Das ermöglicht es uns, die CRD entweder nur für einen bestimmten Namespace oder für den gesamten Cluster zu erstellen.
- Als Nächstes haben wir definiert, wie der Singular- und Pluralname unseres CRD aussehen wird.
- Schließlich haben wir den Kindnamen und den Kurznamen definiert. Anschließend können wir ihn mit "kubectl create -f crd.yaml" erstellen. Der neue namespaced RESTful API-Endpunkt für unsere CRD findet sich unter /apis/stable.example.com/v1/namespaces/*/appconfigs/
Wir fragen uns wahrscheinlich, okay, das ist gut, aber wie ist das nützlich? Um die oben genannte CRD zu verwenden, erstellen wir ein Manifest mit der Art, die wir mit der CRD erstellt haben. Zum Beispiel haben wir my-kind.yaml
apiVersion: "stable.example.com/v1"
kind: AppConfig
metadata:
name: demo-appconfig
spec:
uri: "some uri"
Command: "some command"
image: my-image
Wie Sie sehen können, verwenden wir die Art, die wir in unserem CRD definiert haben, dann haben wir die Felder definiert, die unser Kind-Objekt haben sollen. Hier wollen wir den URI, Befehl und das Bild für unsere App definieren. Wenn wir nun "kubectl create -f my-kind.yaml" ausführen, kann unsere Anwendung die Daten konsumieren, die wir mit dem oben genannten Manifest erstellt haben. Um zu sehen, was passiert, können wir "kubectl get ac -o yaml" ausführen, wir sehen detaillierte Informationen zu dem, was wir gerade erstellt haben. Beachten Sie, wie wir den Kurznamen (ac) verwenden, den wir in unserem CRD definiert haben.
Wie man eine CRD löscht
Um das CRD und die von uns erstellten Ressourcen zu löschen, führt man einfach kubectl delete aus, genau wie bei anderen Ressourcen. Es ist wichtig zu wissen, dass die oben genannte CRD nur Daten sind, die gespeichert und abgerufen werden können, daher bietet sie uns keine vollständig deklarative API. Der Weg, diese Ressource vollständig deklarativ zu machen, besteht darin, einen benutzerdefinierten Controller hinzuzufügen, dessen Aufgabe es ist, sicherzustellen, dass der aktuelle Zustand und der gewünschte Zustand immer synchron sind. Ein Beispiel ist etwas wie ein Replikationscontroller.
CRDs erweitern Kubernetes
CRD ist eine Möglichkeit, Kubernetes zu erweitern, sodass wir eine benutzerdefinierte Ressource unserer Wahl erstellen und diese mit Hilfe eines eigenen Controllers deklarativ machen können.
Zusätzliche Ressourcen
Für mehr Informationen zu Kubernetes entdecken Sie diese Ressourcen:
Kubernetes-Leitfaden
- Was ist Kubernetes (K8s)? Ein Tutorial zu den Grundlagen von Kubernetes
- Kubernetes Best Practices für verbesserte Cluster-Effizienz
- Best Practices: Wie man Anwendungen für Kubernetes architekt
- Kubernetes Pods: Eine Einführung
- Kubernetes ReplicaSets: Eine kurze Einführung
- Kubernetes-Deployments vollständig erklärt
- Wie man Kubernetes DaemonSets verwendet und verwaltet
- Wie Kubernetes-Dienste funktionieren
- Verwendung von Kubernetes Port, TargetPort und NodePort
- Erstellen und verwenden von ConfigMaps in Kubernetes
- Einführung in Kubernetes-Geheimnisse
- Kubernetes-Netzwerkgrundlagen
- Kubernetes-Ingress erklärt
- Einführung in Kubernetes Helm Charts
- Was ist das Kubernetes-Operator-Muster?
- Bereitstellung von PostgreSQL als StatefulSet in Kubernetes
- Kubernetes Custom Resource Definition (CRDs) erklärt
- 3 Kubernetes-Muster für Cloud-native Anwendungen
- Kubernetes Compute-Ressourcen erklärt
- Kubernetes-Sicherheit für DevOps-Pipelines
- Verwendung von Spinnaker mit Kubernetes für Continuous Delivery
- Kubernetes-Multi-Cluster: Wie und warum man sie verwendet.
- Kubernetes-Überwachung: Ein umfassender Leitfaden
- Kubernetes vs. Docker: Ein kurzer Vergleich
- Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
- Kubernetes vs. OpenShift: Was ist der Unterschied?
- Kubernetes-Zertifizierungen: Wie und warum man zertifiziert wird
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.