Problèmes connus de GKE

• 1.36.3-gke.1767000 et versions ultérieures

Échec des charges de travail Agent Sandbox après la mise à niveau du cluster

Le module complémentaire Agent Sandbox (agentsandbox) a fait passer ses définitions de ressources personnalisées et son API de v1alpha1 à v1beta1 à partir de la version 1.36.3-gke.1767000 de GKE. Si vous mettez à niveau un cluster exécutant Agent Sandbox à partir d'une version antérieure à la version 1.36.3-gke.1767000 sans migrer vos ressources personnalisées, les charges de travail v1alpha1 existantes ne fonctionnent pas correctement.

Solution :

Avant de mettre à niveau le plan de contrôle de votre cluster vers la version 1.36.3-gke.1767000 ou une version ultérieure, migrez vos fichiers manifestes et vos charges de travail Agent Sandbox de v1alpha1 vers v1beta1 en suivant le guide de migration d'Agent Sandbox v1alpha1 vers v1beta1.

• 1,35
• 1,36
• 1,37

• 1.35.6-gke.1250001 et versions ultérieures
• 1.36.4-gke.1391002 et versions ultérieures
• 1.37.1-gke.1187000 et versions ultérieures

Les requêtes HTTP POST de jetons provenant du serveur de métadonnées échouent avec une erreur 400 Bad Request

Les charges de travail qui utilisent la fédération d'identité de charge de travail pour GKE pour s'authentifier auprès des API Cloud de Confiance en demandant des jetons d'accès ou d'identité de compte de service au serveur de métadonnées GKE (comme /computeMetadata/v1/instance/service-accounts/default/token ou /computeMetadata/v1/instance/service-accounts/default/identity) peuvent échouer avec une erreur HTTP 400 Bad Request (INVALID_ARGUMENT).

Ce problème se produit lorsqu'une application, une bibliothèque cliente ou une API Gateway envoie une requête HTTP POST sans chaîne de certificats valide dans le corps de la requête. Dans les versions de GKE concernées, les requêtes POST adressées à ces points de terminaison de jeton sont strictement réservées aux jetons d'accès et d'ID liés. Par conséquent, les requêtes dont les charges utiles sont vides, encodées au format de formulaire ou au format JSON non valide sont rejetées.

Pour résoudre le problème, passez à la dernière version de correctif de la version mineure de n'importe quel version disponible.

Solution :

Pour résoudre ce problème, configurez votre application, votre bibliothèque cliente ou votre API Gateway de sorte qu'elle utilise la méthode GET au lieu de POST lorsque vous demandez des jetons d'accès ou d'ID au serveur de métadonnées, comme dans l'exemple suivant :

curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
    

Si votre charge de travail utilise un SDK ou une passerelle tiers (comme MuleSoft Flex Gateway, IBM App Connect ou des scripts HTTP personnalisés) qui envoie par défaut des requêtes POST aux points de terminaison du serveur de métadonnées, mettez à jour la configuration ou la bibliothèque cliente pour envoyer des requêtes GET.

• 1.33 et versions ultérieures

Pods non programmés et quota épuisé lors des mises à niveau mineures en deux étapes du plan de contrôle.

Lors des mises à niveau de version mineure en deux étapes pour les plans de contrôle dans les clusters Autopilot qui utilisent des pods à durée prolongée, de nouveaux pools de nœuds peuvent être provisionnés à l'aide de la version de nœud antérieure. L'autoscaler de cluster évalue les nœuds nouvellement provisionnés par rapport à la version mise à niveau du plan de contrôle, détecte une incompatibilité de version et applique le rejet cloud.google.com/not-target-gke-version:true. L'autoscaler de cluster bloque également le scaling à la hausse des pools de nœuds de pods à durée prolongée existants ou nouvellement créés qui utilisent l'ancienne version de nœud.

Ce comportement empêche la planification des pods et déclenche une boucle de scaling infinie. Au lieu d'effectuer un scaling à la hausse d'un pool de nœuds existant, le provisionnement automatique des nœuds crée un pool à nœud unique à chaque itération de scaling à la hausse pour s'adapter aux charges de travail en attente. Cette boucle génère des centaines de pools de nœuds vides distincts qui peuvent finir par épuiser les quotas de groupes d'instances gérés régionaux.

Solution :

Pour résoudre la boucle de scaling, effectuez manuellement la mise à niveau du plan de contrôle en exécutant la commande suivante :

gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION]

Vous pouvez également appliquer la tolérance suivante aux charges de travail concernées afin qu'elles puissent être planifiées sur les nœuds de la version antérieure :

tolerations:
- key: "cloud.google.com/not-target-gke-version"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

Les nœuds qui installent des volumes NFS accumulent les entrées d'installation et cessent de créer des conteneurs

Sur les nœuds exécutant les versions concernées, l'installation d'un volume NFS laisse des entrées supplémentaires dans la table d'installation du nœud. De plus, lorsqu'un pod utilisant un volume NFS s'arrête, les tentatives d'annulation de l'installation échouent, ce qui entraîne des tentatives répétées de la part de kubelet. Chaque nouvelle tentative ajoute des entrées à la table d'installation, ce qui entraîne une croissance continue de la table d'installation, même lorsqu'aucune nouvelle charge de travail n'est planifiée.

Lorsque la table d'installation atteint la limite du noyau, l'environnement d'exécution du conteneur ne peut plus créer de conteneurs sur ce nœud. Le nœud cesse d'exécuter de nouveaux pods, peut signaler un état NotReady et peut redémarrer à plusieurs reprises. Les pods qui utilisent des volumes NFS peuvent rester à l'état Terminating, car leurs volumes ne peuvent pas être démontés.

Dans les événements de pod et les journaux kubelet, les nœuds dans cet état signalent des erreurs semblables à celles-ci :

MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1

mount: /etc: mount(2) system call failed: No space left on device

Ce problème affecte les pools de nœuds qui installent des volumes NFS avec le pilote NFS "in-tree" Kubernetes. Les nœuds qui n'utilisent pas le pilote NFS intégré pour installer des volumes NFS ne sont pas concernés.

Solution :

Pour récupérer un nœud concerné, redémarrez-le ou recréez-le. Les entrées d'installation supplémentaires n'existent que dans l'état d'exécution du nœud. Elles sont donc effacées lorsque le nœud redémarre. Les pods bloqués à l'état Terminating après le redémarrage peuvent être supprimés à l'aide de la commande suivante :

kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0
    

Pour éviter que le problème ne se reproduise dans les clusters standards, rétrogradez les pools de nœuds qui installent des volumes NFS vers une version 1.36. Définissez une exclusion de maintenance afin que GKE ne mette pas automatiquement à niveau les pools de nœuds vers une version concernée.

Si un cluster Autopilot exécute une version concernée, utilisez l'une des options suivantes à la place :

• Si vos volumes NFS sont sauvegardés par Filestore, installez-les avec le pilote CSI Filestore au lieu du pilote NFS intégré. Le pilote CSI installe les volumes à partir de son propre conteneur et n'utilise pas le composant de nœud concerné.
• Si vous devez continuer à utiliser le pilote NFS intégré, laissez la réparation automatique des nœuds récupérer les nœuds concernés. Les clusters Autopilot réparent automatiquement les nœuds. Un nœud qui signale un état NotReady pendant environ 10 minutes est drainé et recréé, ce qui efface sa table d'installation.

