로컬 환경에서 관측(로그/메트릭) → 이상 감지 → 자동 조치까지 한 번에 묶어보고 싶어서 KubeHeal AI를 살펴봤습니다. 이 글에서는 KubeHeal AI의 구성과 동작 흐름을 정리하고, “파드 삭제” 같은 강한 자동 치유를 쓸 때 필요한 안전장치와 포크 전략까지 제 관점에서 정리합니다.
KubeHeal AI는 무엇인가요?
KubeHeal AI는 Minikube 로컬 Kubernetes에서 동작하는 데모/프로젝트로, 다음을 결합합니다.
- 이상 감지: 파드 재시작 횟수가 일정 기준 이상(예: ≥3) 또는
CrashLoopBackOff상태 감지 - 로그 분석: Kubernetes API로 해당 파드 로그를 가져와 분석(프로젝트 설명상 “AI 기반”, 실제로는 패턴 기반 추정 로직 포함)
- 자동 치유(Self-healing): 문제 파드를 삭제해서 Kubernetes가 재생성/재스케줄링하도록 유도
- 관측: Prometheus/Grafana로 메트릭/상태를 모니터링
핵심은 “클라우드”가 아니라 완전 로컬에서도 운영 자동화의 한 사이클(Detect → Diagnose → Act)을 재현했다는 점입니다.
전체 아키텍처(구성 요소)
프로젝트는 크게 아래 구성으로 이해할 수 있습니다.
- Node.js 앱: 데모용 서비스(또는 장애 상황을 재현하는 워크로드 역할)
- ai-analyzer (Python FastAPI): 로그를 받아 원인을 추정/분류하는 분석 서비스
- 치유 스크립트(Python): Kubernetes API를 통해 파드 상태를 감지하고, 조건 만족 시 파드 삭제 같은 조치를 수행
- Prometheus / Grafana: 메트릭 수집/대시보드 시각화
- Kubernetes manifests: 로컬 클러스터에 배포하기 위한 YAML
- GitHub Actions CI/CD: 빌드/배포 자동화(프로젝트 구성 요소로 언급)
즉, “서비스 + 분석기 + 치유 에이전트 + 관측 + 배포 파이프라인”을 한 레포에서 데모할 수 있는 형태입니다.
동작 흐름: Detect → Diagnose → Act
1) Detect: CrashLoopBackOff 또는 재시작 횟수 임계치 초과 감지
치유 로직은 파드 상태/이벤트에서 흔히 운영 중 문제가 되는 시그널을 봅니다.
CrashLoopBackOff- 재시작 횟수
restartCount >= 3(프로젝트 요약 기준)
이 방식의 장점은 구현이 단순하고 즉시 효과가 있다는 점입니다. 반면 “재시작이 잦다”는 사실만으로는 원인(설정 오류/외부 의존성 장애/일시적 리소스 부족 등)을 구분하기 어렵습니다.
2) Diagnose: Kubernetes API로 로그 수집 후 원인 추정
감지된 파드에 대해 Kubernetes API로 로그를 수집하고, 분석기가 패턴 기반으로 원인을 추정합니다(예: 특정 에러 문자열 매칭).
예를 들면 흐름은 대략 이런 형태로 그려볼 수 있습니다.
healer(감지) → k8s API(로그 가져오기) → ai-analyzer(분석) → healer(조치 결정)
여기서 “AI”는 분석을 서비스로 분리해둔 구조가 포인트입니다. 초기에는 규칙 기반/패턴 기반으로 시작하더라도, 나중에 모델 기반 분류/요약으로 확장하기 쉬운 형태입니다.
3) Act: 문제 파드를 삭제해 쿠버네티스가 다시 살리게 만들기
최종 조치는 단순하지만 강력합니다.
- 문제 파드를 삭제
- ReplicaSet/Deployment가 원하는 상태를 맞추기 위해 새 파드를 생성
- 결과적으로 서비스가 정상화될 가능성을 노림
이 조치는 “컨테이너가 깨졌을 때 다시 띄우면 해결되는 유형(일시적 장애)”에는 잘 먹히지만, 설정/이미지/코드가 근본 원인이면 삭제해도 동일 장애가 반복됩니다. 그래서 다음 섹션의 안전장치가 중요해집니다.
자동 치유를 ‘파드 삭제’로 단순화할 때 필요한 안전장치
제가 이 프로젝트를 보며 가장 크게 남은 질문은 이거였습니다.
자동 치유를 파드 삭제 같은 강한 조치로 단순화할 때, 오탐/반복 장애를 줄이려면 무엇이 필요할까?
실무/운영 관점에서 최소한 아래 4가지는 설계해야 합니다.
- 게이팅(승인/정책)
- 프로덕션에서는 “항상 자동 삭제”보다
- (옵션 A) Slack/Issue로 알림 후 승인 시 실행
- (옵션 B) namespace/label별로 자동치유 허용 정책 적용
같은 장치가 필요합니다.
- 쿨다운/반복 방지
- 같은 워크로드에 대해 “N분 내 M회 이상 치유 발생 시 중단” 같은 서킷브레이커가 없으면, 자동화가 장애를 증폭시키는 루프가 생깁니다.
- 증거 보존(로그/이벤트 스냅샷)
- 파드를 삭제하면 디버깅 정보가 사라질 수 있습니다.
조치 전에 로그/이벤트를 저장(예: 오브젝트 스토리지, 파일, 이슈 코멘트 등)해 “왜 삭제했는지”를 남겨야 합니다.
- 조치 단계화(강도 조절)
- 바로 삭제 대신 단계적으로 가는 방식이 안전합니다. 예:
- 1단계: 알림 + 관측 강화
- 2단계: rollout restart(가능한 경우)
- 3단계: 파드 삭제
- 4단계: 배포 중단/트래픽 차단(더 큰 사고 방지)
KubeHeal AI는 데모로서 “파드 삭제”를 선택해 흐름을 단순하게 만들었고, 그 덕분에 전체 파이프라인의 개념이 명확해졌습니다. 다만 실제 운영에 가까워지려면 위 안전장치가 사실상 필수입니다.
“클라우드브로만의 오픈소스”로 포크하려면: 차별점이 먼저입니다
대화에서 나온 것처럼 단순히 포크해서 “우리 프로젝트”라고 하기보다는, 클라우드브로만의 정체성이 코드/운영으로 드러나야 오래 갑니다. 저는 특히 아래 방향이 좋다고 봅니다.
- Self-healing 안전장치 패키지화: 승인 흐름, 서킷브레이커, 증거 보존, 단계적 조치 같은 운영 안전 기능을 “기본 제공”으로 만들기
- SLO/에러버짓 기반 트리거: 단순 CrashLoopBackOff 감지에서 더 나아가, 서비스 지표(SLI) 기반으로 “지금 정말 조치가 필요한가?”를 판단
- 업스트림 기여 vs 포크 유지 전략 명확화: 포크는 빠르지만 머지 비용이 누적됩니다. 클라우드브로가 장기적으로 가져갈 방향(업스트림에 PR을 올리는지, 독자 로드맵으로 가는지)을 초기에 정해두는 게 중요합니다.
라이선스 관련해서는, “포크한 뒤 우리 쪽 라이선스로 바꾸기”는 업스트림 라이선스(특히 카피레프트 여부)와 저작권자 동의 이슈가 얽힐 수 있으니, 실제 진행 전에는 레포의 LICENSE와 기여자 현황을 기준으로 별도 검토가 필요합니다.
마무리
KubeHeal AI는 “로컬 Minikube에서 자가치유 Kubernetes를 끝까지 연결해보는 데모”로서, 관측과 자동 조치를 한 번에 이해하기 좋은 구조를 갖고 있습니다. 여기에 **안전장치(승인/반복 방지/증거 보존/단계적 조치)**를 더하면, 데모를 넘어 팀의 운영 철학이 담긴 “클라우드브로만의 오픈소스”로 확장할 여지도 충분하다고 봅니다.
