¿Qué es CRD?
Definición de recursos personalizados, k8s permite a los usuarios personalizar los recursos. La definición de un objeto de CRM crea un nuevo recurso de definición con el nombre y el esquema que especifique. La API de Kubernetes proporciona y gestiona el almacenamiento de sus recursos personalizados.
¿Qué es CR?
Recursos personalizados, recursos personalizados, ejemplos específicos de CRM. CR es una extensión de la API de Kubernetes. Los recursos personalizados pueden aparecer y desaparecer dentro de un clúster en ejecución a través del registro dinámico, y los administradores del clúster pueden actualizar los recursos personalizados independientemente del propio clúster. Después de instalar un recurso personalizado, los usuarios pueden usar kubectl para crear y acceder a sus objetos, tal como lo hace con recursos integrados como Pods .
El papel de los controladores personalizados
Los recursos personalizados proporcionan una API verdaderamente declarativa cuando los combinamos con controladores personalizados. La API declarativa impone la separación de funciones, declaramos el estado deseado del recurso y el controlador mantiene el estado actual de los objetos de Kubernetes sincronizados con el estado deseado declarado.
Cómo fortalecer la comprensión de CRD
CRD puede entenderse como una tabla de base de datos, que define el formato del nombre de la columna y el tipo de la tabla. CR es un registro fila por fila en la tabla. Ver también: ¡ Un CRD es como una tabla en Kubernetes! - saber casi
Ejemplos de operaciones CRD
Nuevo CRM
Escriba un resourcedefinition.yaml, de la siguiente manera:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
name: crontabs.stable.example.com
spec:
# group name to use for REST API: /apis/<group>/<version>
group: stable.example.com
# list of versions supported by this CustomResourceDefinition
versions:
- name: v1
# Each version can be enabled/disabled by Served flag.
served: true
# One and only one version must be marked as the storage version.
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
# either Namespaced or Cluster,指定该CRD是命名空间或集群范围的
scope: Namespaced
names:
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
plural: crontabs
# singular name to be used as an alias on the CLI and for display
singular: crontab
# kind is normally the CamelCased singular type. Your resource manifests use this.
kind: CronTab
# shortNames allow shorter string to match your resource on the CLI
shortNames:
- ct
Use el archivo yaml anterior para crear recursos personalizados:
kubectl apply -f resourcedefinition.yaml
Crear objetos personalizados
Escriba my-crontab.yaml, de la siguiente manera:
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
Use el archivo yaml anterior para crear recursos personalizados:
kubectl apply -f my-crontab.yaml
Eliminar CRD
kubectl delete -f resourcedefinition.yaml
Antes de presentar Operator, resumamos brevemente el diseño y el mecanismo de implementación de CRD en Kubernetes en API Server . De acuerdo con el diseño de Kubernetes, la implementación de cada objeto de recurso incorporado oficial para Nodo, Pod, Servicio, etc. incluye las siguientes funciones principales.
- La definición de metadatos (esquema) de los objetos de recursos : se puede entender como la definición de la tabla de la base de datos, que define la estructura de datos de los objetos de recursos correspondientes. La definición de metadatos de los objetos de recursos integrados oficiales se solidifica en el código fuente.
- Lógica de validación de objetos de recursos : para garantizar la legitimidad de los atributos de los objetos de recursos enviados por los usuarios.
- El código de operación CURD del objeto de recurso : puede entenderse como el código CURD de la tabla de la base de datos, pero es más difícil que este último, porque la operación CURD del servidor API en el objeto de recurso se guardará en la base de datos etcd. , y los requisitos de rendimiento del procesamiento también son más altos. Considere también cuestiones complejas como la compatibilidad de versiones y las transiciones de versiones.
- " Controladores automáticos " relacionados con objetos de recursos (como controladores detrás de objetos de recursos como RC e Implementación): Esta es una función muy importante. Kubernetes es una plataforma cuyo objetivo principal es la automatización. Los usuarios dan declaraciones de objetos de recursos deseados, y el "controlador automático" detrás de los recursos garantiza que la cantidad, el estado y el comportamiento de los objetos de recursos correspondientes siempre cumplan con las expectativas del usuario durante la operación.
Del mismo modo, cada desarrollador de un CRD personalizado debe implementar las funciones anteriores. Con el fin de reducir la dificultad y la carga de trabajo de la programación, los diseñadores de API Server se han esforzado mucho para que las primeras tres funciones anteriores se puedan realizar escribiendo directamente el archivo de definición YAML . Para la única cuarta función que requiere programación, dado que API Server proporciona una gran cantidad de bibliotecas API básicas, especialmente el marco de programación List-Watch fácil de usar, la dificultad de programación del controlador automático CRD se reduce considerablemente.
que es operador
El marco del operador no es para usuarios comunes, sino para desarrolladores de la plataforma Kubernetes. Con la API proporcionada por el marco del operador, los desarrolladores de plataformas pueden desarrollar más fácilmente un controlador similar a StatefulSet. En este controlador, los desarrolladores pueden implementar la manipulación personalizada del clúster de destino a través de la codificación, incluida la implementación del clúster, el descubrimiento de fallas y el ajuste del clúster, etc., para lograr una mejor implementación automática y una función de dimensión inteligente. En términos de implementación, operator = CRD + webhook + controller .
El escenario de Operador está especialmente diseñado para aplicaciones con estado Desde la perspectiva de las tendencias de desarrollo, los clústeres con estado principales se implementarán básicamente en clústeres de Kubernetes en forma de Operadores en el futuro.
Modos de trabajo comunes del Operador
Documentos de referencia:
Recursos personalizados | Kubernetes
Amplíe la API de Kubernetes con CustomResourceDefinitions | Kubernetes