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 |