[kubernetes] EKS의 Burstable 인스턴스 타입 변경 문제

들어가기 앞서

현재 운영 중인 서비스는 개발, 품질, 운영 환경을 각각 분리하여 구성되어 있다. 비용 최적화를 위해 각 환경의 EC2 및 EKS 워커 노드 인스턴스 타입을 변경하였으며, 이 과정에서 일부 문제가 발생하였다.

개발 및 품질 환경의 경우, 비용 절감을 위해 리소스를 인스턴스 스케줄러를 통해 관리하고 있다. 이에 따라 리소스는 아래와 같이 정기적으로 중지 및 재시작된다:

• EC2 및 RDS: 매일 22시에 인스턴스를 중지하고, 다음 날 08시에 재시작
• EKS 워커 노드: 22시에 노드 인스턴스를 종료(Scale In)하고, 08시에 다시 생성(Scale Out)

문제가 발생한 시점은 08시 EKS 워커 노드가 새로 생성되는 시점이었다. 이때 워커 노드 내의 일부 파드가 Pending 상태로 머물렀으며, 로그를 확인한 결과 다음과 같은 에러가 발생하고 있었다:

• Startup probe failed (timeout) → Probe fail → Pending → CrashLoopBackOff 

Warning Unhealthy 60s (x5 over 5m) kubelet Startup probe failed: Get "http://10.244.1.23:8080/healthz": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

한편, 인스턴스 타입은 변경되었지만 총 리소스(vCPU 및 Memory)는 동일하게 유지되었다. 그럼에도 불구하고, 타입 변경 이후 오히려 더 많은 수의 노드가 생성되었다는 점이 추가로 확인되었다. 해당 오류를 잡기 위해서는 바뀐 인스턴스 타입에 대한 이해가 필요하다. 

AWS CPU 버스트 개념 정리 (t3.large 기준)

• 버스트 가능한 인스턴스란
  • 기본적으로 낮은 수준의 기준 CPU 성능(예: t3.large는 약 30%)을 제공함
  • 하지만 일시적으로 높은 CPU 성능이 필요한 순간에 "버스트"가 가능함
• CPU 크레딧 시스템
  • CPU 사용률이 기준보다 낮을 때 크레딧이 적립됨
  • CPU 사용률이 기준보다 높아질 때는 크레딧을 소모하며 버스트 성능 발휘
• 크레딧 소진 시 동작
  • 크레딧이 없으면 기준 성능 이상으로는 사용할 수 없게 됨
  • 예: t3.large의 경우 크레딧이 0이면 2 vCPU 중 0.6 vCPU (30%)만 사용 가능
  • 이때 CPU throttling이 발생하며, 성능 저하나 애플리케이션 장애 유발 가능
• 버스트의 유연성
  • 마치 CPU 성능을 저축했다가 필요할 때 꺼내 쓰는 구조
  • 유휴 시간 동안 성능을 저장하고, 필요 시 더 높은 처리량 제공
• Unlimited 모드
  • t3 인스턴스는 기본적으로 unlimited 모드가 활성화되어 있어
    크레딧이 없어도 계속 버스트가 가능하지만 초과 사용량에 따라 요금이 부과됨

현재 상황 요약

Request는 인스턴스에 명시된 총 리소스를 기준으로 파드를 배치하는 기준이라는 점이다. 하지만 Burst 발동 기준은 CPU의 '할당량'이 아닌 실제 '사용량'이다.따라서 파드가 모두 배치된 이후 CPU 사용량이 0.6 vCPU 이하라면 문제가 발생하지 않는다.

하지만 파드들이 배치되고 초기화되는 과정에서 노드 전체의 CPU 사용량이 급격히 상승하면, 크레딧이 부족한 상황에서는 CPU가 제한(throttling)되며 문제가 발생할 수 있다. 

또한, Pod 가 리소스를 사용하지 못해 Pending이 지속되면 Cluster Autoscaler 에 의해 노드가 Scale Out 될 수 있다. 

Right Sizing 인스턴스 타입 변경 주의사항

CPU 버스트 인스턴스는 생성될 때 CPU 크레딧이 초기화된다. 그리고 버스트 발동 조건은 CPU 할당량이 아닌 실제 CPU 사용량에 기반한다. 따라서 단순히 CPU 총 용량만 확인하고 이를 기준으로 인스턴스 타입을 변경하면, 파드가 초기화되는 시점에 CPU 사용률이 급격히 증가하고, 전체 리소스 크기에 맞춰 파드는 배치되었음에도 Pending 상태에 빠지는 현상이 발생하고 노드가 증설될 수 있다.

 

Right Sizing이 필요한 상황에서는 단순한 리소스 스펙 비교만으로 인스턴스 타입을 결정해서는 안 된다. 특히 필자처럼 인스턴스 스케줄러를 통해 노드가 주기적으로 중지 및 재생성되는 환경이라면, 파드 생성 시점의 CPU 사용률을 반드시 고려해야 한다.