Contrat d'exécution du conteneur

Cette page répertorie les exigences et comportements clés des conteneurs dans Knative serving.

Langages et images acceptés

Votre image de conteneur peut exécuter du code écrit dans le langage de programmation de votre choix et utiliser n'importe quelle image de base, à condition de respecter les contraintes présentées sur cette page.

Les fichiers exécutables dans l'image de conteneur doivent être compilés pour Linux 64 bits. Knative serving est spécifiquement compatible avec le format ABI de Linux x86_64.

Écouter les requêtes sur le port approprié

Le conteneur doit écouter les requêtes envoyées à 0.0.0.0 sur le port auquel celles-ci sont envoyées. Par défaut, les requêtes sont envoyées à 8080, mais vous pouvez configurer Knative serving pour envoyer des requêtes au port de votre choix.

Dans les instances de conteneur Knative serving, la valeur de la variable d'environnement PORT correspond toujours au port auquel les requêtes sont envoyées. Sa valeur par défaut est 8080.

Chiffrement de la couche de transport (TLS)

Le conteneur ne doit pas mettre en œuvre directement de sécurité de la couche de transport. TLS est interrompu par Knative serving pour HTTPS et gRPC, puis les requêtes sont transmises par proxy via HTTP ou gRPC au conteneur sans TLS.

Réponses

Votre instance de conteneur doit envoyer une réponse dans le délai spécifié dans le paramètre de délai avant expiration de la requête après réception de celle-ci, y compris l'heure de démarrage de l'instance de conteneur. Sinon, la requête est abandonnée et une erreur 504 est renvoyée.

Variables d'environnement

Les variables d'environnement suivantes sont automatiquement ajoutées aux conteneurs en cours d'exécution :

Nom	Description	Exemple
PORT	Port sur lequel le serveur HTTP doit écouter.	8080
K_SERVICE	Nom du service Knative serving en cours d'exécution.	hello-world
K_REVISION	Nom de la révision de Knative Serving en cours d'exécution.	hello-world.1
K_CONFIGURATION	Nom de la configuration de Knative serving ayant créé la révision.	hello-world

Accès au système de fichiers

Le système de fichiers de votre conteneur est accessible en écriture et obéit au comportement suivant :

• Il s'agit d'un système de fichiers en mémoire. Par conséquent, les opérations d'écriture sur ce système de fichiers utilisent la mémoire de l'instance de conteneur.
• Les données écrites dans le système de fichiers ne persistent pas lorsque l'instance de conteneur est arrêtée.

Cycle de vie de l'instance de conteneur

En réponse aux requêtes entrantes, un service subit automatiquement un scaling à hauteur d'un certain nombre d'instances de conteneurs, chacune exécutant l'image de conteneur déployée.

Lorsqu'une révision ne reçoit aucun trafic, elle subit un scaling vertical à hauteur du nombre minimal d'instances de conteneur configurées (zéro par défaut).

Démarrage

Vos instances de conteneur doivent écouter les requêtes dans les quatre minutes suivant leur démarrage. Pendant ce temps de démarrage, le processeur est alloué aux instances de conteneur.

Calcul limité à une requête

Après le démarrage, vous ne devez vous attendre à pouvoir effectuer des calculs que dans le cadre d'une requête : une instance de conteneur ne se voit pas allouer de CPU si elle n'est pas en mesure d'effectuer des calculs.

Arrêt

Une instance de conteneur peut être arrêtée à tout moment.

Lorsqu'une instance de conteneur doit être arrêtée, les nouvelles requêtes entrantes sont acheminées vers d'autres instances et les requêtes en cours de traitement ont le temps de se terminer. L'instance de conteneur reçoit ensuite un signal SIGTERM indiquant le début d'une période de 10 secondes avant d'être arrêtée (avec un signal SIGKILL). Au cours de cette période, l'instance de conteneur se voit attribuer un ou plusieurs processeurs et est facturée. Si l'instance de conteneur n'intercepte pas le signal SIGTERM, elle est immédiatement arrêtée.

