Einführung
Kubernetes lässt sich durch neue Ressourcentypen erweitern. Eine CustomResourceDefinition, kurz CRD, registriert eine neue API-Ressource beim Kubernetes API-Server. Sobald dies geschehen ist, können Sie die gewohnten kubectl-Befehle verwenden, um Objekte dieses neuen Typs zu erstellen, abzurufen, zu beschreiben, zu labeln und zu patchen.
In diesem Lab erstellen Sie eine kleine, namensraumgebundene (namespaced) CRD namens AppProfile, entdecken diese mithilfe von Kubernetes API-Discovery-Befehlen, erstellen benutzerdefinierte Ressourcen aus YAML-Dateien und aktualisieren diese wie reguläre Kubernetes-Objekte. Für dieses Lab ist kein Controller erforderlich; der Fokus liegt darauf zu verstehen, wie benutzerdefinierte Ressourcentypen erscheinen und wie man mit deren Objekten arbeitet.
Einen Namensraum für benutzerdefinierte Ressourcen vorbereiten
In diesem Schritt bereiten Sie einen sauberen Namensraum für die Arbeit mit benutzerdefinierten Ressourcen vor.
Beginnen Sie im Verzeichnis /home/labex/project. Sie werden die CRD- und Custom-Resource-Manifeste in diesem Verzeichnis erstellen.
mkdir -p /home/labex/project
cd /home/labex/project
Überprüfen Sie, ob der Kubernetes API-Server erreichbar ist. Falls die VM gerade erst gestartet wurde und der Knoten noch nicht bereit ist, warten Sie einige Sekunden und führen Sie den Befehl erneut aus.
kubectl get nodes --request-timeout=5s
Die erwartete Ausgabe sieht in etwa so aus:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Warten Sie, bis der Cluster-Networking-Pod bereit ist, bevor Sie Anwendungsobjekte erstellen.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Erwartete Ausgabe:
pod/calico-node-... condition met
Erstellen Sie einen Namensraum namens ckad-prep-customresources:
kubectl create namespace ckad-prep-customresources
Setzen Sie diesen Namensraum als aktuellen Kontext-Namensraum:
kubectl config set-context --current --namespace=ckad-prep-customresources
Bestätigen Sie den aktuellen Namensraum:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Erwartete Ausgabe:
ckad-prep-customresources
Einen neuen Ressourcentyp mit einer CRD registrieren
In diesem Schritt erstellen Sie eine CustomResourceDefinition namens AppProfile.
Eine CRD hat zwei wichtige Namensebenen. Der metadata.name ist der Pluralname der Ressource plus die API-Gruppe, wie zum Beispiel appprofiles.training.labex.io. Der Abschnitt spec.names definiert, wie Benutzer auf die Ressource verweisen: kind: AppProfile, plural: appprofiles, singular: appprofile und ein Kurzname appprof.
Erstellen Sie die Datei app-profile-crd.yaml:
cat > app-profile-crd.yaml <<'EOF'
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: appprofiles.training.labex.io
spec:
group: training.labex.io
scope: Namespaced
names:
plural: appprofiles
singular: appprofile
kind: AppProfile
shortNames:
- appprof
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required:
- image
- replicas
properties:
image:
type: string
replicas:
type: integer
minimum: 1
tier:
type: string
EOF
Wenden Sie die CRD an:
kubectl apply -f app-profile-crd.yaml
Erwartete Ausgabe:
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io created
Warten Sie, bis der API-Server meldet, dass die CRD etabliert ist:
kubectl wait --for=condition=Established crd/appprofiles.training.labex.io --timeout=120s
Erwartete Ausgabe:
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io condition met
Überprüfen Sie die Namen und den Geltungsbereich (Scope) der CRD:
kubectl get crd appprofiles.training.labex.io -o 'jsonpath={.spec.names.kind}{" "}{.spec.names.plural}{" "}{.spec.scope}{"\n"}'
Erwartete Ausgabe:
AppProfile appprofiles Namespaced
Benutzerdefinierte Ressourcen entdecken und erstellen
In diesem Schritt entdecken Sie den neuen Ressourcentyp und erstellen Ihr erstes AppProfile.
kubectl api-resources listet die dem API-Server bekannten Ressourcentypen auf. Sobald eine CRD etabliert ist, erscheint sie in dieser Discovery-Ausgabe neben den integrierten Ressourcentypen.
kubectl api-resources --api-group=training.labex.io
Die erwartete Ausgabe enthält:
NAME SHORTNAMES APIVERSION NAMESPACED KIND
appprofiles appprof training.labex.io/v1 true AppProfile
Verwenden Sie kubectl explain, um das Schema zu lesen, das Kubernetes aus der CRD gelernt hat. Das Feld spec enthält die anwendungsspezifischen Einstellungen.
kubectl explain appprofile.spec
Die erwartete Ausgabe enthält:
GROUP: training.labex.io
KIND: AppProfile
VERSION: v1
FIELD: spec <Object>
Erstellen Sie die Datei frontend-profile.yaml:
cat > frontend-profile.yaml <<'EOF'
apiVersion: training.labex.io/v1
kind: AppProfile
metadata:
name: frontend
labels:
app.kubernetes.io/part-of: storefront
tier: web
spec:
image: nginx:1.27
replicas: 2
tier: web
EOF
Wenden Sie die benutzerdefinierte Ressource an:
kubectl apply -f frontend-profile.yaml
Erwartete Ausgabe:
appprofile.training.labex.io/frontend created
Listen Sie die benutzerdefinierten Ressourcen mit dem Pluralnamen auf:
kubectl get appprofiles
Die erwartete Ausgabe enthält:
NAME AGE
frontend ...
Lesen Sie Felder aus der benutzerdefinierten Ressource mit jsonpath:
kubectl get appprofile frontend -o 'jsonpath={.spec.image}{" "}{.spec.replicas}{" "}{.spec.tier}{"\n"}'
Erwartete Ausgabe:
nginx:1.27 2 web
Benutzerdefinierte Ressourcen aktualisieren und auswählen
In diesem Schritt verwalten Sie benutzerdefinierte Ressourcen mit denselben kubectl-Mustern, die Sie bereits für integrierte Objekte verwenden.
Patchen Sie die frontend-Ressource, um die gewünschte Anzahl an Replikaten zu ändern. Die Option --type=merge weist Kubernetes an, Ihr JSON-Objekt in das bestehende Objekt zu integrieren, anstatt die gesamte Ressource zu ersetzen.
kubectl patch appprofile frontend --type=merge -p '{"spec":{"replicas":3}}'
Erwartete Ausgabe:
appprofile.training.labex.io/frontend patched
Bestätigen Sie den aktualisierten Wert:
kubectl get appprofile frontend -o 'jsonpath={.spec.replicas}{"\n"}'
Erwartete Ausgabe:
3
Erstellen Sie eine zweite benutzerdefinierte Ressource namens worker:
cat > worker-profile.yaml <<'EOF'
apiVersion: training.labex.io/v1
kind: AppProfile
metadata:
name: worker
labels:
app.kubernetes.io/part-of: storefront
tier: worker
spec:
image: busybox:1.36
replicas: 1
tier: worker
EOF
kubectl apply -f worker-profile.yaml
Erwartete Ausgabe:
appprofile.training.labex.io/worker created
Listen Sie nur die benutzerdefinierten Ressourcen auf, die zur storefront-Anwendung gehören. Dies funktioniert, da benutzerdefinierte Ressourcen normale Kubernetes-Labels unterstützen.
kubectl get appprofiles -l app.kubernetes.io/part-of=storefront
Die erwartete Ausgabe enthält:
NAME AGE
frontend ...
worker ...
Verwenden Sie den Kurznamen appprof, um den Namen und die Replikate jeder Ressource auszugeben:
kubectl get appprof -o 'jsonpath={range .items[*]}{.metadata.name}{"="}{.spec.replicas}{"\n"}{end}'
Die erwartete Ausgabe enthält:
frontend=3
worker=1
Zusammenfassung
Sie haben eine CRD erstellt, gewartet, bis sie etabliert war, die neue API-Ressource mit kubectl api-resources und kubectl explain entdeckt, benutzerdefinierte Ressourcen erstellt, eine benutzerdefinierte Ressource gepatcht, diese nach Labels gefiltert und einen Kurznamen verwendet. Dies sind dieselben operativen Fähigkeiten, die Sie benötigen, wenn CKAD-Aufgaben Ressourcen betreffen, die von einem Operator, Controller oder einer Plattform-Erweiterung installiert wurden.
