En esta página se enumeran los requisitos y comportamientos clave de los contenedores en Knative Serving.
Idiomas e imágenes admitidos
Tu imagen de contenedor puede ejecutar código escrito en el lenguaje de programación que elijas y usar cualquier imagen base, siempre que respete las restricciones que se indican en esta página.
Los ejecutables de la imagen del contenedor deben compilarse para Linux de 64 bits. Knative Serving admite específicamente el formato ABI de Linux x86_64.
Escuchar 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.
En 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.
Cifrado de la capa de transporte (TLS)
El contenedor no debe implementar directamente ninguna seguridad de la capa de transporte. Knative Serving termina TLS para HTTPS y gRPC. Después, las solicitudes se envían como proxy a los contenedores mediante HTTP o gRPC sin TLS.
Respuestas
Tu instancia de contenedor debe enviar una respuesta en el plazo especificado en el ajuste de tiempo de espera de la solicitud después de recibir una solicitud, incluido el tiempo de inicio de la instancia de contenedor. De lo contrario, la solicitud se finaliza y se devuelve un error 504.
Variables de entorno
Las siguientes variables de entorno se añaden automáticamente a los contenedores en ejecución:
| Nombre | Descripción | Ejemplo |
|---|---|---|
PORT |
Puerto en el que debe escuchar tu servidor HTTP. | 8080 |
K_SERVICE |
Nombre del servicio de Knative Serving que se está ejecutando. | hello-world |
K_REVISION |
Nombre de la revisión de Knative Serving que se está ejecutando. | hello-world.1 |
K_CONFIGURATION |
Nombre de la configuración de Knative Serving que ha creado la revisión. | hello-world |
Acceso al sistema de archivos
El sistema de archivos de tu contenedor se puede escribir y está sujeto al siguiente comportamiento:
- Se trata de un sistema de archivos en memoria, por lo que escribir en él usa la memoria de la instancia del contenedor.
- Los datos escritos en el sistema de archivos no se conservan cuando se detiene la instancia del contenedor.
Ciclo de vida de las instancias de contenedor
En respuesta a las solicitudes entrantes, un servicio se escala automáticamente a un número determinado de instancias de contenedor, cada una de las cuales ejecuta la imagen de contenedor desplegada.
Cuando una revisión no recibe tráfico, se reduce al número mínimo de instancias de contenedor configurado (cero de forma predeterminada).
Startup
Las instancias de tu contenedor deben escuchar las solicitudes en un plazo de 4 minutos después de iniciarse. Durante este tiempo de inicio, se asigna CPU a las instancias de contenedor.
El cálculo se limita a una solicitud
Después del inicio, solo deberías poder realizar cálculos en el ámbito de una solicitud: una instancia de contenedor no tiene ninguna CPU asignada si no está procesando una solicitud.
Apagar
Una instancia de contenedor se puede cerrar en cualquier momento.
Cuando es necesario cerrar una instancia de contenedor, las nuevas solicitudes entrantes se dirigen a otras instancias y se da tiempo para que se completen las solicitudes que se estén procesando.
La instancia de contenedor recibe una señal SIGTERM que indica el inicio de un periodo de 10 segundos antes de apagarse (con una señal SIGKILL).
Durante este periodo, se asigna CPU a la instancia de contenedor y se factura.
Si la instancia de contenedor no recibe la señal SIGTERM, se cierra inmediatamente.
A menos que una instancia de contenedor deba permanecer inactiva debido a la configuración del número mínimo de instancias de contenedor, no permanecerá inactiva durante más de 15 minutos.
Recursos de instancias de contenedor
Las solicitudes de recursos de las instancias de contenedor se programan en los nodos del clúster de GKE. Cada nodo comparte la cantidad total de recursos de computación que están disponibles para tu clúster de GKE.
Por lo tanto, la cantidad de recursos de computación que está disponible para un servicio de Knative Serving solo está limitada por la cantidad de recursos disponibles en ese nodo. Consulta más información sobre los recursos de computación para las solicitudes.
Por ejemplo, si asignas 512 MiB de memoria a un contenedor y ese contenedor se ejecuta en el único pod 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 la cola reserva 25 milivCPUs y no hay límite en la cantidad de vCPUs que pueden usar tus servicios de Knative Serving. El consumo de recursos del proxy de la cola depende de cuántas solicitudes se pongan en cola y del tamaño de las solicitudes.
Una vCPU se implementa como una abstracción del hardware subyacente para proporcionar el tiempo de CPU aproximado equivalente a un hiperhilo de hardware único en plataformas de CPU variables. La instancia de contenedor se puede ejecutar en varios núcleos simultáneamente. La vCPU solo se asigna durante el inicio de la instancia de contenedor y el procesamiento de solicitudes. De lo contrario, se limita.
Para asignar un valor de vCPU diferente, consulta la documentación sobre asignación de CPU.
Memoria
De forma predeterminada, el sidecar proxy de la cola no reserva memoria y no hay límite en la cantidad de memoria que pueden usar tus servicios de Knative Serving. Si quieres, puedes configurar límites de memoria para tus servicios de Knative Serving. Para obtener más información sobre cómo gestiona la memoria GKE, consulta Recursos de memoria y CPU asignables.
Entre los usos habituales de la memoria se incluyen los siguientes:
- Código cargado en la memoria para ejecutar el servicio.
- Escribir 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 OpCache de PHP
- Uso de memoria por solicitud
Simultaneidad
De forma predeterminada, cada instancia de contenedor de Knative Serving se configura con una simultaneidad múltiple, donde cada instancia de contenedor puede recibir más de una solicitud al mismo tiempo. Puedes cambiarlo configurando la simultaneidad.
Entorno aislado de instancias de contenedor
Knative Serving no usa un sandbox de contenedores.
Servidor de metadatos de instancias de contenedor
Las instancias de contenedor de serving de Knative exponen un servidor de metadatos que puedes usar para obtener detalles sobre tu instancia de contenedor, como el ID de proyecto, la región, el ID de instancia o las cuentas de servicio.
Puedes acceder a estos datos desde el servidor de metadatos mediante solicitudes HTTP sencillas al endpoint http://metadata.google.internal/ con el encabezado Metadata-Flavor: Google
sin necesidad de usar bibliotecas de cliente. Para obtener más información, consulta Obtener metadatos.
En la siguiente tabla se muestra parte de la información disponible del servidor de metadatos:
| Ruta | Descripción |
|---|---|
/computeMetadata/v1/project/project-id |
ID del proyecto de este servicio de Knative |
/computeMetadata/v1/instance/region |
Región de este servicio de Knative |
/computeMetadata/v1/instance/id |
Identificador único de la instancia del contenedor (también disponible en los registros). |
/computeMetadata/v1/instance/service-accounts/default/token |
Genera un token para la cuenta de servicio de tiempo de ejecución de este servicio de Knative |