WIPI

프로그래밍과 기술 이슈를 빠르게 정리하는 개발 블로그

목록으로

Programming Notes

Kubernetes 1.35: 인플레이스(In-Place) Pod 리사이즈, 안정화(Stable) 단계로 출시

이번 릴리스는 중요한 진전을 보여줍니다: 초기 구상으로부터 6년이 넘는 시간 끝에, Kubernetes v1.27에서 알파(alpha) 버전으로 처음 도입되었고, Kubernetes v1.33에서 베타(beta) 버전으로 승격(graduated)되었던...

작성자

이번 릴리스는 중요한 진전을 보여줍니다: 초기 구상으로부터 6년이 넘는 시간 끝에, Kubernetes v1.27에서 알파(alpha) 버전으로 처음 도입되었고, Kubernetes v1.33에서 베타(beta) 버전으로 승격(graduated)되었던 인플레이스(In-Place) Pod 리사이즈 기능(인플레이스 Pod 수직 스케일링으로도 알려짐)이 이제 Kubernetes 1.35에서 **안정화(stable, GA)**되었습니다!

이번 안정화는 Kubernetes에서 실행되는 워크로드의 리소스 효율성과 유연성을 향상시키는 데 있어 중요한 이정표입니다.

인플레이스 Pod 리사이즈란 무엇인가요?

과거에는 Pod 내 컨테이너에 할당된 CPU 및 메모리 리소스는 불변(immutable)했습니다. 이는 리소스를 변경하려면 전체 Pod를 삭제하고 다시 생성해야 한다는 의미였습니다. 상태 저장 서비스, 배치 작업 또는 지연 시간에 민감한 워크로드의 경우, 이는 엄청나게 중단적인(disruptive) 작업이었습니다.

인플레이스 Pod 리사이즈는 CPU 및 메모리 요청(requests)과 제한(limits)을 가변(mutable)하게 만들어, 실행 중인 Pod 내에서 이 리소스를 조정할 수 있게 해주며, 종종 컨테이너 재시작을 필요로 하지 않습니다.

핵심 개념:

  • 요청 리소스(Desired Resources): 컨테이너의 spec.containers[*].resources 필드는 이제 요청 리소스를 나타냅니다. CPU와 메모리의 경우, 이 필드들은 이제 가변(mutable)합니다.
  • 실제 리소스(Actual Resources): status.containerStatuses[*].resources 필드는 현재 실행 중인 컨테이너에 대해 구성된 리소스를 반영합니다.
  • 리사이즈 트리거: 새로운 resize 하위 리소스(subresource)를 활용하여 Pod의 스펙(specification)에서 원하는 requests와 limits를 업데이트함으로써 리사이즈를 요청할 수 있습니다.

인플레이스 Pod 리사이즈는 어떻게 시작할 수 있나요?

자세한 사용 지침 및 예시는 공식 문서에서 확인할 수 있습니다: 컨테이너에 할당된 CPU 및 메모리 리소스 리사이즈.

어떻게 도움이 되나요?

인플레이스 Pod 리사이즈는 원활한 수직 오토스케일링(vertical autoscaling)과 워크로드 효율성 개선을 가능하게 하는 기본적인 빌딩 블록입니다.

  • 중단 없는 리소스 조정 지연 시간이나 재시작에 민감한 워크로드는 다운타임이나 상태 손실 없이 제자리에서 리소스를 수정할 수 있습니다.
  • 더 강력한 오토스케일링 오토스케일러(Autoscaler)는 이제 더 적은 영향으로 리소스를 조정할 수 있는 권한을 얻었습니다. 예를 들어, 이 기능을 활용하는 Vertical Pod Autoscaler (VPA)의 InPlaceOrRecreate 업데이트 모드가 베타 버전으로 승격되었습니다. 이를 통해 최소한의 중단으로 사용량에 따라 리소스가 자동으로 원활하게 조정될 수 있습니다.
    • 자세한 내용은 AEP-4016을 참조하십시오.
  • 일시적인 리소스 요구 사항 해결 일시적으로 더 많은 리소스가 필요한 워크로드는 신속하게 조정될 수 있습니다. 이는 애플리케이션이 시작 시 더 많은 CPU를 요청한 다음 자동으로 다시 축소되는 CPU 시작 부스트(AEP-7862)와 같은 기능을 가능하게 합니다.

다음은 몇 가지 사용 사례 예시입니다:

  • 플레이어 수 변화에 따라 크기를 조정해야 하는 게임 서버.
  • 사용하지 않을 때는 축소되지만 첫 번째 요청 시 확장될 수 있는 사전에 준비된(pre-warmed) 워커.
  • 효율적인 빈 패킹(bin-packing)을 위해 로드에 따라 동적으로 스케일 조정.
  • 시작 시 JIT 컴파일을 위한 리소스 증가.

베타(1.33)와 안정화(1.35) 사이의 변경 사항

