How to view and diagnose node issues - Container Service for Kubernetes

Fonctionnement

Les résultats du diagnostic passent par quatre étapes :

Node diagnostics

Anomaly identification : collecte des signaux de base — état du nœud, état des pods et flux d'événements du cluster — et identification des anomalies.
Data collection : rassemblement de données contextuelles basées sur les anomalies identifiées, y compris les informations sur les nœuds Kubernetes, les détails des instances ECS et l'état des processus Docker/kubelet.
Diagnostic item check : vérification si les métriques clés se situent dans les plages normales. Les éléments sont regroupés par catégorie, chacun avec une description.
Root cause analysis : détermination de la cause racine des problèmes basée sur les données collectées et les résultats des vérifications.

Résultats du diagnostic

Les résultats se divisent en deux types :

Root cause analysis results : incluent les anomalies détectées, la cause racine identifiée et des suggestions de correction.
Diagnostic item check results : incluent les résultats de vérification par élément. Ceux-ci peuvent révéler des causes que l'analyse des causes racines pourrait manquer.

Les éléments de diagnostic varient selon la configuration du cluster et reflètent votre configuration de cluster réelle.

Cas d'utilisation

Le diagnostic des nœuds et le diagnostic assisté par l'IA couvrent les scénarios suivants.

Catégorie	Scénario
Diagnostic des nœuds	Nœud NotReady — réseau non prêt, insuffisance d'identifiants de processus (PIDs), mémoire insuffisante, espace disque insuffisant, exceptions d'exécution ou aucun battement de cœur détecté
	Quota d'inodes insuffisant
	Quota de PID insuffisant
	Heure du nœud incorrecte
	Système de fichiers du nœud en lecture seule
	Interblocages dans le noyau du nœud
Diagnostic assisté par l'IA	État anormal du nœud
	État anormal de l'instance ECS
	Erreurs kubelet sur les nœuds
	Exceptions d'exécution sur les nœuds
	Espace disque insuffisant
	Utilisation élevée du CPU sur les nœuds

Éléments de diagnostic

Catégorie	Ce qui est vérifié
Nœud	État du nœud, état du réseau, journaux du noyau, processus du noyau et disponibilité des services
NodeComponent	État des composants clés du nœud, y compris les composants réseau et de stockage
ClusterComponent	Disponibilité du serveur API, disponibilité du DNS et état de la passerelle NAT
ECSControllerManager	État de l'instance ECS, connexions réseau, santé du système d'exploitation et E/S disque
GPUNode	État du module NVIDIA et configurations du runtime de conteneur sur les nœuds accélérés par GPU

Nœud

Si un problème persiste après application du correctif suggéré, collectez les journaux du nœud et soumettez un ticket.

