Problèmes connus pour GKE sur AWS

Cette page répertorie certains problèmes connus de GKE sur AWS, ainsi que les étapes à suivre pour en réduire l'impact.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Opérations

L'autoscaler de cluster peut effectuer un scaling à la hausse incorrect à partir de zéro nœud

Voici les versions concernées par ce problème :

  • Toutes les versions antérieures à la version 1.27
  • Versions 1.27 de 1.27.0-gke.0 à 1.27.12-gke.800 (non incluse)
  • Versions 1.28 de 1.28.0-gke.0 à 1.28.8-gke.800 (non incluse)

L'autoscaler de cluster n'effectue pas correctement le scaling à la hausse à partir de zéro pour les pools de nœuds avec des étiquettes ou des rejets personnalisés.

Ce problème se produit, car l'autoscaler de cluster GKE sur AWS n'a pas configuré les libellés de pool de nœuds ni les balises de rejet sur le groupe de scaling automatique du pool de nœuds correspondant lors du provisionnement du pool de nœuds. Pour les pools de nœuds sans aucun nœud, l'autoscaler de cluster ne peut pas créer correctement les modèles de nœud à cause de ces balises manquantes. Cela peut conduire à des décisions de scaling incorrectes, par exemple des pods non planifiés sur les nœuds applicables, ou des nœuds provisionnés qui ne sont pas vraiment nécessaires. Pour en savoir plus, consultez Configuration de la détection automatique.

Mise en réseau

Expirations de délai de l'application causées par les échecs d'insertion de la table conntrack

Voici les versions concernées par ce problème :

  • Toutes les versions 1.23 à partir de 1.23.8-gke.1700
  • Toutes les versions 1.24 à partir de 1.24.0-gke.0
  • Versions 1.25 de 1.25.0-gke.0 à 1.25.10-gke.1200 (non incluse)
  • Versions de 1.26.0-gke.0 à 1.26.4-gke.2200 (non incluse)

Les clusters exécutés sur un système d'exploitation Ubuntu utilisant le noyau 5.15 ou une version ultérieure sont sensibles aux échecs d'insertion des tables Netfilter Connection Tracking (conntrack). Des échecs d'insertion peuvent se produire même lorsque la table conntrack dispose de place pour de nouvelles entrées. Les échecs sont dus à des modifications apportées au noyau 5.15 et aux versions ultérieures qui limitent les insertions de table en fonction de la longueur de chaîne.

Pour savoir si vous êtes concerné par ce problème, vérifiez les statistiques de système de suivi de la connexion au noyau à l'aide de la commande suivante :

sudo conntrack -S

La réponse est semblable à ce qui suit :

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0
error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0
error=519 search_restart=0 clash_resolve=126 chaintoolong=0

Si une valeur chaintoolong dans la réponse est un nombre différent de zéro, vous êtes concerné par ce problème.

Solution

Si vous exécutez la version 1.26.2-gke.1001, passez à la version 1.26.4-gke.2200 ou à une version ultérieure.

Facilité d'utilisation

Erreur "Clusters inaccessibles détectés" dans l'interface utilisateur

Les versions concernées par ce problème sont 1.25.5-gke.1500 et 1.25.4-gke.1300.

Certaines surfaces d'interface utilisateur de la console Google Cloud ne peuvent pas autoriser l'accès au cluster et peuvent afficher le cluster comme inaccessible.

Solution

Mettez à niveau votre cluster vers le dernier correctif disponible (version 1.25). Ce problème a été résolu dans la version 1.25.5-gke.2000.

Erreurs d'API

Kubernetes 1.22 abandonne et remplace plusieurs API. Si vous avez mis à niveau votre cluster vers la version 1.22 ou une version ultérieure, tous les appels effectués par votre application vers l'une des API obsolètes échouent.

Solution

Mettez à niveau votre application pour remplacer les appels d'API obsolètes par leurs équivalents plus récents.