Cette documentation concerne la version la plus récente de GKE sur Azure, publiée en novembre 2021. Consultez les notes de version pour plus d'informations.

Problèmes connus concernant 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.

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

Opérations

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

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

Toutes les versions

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

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 entraîner des décisions de scaling incorrectes, par exemple des pods qui ne sont pas 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écouverte automatique.

Mise en réseau

Expirations d'application dues à des échecs d'insertion de 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.
Les versions 1.25 allant de 1.25.0-gke.0 à (non incluses) 1.25.10-gke.1200.
Versions à partir de 1.26.0-gke.0 jusqu'à, mais sans inclure, 1.26.4-gke.2200.

Les clusters exécutés sur un système d'exploitation Ubuntu qui utilise le noyau 5.15 ou une version ultérieure peuvent rencontrer des échecs d'insertion de table de suivi de connexion (conntrack) netfilter. 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 versions ultérieures qui limitent les insertions de table en fonction de la longueur de la 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 version ultérieure.

Facilité d'utilisation

Erreur de détection de clusters inaccessibles dans l'interface utilisateur

Les versions concernées par ce problème sont les suivantes : 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 est 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.