Esta es la sesión inaugural del Meetup Virtual de Cloud Native en Castellano. El Meetup Virtual de Cloud Native en Castellano esta formado por: * https://www.meetup.com/Cloud-Native-Guadalajara/ * https://www.meetup.com/Cloud-Native-Computing-Peru/ * https://www.meetup.com/Cloud-Native-Mexico/ Queremos llegar con este meetup virtual a cualquier lugar en el mundo en donde de hable castellano. Nos vemos el próximo miércoles 14 de agosto a las 8pm CST en https://www.youtube.com/CloudNativeMexico En esta ocasión hablaremos sobre los Custom Resource Definitions (CRDs)de Kubernetes, para entender que son, ara que sirven y como podemos usarlos y en que contextos no es recomendable usarlos.

1. Entendiendo los
CRDs de Kubernetes
Custom Resource Definitions

2. Recursos de Kubernetes
•En la API de Kubernetes, un recurso es un Endpoint que
almacena una colección de objetos de la API de cierto tipo.
•Por ejemplo, el recurso pods incorporado (built in)
contiene una colección de objetos Pod. La distribución
estándar de Kubernetes trae de caja muchos objetos/recursos
de la API incorporados.
•Ejemplo: Pod, Services, Deployments, etc.
•Con esos recursos, se pueden implementar muchos casos de
uso para ejecutar diversas cargas de trabajo.

3. CRDs
•Custom Resource Definitions.
•Permiten que los usuarios de Kubernetes, extiendan la
funcionalidad base sin modificar el código de Kubernetes en
tiempo de ejecución.
•La idea es que modamos modelar nuevos recursos/objetos,
que sean más específicos a nuestras nececidades.
•Si creamos un CRD, ese recurso puede ser usado como
cualquier otro objeto base de Kubernetes. Es decir estará
disponible para ser usado con kubectl por ejemplo.Todo
esto sin configurar algo extra fuera del cluster de Kubernetes.

4. Estado de los CRDs
•Los diversos CRDs que podamos definir, se almacenaran en la
misma base de datos que el resto de los recursos, en ETCD.
•Esto para tener la misma replicación y administración de su
ciclo de vida que los otros recursos.
•create/edit/delete
•De esta manera, Kubernetes evita que yo tenga que
implementar toda esta funcionalidad. Kubernetes esta listo
para ser extendido. Solo a partir de la versión 1.7.

5. Controller

6. La importancia del controller
•Si Kubernetes solo permitiera que se “agreguen” recursos sin
informar que esto ocurre de alguna forma, no podría ser
posible que lógica personalizada sea ejecutada cuando existen
cambios en un CRD.
•Esto es clave para comportarse como cualquier otro recurso
de Kubernetes.
•Es responsabilidad del desarrollador del CRD, proveer un
controller, que escuche los cambios de ese tipo de CRD.
https://engineering.bitnami.com/articles/a-deep-dive-into-kubernetes-controllers.html

7. Creando el primer CRD
•Es posible crear CRDs de la misma forma que se crea un
Deployment, mediante un manifiesto en formatoYAML
•El primer paso es crear el CRD mismo, una vez hecho esto, es
posible crear “instancias” de los CRDs.
•Todo esto desde el CLI con kubectl

8. Demo: mostrar como
crear un CRD desde el CLI

9. Operator Framework
https://coreos.com/operators/

10. Elementos básicos para un
Controller de un CRD
•Definir un esquema, el cual determina que atributos contiene
la especificación del CRD.
•Escribir la lógica del controller usado la API del Operator
Framework
•Operator Framework se encargará del ciclo de vida y sobre
todo del control de la “reconciliación” (cuando existe una
discordancia entre el estado deseado y actual)

11. ¡Esta parte es la complicada!

12. Ejemplos de CRD
•Strimzi, para instalar clusters de Kafka en Kubernetes.
•Istio Service Mesh, se utilizan un montón de CRDs para los
distintos objetos de configuración:
•VirtualService
•Gateway

13. Demo: Creando un
Controller y CRD funcional