Élément de diagnostic	Ce qui est détecté	Correctif
Erreurs de connectivité vers le serveur API Kubernetes	Si le nœud peut atteindre le serveur API du cluster. La perte de connectivité empêche le nœud de recevoir les affectations de charge de travail.	Vérifiez la configuration du cluster. Consultez Dépannage des clusters ACK.
Blocages de montage AUFS	Si des blocages de montage AUFS se produisent sur le nœud.	Soumettre un ticket.
Erreurs BufferIOError	Si des erreurs BufferIOError sont présentes dans le noyau du nœud.	Soumettre un ticket.
Fuites cgroup	Si des fuites cgroup se produisent. Les fuites cgroup peuvent interrompre la collecte des données de surveillance et provoquer des échecs de démarrage des conteneurs.	Connectez-vous au nœud et supprimez les répertoires cgroup concernés.
État anormal du processus chronyd	Si le processus chronyd fonctionne normalement. Un processus chronyd anormal perturbe la synchronisation de l'horloge, affectant les opérations sensibles au temps.	Exécutez `systemctl restart chronyd` pour redémarrer le processus.
Tirage d'image par containerd	Si le runtime containerd peut tirer les images comme prévu.	Vérifiez la configuration réseau du nœud et les paramètres d'image.
État de containerd	Si le runtime containerd est en cours d'exécution.	Soumettre un ticket.
Disponibilité du pod CoreDNS	Si le nœud peut atteindre l'adresse IP du pod CoreDNS. Des pods CoreDNS inaccessibles provoquent des échecs de résolution DNS pour les charges de travail sur ce nœud.	Vérifiez si le nœud peut accéder à l'adresse IP du pod CoreDNS. Consultez Que faire si la charge de requête DNS n'est pas équilibrée entre les pods CoreDNS ?.
État de l'image	Si les images sont intactes. Des images endommagées empêchent le démarrage des conteneurs.	Soumettre un ticket.
État overlay2 des images	Si le système de fichiers overlay2 dans les images est endommagé.	Soumettre un ticket.
Heure système	Si l'horloge système est précise.	Aucun.
Démarrage du conteneur Docker	Si les conteneurs Docker ne parviennent pas à démarrer.	Soumettre un ticket.
Tirage d'image Docker	Si le nœud peut tirer les images Docker comme prévu.	Vérifiez la configuration réseau du nœud et les paramètres d'image.
État de Docker	Si le runtime Docker est en cours d'exécution.	Soumettre un ticket.
Temps de démarrage de Docker	Le temps de démarrage de Dockerd.	Aucun.
Erreurs de blocage Docker	Si des erreurs de blocage Docker se produisent sur le nœud. Les blocages Docker peuvent amener les conteneurs à cesser de répondre.	Exécutez `systemctl restart docker` pour redémarrer Docker.
Existence de l'instance ECS	Si l'instance ECS sous-jacente existe.	Vérifiez l'état de l'instance ECS. Consultez FAQ sur les nœuds et les pools de nœuds.
État de l'instance ECS	Si l'instance ECS est dans un état sain.	Vérifiez l'état de l'instance ECS. Consultez FAQ sur les nœuds et les pools de nœuds.
Erreurs Ext4FsError	Si des erreurs Ext4FsError sont présentes dans le noyau du nœud.	Soumettre un ticket.
Système de fichiers du nœud en lecture seule	Si le système de fichiers du nœud est devenu en lecture seule. Cela indique généralement une défaillance du disque et bloque toutes les opérations d'écriture, affectant les charges de travail.	Exécutez `fsck` pour réparer le système de fichiers, puis redémarrez le nœud.
Heure matérielle	Si l'horloge matérielle et l'horloge système sont synchronisées. Une différence supérieure à 2 minutes peut provoquer des erreurs de composant.	Exécutez `hwclock --systohc` pour synchroniser l'heure système avec l'horloge matérielle.
DNS	Si les noms de domaine peuvent être résolus sur le nœud.	Consultez Dépannage DNS.
Erreurs oops du noyau	Si des erreurs oops sont présentes dans le noyau du nœud. Elles indiquent des chemins de code inattendus et peuvent provoquer une instabilité.	Soumettre un ticket.
Versions du noyau	Si la version du noyau est obsolète. Les noyaux obsolètes peuvent présenter des problèmes de stabilité connus.	Mettez à jour le noyau du nœud. Consultez FAQ sur les nœuds et les pools de nœuds.
Disponibilité du DNS	Si le nœud peut atteindre l'IP de cluster du service kube-dns pour utiliser le service DNS du cluster.	Vérifiez l'état et les journaux des pods CoreDNS. Consultez Dépannage DNS.
État de kubelet	Si kubelet fonctionne normalement. Un kubelet défaillant empêche le nœud de gérer les pods.	Vérifiez les journaux de kubelet. Consultez Dépannage des clusters ACK.
Temps de démarrage de kubelet	Le temps de démarrage de kubelet.	Aucun.
Utilisation du CPU	Si l'utilisation du CPU du nœud est excessivement élevée.	Aucun.
Utilisation de la mémoire	Si l'utilisation de la mémoire du nœud est excessivement élevée.	Aucun.
Fragmentation de la mémoire	Si une fragmentation de la mémoire existe sur le nœud. La fragmentation réduit la mémoire contiguë et peut dégrader les performances des charges de travail.	Connectez-vous au nœud et exécutez `echo 3 \> /proc/sys/vm/drop_caches` pour vider le cache.
Mémoire swap	Si la mémoire swap est activée. Kubernetes exige que la swap soit désactivée ; son activation peut provoquer un comportement inattendu de kubelet.	Connectez-vous au nœud et désactivez la mémoire swap.
Chargement des pilotes de périphérique réseau	Si les pilotes VirtIO sur les périphériques réseau sont chargés correctement.	Soumettre un ticket.
Utilisation du CPU du nœud excessivement élevée	Si l'utilisation du CPU était élevée au cours de la semaine dernière. Si de nombreux pods sont planifiés sur un nœud avec une utilisation du CPU constamment élevée, la contention des ressources peut entraîner des interruptions de service.	Définissez les demandes et limites de ressources de manière appropriée pour éviter de surcharger le nœud.
Existence de l'IP privée du nœud	Si le nœud dispose d'une adresse IP privée attribuée. Sans IP privée, le nœud ne peut pas communiquer au sein du cluster.	Supprimez le nœud du cluster et rajoutez-le. Ne libérez pas l'instance ECS lors de sa suppression. Consultez Supprimer un nœud et Ajouter des instances ECS existantes.
Utilisation de la mémoire du nœud excessivement élevée	Si l'utilisation de la mémoire était élevée au cours de la semaine dernière. Une utilisation élevée de la mémoire combinée à une planification intensive des pods peut provoquer des erreurs d'épuisement de la mémoire (OOM) et des interruptions de service.	Définissez les demandes et limites de ressources de manière appropriée pour éviter de surcharger le nœud.
État du nœud	Si le nœud est dans l'état Ready.	Redémarrez le nœud. Consultez FAQ sur les nœuds et les pools de nœuds.
Planifiabilité du nœud	Si le nœud est marqué comme non planifiable. Un nœud non planifiable ne reçoit pas de nouvelles affectations de pods.	Vérifiez la configuration de planification du nœud. Consultez Drainage des nœuds et état de planification.
Erreurs OOM	Si des erreurs d'épuisement de la mémoire (OOM) se produisent sur le nœud. Les erreurs OOM peuvent entraîner la terminaison des pods et des processus système.	Soumettre un ticket.
Vérification du runtime	Si le runtime de conteneur du nœud correspond au runtime configuré du cluster. Une incompatibilité peut empêcher le démarrage des pods.	Consultez Puis-je changer le runtime de conteneur d'un cluster de containerd à Docker ?.
Versions du système d'exploitation obsolètes	Si la version du système d'exploitation du nœud présente des bugs connus ou des problèmes de stabilité. Les versions obsolètes du système d'exploitation peuvent provoquer un dysfonctionnement des runtimes Docker et containerd.	Mettez à jour la version du système d'exploitation.
Accès Internet	Si le nœud peut atteindre Internet.	Vérifiez si SNAT est activé pour le cluster. Consultez Activer l'accès Internet pour un cluster ACK existant.
Erreurs RCUStallError	Si des erreurs RCUStallError sont présentes dans le noyau du nœud. Ces erreurs indiquent qu'un cœur de CPU est bloqué dans une section critique read-copy-update (RCU), ce qui peut provoquer le blocage du nœud.	Soumettre un ticket.
Versions du système d'exploitation	La version du système d'exploitation utilisée par le nœud. Les versions obsolètes du système d'exploitation peuvent empêcher le cluster de fonctionner normalement.	Aucun.
Fuites de processus runc	Si des fuites de processus runc se produisent. Les fuites de processus runc peuvent amener le nœud à entrer périodiquement dans l'état NotReady.	Identifiez les processus runc ayant fui et terminez-les manuellement.
Erreurs SoftLockupError	Si des erreurs SoftLockupError sont présentes dans le noyau du nœud. Elles indiquent qu'un cœur de CPU ne répond pas aux interruptions, ce qui peut provoquer une instabilité du nœud.	Soumettre un ticket.
Blocages systemd	Si des blocages systemd se produisent. Un systemd bloqué peut empêcher le démarrage ou l'arrêt des services, affectant la stabilité du nœud.	Connectez-vous au nœud et exécutez `systemctl daemon-reexec` pour redémarrer systemd.
Versions systemd obsolètes	Si la version de systemd présente des bugs connus. Les versions obsolètes peuvent provoquer un dysfonctionnement de Docker et de containerd.	Mettez à jour la version de systemd. Consultez systemd.
Processus bloqués	Si des processus bloqués existent sur le nœud. Les processus bloqués consomment des ressources sans progression et dégradent les performances du nœud.	Soumettre un ticket.
Erreurs unregister_netdevice	Si des erreurs unregister_netdevice sont présentes dans le noyau du nœud. Elles peuvent provoquer des fuites de ressources du noyau et une instabilité du réseau.	Soumettre un ticket.