v1.33의 초기 베타 이후, 개발 노력은 주로 커뮤니티 피드백을 기반으로 기능 안정화 및 사용성 개선에 집중되었습니다. 안정화 버전의 주요 변경 사항은 다음과 같습니다:

  • 메모리 제한 감소 이전에는 메모리 제한 감소가 금지되었습니다. 이 제한이 해제되어 이제 메모리 제한 감소가 허용됩니다. Kubelet은 현재 메모리 사용량이 새로운 원하는 제한 미만인 경우에만 리사이즈를 허용하여 OOM-kill을 방지하려고 시도합니다. 하지만 이 검사는 최선을 다하는(best-effort) 것이며 보장되지는 않습니다.
  • 우선순위가 지정된 리사이즈 노드에 모든 리사이즈 요청을 수락할 충분한 공간이 없는 경우, 지연된(Deferred) 리사이즈는 다음 우선순위에 따라 재시도됩니다:
    • PriorityClass
    • QoS 클래스
    • 지연 시간 지연됨(Deferred), 오래된 요청이 먼저 우선순위가 부여됨.
  • Pod 레벨 리소스(알파) Pod 레벨 리소스와 함께 인플레이스 Pod 리사이즈 지원이 자체 기능 게이트(feature gate) 뒤에 도입되었으며, 이는 v1.35에서 알파 버전입니다.
  • 관찰 가능성 향상: 이제 인플레이스 Pod 리사이즈와 특별히 관련된 새로운 Kubelet 메트릭(metrics) 및 Pod 이벤트가 있어 사용자가 리소스 변경 사항을 추적하고 디버깅하는 데 도움이 됩니다.

다음 단계는 무엇인가요?

인플레이스 Pod 리사이즈가 안정화 단계로 졸업하면서 Kubernetes 생태계 전반에 걸쳐 강력한 통합의 문이 열렸습니다. 현재 계획 중인 몇 가지 추가 개선 영역이 있습니다.

오토스케일러 및 기타 프로젝트와의 통합

더 큰 규모에서 워크로드 효율성을 개선하기 위해 여러 오토스케일러 및 기타 프로젝트와의 통합이 계획되어 있습니다. 논의 중인 몇 가지 프로젝트는 다음과 같습니다:

  • VPA CPU 시작 부스트 (AEP-7862): 애플리케이션이 시작 시 더 많은 CPU를 요청하고 특정 기간 후에 다시 축소되도록 허용합니다.
  • 인플레이스 업데이트를 위한 VPA 지원 (AEP-4016): InPlaceOrRecreate를 위한 VPA 지원은 최근 베타 버전으로 승격되었으며, 궁극적인 목표는 이 기능을 안정화 단계로 승격하는 것입니다. InPlace 모드에 대한 지원은 아직 작업 중입니다. 이 풀 리퀘스트를 참조하십시오.
  • Ray 오토스케일러: 인플레이스 Pod 리사이즈를 활용하여 워크로드 효율성을 개선할 계획입니다. 자세한 내용은 이 Google Cloud 블로그 게시물을 참조하십시오.
  • Agent-sandbox "소프트-일시정지(Soft-Pause)": 향상된 지연 시간을 위해 인플레이스 Pod 리사이즈 활용을 조사 중입니다. 자세한 내용은 Github 이슈를 참조하십시오.
  • 런타임 지원: 자바(Java) 및 파이썬(Python) 런타임은 재시작 없이 메모리 리사이징을 지원하지 않습니다. 자바 개발자들과 열린 대화가 진행 중이며, 해당 버그를 참조하십시오.

인플레이스 Pod 리사이즈와의 통합을 통해 이점을 얻을 수 있는 프로젝트가 있다면, 피드백 섹션에 나열된 채널을 통해 연락 주십시오!

기능 확장

현재 인플레이스 Pod 리사이즈는 스왑(swap), 정적 CPU 관리자(static CPU Manager) 및 정적 메모리 관리자(static Memory Manager)와 함께 사용될 때 금지됩니다. 또한, CPU와 메모리 외의 리소스는 여전히 불변입니다. 커뮤니티 요구 사항에 대한 더 많은 피드백이 들어옴에 따라 지원되는 기능 및 리소스 세트를 확장하는 것이 고려 중입니다.

워크로드 선점(preemption) 지원 계획도 있습니다. 높은 우선순위 Pod의 리사이즈를 위한 충분한 공간이 노드에 없는 경우, 낮은 우선순위 Pod를 자동으로 제거하거나 노드를 업사이즈하는 정책을 활성화하는 것이 목표입니다.

안정성 개선

  • kubelet-스케줄러 경쟁 조건 해결 인플레이스 Pod 리사이즈와 관련하여 kubelet과 스케줄러 사이에 알려진 경쟁 조건(race conditions)이 있습니다. 다음 몇 차례 릴리스에 걸쳐 이러한 문제를 해결하기 위한 작업이 진행 중입니다. 자세한 내용은 이슈를 참조하십시오.
  • 더 안전한 메모리 제한 감소 Kubelet의 OOM-kill 방지를 위한 최선을 다하는(best-effort) 검사는 메모리 사용량 검사를 컨테이너 런타임 자체로 옮김으로써 더욱 안전하게 만들 수 있습니다. 자세한 내용은 이슈를 참조하십시오.

피드백 제공

이 기본적인 기능을 더욱 발전시키기 위해, 이 기능을 개선하고 확장하는 방법에 대한 피드백을 공유해 주십시오. 피드백은 GitHub 이슈, 메일링 리스트 또는 Kubernetes #sig-node 및 #sig-autoscaling 커뮤니티와 관련된 Slack 채널을 통해 공유할 수 있습니다.

오랫동안 기다려온 이 기능의 실현에 기여해주신 모든 분들께 감사드립니다!