Amazon Elastic Kubernetes Service(Amazon EKS) 환경에서 워크로드를 운영하다 보면, Pod의 OOMKilled 종료나 IP 고갈로 인한 생성 실패 등 다양한 장애 상황에 직면하게 됩니다. 이러한 장애가 발생하면 엔지니어는 Pod 로그 수집부터 Kubernetes Events 추적, 노드 시스템 로그 확인까지 반복적이고 시간 소모적인 트러블슈팅 과정을 거쳐야 합니다. 특히 야간이나 주말에는 대응 시간이 길어지고, Pod 삭제나 노드 이상으로 인해 […] ||
Amazon Elastic Kubernetes Service(Amazon EKS) 환경에서 워크로드를 운영하다 보면, Pod의 OOMKilled 종료나 IP 고갈로 인한 생성 실패 등 다양한 장애 상황에 직면하게 됩니다.
이러한 장애가 발생하면 엔지니어는 Pod 로그 수집부터 Kubernetes Events 추적, 노드 시스템 로그 확인까지 반복적이고 시간 소모적인 트러블슈팅 과정을 거쳐야 합니다. 특히 야간이나 주말에는 대응 시간이 길어지고, Pod 삭제나 노드 이상으로 인해 중요한 진단 정보가 유실되기도 합니다.
이 문제를 해결하기 위해 K8sGPT와 Amazon Bedrock Agent같은 AI 기반 도구들이 활용되어 왔습니다. 하지만 K8sGPT 는 현재 리소스 상태 분석에 국한되어 배포 이력이나 조직 고유의 운영 맥락을 반영하기 어렵고, Bedrock Agent는 다양한 도구 통합과 트리거 파이프라인을 직접 구현해야 하는 부담이 있습니다. 결국 두 접근 방식 모두 인시던트 대응에 필요한 end-to-end 자동화된 조사 프로세스를 제공하기에는 한계가 있었습니다.
2025년 12월, AWS는 이러한 한계를 극복하는 AWS DevOps Agent(preview)를 발표했습니다. DevOps Agent는 코드 리포지토리, 관측성 도구, CI/CD 파이프라인, Runbook 등 다양한 소스를 연결하여 인시던트의 근본 원인을 자율적으로 분석하는 프론티어 에이전트입니다.
이 글에서는 Amazon EKS 워크로드의 장애를 자동으로 감지하여 DevOps Agent의 조사를 트리거하는 Kubernetes Operator인 DevOps Agent Operator를 통해 어떻게 자동화된 인시던트 대응 파이프라인을 구축할 수 있는지 설명합니다.
Solutions Overview
DevOps Agent는 강력한 인시던트 분석 기능을 제공하지만, 스스로 EKS 클러스터 내부의 Pod 장애를 감지하지는 않습니다. DevOps Agent가 조사를 시작하려면 외부에서 Webhook을 통해 트리거해야 하며, 이때 두 가지 조건이 충족되어야 합니다.
장애 감지의 즉시성: Pod가 재스케줄링되거나 삭제되기 전에 장애를 감지해야 합니다.
충분한 컨텍스트 전달: manifest, 로그, 이벤트, 노드 정보 등 분석에 필요한 데이터가 함께 전달되어야 합니다.
DevOps Agent Operator는 이 두 조건을 자동으로 충족시키는 Kubernetes Operator입니다.
왜 Operator 인가?
이 자동화를 사람이 수동으로 수행하는 것은 다음과 같은 이유에서 현실적으로 불가능합니다.
수동 트리거의 한계 : DevOps Agent는 Webhook을 통해 외부에서 호출되어야만 동작합니다. 즉, 장애가 발생했을 때 누군가가 직접 데이터를 수집하고 Webhook을 호출해야 합니다. 24/7 운영 환경에서 이를 사람이 수행하는 것은 현실적으로 불가능합니다.
컨텍스트 수집의 어려움 : 정확한 원인 분석을 위해서는 Pod manifest, 로그, Kubernetes Events, 노드 시스템 정보가 모두 필요합니다. 수동 수집은 시간이 소요될 뿐만 아니라 누락이 발생하기 쉬우며, 불완전한 데이터는 분석 정확도를 직접적으로 저하시킵니다.
타이밍 문제 : Kubernetes Events는 기본적으로 약 1시간만 보관되며, Pod가 재시작되면 이전 컨테이너의 로그는 소실됩니다. 장애 발생 직후 즉시 수집하지 않으면 원인 추적에 필요한 핵심 데