Información general sobre la arquitectura del servicio de Knative

En esta página se ofrece una descripción general de la arquitectura de Knative Serving y se explican los cambios que se producen cuando habilitas Knative Serving en tu clúster de Google Kubernetes Engine.

Esta información es útil para los siguientes tipos de usuarios:

• Usuarios que empiezan a usar el servicio de Knative.
• Operadores con experiencia en la ejecución de clústeres de GKE.
• Desarrolladores de aplicaciones que necesiten más información sobre cómo se integra Knative Serving con los clústeres de Kubernetes para diseñar mejores aplicaciones o configurar su aplicación Knative Serving.

Componentes de la instalación predeterminada

Instala Knative Serving en tu clúster para conectar y gestionar tus cargas de trabajo sin estado. Los componentes de Knative se crean en el espacio de nombres knative-serving.

Knative Serving usa Cloud Service Mesh para enrutar el tráfico. De forma predeterminada, Cloud Service Mesh instala componentes en el espacio de nombres istio-system.

Aquí tienes una lista de los componentes instalados por Knative Serving y Cloud Service Mesh:

• Componentes instalados por Knative Serving en el espacio de nombres knative-serving:

  • Activador: cuando los pods se reducen a cero o se sobrecargan con solicitudes enviadas a la revisión, Activador pone en cola temporalmente las solicitudes y envía métricas a Autoscaler para que ponga en marcha más pods. Una vez que la herramienta de escalado automático escala la revisión en función de las métricas registradas y los pods disponibles, Activator reenvía las solicitudes en cola a la revisión. Activator es un componente del plano de datos. Los componentes del plano de datos gestionan todas las funciones y los procesos de reenvío del tráfico de usuarios.
  • Autoscaler: agrega y procesa métricas de Activator y del contenedor sidecar de proxy de cola, un componente del plano de datos que aplica límites de simultaneidad de solicitudes. A continuación, Autoscaler calcula la simultaneidad observada de la revisión y ajusta el tamaño del despliegue en función del número de pods deseado. Cuando los pods están disponibles en la revisión, Autoscaler es un componente del plano de control. De lo contrario, cuando los pods se reducen a cero, Autoscaler es un componente del plano de datos.
  • Controlador: crea y actualiza los recursos secundarios de Autoscaler y los objetos Service. Controller es un componente del plano de control. Los componentes del plano de control gestionan todas las funciones y los procesos que establecen la ruta de solicitud del tráfico de usuarios.
  • Recolector de métricas: recoge métricas de los componentes de servicio de Knative y, a continuación, las reenvía a Cloud Monitoring.
  • Webhook: define valores predeterminados, rechaza objetos incoherentes y no válidos, y valida y modifica las llamadas a la API de Kubernetes en los recursos de servicio de Knative. Webhook es un componente del plano de control.

• Componentes instalados por Cloud Service Mesh que se ejecutan en el espacio de nombres istio-system:

  • Cluster Local Gateway: balanceador de carga del plano de datos responsable de gestionar el tráfico interno que llega de un servicio de Knative Serving a otro. Solo se puede acceder a Cluster Local Gateway desde tu clúster de GKE y no registra ningún dominio externo para evitar que se exponga accidentalmente información privada o procesos internos.
  • Istio Ingress Gateway: balanceador de carga del plano de datos que se encarga de recibir y gestionar el tráfico entrante desde fuera del clúster, incluido el tráfico de redes externas o internas.
  • Istiod configura la Cluster Local Gateway y la Istio Ingress Gateway para gestionar las solicitudes HTTP en los endpoints correctos. Istiod es un componente del plano de control. Para obtener más información, consulta Istiod.

Los componentes de serving de Knative se actualizan automáticamente con cualquier actualización del clúster del plano de control de GKE. Para obtener más información, consulta las versiones disponibles de GKE.

Uso de recursos de clúster

La instalación inicial de Knative Serving requiere aproximadamente 1,5 CPU virtuales y 1 GB de memoria para tu clúster. El número de nodos de tu clúster no afecta a los requisitos de espacio y memoria de una instalación de Knative Serving.

Un activador puede consumir solicitudes con un máximo de 1000 miliCPU y 600 MiB de RAM. Cuando un Activator no puede admitir el número de solicitudes entrantes, se activa un Activator adicional, lo que requiere una reserva de 300 miliCPU y 60 MiB de RAM.

