¿Qué son las definiciones de recursos personalizados (CRD) de Kubernetes?

Las definiciones de recursos personalizados (CRD) son extensiones de la API de Kubernetes que pueden definir nuevos tipos de objetos. Pods, ReplicaSets, ConfigMaps e Ingresses son ejemplos de recursos integrados comunes. Los CRD le permiten agregar tipos completamente nuevos a esta lista y luego administrarlos con herramientas familiares de Kubernetes, como Kubectl.

El mecanismo CRD es intencionalmente abstracto y se puede usar de innumerables formas para almacenar datos y crear nuevas funciones. Encontrará recursos personalizados en muchas herramientas comunitarias populares: Cert-Manager define objetos que representan certificados SSL y emisores, mientras que Helm representa gráficos como su propio CRD.

¿Qué hace un recurso?

Los recursos de Kubernetes definen los tipos de datos que puede almacenar en su clúster. Se accede a ellos a través de la API de Kubernetes, que proporciona puntos finales para crear, enumerar y modificar elementos dentro de cada tipo de recurso.

Puede agregar recursos personalizados para almacenar sus propios datos arbitrarios dentro de su clúster. Los elementos que cree serán almacenados por el componente del plano de control etcd, junto con instancias de recursos integrados. La API muestra automáticamente los recursos personalizados, por lo que no necesita configurar sus propias herramientas para crear instancias de elementos.

Los CRD actúan como estructuras de datos simples de forma predeterminada. Aunque los CRD en la naturaleza a menudo tienen sus propios comportamientos, el mecanismo CRD no proporciona esto. Los controladores y operadores personalizados de Kubernetes se pueden usar para implementar funciones en torno a recursos personalizados. Sin un controlador, los elementos de un CRD siempre existirán como datos estáticos en el clúster con los que puede interactuar a través de puntos finales CRUD proporcionados por la API de Kubernetes.

Los CRD son componentes dinámicos que se pueden crear y eliminar en cualquier momento. Algunos tipos de objetos que se incluyen con Kubernetes también se implementan como CRD, lo que brinda más modularidad dentro del núcleo del clúster.

Creación de un CRD

Los CRD son en sí mismos un tipo de objeto de Kubernetes. Los crea de la misma manera que cualquier otro recurso, escribiendo un archivo YAML y aplicándolo a su clúster:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: custom-apps.crds.example.com
spec:
  group: crds.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                app-name:
                  type: string
                app-version:
                  type: string
                release-count:
                  type: integer
  scope: Namespaced
  names:
    plural: custom-apps
    singular: custom-app
    kind: CustomApp

Use Kubectl para agregar CustomApp CRD a su clúster:

$ kubectl apply -f custom-apps-crd.yaml
customresourcedefinition.apiextensions.k8s.io/custom-apps.crds.example.com created

El archivo YAML define un CRD que podría usarse para almacenar datos sobre aplicaciones. Los CRD necesitan un metadata.name y spec.group campo en un formato preciso: el grupo toma la forma de un subdominio al que pertenece el CRD. El mismo subdominio debe estar incluido en los CRD's metadata.name . El valor de names.plural se antepone como un nuevo componente de subdominio para construir el final metadata.name.

los spec.names El campo define cómo hará referencia al CRD cuando use la API de Kubernetes y los comandos de Kubectl. En este ejemplo, podrá ejecutar kubectl get custom-apps y kubectl get custom-app/example-app para interactuar con objetos que utilizan el CRD. Cuando está creando un nuevo objeto como un archivo YAML, debe configurar kind: CustomApp para convertirlo en una instancia del CRD.

El CRD está configurado como un tipo de objeto de nivel de espacio de nombres por el scope campo. Puedes usar Cluster como valor alternativo para este campo para crear objetos que existen en el nivel de clúster, fuera de cualquier espacio de nombres.

Los datos asociados con sus objetos personalizados se definen en el spec.versions.schema.openAPIV3Schema campo. Cada "versión" enumerada crea una nueva versión de la API de CRD a la que puede hacer referencia con el apiVersion campo en sus archivos YAML de recursos. Los datos del CRD se configuran mediante las propiedades de OpenAPI; aquí, cada "aplicación personalizada" en su clúster debe tener app-name, app-versiony release-count propiedades establecidas en su YAML spec.

Usando su CRD

Pueden pasar unos minutos hasta que se aprovisionen los puntos finales de la API de un nuevo CRD. Verifique el progreso recuperando los detalles del CRD con Kubectl:

$ kubectl describe crd custom-apps.crds.example.com
...
Status:
  Accepted Names:
    Kind:       CustomApp
    List Kind:  CustomAppList
    Plural:     custom-apps
    Singular:   custom-app
  Conditions:
    Last Transition Time:  2022-04-04T13:29:24Z
    Message:               no conflicts found
    Reason:                NoConflicts
    Status:                True
    Type:                  NamesAccepted
    Last Transition Time:  2022-04-04T13:29:24Z
    Message:               the initial names have been accepted
    Reason:                InitialNamesAccepted
    Status:                True
    Type:                  Established
...

El CRD está listo para usar cuando vea Type: Established cerca del final de la salida del comando. Kubernetes aceptará solicitudes al extremo de la API de CRD. En este caso, la URL base de la API será la siguiente:

