Examiner l’intégrité des nœuds et des pods

Cet article fait partie d’une série. Commencez par la vue d’ensemble.

Si les vérifications du cluster effectuées à l’étape précédente sont claires, vérifiez l’intégrité des nœuds Worker d’Azure Kubernetes Service (AKS). Suivez les six étapes de cet article pour vérifier l’intégrité des nœuds, déterminer la raison d’un nœud non sain et résoudre le problème.

Étape 1 : vérifier l’intégrité des nœuds Worker

Divers facteurs peuvent contribuer à des nœuds non sains dans un cluster AKS. Une défaillance de communication entre le plan de contrôle et les nœuds est une raison courante. Cette mauvaise communication est souvent provoquée par des configurations incorrectes dans les règles de pare-feu et de routage.

Lorsque vous configurez votre cluster AKS pour le routage défini par l’utilisateur, vous devez configurer des chemins de sortie via une appliance virtuelle réseau (NVA) ou un pare-feu tel qu’un pare-feu Azure. Pour résoudre le problème de configuration incorrecte, nous vous recommandons de configurer le pare-feu pour autoriser les noms de domaine complets (FQDN) et les ports nécessaires en fonction des conseils relatifs au trafic de sortie AKS.

Il est possible qu’un calcul, qu’une mémoire ou que des ressources de stockage incorrects qui créent des pressions kubelet soient l’autre raison de nœuds non sains. Dans de tels cas, effectuer une mise à l’échelle des ressources peut résoudre le problème de manière efficace.

Dans un cluster AKS privé, des problèmes de résolution DNS (Domain Name System) peuvent provoquer une communication problématique entre le plan de contrôle et les nœuds. Vous devez vérifier que le nom DNS du serveur d’API Kubernetes résout l’adresse IP privée du serveur d’API. La configuration incorrecte d’un serveur DNS personnalisé est la cause courante des échecs de résolution DNS. Si vous utilisez des serveurs DNS personnalisés, veillez à les spécifier correctement en tant que serveurs DNS sur le réseau virtuel où les nœuds sont approvisionnés. Confirmez également que le serveur d’API privé AKS peut être résolu via le serveur DNS personnalisé.

Après la résolution de ces problèmes possibles liés à la communication du plan de contrôle et à la résolution DNS, vous pouvez vous attaquer aux problèmes d’intégrité des nœuds et les résoudre dans votre cluster AKS.

Vous pouvez évaluer l’intégrité de vos nœuds en utilisant l’une des méthodes suivantes.

Affichage de l’intégrité des conteneurs Azure Monitor

Pour afficher l’intégrité des nœuds, des pods utilisateur et des pods système dans votre cluster AKS, suivez ces étapes :

1. Dans le Portail Azure, accédez à Azure Monitor.
2. Dans la section Insights du volet de navigation, sélectionnez Conteneurs.
3. Sélectionnez Clusters monitorés pour obtenir la liste des clusters AKS monitorés.
4. Choisissez le cluster AKS à partir de la liste pour afficher l’intégrité des nœuds, des pods utilisateur et des pods système.

Affichage des nœuds AKS

Pour veiller à ce que tous les nœuds de votre cluster AKS soient dans l’état Prêt, suivez ces étapes :

1. Dans le Portail Azure, accédez à votre cluster AKS.
2. Dans la section Paramètres du volet de navigation, sélectionnez Pools de nœuds.
3. Sélectionner Nœuds.
4. Vérifiez que tous les nœuds sont dans un état Prêt.

Monitoring dans des clusters avec Prometheus et Grafana

Si vous avez déployé Prometheus et Grafana dans votre cluster AKS, vous pouvez utiliser le Tableau de bord des détails du cluster K8 pour obtenir des insights. Ce tableau de bord montre les mesures de cluster Prometheus et présente des informations vitales, telles que l’utilisation du processeur, l’utilisation de la mémoire, l’activité du réseau et l’utilisation du système de fichiers. Il présente également des statistiques détaillées pour des services systemd, des conteneurs et des pods individuels.

Dans le tableau de bord, sélectionnez Conditions de nœud pour afficher des mesures sur l’intégrité et le niveau de performance de votre cluster. Vous pouvez suivre des nœuds qui peuvent avoir des problèmes, tels que ceux liés à la planification, au réseau, à la pression de disque, à la pression de mémoire, à la pression PID (proportionnel, intégral, dérivé) ou à l’espace disque. Monitorez ces mesures afin d’identifier et de résoudre proactivement les problèmes éventuels qui affectent la disponibilité et le niveau de performance de votre cluster AKS.

Monitorer un service managé pour Prometheus et Azure Managed Grafana

