Utiliser le streaming d'image pour extraire des images de conteneur

Cette page vous explique comment utiliser le streaming d'images dans Google Kubernetes Engine (GKE) pour extraire des images de conteneurs en diffusant les données d'image selon les besoins de vos applications.

Les nouveaux clusters Autopilot qui exécutent la version 1.25.5-gke.1000 ou une version ultérieure de GKE utilisent automatiquement le streaming d'images pour extraire les images éligibles. Les instructions de cette page ne s'appliquent qu'aux clusters standards.

Présentation

Le streaming d'images est une méthode d'extraction d'images de conteneurs, dans laquelle GKE diffuse les données à partir des images éligibles, à la demande de vos applications. Vous pouvez utiliser le streaming d'images pour permettre à vos charges de travail de s'initialiser sans attendre le téléchargement de l'image entière, ce qui réduit considérablement les délais d'initialisation. La réduction du délai d'extraction présente les avantages suivants :

• Autoscaling plus rapide
• Latence réduite lors de l'extraction d'images volumineuses
• Démarrage plus rapide des pods

Avec le streaming d'images, GKE utilise un système de fichiers distant comme système de fichiers racine pour tous les conteneurs qui utilisent des images de conteneurs éligibles. GKE diffuse les données d'image du système de fichiers distant en fonction des besoins de vos charges de travail. Sans streaming d'images, GKE télécharge l'intégralité de l'image de conteneur sur chaque nœud et l'utilise comme système de fichiers racine pour vos charges de travail.

Lors du streaming des données d'image, GKE télécharge l'image entière du conteneur en arrière-plan dans le système de fichiers distant, puis la met en cache. GKE diffuse ensuite les futures requêtes de lecture des données à partir de l'image mise en cache.

Lorsque vous déployez des charges de travail qui doivent lire des fichiers spécifiques dans l'image de conteneur, le backend de streaming d'images ne diffuse que les fichiers demandés.

Conditions requises

Pour utiliser le streaming d'images dans les clusters GKE Autopilot et Standard, vous devez répondre aux exigences suivantes :

• Vous devez activer l'API Container File System.

  Activer l'API Container File System

• Les nouveaux clusters Autopilot doivent exécuter la version 1.25.5-gke.1000 ou une version ultérieure de GKE pour que le streaming d'images soit automatiquement activé. Pour obtenir des instructions, consultez la section Définir la version et la version disponible d'un nouveau cluster Autopilot.

• Les clusters GKE Standard nouveaux et existants doivent exécuter la version 1.18.6-gke.4801 ou une version ultérieure.

• Vous devez utiliser Container-Optimized OS avec une image de nœud containerd. Les nœuds Autopilot utilisent toujours cette image de nœud.

• Vos images de conteneurs doivent être stockées dans Artifact Registry.

• Si vous utilisez des clusters privés, vous devez activer l'accès privé à Google sur le sous-réseau pour que vos nœuds puissent accéder au service de streaming d'images.

• Si VPC Service Controls protège vos images de conteneurs et que vous utilisez la diffusion d'images, vous devez également inclure l'API Image Streaming (containerfilesystem.googleapis.com) dans le périmètre de service.

• Si les nœuds GKE du cluster n'utilisent pas le compte de service par défaut, vous devez vous assurer que votre compte de service personnalisé détient le rôle IAM Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer) dans le projet qui héberge l'image du conteneur.

Limites

