Autor: Li Peng (Alibaba Cloud), Wei Wenzhe (Shuhe Technology), este artículo se basa en el intercambio y la compilación de KubeCon China 2023.
Resumen
Los datos, la capacitación, la inferencia, etc. de los servicios de IA requieren una gran cantidad de recursos informáticos y costos de operación y mantenimiento. En el escenario comercial financiero de Shuhe Technology, el almacenamiento del modelo se itera con frecuencia y se implementan en línea múltiples versiones del modelo simultáneamente para su evaluación. El efecto real del modelo en línea es que el costo de los recursos es alto. Cómo mejorar la eficiencia de operación y mantenimiento de los servicios de IA y reducir los costos de recursos mientras se garantiza la calidad del servicio es un desafío.
Knative es una arquitectura de aplicaciones sin servidor de código abierto basada en Kubernetes, que proporciona elasticidad automática basada en solicitudes, escala a 0 y liberación en escala de grises. La implementación de aplicaciones sin servidor a través de Knative le permite centrarse en el desarrollo de la lógica de la aplicación y utilizar los recursos bajo demanda. Por lo tanto, combinar los servicios de IA con la tecnología Knative puede lograr una mayor eficiencia y reducir costos.
Shuhe Technology actualmente implementa más de 500 servicios de modelos de IA a través de Knative, lo que ahorra un 60 % de los costos de recursos, y el ciclo de implementación promedio se reduce del día anterior a 0,5 días.
En este intercambio, le mostraremos cómo implementar cargas de trabajo de IA basadas en Knative. El contenido específico incluye:
- Introducción a Knative
- Shuhe se basa en las mejores prácticas de Knative
- Cómo implementar difusión estable en Knative
Introducción a Knative
Como todos sabemos, Kubernetes ha atraído la atención de muchos fabricantes y desarrolladores desde que fue de código abierto en 2014. Como sistema de orquestación de contenedores de código abierto, los usuarios pueden reducir los costos de operación y mantenimiento y mejorar la eficiencia de operación y mantenimiento mediante el uso de K8, y proporciona API estandarizadas, algo así como El significado es evitar estar limitado por proveedores de nube, formando así un ecosistema nativo de la nube con K8 como núcleo. Según la encuesta CNCF 2021, el 96% de las empresas utilizan o evalúan Kubernetes.
Con la evolución de la tecnología nativa de la nube, la tecnología sin servidor, que se centra en las aplicaciones y utiliza recursos bajo demanda, se ha ido generalizando gradualmente. Gartner predice que más del 50% de las empresas globales implementarán Serverless para 2025.
Sabemos que FaaS, representada por AWS Lambda, ha hecho popular el Serverless. FaaS simplifica la programación: solo necesita escribir un fragmento de código para ejecutarlo directamente y los desarrolladores no necesitan preocuparse por la infraestructura subyacente. Sin embargo, FaaS actualmente tiene deficiencias obvias, incluido el modelo de desarrollo altamente intrusivo, limitaciones de tiempo de ejecución de funciones, soporte de plataformas entre nubes, etc.
La tecnología de contenedores representada por los K8 ha resuelto muy bien estos problemas. El concepto central de Serverless es centrarse en la lógica empresarial y reducir las preocupaciones de infraestructura.
Entonces, ¿cómo proporcionar a los desarrolladores tecnología de contenedores sin servidor basada en el estándar abierto K8?
La respuesta es: Knative.
Trayectoria de desarrollo nativo
Knative es un marco de orquestación de contenedores sin servidor de código abierto basado en Kubernetes lanzado en la conferencia Google Cloud Next de 2018. El objetivo es formular estándares de orquestación de aplicaciones Serverless multiplataforma, nativos de la nube y crear una plataforma Serverless de nivel empresarial. Alibaba Cloud Container Service ya proporcionó capacidades de productización de Knative ya en 2019. Con la incorporación de Knative a CNCF en marzo de 2022, cada vez más desarrolladores están adoptando Knative.
Descripción general de Knative
El módulo principal de Knative incluye principalmente Serving para implementar cargas de trabajo y Eventing, un marco basado en eventos.
La capacidad principal de Knative Serving es su servicio de alojamiento de aplicaciones simple y eficiente, que también es la base de sus capacidades sin servidor. Knative puede expandir automáticamente la cantidad de instancias durante los períodos pico según el volumen de solicitudes de su aplicación y reducir automáticamente la cantidad de instancias cuando el volumen de solicitudes disminuye, lo que puede ayudarlo a ahorrar costos de manera muy automática.
Knative's Eventing proporciona un modelo de evento completo. Una vez que se accede al evento, fluye internamente a través del estándar CloudEvent y, combinado con el mecanismo Broker/Trigger, proporciona una forma ideal para el procesamiento de eventos.
Modelo de aplicación kative.
El modelo de aplicación de Knative es Knative Service:
- Knative Service contiene 2 partes de configuración, una parte se usa para configurar la carga de trabajo, llamada Configuración. Cada vez que se actualiza el contenido de la Configuración, se creará una nueva Revisión.
- La otra parte de Route es la principal responsable de la gestión del tráfico de Knative.
Echemos un vistazo a lo que podemos hacer con la publicación en escala de grises basada en el tráfico:
Supongamos que creamos la versión V1 de Revison al principio. Si hay un nuevo cambio de versión en este momento, entonces solo necesitamos actualizar la configuración en el Servicio y se creará la versión V2. Luego podemos configurar un tráfico diferente. fluye para V1 y V2 a través de la relación Ruta, aquí v1 es 70% y v2 es 30%, entonces el tráfico se distribuirá a estas dos versiones en una proporción de 7:3. Una vez que se verifique la nueva versión V2 y no haya problemas, entonces podemos continuar con la escala de grises ajustando la proporción hasta que la nueva versión V2 esté al 100%. Durante este proceso de actualización en escala de grises, una vez que se descubre una anomalía en la nueva versión, la operación de reversión se puede realizar ajustando la proporción.
Además, podemos etiquetar la revisión en Ruta al tráfico. Después de etiquetar la revisión, podemos realizar directamente una prueba de versión separada a través de la URL, que puede entenderse como verificación canaria. Esta versión no afectará la depuración normal. acceso al tráfico.
Resiliencia automática basada en solicitudes: KPA
¿Por qué necesitamos elasticidad automática basada en las solicitudes?
La elasticidad basada en la CPU o la memoria a veces no refleja completamente el uso real del negocio, pero según la cantidad de concurrencia o la cantidad de solicitudes procesadas por segundo (QPS/RPS), para los servicios web, puede reflejar más directamente el rendimiento del servicio Knative proporciona capacidades de resiliencia automática basadas en solicitudes.
¿Cómo recopilar indicadores?
Para obtener el número actual de solicitudes de servicio, Knative Serving inyecta un contenedor proxy QUEUE (queue-proxy) en cada Pod, que es responsable de recopilar indicadores de concurrencia (concurrencia) o recuento de solicitudes (rps) del contenedor del usuario. Después de que Autoscaler obtenga estos indicadores con regularidad, ajustará la cantidad de Pods en la implementación de acuerdo con el algoritmo correspondiente para lograr la expansión y contracción automática en función de las solicitudes.
¿Cómo calcular el número de Pods elásticos?
Autoscaler calcula la cantidad requerida de Pods en función de la cantidad promedio de solicitudes (o simultaneidad) de cada Pod. De forma predeterminada, Knative usa elasticidad automática según la cantidad de concurrencia, y la cantidad máxima predeterminada de Pods de concurrencia es 100. Además, Knative también proporciona un concepto llamado porcentaje de utilización objetivo, que se denomina utilización objetivo.
Tomando como ejemplo la elasticidad basada en la concurrencia, el número de Pods se calcula de la siguiente manera:
POD数=并发请求总数/(Pod最大并发数*目标使用率)
Mecanismo de implementación de reducción a 0
Cuando se utiliza KPA, cuando no hay solicitudes de tráfico, la cantidad de Pods se reducirá automáticamente a 0; cuando haya solicitudes, la cantidad de Pods se ampliará desde 0. Entonces, ¿cómo sucede esto en Knative? La respuesta es mediante el cambio de modo.
Knative define dos modos de acceso a solicitudes: Proxy y Serve. Proxy Como sugiere el nombre, modo proxy, es decir, la solicitud será reenviada por proxy a través del componente activador. El modo de servicio es un modo de solicitud directa, que solicita directamente desde la puerta de enlace al Pod sin pasar por el proxy activador. Como se muestra abajo:
El cambio de modo lo realiza el componente del escalador automático. Cuando la solicitud es 0, el escalador automático cambiará el modo de solicitud al modo Proxy. En este momento, la solicitud se enviará al componente activador a través de la puerta de enlace. Después de recibir la solicitud, el activador pondrá la solicitud en la cola y presionará indicadores para notificar al escalador automático para la expansión. Cuando el activador detecte que el Pod está listo para ampliación, reenviará la solicitud.
Hacer frente al tráfico intenso
Cómo hacer rebotar recursos rápidamente bajo tráfico repentino
Aquí KPA involucra dos conceptos relacionados con la elasticidad: estable (modo estable) y pánico (modo de pánico). Con base en estos dos modos, podemos ver cómo KPA puede elastizar rápidamente los recursos.
Primero, el modo estable se basa en el período de ventana estable, que es de 60 segundos de forma predeterminada. Es decir, la cantidad promedio de Pods simultáneos se calcula dentro de un período de 60 segundos.
El modo de pánico se basa en el período de la ventana de pánico, que se calcula mediante el período de la ventana de estabilidad y los parámetros de porcentaje de la ventana de pánico. * Método de cálculo del período de ventana de pánico: período de ventana de pánico = porcentaje de ventana de pánico del período de ventana estable. El valor predeterminado es 6 segundos. Calcule el número promedio de Pods simultáneos en un período de 6 segundos.
KPA calculará la cantidad requerida de Pods en función de la cantidad promedio de Pods simultáneos en modo estable y modo de pánico.
Entonces, ¿qué valor se utiliza realmente para que la elasticidad surta efecto? Esto se juzgará en función de si la cantidad de Pods calculados en modo de pánico excede el umbral de pánico PanicThreshold. De forma predeterminada, cuando la cantidad de Pods calculada en modo pánico es mayor o igual a 2 veces la cantidad actual de Pods listos, la cantidad de Pods en modo pánico se usará para la validación elástica; de lo contrario, la cantidad de Pods en modo estable ser usado.
Obviamente, el modo pánico está diseñado para hacer frente a situaciones de tráfico repentinas. En cuanto a la sensibilidad elástica, se puede ajustar a través de los parámetros configurables mencionados anteriormente.
Cómo evitar que Pod explote debido al tráfico repentino
La capacidad de solicitud de ráfaga (target-burst-capacity) se puede configurar en KPA para hacer frente al Pod que se ve abrumado por tráfico inesperado. Es decir, mediante el cálculo del valor de este parámetro, podemos ajustar si la solicitud cambia al modo Proxy, de modo que cuando enfrentemos tráfico repentino, el componente activador se pueda usar como un búfer de solicitud para evitar que el Pod explote.
Algunos consejos para reducir los arranques en frío
Escalado retrasado
Para Pods con altos costos de inicio, el KPA se puede utilizar para reducir la frecuencia de expansión y contracción del Pod estableciendo el tiempo de reducción del retraso del Pod y la reducción del Pod en 0 período de retención.
Reduzca la tasa de uso objetivo para calentar recursos
La configuración del uso del umbral objetivo se proporciona en Knative. Al reducir este valor, la cantidad de Pods que exceden el uso real requerido se puede expandir por adelantado y la capacidad se puede expandir antes de que la solicitud alcance el número concurrente objetivo, lo que indirectamente puede calentar los recursos.
Configuración de políticas flexible
A través de la introducción anterior, comprendemos mejor el mecanismo de funcionamiento de Knative Pod Autoscaler. A continuación, presentaremos cómo configurar KPA. Knative proporciona dos formas de configurar KPA: modo global y modo de revisión. El modo global se puede configurar a través de ConfigMap: config-autoscaler, los parámetros son los siguientes:
Servicio de contenedores en la nube de Alibaba Knative
Los productos de código abierto generalmente no se pueden utilizar directamente en productos. Los problemas que enfrenta la productización de Knative incluyen:
- Hay muchos componentes de gestión y control y operaciones y mantenimiento complejos.
- Diversidad de potencia informática, cómo programarla según diferentes especificaciones de recursos según demanda
- Capacidades de puerta de enlace a nivel de producto en la nube
- Cómo solucionar el problema del arranque en frío
- 。。
Para abordar estos problemas, brindamos el servicio de contenedor de producto Knative. Totalmente compatible con la comunidad Knative y admite el marco de razonamiento de IA KServe. Capacidades de elasticidad mejoradas, que admiten grupos de recursos reservados, elasticidad precisa y predicción elástica; compatibilidad con puertas de enlace ALB, MSE y ASM totalmente administradas; integración impulsada por eventos con el producto en la nube EventBridge; además, integración con otros productos de Alibaba Cloud, como ECI, brazos, servicio de registro, etc. Se llevó a cabo una integración integral.
grupo de recursos reservados
Además de las capacidades nativas de KPA, brindamos la posibilidad de reservar grupos de recursos. Esta función se puede aplicar en los siguientes escenarios:
- ECS se mezcla con ECI. Si queremos utilizar recursos ECS en circunstancias normales y utilizar ECI para tráfico en ráfagas, podemos lograrlo reservando grupos de recursos. En circunstancias normales, el tráfico se transporta a través de recursos ECS y, para el tráfico repentino, los recursos recientemente ampliados utilizan ECI.
- Calentamiento de recursos. Para escenarios en los que se utiliza ECI por completo, el precalentamiento de recursos también se puede lograr reservando grupos de recursos. Cuando se utiliza una instancia reservada de baja especificación para reemplazar la instancia informática predeterminada durante los momentos bajos del negocio, la instancia reservada se utiliza para proporcionar servicios cuando llega la primera solicitud, lo que también desencadenará la expansión de la instancia de especificación predeterminada. Una vez completada la expansión de la instancia de especificación predeterminada, todas las solicitudes nuevas se reenviarán a la especificación predeterminada y luego la instancia se desconectará para conservarla. A través de este método de reemplazo continuo, se logra un equilibrio entre costo y eficiencia, es decir, se reduce el costo de las instancias residentes sin un tiempo de inicio en frío significativo.
Precisión y flexibilidad
La tasa de rendimiento de las solicitudes de procesamiento de un solo Pod es limitada. Si se reenvían varias solicitudes al mismo Pod, se producirá una excepción de sobrecarga en el lado del servidor. Por lo tanto, es necesario controlar con precisión la cantidad de procesamiento simultáneo de solicitudes de un solo Pod. . Especialmente en algunos escenarios AIGC, una sola solicitud ocupará muchos recursos de GPU y es necesario limitar estrictamente la cantidad de solicitudes simultáneas procesadas por cada Pod.
Knative se combina con la puerta de enlace nativa de la nube MSE para proporcionar una implementación de control elástico preciso basado en la concurrencia: el complemento elástico mpa.
mpa obtendrá el número de concurrencia de la puerta de enlace MSE y calculará la cantidad requerida de Pods para la expansión y contracción. Una vez que el Pod esté listo, la puerta de enlace MSE reenviará la solicitud al Pod correspondiente.
Pronóstico elástico
El servicio de contenedores AHPA (Advanced Horizontal Pod Autoscaler) puede identificar automáticamente ciclos elásticos y predecir la capacidad en función de indicadores comerciales históricos para resolver el problema del retraso elástico.
Actualmente, Knative admite la capacidad elástica de AHPA (Advanced Horizontal Pod Autoscaler). Cuando las solicitudes son periódicas, los recursos se pueden precalentar mediante predicción elástica. En comparación con la reducción del umbral de precalentamiento de recursos, AHPA puede maximizar la utilización de recursos.
A través de AHPA usted puede:
- Prepare los recursos con anticipación: amplíe la capacidad con anticipación antes de que lleguen las solicitudes
- Estable y confiable: el rendimiento de RPS previsto es suficiente para cubrir la cantidad real de solicitudes requeridas
evento conducido
Knative proporciona capacidades impulsadas por eventos a través de Eventing, y Eventing utiliza Broker/Trigger para el flujo y la distribución de eventos.
Pero el uso directo de Eventing nativo también enfrenta algunos problemas:
- Cómo cubrir suficientes fuentes de eventos
- Cómo garantizar que los eventos no se pierdan durante la transferencia
¿Cómo crear capacidades impulsadas por eventos a nivel de producción? Nos integramos con Alibaba Cloud EventBridge.
EventBridge es un servicio de bus de eventos sin servidor proporcionado por Alibaba Cloud. Alibaba Cloud Knative Eventing integra EventBridge en la capa inferior, proporcionando capacidades impulsadas por eventos a nivel de producto en la nube para Knative Eventing.
Entonces, ¿cómo utilizamos Knative en nuestros escenarios comerciales reales? ¿Qué beneficios podemos aportar a través de Knative? A continuación, les presentaré las mejores prácticas para utilizar Knative en la tecnología Shuhe.
Shuhe se basa en las mejores prácticas de Knative
Shuhe Technology (nombre completo "Shanghai Shuhe Information Technology Co., Ltd.") se estableció en agosto de 2015. Impulsada por big data y tecnología, Shuhe Technology proporciona a las instituciones financieras soluciones financieras minoristas inteligentes y eficientes. Su negocio abarca el crédito al consumo. marketing de captación de clientes, prevención y control de riesgos, gestión de operaciones y otros servicios en diversos campos, como crédito para pequeñas y microempresas y pago de escenarios.
Huanbei APP, una subsidiaria de Shuhe Technology, es una plataforma de servicio a plazos basada en múltiples escenarios de consumo, que ingresó oficialmente al mercado en febrero de 2016. Al cooperar con instituciones financieras autorizadas, brindamos servicios de crédito al consumo personal al público y brindamos apoyo de financiación de préstamos a propietarios de pequeñas y microempresas. En junio de 2023, Huanbei había acumulado 130 millones de usuarios activados, brindando servicios de crédito razonables a 17 millones de usuarios, ayudándolos a "pedir prestado y pagar fácilmente".
Puntos débiles del lanzamiento del modelo
Durante la fase de lanzamiento del modelo, el desperdicio de recursos es un problema
- Para garantizar la estabilidad de nuestros servicios, los buffers generalmente se reservan y los recursos generalmente se reservan de acuerdo con especificaciones que exceden nuestro uso real.
- Los recursos creados no se utilizan por completo durante todo el tiempo. Verá algunas aplicaciones en línea, especialmente algunas aplicaciones de tipo trabajo fuera de línea. La mayoría de las veces, el uso total de la CPU y la memoria es muy bajo, y solo se utilizan ciertos períodos de tiempo de los recursos. disponible La tasa de uso aumentará y habrá un fenómeno de marea obvio.
- Debido a que el uso de recursos carece de suficiente flexibilidad, a menudo resulta en una gran cantidad de desperdicio de recursos.
El problema de la difícil recuperación de recursos durante la fase fuera de línea del modelo
- Un modelo en línea puede tener varias versiones al mismo tiempo.
- Se utilizan diferentes versiones para evaluar el efecto real en línea del modelo. Si una determinada versión no funciona bien, esta versión se eliminará del proceso de toma de decisiones. En este momento, el modelo ya no proporciona servicios y, en este momento, si los recursos no pueden desconectarse a tiempo, se desperdiciarán recursos.
Modelo de arquitectura de tecnología de entrega continua
Pieza de plataforma modelo
La plataforma modelo genera archivos modelo y luego registra los archivos modelo en BetterCDS.
BetterCDS generará un artefacto correspondiente a este archivo de modelo
La liberación del modelo y la gestión de la versión del modelo se pueden completar a través de productos.
Módulo de gestión knative
Configurar la configuración de expansión global de Knative del modelo.
Cada modelo se puede configurar con su propia configuración de expansión knative.
canalización de CI
El proceso principal de la canalización de CI es extraer el archivo del modelo y crear la imagen del modelo a través del archivo acoplable.
Proceso de implementación
La canalización actualiza el servicio Knative, establece la versión de enrutamiento y la dirección espejo, y actualiza la configuración de expansión elástica de Knative. Knative generará una revisión correspondiente a la versión del producto.
Proceso de actualización del servicio Knative
- Las actualizaciones del servicio Knative generarán una versión de revisión.
- La versión de revisión generará un objeto de implementación.
- La canalización observará el estado de implementación. Si todos los pods están listos, se considera que esta versión se implementó correctamente.
- Después de una implementación exitosa, etiquete la revisión para crear una ruta de versión
Lanzamiento de varias versiones del modelo.
El lanzamiento del producto en múltiples versiones del modelo se implementa a través de la Configuración de Knative:
- Varias versiones del producto corresponden a la versión de revisión de la configuración uno a uno.
- El producto contiene una imagen de versión del modelo, que se genera a partir de la Revisión correspondiente del producto actualizando la versión de imagen del Servicio Knative.
Capacidad de coexistencia de servicios de múltiples versiones del modelo:
- Se crea una ruta de versión para la revisión a través de etiquetas y se llaman diferentes servicios de versión de acuerdo con diferentes rutas.
- Debido a que existen múltiples versiones al mismo tiempo, puede admitir llamadas a diferentes versiones del modelo en el proceso de toma de decisiones para observar el efecto del modelo y, al mismo tiempo, debido a la existencia de múltiples versiones de enrutamiento, puede admitir múltiples políticas de tráfico.
También admite un conjunto de rutas más recientes, que pueden cambiar la ruta más reciente a cualquier versión sin cambiar el proceso de toma de decisiones, completando así el cambio del tráfico en línea.
Ventana emergente basada en solicitudes
Por qué el modelo adopta la estrategia de expansión elástica según el número de solicitudes:
-
La mayoría de los modelos son servicios de uso intensivo de computación y el uso de la CPU del modelo está positivamente relacionado con la cantidad de solicitudes, por lo que una vez que aumentan las solicitudes, la CPU se llenará y eventualmente provocará una avalancha de servicios.
-
Además de la ventana emergente basada en solicitudes, también hay una ventana emergente HPA basada en indicadores de CPU y memoria, pero la ventana emergente HPA también tiene los siguientes problemas:
a. El vínculo de expansión elástica del indicador es largo: Prometheus recopila el indicador del indicador de exposición al servicio y el indicador aumenta. Luego, HPA calcula el número de grupos que se expandirán en función del indicador y luego comienza a expandir el grupo. El vínculo de expansión elástica general es relativamente largo.
B. Indicadores inexactos: por ejemplo, el gc de Java provocará cambios periódicos en la memoria.
c. El indicador no puede reflejar el estado real del servicio: cuando el indicador aumenta, el retraso de respuesta se ha vuelto muy alto. Es decir, si el indicador descubre que se excede el umbral, se retrasará y luego se cancelará el pod. ampliado y la cápsula estará lista, pero también se ha pospuesto.
- Por lo tanto, debemos adelantar el tiempo de expansión y utilizar la cantidad de solicitudes para activar la expansión del modelo para garantizar que el servicio modelo pueda mantener el estado normal del servicio.
El siguiente es el proceso de trabajo de una solicitud de versión de revisión del 100% al 0%:
El enlace emergente de Knative es el siguiente:
- Se solicita tráfico desde el servicio al pod.
- PodAutoscaler recopila los indicadores de solicitud de tráfico del proxy de cola en el Pod en tiempo real y calcula la cantidad de pods que se expandirán en función de la solicitud actual.
- PodAutoscaler controla la implementación para expandir los pods, y los Pods expandidos se agregarán a este Servicio, completando así la expansión de los Pods.
En comparación con la expansión elástica del indicador, la estrategia de expansión elástica basada en solicitudes tiene una respuesta más rápida y una mayor sensibilidad. Capaz de garantizar la respuesta del servicio. En vista de los puntos débiles del recurso fuera de línea en el pasado, dado que se puede reducir a 0, podemos ajustar el número mínimo de pods en la revisión a 0. Si no hay ninguna solicitud, se reducirá automáticamente a 0. Combinado con nodos elásticos, reducir la capacidad a 0 ya no ocupará recursos y también implementa la capacidad sin servidor de los servicios modelo.
Lanzamiento del modelo integral BetterCDS
El modelo se implementa a través de la tubería. El siguiente es el proceso de pasos del proceso de lanzamiento de BetterCDS.
- Paso de implementación de la versión: Activar la implementación del modelo Knative.
- Nueva ruta: Agregar ruta de la versión Knative.
- Actualizar la ruta más reciente: actualice la ruta más reciente como parámetro de la tubería. Puede optar por actualizar la ruta más reciente cuando se complete la implementación.
A través del módulo de gestión de configuración de ventanas emergentes de Knative, cada modelo se puede configurar con una configuración emergente global y una configuración emergente de versión.
Arquitectura de expansión elástica del clúster
Las aplicaciones de contenedores se ejecutan en nuestros grupos de nodos virtuales y ACK, y los nodos elásticos y ecs se combinan. El negocio normal se realiza mediante nodos ecs anuales y mensuales, y el negocio elástico se realiza mediante nodos elásticos de pago por uso, que pueden alcanzar altas elasticidad a bajo costo. Basado en la capacidad de elasticidad de los nodos virtuales, no solo cumple con los requisitos de elasticidad, sino que también evita el desperdicio de recursos y reduce los costos de uso.
- ACK mantiene un grupo de recursos de nodos fijos y reserva nodos en función de los pods residentes y el volumen de negocios regular, con costos de suscripción anuales y mensuales más bajos.
- Los nodos virtuales ejecutan instancias elásticas para proporcionar capacidades elásticas. Como no hay necesidad de preocuparse por los nodos, las capacidades elásticas se pueden ampliar según sea necesario para hacer frente fácilmente al tráfico repentino y a los picos y valles.
- Para las empresas que no tienen altos requisitos en tiempo real para trabajos y tareas fuera de línea, los recursos no estarán ocupados todo el tiempo debido a la periodicidad y la ventaja de costos es alta.
- Operación y mantenimiento gratuitos: nodos elásticos, las cápsulas se destruirán cuando se agoten
Resultados y beneficios
La elasticidad de Knative maximiza el uso de recursos. A partir de las curvas de solicitudes de recursos y tráfico, podemos ver que nuestros recursos tienen picos y valles, y hay una periodicidad obvia. Cuando la solicitud aumenta, el uso del Pod aumenta y cuando la solicitud disminuye, el Pod el uso aumenta y el volumen disminuye. El número máximo de Pods en el clúster es cercano a 2000, el costo se reduce en aproximadamente un 60% en comparación con el pasado y el ahorro de recursos es considerable.
Gracias a las capacidades de publicación de múltiples versiones de Knative, la eficiencia de la publicación también ha mejorado, de horas en el pasado a minutos ahora. La práctica del modelo Knative de Shuhe también recibió una certificación autorizada y fue seleccionada como "Excelente caso de aplicación nativa de la nube" por la Cloud Native Industry Alliance de la Academia de Tecnología de la Información y las Comunicaciones.
Knative y AIGC
Como proyecto muy conocido en el campo AIGC, Stable Diffusion puede ayudar a los usuarios a generar de forma rápida y precisa las escenas e imágenes que desean. Sin embargo, actualmente el uso de Stable Diffusion directamente en K8 enfrenta los siguientes problemas:
- La tasa de rendimiento de las solicitudes de procesamiento de un solo Pod es limitada. Si se reenvían varias solicitudes al mismo Pod, se producirá una excepción de sobrecarga en el lado del servidor. Por lo tanto, es necesario controlar con precisión la cantidad de procesamiento simultáneo de solicitudes de un solo Pod. .
- Los recursos de GPU son valiosos y se espera que utilicen recursos según sea necesario y liberen recursos de GPU de manera oportuna cuando el negocio sea bajo.
Con base en los dos problemas anteriores, podemos lograr una elasticidad precisa basada en la concurrencia a través de Knative. Cuando los recursos no estén en uso, la capacidad se reducirá a 0.
Además, Knative proporciona un disco observable listo para usar, que le permite ver la cantidad de solicitudes, la tasa de éxito de las solicitudes, las tendencias de expansión y contracción del Pod y los retrasos en las respuestas de las solicitudes, etc.