Échecs de charge de travail GPU A4X Max (GB300)

La création ou la mise à niveau de pools de nœuds GKE A4X Max (a4x-maxgpu-4g-metal) vers des versions de correctif spécifiques (voir la colonne Version(s) identifiée(s)) entraîne des échecs de charge de travail GPU avec les superchips NVIDIA GB300 Grace Blackwell Ultra associés. En raison des temps de démarrage prolongés de la mémoire à haut débit (HBM) sur le matériel GB300 avec ce type de machine Bare Metal, le service de démarrage nvidia-persistenced expire. Ce délai d'expiration laisse les GPU non initialisés et génère le message d'erreur cudaErrorDeviceUnavailable(46) lorsque les pods tentent de revendiquer des ressources CUDA.

Solution :

Mettez à niveau chaque cluster et pool de nœuds concerné vers une version corrigée. GKE empêche la création de pools de nœuds A4X Max avec les versions concernées et ne met pas automatiquement à niveau les pools de nœuds vers les versions concernées. GKE n'empêche pas les mises à niveau manuelles vers les versions concernées. Toutefois, pour éviter les échecs, nous vous recommandons de ne pas passer aux versions concernées.

Solution :

Si vous ne pouvez pas effectuer la mise à niveau, supprimez tous les pools de nœuds A4X Max qui exécutent les versions concernées, puis recréez-les en utilisant une version antérieure non concernée. Notez que, comme la capacité A4X Max doit être obtenue via une réservation, vous ne perdrez aucune capacité en supprimant les pools de nœuds.

Nœuds GPU ou TPU bloqués avec des rejets impending-node-termination après la maintenance de l'hôte

Sur les clusters GKE avec des nœuds d'accélérateur (GPU ou TPU) qui exécutent les versions concernées, les nœuds peuvent rester bloqués avec les rejets cloud.google.com/impending-node-termination ou cloud.google.com/maintenance-window-started une fois la maintenance ou les réparations de l'hôte Compute Engine terminées. Lorsque l'instance de VM est redémarrée, le contrôleur de maintenance GKE peut réappliquer prématurément ces rejets si un autre événement de maintenance est planifié pour le nœud, ce qui empêche la planification de nouvelles charges de travail sur des nœuds opérationnels.

Solution :

Pour résoudre le problème de blocage, vous devez supprimer manuellement les libellés de maintenance active gérés par GKE et les rejets des nœuds concernés. Si vous ne supprimez que les rejets, le contrôleur de maintenance GKE les réappliquera automatiquement.

Pour effacer les étiquettes et les rejets, exécutez les commandes suivantes :

kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-
kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest-
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination-
kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started-
    

Remplacez NODE_NAME par le nom du nœud concerné.

• 1.33
• 1,34

Échecs d'admission de pods pour les charges de travail TPU v7 en raison d'un nombre de puces incorrect.

GKE annonce de manière incorrecte huit puces TPU pouvant être allouées pour les accélérateurs TPU v7 (tpu7x) avec une topologie 2x2x1, qui ne contient physiquement que quatre puces. Cette incohérence empêche la planification des pods pour les charges de travail TPU v7.

L'architecture à double chiplet de TPU v7 n'est pas gérée correctement dans les versions antérieures, ce qui entraîne des échecs d'admission des pods. Selon les ressources TPU demandées, les erreurs suivantes se produisent :

• Lorsque vous demandez quatre TPU (google.com/tpu: 4), le "kubelet" renvoie une erreur UnexpectedAdmissionError : "invalid TPU chip count request, you must request all 4 chips on this node together".
• Lors de la demande de huit TPU (google.com/tpu: 8), le webhook d'admission tpu-accelerator-topology-constraints refuse la demande avec l'erreur suivante : "Invalid resource requests for google.com/tpu. Elle doit être égale à l'une des valeurs [4] pour l'accélérateur tpu7x et la topologie 2x2x1".

Solution :

Pour résoudre ce problème, mettez à niveau le cluster GKE vers la version 1.34.1-gke.1829001 ou ultérieure.

Le client Lustre n'utilise pas les cartes d'interface réseau secondaires sur les nœuds à cartes d'interface réseau multiples

Sur les nœuds GKE dotés de plusieurs cartes d'interface réseau (NIC), le pilote CSI Managed Lustre est activé par défaut pour utiliser toutes les cartes d'interface réseau disponibles afin d'agréger la bande passante en répartissant le trafic de stockage TCP sur les interfaces réseau. Toutefois, en raison d'un problème connu, les clients Lustre à partir de la version 2.14.0_p249 peuvent ne pas utiliser de cartes d'interface réseau secondaires. À la place, tout le trafic de stockage TCP vers l'instance Managed Lustre est acheminé exclusivement via la carte d'interface réseau principale, ce qui empêche l'agrégation de la bande passante et limite le débit de stockage.

Solution :

Si vos charges de travail nécessitent l'agrégation de bande passante multi-NIC pour Managed Lustre, rétrogradez vos pools de nœuds vers une version de GKE antérieure à la version 1.35.3-gke.1234000, par exemple la version 1.35.2-gke.1842000.

Délai d'expiration de la connexion ou connexion refusée pour les flux redirigés vers le serveur de métadonnées GKE

Dans GKE 1.35 et versions ultérieures, les charges de travail qui utilisent Workload Identity pour s'authentifier auprès des API Google Cloud peuvent rencontrer des délais de connectivité temporaires ou des connexions refusées au serveur de métadonnées GKE immédiatement après le démarrage du nœud.

Solution :

Pour obtenir des recommandations et des solutions de contournement, consultez Résoudre les erreurs de délai d'expiration au démarrage du pod.

Échec du nettoyage du shim gVisor, journalisation de l'erreur "runsc: executable file not found in $PATH"

À chaque sortie de pod gVisor ou arrêt pour cause de mémoire insuffisante, containerd tente de supprimer le bac à sable. Cependant, le processus de nettoyage échoue parfois, consignant l'erreur exec: "runsc": executable file not found in $PATH. Cette erreur peut entraîner des problèmes tels que l'épuisement des ressources, la dégradation du réseau, une panique NodeLocalDNS, des délais d'expiration DNS ou une latence élevée lors de la création de pods.

Solution :

Mettez à niveau les nœuds GKE vers la version 1.35.1 ou une version ultérieure. Pour les clusters standards, mettez à niveau le pool de nœuds contenant les nœuds concernés. Pour les clusters Autopilot, mettez à niveau manuellement le cluster Autopilot vers la version 1.35.1 ou une version ultérieure. GKE mettra automatiquement à niveau vos nœuds pour qu'ils correspondent à la version du plan de contrôle dès que possible.

Solution :

Si vous ne pouvez pas mettre à niveau votre cluster, effectuez l'une des opérations suivantes :

