Problèmes connus de la mise en réseau GKE

Cette page répertorie les problèmes connus liés à la mise en réseau 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.

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

Sélectionnez votre version de GKE :

Vous pouvez également rechercher votre problème :

Version(s) identifiée(s) Version(s) corrigée(s) Problème et solution
1.31, 1.32, 1.33
  • 1.33.1-gke.1107000 et versions ultérieures

Indisponibilité des équilibreurs de charge d'Ingress et de service sur les clusters avec un réseau ancien

Une incompatibilité avec les anciens réseaux entraîne le détachement des backends d'un équilibreur de charge géré par GKE déployé à l'aide d'Ingress ou d'un service. L'équilibreur de charge ne dispose alors d'aucun backend actif, ce qui entraîne l'abandon de toutes les requêtes entrantes adressées à ces équilibreurs de charge.

Ce problème affecte les clusters GKE qui utilisent un ancien réseau et qui sont en version 1.31 ou ultérieure.

Pour identifier les clusters GKE avec un ancien réseau, exécutez la commande suivante : 

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"

Un cluster avec un ancien réseau obtiendra un résultat vide pour cette commande.

Solution :

Étant donné que les anciens réseaux sont obsolètes depuis un certain temps, la solution recommandée consiste à migrer votre ancien réseau vers un réseau VPC. Pour ce faire, vous pouvez convertir un ancien réseau contenant des clusters GKE. Si vous ne pouvez pas effectuer cette migration pour le moment, contactez Cloud Customer Care.

1.30, 1.31, 1.32
  • 1.30.10-gke.1070000 et versions ultérieures
  • 1.31.5-gke.1068000 et versions ultérieures
  • 1.32.1-gke.1002000 et versions ultérieures

Les nœuds nouvellement créés ne sont pas ajoutés aux équilibreurs de charge internes de couche 4.

Il est possible que les équilibreurs de charge Google Cloud créés pour les services LoadBalancer internes ne détectent pas les nœuds nouvellement créés dans le groupe d'instances de backend.

Le problème sera plus visible sur un cluster dont le nombre de nœuds a été réduit à zéro, puis augmenté à un ou plusieurs nœuds.

Solutions :

  • Activez le sous-paramètre GKE et recréez le service.

    Remarque : Une fois le sous-paramètre GKE activé, il ne peut plus être désactivé.

  • Créez un autre service d'équilibrage de charge interne. Lors de la synchronisation, le groupe d'instances sera également corrigé pour le service concerné. Le nouveau service peut être supprimé après la synchronisation.
  • Ajoutez, puis supprimez le libellé node.kubernetes.io/exclude-from-external-load-balancers de l'un des nœuds.
  • Ajoutez un nœud au cluster. Vous pouvez supprimer le nœud une fois que le service a commencé à fonctionner.
1.27,1.28,1.29,1.30,1.31

Le contrôleur NEG cesse de gérer les points de terminaison lorsque le port est supprimé du service

Lorsque le contrôleur NEG est configuré pour créer un NEG autonome pour un service et que l'un des ports configurés est ensuite supprimé du service, le contrôleur NEG finit par cesser de gérer les points de terminaison du NEG. En plus des services pour lesquels l'utilisateur crée une annotation NEG autonome, cela affecte également les services référencés par GKE Gateway, MCI et GKE Multi Cluster Gateway.

Solution :

Lorsque vous supprimez un port d'un service avec une annotation NEG autonome, l'annotation doit également être mise à jour pour supprimer le port en question.

1.28

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 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.

1.27,1.28,1.29
  • 1.26.13-gke.1052000 et versions ultérieures
  • 1.27.10-gke.1055000 et versions ultérieures
  • 1.28.6-gke.1095000 et versions ultérieures
  • 1.29.1-gke.1016000 et versions ultérieures

Échecs intermittents d'établissement de la connexion

Les clusters dont le plan de contrôle exécute les versions 1.26.6-gke.1900 et ultérieures peuvent rencontrer des échecs intermittents d'établissement de connexion.

Les risques de défaillance sont faibles et n'affectent pas tous les clusters. Les échecs devraient cesser complètement au bout de quelques jours après l'apparition du problème.

1.27,1.28,1.29
  • 1.27.11-gke.1118000 ou versions ultérieures
  • 1.28.7-gke.1100000 ou versions ultérieures
  • 1.29.2-gke.1217000 ou versions ultérieures

Problèmes de résolution DNS avec Container-Optimized OS

Les charges de travail exécutées sur des clusters GKE avec des nœuds basés sur Container-Optimized OS peuvent rencontrer des problèmes de résolution DNS.

