시나리오
플랫폼 팀이 여러 네임스페이스에 걸쳐 프로덕션 EKS 클러스터를 운영하고 있습니다. CPU 알림은 간헐적으로 발생하지만 조사는 느립니다 — 엔지니어들이 수백 개의 파드에 걸쳐 로그, 메트릭, 이벤트를 상관 분석하기 위해 수동으로kubectl 명령을 실행합니다.
수동 Kubernetes 트러블슈팅의 어려움
팀은 Kai에게 클러스터를 엔드투엔드로 평가하고, 리소스 낭비를 파악하며, 오토스케일링 정책이 없는 곳에 권고안을 제시해 달라고 요청합니다.단계별 안내
Kubernetes 연결 가이드를 따라 Kai가 EKS 클러스터에 접근할 수 있도록 하세요. 연결이 Connected 상태를 표시하면 Kai가 클러스터를 직접 쿼리할 수 있습니다.
Kai가 세 가지 발견 사항을 표시합니다: auth-service와 notification-worker는 과도하게 프로비저닝되어 있고(CPU 18–21%), api-gateway와 cache-redis는 적절한 크기이며, payment-processor는 CPU 80–86%와 메모리 88–94%로 위험할 정도로 프로비저닝이 부족하여 OOM 킬 및 서비스 중단 위험이 높습니다.
Kai가 평균 CPU 30% 미만(일부는 12–15%에 불과)인 노드 다섯 개를 발견하여 월 약 $573를 낭비하고 있음을 확인합니다. 경량 워크로드를 실행하는 과도하게 큰 t3.xlarge 인스턴스와 — 불량한 파드 스케줄링으로 인해 — 일부 노드에는 2–3개의 파드만 있는 반면 다른 노드에는 8–9개가 있습니다.
효과적인 이유
- **Kai**가 클러스터 API를 직접 쿼리하여 수동
kubectl세션과 도구 전환을 대체합니다. - 크로스 레이어 상관 분석이 파드 활용률, 노드 용량, 스케줄링 패턴을 단일 분석 과정에서 연결합니다.
- **
#report와#chart**가 Kai가 발견 사항을 표시하기 전에 추론할 수 있는 구조화된 출력을 생성합니다. - **
#recommend**가 원시 메트릭 덤프 대신 실행 가능한 HPA 정책 변경 사항을 생성합니다. - **CloudKeepers**가 이 분석을 스케줄에 따라 실행하여 온콜 엔지니어가 호출받기 전에 발견 사항이 전달됩니다.
직접 시도해 보기
Kai 에이전트 레퍼런스
Kubernetes 엔지니어 에이전트 Kai의 전체 기능
Kubernetes 연결
CloudThinker를 EKS 클러스터에 연결하는 단계별 가이드
Topology Explorer
Kubernetes 서비스 의존성을 매핑하여 인시던트 근본 원인 분석을 빠르게
CloudKeepers
Kubernetes 워크로드 전반에 걸쳐 지속적인 상태 검사를 자동으로 실행