• Examinez et augmentez les demandes et limites de mémoire pour les pods gVisor.
• Déployez le DaemonSet privilégié suivant pour copier le binaire runsc de /home/containerd/usr/local/sbin vers /home/kubernetes/bin :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: runsc-path
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: runsc-path
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: runsc-path
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor
      volumes:
      - name: host
        hostPath:
          path: /
      initContainers:
      - name: copy-runsc
        image: bash
        command:
        - /usr/local/bin/bash
        - -c
        - |
          set -euo pipefail
          cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin
          chmod a+rx /host/home/kubernetes/bin/runsc
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: 5Mi
            cpu: 5m
        securityContext:
          privileged: true
      containers:
      - image: gcr.io/google-containers/pause:3.2
        name: pause
    

Les volumes dynamiques reviennent au type de disque par défaut

La planification ou l'association des charges de travail utilisant des volumes dynamiques dans GKE version 1.35.0-gke.2232000 ou ultérieure peut échouer. Ce problème peut également entraîner le provisionnement des volumes à l'aide de la hd-type de remplacement (telle que hyperdisk-balanced) au lieu de la pd-type, même sur les nœuds qui ne sont pas compatibles avec Hyperdisk.

Cela se produit, car le serveur de nœuds PDCSI ne parvient pas à renseigner l'objet CSINode avec les topologies de types de disques compatibles. Par conséquent, le contrôleur ne dispose pas des informations de topologie nécessaires pour faire correspondre les volumes aux nœuds compatibles.

Solution :

Passez à la version 1.35.3-gke.1290000 ou ultérieure.

• Toutes les versions de correctif antérieures à 1.34.3-gke.1208000 pour GKE 1.34
• Toutes les versions de correctif antérieures à 1.35.0-gke.2232000 pour GKE 1.35

• 1.34.3-gke.1208000 pour GKE 1.34
• 1.35.0-gke.2232000 pour GKE 1.35

Problèmes de démarrage des pods lors des mises à niveau vers GKE 1.35 pour les clusters GKE Dataplane V2

Clusters mettant à niveau le plan de contrôle vers GKE version 1.35.0-gke.2232000 et versions ultérieures à partir des versions

• Antérieure à 1.34.3-gke.1208000 pour GKE 1.34
• Antérieure à 1.35.0-gke.2232000 pour GKE 1.35

Les nouvelles charges de travail ne démarreront pas pendant le déploiement de anetd si elles sont planifiées sur un nœud avec un anetd obsolète. Pendant le déploiement, le message d'erreur suivant peut s'afficher :

Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded

Cela est dû au fait que GKE utilise l'opérateur identity-management-mode, qui nécessite que tous les agents et l'opérateur aient une vue synchronisée des libellés liés à l'identité. À partir de GKE 1.35.0-gke.2232000, les étiquettes topology.kubernetes.io sont exclues de l'ensemble d'identités pour éviter la duplication d'identités. Cette modification entraîne une incompatibilité de configuration temporaire entre le plan de contrôle mis à niveau et les agents anetd obsolètes pendant le déploiement. Pour en savoir plus, consultez la demande d'extraction Cilium.

Solution :

• Pour GKE 1.34 antérieur à 1.34.3-gke.1208000 : passez d'abord à la version 1.34.3-gke.1208000 ou ultérieure, puis à la version 1.35.0-gke.2232000 ou ultérieure.
• Pour GKE 1.35 antérieur à 1.35.0-gke.2232000 : après la mise à niveau, attendez la fin du déploiement de anetd. Pour accélérer le déploiement manuellement, supprimez les pods anetd obsolètes. Cela garantit que l'opérateur et les agents de nœud anetd disposent d'une vue synchronisée des étiquettes pertinentes pour l'identité.

• 1,32
• 1.33
• 1,34
• 1,35

• 1.32.11-gke.1153001 et versions ultérieures
• 1.33.5-gke.2326000 et versions ultérieures
• 1.34.3-gke.1214000 et versions ultérieures
• 1.35.0-gke.2180000 et versions ultérieures

Retards de programmation des pods sur les nouveaux nœuds lorsque la règle de réseau Calico est activée

Sur les clusters GKE pour lesquels la règle de réseau Calico est activée, une régression dans les versions concernées peut entraîner des retards importants dans la planification des pods sur les nœuds nouveaux ou recréés. Ces retards peuvent entraîner le maintien des nœuds à l'état NotReady pendant de longues périodes.

Le problème est dû au fait que le script de démarrage de Calico CNI ne formate pas correctement l'URL du serveur d'API Kubernetes pour les adresses IPv4 en les plaçant entre crochets ([]). Cette approche entraîne une erreur d'analyse d'URL lors de la création de bacs à sable de pods, visible dans les journaux "kubelet" :

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443"

Solution :

La version du composant Calico est déterminée par la version du plan de contrôle du cluster. Pour résoudre ce problème, mettez à niveau le plan de contrôle de votre cluster vers l'une des versions corrigées. Après avoir mis à niveau le plan de contrôle, vous devez recréer les nœuds de vos pools de nœuds pour vous assurer qu'ils utilisent le bon format d'URL du serveur d'API Kubernetes. Pour ce faire, vous pouvez effectuer une mise à niveau sur place de votre pool de nœuds vers la même version ou une version plus récente, ou recréer manuellement vos pools de nœuds.

• 1.32.8-gke.1134000 et versions ultérieures pour GKE 1.32
• 1.33.3-gke.1392000 et versions ultérieures pour GKE 1.33
• Toutes les versions de correctif pour GKE 1.34 et 1.35

• 1.32.11-gke.1075000 et versions ultérieures pour GKE 1.32
• 1.33.5-gke.2392000 et versions ultérieures pour GKE 1.33
• 1.34.3-gke.1318000 et versions ultérieures pour GKE 1.34
• 1.35.0-gke.2398000 et versions ultérieures pour GKE 1.35

Baisse des performances de la mise en réseau à usage général sur les types de machines GPU des séries A et G4

Les clusters GKE avec des nœuds GPU de série A et G4 présentent des performances dégradées pour la mise en réseau à usage général sur GKE 1.32.8-gke.1134000 et versions ultérieures pour GKE 1.32, et sur GKE 1.33.3-gke.1392000 et versions ultérieures. La dégradation des performances sur la mise en réseau à usage général affecte les types de machines GPU, y compris les séries de machines A3, A4, A4X et G4. Notez que GPUDirect-TCPXO sur A3 Mega et GPUDirect-RDMA sur A3 Ultra, A4 et A4X ne sont pas concernés.

Cela se produit, car le script au niveau du nœud (/usr/bin/google_set_multiqueue) qui définit l'affinité d'interruption est mal configuré.

Solution :

Mettez à niveau chaque pool de nœuds concerné vers une version corrigée.

• 1.32.8-gke.1134000 et versions ultérieures pour GKE 1.32
• 1.33.3-gke.1392000 et versions ultérieures pour GKE 1.33 et versions ultérieures

• 1.32.11-gke.1075000 et versions ultérieures pour GKE 1.32
• 1.33.5-gke.2392000 et versions ultérieures pour GKE 1.33

Baisse des performances de GPUDirect-TCPX sur A3 High

