쿠버네티스 v1.36: 파드 수준 리소스의 인플레이스(In-Place) 수직 스케일링 베타 단계로 승격

v1.34에서 파드 수준 리소스(Pod-Level Resources)가 베타 단계로 진입하고 v1.35에서 인플레이스 파드 수직 스케일링(In-Place Pod Vertical Scaling)이 정식 출시(GA)된 데 이어, 쿠버네티스 커뮤니티는 파드 수준 리소스의 인플레이스 수직 스케일링 기능이 v1.36에서 베타로 승격되었음을 발표하게 되어 매우 기쁩니다!

이 기능은 현재 InPlacePodLevelResourcesVerticalScaling 기능 게이트를 통해 기본적으로 활성화되어 있습니다. 이를 통해 사용자는 실행 중인 파드의 전체 리소스 할당량(.spec.resources)을 업데이트할 수 있으며, 대부분의 경우 컨테이너를 재시작할 필요가 없습니다.

왜 파드 수준의 인플레이스 크기 조정인가요?

파드 수준 리소스 모델은 컨테이너들이 리소스를 공동으로 공유할 수 있게 함으로써, 사이드카가 포함된 복잡한 파드의 관리 방식을 단순화했습니다. v1.36에서는 이제 이 통합된 리소스 경계를 실시간으로 조정할 수 있습니다.

이는 개별 컨테이너에 제한(limit)이 정의되지 않은 파드에서 특히 유용합니다. 이러한 컨테이너들은 새로 조정된 파드 수준의 크기에 맞춰 자신의 유효 경계를 자동으로 확장하므로, 매번 컨테이너별로 리소스를 다시 계산할 필요 없이 피크 시간대에 공유 리소스 풀을 늘릴 수 있습니다.

리소스 상속과 `resizePolicy`

파드 수준의 크기 조정이 시작되면, Kubelet은 파드 수준의 예산으로부터 제한을 상속받는 모든 컨테이너에 대해 이를 크기 조정 이벤트로 처리합니다. 재시작이 필요한지 여부를 결정하기 위해 Kubelet은 개별 컨테이너 내에 정의된 resizePolicy를 참조합니다.

중단 없는 업데이트(Non-disruptive Updates): 컨테이너의 resizePolicy가 NotRequired로 설정된 경우, Kubelet은 컨테이너 런타임 인터페이스(CRI)를 통해 cgroup 제한을 동적으로 업데이트하려고 시도합니다.
중단이 발생하는 업데이트(Disruptive Updates): RestartContainer로 설정된 경우, 새로운 통합 경계를 안전하게 적용하기 위해 컨테이너를 재시작합니다.

참고: 현재 resizePolicy는 파드 수준에서는 지원되지 않습니다. Kubelet은 업데이트를 인플레이스로 적용할지 또는 재시작이 필요한지 결정할 때 항상 개별 컨테이너의 설정을 따릅니다.

예시: 공유 리소스 풀 스케일링

이 시나리오에서는 파드가 2 CPU의 파드 수준 제한으로 정의되어 있습니다. 개별 컨테이너에는 자체 제한이 정의되어 있지 않으므로 이 전체 풀을 공유합니다.

1. 초기 파드 사양

apiVersion: v1
kind: Pod
metadata:
  name: shared-pool-app
spec:
  resources: # 파드 수준 제한
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: main-app
    image: my-app:v1
    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]
  - name: sidecar
    image: logger:v1
    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]

2. 크기 조정 작업

CPU 용량을 4 CPU로 두 배 늘리려면 resize 하위 리소스(subresource)를 사용하여 패치를 적용합니다.

kubectl patch pod shared-pool-app --subresource resize --patch \
 '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'

노드 수준의 현실: 실행 가능성 및 안전성

크기 조정 패치를 적용하는 것은 첫 번째 단계일 뿐입니다. Kubelet은 노드 안정성을 보장하기 위해 몇 가지 검사를 수행하고 특정 순서를 따릅니다.

1. 타당성 검사 (The feasibility check)

크기 조정을 허용하기 전에, Kubelet은 새로운 통합 요청량이 노드의 할당 가능 용량(allocatable capacity) 내에 들어오는지 확인합니다. 만약 노드 리소스가 초과되면 크기 조정은 무시되지 않고, 대신 PodResizePending 상태에 Deferred(지연됨) 또는 Infeasible(실행 불가) 상태가 반영되어 왜 리소스 경계가 커지지 않았는지에 대한 즉각적인 피드백을 제공합니다.

2. 업데이트 순서 (Update sequencing)

리소스 "오버슈트(overshoot)"를 방지하기 위해 Kubelet은 특정 순서로 cgroup 업데이트를 조정합니다.

리소스 증가 시: 파드 수준의 cgroup을 먼저 확장하여 공간을 만든 후, 개별 컨테이너의 cgroup을 확장합니다.
리소스 감소 시: 컨테이너 cgroup을 먼저 제한(throttle)한 다음, 통합된 파드 수준의 cgroup을 축소합니다.

관찰 가능성: 크기 조정 상태 추적

베타 단계로 넘어오면서, 쿠버네티스는 **파드 조건(Pod Conditions)**을 사용하여 크기 조정의 생명 주기를 추적합니다.

PodResizePending: 사양(spec)은 업데이트되었으나 노드가 아직 변경 사항을 수락하지 않은 상태입니다 (예: 용량 부족).
PodResizeInProgress: 노드가 크기 조정을 수락(status.allocatedResources)했으나, 변경 사항이 아직 cgroup에 완전히 적용되지 않은 상태입니다 (status.resources).

status:
  allocatedResources:
    cpu: "4"
  resources:
    limits:
      cpu: "4"
  conditions:
  - type: PodResizeInProgress
    status: "True"

제약 조건 및 요구 사항

cgroup v2 전용: 정확한 통합 적용을 위해 필요합니다.
CRI 지원: UpdateContainerResources CRI 호출을 지원하는 컨테이너 런타임이 필요합니다 (예: containerd v2.0+ 또는 CRI-O).
기능 게이트: PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, NodeDeclaredFeatures가 필요합니다.
Linux 전용: 현재 Linux 기반 노드에서만 사용할 수 있습니다.

향후 계획

정식 출시(GA)를 향해 나아가면서, 커뮤니티는 VPA(Vertical Pod Autoscaler) 통합에 집중하고 있습니다. 이를 통해 VPA가 파드 수준의 리소스 권장 사항을 발행하고 인플레이스 작동을 자동으로 트리거할 수 있게 될 것입니다.

시작하기 및 피드백 제공

이 기능을 테스트해 보시고 표준 쿠버네티스 소통 채널을 통해 피드백을 주시기 바랍니다.