NodeComponent

Élément de diagnostic	Ce qui est détecté	Correctif
État du composant CNI	Si le plugin Container Network Interface (CNI) fonctionne comme prévu. Un plugin CNI défaillant arrête la mise en réseau des pods sur le nœud.	Vérifiez l'état du composant réseau du cluster. Consultez FAQ sur la gestion du réseau.
État du composant CSI	Si le plugin Container Storage Interface (CSI) fonctionne comme prévu. Un plugin CSI défaillant empêche les pods de monter des volumes.	Vérifiez l'état du composant de stockage du cluster. Consultez FAQ sur CSI.

ClusterComponent

Élément de diagnostic	Ce qui est détecté	Correctif
Version de aliyun-acr-credential-helper	Si la version du composant aliyun-acr-credential-helper est obsolète.	Mettez à jour aliyun-acr-credential-helper. Consultez Utiliser le composant aliyun-acr-credential-helper pour tirer des images sans utiliser de secret.
Disponibilité du service API	Si le service API du cluster est disponible. Un service API indisponible bloque les opérations de gestion des charges de travail.	Exécutez `kubectl get apiservice` pour vérifier la disponibilité. Si indisponible, exécutez `kubectl describe apiservice` pour identifier la cause.
Blocs CIDR de pod disponibles insuffisants	Si le nombre de blocs CIDR de pod disponibles dans un cluster Flannel est inférieur à cinq. Chaque nœud nécessite un bloc CIDR de pod ; si tous les blocs sont utilisés, les nouveaux nœuds ne peuvent pas rejoindre le cluster.	Soumettre un ticket.
Points de terminaison CoreDNS	Le nombre de points de terminaison CoreDNS actifs. Trop peu de points de terminaison réduisent la disponibilité du DNS.	Vérifiez l'état et les journaux des pods CoreDNS. Consultez Dépannage DNS.
Adresses IP de cluster CoreDNS	Si des adresses IP de cluster sont attribuées aux pods CoreDNS. Sans IP de cluster, les requêtes DNS ne peuvent pas atteindre CoreDNS, provoquant des échecs DNS à l'échelle du service.	Vérifiez l'état et les journaux des pods CoreDNS. Consultez Dépannage DNS.
État de la passerelle NAT	Si la passerelle NAT du cluster fonctionne normalement. Une passerelle NAT défaillante bloque le trafic Internet sortant des nœuds sans IP publique.	Connectez-vous à la console NAT Gateway et vérifiez si la passerelle est verrouillée en raison de paiements en retard.
Taux excessivement élevé d'abandons de connexions simultanées sur la passerelle NAT	Si la passerelle NAT abandonne un taux anormalement élevé de connexions simultanées. Des taux d'abandon élevés indiquent que la passerelle a atteint sa capacité de connexion.	Mettez à niveau la passerelle NAT. Consultez FAQ sur la mise à niveau des passerelles NAT Internet standard vers des passerelles NAT Internet améliorées.