Les clusters GKE avec des nœuds A3 High (a3-highgpu-8g) présentent des performances dégradées lors de l'utilisation de GPUDirect-TCPX sur GKE 1.32.8-gke.1134000 et versions ultérieures pour GKE 1.32, et sur GKE 1.33.3-gke.1392000 et versions ultérieures.

Cela se produit, car le script au niveau du nœud (/usr/bin/google_set_multiqueue) qui définit l'affinité d'interruption est mal configuré.

Solution :

Pour les pools de nœuds GKE 1.32, mettez à niveau les versions des pools de nœuds GKE vers la version 1.32.11-gke.1075000 ou une version ultérieure. Pour les pools de nœuds GKE 1.33 et versions ultérieures, mettez à niveau les versions des pools de nœuds GKE vers la version 1.33.5-gke.2392000 ou ultérieure. Pour les pools de nœuds GKE 1.34, consultez GPUDirect-TCPX n'est pas disponible avec A3 High pour GKE version 1.34 et ultérieure.

1.35.0-gke.2232000 et versions ultérieures.

Duplication d'identité Cilium dans les clusters GKE Dataplane V2

Les clusters GKE exécutant la version 1.35 avec GKE Dataplane V2 activé peuvent connaître une augmentation du nombre de ressources personnalisées ciliumidentities.cilium.io. Ce problème est dû à l'ajout d'étiquettes topology.kubernetes.io aux pods dans Kubernetes 1.35, ce qui génère des identités Cilium supplémentaires pour chaque zone dans laquelle un pod d'une charge de travail est planifié.

Dans les clusters régionaux et zonaux, la planification d'une nouvelle charge de travail peut entraîner une duplication temporaire de l'identité Cilium. Cette duplication se produit, car les pods obtiennent une identité au moment de la création en fonction des étiquettes initiales, et une autre identité après l'ajout des étiquettes de topologie lorsque le pod est planifié sur un nœud. Dans les clusters régionaux, le nombre d'identités peut également augmenter d'un facteur proportionnel au nombre de zones couvertes par le cluster.

Impact :

Si le nombre total d'identités dépasse 65 535, la planification des nouvelles charges de travail peut échouer.

Solution :

Pour limiter le nombre total d'identités, évitez d'ajouter des étiquettes avec un grand nombre de valeurs uniques à vos pods.

Pour en savoir plus, consultez la documentation Cilium suivante :

• Sécurité basée sur l'identité
• Identités de sécurité

Les mises à niveau manuelles doivent être effectuées à partir de la version 1.34.3-gke.1208000 ou ultérieure. Si vous lancez la mise à niveau à partir d'une version antérieure à la version 1.34.3-gke.1208000, vous risquez de rencontrer des problèmes temporaires de planification des pods pendant le processus de mise à niveau.

• Versions de correctif 1.34 antérieures à 1.34.5-gke.1153000
• Versions de correctif 1.35 antérieures à 1.35.2-gke.1485000

• 1.34.5-gke.1153000 et versions ultérieures
• 1.35.2-gke.1485000 et versions ultérieures
• 1.36 et versions ultérieures

Vous devez également utiliser le programme d'installation GPUDirect-TCPX version 3.1.9 ou ultérieure et le side-car version 2.0.12 ou ultérieure. Les versions du programme d'installation et du side-car ont un mappage de type "un à un" et doivent correspondre. Par exemple, la version 3.1.12 du programme d'installation GPUDirect-TCPX correspond à la version 2.0.15 du side-car. Pour en savoir plus sur les versions du programme d'installation et du side-car, consultez les notes de version de GPUDirect-TCPX.

GPUDirect-TCPX n'est pas disponible avec A3 High pour certaines versions de GKE

Les clusters GKE avec des nœuds A3 High (a3-highgpu-8g) utilisent GPUDirect-TCPX pour maximiser la bande passante réseau des GPU. Pour les nœuds qui utilisent TCPX et A3 High, la mise à niveau vers les versions de GKE concernées peut entraîner des problèmes de fonctionnement ou de performances avec TCPX. En effet, TCPX n'est pas compatible avec le noyau Linux 6.12 mis à jour utilisé par Container-Optimized OS version 125 ou ultérieure. La version 125 est utilisée par GKE version 1.34.

Les autres types de machines GPU A3 High (a3-highgpu-1g, a3-highgpu-2g, a3-highgpu-4g) et les autres séries de machines GPU ne sont pas concernés, car ils ne sont pas compatibles avec GPUDirect-TCPX.

Solution :

Pour résoudre ce problème, effectuez une mise à niveau vers les correctifs de version GKE corrigés. Pour en savoir plus sur la configuration et la mise à niveau des pools de nœuds avec GPUDirect-TCPX, consultez Maximiser la bande passante réseau des GPU dans les clusters standards ou Maximiser la bande passante réseau des GPU dans les clusters Autopilot.

Lorsque vous exécutez des tests NCCL sur des versions fixes, les avertissements suivants peuvent s'afficher, mais ils n'ont aucune incidence sur les performances ni sur les fonctionnalités :

• Journaux NCCL WARN pour Rx Ctrl Timeouts : ce message peut s'afficher si la charge de travail publie une opération de communication Recv sur la cible bien avant de publier une opération de communication Send sur l'initiateur. Aucun impact sur les performances n'est attendu.
• Journaux d'avertissement NCCL pour No free space for recv task : ce message avertit d'un faible nombre total de tâches réseau pour traiter les opérations, ce qui entraîne l'occupation temporaire de toutes les tâches. Aucun impact sur les performances n'est attendu.

Capacité minimale d'instances mise à jour

La capacité minimale des instances Managed Lustre a été mise à jour et est désormais de 9 000 Gio. Les clusters exécutant des versions antérieures à la 1.34.0-gke.2285000 ne peuvent pas créer d'instances avec cette capacité minimale via le pilote CSI Managed Lustre.

Solution :

Mettez à niveau votre cluster vers la version 1.34.0-gke.2285000 ou une version ultérieure pour permettre la création d'instances Managed Lustre avec une capacité minimale de 9 000 Gio.

L'interface utilisateur de la consoleCloud de Confiance devient non modifiable pendant la réparation automatique des nœuds

Lorsqu'un nœud GKE est en cours de réparation automatique, le pool de nœuds ne peut pas être modifié via la console Cloud de Confiance en raison d'une opération en cours.

Solution :

Vous pouvez toujours modifier la configuration du pool de nœuds à l'aide des commandes gcloud CLI.

Niveau de performances incorrect pour les instances Lustre provisionnées dynamiquement

Lors du provisionnement dynamique d'une instance Lustre, la création de l'instance échoue avec une erreur InvalidArgument pour PerUnitStorageThroughput, quelle que soit la valeur perUnitStorageThroughput spécifiée dans la requête API.

Solution :

Mettez à niveau le cluster GKE vers la version 1.33.4-gke.1036000 ou une version ultérieure. Si vous utilisez la version stable, il est possible qu'une version plus récente ne soit pas encore disponible. Dans ce cas, vous pouvez sélectionner manuellement une version du canal standard ou rapide qui inclut le correctif.

• 1.32.3-gke.1099000 et versions ultérieures
• 1.33

