Problèmes connus pour GKE sur Azure

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

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.

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.

Sélectionnez votre version de GKE sur Azure :

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

Vous pouvez également rechercher votre problème :

Catégorie Version(s) identifiée(s) Problème et solution
Opérations 1.28, 1.27, 1.26, 1.25, 1.24, 1.23, 1.22

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

1.26.0-gke.0 à 1.26.4-gke.220 (non incluse)

de 1.25.0-gke.0 à 1.25.10-gke.1200 (non incluse) ;

1.24 à partir de 1.24.0-gke.0

1.23 à partir de 1.23.8-gke.1700

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 1.25.5-gke.1500, 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.
Facilité d'utilisation 1.22

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.
Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.