Julio Chana | Extendiendo kubernetes | Codemotion Madrid 2018
2 recomendaciones353 vistas
El documento describe cómo extender Kubernetes mediante la creación de operadores, que son controladores que gestionan recursos personalizados (CRDs) y mantienen su estado. Proporciona un ejemplo práctico de un operador para Redis, detallando su funcionamiento y cómo gestionar eventos para asegurar la integridad del sistema. También menciona la biblioteca Kooper, que facilita la creación de estos operadores al abstraer los componentes de Kubernetes.
Julio Chana | Extendiendo kubernetes | Codemotion Madrid 2018
- 1. Extendiendo Kubernetes: diseño de un operador Madrid | 30 Noviembre - 1 Diciembre, 2018 Julio Chana
- 2. Julio Chana Graduado en Ingeniería Informática por la Universidad Politécnica de Madrid SRE en Spotahome Twitter / @jchanam GitHub / @jchanam _Sobre mí
- 4. _¿Por qué extender Kubernetes? ¿Qué permite Kubernetes? • Hacer despliegues simples de microservicios • Crear balanceadores • Guardar secretos • Etc
- 5. _¿Por qué extender Kubernetes? ¿Qué necesitamos? • Desplegar software complejo ○ Varias piezas ○ Control individual ○ Orden específico • Control del ciclo de vida ○ Recuperación de errores ○ Cambios de estado ○ etc
- 6. _¿Por qué extender Kubernetes? /2 Ejemplo - Redis Failover Master Slave Slave Sentinel Sentinel Sentinel Redis +info: redis.io/topics/sentinel
- 7. _¿Por qué extender Kubernetes? /3 Opción 1: Init-containers + mucha imaginación, pero... • Scripts para comprobar prerrequisitos ○ Complejidad ○ Difícil testeo ○ No es resiliente ○ etc • No permite controlar varias piezas de forma simultánea
- 8. Opción 2: Charts de Helm, pero… • No permite requisitos previos • No comprueba estado actual de forma constante • Especifica los componentes que quiero, del modo que quiero, pero no cómo llegar a ello _¿Por qué extender Kubernetes? /3 +info: helm.sh
- 9. Solución: Crear nuestros propios controladores para implementar la lógica operacional de la aplicación. Beneficios: • Gestión específica • Orden necesario • Control completo • Mantenimiento contínuo • Estado fiable _¿Por qué extender Kubernetes? /4
- 11. _Cómo extender Kubernetes Pod C ReplicaSet Pod’ C Deployment ReplicaSet’ Pod C Pod’ C Recurso mínimo: Pod ↳ ReplicaSet: gestiona ciclo de vida de Pods ↳ Deployment: gestiona versiones de ReplicaSets
- 12. Igual que Kubernetes, crearemos nuestros recursos y trabajaremos sobre ellos: _Cómo extender Kubernetes /2 CRD Controller Operator+ = 1. Definición 2. Lógica 3. Éxito
- 13. _Cómo extender Kubernetes /3 Crear CRD (Custom Resource Definition) == Extender API Kubernetes APIs Pod Statefulset Service Role RoleBinding PersistentVolume Deployment PodDisruptionBudget Job DaemonSet Secret API Extensions + MyCustomResource_A MyCustomResource_B ... MyCustomResource_Z Son como el resto de recursos: • Usan recursos existentes • Configurados de forma específica • Con estado propio
- 14. _Cómo extender Kubernetes /4 CRD: Definición de los objetos que va a gestionar el controlador Mínimo dos componentes: • TypeMeta • Kind • APIVersion • ObjectMeta • Name • Namespace • Labels • Annotations • etc
- 15. _Cómo extender Kubernetes /4 Spec: información propia que necesitaremos. Estructura libre. Status: información del estado de nuestros objetos.
- 16. _Cómo extender Kubernetes /5 Una vez se tenga definido el CRD, Kubernetes ofrece un autogenerador de código, que creará las interfaces que nos permitirán interactuar con nuestros recursos. Con esto tendremos una API similar a la de cualquier otro recurso de Kubernetes.
- 17. _Cómo extender Kubernetes /6 CRD Controller Operator+ = ListerWatcher Handler+ ListerWatcher: ・ ‘Lister’: permite listar los recursos existentes ・ ‘Watcher’: escucha eventos de cambio de estado Handler: recibirá 3 tipos de llamadas: ・ ‘Add’: define el estado esperado del recurso ・ ‘Update’: define que un recurso se ha modificado ・ ‘Delete’: define que el recurso debe dejar de existir
- 18. _Cómo extender Kubernetes /7 Gestión de los eventos: 1. Simplificación -> Add == Update a. Siempre recibimos el estado deseado (level trigger) b. Menos lógica c. Sólo un flujo de trabajo 2. ‘Reconcilitation loop’ a. Un evento de ‘add’ por cada recurso cada N segundos b. Resiliencia frente a fallos 3. Borrado por el Garbage Collector de Kubernetes +info: github.com/spotahome/kooper
- 20. _Ejemplo: Redis Operator Pasos que lleva a cabo el controlador: 1. Registrar CRD 2. Quedarse a la espera de recibir los posibles eventos a. Cuando llega un evento ‘Add’ i. “Ensure”: asegurarse de que todos los recursos existen (y si no, crearlos) ii. “CheckAndHeal”: Comprobar que cada recurso está en el estado esperado b. Cuando llega un evento “Delete” i. En principio no es necesaria intervención
- 21. _Ejemplo: Redis Operator /2 Ensure Inicio de los recursos por defecto. Cada recurso no conoce del resto 1. Redis -> Nodos Máster 2. Sentinel -> Monitorizándose a sí mismos Master Master Master Sentinel Sentinel Sentinel Redis
- 22. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Master Master Master Sentinel Sentinel Sentinel Redis
- 23. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster Master Master Master Sentinel Sentinel Sentinel Redis
- 24. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste Master Slave Slave Sentinel Sentinel Sentinel Redis
- 25. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste 2. Comprobar que todos los esclavos tengan el mismo máster Master Slave Slave Sentinel Sentinel Sentinel Redis
- 26. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste 2. Comprobar que todos los esclavos tengan el mismo máster. Si no: a. Configurar los nodos con el máster correcto Master Slave Slave Sentinel Sentinel Sentinel Redis
- 27. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste 2. Comprobar que todos los esclavos tengan el mismo máster. Si no: a. Configurar los nodos con el máster correcto 3. Comprobar que todos los Sentinel monitorizan al Redis máster Master Slave Slave Sentinel Sentinel Sentinel Redis
- 28. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste 2. Comprobar que todos los esclavos tengan el mismo máster. Si no: a. Configurar los nodos con el máster correcto 3. Comprobar que todos los Sentinel monitorizan al Redis máster.Si no: a. Configurar todos los Sentinel para monitorizar este máster Master Slave Slave Sentinel Sentinel Sentinel Redis
- 29. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste 2. Comprobar que todos los esclavos tengan el mismo máster. Si no: a. Configurar los nodos con el máster correcto 3. Comprobar que todos los Sentinel monitorizan al Redis máster.Si no: a. Configurar todos los Sentinel para monitorizar este máster Master Slave Slave Sentinel Sentinel Sentinel Redis
- 30. _Ejemplo: Redis Operator /2 Check and Heal 1. Comprobar el número de nodos actuando como máster. Si > 1: a. Elegir un máster b. Configurar el resto de nodos como esclavos de éste 2. Comprobar que todos los esclavos tengan el mismo máster. Si no: a. Configurar los nodos con el máster correcto 3. Comprobar que todos los Sentinel monitorizan al Redis máster.Si no: a. Configurar todos los Sentinel para monitorizar este máster Master Slave Slave Sentinel Sentinel Sentinel Redis ESTADO ESPERADO
- 31. _Ejemplo: Redis Operator /3 Pasos que lleva a cabo el controlador tras un ‘Delete’: ● En el caso de los elementos creados dentro de Kubernetes, el borrado lo gestiona el garbage collector mediante el “Owner Reference” ○ Define qué recursos dependen de él ○ Borra en cascada (de mayor a menor) ● Si hay elementos externos, sí que deberemos hacer limpieza desde el controlador.
- 32. Otros ejemplos
- 33. _Otros ejemplos Cert Manager: https://github.com/jetstack/cert-manager
- 34. _Otros ejemplos Cert Manager: https://github.com/jetstack/cert-manager
- 35. _Otros ejemplos Cert Manager: https://github.com/jetstack/cert-manager
- 36. _Otros ejemplos /2 Prometheus Operator: https://github.com/coreos/prometheus-operator Service Level Operator: https://github.com/spotahome/service-level-operator Jaeger Operator: https://github.com/jaegertracing/jaeger-operator
- 37. Kooper
- 38. _Kooper Kooper es una librería que nos abstrae de los componentes de Kubernetes, facilitándonos crear los operadores: ・ Registra los CRD que definamos ・ Crea el controlador: ・ Lee los eventos de Kubernetes ・ Envía a nuestro handler los eventos con toda la información necesaria ・ Hace reintentos ・ Proporciona métricas +info: github.com/spotahome/kooper
- 39. Resumen
- 40. _Resumen Operador: Custom Resource Definition (CRD) + Controlador CRD: Especificación de nuestro recurso. Puede contener todo lo que sea necesario para nuestra aplicación Controlador: Gestiona los recursos de Kubernetes necesarios y comprueba que están funcionando del modo esperado
- 41. Consistencia eventual: ● Enfocar el diseño al estado deseado ● Recibiremos eventos sobre recursos nuevos y existentes ● El proceso debe ser idempotente ● Cada pieza debe ser capaz de arrancarse en un estado estable _Resumen /2
- 42. Más información: ・ https://product.spotahome.com Repositorios Open Source: ・ github.com/spotahome/kooper ・ github.com/spotahome/redis-operator ・ github.com/spotahome/service-level-operator ¡Gracias!