Erreur d'entrée/sortie lors du changement de nom ou du déplacement de fichiers à l'aide du pilote CSI Cloud Storage FUSE

Lorsque vous utilisez une version concernée du pilote CSI Cloud Storage FUSE, le changement de nom ou le déplacement de fichiers dans des buckets Cloud Storage peut échouer avec une erreur d'E/S.

Solution :

Ajoutez temporairement une définition d'image side-car spécifique à votre fichier manifeste de pod. Dans la section spec.containers du fichier manifeste de votre pod, ajoutez la définition de conteneur suivante avec l'image gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2.

    # Add the following block to use the fixed sidecar image
    - name: gke-gcsfuse-sidecar
      image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2
    

Pour en savoir plus, consultez le fichier manifeste du pod dans Configurer une image privée pour le conteneur side-car.

Après avoir mis à niveau votre cluster vers une version de GKE corrigée ou ultérieure, vous devez supprimer l'intégralité du bloc gke-gcsfuse-sidecar de votre fichier manifeste. Une fois ce bloc supprimé, GKE recommencera à injecter et à gérer automatiquement l'image side-car appropriée pour la version mise à niveau de votre cluster.

Condition de concurrence dans les DaemonSets gke-metrics-agent

Lorsque vous ajoutez l'étiquette cloud.google.com/gke-metrics-agent-scaling-level à un pool de nœuds pour augmenter manuellement l'allocation de mémoire du DaemonSet gke-metrics-agent, une condition de concurrence se produit dans le DaemonSet lors de la création d'un nœud. Cette condition de concurrence entraîne des redémarrages intermittents et peut entraîner la perte de métriques.

Ce problème se produit, car il y a un délai avant que l'étiquette ne soit ajoutée à un nouveau nœud dans le pool de nœuds. Pendant ce délai, le DaemonSet crée un pod avec l'allocation de mémoire d'origine sur ce nœud. Une fois l'étiquette appliquée, le DaemonSet crée un pod avec la nouvelle allocation de mémoire. Le pod existant n'est pas complètement supprimé lorsque le pod mis à jour démarre. Ces deux pods tentent de se lier au même numéro de port.

Solution :

Après avoir ajouté l'étiquette cloud.google.com/gke-metrics-agent-scaling-level à un pool de nœuds, redémarrez le DaemonSet gke-metrics-agent :

kubectl -n kube-system rollout restart daemonset gke-metrics-agent

Limite de fichiers ouverts réduite avec containerd 2.0

Pour les pools de nœuds exécutant GKE version 1.33, qui utilise containerd 2.0, la limite souple par défaut pour les fichiers ouverts (ulimit -n) pour les conteneurs est abaissée à 1 024.

Il s'agit d'un changement dans containerd lui-même (voir la demande d'extraction containerd 8924) où LimitNOFILE a été supprimé de containerd.service conformément aux bonnes pratiques, ce qui entraîne l'application de la limite logicielle par défaut du système.

Les charges de travail qui s'attendent à une limite souple par défaut plus élevée (par exemple, celles qui s'appuient implicitement sur la limite par défaut plus élevée précédente) peuvent rencontrer des défaillances, telles que des erreurs Too many open files.

Solution :

Passez d'une version de correctif 1.33 antérieure à la version 1.33.2-gke.1043000 ou ultérieure.

Solution :

Augmentez la limite de fichiers ouverts pour vos charges de travail à l'aide de l'une des méthodes suivantes :

• Ajustement au niveau de l'application : modifiez le code ou la configuration de l'application pour définir explicitement ulimit -n ou prlimit --nofile=524288.
• Plug-in Containerd NRI Ulimit Adjuster  : utilisez le plug-in containerd/nri ulimit-adjuster pour ajuster la limite ulimit.
• Rétrograder le pool de nœuds (Standard uniquement) : pour les clusters GKE Standard, vous pouvez temporairement rétrograder votre pool de nœuds vers la version 1.32 afin d'éviter ce problème jusqu'à ce qu'une solution permanente soit disponible.

"status.storedVersions" non valide pour les CRD gérées

Certaines CRD gérées par GKE peuvent comporter un champ status.storedVersions non valide, ce qui risque d'interrompre l'accès aux objets CRD après une mise à niveau.

Ce problème affecte les clusters qui répondent aux deux conditions suivantes :

• Clusters ayant utilisé une version de GKE concernée à un moment donné.
• Clusters contenant des versions non compatibles (served=false) d'objets CRD stockés dans etcd.

Solution :

La solution recommandée consiste à retarder les mises à niveau du cluster jusqu'à ce que le problème soit résolu.

Si vous savez que votre cluster contient des versions non compatibles d'objets CRD, vous pouvez ajouter ces versions au champ status.storedVersions à l'aide de la commande kubectl patch.

• 1.32.2-gke.1652003 ou versions ultérieures
• 1.31.6-gke.1221001 ou version ultérieure
• 1.30.10-gke.1227001 ou version ultérieure

Métriques manquantes ou autoscaler de charge de travail n'effectuant pas de scaling

Vous pouvez observer des écarts dans les données de métriques sur les versions concernées après que la taille du cluster a augmenté de plus de cinq nœuds. Ce problème peut également avoir un impact sur les opérations d'autoscaling.

Ce problème ne concerne que les clusters mis à niveau vers les versions concernées. Les clusters nouvellement créés devraient fonctionner comme prévu.

Solution :

Si vous êtes concerné, vous pouvez revenir à une version de correctif antérieure ou passer à une version corrigée plus récente.

Limites de taille et d'association des volumes Google Cloud Hyperdisk

En règle générale, un pod qui ne peut pas être planifié en raison des limites d'association de volumes d'un nœud déclenche le provisionnement automatique d'un nouveau nœud. Lorsque des charges de travail utilisant un produit Hyperdisk sont planifiées sur un nœud qui exécute une VM C3, le provisionnement automatique des nœuds n'a pas lieu et le pod est planifié sur le nœud déjà plein.

La charge de travail est planifiée sur le nœud malgré l'absence de rattachement de disque disponible. La charge de travail ne démarre pas non plus, en raison d'une erreur semblable à celle-ci :

 AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17]

Le problème est présent pour tous les produits Hyperdisk sur les machines C3.

Les limites d'association d'Hyperdisk varient en fonction du nombre de processeurs virtuels de la VM et du produit Hyperdisk. Pour en savoir plus, consultez Limites de performances des volumes Hyperdisk.

Solution :

Les produits Google Cloud Hyperdisk déclenchent le provisionnement automatique sur d'autres formes de VM. Nous vous recommandons une forme qui n'est compatible qu'avec Google Cloud Hyperdisk.

gke-metadata-server est arrêté par OOMKilled sur les nœuds TPU/GPU

Sur les nœuds TPU GKE (par exemple, ct4p-hightpu-4t) et les nœuds GPU (par exemple, a3-highgpu-8g), le noyau peut arrêter le gke-metadata-server avec un OOMKilled lorsque l'utilisation de la mémoire du serveur dépasse 100 Mo.

Solution :

Si vous observez des événements OOMKilled pour gke-metadata-server sur des nœuds TPU ou GPU, contactez l'équipe d'astreinte GKE Identity (ID du composant : 395450) pour connaître les options de correction.

