devops

Kubernetes 인플레이스 Pod 리사이즈

발행: (2025년 12월 29일 오후 06:00 GMT+9)
8 min read
원문: Dev.to

Source: Dev.to

Kubernetes In-Place Pod Resize에 대한 커버 이미지

Alik Khilazhev

Source:

배경

약 6년 전, 쿠버네티스에서 대규모 Java 기반 플랫폼을 운영하던 중, 서비스가 애플리케이션 시작 시점에 훨씬 높은 CPU와 메모리를 요구한다는 반복적인 문제를 발견했습니다. Spring Bean과 AutoConfiguration을 과도하게 사용하면서 부트스트랩을 버티기 위해 과도한 리소스 요청과 제한을 설정해야 했지만, 실제로는 이후 대부분 사용되지 않았습니다.

이러한 우회 방법은 결코 옳게 느껴지지 않았습니다. 엔지니어로서 저는 최악의 순간이 아니라 애플리케이션의 실제 라이프사이클을 반영하는 해결책을 원했습니다.

문제를 설명하고 재시작 없이 파드 리소스를 동적으로 조정하는 접근 방식을 제안하는 이슈를 쿠버네티스 저장소에 열었습니다. 해당 이슈는 큰 논의 없이 조용히 관심을 모았고(👍 이모지 13개), 몇 달마다 자동화 봇이 스테일(오래된) 레이블을 붙이려 했으며, 저는 매번 그 레이블을 제거했습니다. 이 과정은 거의 6년 동안 계속되었습니다…

그리고 Kubernetes 1.35가 출시되면서 In‑Place Pod Resize 기능이 안정화(stable)되었습니다.

인‑플레이스 팟 리사이즈가 가져오는 것

인‑플레이스 팟 리사이즈는 쿠버네티스가 안전한 경우에 파드를 재시작하지 않고 CPU 및 메모리 요청과 제한을 업데이트할 수 있게 합니다. 이는 리소스 변경으로 인한 불필요한 재시작을 크게 줄여 중단을 최소화하고 워크로드의 신뢰성을 높입니다.

시간이 지나면서, 특히 시작 후에 리소스 요구가 변하는 애플리케이션에게 이 기능은 오래 기다리던 핵심 요소를 제공합니다.

Source: …

VerticalPodAutoscaler에 미치는 영향

새로운 resizePolicy 필드는 pod‑spec 수준에서 설정됩니다. pod 리소스를 수동으로 변경하는 것이 기술적으로 가능하더라도, 이는 스케일링을 의미하지 않습니다. 실제로 이 기능은 워크로드 컨트롤러에 의해 구동되어야 합니다.

현재 인‑플레이스 pod 크기 조정을 지원하는 유일한 컨트롤러는 Vertical Pod Autoscaler (VPA) 입니다.

이 동작을 가능하게 하는 두 가지 향상 제안이 있습니다:

  1. AEP‑4016: VPA에서 인‑플레이스 업데이트 지원 – InPlaceOrRecreate 업데이트 모드를 도입합니다.
  2. AEP‑7862: CPU 시작 부스트 – 시작 시점에 더 많은 CPU를 제공하여 pod를 일시적으로 부스트합니다. 이는 원래 이슈에서 제안한 접근 방식과 개념적으로 유사합니다.

예시: 두 AEP 기능을 모두 활용한 Deployment + VPA

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: app
          image: my-heavy-java-app:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 1000m
              memory: 1024Mi
            limits:
              cpu: 2000m
              memory: 2048Mi
---
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: InPlaceOrRecreate
  resourcePolicy:
    containerPolicies:
      - containerName: app
        minAllowed:
          cpu: "250m"
          memory: "512Mi"
        maxAllowed:
          cpu: "3000m"
          memory: "8192Mi"
        # The CPU boosted resources can go beyond maxAllowed.
        startupBoost:
          cpu:
            type: Factor
            quantity: "2"

이 설정을 사용하면 시작 시점에 CPU 요청 및 제한이 두 배가 됩니다. 부스트 기간 동안에는 리사이징이 발생하지 않습니다. pod가 Ready 상태에 도달하면 VPA 컨트롤러가 현재 권장값으로 CPU를 다시 낮춥니다. 이후 VPA는 정상적으로 동작하며, 주요 차이점은 가능한 경우 인‑플레이스로 리소스 업데이트가 적용된다는 점입니다.

제한 사항

이 기능이 위에서 설명한 문제를 완전히 해결합니까? 부분적으로만 해결합니다.

  1. 런타임 제약 – Java와 Python 런타임은 현재 재시작 없이 메모리 제한을 조정하는 것을 지원하지 않습니다. 이 제한은 Kubernetes 외부에 존재하며, OpenJDK 프로젝트에서 오픈 티켓으로 추적되고 있습니다.

    OpenJDK 티켓 일러스트레이션

  2. 메모리 제한 감소 – Kubernetes는 아직 In‑Place Pod Resize가 활성화된 경우에도 메모리 제한을 감소시키는 것을 지원하지 않습니다. 이는 메모리 제한 감소 향상 제안서에 문서화된 알려진 제한 사항입니다.

    In‑place Pod Resize – 메모리‑제한 감소

그 결과, In‑place Pod Resize가 CPU와 관련된 시작 시 스파이크를 효과적으로 해결하는 반면, 메모리 크기 조정은 여전히 해결되지 않은 문제로 남아 있습니다.

최종 생각

In‑place Pod Resize는 StartupBoost와 같은 멋진 새로운 기능의 기반을 제공하고 VPA 사용을 보다 신뢰할 수 있게 합니다. 메모리 감소 지원(memory‑decrease support) 및 스케줄링 경쟁 조건(scheduling race condition)과 같은 중요한 격차가 여전히 남아 있지만, 이번 변화는 의미 있는 진전입니다.

시작 단계와 정상 상태 단계가 뚜렷한 워크로드에 대해, Kubernetes는 마침내 현실을 더 가깝게 모델링하기 시작했습니다.

Back to Blog

관련 글

더 보기 »