Vous pouvez utiliser des tableaux de bord prédéfinis pour visualiser et analyser des mesures Prometheus. Pour ce faire, vous devez configurer votre cluster AKS pour collecter des mesures Prometheus dans Service Azure Monitor géré pour Prometheus et connectez votre Espace de travail Azure Monitor à un espace de travail Azure Managed Grafana. Ces tableaux de bord fournissent une vue complète du niveau de performance et de l’intégrité de votre cluster Kubernetes.

Les tableaux de bord sont approvisionnés dans l’instance Azure Managed Grafana spécifiée dans le dossier Prometheus managé. Certains tableaux de bord comprennent :

• Kubernetes / Ressources de calcul / Cluster
• Kubernetes / Ressources de calcul / Espace de noms (pods)
• Kubernetes / Ressources de calcul / Nœud (pods)
• Kubernetes / Ressources de calcul / Pod
• Kubernetes / Ressources de calcul / Espace de noms (charges de travail)
• Kubernetes / Ressources de calcul / Charge de travail
• Kubernetes / Kubelet
• Exportateur de nœuds / Méthode USE / Nœud
• Exportateur de nœuds / Nœuds
• Kubernetes / Ressources de calcul / Cluster (Windows)
• Kubernetes / Ressources de calcul / Espace de noms (Windows)
• Kubernetes / Ressources de calcul / Pod (Windows)
• Kubernetes / Méthode USE / Cluster (Windows)
• Kubernetes / Méthode USE / Nœud (Windows)

Ces tableaux de bord intégrés sont largement utilisés dans la communauté open source pour la surveillance des clusters Kubernetes avec Prometheus et Grafana. Utilisez ces tableaux de bord pour voir des mesures, telles que l’utilisation de la ressource, l’intégrité du pod et l’activité réseau. Vous pouvez également créer des tableaux de bord personnalisés adaptés à vos besoins en matière de monitoring. Les tableaux de bord vous aident à surveiller et analyser efficacement des mesures Prometheus dans votre cluster AKS, ce qui vous permet d’optimiser le niveau de performance, de résoudre des problèmes et de veiller à une opération fluide de vos charges de travail Kubernetes.

Vous pouvez utiliser le tableau de bord Kubernetes / Ressources de calcul / Nœud (pods) pour afficher des mesures pour des nœuds de l’agent Linux. Vous pouvez visualiser l’utilisation du processeur, le quota du processeur, l’utilisateur de la mémoire et le quota de mémoire de chaque pod.

Si votre cluster inclut des nœuds d’agent Windows, vous pouvez utiliser le tableau de bord Kubernetes / Ressources de calcul / Nœud (Windows) pour visualiser les mesures Prometheus collectées à partir de ces nœuds. Ce tableau de bord fournit un affichage complet du niveau de performance et de la consommation de la ressource pour des nœuds Windows au sein de votre cluster.

Tirez parti de ces tableaux de bord dédiés afin de pouvoir facilement monitorer et analyser des mesures importantes liées au processeur, à la mémoire et à d’autres ressources dans des nœuds d’agent Windows et Linux. Cette visibilité vous permet d’identifier des goulots d’étranglement éventuels, d’optimiser l’allocation des ressources et de veiller à une opération efficace dans tout votre cluster AKS.

Étape 2 : vérifier la connectivité du plan de contrôle et du nœud Worker

Si les nœuds Worker sont sains, vous devez examiner la connectivité entre le plan de contrôle AKS géré et les nœuds Worker du cluster. AKS permet une communication entre le serveur d’API Kubernetes et des kubelets de nœuds individuels via une méthode de communication de tunnel sécurisée. Ces composants peuvent communiquer, même s’ils se trouvent sur différents réseaux virtuels. Le tunnel est protégé avec un chiffrement mTLS (Mutual Transport Layer Security). Le tunnel principal utilisé par AKS est appelé Konnectivity (précédemment appelé apiserver-network-proxy). Veillez à ce que tous les FQDN et toutes les règles de réseau respectent les règles de réseau Azure requises.

Pour vérifier la connectivité entre le plan de contrôle AKS géré et les nœuds Worker de cluster d’un cluster AKS, vous pouvez utiliser l’outil de ligne de commande kubectl.

Si vous souhaitez veiller au fonctionnement approprié des pods d’agent Konnectivity, exécutez la commande suivante :

kubectl get deploy konnectivity-agent -n kube-system

Vérifiez que les pods sont dans un état Prêt.

S’il existe un problème de connectivité entre les pl et les nœuds Worker, établissez la connectivité après avoir vérifié que les règles de trafic de sortie AKS requises sont autorisées.

Exécutez ensuite la commande suivante pour redémarrer les pods konnectivity-agent :

kubectl rollout restart deploy konnectivity-agent -n kube-system

Si le redémarrage des pods ne corrige pas la connexion, consultez les journaux pour rechercher des anomalies. Exécutez la commande suivante pour afficher les journaux des pods konnectivity-agent :

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