• 1.32.0-gke.1358000 à 1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001, 1.32.4-gke.1533000
• 1.33.0-gke.0 à 1.33.0-gke.1552000

• 1.32.4-gke.1353003 et versions ultérieures
• 1.33.0-gke.1552000 et versions ultérieures

Les redimensionnements de volume peuvent être bloqués en raison de l'état NodePendingResize en attente sur les PVC.

Les clusters de la version 1.32 dont les nœuds sont de la version 1.31 ou d'une version antérieure ne parviendront pas à mettre à jour l'état PersistentVolumeClaim lors du redimensionnement. Cet état incorrect empêche le démarrage des opérations de redimensionnement ultérieures, ce qui empêche tout redimensionnement supplémentaire.

Un PVC dans cet état comporte un champ status.allocatedResourceStatuses qui contient NodePendingResize ou les champs status.allocatedResources et status.conditions.type: FileSystemResizePending.

Si un PVC a été créé alors que votre cluster était sur une version concernée, vous pouvez voir ce problème persister après la mise à niveau de votre cluster vers une version corrigée connue. Dans ce scénario, vous devez appliquer un correctif à votre PVC pour supprimer le champ status.allocatedResources à l'aide d'une solution de contournement ponctuelle.

Solution :

Les PVC bloquées en raison d'un état "en attente" peuvent être corrigées pour supprimer cet état. Vous pouvez utiliser une commande de correctif comme celle-ci pour supprimer l'état "en attente" :

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'

• 1.32.4-gke.1236007, 1.32.4-gke.1353001

• 1.32.4-gke.1353003 et versions ultérieures

Le pilote PDCSI peut consigner des journaux de manière excessive

Les clusters GKE exécutant certaines versions de la version 1.32 peuvent émettre un nombre excessif de messages de journal provenant du pilote PDCSI. Cette journalisation excessive consommerait le quota de l'API d'écriture Cloud Logging.

Solution :

Vous pouvez réduire cette journalisation excessive en ajoutant un filtre d'exclusion. Pour exclure les messages de journal de l'ingestion dans Cloud Logging, utilisez la requête suivante :

      resource.type="k8s_container"
      resource.labels.container_name="gce-pd-driver"
      (sourceLocation.file="cache.go" OR "Cannot process volume group")
    

• 1.27.16-gke.2440000 et versions ultérieures
• 1.28.15-gke.1673000 et versions ultérieures
• 1.29.13-gke.1038000 et versions ultérieures
• 1.30.9 et versions ultérieures
• 1.31.7 et versions ultérieures
• 1.32.1-gke.1357001 et versions ultérieures

• 1.27.16-gke.2691000 et versions ultérieures
• 1.28.15-gke.2152000 et versions ultérieures
• 1.29.15-gke.1218000 et versions ultérieures
• 1.30.11-gke.1190000 et versions ultérieures
• 1.31.7-gke.1363000 et versions ultérieures
• 1.32.4-gke.1106000 et versions ultérieures
• 1.33.0-gke.1552000 et versions ultérieures

Les pods qui tentent d'installer des volumes persistants NFS sur des nœuds COS qui disposaient auparavant d'un montage en lecture seule (RO) ne seront installés qu'en mode RO.

Pour GKE version 1.27 et ultérieures, les volumes NFS utilisant le pilote CSI Kubernetes intégré ne peuvent installer des volumes persistants en mode RO qu'après une installation RO précédente sur le même nœud.

Solution :

Rétrogradez les pools de nœuds vers une version antérieure aux versions concernées.

• Versions 1.32 de 1.32.1-gke.1357001 à 1.32.4-gke.1106000 (non incluse)
• Toutes les versions 1.33 antérieures à 1.33.0-gke.1552000

• 1.32 : 1.32.4-gke.1106000 et versions ultérieures
• Version 1.33 : 1.33.0-gke.1552000 et versions ultérieures

Les pods qui tentent d'installer des volumes persistants NFS sur des nœuds Ubuntu ne pourront pas s'exécuter.

Pour GKE 1.32 et versions ultérieures, les volumes NFS utilisant le pilote CSI Kubernetes intégré ne pourront pas installer de volumes persistants sur les nœuds Ubuntu. Dans ce cas, les messages d'erreur suivants peuvent s'afficher :

"MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1"

Output: Mount failed: mount failed: exit status 127

"Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes"

En plus de ces messages d'erreur, les pods utilisant ces volumes ne pourront pas démarrer.

Solution :

Revenir à une version antérieure des pools de nœuds (version 1.31).

• 1.28.15-gke.1668000 ou versions ultérieures
• 1.29.13-gke.1028000 ou versions ultérieures
• 1.30.8-gke.1287000 ou versions ultérieures
• 1.31.6-gke.1020000 ou versions ultérieures
• 1.32.1-gke.1369000 ou versions ultérieures

Les pods utilisant des appels système liés à io_uring peuvent être bloqués à l'état "Terminating"

Les pods qui utilisent des appels système liés à io_uring peuvent passer à l'état D (veille du disque), également appelé TASK_UNINTERRUPTIBLE, en raison d'un bug dans le noyau Linux. Les processus à l'état D ne peuvent pas être réveillés par des signaux, y compris SIGKILL.

Lorsqu'un pod est concerné par ce problème connu, ses conteneurs peuvent ne pas s'arrêter normalement. Dans les journaux containerd, vous pouvez observer des messages répétés semblables à celui-ci : Kill container [container-id], indiquant que le système tente de manière répétée d'arrêter un conteneur.
Simultanément, les journaux kubelet affichent des messages d'erreur, tels que les suivants :

"Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded"

ou

"Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid"

Ces symptômes indiquent que des processus du conteneur sont bloqués dans un état de veille ininterrompue (état D), ce qui empêche l'arrêt correct du pod.

Les charges de travail qui utilisent io_uring directement ou indirectement via un environnement d'exécution de langage tel que NodeJS peuvent être affectées par ce problème connu. Les charges de travail concernées ont un processus à l'état D (veille du disque) dans le fichier /proc/<pid>/state et affichent la chaîne io_uring dans le contenu de /proc/<pid>/stack. Les charges de travail Node.js peuvent désactiver l'utilisation d'io_uring via UV_USE_IO_URING=0.

Solution :

Mettez à niveau les nœuds du cluster vers une version corrigée ou ultérieure.

• 1.30.8-gke.1261000 et versions ultérieures
• 1.31.4-gke.1183000 et versions ultérieures
• 1.32.0-gke.1448000 et versions ultérieures

Les charges de travail utilisant le streaming d'images échouent avec des erreurs d'authentification

Un bug dans la fonctionnalité de streaming d'images peut entraîner l'échec des charges de travail lorsqu'un ensemble de conditions spécifiques est rempli pendant que le conteneur lit des fichiers. Les messages d'erreur liés aux échecs d'authentification peuvent être visibles dans le journal gcfsd.

Pour vérifier si vous êtes concerné, recherchez les journaux à l'aide de la requête de recherche suivante : resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential."

La présence de ces erreurs indique que les nœuds sont affectés.