Cada pod creado por el servicio de serving de Knative crea un sidecar proxy de cola que aplica los límites de simultaneidad de las solicitudes. El proxy de la cola reserva 25 milivCPUs y no tiene ninguna reserva de memoria. El consumo del proxy de la cola depende del número de solicitudes que se pongan en cola y del tamaño de las solicitudes. No hay límites en los recursos de CPU y memoria que puede consumir.

Crear un servicio

Arquitectura de servicio de Knative serving (haz clic en la imagen para ampliarla)

Knative Serving amplía Kubernetes definiendo un conjunto de definiciones de recursos personalizados (CRDs): Service, Revision, Configuration y Route. Estos CRDs definen y controlan cómo se comportan tus aplicaciones en el clúster:

• Knative serving Service es el recurso personalizado de nivel superior definido por Knative serving. Es una única aplicación que gestiona todo el ciclo de vida de tu carga de trabajo. Tu servicio se asegura de que tu aplicación tenga una ruta, una configuración y una nueva revisión para cada actualización del servicio.
• Una revisión es una captura inmutable del código y la configuración en un momento dado.
• Configuración mantiene los ajustes actuales de la última revisión y registra un historial de todas las revisiones anteriores. Al modificar una configuración, se crea una nueva revisión.
• Route define un endpoint HTTP y lo asocia a una o varias revisiones a las que se reenvían las solicitudes.

Cuando un usuario crea un servicio de Knative, ocurre lo siguiente:

1. El objeto Service de Knative Serving define lo siguiente:

   1. Una configuración sobre cómo servir tus revisiones.
   2. Una revisión inmutable de esta versión de tu servicio.
   3. Una ruta para gestionar la asignación de tráfico especificada a tu revisión.

2. El objeto de ruta crea VirtualService. El objeto VirtualService configura Ingress Gateway y Cluster Local Gateway para enrutar el tráfico de la pasarela a la revisión correcta.

3. El objeto de revisión crea los siguientes componentes del plano de control: un objeto de servicio de Kubernetes y un objeto de implementación.

4. La configuración de red conecta Activator, Autoscaler y los balanceadores de carga de tu aplicación.

Gestión de solicitudes

En el siguiente diagrama se muestra una vista general de una posible ruta de solicitud del tráfico de usuarios a través de los componentes del plano de datos de Knative Serving en un clúster de ejemplo de Google Kubernetes Engine:

Arquitectura de clúster de Knative Serving (haz clic en la imagen para ampliarla)

El siguiente diagrama se basa en el anterior para ofrecer una vista detallada de la ruta de la solicitud del tráfico de usuarios, que también se describe en detalle a continuación:

Ruta de solicitud de Knative Serving (haz clic en la imagen para ampliarla)

En el caso de una ruta de solicitud de servicio de Knative:

1. El tráfico llega a través de:

   • Ingress Gateway para el tráfico procedente de fuera de los clústeres
   • La puerta de enlace local del clúster para el tráfico dentro de los clústeres

2. El componente VirtualService, que especifica las reglas de enrutamiento del tráfico, configura las pasarelas para que el tráfico de los usuarios se dirija a la revisión correcta.

3. El servicio de Kubernetes, un componente del plano de control, determina el siguiente paso en la ruta de la solicitud en función de la disponibilidad de los pods para gestionar el tráfico:

   • Si no hay pods en la revisión:

     1. Activator pone en cola temporalmente la solicitud recibida y envía una métrica a Autoscaler para escalar más pods.
     2. El escalador automático se ajusta al estado deseado de los pods en la implementación.
     3. La implementación crea más pods para recibir solicitudes adicionales.
     4. Activator vuelve a intentar enviar solicitudes al sidecar proxy de la cola.

   • Si el servicio se escala horizontalmente (hay pods disponibles), el servicio de Kubernetes envía la solicitud al sidecar proxy de la cola.

4. El sidecar proxy de la cola aplica los parámetros de la cola de solicitudes, las solicitudes de un solo hilo o de varios hilos, que el contenedor puede gestionar a la vez.

5. Si el sidecar proxy de la cola tiene más solicitudes de las que puede gestionar, Autoscaler crea más pods para gestionar las solicitudes adicionales.

6. El sidecar proxy de la cola envía tráfico al contenedor de usuario.