【Serie Knative】Comprenda el diseño del sistema de expansión y contracción Knative Serving

Knative Serving es el núcleo del sistema Knative Serving, y comprender los componentes del sistema Knative Serving puede facilitar la comprensión de la implementación del sistema Knative Serving:

Comprenda el control flujo y tendencia del flujo de datos y comprender su papel en el proceso de expansión y contracción. Debido al espacio limitado, aquí sólo se proporciona una breve descripción de los componentes y cada componente se explicará en detalle más adelante.

Queue-proxy es un contenedor Sidecar que se ejecuta junto al contenedor del usuario y se ejecuta en el mismo Pod que el contenedor del usuario. Cada solicitud pasará por el contenedor de proxy de cola antes de llegar al contenedor empresarial.

Por eso pregunta qué es el proxy.

La función principal de queue-proxy es contar y limitar la concurrencia de solicitudes que llegan al contenedor empresarial. Cuando la concurrencia se establece para una Revisión (por ejemplo, se establece 5), queue-proxy lo hará. asegúrese de que no haya solicitudes simultáneas al mismo tiempo. Más de 5 solicitudes llegan al contenedor comercial. Cuando llegan más de 5 solicitudes, queue-proxy primero almacenará temporalmente las solicitudes en su propia cola (es por eso que hay una cola en el nombre). Queue-proxy también contará las solicitudes entrantes y proporcionará consultas de simultaneidad promedio y rps (solicitudes por segundo) a través del puerto especificado.

Autoscaler es un pod importante en el sistema Knative Serving. Consta de tres partes:

El reconciliador PodAutoscaler monitoreará los cambios de PodAutoscaler (KPA) y luego los entregará a Collector y. Decididor de procesamiento

El recopilador es el principal responsable de recopilar indicadores del proxy de cola de la aplicación. El recopilador recopilará los indicadores de cada instancia y luego resumirá los indicadores de todo el sistema. Para lograr la expansión y contracción, se recopilarán muestras de todas las instancias de la aplicación y las muestras recopiladas se reflejarán en todo el clúster.

Después de obtener el indicador, Decider decide cuántos Pods expandir. La fórmula de cálculo simple es la siguiente:

Además, la cantidad de expansión y contracción también estará limitada por el número máximo y mínimo de instancias en la Revisión. Al mismo tiempo, el Autoscaler también calculará la capacidad restante de solicitudes de ráfaga en el sistema actual (cuántas instancias se pueden expandir y contraer) para decidir si el Activador debe reenviar la solicitud.

Activator es un componente compartido por todas las aplicaciones en todo el sistema. Puede ampliarse y reducirse. Su objetivo principal es almacenar en caché las solicitudes e informar proactivamente los indicadores de solicitudes a Autoscaler.

Activator es. Se utiliza principalmente en el proceso de comenzar desde cero y reducirse a cero, y puede equilibrar la carga de las solicitudes de acuerdo con el volumen de solicitudes. Cuando la revisión se reduce a cero, las solicitudes pasan primero por el Activador en lugar de ir directamente a la revisión. Cuando llega la solicitud, el Activador almacenará en caché estas solicitudes y llevará el indicador de solicitud (número de solicitudes simultáneas) para activar el Autoscaler para expandir la instancia. Cuando la instancia esté lista, el Activador sacará la solicitud del caché y la reenviará. . Al mismo tiempo, para evitar sobrecargar las instancias de backend, Activator también actuará como equilibrador de carga, decidiendo qué instancia reenviar en función del volumen de solicitudes (distribuyendo solicitudes a todos los Pods en el backend, en lugar de que excedan el conjunto). cargar concurrencia).

Knative Serving decidirá si permite que la solicitud pase por el Activador en función de diferentes situaciones. Cuando hay suficientes instancias de pod en un sistema de aplicación, el Activador ya no desempeñará la función de reenvío de proxy y la solicitud se enviará directamente al. revisión para reducir la sobrecarga de rendimiento de la red.

A diferencia del proxy de cola, Activator informa activamente los indicadores a Autoscaler a través de websocket. Este diseño, por supuesto, está diseñado para iniciar en frío instancias de aplicaciones lo más rápido posible. queue-proxy es una extracción pasiva: el escalador automático va a queue-proxy para extraer indicadores para el puerto especificado.

API: podautoscalers.autoscaling.internal.knative.dev

PodAutoscaler es una abstracción para expansión y contracción, la abreviatura es KPA o PA, cada revisión

En consecuencia, se generará un PodAutoscaler.

Puede verlo a través del siguiente comando

API: serverlessservices.networking.internal.knative.dev

ServerlessServices es generado por KPA y un KPA genera un SKS. es una abstracción del servicio k8s

Se utiliza principalmente para controlar si el flujo de datos fluye directamente a la revisión del servicio (el número de instancias no es cero) o a través del Activador (el. número de instancias es 0).

Para cada revisión se generarán dos servicios k8s, un servicio público y un servicio privado.

El servicio privado es un servicio k8s estándar, y los correspondientes se filtran a través del. selector de etiquetas. Los pods generados por la implementación, es decir, los puntos finales correspondientes al svc, son administrados y controlados automáticamente por k8s.

El servicio público no está controlado por k8s. No tiene un selector de etiquetas y no generará automáticamente puntos finales como el servicio privado. Los endpoints correspondientes al servicio público

están controlados por el reconciliador Knative SKS.

SKS tiene dos modos: proxy y servicio.

Veamos el flujo de datos en varias situaciones para profundizar nuestra comprensión del mecanismo del sistema de expansión y contracción de Knative.

El flujo de trabajo en estado estable es el siguiente:

El flujo de trabajo de reducción a cero es el siguiente:

El flujo de trabajo del proceso de inicio en frío es el siguiente :

Después de que la revisión se reduce a cero, si llegan solicitudes en este momento, es necesario ampliar el sistema. Debido a que SKS está en modo proxy, el tráfico se solicitará directamente al Activador.

El Activador contará el número de solicitudes e informará activamente los indicadores al Autoscaler. Al mismo tiempo, el Activador almacenará en caché las solicitudes y observará el servicio privado de SKS hasta que se generen los puntos finales correspondientes al servicio privado.

Después de que el Autoscaler reciba el indicador enviado por el Activador, inmediatamente iniciará la lógica de expansión. La conclusión de este proceso es que se debe crear al menos un Pod. AutoScaler modificará el número de copias de la implementación correspondiente a la revisión a N (N>0). AutoScaler también establecerá el estado de SKS en modo de servicio. el tráfico será dirigido a Dirigirlo al pod correspondiente a la revisión.

El Activador eventualmente detectará la generación de puntos finales correspondientes al servicio privado y realizará comprobaciones de estado en los puntos finales. Una vez superada la verificación de estado, el Activador reenviará la solicitud previamente almacenada en caché a

la instancia en buen estado.

Finalmente la revisión completó el arranque en frío (expansión desde cero).