Kubernetes 1.35: 인플레이스 Pod 크기 조정이 안정화 단계로 진입

Source: Kubernetes Blog

위에 제공된 소스 링크 외에 번역할 텍스트가 포함되어 있지 않습니다. 번역이 필요한 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

Release Announcement

이 릴리스는 중요한 단계입니다: 초기 구상이 시작된 지 6년이 넘은 In‑Place Pod Resize 기능(또는 In‑Place Pod Vertical Scaling이라 불리는)이 Kubernetes v1.27에서 alpha로 처음 소개된 후 Kubernetes v1.33에서 beta로 승격되었으며, 이제 Kubernetes v1.35에서 **stable (GA)**가 되었습니다!

이번 정식 승격은 Kubernetes에서 실행되는 워크로드의 자원 효율성과 유연성을 향상시키는 중요한 이정표입니다.

인플레이스 팟 리사이즈

역사적으로, 팟 안 컨테이너에 정의된 CPU와 메모리 리소스는 불변이었습니다.
이를 변경하려면 전체 팟을 삭제하고 다시 생성해야 했으며, 이는 다음과 같은 경우에 방해가 되는 작업이었습니다:

• 상태 저장 서비스
• 배치 작업
• 지연에 민감한 워크로드

인플레이스 팟 리사이즈는 CPU와 메모리 요청(requests) 및 **제한(limits)**을 가변으로 만들어, 팟이 실행 중일 때도 컨테이너를 재시작하지 않고 리소스를 조정할 수 있게 합니다.

핵심 개념

인플레이스 리사이즈 수행 방법

1. 팟 스펙을 편집(또는 kubectl patch/kubectl apply 사용)하여 spec.containers 아래의 resources 섹션을 수정합니다.

   spec:
     containers:
     - name: my-app
       resources:
         requests:
           cpu: "500m"
           memory: "256Mi"
         limits:
           cpu: "1"
           memory: "512Mi"

2. resize 서브리소스를 사용해 리사이즈 요청을 제출합니다:

   kubectl replace --subresource=resize -f pod-resize.yaml

3. 변경 사항 확인:

   kubectl get pod -o jsonpath='{.status.containerStatuses[*].resources}'

장점

• 무중단 업데이트로 리소스 집약적인 워크로드를 처리합니다.
• 성능 튜닝을 빠르게 반복할 수 있습니다.
• 운영 오버헤드 감소—단순 스케일링을 위해 팟을 삭제/재생성할 필요가 없습니다.

인플레이스 팟 리사이즈는 최신 쿠버네티스 릴리스에서 표준 기능으로 제공되어, 프로덕션 워크로드에 보다 유연하고 즉각적인 리소스 관리가 가능해졌습니다.

인플레이스 팟 리사이즈를 시작하려면 어떻게 해야 하나요?

공식 문서에 자세한 사용 방법과 예제가 제공됩니다:

Resize CPU and Memory Resources assigned to Containers

Source: …

이것이 어떻게 도움이 되나요?

인‑플레이스 Pod 크기 조정은 원활한 수직 자동 스케일링을 가능하게 하고 워크로드 효율성을 향상시키는 기본적인 빌딩 블록입니다.

이점

• 중단 없이 리소스 조정
  지연 시간이나 재시작에 민감한 워크로드는 인‑플레이스 방식으로 리소스를 수정할 수 있어 다운타임이나 상태 손실을 방지합니다.

• 보다 강력한 자동 스케일링
  자동 스케일러가 영향을 최소화하면서 리소스를 조정할 수 있습니다. 예를 들어, 베타 단계로 진입한 Vertical Pod Autoscaler(VPA)의 InPlaceOrRecreate 업데이트 모드는 이 기능을 활용해 사용량에 따라 파드를 자동·무중단으로 크기 조정합니다.

  자세한 내용은 AEP‑4016 enhancement를 참조하십시오.

• 일시적인 리소스 요구 사항 해결
  일시적으로 더 많은 리소스가 필요한 워크로드를 빠르게 조정할 수 있습니다. 이는 CPU Startup Boost(AEP‑7862)와 같은 기능을 가능하게 하며, 애플리케이션이 시작 시 추가 CPU를 요청하고 이후 자동으로 축소됩니다.

사용 사례 예시

• 플레이어 수에 따라 규모가 변하는 게임 서버.
• 유휴 시 축소되고 첫 요청 시 확장되는 사전 워밍된 워커.
• 워크로드를 효율적으로 빈‑패킹하기 위한 동적 스케일링.
• 시작 시점에 즉시 컴파일(JIT)을 위해 일시적으로 리소스를 늘리는 경우.

Changes Between Beta (1.33) and Stable (1.35)

Since the initial beta in v1.33, development has focused on stabilizing the feature and improving its usability based on community feedback. Below are the primary changes introduced in the stable release v1.35.