1.28 1.28.3-gke.1090000 (et versions ultérieures)

La règle de réseau supprime une connexion en raison d'une recherche de suivi des connexions incorrecte

Pour les clusters sur lesquels GKE Dataplane V2 est activé, lorsqu'un pod client se connecte lui-même à l'aide d'un service ou de l'adresse IP virtuelle d'un équilibreur de charge réseau passthrough interne, le paquet de réponse n'est pas identifié comme faisant partie d'une connexion existante en raison d'une recherche conntrack incorrecte dans le plan de données. Cela signifie qu'une règle de réseau qui limite le trafic entrant pour le pod est appliquée de manière incorrecte sur le paquet.

L'impact de ce problème dépend du nombre de pods configurés pour le service. Par exemple, si le service dispose d'un pod de backend, la connexion échoue toujours. Si le service dispose de deux pods de backend, la connexion échoue la moitié du temps.

Solution :

Vous pouvez limiter les conséquences de ce problème en configurant la même valeur pour port et containerPort dans le fichier manifeste du service.

1.27,1.28
  • 1.28.3-gke.1090000 (et versions ultérieures)
  • 1.27.11-gke.1097000 (et versions ultérieures)

Suppressions de paquets pour les flux de connexion "hairpin"

Pour les clusters avec GKE Dataplane V2 activé, lorsqu'un pod crée une connexion TCP vers lui-même à l'aide d'un service, de sorte que le pod est à la fois la source et la destination de la connexion, le suivi des connexions GKE Dataplane V2 eBPF suit les états de connexion de manière incorrecte, ce qui entraîne des fuites dans les entrées conntrack.

En cas de fuite d'un tuple de connexion (protocole, adresse IP source/de destination et port source/de destination), les nouvelles connexions utilisant le même tuple de connexion peuvent entraîner des suppressions de paquets de retour.

Solution :

Utilisez l'une des solutions suivantes :

  • Activez la réutilisation TCP (message keep-alive) pour une application exécutée dans un pod pouvant communiquer avec elle-même à l'aide d'un service. Cela permet d'empêcher l'envoi de l'option TCP FIN et d'éviter les fuites sur l'entrée conntrack.
  • Lorsque vous utilisez des connexions de courte durée, exposez le pod à l'aide d'un équilibreur de charge proxy, tel que Gateway, pour exposer le service. La destination de la requête de connexion est alors définie sur l'adresse IP de l'équilibreur de charge, ce qui empêche GKE Dataplane V2 d'effectuer une traduction d'adresse réseau source (SNAT) vers l'adresse IP de rebouclage.
Antérieur à 1.31.0-gke.1506000 1.31.0-gke.1506000 et versions ultérieures

Le réseau typé par appareil dans le multiréseau GKE échoue avec les noms de réseau longs

La création du cluster échoue avec l'erreur suivante :

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

Solution :

Limitez la longueur des noms d'objets réseau de type appareil à 41 caractères maximum. Le chemin d'accès complet de chaque socket de domaine UNIX est composé, y compris le nom de réseau correspondant. Linux limite la longueur des chemins d'accès aux sockets à 107 octets. En tenant compte du répertoire, du préfixe du nom de fichier et de l'extension .sock, le nom du réseau est limité à 41 caractères maximum.
1.27, 1.28, 1.29, 1.30
  • 1.30.4-gke.1282000 ou version ultérieure
  • 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 la règle de réseau est activée peuvent rencontrer des problèmes de connectivité avec les pods hostPort. De plus, la préparation des pods nouvellement créés peut prendre 30 à 60 secondes supplémentaires.

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.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 s'exécutant 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 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.28, 1.29, 1.30, 1.31

Les pods Calico ne sont pas opérationnels sur les clusters comportant moins de trois nœuds au total et un nombre insuffisant de vCPU.

Les pods Calico-typha et calico-node ne peuvent pas être planifiés sur les clusters qui remplissent toutes les conditions suivantes : moins de trois nœuds au total, chaque nœud ayant un ou moins de processeurs virtuels allouables, et règle de réseau activée. Cela est dû à des ressources de processeur insuffisantes.

Solutions :

  • Effectuez un scaling à au moins trois pools de nœuds avec un nœud utilisant un processeur virtuel allouable.
  • Redimensionnez un pool de nœuds unique à un minimum de trois nœuds avec un processeur virtuel allouable.
  • Utilisez un type de machine avec au moins deux processeurs virtuels pouvant être alloués sur un pool de nœuds avec un seul nœud.