Si vous êtes concerné par ce problème, vous pouvez mettre à niveau vos pools de nœuds vers une version corrigée de GKE.

• 1.30.0 à 1.30.5-gke.1443001
• 1.31.0 à 1.31.1-gke.1678000

• 1.30.5-gke.1628000 et versions ultérieures
• 1.31.1-gke.1846000 et versions ultérieures

Augmentation des taux d'éviction de pods sur les versions 1.30 et 1.31 de GKE

Certaines versions de GKE 1.30 et GKE 1.31 qui utilisent respectivement COS 113 et COS 117 ont des noyaux créés avec l'option CONFIG_LRU_GEN_ENABLED=y. Cette option active la fonctionnalité de noyau Multi-Gen LRU, qui entraîne une erreur de calcul de l'utilisation de la mémoire par le kubelet et peut entraîner l'éviction des pods par le kubelet.

L'option de configuration CONFIG_LRU_GEN_ENABLED est désactivée dans cos-113-18244-151-96 et cos-117-18613-0-76.

Il est possible que vous ne voyiez pas toujours un taux d'éviction de pods inhabituel, car ce problème dépend du modèle d'utilisation de la mémoire de la charge de travail. Le risque que le kubelet expulse des pods est plus élevé pour les charges de travail qui n'ont pas défini de limite de mémoire dans le champ "resources". En effet, les charges de travail peuvent demander plus de mémoire que ce que kubelet indique comme disponible.

Si vous constatez une utilisation de la mémoire plus élevée d'une application après la mise à niveau vers les versions de GKE mentionnées sans aucune autre modification, vous êtes peut-être concerné par l'option de noyau.

Pour vérifier si les taux d'éviction de pods sont inhabituels, analysez les métriques suivantes avec l'explorateur de métriques : kubernetes.io/container_memory_used_bytes et kubernetes.io/container_memory_request_bytes.

Vous pouvez utiliser les requêtes PromQL suivantes. Remplacez les valeurs de cluster_name, namespace_name, metadata_system_top_level_controller_type et metadata_system_top_level_controller_name par le nom et le type de la charge de travail que vous souhaitez analyser :

Si vous constatez des pics inhabituels d'utilisation de la mémoire qui dépassent la mémoire demandée, la charge de travail est peut-être expulsée plus souvent.

Solution

Si vous ne pouvez pas passer aux versions corrigées et que vous exécutez un environnement GKE dans lequel vous pouvez déployer des pods privilégiés, vous pouvez désactiver l'option LRU multigénérationnelle à l'aide d'un DaemonSet.

1. Mettez à jour les pools de nœuds GKE à partir desquels vous souhaitez exécuter le DaemonSet avec une annotation pour désactiver l'option LRU multigénérationnelle. Par exemple, disable-mglru: "true".
2. Mettez à jour le paramètre nodeSelector dans le fichier manifeste du DaemonSet avec la même annotation que celle utilisée à l'étape précédente. Par exemple, consultez le fichier disable-mglru.yaml dans le dépôt GoogleCloudPlatform/k8s-node-tools.
3. Déployez le DaemonSet sur votre cluster.

Une fois que le DaemonSet est exécuté dans tous les pools de nœuds sélectionnés, la modification prend effet immédiatement et le calcul de l'utilisation de la mémoire kubelet revient à la normale.

• 1.28.14-gke.1175000 et versions ultérieures
• 1.29.9-gke.1341000 et versions ultérieures
• 1.30.5-gke.1355000 et versions ultérieures
• 1.31.1-gke.1621000 et versions ultérieures

Pods bloqués à l'état "Arrêt en cours"

Un bug dans l'environnement d'exécution du conteneur (containerd) peut entraîner le blocage des pods et des conteneurs à l'état "En cours d'arrêt" avec des erreurs semblables à celles-ci :

Si vous êtes concerné par ce problème, vous pouvez mettre à niveau vos nœuds vers une version de GKE avec une version corrigée de containerd.

• 1.34 et versions antérieures
• Versions 1.35 antérieures à 1.35.6-gke.1005000
• Versions 1.36 antérieures à 1.36.0-gke.2459000

• 1.35.6-gke.1005000 et versions ultérieures
• 1.36.0-gke.2459000 et versions ultérieures

Le streaming d'images échoue en raison de liens symboliques

Un bug dans la fonctionnalité de streaming d'images peut empêcher le démarrage des conteneurs.

La création de conteneurs s'exécutant sur un nœud avec le streaming d'images activé sur des versions spécifiques de GKE peut échouer avec l'erreur suivante :

Solution :

Pour résoudre ce problème, mettez à niveau vos pools de nœuds vers une version corrigée (1.35.6-gke.1005000 ou ultérieure, ou 1.36.0-gke.2459000 ou ultérieure).

Si vous ne pouvez pas effectuer de mise à niveau, vous pouvez rechercher des couches vides ou en double. Si vous ne parvenez pas à supprimer les couches vides ou en double, désactivez le streaming d'images.

• 1.28.9-gke.1103000 et versions ultérieures
• 1.29.4-gke.1202000 et versions ultérieures
• 1.30 : toutes les versions

Échec du streaming d'images en raison de fichiers manquants

Un bug dans la fonctionnalité de streaming d'images peut entraîner l'échec des conteneurs en raison d'un ou de plusieurs fichiers manquants.

Les conteneurs exécutés sur un nœud pour lequel le streaming d'images est activé sur les versions suivantes peuvent ne pas démarrer ou s'exécuter avec des erreurs indiquant que certains fichiers n'existent pas. Voici quelques exemples de ces erreurs :

• No such file or directory
• Executable file not found in $PATH

Si vous êtes concerné par ce problème, vous pouvez désactiver le streaming d'images.

Erreur de configuration TLS de la passerelle

Nous avons identifié un problème de configuration de TLS pour les passerelles dans les clusters exécutant GKE version 1.28.4-gke.1083000. Cela affecte les configurations TLS utilisant un SSLCertificate ou un CertificateMap. Si vous mettez à niveau un cluster avec des passerelles existantes, les mises à jour apportées à la passerelle échoueront. Pour les nouvelles passerelles, les équilibreurs de charge ne seront pas provisionnés. Ce problème sera résolu dans une prochaine version de correctif GKE 1.28.

Problème lié au plug-in d'appareil GPU

Les clusters qui exécutent des GPU et qui sont mis à niveau de la version 1.26 vers une version de correctif 1.27 antérieure à la version 1.27.8 peuvent rencontrer des problèmes avec les plug-ins d'appareil GPU de leurs nœuds (nvidia-gpu-device-plugin). Procédez comme suit en fonction de l'état de votre cluster :

• Si votre cluster exécute la version 1.26 et dispose de GPU, ne le mettez pas à niveau manuellement tant que la version 1.27.8 n'est pas disponible dans le version disponible de votre cluster.
• Si votre cluster exécute une version de correctif 1.27 antérieure et que les nœuds sont affectés, redémarrez les nœuds ou supprimez manuellement le pod nvidia-gpu-device-plugin sur les nœuds (le gestionnaire de modules complémentaires créera un plug-in de travail).
• Si votre cluster utilise les mises à niveau automatiques, cela ne vous concerne pas, car les mises à niveau automatiques ne déplacent les clusters que vers des versions de correctif contenant le correctif.

