가시다님과 정영준 님과 함께하는 쿠버네티스 디버깅
10 views
블로그 불러오는 중...
문의 보내기
남겨주면 블로그 주인에게 바로 전달돼요.
오늘은 가시다님과 하는 스터디에서 AWS 정영준 님께서 쿠버네티스 디버깅 세션을 해 주셨다. 우리 회사는 쿠버네티스를 쓰진 않지만, 도커로 온프레미스 및 AWS 서비스를 하고 있다. 나도 실무를 하면 항상 발생하는 에러의 패턴들은 정해져 있었고, 나름대로 문제를 찾아가는 순서들을 내 직감대로 처리하고 있었는데, 이렇게 체계적으로 문제의 패턴들을 정리해서 관리하면 훨씬 빠를 것 같다는 생각을 했다.
그리고 해당 과정을 잘 정리해 두면 추후에 내부 LLM 을 이용해서, 에러를 추측하고 대응책을 줄 수 있는 챗 App 을 만들 수 있겠다고 생각이 들었다.
일단은 강의 자료의 내용은 다음과 같다. https://devfloor9.github.io/engineering-playbook/slides/eks-debugging/
디버깅을 할때에는 추측에 기반해서 하면 안 된다. MTTR 이라는 새로운 용어에 대해서 배웠다.
MTTR(Mean Time To Repair/Recover, 평균 수리/복구 시간)은 장애 발생 시점부터 시스템이 정상 기능으로 복구될 때까지 소요되는 평균 시간입니다.
6 계층의 레이어들을 하나하나 디버깅을 하며 에러를 찾아간다.
EKS의 컨트롤 플레인은 AWS가 관리하지만, API Server에 과부하가 걸리면 클러스터 전체가 마비된다.
Pending 상태: 클러스터에 여유 리소스가 없거나, Taint/Toleration, NodeSelector 설정이 잘못되어 스케줄링을 못하는 상태. (해결: kubectl describe pod의 Event 확인)
CrashLoopBackOff 상태:
앱이 떴다가 죽기를 반복합니다.
kubectl logs <pod-name> -n <namespace> --previous 명령어 입력 시 크래시 된 컨테이너 로그를 확인 가능하다.
Probe 실패 이슈 (Liveness / Readiness) 앱은 정상인데 K8s가 자꾸 Pod를 죽인다면 헬스체크 설정을 봐야 한다. AWS ALB 헬스체크, 쿠버네티스 헬스 체크 등을 확인한다.
VPC CNI IP 고갈 문제 EKS는 Pod에 실제 VPC 서브넷 IP를 할당합니다. 노드나 Pod가 갑자기 안 뜬다면 서브넷의 IP 를 확인해 본다.
CoreDNS ndots: 5 이슈 (DNS 과부하) K8s는 기본적으로 외부 도메인을 호출할 때 불필요한 내부 도메인 검색을 최대 5번 반복합니다(ndots: 5). 이로 인해 CoreDNS에 엄청난 부하가 발생할 수 있다.
ALB와 Readiness Probe의 미스매치 (502/503 에러) K8s 내부에서는 Pod가 'Ready'라고 판단했는데, 앞단의 ALB는 아직 'Unhealthy'라고 판단하는 그 시간 차이 구간에 사용자가 접속하면 502/503 에러가 발생할 수 있다. 두 헬스체크의 주기와 타임아웃을 동기화해야 한다. 해당 부분은 상위 링크에 잘 정리되어 있다.
OOM (Out Of Memory) - vLLM 사용 시 GPU 메모리를 다 써서 터지는 경우입니다. vLLM 같은 추론 서버는 기본적으로 GPU 메모리의 90%를 선점하도록 설정되어 있습니다. 이 비율을 낮추거나 Tensor Parallelism을 사용해 여러 GPU로 분산시켜야 합니다.
NCCL 타임아웃 (분산 학습) 여러 GPU 노드가 통신하며 학습할 때 네트워크가 단절되면 NCCL Timeout 에러가 납니다. Security Group에서 노드 간 통신을 확인한다.
알림이 너무 많으면 알림을 무시하게 된다. 알림 기준을 리뷰해서 정해야 한다고 한다.
사실 우리 회사의 경우도 해당 알림을 정의하진 않았지만, 너무 많은 알림 메일은 결국 안보게 되는 문제가 있었다.
좋은 내용이였고 쿠버네티스로 트러블 슈팅을 좀 해보고 싶은 생각이 든다. 일단은 주어진 환경에서 Observability 를 좀 지킬 수 있게 한번 만들어 보고 싶다.