쿠버네티스를 처음 도입할 때 쉽게 놓칠 수 있는 부분이 바로 리소스 Request와 Limit 설정입니다. 이에 대한 설정을 하지 않거나 잘못 설정한 경우에는 해당 애플리케이션의 가용성 저하는 물론, 클러스터 전체에 영향을 줄 수 있습니다.

이번 글에서는 실제 운영 환경에서 발생한 사례를 중심으로, 모니터링 툴을 활용해 문제를 진단하고 리소스 설정을 최적화한 과정을 소개합니다.

1. 노드를 죽인 파드들: 정기적 보고서 검진을 통한 Request/Limit 최적화

여러 언어로 개발된 백엔드 애플리케이션을 리소스 제한 설정 없이 쿠버네티스에 배포한 후 운영한 사례입니다. 이 애플리케이션은 평소에는 자원 사용량이 적지만, 특정 시간대에는 사용량이 급격히 증가하면서 CPU와 메모리 점유량이 같이 치솟는 패턴을 보였습니다.

일부 Pod가 리소스 요청(requests)과 제한(limits) 설정 없이 클러스터에 배포되었고, 특정 노드에 스케줄된 이후 점차 과도한 CPU와 메모리를 사용하게 되었습니다. 자원에 대한 제한 설정이 없었기 때문에 노드는 해당 Pod에 계속 리소스를 할당하였고, 시스템 임계점에 도달하게 됩니다.

결국, 해당 노드는 CPU 과다 사용, 메모리 부족, 프로세스 스케줄 지연 등이 복합적으로 발생하면서 kubelet과 container runtime의 응답 지연이 발생하였고, 클러스터는 이 노드로부터의 응답을 받지 못하게 되어 일정 시간이 지나자 해당 노드를 NotReady 상태로 전환했습니다.

클러스터의 컨트롤러는 NotReady 상태의 노드에서 실행 중이던 파드들을 삭제하고 새로운 노드에 재스케줄을 시도하였으나, 이들 역시 리소스 제한이 없는 상태였고, 새로 배치된 노드들 또한 여유 자원이 부족한 상황이었습니다. 이로 인해 재스케줄된 파드들의 리소스 요구가 집중되며, 해당 노드들 또한 과부하 상태에 빠지기 시작했습니다.

결국 하나의 노드에서 시작된 자원 고갈이 파드 재배치 과정을 통해 다른 노드까지 부하를 확산시켰고, 다수의 노드가 NotReady 상태로 전환되면서 서비스 응답 지연, 일부 애플리케이션 타임아웃, 내부 통신 장애 등이 발생하게 되었습니다.

이를 계기로 모니터링 도구의 리소스 사용량 보고서와 매트릭스 차트를 주기적으로 활용하기 시작했습니다. 테스트를 위해 리소스가 충분한 노드를 별도로 구성하여, 해당 애플리케이션의 시간대별 자원 사용량과 평상시 대비 피크 수치를 시각적으로 파악할 수 있었고, 이를 기반으로 적절한 request/limit 값을 설정하였습니다.

예를 들어:

• 평균 CPU 사용량: 250m
• 최대 CPU 사용량: 900m

→ request: 300m, limit: 1로 조정

2. 배치잡 리소스 쟁탈: ‘Pod 시작 분석’ 기능으로 해결

또 다른 사례는 배치 애플리케이션이 자주 실행되는 환경이었습니다. 배치는 짧게는 2분, 길게는 10분가량 소요되며, 이 역시 리소스 설정 없이 운영되고 있었습니다. 여러 개의 잡이 동시에 실행되면서 클러스터에 과부하가 발생했고, 이로 인해 일부 작업은 대기하거나 실패하는 경우도 있었습니다.

이 문제를 해결하기 위해 모니터링 도구의 [Pod 시작 분석] 기능을 활용했습니다.

이 기능은 파드가 시작된 직후 5분간의 리소스 사용량 추이를 구간별로 시각화해주며, 초기화 컨테이너와 첫 부하 시점을 포함한 데이터를 제공합니다. 이를 바탕으로 애플리케이션의 성능을 개선하고, 동시에 잡이 실행될 경우 파드가 균등하게 분산되도록 스케줄링을 조절했습니다.

