Esta información es útil para los siguientes tipos de usuarios:
- Usuarios que comienzan a usar Knative serving.
- Operadores con experiencia en la ejecución de clústeres de GKE
- Desarrolladores de aplicaciones que necesitan saber más sobre cómo Knative serving se integra en los clústeres de Kubernetes para diseñar mejores aplicaciones o configurar su aplicación de Knative serving
Componentes en la instalación predeterminada
Instala Knative serving en tu clúster para conectar y administrar 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 los componentes en el espacio de nombres istio-system.
Esta es 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, el activador pone en cola las solicitudes de forma temporal y envía métricas al escalador automático para iniciar más Pods. Una vez que el escalador automático ajusta la escala de la revisión según las métricas informadas y los Pods disponibles, el activador reenvía las solicitudes en cola a la revisión. El activador es un componente del plano de datos. Los componentes del plano de datos administran todas las funciones y los procesos que reenvían el tráfico de los usuarios.
- Escalador automático: Agrega y procesa métricas del activador y del contenedor de sidecar del proxy de cola, un componente en el plano de datos que aplica los límites de simultaneidad de solicitudes. Luego, el escalador automático calcula la simultaneidad observada de la revisión y ajusta el tamaño de la implementación según el recuento de Pods deseado. Cuando los Pods están disponibles en la revisión, el escalador automático es un componente del plano de control. De lo contrario, cuando se reduce la escala de los Pods a cero, el escalador automático es un componente del plano de datos.
- Controlador: Crea y actualiza los recursos secundarios del escalador automático y los objetos Service. El controlador es un componente del plano de control. Los componentes del plano de control administran todas las funciones y los procesos que establecen la ruta de acceso a solicitudes del tráfico de los usuarios.
- Recopilador de métricas: Recopila métricas de componentes de Knative serving y, luego, las reenvía a Cloud Monitoring.
- Webhook: Establece valores predeterminados, rechaza objetos incoherentes y no válidos, y valida y muta las llamadas a la API de Kubernetes en función de los recursos de Knative serving. Webhook es un componente del plano de control.
Componentes instalados por Cloud Service Mesh que se ejecutan en el espacio de nombres
istio-system:- Puerta de enlace local del clúster: Balanceador de cargas en el plano de datos responsable de controlar el tráfico interno que llega de un servicio de Knative serving a otro. Solo se puede acceder a la puerta de enlace local del clúster desde el clúster de GKE, y esta no registra un dominio externo para evitar la exposición accidental de información privada o de procesos internos.
- Puerta de enlace de entrada de Istio: Balanceador de cargas en el plano de datos responsable de recibir y manejar el tráfico entrante desde fuera del clúster, incluido el tráfico de redes externas o internas.
- Istiod: Configura la puerta de enlace local del clúster y la puerta de enlace de entrada de Istio para controlar las solicitudes HTTP en los extremos correctos. Istiod es un componente del plano de control. Para obtener más información, consulta Istiod.
Los componentes de Knative serving se actualizan automáticamente con cualquier actualización del clúster del plano de control de GKE. Para obtener más información, consulta Versiones de GKE disponibles.
Uso de recursos del clúster
La instalación inicial de Knative serving requiere aproximadamente 1.5 CPU virtuales y 1 GB de memoria para tu clúster. La cantidad de nodos en tu clúster no afecta los requisitos de espacio y memoria para una instalación de Knative serving.
Un activador puede consumir solicitudes a un máximo de 1,000 millicores de CPU y 600 MiB de RAM. Cuando un activador existente no puede admitir la cantidad de solicitudes entrantes, se inicia un activador adicional, que requiere una reserva de 300 millicores de CPU y 60 MiB de RAM.
Cada Pod que crea el servicio de Knative serving crea un archivo adicional del proxy de cola que aplica los límites de simultaneidad de solicitudes. El proxy de cola reserva 25 millicores de CPU y no tiene reserva de memoria. El consumo del proxy de cola depende de la cantidad de solicitudes en cola y del tamaño de estas. No hay límites en cuanto a la CPU y los recursos de memoria que puede consumir.
Cómo crear un servicio
Knative serving extiende Kubernetes a través de la definición de un conjunto de definiciones de recursos personalizados (CRD): servicio, revisión, configuración y ruta. Estas CRD definen y controlan el comportamiento de tus aplicaciones en el clúster:
- El servicio de Knative serving es el recurso personalizado de nivel superior definido por Knative serving. Es una sola aplicación que administra todo el ciclo de vida de tu carga de trabajo. El servicio garantiza que tu app tenga una ruta, una configuración y una revisión nueva para cada actualización del servicio.
- La revisión es una instantánea inmutable del código y la configuración en un momento determinado.
- La configuración permite que las opciones establecidas actualmente de la última revisión se mantengan y que se registre un historial de todas las revisiones anteriores. Si modificas una configuración, se crea una revisión nueva.
- La ruta define un extremo HTTP y asocia el extremo con una o más revisiones a las que se reenvían las solicitudes.
Cuando un usuario crea un servicio de Knative serving, sucede lo siguiente:
El objeto del servicio de Knative serving define lo siguiente:
- Una configuración para entregar las revisiones
- Una revisión inmutable para esta versión del servicio
- Una ruta para administrar la asignación de tráfico especificada a la revisión
El objeto de ruta crea un VirtualService. El objeto VirtualService configura la puerta de enlace de entrada y la puerta de enlace local del clúster para enrutar el tráfico de puerta de enlace a la revisión correcta.
El objeto de revisión crea los siguientes componentes del plano de control: un objeto Deployment y un objeto Service de Kubernetes.
La configuración de red conecta el activador, el escalador automático y los balanceadores de cargas para tu app.
Cómo administrar solicitudes
En el siguiente diagrama, se muestra una descripción general de alto nivel de una posible ruta de solicitud para el tráfico de usuarios a través de los componentes del plano de datos de Knative serving en un clúster de muestra de Google Kubernetes Engine:
El siguiente diagrama se expande desde el diagrama anterior para proporcionar una vista detallada de la ruta de acceso a solicitudes del tráfico del usuario, que también se describe en detalle a continuación:
Para una ruta de solicitud de Knative serving:
El tráfico llega a través de estas puertas de enlace:
- La puerta de enlace de entrada para el tráfico proveniente de fuera de los clústeres
- La puerta de enlace local del clúster para el tráfico dentro de los clústeres
El componente VirtualService, que especifica las reglas de enrutamiento de tráfico, configura las puertas de enlace para que el tráfico de los usuarios se enrute a la revisión correcta.
El objeto Service de Kubernetes, un componente del plano de control, determina el siguiente paso en la ruta de acceso a solicitudes según la disponibilidad de los Pods para manejar el tráfico:
Si no hay Pods en la revisión, sucede lo siguiente:
- El activador pone en cola de manera temporal la solicitud recibida y envía una métrica al escalador automático para aumentar la escala de Pods.
- El escalador automático ajusta la escala al estado deseado de Pods en el objeto Deployment.
- Este último objeto crea más Pods para recibir solicitudes adicionales.
- El activador vuelva intentar realizar solicitudes al sidecar del proxy de cola.
Si el servicio se escala horizontalmente (los Pods están disponibles), el objeto Service de Kubernetes envía la solicitud al sidecar del proxy de cola.
El sidecar del proxy de cola aplica parámetros de cola de solicitudes, y solicitudes de uno o varios subprocesos, que el contenedor puede controlar a la vez.
Si el sidecar del proxy de cola tiene más solicitudes de las que puede controlar, el escalador automático crea más Pods para manejar solicitudes adicionales.
El sidecar del proxy de cola envía tráfico al contenedor del usuario.