• Vous ne pouvez pas utiliser un secret pour extraire des images de conteneurs sur des versions de GKE antérieures à la version 1.23.5-gke.1900.
• Les images de conteneurs qui utilisent le fichier manifeste d'image V2, schéma version 1 ne sont pas éligibles.
• Les images de conteneurs chiffrées à l'aide de clés de chiffrement gérées par le client (CMEK) sont éligibles au streaming d'images sur GKE 1.25.3-gke.1000 ou une version ultérieure. Dans les versions précédentes, GKE télécharge ces images sans diffuser les données. Vous pouvez toujours utiliser CMEK pour protéger les disques persistants et les disques de démarrage personnalisés associés dans les clusters utilisant le streaming d'images.
• Les images de conteneurs comportant des couches en double ne sont pas acceptées. GKE télécharge ces images sans diffuser les données. Dans votre image de conteneur, recherchez des couches vides ou des couches en double.
• Le dépôt Artifact Registry doit se trouver dans la même région que vos nœuds GKE ou dans un emplacement multirégional correspondant à la région dans laquelle vos nœuds sont exécutés. Exemple :
  • Si vos nœuds se trouvent dans us-east1, le streaming d'images est disponible pour les dépôts dans la région us-east1 ou dans l'emplacement multirégional us, car GKE et Artifact Registry s'exécutent dans des centres de données aux États-Unis.
  • Si vos nœuds se trouvent dans la région northamerica-northeast1, ils s'exécutent au Canada. Dans ce cas, le streaming d'images n'est disponible que pour les dépôts de la même région.
• Si vos charges de travail lisent de nombreux fichiers dans une image lors de l'initialisation, vous remarquerez peut-être des délais d'initialisation plus élevés en raison de la latence qu'ajoutent les lectures de fichiers distants.
• Vous ne remarquerez peut-être pas les avantages du streaming d'images lors de la première extraction d'une image éligible. Cependant, une fois que le streaming d'images a mis en cache l'image, les futures extractions d'images sur n'importe quel cluster bénéficieront des avantages du streaming d'images.
• Les clusters GKE Standard utilisent la configuration au niveau du cluster pour déterminer s'il convient d'activer le streaming d'images sur les pools de nœuds créés par le provisionnement automatique des nœuds. Toutefois, vous ne pouvez pas utiliser la séparation de charge de travail pour créer des pools de nœuds avec le streaming d'images activé lorsque le streaming d'images est désactivé au niveau du cluster.
• Les fonctionnalités de fichiers Linux, telles que CAP_NET_RAW, sont compatibles avec le streaming d'images dans GKE 1.22.6-gke.300 et versions ultérieures. Pour les versions précédentes de GKE, ces fonctionnalités ne sont pas disponibles lors de la diffusion du fichier image ni lors de l'enregistrement de l'image sur le disque local. Pour éviter toute interruption potentielle, n'utilisez pas le streaming d'images pour les conteneurs dotés de ces fonctionnalités dans les versions de GKE antérieures à 1.22.6-gke.300. Si votre conteneur repose sur des fonctionnalités de fichier Linux, son démarrage peut échouer avec des erreurs de refus d'autorisation lors de l'exécution avec le streaming d'images activé.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

• Activez l'API Container File System.

  Activer l'API Container File System

Activer le streaming d'images sur les clusters

Vous pouvez activer le streaming d'images sur des clusters standards nouveaux ou existants en utilisant l'option --enable-image-streaming de gcloud CLI ou la console Google Cloud. Par défaut, les pools de nœuds du cluster héritent du paramètre de streaming d'images au niveau du cluster. Vous pouvez modifier ce comportement en activant ou en désactivant le streaming d'images sur les pools de nœuds du cluster.

Tous les nouveaux clusters Autopilot qui exécutent GKE version 1.25.5-gke.1000 ou une version ultérieure utilisent le streaming d'images pour extraire des images éligibles. Pour obtenir des instructions, consultez la section Définir la version et la version disponible d'un nouveau cluster Autopilot. Les instructions suivantes ne s'appliquent qu'aux clusters GKE Standard.

Sur un nouveau cluster

Vous pouvez activer le streaming d'images sur de nouveaux clusters à l'aide de gcloud CLI ou de la console Google Cloud.

gcloud container clusters create CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --image-type="COS_CONTAINERD" \
    --enable-image-streaming

Sur un cluster existant

Vous pouvez activer le streaming d'images sur des clusters existants qui répondent aux exigences à l'aide de gcloud CLI ou de la console Google Cloud.

gcloud container clusters update CLUSTER_NAME \
    --enable-image-streaming

Une fois le cluster modifié, GKE active automatiquement le streaming d'images sur vos pools de nœuds existants. Si vous avez explicitement activé ou désactivé le streaming d'images sur des pools de nœuds individuels, ces pools n'héritent pas des modifications apportées au paramètre au niveau du cluster.