• 1.27.5-gke.1300 et versions ultérieures
• 1.28.1-gke.1400 et versions ultérieures

L'autoscaling s'arrête pour toutes les charges de travail

HorizontalPodAutoscaler (AHP) et VerticalPodAutoscaler (VPA) peuvent arrêter l'autoscaling de toutes les charges de travail d'un cluster s'il contient des objets AHP autoscaling/v2 mal configurés. Le problème affecte les clusters exécutant des versions de correctif antérieures de GKE 1.27 et 1.28 (par exemple, 1.27.3-gke.100).

Solution :

Corrigez les objets AHP autoscaling/v2 mal configurés en vous assurant que les champs de spec.metrics.resource.target correspondent, par exemple :

• Lorsque spec.metrics.resource.target.type est Utilization, la cible doit être averageUtilization.
• Lorsque spec.metrics.resource.target.type est AverageValue, la cible doit être averageValue.

Pour en savoir plus sur la configuration des objets AHP autoscaling/v2, consultez la documentation Kubernetes sur HorizontalPodAutoscaler.

• 1.28.7-gke.1026000
• 1.29.2-gke.1060000

Échec du déploiement de Container Threat Detection

Container Threat Detection peut ne pas se déployer sur les clusters Autopilot exécutant les versions de GKE suivantes :

• 1.28.6-gke.1095000 à 1.28.7-gke.1025000
• 1.29.1-gke.1016000 à 1.29.1-gke.1781000

• 1.30.4-gke.1282000 ou versions ultérieures
• 1.29.8-gke.1157000 ou versions ultérieures
• 1.28.13-gke.1078000 ou versions ultérieures
• 1.27.16-gke.1342000 ou versions ultérieures

Problèmes de connectivité pour les pods hostPort après la mise à niveau du plan de contrôle

Les clusters pour lesquels une règle de réseau est activée peuvent rencontrer des problèmes de connectivité avec les pods hostPort. De plus, les pods nouvellement créés peuvent prendre 30 à 60 secondes supplémentaires pour être prêts.

Le problème se produit lorsque le plan de contrôle GKE d'un cluster est mis à niveau vers l'une des versions GKE suivantes :

• 1.30 à 1.30.4-gke.1281999
• 1.29.1-gke.1545000 à 1.29.8-gke.1156999
• 1.28.7-gke.1042000 à 1.28.13-gke.1077999
• 1.27.12-gke.1107000 à 1.27.16-gke.1341999

Solution :

Mettez à niveau ou recréez les nœuds immédiatement après la mise à niveau du plan de contrôle GKE.

• 1.32.1-gke.1729000 ou versions ultérieures
• 1.31.6-gke.1020000 ou versions ultérieures

Trafic UDP interrompu entre les pods qui s'exécutent sur le même nœud

Les clusters pour lesquels la visibilité intranœud est activée peuvent rencontrer des problèmes de trafic UDP entre les pods qui s'exécutent sur le même nœud.

Le problème se produit lorsque le nœud du cluster GKE est mis à niveau vers l'une des versions GKE suivantes ou créé avec l'une d'elles :

• 1.32.1-gke.1729000 ou versions ultérieures
• 1.31.6-gke.1020000 ou versions ultérieures

Le chemin d'accès concerné est le trafic UDP entre pods sur le même nœud via Hostport ou Service.

Solution

Mettez à niveau le cluster vers l'une des versions corrigées suivantes :

• 1.32.3-gke.1927000 ou versions ultérieures
• 1.31.7-gke.1390000 ou versions ultérieures

• 1.29.10-gke.1071000 ou versions ultérieures
• 1.30.5-gke.1723000 ou versions ultérieures
• 1.31.2-gke.1115000 ou versions ultérieures

Incompatibilité entre l'opérateur Ray et le chiffrement de la base de données Cloud KMS

Certaines versions de l'opérateur Ray ne sont pas compatibles avec le chiffrement de base de données Cloud KMS.

Solutions :

Mettez à niveau le plan de contrôle du cluster vers une version corrigée ou ultérieure.

• 1.30.8-gke.1051000 ou versions ultérieures
• 1.31.1-gke.2008000 et versions ultérieures

Le pod du gestionnaire de maintenance des GPU est bloqué à l'état CrashLoopBackOff

Avec ce problème, les pods gpu-maintenance-handler sont bloqués à l'état "CrashLoopBackOff" sur leurs nœuds respectifs. Cet état empêche l'application de l'étiquette "upcoming maintenance" aux nœuds GKE, ce qui peut avoir un impact sur les processus de drainage des nœuds et d'éviction des pods pour les charges de travail.

Si vous êtes concerné par ce problème, vous pouvez le résoudre en mettant à niveau votre plan de contrôle vers une version de GKE incluant le correctif.

Les pods ne démarrent pas sur les nœuds pour lesquels le streaming d'images est activé

Sur les nœuds où le streaming d'images est activé, les charges de travail peuvent ne pas démarrer avec la signature d'erreur suivante : Failed to create pod sandbox ... context deadline exceeded

Les journaux du port série d'un nœud concerné contiennent également la signature d'erreur suivante : task gcfsd ... blocked for more than X seconds

La présence de ces deux signatures d'erreur indique un blocage dans l'un des composants de streaming d'images. Ce blocage empêche les pods de démarrer correctement.

Atténuation :

Redémarrez le nœud pour une correction rapide. Notez que le nœud redémarré peut toujours rencontrer à nouveau le blocage. Pour une atténuation plus robuste, désactivez le streaming d'images sur le pool de nœuds en exécutant la commande suivante :

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

• 1.32.4-gke.1198000 et versions ultérieures
• Versions 1.33 antérieures à 1.33.5-gke.1862000
• Versions 1.34 antérieures à 1.34.1-gke.2541000

• 1.33.5-gke.1862000 et versions ultérieures
• 1.34.1-gke.2541000 et versions ultérieures

ComputeClasses personnalisées avec ImageType n'utilisant pas de pools de nœuds GKE existants.

Lorsque vous utilisez une ComputeClass personnalisée qui définit un champ ImageType, l'autoscaler de cluster crée et effectue un scaling à la hausse de nouveaux pools de nœuds de manière répétée au lieu d'effectuer un scaling à la hausse des pools de nœuds existants. L'état de ComputeClass n'est pas sain.

Solution :

Mettez à niveau le cluster vers l'une des versions corrigées suivantes :

• 1.33.5-gke.1862000 ou versions ultérieures
• 1.34.1-gke.2541000 ou versions ultérieures

Vous pouvez également atténuer ce problème en ne définissant pas certains champs dans la ComputeClass personnalisée.

• Si vous n'utilisez pas de ComputeClass personnalisée Autopilot, ne définissez pas le champ ImageType. Dans ce cas, la valeur utilisée est le paramètre par défaut au niveau du cluster, qui est cos_containerd par défaut.
• Si vous utilisez une ComputeClass personnalisée Autopilot, ne définissez pas le champ nodePoolConfig, qui est un niveau ImageType.