ECSControllerManager

Élément de diagnostic	Ce qui est détecté	Correctif
Paiements en retard liés aux composants de l'instance ECS	Si le disque ou la bande passante réseau de l'instance est restreint en raison de paiements en retard. Les ressources restreintes peuvent provoquer des échecs de charge de travail.	Rechargez votre compte pour rétablir l'accès.
Paiements en retard liés à l'instance ECS	Si l'instance ECS à la demande a été suspendue en raison de paiements en retard.	Rechargez votre compte, puis redémarrez l'instance.
État de la carte réseau de l'instance ECS	Si la carte réseau (NIC) de l'instance fonctionne normalement. Une NIC anormale provoque une perte de connectivité réseau.	Redémarrez l'instance.
État de démarrage de l'instance ECS	Si l'instance peut démarrer normalement.	Si le démarrage échoue, créez une nouvelle instance.
État du système de gestion backend de l'instance ECS	Si le système de gestion backend de l'instance fonctionne normalement.	Redémarrez l'instance.
État des CPU de l'instance ECS	Si une contention CPU ou des échecs de liaison CPU existent au niveau sous-jacent de l'instance. La contention CPU peut empêcher l'instance d'acquérir des ressources CPU et dégrader les performances.	Redémarrez l'instance.
Verrous fractionnés dans les CPU de l'instance ECS	Si des verrous fractionnés se produisent dans les CPU de l'instance ECS. Les verrous fractionnés peuvent sévèrement dégrader les performances du CPU.	Consultez Détection et gestion des verrous fractionnés.
État de l'atténuation DDoS pour l'instance ECS	Si l'adresse IP publique de l'instance subit une attaque DDoS.	Achetez un service anti-DDoS. Consultez Comparaison des solutions Alibaba Cloud Anti-DDoS.
Capacités de lecture/écriture limitées du disque cloud	Si le débit de lecture/écriture du disque cloud est limité. La limitation se produit lorsque le maximum d'IOPS est atteint, ralentissant ou mettant en file d'attente les opérations d'E/S.	Consultez Performances du stockage par blocs.
Chargement du disque de l'instance ECS	Si le disque cloud peut être attaché au démarrage de l'instance.	Arrêtez l'instance et redémarrez-la.
Expiration de l'instance ECS	Si l'instance par abonnement a expiré. Une instance expirée est arrêtée et ses ressources deviennent indisponibles.	Renouvelez l'instance. Consultez Renouveler une instance par abonnement.
Plantages du système d'exploitation de l'instance ECS	Si des plantages du système d'exploitation se sont produits au cours des dernières 48 heures.	Consultez les journaux système pour identifier la cause. Consultez Afficher les journaux système et les captures d'écran.
État de l'hôte de l'instance ECS	Si le serveur physique hébergeant l'instance présente des défaillances. Les défaillances de l'hôte peuvent dégrader les performances de l'instance.	Redémarrez l'instance.
Chargement de l'image de l'instance ECS	Si l'instance peut charger son image lors de l'initialisation.	Redémarrez l'instance.
Blocages d'E/S sur le disque de l'instance ECS	Si des blocages d'E/S se produisent sur le disque système. Les blocages d'E/S disque peuvent rendre le système d'exploitation non réactif.	Vérifiez les métriques du disque. Consultez Afficher les données de surveillance d'un disque cloud. Pour Alibaba Cloud Linux 2, consultez Détecter les blocages d'E/S des systèmes de fichiers et des couches de blocs.
Limite supérieure de la bande passante de l'instance ECS	Si la bande passante totale de l'instance a atteint le maximum pour son type d'instance. Lorsque la limite est atteinte, le débit réseau est plafonné et des paquets peuvent être perdus.	Passez à un type d'instance avec une bande passante plus élevée. Consultez Aperçu des modifications de configuration des instances.
Limite supérieure de la bande passante burst de l'instance ECS	Si la bande passante burst de l'instance a dépassé le maximum autorisé pour son type d'instance.	Passez à un type d'instance avec une bande passante plus élevée. Consultez Aperçu des modifications de configuration des instances.
Chargement de la NIC de l'instance ECS	Si la NIC peut être chargée sur l'instance. Si la NIC ne parvient pas à se charger, l'instance perd la connectivité réseau.	Redémarrez l'instance.
Établissement de session NIC sur l'instance ECS	Si des sessions peuvent être établies vers la NIC. Si la NIC ne peut pas établir de sessions ou a atteint sa limite de sessions, la connectivité ou le débit réseau est affecté.	Redémarrez l'instance.
Opérations clés sur l'instance ECS	Si les opérations récentes sur l'instance — telles que le démarrage, l'arrêt ou la mise à niveau — se sont terminées avec succès.	Réessayez l'opération ayant échoué.
Perte de paquets sur la NIC de l'instance ECS	Si une perte de paquets entrants ou sortants se produit sur la NIC. La perte de paquets provoque des erreurs réseau et peut perturber les services.	Redémarrez l'instance.
Dégradation des performances de l'instance ECS	Si les performances de l'instance ont été temporairement dégradées en raison de problèmes logiciels ou matériels.	Consultez les événements historiques ou les journaux système de l'instance pour identifier la cause. Consultez Afficher les événements système historiques.
Performances compromises de l'instance ECS	Si les performances de l'instance sont réduites. Des crédits CPU insuffisants amènent les instances éclatables à revenir aux performances de base.	L'instance ECS ne peut fournir que les performances de base en raison de crédits CPU disponibles insuffisants.
Redimensionnement du disque de l'instance ECS	Si le disque a été redimensionné mais que le système d'exploitation n'a pas encore étendu le système de fichiers. L'espace disque supplémentaire est indisponible jusqu'à ce que le système de fichiers soit redimensionné.	Le système d'exploitation ne redimensionne pas automatiquement le système de fichiers après le redimensionnement du disque. Si le disque reste inutilisable, redimensionnez-le à nouveau.
Demande de ressources de l'instance ECS	Si suffisamment de ressources CPU physiques et de mémoire sont disponibles pour l'instance. Si les ressources sont insuffisantes, l'instance ne peut pas démarrer.	Attendez quelques minutes et essayez de démarrer l'instance à nouveau. Si le problème persiste, créez une instance dans une autre région.
État du système d'exploitation de l'instance ECS	Si des paniques du noyau, des erreurs OOM ou des défaillances internes se sont produites dans le système d'exploitation de l'instance. Elles sont souvent causées par des paramètres mal configurés ou des programmes utilisateur.	Redémarrez l'instance.
État de virtualisation de l'instance ECS	Si des exceptions existent dans la couche de virtualisation sous-jacente. Elles peuvent amener l'instance à cesser de répondre ou à être suspendue de manière inattendue.	Redémarrez l'instance.

