Problèmes connus de GKE

Autopilot Standard

Cette page répertorie les problèmes connus liés à GKE. Cette page s'adresse aux administrateurs et aux architectes qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente, et qui gèrent les alertes et les pages lorsque les objectifs de niveau de service (SLO) ne sont pas atteints ou que les applications échouent.

Cette page répertorie les problèmes connus pour toutes les versions compatibles et pour les deux versions mineures qui précèdent immédiatement la version la plus ancienne de la prise en charge étendue. Une fois qu'une version a atteint la fin de l'assistance étendue, tous les problèmes N-2 sont supprimés. Par exemple, lorsque la version 1.30 arrive à la fin de la période de compatibilité étendue, les problèmes connus spécifiques aux versions 1.28 et antérieures sont supprimés.

Si vous participez au programme Google Developer, enregistrez cette page pour recevoir des notifications lorsqu'une note de version associée à cette page est publiée. Pour en savoir plus, consultez Pages enregistrées.

Pour filtrer les problèmes connus en fonction d'une version de produit ou d'une catégorie, sélectionnez vos filtres dans les menus déroulants suivants.

Sélectionnez votre version de GKE :

1,35 1,34 1.33 1,32 1.31 1,30 1,29 1.28 1.27

Sélectionnez votre catégorie de problème :

Configuration Installation Mises à niveau et mises à jour Opération Journalisation et surveillance Sécurité Réinitialisation/Suppression Performances

Vous pouvez également rechercher votre problème :