/apis/custom-apps.crds.example.com/v1/namespaces/*/custom-apps/...

Ahora puede usar Kubectl para ver los objetos que se han creado con el CRD:

$ kubectl get custom-apps
No resources found in default namespace.

Aunque todavía no existen objetos, Kubernetes ahora sabe que tiene un tipo de recurso llamado custom-apps.

Para crear un objeto de "aplicación personalizada", escriba un nuevo archivo YAML con kind: CustomApp. los apiVersion debe establecerse en el nombre de grupo y la versión de API proporcionada por el CRD. Dentro de spec sección, incluya las propiedades que definió en el esquema del CRD.

apiVersion: crds.example.com/v1
kind: CustomApp
metadata:
  name: demo-app-1
spec:
  app-name: demo-app
  app-version: 1.1.0
  release-count: 5

Use Kubectl para agregar el objeto a su clúster:

$ kubectl apply -f custom-app.yaml
customapp.crds.example.com/demo-app created

Ahora puede recuperar los detalles del objeto usando los comandos familiares de Kubectl:

$ kubectl describe custom-app/demo-app-1
Name:         demo-app
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  crds.example.com/v1
Kind:         CustomApp
...
Spec:
  App - Name:       demo-app
  App - Version:    1.1.0
  Release - Count:  5
...
Events:             <none>

Tiene un recurso personalizado en funcionamiento que ahora almacena algunos datos dentro de su clúster de Kubernetes. Puede eliminar el CRD eliminándolo en Kubectl; esto limpiará automáticamente todos los objetos que lo usan.

$ kubectl delete crd custom-apps.crds.example.com
customresourcedefinition.apiextensions.k8s.io "custom-apps.crds.example.com" deleted

Creación de API declarativas con CRD

Este CRD no agrega ninguna funcionalidad al clúster. Almacena datos, proporciona una API para interactuar con ellos y otros objetos pueden hacer referencia a ellos. Los CRD se vuelven más poderosos cuando se combinan con un controlador personalizado que puede asumir la responsabilidad de administrarlos.

Los controladores rastrean los recursos y toman medidas en respuesta a sus eventos. Escribir un controlador para sus CRD le permite convertirlos en API declarativas que provocan un cambio real dentro de su clúster. Sus objetos pueden representar el deseado estado, en lugar del estado actual exacto.

Cert-Manager utiliza este modelo para adquirir automáticamente certificados SSL cuando aparecen nuevos objetos CertificateRequest en su clúster. Dentro del núcleo de Kubernetes, los nodos extraen y ejecutan imágenes de contenedores en respuesta a la aparición de pods. Los controladores le permiten adjuntar comportamientos a sus propios CRD, por lo que agregar una "aplicación personalizada" podría hacer que su configuración se obtenga de un servicio externo. Puede comenzar a crear controladores utilizando Go SDK para integrar su propio código con el tiempo de ejecución de Kubernetes.

¿Cuándo usar los CRD?

Los CRD se utilizan mejor para manejar datos internos de su organización, equipo o proyecto. Están diseñados para representar esquemas claramente definidos, ya sea como valores estáticos o API declarativas respaldadas por una implementación de controlador personalizada.

Las funciones avanzadas le permiten implementar rutinas de validación para los campos en su esquema. También puede usar finalizadores para manejar las eliminaciones de objetos y adoptar el sistema de control de versiones para manejar los cambios en sus definiciones de CRD.

Los CRD a veces se superponen con Kubernetes ConfigMaps. Estos son objetos incorporados para almacenar datos de configuración genéricos asociados con sus aplicaciones. Un ConfigMap es apropiado cuando va a consumir los valores en un lugar específico de su clúster, como un pod que accede a la configuración de la base de datos como variables de entorno inyectadas desde un ConfigMap.

Los CRD están destinados a usarse cuando los datos deben ser un ciudadano de primera clase en su clúster. Puede crear varias instancias del tipo de recurso del CRD, interactuar directamente con ellas mediante Kubectl y crear sus propios esquemas estructurados que guíen a los usuarios para que ingresen los valores correctos. Pueden ser una mejor opción cuando los datos existen independientemente de cualquier otro elemento en su clúster.

Resumen

Las definiciones de recursos personalizados (CRD) de Kubernetes definen nuevos tipos de objetos que puede usar con la API de Kubernetes y Kubectl. Cada CRD obtiene su propia API versionada, tiene un esquema estructurado y se puede usar para implementar una nueva funcionalidad en el clúster cuando está respaldado por un controlador complementario.

Los CRD a veces pueden parecer complicados y reservados para situaciones avanzadas. Esto no tiene que ser el caso. Los CRD simples para almacenar valores estáticos en su clúster son fáciles de crear, como se ilustra en el ejemplo de "aplicación personalizada" anterior. Se pueden usar para almacenar datos de clúster independientes para que reciban un tratamiento de primera clase dentro de Kubernetes.

También es importante reconocer dónde los CRD no encajan bien. Los objetos incorporados como ConfigMaps y Secrets están diseñados para adaptarse a la mayoría de las formas de configuración que usarán directamente los Pods de su aplicación. Escribir un CRD que defina el esquema del archivo de configuración de su aplicación suele ser innecesario y más complicado de mantener con el tiempo, ya que no se beneficiará de las funciones de ConfigMap, como las actualizaciones continuas automáticas y la inyección de variables de entorno.