Résoudre les problèmes liés aux pools de nœuds Windows Server

Lorsque vous exécutez des pools de nœuds Windows Server dans Google Kubernetes Engine (GKE), vous pouvez rencontrer des problèmes tels que l'échec du démarrage des pods, des erreurs lors de l'extraction d'images de conteneurs Windows , des problèmes de connectivité réseau ou des nœuds qui ne démarrent pas.

Utilisez ce document pour diagnostiquer et résoudre ces problèmes courants, et pour que vos applications basées sur Windows continuent de fonctionner de manière fiable.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme qui gèrent des clusters GKE avec des pools de nœuds Windows, ainsi que pour les développeurs d'applications qui déploient et exécutent des applications basées sur Windows sur GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches auxquels nous faisons référence dans le Google Cloud contenu, consultez Rôles et tâches courants des utilisateurs GKE.

Pour obtenir des conseils plus généraux, consultez la documentation Kubernetes sur le débogage des pods et des services.

Problèmes de nœud Containerd

Pour savoir comment résoudre les problèmes si vous utilisez une image de nœud Containerd, consultez Problèmes liés aux pools de nœuds Windows Server.

Les pods Windows ne démarrent pas

Les incompatibilités entre l'image de base et les versions de l'OS hôte Windows Server peuvent empêcher le démarrage des pods.

Symptômes

  • Les pods Windows ne démarrent pas.
  • Le nœud signale l'état NotReady.

Cause

L'image de conteneur a été créée à partir d'une ancienne image Windows de base incompatible avec la version Windows Server du nœud hôte.

Solution

Créez vos images de conteneur à l'aide d'images Windows de base intégrant les mises à jour Windows publiées à partir de mars 2020. Pour en savoir plus sur la compatibilité des conteneurs Microsoft, consultez la documentation de Microsoft sur les problèmes d'incompatibilité des conteneurs Windows Server (février 2020).

Erreurs d'extraction d'image

Les images de conteneur Windows Server sont souvent beaucoup plus volumineuses que les images Linux, ce qui peut entraîner des délais avant expiration.

Symptômes

  • Messages d'erreur tels que Failed to pull image ou context cancelled.
  • Les pods affichent l'état ErrImagePull.

Cause

Les images de conteneur Windows Server et les couches dont elles sont composées peuvent être volumineuses. Leur taille peut entraîner le dépassement du délai avant expiration de l'agent kubelet lors du téléchargement et de l'extraction des couches du conteneur.

Solution

Pour résoudre ces échecs d'extraction d'image, essayez les solutions suivantes :

  • Augmenter le nombre de processeurs du nœud : l'extraction de conteneurs est exécutée en parallèle sur plusieurs cœurs. Par conséquent, les types de machines comportant davantage de cœurs réduisent le temps d'extraction global.
  • Optimiser les couches d'image : pour améliorer la mise en cache des couches Docker et augmenter les chances de réussite de vos tentatives d'extraction d'images, divisez vos couches d'application en plusieurs couches plus petites. Pour en savoir plus, consultez Images et couches dans la documentation du pilote de stockage Docker.
  • Utiliser des extractions manuelles : connectez-vous à vos nœuds Windows Server et exécutez manuellement la commande docker pull sur les images de conteneur avant de créer vos pods.

Pour obtenir des conseils plus généraux, consultez Résoudre les problèmes d'extraction d'images.

Famille d'images en fin de vie

GKE rend régulièrement obsolètes les anciennes familles d'images Windows Server lorsque l'assistance du fournisseur prend fin. Cette obsolescence empêche la création de pools de nœuds avec ces images.

Symptômes

Lorsque vous créez un pool de nœuds avec une image Windows, vous recevez une erreur semblable à celle-ci :

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

Cause

La famille d'images Windows Server sélectionnée n'est plus compatible avec GKE.

Solution

Choisissez une image Windows disponible et compatible. Pour connaître la date de fin de compatibilité des images de nœuds Windows GKE, utilisez la commande gcloud container get-server-config décrite dans Mapper les versions GKE et Windows.

Expiration du délai d'inactivité lors de la création du pool de nœuds

L'initialisation simultanée d'un grand nombre de nœuds Windows Server peut entraîner des délais avant expiration.

Symptômes

Les opérations de création de pool de nœuds expirent avant de se terminer.

Cause

Le délai de création d'un pool de nœuds peut expirer si vous créez un grand nombre de nœuds (par exemple, 500) et qu'il s'agit du premier pool de nœuds du cluster utilisant une image Windows Server.

Solution