Vérifier que le streaming d'images est activé sur un cluster

Vous pouvez vérifier si le streaming d'images est activé au niveau du cluster à l'aide de gcloud CLI ou de la console Google Cloud.

gcloud container clusters describe CLUSTER_NAME \
    --flatten "nodePoolDefaults.nodeConfigDefaults"

gcfsConfig:
  enabled: true
...

gcfsConfig: {}
...

Activer le streaming d'images sur des pools de nœuds

Par défaut, les pools de nœuds héritent du paramètre de streaming d'images au niveau du cluster. Vous pouvez activer ou désactiver le streaming d'images sur des pools de nœuds spécifiques à l'aide de gcloud CLI.

Sur un nouveau pool de nœuds

Pour créer un pool de nœuds avec le streaming d'images activé, exécutez la commande suivante :

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --image-type="COS_CONTAINERD" \
    --enable-image-streaming

Remplacez les éléments suivants :

• NODE_POOL_NAME : nom de votre nouveau pool de nœuds.
• CLUSTER_NAME : nom du cluster pour le pool de nœuds.
• COMPUTE_ZONE : zone Compute Engine de votre cluster. Pour les clusters régionaux, utilisez plutôt l'option --region=COMPUTE_REGION.

Sur un pool de nœuds existant

Vous pouvez activer le streaming d'images sur les pools de nœuds existants qui répondent aux exigences.

Pour mettre à jour un pool de nœuds existant afin d'utiliser le streaming d'images, exécutez la commande suivante :

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --enable-image-streaming

Vérifier que le streaming d'images est activé sur un pool de nœuds

Vérifiez si le streaming d'images est activé pour un pool de nœuds :

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \

Le paramètre est activé si la sortie ressemble à ce qui suit :

gcfsConfig:
  enabled: true
...

Ce paramètre est désactivé si la sortie ressemble à ce qui suit :

gcfsConfig: {}
...

Planifier une charge de travail à l'aide du streaming d'images

Une fois activé sur votre cluster, le streaming d'images est automatiquement utilisé par GKE lors de l'extraction d'images de conteneurs éligibles à partir d'Artifact Registry sans nécessiter de configuration supplémentaire.

GKE ajoute le libellé cloud.google.com/gke-image-streaming: "true" aux nœuds des pools de nœuds avec le streaming d'images activé. Sur GKE Standard, si vous activez ou désactivez le streaming d'images sur des pools de nœuds spécifiques afin que votre cluster contienne un mélange de nœuds qui utilisent le streaming d'images et d'autres qui ne l'utilisent pas, vous pouvez utiliser des sélecteurs de nœuds dans vos déploiements pour contrôler si GKE planifie vos charges de travail sur des nœuds qui utilisent le streaming d'images.

Dans l'exemple suivant, vous planifiez un déploiement qui utilise une image de conteneur volumineuse sur un cluster avec le streaming d'images activé. Vous pouvez ensuite comparer les performances avec une extraction d'images sans le streaming d'images activé.

1. Créez un cluster avec le streaming d'images activé :

   gcloud container clusters create CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --enable-image-streaming \
       --image-type="COS_CONTAINERD"
   

2. Obtenez les identifiants du cluster :

   gcloud container clusters get-credentials CLUSTER_NAME \
       --zone=COMPUTE_ZONE
   

3. Enregistrez le manifeste suivant sous le nom frontend-deployment.yaml :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: frontend
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: guestbook
         tier: frontend
     template:
       metadata:
         labels:
           app: guestbook
           tier: frontend
       spec:
         containers:
         - name: php-redis
           image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
           env:
           - name: GET_HOSTS_FROM
             value: "dns"
           resources:
             requests:
               cpu: 100m
               memory: 100Mi
           ports:
           - containerPort: 80
   

   La taille de l'image de conteneur gb-frontend est de 327 Mo.

4. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f frontend-deployment.yaml
   

