Kubernetes Pod 부팅 스파이크, 어떻게 해결할까?

 

이전에 부팅스파이크 조절이 어려웠는데 kubernetes 1.35v 가 나오면서 새 기능인  In-Place Resize 으로 조절이 가능해졌습니다! 그에 대한 글 작성 시작!~ 합니다! 

 

---

들어가며

Kubernetes에서 Pod을 운영하다 보면 한 가지 골치 아픈 문제를 만나게 됩니다. 바로 부팅 스파이크(Boot Spike) 입니다.

Pod이 시작될 때 CPU 사용량이 급격히 치솟았다가 안정화되는 현상인데요, 특히 JVM 기반 애플리케이션(Spring Boot, Java)에서 자주 발생합니다.

 

📊 CPU 사용량 변화

300m

100m

50m

⚡ 스파이크

 

 

 

 

 

 

▲ 시작 ▲ Ready → 정상 운영

 

이 글에서는 부팅 스파이크가 왜 문제가 되는지, 그리고 어떻게 해결할 수 있는지 정리해보겠습니다.

---

부팅 스파이크가 왜 문제일까?

1. CPU Throttling으로 인한 시작 지연

Pod의 CPU Request를 50m로 설정했는데, 시작 시 300m가 필요하다면? Kubernetes는 설정된 Request/Limit에 따라 CPU 사용을 제한합니다. 결과적으로 초기화가 느려지고, 심하면 Probe 실패로 재시작이 반복됩니다.

2. HPA 과반응

CPU 사용률 기반 HPA를 사용한다면, 부팅 스파이크를 "실제 부하"로 오인합니다.

시작 스파이크 발생 (CPU 600%)
       ↓
HPA: "부하가 높네! Pod 늘려야겠다"
       ↓
새 Pod 생성 → 또 스파이크 → 또 스케일...
       ↓
Pod 폭증

3. 리소스 딜레마

• Request를 높이면? → 노드 자원 낭비, 비용 증가
• Request를 낮추면? → 부팅 실패, HPA 과반응

---

해결책: In-Place Pod Resize + kube-startup-cpu-boost

2025년 12월 17일, Kubernetes 1.35가 출시되면서 In-Place Pod Resize(InPlacePodVerticalScaling)가 드디어 GA(정식 출시)되었습니다. 이제 Pod을 재시작하지 않고도 CPU/Memory를 동적으로 조정할 수 있습니다.

Google이 만든 kube-startup-cpu-boost는 이 기능을 활용해서 부팅 스파이크 문제를 깔끔하게 해결합니다.

동작 원리

1. Pod 생성 요청
       ↓
2. Webhook이 가로채서 CPU Request 증가 (50m → 200m)
       ↓
3. 높은 CPU로 빠르게 초기화
       ↓
4. Ready 상태 도달
       ↓
5. In-Place Resize로 원복 (200m → 50m)
   ※ Pod 재시작 없음!

설정 방법

먼저 컨트롤러를 설치합니다:

helm repo add kube-startup-cpu-boost <https://google.github.io/kube-startup-cpu-boost>
helm install kube-startup-cpu-boost kube-startup-cpu-boost/kube-startup-cpu-boost \\
  -n kube-startup-cpu-boost-system --create-namespace

그리고 StartupCPUBoost 리소스를 생성합니다:

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: StartupCPUBoost
metadata:
  name: my-app-boost
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-app
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      percentageIncrease:
        value: 300          # 시작 시 4배 (50m → 200m)
  durationPolicy:
    podCondition:
      type: Ready
      status: "True"        # Ready 되면 자동 원복

실제 효과

 

항목	Before	After
시작 시 CPU	50m (throttling)	200m (충분)
초기화 시간	~20초	~9초
정상 운영 CPU	50m	50m (동일)
Pod 재시작	-	없음

초기화 시간이 절반 이상 단축됩니다!

---

EKS 사용자라면?

Kubernetes 1.35는 이미 출시되었지만, EKS는 AWS 관리형 서비스이므로 지원 시점이 다릅니다.

 

환경	In-Place Pod Resize 지원
Kubernetes 1.35+ (Self-managed)	✅ 사용 가능
GKE	✅ 사용 가능
EKS 1.33/1.34	❌ 미지원
EKS 1.35	⏳ 출시 대기

EKS 1.35 출시 전 임시 해결책

EKS 1.35가 출시될 때까지는 다음 방법들을 조합해서 사용하세요:

1. CPU Limit 제거 (가장 효과적)

resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    # cpu: 제거 → 부팅 시 노드 여유분 사용 가능
    memory: 512Mi

CAST.AI의 실제 사례:

• 시작 성공률: 65% → 99%+
• 초기화 시간: 40% 감소

2. startupProbe 설정

startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30    # 최대 150초 대기
  periodSeconds: 5

3. HPA stabilizationWindow

behavior:
  scaleUp:
    stabilizationWindowSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300

EKS 권장 조합 (1.35 출시 전)

spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: 50m
        memory: 200Mi
      limits:
        # cpu: 제거!
        memory: 512Mi
    startupProbe:
      httpGet:
        path: /health
        port: 8080
      failureThreshold: 30
      periodSeconds: 5

---

정리

 

환경	권장 방법
Kubernetes 1.35+	kube-startup-cpu-boost (동적 boost/복원)
EKS 1.33/1.34	CPU Limit 제거 + startupProbe + stabilizationWindow
EKS 1.35 출시 후	kube-startup-cpu-boost로 마이그레이션

Kubernetes 1.35의 In-Place Pod Resize GA는 오랫동안 기다려온 기능입니다. Self-managed 클러스터나 GKE를 사용 중이라면 지금 바로 kube-startup-cpu-boost를 도입해보세요.

EKS 사용자라면 1.35 출시를 기다리면서, 우선 CPU Limit 제거로 부팅 스파이크를 완화하는 것을 권장합니다.

---

참고 자료

• Kubernetes 1.35: In-Place Pod Resize GA (2025.12.17 출시)
• google/kube-startup-cpu-boost
• Startup CPU Boost with In-Place Pod Resize - Piotr's TechBlog
• CAST.AI: Kubernetes Resource Management