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 faites partie du Google Developer Program, enregistrez cette page pour recevoir des notifications lorsqu'une note de version la concernant 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 :
Sélectionnez votre catégorie de problème :
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 | 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 dynamiquementLors du provisionnement dynamique d'une instance Lustre, la création de l'instance échoue avec une erreur Solution : Mettez à niveau le cluster GKE vers la version 1.33.4-gke.1036000 ou ultérieure. Si vous utilisez le canal 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 des canaux "Standard" ou "Rapide" qui inclut le correctif. |
| Opération |
|
1.33.3-gke.1266000 et versions ultérieures |
Erreur d'entrée/sortie lors du renommage ou du déplacement de fichiers à l'aide du pilote CSI Cloud Storage FUSELorsque 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 échoue et génère 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 # 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 GKE corrigée ou ultérieure, vous devez supprimer l'intégralité du bloc |
| Journalisation et surveillance | Toutes les versions | À déterminer |
Condition de concurrence dans les DaemonSets
|
| Mises à niveau | 1.33 | 1.33.2-gke.1043000 |
Limite de fichiers ouverts abaissée avec containerd 2.0Pour 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 ( Il s'agit d'une modification apportée à containerd lui-même (voir la demande d'extraction containerd #8924), où 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 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 :
|
| Mises à niveau | 1.31.5-gke.1169000, 1.32.1-gke.1376000 | 1.31.7-gke.1164000, 1.32.3-gke.1512000 |
État CRD "storedVersions" non valide pour les CRD gérésIl est possible que certains CRD gérés par GKE comportent un champ Ce problème affecte les clusters qui remplissent les deux conditions suivantes :
Solution : La solution de contournement 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 également ajouter ces versions au champ |
| Fonctionnement, journalisation et surveillance | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
Métriques manquantes ou autoscaler de charge de travail qui ne fait pas de scalingVous 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 n'affecte 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 antérieure ou passer à une version corrigée plus récente. |
| Opération |
Limites de taille et de pièces jointes de Google Cloud HyperdiskEn règle générale, un pod qui ne peut pas être planifié en raison des limites de rattachement de volume 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 exécutant une VM C3, le provisionnement automatique des nœuds ne se produit pas et le pod est planifié sur le nœud déjà complet. La charge de travail est planifiée sur le nœud malgré l'absence de disque disponible. La charge de travail ne parvient pas non plus à démarrer en raison d'une erreur semblable à la suivante : 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 Hyperdisk varient en fonction du nombre de processeurs virtuels de la VM et du produit Hyperdisk. Pour en savoir plus, consultez Limites de performances Hyperdisk. Solution : Les produits 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 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 OOMKilled sur les nœuds TPU/GPUSur les nœuds TPU (par exemple, Solution : Si vous constatez des événements |
|
| Opération |
|
|
Le redimensionnement de volumes peut être bloqué en raison de l'état "NodePendingResize" en suspens sur les PVC.Les clusters de version 1.32 dont les nœuds sont de version 1.31 ou antérieure ne pourront 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 effectivement tout redimensionnement supplémentaire. Un PVC dans cet état comporte un champ Si un PVC a été créé alors que votre cluster utilisait une version concernée, ce problème peut persister même 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 Solution : Les PVC bloqués en raison d'un état en attente peuvent être corrigés pour supprimer cet état. Vous pouvez utiliser une commande patch comme celle ci-dessous 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 |
|
|
Le pilote PDCSI peut enregistrer des journaux de manière excessiveLes clusters GKE exécutant certaines versions de 1.32 peuvent émettre un nombre excessif de messages de journaux à partir 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 empêcher l'ingestion des messages de journaux 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 |
|
|
Les pods qui tentent d'installer des volumes persistants NFS sur des nœuds COS qui avaient auparavant un montage en lecture seule (RO) ne seront monté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 monter des volumes persistants en mode lecture seule qu'après un montage en lecture seule précédent sur le même nœud. Solution : Rétrograder les pools de nœuds vers une version antérieure à celles concernées |
| Opérations |
|
|
Les pods qui tentent d'installer des volumes persistants NFS sur des nœuds Ubuntu ne pourront pas s'exécuter.Pour GKE version 1.32 et ultérieures, les volumes NFS utilisant le pilote CSI "in-tree" Kubernetes 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" Solution : Rétablissez une version antérieure des 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.1302000 |
|
Les pods utilisant des appels système liés à io_uring peuvent être bloqués à l'état "Terminating"
En raison d'un bug dans le noyau Linux, les pods qui utilisent des appels système liés à io_uring peuvent passer à l'état D (veille du disque), également appelé TASK_UNINTERRUPTIBLE. Les processus à l'état D ne peuvent pas être réactivés par des signaux, y compris
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 à ce qui suit :
ou
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 comme 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 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 |
|
Échec des charges de travail utilisant le streaming d'images avec des erreurs d'authentificationUn bug dans la fonctionnalité de streaming d'images peut entraîner l'échec des charges de travail lorsqu'un ensemble de conditions spécifiques sont remplies pendant que le conteneur lit des fichiers. Des messages d'erreur liés à des échecs d'authentification peuvent s'afficher dans le journal gcfsd.
Pour vérifier si vous êtes concerné, recherchez dans les journaux à l'aide de la requête de recherche suivante :
La présence de ces erreurs indique que les nœuds sont concernés. Si vous êtes concerné par ce problème, vous pouvez mettre à niveau vos pools de nœuds vers une version GKE corrigée. |
| Opération |
|
|
Augmentation des taux d'éviction de pods dans 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 créés avec l'option
L'option de configuration 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 celle que le kubelet indique comme disponible. Si vous constatez une utilisation plus élevée de la mémoire d'une application après la mise à niveau vers les versions GKE mentionnées, sans aucune autre modification, vous êtes peut-être concerné par l'option du noyau.
Pour vérifier si les taux d'éviction de pods sont inhabituels, analysez les métriques suivantes avec l'explorateur de métriques :
Vous pouvez utiliser les requêtes PromQL suivantes. Remplacez les valeurs de
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 dans l'utilisation de la mémoire qui dépassent la mémoire demandée, il est possible que la charge de travail soit expulsée plus souvent. SolutionSi vous ne pouvez pas effectuer la mise à niveau vers les versions corrigées et que vous exécutez dans un environnement GKE où vous pouvez déployer des pods privilégiés, vous pouvez désactiver l'option LRU multigénération à l'aide d'un DaemonSet.
Une fois le DaemonSet 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 redevient normal. |
| Opération | 1.28, 1.29, 1.30, 1.31 |
|
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 "Terminating" (En cours d'arrêt) avec des erreurs semblables à celles ci-dessous : 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.28,1.29 |
|
Échec du streaming d'images en raison de liens symboliquesUn 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"
Si vous êtes concerné par ce problème, 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 |
|
Échec du streaming d'images en raison de fichiers manquantsUn 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 ce type d'erreurs :
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 passerelleNous avons identifié un problème de configuration de TLS pour les passerelles dans les clusters exécutant la version 1.28.4-gke.1083000 de GKE. 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 corrective de 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 de périphérique GPU de leurs nœuds (
|
| Opération | 1.27,1.28 |
|
L'autoscaling de toutes les charges de travail s'arrête
Les 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 Solution :
Corrigez les objets AHP
Pour en savoir plus sur la configuration des objets |
| Opération | 1.28,1.29 |
|
Échec du déploiement de Container Threat DetectionIl est possible que Container Threat Detection ne parvienne pas à se déployer sur les clusters Autopilot exécutant les versions GKE suivantes :
|
| Mise en réseau, mises à niveau | 1.27, 1.28, 1.29, 1.30 |
|
Problèmes de connectivité pour les pods
|
| Mise en réseau | 1.31, 1.32 |
|
Trafic UDP interrompu entre les pods s'exécutant sur le même nœudLes 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 :
Le chemin 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 :
|
| Opération | 1.29,1.30,1.31 |
|
Incompatibilité entre l'opérateur Ray et le chiffrement de la base de données Cloud KMSCertaines versions de Ray Operator ne sont pas compatibles avec le chiffrement de la 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 |
|
Pod du gestionnaire de maintenance GPU bloqué dans l'état CrashLoopBackOffDans ce cas, les pods gpu-maintenance-handler sont bloqués à l'état "CrashLoopBackOff" sur leurs nœuds respectifs. Cet état empêche l'application du libellé "Maintenance à venir" aux nœuds GKE, ce qui peut avoir un impact sur les processus de vidange 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 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 avec le streaming d'images activé
Sur les nœuds sur lesquels le streaming d'image est activé, les charges de travail peuvent ne pas démarrer avec la signature d'erreur suivante :
Les journaux du port série d'un nœud concerné contiennent également la signature d'erreur suivante :
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 atténuation rapide. Notez que le nœud redémarré peut toujours rencontrer à nouveau l'impasse. 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 |
É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-enginepour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack#kubernetes-enginepour obtenir une assistance supplémentaire de la communauté. - Signaler des bugs ou demander des fonctionnalités à l'aide de l'outil public de suivi des problèmes.