1. Memory‑limit Decrease

• Previously, decreasing memory limits was prohibited.
• This restriction has been lifted; memory‑limit decreases are now permitted.
• The Kubelet will try to prevent OOM‑kills by allowing the resize only if the current memory usage is below the new desired limit.
• Note: This check is best‑effort and not guaranteed.

2. Prioritized Resizes

When a node lacks sufficient room to satisfy all resize requests, Deferred resizes are re‑attempted based on the following priority order:

1. PriorityClass
2. QoS class
3. Duration of the Deferred state – older requests are prioritized first.

3. Pod‑Level Resources (Alpha)

• In‑place Pod Resize now supports Pod Level Resources.
• This capability is gated behind a feature flag and is alpha in v1.35.

4. Increased Observability

• New Kubelet metrics and Pod events have been added specifically for In‑Place Pod Resize.
• These enhancements help users track and debug resource changes more effectively.

Source: …

다음은 무엇인가요?

In‑Place Pod Resize 가 stable 로 졸업함에 따라 Kubernetes 생태계 전반에 걸친 강력한 통합의 문이 열렸습니다. 현재 계획 중인 추가 개선 영역이 몇 가지 있습니다.

Autoscaler 및 기타 프로젝트와의 통합

Autoscaler 및 관련 프로젝트와의 통합을 통해 대규모 환경에서 워크로드 효율성을 높이는 것이 목표입니다. 논의 중인 프로젝트는 다음과 같습니다.

• VPA CPU 시작 부스트 – AEP‑7862
  애플리케이션이 시작 시 더 많은 CPU 를 요청하고, 일정 시간이 지나면 다시 축소할 수 있도록 합니다.

• In‑place 업데이트를 위한 VPA 지원 – AEP‑4016
  InPlaceOrRecreate 지원이 beta 로 졸업했으며, 이 기능을 stable 로 올리는 것이 목표입니다. 순수 InPlace 모드 지원은 아직 진행 중이며, 자세한 내용은 PR #8818 을 참고하세요.

• Ray autoscaler – In‑Place Pod Resize 를 활용해 워크로드 효율성을 향상시키는 계획이 있습니다. 자세한 내용은 Google Cloud 블로그 게시물 을 확인하세요.

• Agent‑sandbox “Soft‑Pause” – 지연 시간을 낮추기 위해 In‑Place Pod Resize 사용을 조사 중입니다. 관련 내용은 GitHub 이슈 를 참고하세요.

• 런타임 지원 – Java 와 Python 런타임은 현재 재시작 없이 메모리를 리사이즈할 수 없습니다. Java 개발자와의 공개 논의가 진행 중이며, 자세한 내용은 JDK 버그 를 참고하세요.

프로젝트가 In‑Place Pod Resize 와의 통합을 통해 혜택을 받을 수 있다고 생각되면, Feedback 섹션에 나와 있는 채널을 통해 연락해 주세요.

기능 확장

현재 In‑Place Pod Resize 는 다음 상황에서 금지됩니다.

• Swap
• 정적 CPU Manager
• 정적 Memory Manager

CPU 와 메모리를 제외한 다른 리소스는 변경할 수 없습니다. 커뮤니티 피드백을 수집하면서 지원되는 기능 및 리소스 범위를 확대하는 방안을 검토하고 있습니다.

향후 계획에는 워크로드 선점 도 포함됩니다. 노드 용량이 부족해 고우선순위 pod 를 리사이즈할 수 없을 때, 정책에 따라 낮은 우선순위 pod 를 자동으로 퇴출하거나 노드를 확장할 수 있습니다.

안정성 향상

• kubelet‑scheduler 레이스 컨디션 해결
  kubelet 과 scheduler 사이에 존재하는 알려진 레이스 컨디션이 In‑Place Pod Resize 에 영향을 줍니다. 향후 릴리스에서 이 문제를 해결하기 위한 작업이 진행 중이며, 자세한 내용은 issue #126891 을 참고하세요.

• 메모리 제한 감소 시 안전성 강화
  kubelet 의 최선 노력 OOM‑kill 방지 메커니즘을 컨테이너 런타임 자체로 메모리 사용량 검사를 이동시켜 보다 안전하게 만들 수 있습니다. 자세한 내용은 issue #135670 을 확인하세요.

피드백 제공

이 기능을 개선하고 확장하는 데 도움을 주고 싶다면 여러분의 의견을 환영합니다!

• GitHub: 해당 저장소에 이슈를 열어 주세요.

• Mailing Lists: 적절한 Kubernetes 메일링 리스트에 여러분의 생각을 공유해 주세요.

• Slack: Kubernetes 커뮤니티에서 대화에 참여하세요:

  • #sig-node
  • #sig-autoscaling

오래 기다려온 이 기능을 현실로 만든 모든 분들께 감사드립니다!