본문으로 건너뛰기

Kubernetes 이벤트 보존과 AI Agent 조회 아키텍처

12분 읽기
AI용 문서 안내

개요​

장애를 조사하는 AI 에이전트는 클러스터의 보존 기간보다 오래된 이벤트가 필요할 수 있습니다. Kubernetes 이벤트의 기본 보존 기간은 1시간이므로, 과거 장애 이력을 분석하려면 외부 저장소로 내보내야 합니다. 이 가이드는 수집·저장·조회를 3계층으로 나누고, EKS MCP 서버와 CloudWatch MCP 서버로 최근 이벤트와 보관한 이벤트를 에이전트에 제공하는 방법을 설명합니다.

배경: Kubernetes 이벤트의 구조적 제약​

1시간 TTL​

Kubernetes Event 객체는 etcd에 저장되며, kube-apiserver의 --event-ttl 플래그 기본값은 1h0m0s입니다. EKS는 업스트림 기본값인 60분을 유지해 왔으며, 이벤트가 etcd를 채우면 API 서버 성능이 저하되기 때문에 오랫동안 이 설정의 변경을 허용하지 않았습니다(containers-roadmap #785). 60분이 지나면 etcd가 이벤트를 삭제하므로 kubectl get events로는 최근 1시간의 이벤트만 조회할 수 있습니다.

EKS Control Plane Customization (신규)

EKS는 최근 Kubernetes control plane customization 기능을 통해 scheduler, controller manager, API server 설정 일부를 노출하기 시작했으며, 여기에 event time-to-live 설정이 포함됩니다(EKS 콘솔 도움말). 다만 TTL을 늘리면 etcd 저장 객체가 증가해 컨트롤 플레인 성능에 영향을 줄 수 있고, 아래의 best-effort 특성은 그대로 유지되므로, TTL 연장은 export 파이프라인의 대체재가 아니라 보완재로 취급해야 합니다. 지원 버전·API 세부 사항은 적용 전 최신 문서에서 확인이 필요합니다.

Best-effort 데이터​

Kubernetes Event v1 API 문서는 이벤트를 다음과 같이 정의합니다: "Events have a limited retention time... should be treated as informative, best-effort, supplemental data." 이벤트는 보존과 전달이 보장되지 않는 보조 신호이며, 장애 분석의 유일한 근거로 삼을 수 없습니다.

Audit 로그로 대체 불가​

EKS 컨트롤 플레인 audit 로그를 활성화해도 Event 객체는 수집되지 않습니다. EKS 감사 정책에 Do not log events resources(level: None)가 명시되어 있기 때문입니다(EKS Best Practices: Auditing and logging). Audit 로그는 "누가 어떤 API를 호출했는가"를 기록하므로 원인 추적에 유용하지만, Event 리소스 자체의 보존 수단이 될 수 없습니다.

EventBridge에 대한 흔한 오해

Amazon EventBridge의 aws.eks 소스 이벤트는 EKS 서비스 이벤트(add-on 생성/삭제/헬스 등)만 전달합니다. Pod 스케줄링 실패, OOMKilled 같은 Kubernetes 클러스터 이벤트는 EventBridge로 전달되지 않습니다.

아키텍처: 수집 → 저장 → 조회 3계층​

이벤트를 AI Agent가 조회할 수 있게 만들려면 수집(export), 저장(durable store), 조회(query interface)를 분리해 설계합니다.

글씨가 작으면 확대해서 확인할 수 있습니다.
다이어그램

수집 계층: Export 방식 비교​

방식수집 대상특징적합한 경우
CloudWatch Observability add-on (Container Insights)컨테이너/호스트/데이터플레인 로그관리형 add-on, Fluent Bit 기반CloudWatch 중심 스택
kubernetes-event-exporterEvent 객체 전체속성 기반 필터·라우팅, leader election HA, 20개 이상 sink이벤트 전용 파이프라인
ADOT / OTel Collector (k8sobjects receiver)Event 포함 K8s 객체기존 OTel 파이프라인에 통합OTel 표준화 환경
자체 watcher (aws-samples/eks-event-watcher)선택한 이벤트Kubernetes API watch 기반 커스텀특수 필터링 요구
Container Insights의 기본 수집 범위

표준 Container Insights의 Fluent Bit DaemonSet이 기본 수집하는 것은 /aws/containerinsights/{cluster}/application(컨테이너 로그), /host(호스트 로그), /dataplane(kubelet 등 데이터플레인 로그)입니다. Event 객체(kubectl get events)는 기본 수집 대상이 아닙니다. "Container Insights로 이벤트를 저장 중"이라면 별도의 이벤트 수집 설정이 실제로 존재하는지, 어느 로그 그룹에 쌓이는지 먼저 확인해야 합니다.

kubernetes-event-exporter는 이벤트 파이프라인의 사실상 커뮤니티 표준입니다. EKS Workshop에서도 OpenSearch로의 이벤트 export에 이 도구를 사용합니다. 프로덕션 구성 시 다음을 적용합니다:

# kubernetes-event-exporter 구성 예시 (Loki sink)
logLevel: info
kubeQPS: 100          # 대규모 클러스터에서 이벤트 유실 방지
kubeBurst: 500
maxEventAgeSeconds: 60
leaderElection:
  enabled: true        # HA 배포 시 중복 전송 방지
receivers:
  - name: "loki"
    loki:
      url: http://loki.monitoring:3100/loki/api/v1/push
      streamLabels:          # 정적 라벨만 지원 (템플릿은 layout/headers에서만 동작)
        app: kube-events
route:
  routes:
    - match:
        - receiver: "loki"
      drop:
        - type: "Normal"   # Warning만 저장 — Normal이 대부분이므로 수집량 대폭 절감

저장 계층: 조회 패턴 기준 선택​

저장소는 이벤트를 "어떻게 조회할 것인가"를 기준으로 선택합니다.

저장소조회 패턴보존 비용MCP 연동
CloudWatch LogsLogs Insights 쿼리, 패턴 분석중간 (S3 export로 절감)CloudWatch MCP, EKS MCP 직접 지원
OpenSearch필드 기반 정밀 검색, 대시보드중간~높음커스텀 툴 필요
LokiLogQL, 저비용 장기 보관낮음커스텀 툴 필요
S3 + AthenaSQL 사후 분석, 아카이브매우 낮음커스텀 툴 필요
Kinesis / Firehose실시간 스트림 처리전송량 기반커스텀 툴 필요

CloudWatch에 이미 이벤트가 쌓이고 있다면 Loki로 재전송(CloudWatch → Loki)하는 구성은 홉이 하나 낭비됩니다. Loki를 목적지로 쓰려면 kubernetes-event-exporter에서 Loki로 직접 전송하는 것이 CloudWatch 수집 비용도 절감합니다.

조회 계층: MCP 서버 기반 AI Agent 연동​

EKS MCP 서버와 CloudWatch MCP 서버의 역할 분담​

AWS는 fully managed EKS MCP 서버(2025년 11월 발표, preview)와 CloudWatch MCP 서버를 제공합니다. 두 서버는 조회 대상이 다르므로 장애 분석 Agent에는 함께 연결하는 것이 표준 구성입니다.

구분EKS MCP 서버CloudWatch MCP 서버
관점클러스터·K8s 리소스의 현재 상태축적된 로그·메트릭·알람 히스토리
핵심 도구get_k8s_events, get_pod_logs, list_k8s_resources, get_cloudwatch_logs, get_eks_insightsAlarm 기반 트러블슈팅, Log Analyzer(이상·에러 패턴), Metric Definition Analyzer, Alarm Recommendations
인증AWS IAM (SigV4), CloudTrail 감사AWS IAM (SigV4)
접근 제어IAM 권한 단위 분리(eks-mcp:CallReadOnlyTool / CallPrivilegedTool), AmazonEKSMCPReadOnlyAccess 관리형 정책읽기 중심 도구 구성
EKS MCP 서버의 get_k8s_events는 보존 솔루션이 아님

get_k8s_events는 라이브 Kubernetes API를 조회해 특정 리소스(kind/name/namespace)의 이벤트를 반환합니다. 별도 저장 계층 없이 API 서버를 조회하는 구조이므로 etcd TTL 제약이 그대로 적용됩니다. 1시간 이전의 이벤트가 필요하면 export 파이프라인으로 저장한 로그 그룹을 get_cloudwatch_logs 또는 CloudWatch MCP 서버로 조회해야 합니다. EKS MCP 서버는 현재 preview 상태이므로 프로덕션 채택 전 GA 여부와 도구 변경 사항을 재확인해야 합니다.

MCP가 없는 저장소의 연동​

OpenSearch, Loki 등 MCP 서버가 제공되지 않는 저장소는 Strands Agents SDK 등으로 쿼리 API(LogQL, OpenSearch DSL)를 감싼 커스텀 툴을 구현해 Agent에 노출합니다. 저장소가 무엇이든 MCP 또는 툴 인터페이스로 표준화하면 저장소 교체 시 Agent 코드 변경을 최소화할 수 있습니다.

권장 아키텍처 패턴​

패턴 A: 최소 변경 (CloudWatch 중심)​

Container Insights를 이미 사용 중인 환경에서 파이프라인 추가 없이 시작하는 구성입니다.

이벤트 수집기 → CloudWatch Logs → CloudWatch MCP + EKS MCP → AI Agent
                                   (+ 컨트롤 플레인 api/audit 로그 활성화)
  1. 이벤트가 실제로 저장되는 로그 그룹을 확인합니다(아래 검증 섹션).
  2. 컨트롤 플레인 로그(api, audit)를 활성화합니다. 이벤트(best-effort)의 공백을 durable한 API 호출 이력이 보완합니다.
aws eks update-cluster-config \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit"],"enabled":true}]}'
  1. AI Agent에 CloudWatch MCP 서버(히스토리 분석)와 EKS MCP 서버(현재 상태 조회)를 함께 연결합니다.

패턴 B: 정밀 검색 강화 (이벤트 전용 파이프라인)​

이벤트 필드(reason, involvedObject, message) 기반 정밀 검색과 장기 보존이 중요한 경우의 구성입니다.

kubernetes-event-exporter ─┬→ OpenSearch/Loki (검색·대시보드 → 커스텀 툴)
                           └→ S3 (장기 아카이브 → Athena SQL 사후 분석)

운영 원칙​

  1. 이벤트를 유일 근거로 삼지 않습니다 — best-effort 데이터이므로 audit 로그, 메트릭, 애플리케이션 로그와 교차 검증합니다.
  2. 수집기를 명시적으로 운영합니다 — "누가 이벤트를 watch해서 어디로 보내는가"를 파이프라인으로 관리하고 유실 지표(watch lag)를 모니터링합니다.
  3. 저장소는 조회 패턴으로 선택합니다 — 실시간(Kinesis), 검색(OpenSearch·Loki), 아카이브(S3+Athena)를 요구사항에 맞게 조합합니다.
  4. AI Agent에는 표준 인터페이스로 노출합니다 — MCP 서버 또는 SDK 커스텀 툴로 감싸 저장소 교체와 확장에 대비합니다. MCP preview 단계의 리스크는 자체 구현으로 헤지합니다.

검증: 이벤트 저장 여부 확인​

이벤트가 CloudWatch에 실제로 쌓이는지 확인하는 CloudWatch Logs Insights 쿼리입니다. 이벤트 수집기가 기록하는 로그 그룹을 대상으로 실행합니다.

fields @timestamp, @message
| filter @message like /(?i)(FailedScheduling|OOMKilling|BackOff|Unhealthy|FailedMount)/
| sort @timestamp desc
| limit 50

Warning 유형별 발생 빈도 집계:

fields @timestamp
| parse @message /"reason":\s*"(?<reason>[^"]+)"/
| filter ispresent(reason)
| stats count(*) as cnt by reason
| sort cnt desc

1시간 이전 타임스탬프의 이벤트가 조회되면 export 파이프라인이 정상 동작하는 것입니다. 최근 1시간 데이터만 존재한다면 라이브 API 조회 결과이거나 파이프라인이 최근에 시작된 것이므로 수집기 설정을 점검합니다.

결론​

Kubernetes 이벤트는 클러스터에 남아 있는 동안 조회할 수 있습니다. 다만 기본 1시간의 TTL과 best-effort 전달 특성 때문에 장기 장애 이력으로 쓰기에는 한계가 있습니다. 실시간 조회, 검색, 아카이브 요구에 맞춰 저장소를 선택하며, CloudWatch는 그 후보 중 하나입니다. 이 문서의 구성에서는 EKS MCP 서버가 현재 상태를, CloudWatch MCP 서버가 축적한 데이터를 제공합니다. get_k8s_events로 이미 만료된 이벤트를 복구할 수는 없습니다.

참고 자료​

공식 문서​

블로그 / 워크샵​

관련 문서 (내부)​