Déboguer AWS EKS Auto Mode

Avec Auto Mode, AWS gère l'intégralité du produit EKS pour vous : création des nœuds, 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.

Revers de la médaille : plus de SSH, plus de SSM, plus d'accès direct aux nœuds.

Heureusement, AWS expose plusieurs outils pour diagnostiquer vos clusters sans toucher aux nœuds. Voici lesquels et comment les utiliser concrètement.

NodeDiagnostic - la méthode recommandée

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

Quand vous créez une ressource NodeDiagnostic nommée d'après un nœud, l'agent détecte la création de la ressource, 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 nœud téléverse l'archive directement sur S3.
Vous n'avez même pas besoin de récupérer le fichier depuis le nœud.

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 fichiers local du nœud. L'archive est stockée temporairement sur le nœud 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 nœud
kubectl ekslogs i-01234567890123456

# Collecte de tous les nœuds 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 nœud 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 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 nœuds. 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 nœuds
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'

# Détail d'un nœud 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 nœud 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 nœud 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, nœud 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 nœud 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 nœud a son CoreDNS local (résolution sans quitter le nœud), ce qui change la donne.

Pour vérifier la résolution DNS depuis un nœud 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 nœud (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 nœud 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 nœud anormal)
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent

# 5. Conditions du nœud
kubectl describe node <node-name>

# 6. Collecte des logs du nœud
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 nœuds, mais ce n'est pas bloquant si vous avez les bons réflexes :

En pratique, kubectl ekslogs est celui que j'utilise le plus. Installez-le dans votre toolchain : il vous évitera bien des tickets 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