À moins qu'une instance de conteneur ne soit désactivée en raison du paramètre de nombre minimal d'instances de conteneur défini, elle ne restera pas inactive pendant plus de 15 minutes.

Ressources d'instance de conteneur

Les requêtes de ressources pour vos instances de conteneur sont planifiées dans les nœuds de votre cluster GKE. Chaque nœud partage la quantité totale de ressources de calcul disponibles pour votre cluster GKE.

Par conséquent, la quantité de ressources de calcul disponibles pour un service Knative serving n'est limitée que par la quantité de ressources disponibles dans ce nœud. En savoir plus sur les ressources de calcul pour les requêtes

Par exemple, si vous allouez 512 Mo de mémoire à un conteneur et que celui-ci s'exécute dans le seul pod d'un nœud qui dispose de 8 Go de mémoire, ce conteneur peut tenter d'utiliser davantage de RAM.

Processeur

Par défaut, le side-car proxy de file d'attente réserve 25 milliprocesseurs, et la quantité de vCPU que vos services Knative serving peuvent utiliser est illimitée. La consommation de ressources du proxy de file d'attente dépend du nombre de requêtes mises en file d'attente et de leur taille.

Un processeur virtuel est mis en œuvre sous la forme d'une abstraction de matériel sous-jacent pour fournir le temps CPU équivalent d'un seul hyper-thread matériel sur des plates-formes de processeur variables. L'instance de conteneur peut être exécutée simultanément sur plusieurs cœurs. Le vCPU n'est alloué que lors du démarrage de l'instance de conteneur et du traitement des requêtes. Sinon, il est limité.

Pour allouer une autre valeur de processeur virtuel, reportez-vous à la documentation sur l'allocation de processeurs.

Mémoire

Par défaut, le side-car proxy de file d'attente ne réserve pas de mémoire, et la quantité de mémoire que vos services Knative serving peuvent utiliser est illimitée. Si vous le souhaitez, vous pouvez configurer des limites de mémoire pour vos services Knative serving. Pour en savoir plus sur la manière dont GKE gère la mémoire, consultez la page Mémoire et ressources de processeur pouvant être allouées.

Les utilisations types de la mémoire sont les suivantes :

• Code chargé dans la mémoire pour exécuter le service
• Écriture des données dans le système de fichiers
• Processus supplémentaires exécutés dans le conteneur, tel qu'un serveur nginx
• Systèmes de mise en cache en mémoire tels que l'OpCache PHP
• Utilisation de mémoire par requête

Simultanéité

Chaque instance de conteneur Knative serving est exécutée simultanément par défaut. Ainsi, chaque instance de conteneur peut recevoir plusieurs requêtes en même temps. Vous pouvez modifier ce paramètre en configurant la simultanéité.

Bac à sable d'instance de conteneur

Le service Knative serving n'utilise pas de bac à sable de conteneur.

Serveur de métadonnées d'instance de conteneur

Les instances de conteneur Knative serving exposent un serveur de métadonnées que vous pouvez utiliser pour récupérer des informations sur votre instance de conteneur, telles que l'ID de projet, la région, l'ID d'instance ou les comptes de service.

Vous pouvez accéder à ces données à partir du serveur de métadonnées en utilisant de simples requêtes HTTP vers le point de terminaison http://metadata.google.internal/ avec l'en-tête Metadata-Flavor: Google : aucune bibliothèque cliente n'est requise. Pour en savoir plus, consultez la section Obtenir des métadonnées.

Le tableau suivant répertorie certaines des informations sur le serveur de métadonnées disponibles :

Chemin	Description
/computeMetadata/v1/project/project-id	ID du projet de ce service Knative serving
/computeMetadata/v1/instance/region	Région de ce service Knative serving
/computeMetadata/v1/instance/id	Identifiant unique de l'instance de conteneur (également disponible dans les journaux).
/computeMetadata/v1/instance/service-accounts/default/token	Génère un jeton pour le compte de service de l'environnement d'exécution de ce service Knative serving