Introduction

Avec Auto Mode, AWS gère l'intégralité du produit EKS pour vous : création des noeuds, autoscaling, réseau, stockage et mises à jour de sécurité. Fini les node groups à configurer, les add-ons à maintenir et les patchs de sécurité à gérer.

Les instances EC2 du cluster sont gérées via des configurations Karpenter. Leurs AMI sont immuables, leurs systèmes de fichiers racine sont en lecture seule, et elles sont automatiquement remplacées tous les 21 jours maximum.

Mais cette simplification a un revers : plus de SSH, plus de SSM, plus d'accès direct aux noeuds.

Pas de panique. AWS expose plusieurs outils pour diagnostiquer vos clusters sans accès direct aux noeuds. Voici lesquels et comment les utiliser.

NodeDiagnostic - la méthode recommandée

Le Node Monitoring Agent (NMA) est pré-installé sur chaque noeuds Auto Mode. Il expose une CRD NodeDiagnostic qui permet de collecter les logs système sans jamais toucher au noeuds.

Quand vous créez une ressource NodeDiagnostic nommée d'après un noeuds, l'agent détecte la création, rassemble les logs (kubelet, containerd, syslog, etc.) en une archive, et la dépose à la destination spécifiée.

Destination S3

L'approche historique consiste à générer une URL pré-signée S3 et à la passer dans le spec :

apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
  name: i-01234567890123456
spec:
  logCapture:
    destination: https://mon-bucket.s3.amazonaws.com/...

Le noeud téléverse l'archive directement sur S3.
Vous n'avez même pas besoin de récupérer le fichier depuis le noeud.

Destination node (kubectl ekslogs)

Depuis la version v1.6.1-eksbuild.1 du NMA (disponible sur Auto Mode AMI 2026.3.11+), la destination peut être le système de fichier local du noeud. L'archive est stockée temporairement sur le noeud et récupérée via l'API node/proxy de kubelet.

AWS a publié un plugin kubectl qui automatise toute cette chaîne :

# Installation
curl -LO https://raw.githubusercontent.com/aws/eks-node-monitoring-agent/refs/heads/main/tools/kubectl-ekslogs/kubectl-ekslogs
chmod +x kubectl-ekslogs
sudo mv kubectl-ekslogs /usr/local/bin/

# Collecte des logs d'un noeud
kubectl ekslogs i-01234567890123456

# Collecte de tous les noeuds d'un node group
kubectl ekslogs -l eks.amazonaws.com/nodegroup=mon-node-group

# Upload direct sur S3
kubectl ekslogs --s3 mon-bucket --key logs/2026-06 i-01234567890123456

Ce que contient l'archive :

• Logs kubelet (journald)
• Logs containerd
• Configuration kubelet
• État des pods et containers
• Métriques de performance de base
• Logs système (/var/log/messages, dmesg)
• Logs des add-ons préinstallés (VPC CNI, kube-proxy, CoreDNS, EBS CSI Driver, EKS Pod Identity Agent)

kubectl debug node — inspection interactive

Si vous avez besoin de voir ce qui se passe en direct (et pas seulement des logs passés), utilisez kubectl debug node.
Cette commande lance un pod éphémère sur le noeud cible avec un shell interactif :

kubectl debug node/i-01234567890123456 \
  -it \
  --profile=sysadmin \
  --image=public.ecr.aws/amazonlinux/amazonlinux:2023

Une fois dans le shell :

# Installer nsenter pour accéder au namespace mount du host
yum install -y util-linux-core

# Streamer les logs kubelet en direct
nsenter -t 1 -m journalctl -f -u kubelet

# Voir les logs containerd
nsenter -t 1 -m journalctl -f -u containerd

# Vérifier la résolution DNS
nsenter -t 1 -n nslookup amazon.com 127.0.0.53

# Inspecter la configuration réseau
nsenter -t 1 -n ip addr
nsenter -t 1 -n iptables -L -n

Le profil sysadmin monte automatiquement les volumes host nécessaires ( /var/log, /var/lib/kubelet, etc.) avec les bons droits.
C'est l'équivalent d'un SSH sans en être un.

Node conditions et events — la surveillance intégrée