5. Vérifiez que GKE a créé le déploiement :

   kubectl get pods -l app=guestbook
   

   Le résultat ressemble à ce qui suit :

   NAMESPACE    NAME                          READY    STATUS       RESTARTS    AGE
   default      frontend-64bcc69c4b-pgzgm     1/1      Completed    0           3s
   

6. Obtenez le journal des événements Kubernetes pour afficher les événements d'extraction d'images :

   kubectl get events --all-namespaces
   

   Le résultat ressemble à ce qui suit :

   NAMESPACE  LAST SEEN  TYPE    REASON          OBJECT                                                 MESSAGE
   default    11m        Normal  Pulling         pod/frontend-64bcc69c4b-pgzgm                          Pulling image "us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5"
   default    11m        Normal  Pulled          pod/frontend-64bcc69c4b-pgzgm                          Successfully pulled image "us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5" in 1.536908032s
   default    11m        Normal  ImageStreaming  node/gke-riptide-cluster-default-pool-f1552ec4-0pjv    Image us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 is backed by image streaming.
   ...
   

   Dans ce résultat :

   • L'événement Pulled indique le temps nécessaire au streaming d'images pour l'extraction.

   • L'événement ImageStreaming montre que le nœud utilise le streaming d'images pour diffuser l'image de conteneur.

Comparer les performances avec des extractions d'images standards

Dans cet exemple facultatif, vous créez un cluster avec le streaming d'images désactivé et vous déployez frontend pour comparer les performances avec le streaming d'images.

1. Créez un cluster avec le streaming d'images désactivé :

   gcloud container clusters create CLUSTER2_NAME\
       --zone=COMPUTE_ZONE \
       --image-type="COS_CONTAINERD"
   

2. Obtenez les identifiants du cluster :

   gcloud container clusters get-credentials CLUSTER2_NAME \
       --zone=COMPUTE_ZONE
   

3. Déployez le frontend de l'exemple précédent :

   kubectl apply -f frontend-deployment.yaml
   

4. Obtenez le journal des événements Kubernetes :

   kubectl get events --all-namespaces
   

   Le résultat ressemble à ce qui suit :

    NAMESPACE  LAST SEEN  TYPE    REASON     OBJECT                             MESSAGE
    default    87s        Normal  Pulled     pod/frontend-64bcc69c4b-qwmfp      Successfully pulled image "us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5" in 23.929723476s
   

   Notez le temps nécessaire à GKE pour extraire l'image entière. Dans cet exemple de résultat, GKE a besoin de près de 24 secondes. Lorsque le streaming d'images est activé, GKE n'a besoin que de 1,5 seconde pour extraire les données d'image dont la charge de travail a besoin pour démarrer.

Effectuer un nettoyage

Pour éviter des frais, supprimez les clusters que vous avez créés dans les exemples précédents :

gcloud container clusters delete CLUSTER_NAME CLUSTER2_NAME

Désactiver le streaming d'images

Si vous utilisez GKE Autopilot, vous ne pouvez pas désactiver le streaming d'images sur des clusters individuels. Vous pouvez désactiver l'API Container File System, ce qui désactive le streaming d'images pour l'ensemble du projet.

Si vous utilisez des clusters GKE Standard, vous pouvez désactiver le streaming d'images sur des clusters individuels ou sur des pools de nœuds spécifiques, comme décrit dans les sections suivantes.

Désactiver le streaming d'images sur un cluster GKE Standard

Vous pouvez désactiver le streaming d'images sur des clusters GKE Standard existants en utilisant gcloud CLI ou la console Google Cloud.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-image-streaming

Sur un nouveau pool de nœuds

Pour désactiver le streaming d'images lors de la création d'un pool de nœuds, spécifiez l'option --no-enable-image-streaming, comme dans la commande suivante :

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --no-enable-image-streaming

Sur un pool de nœuds existant

Pour désactiver le streaming d'images sur un pool de nœuds existant, exécutez la commande suivante :

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --no-enable-image-streaming

Réservation de mémoire pour le streaming d'images

