Keda o como convertir Kubernetess en Serverless
Descargar como PPTX, PDF•0 recomendaciones•224 vistas
Este documento presenta KEDA, un proyecto de código abierto que permite escalar automáticamente aplicaciones en Kubernetes en respuesta a eventos externos. Explica cómo KEDA monitorea eventos para escalar proactivamente despliegues, permitiendo convertir Kubernetes en un entorno serverless. También describe cómo usar KEDA para desplegar funciones de Azure en Kubernetes y cómo gestionar procesos largos para evitar problemas de escalado.
Keda o como convertir Kubernetess en Serverless
- 1. 2020 Netcoreconf KEDA y Azure Functions o como convertir Kubernetes en Serverless Eduard Tomàs Compulsive Developer @ Plain Concepts @eiximenis
- 3. #netcoreconf ¿Quien soy yo? • Principal Tech Lead @ PlainConcepts BCN • Padre orgulloso • Bebedor de cerveza • Picateclas a mucha honra • Microsoft MVP desde 2012
- 4. #netcoreconf Serverless • Foco en tú código, no en infraestructura • Escalado on demand • Ideal para apps basadas en eventos • Pago por uso
- 5. #netcoreconf Usos de Serverless Automatización Integración de servicios Creación rápida de APIs Proceso de eventos
- 6. #netcoreconf FaaS – Functions as a Service • El paradigma típico de Serverless • Desplegamos “código” que se ejecuta y escala automáticamente • La ejecución suele ser motivada por eventos • Ideal para cloud • Azure Functions, AWS Lambdas, Google Functions
- 7. #netcoreconf Escalado en Kubernetes • Soportado “de serie” mediante el HPA • Pero (en un cluster estándard) el escalado no es óptimo para apps basadas en eventos • Escala sobre el síntoma (ej. Memoria, CPU), pero no la causa (ej. muchos mensajes encolados en SQS, Service Bus, RabbitMQ,…)
- 8. #netcoreconf KEDA – Kubernetes Event-Drive Autoscaler • Proyecto de código abierto iniciado por Microsoft • En proceso de donarse a la CNCF como Sandbox Project • Un paso más para tener serverless ON kubernetes
- 9. #netcoreconf KEDA • Monitoriza eventos para escalar proactivamente deployments • Usa HPAs y servidor de métricas propias • Permite escalar desde cero pods • Extensible mediante el concepto de scalers
- 10. #netcoreconf Keda - Arquitectura Pods Horizontal Pod Autoscaler (HPA) Servidor Métricas Controlador Escalador
- 11. #netcoreconf Conceptos de Keda: ScaledObject • CRD de Kubernetes que define una escalación por eventos • Permite escalar un deployment en base a eventos externos • spec.scaleTargetRef.deploymentName: Deployment a escalar • spec.triggers: Triggers que controlan el escalado del deployment
- 12. #netcoreconf Azure functions & Docker • Es possible empaquetar un Proyecto de AF como Docker 1. func init func-project 2. cd func-project 3. func init --docker-only 4. func new 5. docker build –t func-project .
- 13. #netcoreconf Publicar Azure Functions en Kubernetes con KEDA Hacer un “docker login” contra el ACR az acr login –n my-acr Desplegar la AF en Kubernetes func kubernetes deploy --name func-project –registry my-acr.azurecr.io
- 14. #netcoreconf Recursos generadaos • Un deployment • Un SecretMap con la configuración • Un ScaledObject con los triggers configurados
- 16. #netcoreconf Configuración de Azure functions en Keda • func kubernetes deploy genera por defecto configuración basada en local.settings.json • Se puede usar configuración propia creando un secretmap y usando --secret-name en func kubernetes deploy
- 17. #netcoreconf Desplegar manualmente con kubectl • Es posible desplegar con kubectl usando “func kubernetes deploy – dry-run” y mandando el resultado a kubectl • Eso permite también empaquetar con Helm todo el proceso
- 19. #netcoreconf KEDA: Principios de diseño • KEDA no es solo para FaaS • Puede escalar cualquier workload que se ejecute en Kubernetes • Funciona en cualquier cluster (desde MiniKube a AKS, EKS, GKE)
- 20. #netcoreconf Keda y métricas propias • Es posible usar Keda para autoescalar un deployment en base a métricas “propias” • Esas métricas se publican en Prometheus • Y se usan para autoescalar usando Keda
- 22. #netcoreconf Ejecuciones “largas” • KEDA autoescala workloads basados en métricas asociadas a los eventos • P. ej. El número de mensajes pendientes en una cola de RabbitMQ • Tenemos un proceso que consume mensajes, y tarda tiempo (p. ej. 3 h) en procesar un mensaje • El numero de mensajes pendientes aumenta y KEDA escala el deployment
- 23. #netcoreconf Ejecuciones “largas” Instancia 2 – Procesando mensaje 10% Instancia 1 – Procesando mensaje 80% Instancia 4 – Procesando mensaje 50% Instancia 3 – Procesando mensaje 90%
- 24. #netcoreconf Ejecuciones “largas” Instancia 2 – Procesando mensaje 10% Instancia 1 – Procesando mensaje 80% Instancia 4 – Procesando mensaje 50% Instancia 3 – Procesando mensaje 90%
- 25. #netcoreconf Ejecuciones “largas” • Dos opciones para evitar este problema • Opción 1: Usar los tiempos de vida de los pods (pod lifecycle) • Opción 2: Convertir el deployment en job y escalar el job por eventos
- 26. #netcoreconf Ejecuciones “largas” • Usar pod lifecycle • Pedir a Kubernetes “tiempo extra” cuando Kubernetes va a matar el pod • Funciona, pero es “feo” (estado terminating durante horas)
- 27. #netcoreconf Escalar “jobs” • En lugar de escalar deployments indicar a KEDA que cree un job por cada evento • Esos jobs se ejecutan hasta su finalización • Además podemos controlar el paralelismo
- 28. #netcoreconf Keda vs “standard approach” • Aproximación “estándard” Adaptador de Eventos ContainerHTTP • Desarrollador no debe preocuparse de obtener los eventos • Todo es HTTP/gRPC • Desarrollador no tiene acceso a las capacidades nativas del gestor de eventos • Ciertos patrones como ordenación son complicados • La responsabilidad de gestionar los eventos es del operador no del contenedor
- 29. #netcoreconf Keda vs “standard approach” • Aproximación de Keda Container Protocolo nativo • Desarrollador tiene acceso a las capacidades nativas del gestor de eventos • Cualquier patrón es posible (si lo soporta el emisor de eventos) • El desarrollador debe conocer los distintos emisores de eventos que use
- 30. #netcoreconf Recursos • https://keda.sh • https://github.com/kedacore/keda • https://helm.sh • https://cncf.io