kagent - 쿠버네티스 클러스터에 AI 에이전트를 넣어 장애를 진단하는 법

핵심 메시지

• kagent는 쿠버네티스 클러스터 안에 AI 에이전트를 넣는 오픈소스 도구다. YAML로 설정하고 에이전트가 건드릴 수 있는 범위를 직접 정한다.
• 에이전트는 마법을 부리지 않는다. 사람이 치는 것과 같은 kubectl 명령을 실행하되, '어떤 명령을 어떤 순서로' 실행할지 안다는 점이 다르다. 변경 전에는 반드시 사람에게 확인을 구한다.
• 대표적 함정은 서비스 셀렉터 불일치다. 서비스는 app=web을 찾는데 파드는 app=engine-x로 태그돼 있으면, 아무 에러도 안 나면서 트래픽이 어느 파드에도 가지 않는다. kubectl get endpoints로 빈 목록을 봐야 알 수 있다.
• 실습에서 손으로 잡으면 5~20분 걸리던 두 문제(셀렉터 불일치, 리소스 쿼터로 막힌 오토스케일)를 에이전트는 각각 약 2분 만에 원인까지 짚었다.
• 가장 큰 이점은 자연어다. 증상만 설명하면 에이전트가 조사를 대신하며, 담당자의 숙련도와 무관하게 장애 해결 시간을 낮춘다.

쉽게 이해하기

영상은 흔한 장애 상황으로 시작한다. 앱 파드는 정상이고 로그에도 이상이 없는데 접속하면 'connection refused'가 뜬다. 쿠버네티스에서는 파드가 수시로 생겼다 사라지므로 앞단에 안정적인 '서비스'를 두고, 서비스는 라벨(name tag)로 어떤 파드에 트래픽을 보낼지 정한다. 서비스가 찾는 라벨과 파드의 실제 라벨이 어긋나면 서비스는 아무 파드도 못 찾지만 아무것도 크래시하거나 로그를 남기지 않는다. 초보자는 kubectl get endpoints라는 한 명령에 도달하기까지 한 시간을 허비할 수 있다.

kagent는 바로 이런 문제를 겨냥한다. 클러스터 안의 에이전트에게 평범한 영어로 '엔진엑스 앱에 접속이 안 된다, 이유를 찾아라'라고 말하면, 에이전트는 서비스가 찾는 라벨을 읽고, 비어 있는 엔드포인트 목록을 확인하고, 파드의 실제 라벨을 읽어 불일치를 잡아낸다. 그리고 스스로 고치지 않고 '이렇게 바꿀 텐데 괜찮은가'를 먼저 묻는다.

KodeKloud 실습은 before/after 구조다. 먼저 손으로 두 문제를 잡는다. 첫째, default 네임스페이스의 order-api 서비스가 파드에 트래픽을 안 보낸다. curl은 실패하고, kubectl get endpoints는 비어 있다. 서비스 셀렉터는 version=V1을 찾는데 파드는 V2로 라벨돼 있었다. 셀렉터를 V2로 고치자 엔드포인트가 나타나고 접속이 된다. 명령 5~6개와 다음에 무엇을 볼지 아는 감이 필요했다.

둘째 문제는 backend-apps 네임스페이스의 inventory 서비스로, HPA(수평 파드 오토스케일러)가 최소 3개를 유지해야 하는데 파드가 1개만 뜬다. HPA 이벤트에는 메트릭 관련 경고가 있었지만 메트릭 서버는 정상이었다. 네임스페이스 이벤트를 보니 '쿼터 초과로 파드가 금지됨'이라는 단서가 있었다. 리소스 쿼터가 파드를 1개로 제한하고 있었던 것이다. 쿼터를 10으로 올리고 디플로이먼트를 재시작하자 파드가 뜬다. 쿼터가 드러나기까지 다섯 단계의 점검이 필요했다.

after에서는 클러스터 안에서 도는 kagent UI 챗에 같은 문제를 자연어로 던진다. 에이전트는 describe resource 같은 도구를 호출해 실제 데이터를 읽고, 모델이 다음에 무엇을 볼지 정하는 과정을 반복하며 사람이 손으로 한 조사와 똑같은 경로를 밟는다. 셀렉터 불일치를 찾아내 매니페스트를 적용해 고치고, HPA 문제에서는 이벤트·레플리카셋·디플로이먼트·HPA를 훑어 리소스 쿼터를 포함한 원인 후보를 순위까지 매겨 제시한 뒤 어떻게 고칠지 되묻는다.

주요 인사이트

• AI 에이전트의 가치는 '새로운 능력'이 아니라 '순서를 아는 것'에 있다. kagent는 사람과 같은 kubectl 명령을 쓰지만, 증상에서 원인까지 어떤 명령을 어떤 순서로 실행할지 안다.
• 에이전트가 클러스터를 스스로 바꾸지 않고 변경 전에 사람의 승인을 구하는 설계는, 운영 환경에서 자동화의 위험을 통제하는 안전장치다.
• 쿠버네티스의 가장 까다로운 장애는 크래시나 에러 로그가 아니라 '조용히 아무 일도 안 일어나는' 부류다. 셀렉터 불일치와 리소스 쿼터 제한이 대표적이며, 어떤 명령을 봐야 할지 아는 것이 관건이다.
• 손으로 5~20분 걸리던 진단을 에이전트가 약 2분에 끝냈다. 실제 장애 상황에서는 여러 모니터링 도구의 알림이 동시에 울리는 만큼, 해결 시간 단축의 체감은 더 크다.
• 자연어 인터페이스는 담당자의 숙련도 격차를 줄인다. 증상만 설명하면 되므로 신입이든 시니어든 비슷한 속도로 원인에 접근할 수 있다.

자주 묻는 질문

관련 AI 소식