Les journaux doivent montrer la sortie suivante :

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

Vous pouvez également rechercher les journaux de conteneur dans le service de journalisation et de monitoring pour récupérer les journaux. Pour obtenir un exemple qui recherche les erreurs de connectivité aks-link, voir Interroger des journaux à partir de Container Insights.

Exécutez la requête suivante pour récupérer les journaux :

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

Exécutez la requête suivante afin de rechercher dans les journaux de conteneur tout pod ayant échoué dans un espace de noms spécifique :

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

Si vous n’obtenez pas les journaux en utilisant les requêtes ou l’outil kubectl, utilisez l’authentification Secure Shell (SSH). Cet exemple recherche le pod tunnelfront après connexion au nœud via SSH.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

Étape 3 : valider la résolution DNS lors d’une restriction de sortie

La résolution DNS est un aspect essentiel de votre cluster AKS. Si la résolution DNS ne fonctionne pas correctement, elle peut entraîner des erreurs de plan de contrôle ou des échecs d’extraction d’images de conteneur. Pour veiller au fonctionnement correct de la résolution DNS vers le serveur d’API Kubernetes, suivez ces étapes :

1. Exécutez la commande kubectl exec pour ouvrir un interpréteur de commandes dans le conteneur s’exécutant dans le pod.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. Vérifiez si les outils nslookup ou dig sont installés dans le conteneur.

3. Si aucun des outils n’est installé dans le pod, exécutez la commande suivante pour créer un pod utilitaire dans le même espace de noms.

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. Vous pouvez récupérer l’adresse du serveur d’API à partir de la page de vue d’ensemble de votre cluster AKS dans le Portail Azure ou vous pouvez exécuter la commande suivante.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. Exécutez la commande suivante pour tenter de résoudre le serveur d’API AKS. Si vous souhaitez obtenir plus d’informations, voir Résoudre les échecs de résolution DNS à partir du pod, mais pas à partir du nœud Worker.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. Vérifiez le serveur DNS en amont à partir du pod pour veiller à ce que la résolution DNS fonctionne correctement. Par exemple, pour Azure DNS, exécutez la commande nslookup.

   nslookup microsoft.com 168.63.129.16
   

7. Si les étapes précédentes ne fournissent pas d’insights, connectez-vous à l’un des nœuds Worker, puis tentez la résolution DNS à partir du nœud. Cette étape permet d’identifier si le problème est lié à AKS ou à la configuration de mise en réseau.

8. Si la résolution DNS est réussie à partir du nœud, mais pas à partir du pod, il est possible que le problème soit lié au DNS Kubernetes. Pour découvrir les étapes pour déboguer une résolution DNS à partir du pod, voir Résoudre les échecs de résolution DNS.

   Si une résolution DNS échoue à partir du nœud, examinez la configuration de mise en réseau pour vérifier que les chemins de routage et les ports appropriés sont ouverts pour faciliter la résolution DNS.

Étape 4 : rechercher les erreurs de kubelet

Vérifiez la condition du processus kubelet qui s’exécute sur chaque nœud Worker et veillez à ce qu’il ne soit pas sous pression. Il est possible qu’une pression se rapporte au processeur, à la mémoire ou au stockage. Si vous souhaitez vérifier l’état des kubelets de nœuds individuels, vous pouvez utiliser l’une des méthodes suivantes.

Classeur de kubelets AKS

Pour veiller à ce que les kubelets de nœud d’agent fonctionnent correctement, suivez ces étapes :

1. Accédez à votre cluster AKS dans le Portail Azure.

2. Sélectionnez Classeurs dans la section Monitoring du volet de navigation.

3. Sélectionnez le classeur Kubelet.

   

4. Sélectionnez Opérations et vérifiez que les opérations de tous les nœuds Worker sont terminées.

   

Monitoring dans des clusters avec Prometheus et Grafana

Si vous avez déployé Prometheus et Grafana dans votre cluster AKS, vous pouvez utiliser le tableau de bord Kubernetes / Kubelet pour obtenir des insights sur l’intégrité et le niveau de performance des kubelets de nœuds individuels.

Monitorer un service managé pour Prometheus et Azure Managed Grafana

Vous pouvez utiliser le tableau de bord prédéfini Kubernetes / Kubelet pour visualiser et analyser les mesures Prometheus pour les kubelets de nœud Worker. Pour ce faire, vous devez configurer votre cluster AKS pour collecter des mesures Prometheus dans Service Azure Monitor géré pour Prometheus et connectez votre Espace de travail Azure Monitor à un espace de travail Azure Managed Grafana.

La pression augmente au redémarrage de kubelet et entraîne un comportement sporadique et imprévisible. Vérifiez que le nombre d’erreurs n’augmente pas continuellement. Une erreur occasionnelle est acceptable, mais une croissance constante indique un problème sous-jacent que vous devez examiner et résoudre.