Catégorie	Version(s) identifiée(s)	Version(s) corrigée(s)	Problème et solution
Opération	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 afin de s'authentifier auprès des API Google Cloud en demandant des jetons d'accès au compte de service ou des jetons d'identité au serveur de métadonnées GKE (par exemple,/computeMetadata/v1/instance/service-accounts/default/tokenou/computeMetadata/v1/instance/service-accounts/default/identity) peuvent échouer et générer une erreurHTTP 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 envoyées à ces points de terminaison de jeton sont strictement réservées aux jetons d'accès et d'identité 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.
Mises à niveau et mises à jour	1.33 et versions ultérieures	À déterminer	Pods non planifiés et quota épuisé lors des mises à niveau mineures en deux étapes pour le 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 programmation des pods et déclenche une boucle de scaling infinie. Au lieu de mettre à l'échelle un pool de nœuds existant, le provisionnement automatique des nœuds crée un pool de nœuds unique à chaque itération de mise à l'échelle 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"
Opération	1.37.0-gke.2941000 et versions ultérieures	1.37.1-gke.1131000	Les nœuds qui installent des volumes NFS accumulent des 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 pour 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 : 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 affiche l'état NotReady pendant environ 10 minutes est vidé et recréé, ce qui efface sa table de montage.
Mises à niveau	1.34.9-gke.1065000 et versions ultérieures, 1.35.6-gke.1049000 et versions ultérieures, et toutes les versions de correctif 1.36	1.34.10-gke.1328000 et versions ultérieures, 1.35.8-gke.1026000 et versions ultérieures, 1.36.4-gke.1058000 et versions ultérieures (aucun correctif n'est encore disponible pour la version 1.37)	É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 charges 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 réclamer des ressources CUDA. Solution : Mettez à niveau chaque cluster et pool de nœuds concernés 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 mettra 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 exécutant les versions concernées, puis recréez-les à l'aide d'une version antérieure non concernée. Notez que, comme la capacité maximale A4X doit être obtenue par le biais d'une réservation, vous ne perdrez aucune capacité en supprimant les pools de nœuds.
Opération	Versions 1.33 antérieures à 1.33.5-gke.2469000, versions 1.34 antérieures à 1.34.1-gke.2037001	1.33.5-gke.2469000 et versions ultérieures, 1.34.1-gke.2037001 et versions ultérieures, 1.35 et versions ultérieures	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 taints 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 ce problème, vous devez supprimer manuellement les libellés et les taints de maintenance active gérés par GKE 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é.
Opération	1.33 1,34	1.34.1-gke.1829001 et versions ultérieures	É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 au niveau des rapports 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. Les erreurs suivantes se produisent en fonction des ressources TPU demandées : 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". Lorsque vous demandez 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.
Opération	1.35.3-gke.1234000 et versions ultérieures	À déterminer	Le client Lustre n'utilise pas les cartes d'interface réseau secondaires sur les nœuds à plusieurs cartes d'interface réseau Sur les nœuds GKE dotés de plusieurs cartes d'interface réseau (NIC), le pilote CSI Lustre géré est activé par défaut pour utiliser toutes les cartes NIC 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, il est possible que les clients Lustre à partir de la version 2.14.0_p249 n'utilisent pas les 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 GKE antérieure à 1.35.3-gke.1234000, telle que 1.35.2-gke.1842000.
Opération	1.35 et versions ultérieures	À déterminer	Délai avant expiration de la connexion ou connexion refusée pour les flux redirigés vers le serveur de métadonnées GKE Dans la version 1.35 et ultérieures de GKE, les charges de travail qui utilisent Workload Identity pour s'authentifier auprès des API Google Cloud peuvent rencontrer des délais d'expiration 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 d'expiration au démarrage du pod.
Opération	1.33.8-gke.1026000 et versions ultérieures	1.35.1 et versions ultérieures	Le shim gVisor ne parvient pas à effectuer le nettoyage et enregistre 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 Standard, 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
Opération	1.35.0-gke.2232000 et versions ultérieures	1.35.3-gke.1.35.3-gke.1290000 et versions ultérieures	Les volumes dynamiques reviennent au type de disque par défaut Les charges de travail utilisant des volumes dynamiques dans GKE version 1.35.0-gke.2232000 ou ultérieure peuvent ne pas être planifiées ni associées. 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.
Mises à niveau et mises à jour	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 peuvent rencontrer des problèmes de démarrage des pods pour les nouvelles charges de travail créées lors du déploiement du DaemonSet anetd. Les nouvelles charges de travail ne pourront pas démarrer lors du déploiement de anetd si elles sont planifiées sur un nœud avec un anetd obsolète. Lors du 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 se produit car 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 que le déploiement de anetd soit terminé. Pour accélérer manuellement le déploiement, 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 libellés pertinents pour l'identité.
Mises à niveau et mises à jour	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 planification des pods sur les nouveaux nœuds avec la règle de réseau Calico 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. Ce problème est dû au fait que le script de démarrage Calico CNI met en forme de manière incorrecte l'URL du serveur d'API Kubernetes pour les adresses IPv4 en les encadrant de crochets ([]). Cette approche entraîne une erreur d'analyse de l'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.
Performances	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 de série 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.
Performances	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	Les performances de GPUDirect-TCPX diminuent 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 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.
Mises à niveau	1,35	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 constater 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 produit 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 reçoivent une identité au moment de leur 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 de nouvelles charges de travail peut échouer. Solution : Pour limiter le nombre total d'identités, évitez d'ajouter à vos pods des étiquettes comportant un grand nombre de valeurs uniques. 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.
Mises à 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 de l'installateur et du sidecar 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 de l'installateur 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 GKE concernées peut entraîner des problèmes fonctionnels ou des problèmes de performances avec TCPX. En effet, TCPX n'est pas compatible avec le noyau Linux 6.12 mis à jour, utilisé par Container-Optimized OS milestone 125 ou version ultérieure. La version majeure 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 savoir comment configurer et mettre à 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. Ils n'ont aucun impact 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.
Opération	Toutes les versions antérieures à 1.34.0-gke.2285000	1.34.0-gke.2285000 et versions ultérieures	Capacité minimale des instances modifiée 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 version 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 la version de votre cluster vers la version 1.34.0-gke.2285000 ou ultérieure pour pouvoir créer des instances Lustre gérées avec une capacité minimale de 9 000 Gio.
Opération	Toutes les versions	À déterminer	L'interface utilisateur de la consoleGoogle Cloud 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 Google Cloud 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.
Opération	Versions 1.33 antérieures à 1.33.4-gke.1036000	1.33.4-gke.1036000 et versions ultérieures	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.
Opération	1.32.3-gke.1099000 et versions ultérieures 1.33	1.33.3-gke.1266000 et versions ultérieures	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, il est possible que le renommage ou le déplacement de fichiers dans des buckets Cloud Storage échouent et génèrent une erreur d'E/S. Solution : Ajoutez temporairement une définition d'image side-car spécifique au fichier manifeste de votre 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 de votre cluster mise à niveau.
Journalisation et surveillance	Toutes les versions	À déterminer	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 l'ajout du libellé à un nouveau nœud du pool de nœuds est retardé. 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é le libellé 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
Mises à niveau	1.33	1.33.2-gke.1043000	Limite de fichiers ouverts abaissée avec containerd 2.0 Pour les pools de nœuds exécutant la version 1.33 de GKE, qui utilise containerd 2.0, la limite logicielle 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 logicielle par défaut plus élevée (par exemple, celles qui s'appuient implicitement sur l'ancienne limite par défaut plus élevée) peuvent rencontrer des échecs, tels que des erreurs Too many open files. Solution : Mettez à niveau une version de correctif 1.33 antérieure vers 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 d'ajustement de l'ulimit NRI containerd  : utilisez le plug-in containerd/nri ulimit-adjuster pour ajuster l'ulimit. Rétrograder un 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. Pour en savoir plus sur la migration vers containerd 2, consultez Migrer des nœuds vers containerd 2.
Mises à niveau	1.31.5-gke.1169000, 1.32.1-gke.1376000	1.31.7-gke.1164000, 1.32.3-gke.1512000	"status.storedVersions" non valide pour les CRD gérées Il est possible que certains CRD gérés par GKE comportent un champ status.storedVersions non valide, ce qui risque de compromettre l'accès aux objets CRD après une mise à niveau. Ce problème affecte les clusters qui présentent les deux caractéristiques suivantes : Clusters ayant utilisé une version 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.
Fonctionnement, journalisation et surveillance	1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000	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 qui ne s'adapte pas 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 aux versions corrigées plus récentes.
Opération			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 qui utilisent 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 disques Hyperdisk. Solution : Les produits Google Cloud Hyperdisk déclenchent le provisionnement automatique sur d'autres formes de VM. Nous vous recommandons de choisir une forme qui n'est compatible qu'avec Google Cloud Hyperdisk.
Opération	1.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000		gke-metadata-server est arrêté par OOMKilled sur les nœuds TPU/GPU Sur les nœuds TPU (par exemple, ct4p-hightpu-4t) et GPU (par exemple, a3-highgpu-8g) de GKE, le noyau peut arrêter 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.
Opération	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 qui ont des nœuds de la version 1.31 ou d'une version antérieure ne parviendront pas à mettre à jour l'état de PersistentVolumeClaim lors du redimensionnement. Cet état incorrect empêche le début des opérations de redimensionnement ultérieures, ce qui empêche effectivement tout redimensionnement ultérieur. Un PVC dans cet état comporte un champ status.allocatedResourceStatuses contenant 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, votre PVC doit être corrigé 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}}'
Opération	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 données 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 Cloud Logging Write. 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")
Opérations	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érieure, les volumes NFS utilisant le pilote CSI intégré à Kubernetes ne peuvent installer des volumes persistants en mode lecture seule qu'après une précédente installation en mode lecture seule sur le même nœud. Solution : Rétrogradez les pools de nœuds vers une version antérieure aux versions concernées.
Opérations	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 de monter 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 : Rétrograder les pools de nœuds vers la version 1.31.
Opération	>= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1369000	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 à Kill container [container-id], indiquant que le système tente à plusieurs reprises d'arrêter un conteneur. Parallèlement, 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.
Opération	1.28, 1.29, 1.30, 1.31	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 dans 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.
Opération	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 disposent de noyaux qui ont été 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 constatiez 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 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 le kubelet indique comme disponible. Si vous constatez une utilisation de 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 : max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) 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. 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ération. Par exemple, disable-mglru: "true". Mettez à jour le paramètre nodeSelector dans le fichier manifeste 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. 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.
Opération	1.28, 1.29, 1.30, 1.31	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 "Terminating" 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 : OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown 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.
Opération	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. Les conteneurs exécutés sur un nœud avec le streaming d'images activé sur des versions GKE spécifiques peuvent ne pas être créés et générer l'erreur suivante : "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links" 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.
Opération	1.27,1.28,1.29	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 plusieurs fichiers manquants. Les conteneurs exécutés sur un nœud avec le streaming d'images 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.
Mise en réseau,Mises à niveau et mises à jour	1.28		Erreur de configuration TLS de la passerelle Nous avons identifié un problème lors de la 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 modifications 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.
Mises à niveau et mises à jour	1.27	1.27.8 ou ultérieure	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 ou supprimez manuellement le pod nvidia-gpu-device-plugin sur les nœuds (le gestionnaire de modules complémentaires créera un nouveau plug-in fonctionnel). 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 les versions correctives.
Opération	1.27,1.28	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. Ce 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 défini sur AverageValue, la cible doit être averageValue. Pour en savoir plus sur la configuration des objets AHP autoscaling/v2, consultez la documentation Kubernetes sur HorizontalPodAutoscaler.
Opération	1.28,1.29	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
Mise en réseau, mises à niveau	1.27, 1.28, 1.29, 1.30	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.
Mise en réseau	1.31, 1.32	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 ou créé avec l'une des versions GKE suivantes : 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
Opération	1.29,1.30,1.31	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 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.
Mises à niveau et mises à jour	1.30, 1.31	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. "Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')" 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.
Opération	1.33.1-gke.1522000 et versions ultérieures	1.33.4-gke.1142000 et versions ultérieures	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 Remarque : La désactivation du streaming d'images recrée tous les nœuds d'un pool de nœuds.
Opération	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 les pools de nœuds GKE existants. Lorsque vous utilisez une classe 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 opérationnel. 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 version ultérieure 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 Autopilot personnalisée, 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 Autopilot personnalisée, ne définissez pas le champ nodePoolConfig, qui est un niveau ImageType.

Étapes suivantes

• Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide pour bénéficier d'une assistance supplémentaire, y compris des conseils sur les sujets suivants :

  • Ouvrir une demande d'assistance en contactant Cloud Customer Care.
  • Obtenir de l'aide de la communauté en posant des questions sur Stack Overflow et en utilisant le tag google-kubernetes-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour obtenir une assistance supplémentaire de la communauté.
  • Signaler des problèmes ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.