O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Keda o como convertir Kubernetess en Serverless

257 visualizações

Publicada em

Slides de mi charla en la netcoreconf de Valencia donde hablé de KEDA y de domo integrarlo con Azure functions, para desplegar workloads FaaS en un Kubernetes.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Keda o como convertir Kubernetess en Serverless

  1. 1. 2020 Netcoreconf KEDA y Azure Functions o como convertir Kubernetes en Serverless Eduard Tomàs Compulsive Developer @ Plain Concepts @eiximenis
  2. 2. #netcoreconf Sponsors
  3. 3. #netcoreconf ¿Quien soy yo? • Principal Tech Lead @ PlainConcepts BCN • Padre orgulloso • Bebedor de cerveza • Picateclas a mucha honra • Microsoft MVP desde 2012
  4. 4. #netcoreconf Serverless • Foco en tú código, no en infraestructura • Escalado on demand • Ideal para apps basadas en eventos • Pago por uso
  5. 5. #netcoreconf Usos de Serverless Automatización Integración de servicios Creación rápida de APIs Proceso de eventos
  6. 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. 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. 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. 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. 10. #netcoreconf Keda - Arquitectura Pods Horizontal Pod Autoscaler (HPA) Servidor Métricas Controlador Escalador
  11. 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. 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. 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. 14. #netcoreconf Recursos generadaos • Un deployment • Un SecretMap con la configuración • Un ScaledObject con los triggers configurados
  15. 15. Desplegando en Kubernetes
  16. 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. 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
  18. 18. Desplegar con Helm
  19. 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. 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
  21. 21. Prometheus y Keda
  22. 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. 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. 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. 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. 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. 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. 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. 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. 30. #netcoreconf Recursos • https://keda.sh • https://github.com/kedacore/keda • https://helm.sh • https://cncf.io
  31. 31. #netcoreconf Sponsors
  32. 32. Más información: info@netcoreconf.com @Netcoreconf Visítanos en: netcoreconf.com

×