En esta página, se enumeran los requisitos y comportamientos clave de los contenedores en Knative serving.
Imágenes y lenguajes compatibles
Tu imagen de contenedor puede ejecutar código escrito en el lenguaje de programación que elijas y usar cualquier imagen base, siempre que cumpla con las restricciones enumeradas en esta página.
Los ejecutables en la imagen del contenedor deben compilarse para Linux de 64 bits. Knative serving admite específicamente el formato ABI x86_64 de Linux.
Escucha solicitudes en el puerto correcto
El contenedor debe escuchar las solicitudes en 0.0.0.0 en el puerto al que se envían las solicitudes. De forma predeterminada, las solicitudes se envían a 8080, pero puedes configurar Knative serving para enviar solicitudes al puerto que elijas.
Dentro de las instancias de contenedor de Knative serving, el valor de la variable de entorno PORT siempre refleja el puerto al que se envían las solicitudes.
El valor predeterminado es 8080.
Encriptación de la capa de transporte (TLS)
El contenedor no debe implementar ninguna seguridad de la capa de transporte de forma directa. Knative serving finaliza TLS para HTTPS y gRPC, y las solicitudes se envían como HTTP o gRPC al contenedor sin TLS.
Respuestas
La instancia de contenedor debe enviar una respuesta dentro del tiempo especificado en la configuración de tiempo de espera de la solicitud después de recibir una solicitud, incluido el tiempo de inicio de la instancia del contenedor. De lo contrario, se completa la solicitud y se muestra un error 504.
Variables de entorno
Las siguientes variables de entorno se agregan de forma automática a los contenedores en ejecución:
| Nombre | Descripción | Ejemplo |
|---|---|---|
PORT |
El puerto en el que debe escuchar el servidor HTTP. | 8080 |
K_SERVICE |
El nombre del servicio de Knative serving que se ejecuta. | hello-world |
K_REVISION |
Es el nombre de la revisión de Knative serving que se ejecuta. | hello-world.1 |
K_CONFIGURATION |
El nombre de la configuración de Knative serving que creó la revisión. | hello-world |
Acceso al sistema de archivos
El sistema de archivos de tu contenedor admite escritura y está sujeto al siguiente comportamiento:
- Este es un sistema de archivos en la memoria, por lo que para escribir en él, se usa la memoria de la instancia del contenedor.
- Los datos escritos en el sistema de archivos no persisten cuando se detiene la instancia de contenedor.
Ciclo de vida de las instancias de contenedor
En respuesta a las solicitudes entrantes, se escala automáticamente un servicio a una cierta cantidad de instancias de contenedores, cada una de las cuales ejecuta la imagen de contenedor implementada.
Cuando una revisión no recibe tráfico, la escala se ajusta a la cantidad mínima de instancias de contenedor configuradas (cero de forma predeterminada).
Inicio
Las instancias de contenedor deben escuchar las solicitudes en un plazo de 4 minutos después de su inicio. Durante este tiempo de inicio, las instancias de contenedor reciben la CPU asignada.
El procesamiento se limita a una solicitud
Después del inicio, solo deberías esperar poder calcular dentro del alcance de una solicitud: una instancia de contenedor no tiene ninguna CPU asignada si no procesa una solicitud.
Apagar
Una instancia de contenedor se puede cerrar en cualquier momento.
Cuando se debe cerrar una instancia de contenedor, las solicitudes entrantes nuevas se enrutan a otras instancias y las solicitudes en proceso tienen tiempo para completarse.
Luego, la instancia de contenedor recibe una señal SIGTERM que indica el inicio de un período de 10 segundos antes de apagarse (con una señal SIGKILL).
Durante este período, la instancia de contenedor se asigna a la CPU y se factura.
Si la instancia de contenedor no captura la señal SIGTERM, se cierra de inmediato.
A menos que una instancia de contenedor deba mantenerse inactiva debido a la configuración de la cantidad mínima de instancias de contenedor, no se mantendrá inactiva por más de 15 minutos.
Recursos de instancias de contenedor
Las solicitudes de recursos para tus instancias de contenedor se programan en los nodos de tu clúster de GKE. Cada nodo comparte la cantidad total de recursos de procesamiento que está disponible para el clúster de GKE.
Por lo tanto, la cantidad de recursos de procesamiento que está disponible para un servicio de Knative serving está limitada solo por la cantidad de recursos disponibles en ese nodo. Obtén más información sobre los recursos de procesamiento para las solicitudes.
Por ejemplo, si asignas 512 MiB de memoria para un contenedor y este se ejecuta en el único Pod dentro de un nodo que tiene 8 GiB de memoria, ese contenedor puede intentar usar más RAM.
CPU
De forma predeterminada, el sidecar del proxy de cola reserva 25 millicores de CPU y no hay un límite para la cantidad de CPU virtuales que pueden usar los servicios de Knative serving. El consumo de recursos del proxy de la cola depende de cuántas solicitudes se ponen en la cola y el tamaño de las solicitudes.
Una CPU virtual se implementa como una abstracción del hardware subyacente para proporcionar el tiempo de CPU equivalente aproximado de un subproceso de hardware único en plataformas variables de CPU. La instancia de contenedor se puede ejecutar en varios núcleos de forma simultánea. La CPU virtual solo se asigna durante el inicio de la instancia de contenedor y el procesamiento de solicitudes; de lo contrario, se regula.
Para asignar un valor de CPU virtual diferente, consulta la documentación a fin de asignar CPU.
Memoria
De forma predeterminada, el sidecar del proxy de cola no reserva memoria y no hay límite para la cantidad de memoria que pueden usar los servicios de Knative serving. Si lo deseas, puedes configurar límites de memoria para tus servicios de Knative serving. Para obtener más información sobre cómo GKE maneja la memoria, consulta Memoria asignable y recursos de CPU.
Entre los usos típicos de la memoria, se incluyen los siguientes:
- Código cargado en la memoria para ejecutar el servicio
- Escribe en el sistema de archivos
- Procesos adicionales que se ejecutan en el contenedor, como un servidor nginx
- Sistemas de almacenamiento en caché en memoria, como la OpCache de PHP
- Uso de memoria por solicitud
Simultaneidad
De forma predeterminada, cada instancia de contenedor de Knative serving está configurada en varias solicitudes simultáneas, en las que cada instancia de contenedor puede recibir más de una solicitud al mismo tiempo. Para cambiar esto, Configura la simultaneidad.
Zona de pruebas de la instancia del contenedor
Knative serving no usa una zona de pruebas en contenedores.
Servidor de metadatos de la instancia del contenedor
Las instancias de contenedor de Knative serving exponen un servidor de metadatos que puedes usar para recuperar detalles sobre la instancia de contenedor, como el ID del proyecto, la región, el ID de la instancia o las cuentas de servicio.
Puedes acceder a estos datos desde el servidor de metadatos a través de solicitudes HTTP simples al extremo http://metadata.google.internal/ con el encabezado Metadata-Flavor: Google: no se necesitan bibliotecas cliente. Para obtener más información, consulta Obtén metadatos.
En la siguiente tabla, se enumeran algunos de los datos del servidor de metadatos disponibles:
| Ruta | Descripción |
|---|---|
/computeMetadata/v1/project/project-id |
ID del proyecto de este servicio de Knative serving |
/computeMetadata/v1/instance/region |
Región de este servicio de Knative serving |
/computeMetadata/v1/instance/id |
Identificador único de la instancia de contenedor (también disponible en registros). |
/computeMetadata/v1/instance/service-accounts/default/token |
Genera un token para la cuenta de servicio del entorno de ejecución de este servicio de Knative serving. |