Introducción
Kubernetes puede extenderse con nuevos tipos de recursos. Una definición de recurso personalizado (CustomResourceDefinition), conocida habitualmente como CRD, registra un nuevo recurso de API en el servidor de API de Kubernetes. Una vez hecho esto, puede utilizar los comandos habituales de kubectl para crear, obtener, describir, etiquetar y aplicar parches a objetos de ese nuevo tipo.
En este laboratorio, creará un pequeño CRD con ámbito de espacio de nombres llamado AppProfile, lo descubrirá mediante comandos de descubrimiento de la API de Kubernetes, creará recursos personalizados a partir de YAML y los actualizará como si fueran objetos normales de Kubernetes. No se necesita ningún controlador para este laboratorio; el objetivo es comprender cómo aparecen los tipos de recursos personalizados y cómo trabajar con sus objetos.
Preparar un espacio de nombres para recursos personalizados
En este paso, preparará un espacio de nombres limpio para practicar con recursos personalizados.
Comience en /home/labex/project. Escribirá el CRD y los manifiestos de los recursos personalizados en este directorio.
mkdir -p /home/labex/project
cd /home/labex/project
Compruebe que el servidor de API de Kubernetes sea accesible. Si la máquina virtual acaba de iniciarse y el nodo aún no está listo, espere unos segundos y vuelva a ejecutar el comando.
kubectl get nodes --request-timeout=5s
La salida esperada incluye:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Espere a que el Pod de red del clúster esté listo antes de crear objetos de aplicación.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Salida esperada:
pod/calico-node-... condition met
Cree un espacio de nombres llamado ckad-prep-customresources:
kubectl create namespace ckad-prep-customresources
Establezca este espacio de nombres como el espacio de nombres del contexto actual:
kubectl config set-context --current --namespace=ckad-prep-customresources
Confirme el espacio de nombres actual:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Salida esperada:
ckad-prep-customresources
Registrar un nuevo tipo de recurso con un CRD
En este paso, creará una definición de recurso personalizado (CRD) llamada AppProfile.
Un CRD tiene dos capas de nomenclatura importantes. El metadata.name es el nombre del recurso en plural más el grupo de la API, como appprofiles.training.labex.io. La sección spec.names define cómo se referirán las personas al recurso: kind: AppProfile, plural: appprofiles, singular: appprofile y un nombre corto appprof.
Cree 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
Aplique el CRD:
kubectl apply -f app-profile-crd.yaml
Salida esperada:
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io created
Espere hasta que el servidor de API informe que el CRD está establecido:
kubectl wait --for=condition=Established crd/appprofiles.training.labex.io --timeout=120s
Salida esperada:
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io condition met
Inspeccione los nombres y el ámbito del CRD:
kubectl get crd appprofiles.training.labex.io -o 'jsonpath={.spec.names.kind}{" "}{.spec.names.plural}{" "}{.spec.scope}{"\n"}'
Salida esperada:
AppProfile appprofiles Namespaced
Descubrir y crear recursos personalizados
En este paso, descubrirá el nuevo tipo de recurso y creará su primer AppProfile.
kubectl api-resources enumera los tipos de recursos conocidos por el servidor de API. Una vez que se establece un CRD, aparece en esta salida de descubrimiento junto a los tipos de recursos integrados.
kubectl api-resources --api-group=training.labex.io
La salida esperada incluye:
NAME SHORTNAMES APIVERSION NAMESPACED KIND
appprofiles appprof training.labex.io/v1 true AppProfile
Utilice kubectl explain para leer el esquema que Kubernetes aprendió del CRD. El campo spec es donde residen los ajustes específicos de la aplicación.
kubectl explain appprofile.spec
La salida esperada incluye:
GROUP: training.labex.io
KIND: AppProfile
VERSION: v1
FIELD: spec <Object>
Cree 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
Aplique el recurso personalizado:
kubectl apply -f frontend-profile.yaml
Salida esperada:
appprofile.training.labex.io/frontend created
Enumere los recursos personalizados con el nombre en plural:
kubectl get appprofiles
La salida esperada incluye:
NAME AGE
frontend ...
Lea los campos del recurso personalizado con jsonpath:
kubectl get appprofile frontend -o 'jsonpath={.spec.image}{" "}{.spec.replicas}{" "}{.spec.tier}{"\n"}'
Salida esperada:
nginx:1.27 2 web
Actualizar y seleccionar recursos personalizados
En este paso, gestionará recursos personalizados con los mismos patrones de kubectl que ya utiliza para los objetos integrados.
Aplique un parche al recurso personalizado frontend para cambiar su número deseado de réplicas. La opción --type=merge le indica a Kubernetes que combine su objeto JSON con el objeto existente en lugar de reemplazar todo el recurso.
kubectl patch appprofile frontend --type=merge -p '{"spec":{"replicas":3}}'
Salida esperada:
appprofile.training.labex.io/frontend patched
Confirme el valor actualizado:
kubectl get appprofile frontend -o 'jsonpath={.spec.replicas}{"\n"}'
Salida esperada:
3
Cree un segundo recurso personalizado llamado 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
Salida esperada:
appprofile.training.labex.io/worker created
Enumere solo los recursos personalizados que pertenecen a la aplicación storefront. Esto funciona porque los recursos personalizados admiten etiquetas normales de Kubernetes.
kubectl get appprofiles -l app.kubernetes.io/part-of=storefront
La salida esperada incluye:
NAME AGE
frontend ...
worker ...
Utilice el nombre corto appprof para imprimir el nombre de cada recurso y su número de réplicas:
kubectl get appprof -o 'jsonpath={range .items[*]}{.metadata.name}{"="}{.spec.replicas}{"\n"}{end}'
La salida esperada incluye:
frontend=3
worker=1
Resumen
Ha creado un CRD, ha esperado a que se estableciera, ha descubierto el nuevo recurso de API con kubectl api-resources y kubectl explain, ha creado recursos personalizados, ha aplicado un parche a un recurso personalizado, los ha seleccionado por etiqueta y ha utilizado un nombre corto. Estas son las mismas habilidades operativas que utilizará cuando las tareas de CKAD involucren recursos instalados por un operador, controlador o extensión de plataforma.