GPUNode

Élément de diagnostic	Ce qui est détecté	Correctif
Runtime de conteneur	Si le runtime de conteneur sur le nœud accéléré par GPU est valide. ACK prend uniquement en charge Docker et containerd pour les nœuds accélérés par GPU.	Vérifiez l'état du runtime Docker ou containerd sur le nœud.
Version de NVIDIA-Container-Runtime	Si la version de NVIDIA-Container-Runtime est compatible avec le cluster. Un NVIDIA-Container-Runtime incompatible ou manquant empêche le démarrage des conteneurs GPU.	1. Vérifiez si la version de NVIDIA-Container-Runtime correspond à la version Kubernetes du cluster. Consultez Notes de version des versions Kubernetes. 2. Si le problème persiste, collectez les données de diagnostic et soumettez un ticket. Consultez Collecter des données de diagnostic à partir des nœuds accélérés par GPU.
État du module cGPU	Si le module cGPU fonctionne comme prévu sur les nœuds avec le partage GPU activé.	1. Vérifiez si le composant cGPU est installé. Consultez Installer le composant de partage GPU. 2. Si le module échoue toujours, collectez les données de diagnostic et soumettez un ticket. Consultez Collecter des données de diagnostic à partir des nœuds accélérés par GPU.
Configurations du runtime de conteneur	Si le runtime de conteneur sur le nœud accéléré par GPU est correctement configuré. Une mauvaise configuration empêche l'exécution des conteneurs GPU.	Vérifiez si le champ `nvidia-container-runtime` est spécifié dans le fichier de configuration du runtime : Docker — `/etc/docker/daemon.json` ; containerd — `/etc/containerd/config.toml`.
État de NVIDIA-Container-Runtime	Si NVIDIA-Container-Runtime fonctionne comme prévu.	Collectez les données de diagnostic et soumettez un ticket. Consultez Collecter des données de diagnostic à partir des nœuds accélérés par GPU.
État du module NVIDIA	Si le module noyau NVIDIA fonctionne comme prévu sur le nœud accéléré par GPU. Un module NVIDIA défaillant empêche l'exécution de toutes les charges de travail GPU.	1. Diagnostiquez le nœud accéléré par GPU. Consultez FAQ GPU. 2. Collectez les données de diagnostic et soumettez un ticket. Consultez Collecter des données de diagnostic à partir des nœuds accélérés par GPU.