AWS опубликовала техническое руководство по автоматизированному реагированию на инциденты в Amazon EKS. На примере DevOps Agent Operator оно показывает, как оператор обнаруживает сбои и автоматически запускает расследования AWS DevOps Agent.

AWS DevOps Agent сам не обнаруживает отказы подов, поэтому расследование запускает внешний источник через webhook. Он должен передать манифест, журналы, события и сведения об узле.

Оператор замечает изменения состояния через Kubernetes watch за миллисекунды и сразу сохраняет нестабильные диагностические данные в Amazon S3 или CloudWatch. Стратегия сбора зависит от типа сбоя: dmesg и память для OOMKilled, предыдущие журналы и история перезапусков для CrashLoopBackOff, IPAMD и сопоставления ENI для исчерпания IP.

Для журналов уровня узла оператор использует AWS Systems Manager Run Command, поэтому ему нужны managed node groups EKS или самостоятельно управляемые EC2-узлы. На Fargate доступны только Kubernetes-данные без dmesg и IPAMD introspection.

Проверка утверждений:

  • AWS опубликовала техническое руководство, в котором на примере DevOps Agent Operator показывает, как построить автоматизированный конвейер реагирования на инциденты в Amazon EKS: оператор обнаруживает сбои и автоматически запускает расследования AWS DevOps Agent. (подтверждено первоисточником: доказательство; «This post shows how to build an automated incident response pipeline using the DevOps Agent Operator, a Kubernetes Operator that detects EKS failures and triggers DevOps Agent investigations automatically.»)
  • AWS DevOps Agent сам не обнаруживает отказы подов в EKS: расследование должен запустить внешний источник через webhook, передав своевременно собранный контекст — манифест, журналы, события и сведения об узле. (подтверждено первоисточником: доказательство; «AWS DevOps Agent provides powerful incident analysis. However, it does not detect pod failures inside an EKS cluster on its own. To start an investigation, an external source must trigger DevOps Agent through a webhook.»)
  • Оператор через Kubernetes watch обнаруживает изменения состояния за миллисекунды и сразу сохраняет нестабильные диагностические данные в Amazon S3 или CloudWatch, прежде чем задержки внешнего мониторинга приведут к их потере. (подтверждено первоисточником: доказательство; «Proactive preservation of volatile data : The Operator detects state changes in milliseconds via watch and preserves data to S3/CloudWatch instantly—before external tool delays (metric collection, alert evaluation, webhook delivery) let evidence disappear.»)
  • В отличие от kubectl, оператор собирает данные уровня конкретного узла по актуальному сопоставлению pod-to-node: например, dmesg для OOMKilled и данные IPAMD для исчерпания IP-адресов. (подтверждено первоисточником: доказательство; «Selective collection of node-level data : kubectl exposes only container-level and event data, but root causes often live deeper in the node—for example, OOMKilled traces to node dmesg, and IP exhaustion details are in IPAMD introspection. Because the Operator knows the real-time pod-to-node mapping, it collects only what each failure type needs from the exact node.»)
  • Стратегия сбора закодирована по типу сбоя: dmesg и память для OOMKilled, предыдущие журналы и история перезапусков для CrashLoopBackOff, IPAMD и сопоставления ENI для исчерпания IP. (подтверждено первоисточником: доказательство; «Encoding operational knowledge in code : The Operator pattern captures human expertise in code, applying different strategies per failure type—dmesg/memory for OOMKilled, previous logs/restart history for CrashLoopBackOff, IPAMD/ENI mappings for IP exhaustion—directly improving analysis accuracy.»)
  • При ошибке сбора или загрузки reconcile возвращает ошибку и повторно ставит pod в очередь с экспоненциальной задержкой; один worker и аннотация processed обеспечивают последовательную обработку массовых сбоев и однократную отправку каждого pod. (подтверждено первоисточником: доказательство; «If data collection or an upload to Amazon S3 or CloudWatch Logs fails, the reconcile returns an error and the pod is requeued with exponential backoff rather than dropped, and throttled AWS API requests are retried automatically. The Operator also runs a single reconcile worker and marks each pod with a processed annotation, so a mass failure—for example, 100 replicas crashing at once—is handled one pod at a time and each pod is reported only once.»)
  • Сбор журналов уровня узла выполняется через AWS Systems Manager Run Command и поэтому требует managed node groups EKS либо самостоятельно управляемых EC2-узлов; на Fargate доступны только Kubernetes-данные, без dmesg и IPAMD introspection. (подтверждено первоисточником: доказательство; «Node type : Node-level log collection uses AWS Systems Manager Run Command against the EC2 instance that ran the failed pod, so it requires Amazon EKS managed node groups or self-managed EC2 nodes. On AWS Fargate, the Operator still collects Kubernetes-level data—the pod manifest, events, and container logs—but node-level data such as dmesg output and IPAMD introspection is not available.»)
  • DevOps Agent Operator использует generic webhook, защищённый аутентификацией HMAC-SHA256. (подтверждено первоисточником: доказательство; «The DevOps Agent Operator uses a generic webhook. It maintains security through HMAC-SHA256 authentication.»)
  • Для локальной сборки оператора нужен Go 1.25 или новее; оператор собран на клиентских библиотеках Kubernetes 1.35 и использует только core API Pod, Node и Event. (подтверждено первоисточником: доказательство; «Building the image locally requires Go 1.25 or later. The Operator is built against the Kubernetes 1.35 client libraries and uses only the core Pod, Node, and Event APIs.»)
  • В разобранном сценарии OOMKilled оператор собирает данные уровня узла: журналы kubelet, containerd и ipamd, показатели диска, памяти и сети и вывод kernel OOM killer из dmesg. (подтверждено первоисточником: доказательство; «It then gathers node-level data such as kubelet, containerd, and ipamd logs, disk/memory/network usage, and the kernel OOM killer log from dmesg output.»)

Первоисточники:

оценка 75.0 · тип guide · ревизия 1 · истории st-txlcqh