Étape 5 : utiliser l’outil détecteur de problèmes de nœud (NPD) pour vérifier l’intégrité du nœud

NDP est un outil Kubernetes que vous pouvez utiliser pour identifier et signaler des problèmes liés au nœud. Il fonctionne en tant que service systemd sur chaque nœud dans le cluster. Il regroupe les informations système et les mesures, telles que l’utilisation du processeur, l’utilisation du disque et l’état de la connectivité réseau. En cas de détection d’un problème, l’outil NDP génère un rapport sur les événements et la condition du nœud. Dans AKS, l’outil NDP est utilisé pour monitorer et gérer des nœuds dans un cluster Kubernetes hébergé sur le cloud Azure. Pour obtenir plus d’informations, consultez NDP dans des nœuds AKS.

Étape 6 : vérifier les opérations d’entrée/sortie par seconde (IOPS) du disque pour la limitation

Pour vérifier que les IOPS ne sont pas limitées et qu’elles n’affectent pas les services et charges de travail au sein de votre cluster AKS, vous pouvez utiliser l’une des méthodes suivantes.

Classeur d’entrée/sortie du disque de nœud AKS

Pour monitorer les mesures liées aux opérations d’entrée/sortie du disque des nœuds Worker dans votre cluster AKS, vous pouvez utiliser le classeur entrée/sortie du disque de nœud. Suivez ces étapes pour accéder au classeur :

1. Accédez à votre cluster AKS dans le Portail Azure.

2. Sélectionnez Classeurs dans la section Monitoring du volet de navigation.

3. Sélectionnez le classeur Entrée/sortie du disque de nœud.

   

4. Examinez les mesures relatives aux entrée/sorties.

   

Monitoring dans des clusters avec Prometheus et Grafana

Si vous avez déployé Prometheus et Grafana dans votre cluster AKS, vous pouvez utiliser le tableau de bord Node / Méthode USE afin d’obtenir des insights sur les entrées/sorties du disque pour les nœuds Worker du cluster.

Monitorer un service managé pour Prometheus et Azure Managed Grafana

Vous pouvez utiliser le tableau de bord Exportateur de nœud / Nœuds prédéfini pour visualiser et analyser des mesures relatives aux entrées/sorties du disque à partir des nœuds Worker. Pour ce faire, vous devez configurer votre cluster AKS pour collecter des mesures Prometheus dans Service Azure Monitor géré pour Prometheus et connectez votre Espace de travail Azure Monitor à un espace de travail Azure Managed Grafana.

IOPS et disques Azure

Les périphériques de stockage physiques ont des limitations inhérentes en termes de bande passante et du nombre maximal d’opérations sur les fichiers qu’ils peuvent traiter. Les disques Azure sont utilisés pour stocker le système d’exploitation qui s’exécute sur des nœuds AKS. Les disques sont soumis aux mêmes contraintes physiques que le système d’exploitation.

Envisagez le concept de débit. Vous pouvez multiplier la taille moyenne d’entrée/sortie par les IOPS pour déterminer le débit en mégabits par seconde (Mbits/s). Des tailles d’entrée/sortie plus volumineuses se traduisent par des IOPS inférieures en raison du débit fixe du disque.

Quand une charge de travail dépasse les limites maximales du service d’IOPS affectées aux disques Azure, il est possible que le cluster cesse de répondre et entre dans un état d'attente d’entrée/sortie. Dans des systèmes basés sur Linux, plusieurs composants sont traités comme des fichiers, tels que des sockets réseau, CNI, Docker et d’autres services qui s’appuient sur une entrée/sortie réseau. Par conséquent, si le disque ne peut pas être lu, la défaillance s’étend à tous ces fichiers.

Plusieurs événements et scénarios peuvent déclencher une limitation d’IOPS, notamment :

• Un nombre considérable de conteneurs qui s’exécutent sur des nœuds, car l’entrée/sortie Docker partage le disque du système d’exploitation.

• Des outils tiers ou personnalisés qui sont utilisés pour la sécurité, le monitoring et la journalisation, ce qui peut générer des opérations d’entrée/sortie supplémentaires sur le disque du système d’exploitation.

• Des événements de basculement de nœuds et des travaux périodiques qui intensifient la charge de travail ou mettent à l’échelle le nombre de pods. Cette charge accrue augmente le risque d’occurrences de limitation, entraînant éventuellement la transition de tous les nœuds vers un état Pas prêt jusqu’à la fin des opérations d’entrée/sortie.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Principaux auteurs :

• Paolo Salvatori | Ingénieur client principal
• Francis Simy Nazareth | Spécialiste technique senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Limites du nombre de disques de machine virtuelle
• Performances des disques et des machines virtuelles

Ressources associées