또한, 다음과 같이 적절한 리소스 값까지 도출하여 적용했습니다.

• 초기 1분: CPU burst 800m
• 이후 안정 시: 200m 유지

→ request: 300m, limit: 800m로 조정

그 결과, 동일 시간에 더 많은 배치잡을 안정적으로 실행할 수 있게 되었습니다.

3. 배치잡이 끝나지 않는다면? “파드 타임라인” 기능으로 문제 파악

이번 사례는 동일한 배치잡이 반복 실행되는 환경에서 발생했습니다. 가끔씩 작업이 예상보다 오래 걸리면서 이전 배치잡이 완료되기 전에 다음 배치가 시작되고, 이로 인해 파드 수가 기하급수적으로 증가하는 현상이 나타났습니다.

이 문제는 모니터링 도구의 [파드 타임라인] 기능을 통해 빠르게 인지할 수 있었습니다. 이 기능은 시간대 별로 파드의 생성 및 종료 여부를 막대 그래프로 표시해주며, 겹치는 배치잡들을 시각적으로 비교할 수 있도록 도와줍니다.

각 막대를 클릭하면 해당 파드의 CPU 사용량, 메모리 사용량, 스로틀 현황까지 확인할 수 있어 다음과 같은 개선 작업을 수행할 수 있었습니다.

• 배치 실행 주기 조정
• 리소스 limit 상향 조정
• 동시에 실행 가능한 배치 수 제한

4. 컨테이너 요약 분석: 전문가가 아니어도 쉽게 이해

마지막으로, 앞서 소개한 사례 전반에 도움이 되는 [컨테이너 요약 분석] 기능을 설명하며 글을 마무리하고자 합니다.

쿠버네티스에 익숙하지 않거나 도입 초기 단계라면 컨테이너나 파드에서 어떤 항목을 점검해야 할지 막막할 수 있습니다. 와탭 쿠버네티스의 [컨테이너 요약 분석] 기능을 사용하면 전체 컨테이너의 리소스 사용 패턴, 오류 발생률, 상태 변화 등을 직관적으로 정리해 보여주며, 문제의 원인을 쉽게 파악하고 개선할 수 있도록 도와줍니다.

예를 들어 다음과 같은 항목을 한눈에 확인할 수 있습니다.

• 어떤 컨테이너가 스로틀이 자주 발생하는지
• 재시작 빈도가 비정상적으로 높은지
• 특정 시간대에 메모리 누수가 발생했는지
• CPU나 메모리 설정이 평균 사용률 대비 과도하게 낮게 설정된 것은 아닌지

쿠버네티스 클러스터는 수십 개 이상의 프로세스와 기능이 결합된 복잡한 플랫폼입니다. 처음 접하는 사용자에게는 문제의 원인을 파악하는 것조차 쉽지 않지만, [컨테이너 요약 분석] 기능을 활용하면 복잡한 쿠버네티스 환경의 문제를 빠르고 정확하게 진단할 수 있습니다.

맺으며

쿠버네티스는 유연하고 강력한 플랫폼이지만, 리소스 설정이 적절하지 않으면 불필요한 비용이 발생하기도 하고, 예기치 않은 부하로 인해 서비스 장애로 이어질 수 있습니다. 따라서 리소스 설정은 매우 중요하며, 이를 지속적으로 모니터링하고 최적화함으로써 서비스의 안정성과 운영 효율을 높일 수 있습니다.

와탭 쿠버네티스 팀은 고객이 안정적으로 서비스를 운영할 수 있도록 다양한 모니터링 및 분석 방안을 끊임없이 고민하고 있습니다. 현재 실행 중인 파드들의 리소스 사용 현황을 와탭 쿠버네티스를 통해 점검해보세요. 리포트와 분석 기능을 통해 보다 안정적인 클러스터 운영에 한 걸음 더 가까워질 수 있습니다. 😉

와탭 쿠버네티스 모니터링 경험해 보기 →