Introducción
Al hablar de Serverless, Kubernetes es un tema que no se puede evitar.
En la lección de hoy, continuaremos aprendiendo cómo configurar un entorno Serverless privado. Específicamente, construiremos la infraestructura Serverless basada en el despliegue local de K8s de la lección anterior. Luego, instalaremos componentes adicionales para ampliar las capacidades del clúster K8s, permitiendo finalmente que el clúster K8s local soporte Serverless.
Requisitos previos para construir Serverless
Antes de comenzar, aclaremos una pregunta que surgió durante el curso fundamental sobre Computación Serverless, particularmente FaaS. Algunos estudiantes preguntaron: “¿Cuál es la relación entre microservicios, Service Mesh y Serverless?”
Estos conceptos aparecen con frecuencia en las discusiones, pero no te sientas presionado. Yo también estaba confundido por estos conceptos cuando empecé a aprender sobre Serverless. Primero revisemos los microservicios. Al usar microservicios para crear BaaS, es posible que hayas notado que muchos conceptos en microservicios son bastante similares a los de Serverless.
En términos simples, Service Mesh es una solución de comunicación de red para microservicios que opera sin que los microservicios sean conscientes de ello. También podemos delegar la comunicación de red en una arquitectura Serverless a un Service Mesh. A través de Service Mesh, los componentes Serverless pueden trabajar estrechamente con el clúster K8s, y finalmente soportar nuestras aplicaciones desplegadas de manera Serverless. Veamos el siguiente diagrama de arquitectura:
Del diagrama, podemos ver claramente que la infraestructura subyacente de Serverless se puede construir sobre Service Mesh. Sin embargo, Service Mesh es solo una de las soluciones para implementar la comunicación de red en Serverless. También hay otras opciones como RSocket, gRPC y Dubbo. Elegí Service Mesh porque esta solución puede basarse en componentes de K8s y proporciona herramientas de visualización para ayudarnos a entender el mecanismo de funcionamiento de Serverless, como cómo lograr un tiempo de inicio cero y controlar el tráfico para lanzamientos graduales. Si quieres practicar, Service Mesh es sin duda la primera opción.
Infraestructura Serverless: Service Mesh
Algunas personas se refieren a Kubernetes, Service Mesh y tecnologías Serverless como los “tres pilares” del desarrollo de aplicaciones nativas en la nube. A estas alturas, supongo que entiendes la razón detrás de esto. Sin embargo, debo aclarar que en las siguientes lecciones introduciremos muchos términos nuevos. Te he dado una visión general de estos términos para que puedas tener una comprensión amplia. Si tienes tiempo, deberías profundizar en ellos.
Ahora, volvamos al tema principal y observemos más de cerca los principios de Service Mesh.
Cuando discutimos microservicios, solo cubrimos la guía teórica sobre descomposición e integración, sin tocar la implementación específica. Si pasamos a la implementación, la industria tiene muchos frameworks de microservicios, pero la mayoría se limitan a SDKs de lenguajes específicos, especialmente frameworks de microservicios Java.
El framework de microservicios en forma de SDK generalmente tiene un enfoque pesado en la implementación de la comunicación de red entre microservicios, como reintentar solicitudes de servicio fallidas, balanceo de carga entre múltiples instancias de servicio y limitación de tráfico durante altos volúmenes de solicitudes de servicio. Estas lógicas a menudo requieren la atención de los desarrolladores de microservicios y deben implementarse repetidamente en cada lenguaje SDK. Entonces, ¿es posible extraer la lógica de comunicación de red de microservicios del SDK, haciendo que nuestros microservicios sean más ligeros e incluso eliminando la necesidad de preocuparse por la comunicación de red?
La respuesta es Service Mesh.
Si desplegamos aplicaciones descompuestas en Pods del clúster K8s, el proceso se muestra en el siguiente diagrama, donde la aplicación MyApp llamará directamente al microservicio de usuario y al microservicio de tareas pendientes dentro del clúster a través de HTTP.
Pero, ¿qué pasa con los problemas de seguridad que surgen del acceso HTTP directo? Si alguien inicia un contenedor BusyBox en nuestro clúster, ¿no podría atacar directamente nuestro microservicio de usuario y el microservicio de tareas pendientes? Además, cuando tenemos múltiples instancias del microservicio de usuario, ¿cómo asignamos el tráfico?
Tradicionalmente, usaríamos un SDK de arquitectura de microservicios, que contiene mucha de esta lógica y muchas estrategias que debemos decidir cuándo activar al llamar al SDK. Nuestro código también se volvería fuertemente acoplado con el SDK de arquitectura de microservicios.
Service Mesh, sin embargo, adopta un enfoque diferente al extraer la lógica de comunicación de red del microservicio y gestionar el tráfico de red de manera no intrusiva, permitiéndonos no preocuparnos más por el pesado SDK de microservicios. Veamos cómo Service Mesh resuelve este problema.
Service Mesh se puede dividir en un plano de datos y un plano de control. El plano de datos es responsable de gestionar la comunicación de red, mientras que el plano de control controla y monitorea el estado de la comunicación de red. Service Mesh intercepta todo el tráfico de red inyectando un Sidecar.
En el plano de datos, nuestras aplicaciones y microservicios parecen comunicarse directamente con el Sidecar, pero en realidad, el Sidecar puede lograr esto mediante el secuestro de tráfico. Por lo tanto, nuestras aplicaciones y microservicios generalmente no son conscientes de esto y no requieren modificaciones, solo usan solicitudes HTTP para transmitir datos.
El plano de control es más complejo y es el núcleo de las operaciones de Service Mesh. El piloto es el motor de todo el plano de control, responsable del descubrimiento de servicios, la gestión del tráfico y el escalado. Citadel es la fortaleza guardian del plano de control, responsable de los certificados de seguridad y la autenticación. Mixer es el oficial de comunicaciones, que distribuye las políticas del plano de control y recopila el estado operativo de cada servicio.
Ahora deberías tener una comprensión clara de qué es Service Mesh, cómo extrae la lógica de comunicación de red de microservicios del SDK y por qué decimos que Service Mesh es la base de comunicación de red para Serverless.
La relación entre Serverless y los motores de contenedores
El valor central de Serverless radica en no tener que gestionar servidores, permitiendo centrarse en la lógica de negocio. La tecnología de contenedores proporciona la infraestructura potente y las capacidades de programación flexibles necesarias para Serverless, especialmente cuando se combina con herramientas de orquestación como Kubernetes.
Los contenedores ofrecen ventajas como empaquetado ligero, aislamiento de recursos e inicio rápido. Los contenedores empaquetan aplicaciones y sus dependencias, asegurando consistencia en el entorno de ejecución, lo que facilita el despliegue rápido y el inicio de instancias de aplicación en una plataforma Serverless. Además, los contenedores proporcionan entornos de ejecución aislados, asegurando que diferentes aplicaciones no interfieran entre sí, mejorando la estabilidad general de la plataforma. Además, el inicio de los contenedores es más rápido que el de las máquinas virtuales, cumpliendo con los altos requisitos de las aplicaciones Serverless para el escalado elástico.
Como núcleo de la programación Serverless, Kubernetes tiene funciones como despliegue automatizado, escalado elástico y descubrimiento de servicios. Puede desplegar automáticamente aplicaciones en contenedores según reglas predefinidas sin intervención manual, ajustar el número de instancias de aplicación según la carga en tiempo real, asegurando el rendimiento mientras optimiza la utilización de recursos, y proporcionar mecanismos de descubrimiento de servicios para facilitar la comunicación entre componentes dentro de la plataforma Serverless.
Para construir una plataforma Serverless basada en contenedores, primero, debes empaquetar las aplicaciones y sus dependencias en imágenes de contenedor, asegurando que las aplicaciones puedan desplegarse y ejecutarse rápidamente en la plataforma. Luego, elige una plataforma en la nube adecuada o configura un clúster Kubernetes autogestionado como infraestructura para la plataforma Serverless. A continuación, desarrolla componentes de la plataforma Serverless, incluyendo una puerta de enlace API para recibir y enrutar solicitudes externas, un tiempo de ejecución de funciones para cargar y ejecutar el código de las funciones y gestionar los ciclos de vida de las funciones, y desencadenadores de eventos que escuchan varias fuentes de eventos y convierten eventos en llamadas a funciones. Finalmente, usa Deployment de Kubernetes para gestionar el despliegue y la actualización de instancias de aplicación, Service para el descubrimiento de servicios y balanceo de carga, y HPA para lograr un escalado elástico automático.
Una plataforma Serverless basada en contenedores ofrece alta flexibilidad, gran capacidad de personalización y rentabilidad. Los desarrolladores pueden elegir libremente la tecnología de contenedores subyacente y la plataforma Kubernetes, personalizar las funciones y características de la plataforma Serverless según sus necesidades, y utilizar las capacidades de programación de recursos de Kubernetes para optimizar la utilización de recursos y reducir costos.
La combinación de la tecnología de contenedores y Kubernetes proporciona herramientas y métodos potentes para construir plataformas Serverless eficientes, flexibles y escalables, permitiendo a los desarrolladores construir fácilmente sus propias plataformas Serverless, centrarse en el desarrollo de la lógica de negocio y mejorar la eficiencia del desarrollo.
Novita AI Serverless
En Novita AI, hemos desarrollado nuestro propio motor de contenedores, Nexus. Aprovechando las potentes capacidades de computación distribuida y programación de recursos de Nexus, Novita AI ha construido un servicio Serverless orientado a la próxima generación de IA generativa. Los usuarios solo necesitan centrarse en la innovación empresarial sin preocuparse por los recursos informáticos subyacentes. Las reservas ya están abiertas; únete a la lista de espera para ser el primero en experimentar Novita AI Serverless.
Novita AI es la plataforma en la nube integral que impulsa tus ambiciones de IA. APIs integradas, serverless, instancias GPU — las herramientas rentables que necesitas. Elimina la infraestructura, comienza gratis y haz realidad tu visión de IA.
Lectura recomendada
Escalado bajo demanda: cómo Serverless maneja los picos de tráfico con facilidad
Descubriendo la revolución: explorando el mundo de la computación Serverless