Réduisez le nombre initial de nœuds lors de la création du pool de nœuds. Une fois le pool de nœuds créé, vous pouvez augmenter le nombre de nœuds.

Les nœuds Windows passent à l'état NotReady avec l'erreur PLEG is not healthy

La planification rapide de plusieurs conteneurs Windows sur un seul nœud peut surcharger le générateur d'événements de cycle de vie des pods (PLEG).

Symptômes

  • Les nœuds Windows passent à l'état NotReady.
  • Les événements ou les journaux affichent un message d'erreur PLEG is not healthy.

Cause

Un problème Kubernetes connu se produit lorsque plusieurs pods démarrent très rapidement sur un seul nœud Windows.

Solution

Pour résoudre les échecs PLEG et éviter qu'ils ne se reproduisent :

  • Redémarrez le nœud Windows Server concerné.
  • Limitez la création de pods Windows à un pod toutes les 30 secondes maximum.

TerminationGracePeriod incohérent

Les différences entre les minuteurs d'arrêt des conteneurs Windows et les paramètres de délai de grâce Kubernetes peuvent entraîner l'arrêt inattendu des conteneurs.

Symptômes

Les conteneurs sont arrêtés de force par Windows avant l'expiration de la durée configurée dans le champ TerminationGracePeriodSeconds.

Cause

Le délai avant expiration du système Windows interne pour le conteneur diffère du délai de grâce spécifié dans le fichier manifeste du pod Kubernetes.

Solution

Modifiez le délai avant expiration du conteneur Windows en modifiant les clés de registre locales du conteneur au moment de la création de l'image. Alignez le champ TerminationGracePeriodSeconds dans votre fichier manifeste de pod en conséquence.

Problèmes de connectivité réseau

Les différences de taille de l'unité de transmission maximale (MTU) entre la mise en réseau des conteneurs Windows Server et les Google Cloud réseaux peuvent entraîner la perte de paquets.

Symptômes

Les applications exécutées dans des conteneurs Windows Server rencontrent des échecs de connectivité réseau ou des pertes de paquets.

Cause

La mise en réseau de conteneurs Windows Server suppose souvent une MTU réseau de 1500, qui est incompatible avec Google Cloudla MTU de 1460.

Solution

Configurez la MTU de l'interface réseau du conteneur et la valeur de la MTU de l'interface réseau du nœud Windows Server sur 1460 ou moins. Pour en savoir plus, consultez les problèmes connus liés aux conteneurs Windows dans la documentation Compute Engine.

Problèmes de démarrage des nœuds

Les nouvelles instances Windows Server peuvent ne pas parvenir à terminer les scripts d'initialisation ni à s'enregistrer auprès du plan de contrôle.

Symptômes

Les nœuds Windows Server ne parviennent pas à s'initialiser ni à rejoindre le cluster.

Cause

Des erreurs lors de l'initialisation du nœud empêchent le nœud de démarrer ou de rejoindre le cluster.

Solution

Pour identifier les erreurs de démarrage qui pourraient être à l'origine du problème, examinez la sortie du port série du nœud :

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

Remplacez les éléments suivants :

  • NODE_NAME : nom du nœud.
  • COMPUTE_ZONE : zone de calcul du nœud.

Services inaccessibles de façon intermittente dans les nœuds Windows avec des clusters exécutant la version 1.24 ou une version antérieure

Sur les clusters exécutant la version 1.24 ou une version antérieure, le redémarrage du composant kube-proxy entraîne des retards temporaires dans le routage réseau pendant le retraitement des règles d'équilibreur de charge du service réseau hôte (HNS).

Symptômes

Les services sont inaccessibles de façon intermittente à partir des pods exécutés sur des nœuds Windows.

Cause

Pour les clusters GKE exécutant la version 1.24 ou une version antérieure, si un événement redémarre le composant kube-proxy sur un nœud Windows (par exemple, le démarrage d'un nœud, la mise à niveau d'un nœud ou le redémarrage manuel), le composant doit se synchroniser et recréer toutes les règles d'équilibreur de charge HNS. Si le cluster comporte un grand nombre de ces règles, leur traitement peut prendre beaucoup de temps (environ 30 secondes par règle). Pendant ce délai de synchronisation, les services sont inaccessibles de façon intermittente à partir des pods exécutés sur ce nœud. Pour en savoir plus, consultez le problème original dans GitHub.

Solution

Mettez à niveau votre plan de contrôle de cluster vers la version 1.25 ou une version ultérieure. Ce comportement est considérablement amélioré dans les versions plus récentes, comme indiqué dans la demande d'extraction dans GitHub.

Étape suivante