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 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.30, 1.31, 1.32

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

Les équilibreurs de charge Google Cloud créés pour les services LoadBalancer internes peuvent ne pas détecter les nœuds nouvellement créés dans le groupe d'instances de backend.

Le problème est le plus visible sur un cluster qui a été réduit à zéro nœud, puis redimensionné à un ou plusieurs nœuds.

Solutions :

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

    Remarque: Une fois activé, le sous-paramètre GKE ne peut pas ê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 l'étiquette node.kubernetes.io/exclude-from-external-load-balancers sur 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 qu'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 la passerelle GKE, MCI et la passerelle multicluster GKE.

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 mises à jour apportées à la passerelle échoueront. Pour les nouvelles passerelles, les équilibreurs de charge ne seront pas provisionnés. Ce problème sera résolu dans une prochaine version de correctif 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 exécutant le plan de contrôle version 1.26.6-gke.1900 ou ultérieure peuvent rencontrer des échecs intermittents d'établissement de connexion.

Les risques de défaillances sont faibles et ne concernent pas tous les clusters. Les défaillances devraient cesser complètement quelques jours après le début des symptômes.

1.27,1.28,1.29
  • 1.27.11-gke.1118000 ou version ultérieure
  • 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 avec GKE Dataplane V2 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. Cette solution 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.
Version antérieure à 1.31.0-gke.1506000 1.31.0-gke.1506000 et versions ultérieures

Le réseau de type appareil dans le multiréseau GKE échoue avec des 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 version ultérieure

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 nouveaux pods peut prendre entre 30 et 60 secondes supplémentaires.

Le problème se déclenche 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.28, 1.29, 1.30, 1.31

Pods Calico non opérationnels sur des 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 des clusters répondant à toutes les conditions suivantes: moins de trois nœuds au total, chaque nœud disposant d'un ou de moins de vCPU allouables et la règle de réseau activée. Cela est dû à un manque de ressources de processeur.

Solutions :

  • Évoluez jusqu'à un minimum de trois pools de nœuds, avec un nœud utilisant un processeur virtuel allocable.
  • Redimensionnez un pool de nœuds unique à un minimum de trois nœuds avec un vCPU allouable.
  • Utilisez un type de machine avec au moins deux vCPU allouables dans un pool de nœuds avec un seul nœud.