Kubernetes 노드 CPU 높아 보일 때 점검 순서 (실전 트러블슈팅)

Kubernetes 노드 CPU 사용량이 높아 보일 때 확인한 순서

운영 중인 Kubernetes 클러스터에서 특정 노드의 CPU 사용률이 높아 보이는 상황이 있었다. 처음에는 노드 자체가 무거운 일을 하고 있는지 의심했지만, 실제로 확인해보니 단일 프로세스가 CPU를 독점하는 상황은 아니었다.

이 글은 그때 확인한 순서를 정리한 것이다. 실제 노드명, IP, 레지스트리 주소 등은 모두 제거했다.

1. 노드 사용량 확인

가장 먼저 kubectl top node로 전체 노드 상태를 확인했다.

kubectl top node
kubectl top node <node-name>

CPU 사용률이 30% 안팎이라면 보통 즉시 장애로 보기는 어렵다. 다만 평소보다 높은지, 특정 시간대에 계속 유지되는지가 중요하다.

2. 파드별 사용량 확인

kubectl top pod -A --sort-by=cpu
kubectl top pod -A --sort-by=memory

이 단계에서는 어떤 워크로드가 CPU와 메모리를 많이 쓰는지 확인한다. 예를 들어 대시보드, 메시지 브로커, 모니터링 에이전트, 로그 수집기 등이 조금씩 CPU를 쓰는 경우가 있다.

3. 해당 노드에 올라간 파드 확인

kubectl get pod -A -o wide --field-selector spec.nodeName=<node-name>

kubectl top pod는 환경에 따라 spec.nodeName field selector를 지원하지 않을 수 있다. 그럴 때는 get pod -o wide로 노드에 올라간 파드를 먼저 좁혀본다.

4. SSH 없이 노드 내부 프로세스 확인

노드에 직접 SSH가 어려운 경우 kubectl debug node를 사용할 수 있다.

kubectl debug node/<node-name> -q --image=busybox:1.36 -- \
  chroot /host sh -c 'ps -eo pid,ppid,user,comm,%cpu,%mem,rss,args --sort=-%cpu | head -30'

이렇게 하면 host filesystem을 기준으로 프로세스 목록을 볼 수 있다.

5. 판단

이번 경우에는 단일 프로세스가 CPU를 계속 태우는 상황은 아니었다. 여러 서비스와 시스템 데몬이 조금씩 사용하고 있었다.

확인된 유형은 다음과 같았다.

대시보드 프로세스
메시지 브로커 관련 Java 프로세스
kubelet
container runtime
monitoring agent
CNI agent

결론적으로 CPU보다 더 중요한 문제는 다른 곳에 있었다. 이미지 pull 실패가 오랫동안 반복되고 있었고, 이것이 이벤트와 로그를 계속 만들고 있었다.

정리

Kubernetes 노드 CPU를 볼 때는 kubectl top node만 보고 판단하지 않는 것이 좋다.

확인 순서는 다음처럼 가져가면 된다.

1. kubectl top node
2. kubectl top pod -A
3. 특정 노드의 파드 목록
4. node debug로 host process 확인
5. ImagePullBackOff, CrashLoopBackOff 같은 반복 실패 확인

CPU가 높아 보이는 현상은 실제 원인이 CPU가 아닐 때도 있다. 반복 실패, 로그 증가, 이미지 캐시 누적 같은 운영 잡음도 함께 봐야 한다.