GKE réserve des ressources mémoire pour le streaming d'images en plus de la mémoire réservée aux composants du système de nœuds à exécuter. GKE ne réserve pas de ressources de processeur supplémentaires pour le streaming d'images. Dans les clusters GKE Standard, cette réservation modifie les ressources de mémoire que vous pouvez demander dans vos pods. Dans GKE Autopilot, GKE gère les allocations système. Il n'y a donc aucun impact sur la planification de vos charges de travail.

Pour en savoir plus sur les réservations de mémoire effectuées par GKE pour les composants de nœud, consultez la page Architecture d'un cluster standard.

Dans les nœuds qui utilisent le streaming d'images, GKE effectue les réservations de mémoire supplémentaires suivantes pour les nouvelles réservations :

• Aucune mémoire supplémentaire pour les machines dotées de moins de 1 Gio de mémoire
• 1 % des 4 premiers Gio de mémoire
• 0,8 % des 4 Gio de mémoire suivants (jusqu'à 8 Gio)
• 0,4 % des 8 Gio de mémoire suivants (jusqu'à 16 Gio)
• 0,24 % des 112 Gio de mémoire suivants (jusqu'à 128 Gio)
• 0,08 % de toute la mémoire au-delà de 128 Gio

Dépannage

GKE n'utilise pas le système de fichiers du streaming d'images

Si le journal des événements GKE n'affiche pas les événements de streaming d'images, l'image n'est pas sauvegardée par le système de fichiers distant. Si GKE a déjà extrait l'image du nœud, ce comportement est normal, car il utilise le cache local de l'image pour les extractions suivantes au lieu d'utiliser le streaming d'images. Vous pouvez le vérifier en recherchant Container image IMAGE_NAME already present on machine dans le champ Message de l'événement Pulled du pod.

Si vous ne voyez pas l'événement de streaming d'images lors de la première extraction de l'image sur le nœud, assurez-vous de remplir les conditions requises pour le streaming d'images. Si vous remplissez les conditions requises, vous pouvez diagnostiquer le problème en consultant les journaux du service de streaming d'images (nommé gcfsd) :

1. Accédez à l'explorateur de journaux dans la console Google Cloud :

   Accéder à l'explorateur de journaux

2. Dans le champ Requête, saisissez la requête suivante :

   logName="projects/PROJECT_ID/logs/gcfsd"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   Remplacez les éléments suivants :

   • PROJECT_ID : le nom de votre projet
   • CLUSTER_NAME : le nom du cluster

3. Cliquez sur Exécuter la requête.

Vous pouvez également consulter les journaux gcfsd à l'aide de l'explorateur de journaux :

1. Accédez à l'explorateur de journaux dans la console Google Cloud :

   Accéder à l'explorateur de journaux

2. Dans le champ Requête, saisissez la requête suivante :

   logName="projects/PROJECT_ID/logs/gcfsd"
   

   Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

PermissionDenied

Si les journaux gcfsd affichent un message d'erreur semblable à celui-ci, le nœud ne dispose pas du champ d'application d'API approprié. GKE extrait des images de conteneurs pour des charges de travail sans utiliser le streaming d'images.

level=fatal msg="Failed to create a Container File System client: rpc error:
code = PermissionDenied desc = failed to probe endpoint: rpc error: code = PermissionDenied
desc = Request had insufficient authentication scopes."

Pour résoudre ce problème, attribuez le champ d'application approprié au nœud afin de lui permettre d'utiliser le streaming d'images. Ajoutez le champ d'application devstorage.read_only au cluster ou au pool de nœuds, comme décrit ci-dessous :

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --image-type="COS_CONTAINERD" \
    --enable-image-streaming \
    --scope="https://www.googleapis.com/auth/devstorage.read_only"

FailedPrecondition

Si le message d'erreur affiche code = FailedPrecondition, l'image n'a pas été importée dans le système de fichiers distant du streaming d'images.

Cette erreur peut se produire si vous essayez d'utiliser le streaming d'images avec un pool de nœuds existant. Si un nœud du pool de nœuds dispose déjà de l'image de conteneur sur le disque, GKE utilise l'image locale au lieu du streaming d'images pour obtenir l'image.

Pour résoudre ce problème, procédez comme suit :

• Attendez quelques minutes, puis réessayez de déployer votre charge de travail.
• Ajoutez des nœuds ou un pool de nœuds, et planifiez la charge de travail sur ces nœuds.

InvalidArgument

Si le message d'erreur affiche code=InvalidArgument, l'image de conteneur utilisée par votre charge de travail n'est pas compatible avec le streaming d'images. Vérifiez que l'image répond aux exigences. Si votre image ne se trouve pas dans Artifact Registry, essayez de migrer vers Artifact Registry.

backend.FileContent failed

L'erreur suivante peut se produire lors de la lecture de fichiers de conteneur avec le streaming d'images activé :

level=error msg="backend.FileContent failed" error="rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Content requests per project per region' and limit 'Content requests per project per region per minute per region' of service 'containerfilesystem.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'." layer_id="sha256:1234567890" module=gcfs_backend offset=0 path=etc/passwd size=4096

Cette erreur indique que le projet a dépassé le quota requis pour lire les fichiers du service de système de fichiers du conteneur distant. Pour résoudre ce problème, augmentez les quotas suivants :

• Requêtes de contenu par projet et par région, par minute et par région
• Requêtes de contenu par projet et par région

GKE télécharge l'image sans diffuser les données

Les images de conteneurs utilisant des clés de chiffrement gérées par le client (CMEK) ne sont éligibles que pour le streaming d'images sur GKE version 1.25.3-gke.1000 ou ultérieure. Les images de conteneurs avec des couches en double ne sont pas éligibles au streaming d'images. Pour en savoir plus, consultez la section Limites.

Rechercher des couches vides ou en doubles

Pour vérifier la présence de couches vides ou en double dans l'image de conteneur, exécutez la commande suivante :

docker inspect IMAGE_NAME

Remplacez IMAGE_NAME par le nom de l'image de conteneur.

Dans le résultat de la commande, inspectez les entrées sous "Layers".

Si l'une des entrées correspond exactement à la sortie "sha256" suivante, l'image de conteneur comporte une couche vide et n'est pas éligible pour le streaming d'images.

"Layers": [
  ...
  "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
  ...
]

S'il existe des entrées en double, comme dans l'exemple suivant, l'image de conteneur comporte des couches en double et n'est pas éligible pour le streaming d'images.

"Layers": [
  "sha256:28699c71935fe3ffa56533db44ad93e5a30322639f7be70d5d614e06a1ae6d9b",
  ...
  "sha256:28699c71935fe3ffa56533db44ad93e5a30322639f7be70d5d614e06a1ae6d9b",
  ...
]

Échec de la commande mv et des appels système renameat2 sur les fichiers de lien symbolique

Pour les nœuds GKE exécutant les versions 1.25 ou ultérieures, lorsque le streaming d'images est activé, la commande mv et l'appel système renameat2 peuvent échouer sur les fichiers de lien symbolique dans les images de conteneur avec le message d'erreur "Aucun appareil ou adresse de ce type". Ce problème est causé par une régression sur les noyaux Linux récents.

Ces appels système ne sont pas courants. La majorité des images ne sont donc pas affectées par ce problème. Le problème se produit généralement lors des étapes d'initialisation du conteneur, lorsqu'une application est en cours d'exécution et de déplacement de fichiers. Il n'est pas possible de tester l'image localement. Par conséquent, GKE recommande d'utiliser le streaming d'images sur les environnements de test pour détecter le problème avant que l'image ne soit utilisée en production.

Le correctif est disponible dans les versions de correctif GKE suivantes :

• 1.25 : 1.25.14-gke.1351000 et versions ultérieures
• 1.26 : 1.26.9-gke.1345000 et versions ultérieures
• 1.27 : 1.27.6-gke.100 et versions ultérieures
• 1.28 : 1.28.1-gke.1157000 et versions ultérieures

Pour limiter ce problème pour les charges de travail affectées, vous pouvez également remplacer le code qui conduit à l'appel du système renameat2. Si vous ne pouvez pas modifier le code, vous devez désactiver le streaming d'images sur le pool de nœuds pour limiter le problème.