Avant même de collecter des logs, regardez l'état de santé de vos noeuds. Le NMA publie automatiquement des conditions et des events Kubernetes qu'il faut savoir lire.

Conditions (problèmes graves)

# Voir les conditions de tous les noeuds
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'

# Détail d'un noeud spécifique
kubectl describe node i-01234567890123456

Les conditions typiques : DiskPressure, MemoryPressure, PIDPressure, NetworkUnavailable. Toute condition à True signale un problème nécessitant action.

Events (alertes temporaires)

# Tous les événements NMA
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent

# Événements d'un noeud spécifique
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=i-01234567890123456

# Surveiller en temps réel
kubectl get events -w --field-selector involvedObject.kind=Node

Le NMA détecte automatiquement des problèmes comme :

• Attachement EBS qui échoue
• Sous-réseau supprimé
• Problème de connectivité réseau
• Échec de join du noeud au cluster

CloudWatch Container Insights — la vue d'ensemble

Pour une observabilité continue, activez Container Insights.
Il déploie un agent CloudWatch en DaemonSet et Fluent Bit pour la collecte de logs.

Log groups créés automatiquement :

Container Insights fournit aussi des dashboards prêts à l'emploi dans CloudWatch, avec des métriques au niveau cluster, noeud et pod. C'est la solution recommandée par AWS pour le monitoring de production.

Pour les clusters Auto Mode spécifiquement, les logs CoreDNS sont particulièrement utiles : chaque noeud exécute sa propre instance CoreDNS en processus systemd (pas en pod), et les logs sont dans /var/log/journal.

Diagnostic DNS

Les problèmes DNS sont fréquents sur EKS. Avec Auto Mode, chaque noeud a son CoreDNS local (résolution sans quitter le noeud), ce qui change la donne.

Pour vérifier la résolution DNS depuis un noeud Auto Mode :

# Lancer un debug container
kubectl debug node/i-01234567890123456 -it --profile=sysadmin \
  --image=public.ecr.aws/amazonlinux/amazonlinux:2023

# Tester la résolution
yum install -y bind-utils
nsenter -t 1 -n nslookup amazon.com 127.0.0.53
nsenter -t 1 -n nslookup kubernetes.default.svc.cluster.local 127.0.0.53

# Voir les logs CoreDNS
nsenter -t 1 -m journalctl -f -u coredns

Si CoreDNS ne répond pas, vérifiez que le nameserver défini dans /etc/resolv.conf du noeud (géré par Auto Mode) est bien 127.0.0.53.

Check-list de diagnostic rapide

Quand un pod ne démarre pas ou qu'un noeud est NotReady, voici les commandes à exécuter dans l'ordre :

# 1. État général du cluster
kubectl get nodes
kubectl get pods --all-namespaces | grep -v Running | grep -v Completed

# 2. Description du pod problématique
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

# 3. Événements récents
kubectl get events --all-namespaces --sort-by='.lastTimestamp' | tail -20

# 4. Événements NMA (si noeud anormal)
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent

# 5. Conditions du noeud
kubectl describe node <node-name>

# 6. Collecte des logs du noeud
kubectl ekslogs <node-name>

# 7. Inspection interactive si nécessaire
kubectl debug node/<node-name> -it --profile=sysadmin \
  --image=public.ecr.aws/amazonlinux/amazonlinux:2023

En résumé

EKS Auto Mode supprime l'accès direct aux noeuds, mais ce n'est pas un problème si vous maîtrisez les bons outils :

L'outil kubectl ekslogs est le plus pratique au quotidien. Installez-le dès maintenant dans votre toolchain — il vous sauvera des heures à ne pas ouvrir de ticket AWS Support.

Sources

• Amazon EKS Auto Mode — documentation AWS
• Troubleshoot EKS Auto Mode
• Retrieve node logs for a managed node using kubectl and S3
• Node Monitoring Agent — GitHub (kubectl ekslogs)
• Usage of EKS NMA for collecting node logs — AWS re:Post
• Faster nodes, smarter scaling — AWS Containers Blog
• View the health status of your nodes
• Troubleshoot problems with Amazon EKS
• EKS Debugging Guide — Engineering Playbook