Kubernetes v1.36에서는 중단된(suspended) Job의 Pod 템플릿에서 컨테이너 리소스 요청(requests) 및 제한(limits)을 수정할 수 있는 기능이 베타(beta)로 승격되었습니다. v1.35에서 알파(alpha)로 처음 도입된 이 기능을 통해 큐 컨트롤러(queue controllers)와 클러스터 관리자는 Job이 시작되거나 재개되기 전, 중단된 상태에서 CPU, 메모리, GPU 및 확장 리소스 사양을 조정할 수 있습니다.
왜 중단된 Job의 Pod 리소스를 수정해야 할까요?
배치(Batch) 및 머신러닝 워크로드는 Job 생성 시점에 리소스 요구 사항을 정확히 알 수 없는 경우가 많습니다. 최적의 리소스 할당은 현재 클러스터의 가용 용량, 큐 우선순위, 그리고 GPU와 같은 특수 하드웨어의 가용 상태에 따라 달라집니다.
이 기능이 도입되기 전에는 Job의 Pod 템플릿에 설정된 리소스 요구 사항은 한 번 설정되면 변경할 수 없었습니다. 만약 Kueue와 같은 큐 컨트롤러가 중단된 Job을 실행하기 위해 리소스를 변경해야 한다고 판단하면, 기존 Job을 삭제하고 다시 생성하는 방법뿐이었습니다. 이 과정에서 Job과 관련된 메타데이터, 상태 또는 이력이 모두 손실되었습니다. 또한, 이 기능은 클러스터 부하가 높을 때 특정 CronJob 인스턴스가 실행되지 못하고 실패하는 대신, 리소스를 줄여서 천천히라도 진행할 수 있는 방법을 제공합니다.
처음에 4개의 GPU를 요청하는 머신러닝 학습 Job을 가정해 보겠습니다:
apiVersion: batch/v1
kind: Job
metadata:
name: training-job-example-abcd123
labels:
app.kubernetes.io/name: trainer
spec:
suspend: true
template:
metadata:
annotations:
kubernetes.io/description: "ML training, ID abcd123"
spec:
containers:
- name: trainer
image: example-registry.example.com/training:2026-04-23T150405.678
resources:
requests:
cpu: "8"
memory: "32Gi"
example-hardware-vendor.com/gpu: "4"
limits:
cpu: "8"
memory: "32Gi"
example-hardware-vendor.com/gpu: "4"
restartPolicy: Never
클러스터 리소스를 관리하는 큐 컨트롤러가 현재 2개의 GPU만 사용 가능하다고 판단할 수 있습니다. 이 기능을 사용하면 컨트롤러는 Job을 재개하기 전에 리소스 요청 사항을 업데이트할 수 있습니다:
apiVersion: batch/v1
kind: Job
metadata:
name: training-job-example-abcd123
labels:
app.kubernetes.io/name: trainer
spec:
suspend: true
template:
metadata:
annotations:
kubernetes.io/description: "ML training, ID abcd123"
spec:
containers:
- name: trainer
image: example-registry.example.com/training:2026-04-23T150405.678
resources:
requests:
cpu: "4"
memory: "16Gi"
example-hardware-vendor.com/gpu: "2"
limits:
cpu: "4"
memory: "16Gi"
example-hardware-vendor.com/gpu: "2"
restartPolicy: Never
리소스가 업데이트되면 컨트롤러는 spec.suspend를 false로 설정하여 Job을 재개하고, 새로운 Pod는 조정된 리소스 사양으로 생성됩니다.
작동 방식
Kubernetes API 서버는 중단된 Job에 대해 특별히 Pod 템플릿 리소스 필드의 불변성 제약을 완화합니다. 새로운 API 타입은 도입되지 않았으며, 기존 Job 및 Pod 템플릿 구조 내에서 유효성 검사 규칙을 완화하여 이 변화를 수용했습니다.
수정 가능한 필드는 다음과 같습니다:
spec.template.spec.containers[*].resources.requestsspec.template.spec.containers[*].resources.limitsspec.template.spec.initContainers[*].resources.requestsspec.template.spec.initContainers[*].resources.limits
리소스 업데이트는 다음 조건이 충족될 때 허용됩니다:
- Job의
spec.suspend가true로 설정되어 있어야 합니다. - 이전에 실행 중이었다가 중단된 Job의 경우, 리소스 수정을 수락하기 전에 모든 활성 Pod가 종료되어야 합니다(
status.active가 0이어야 함).
표준 리소스 유효성 검사는 여전히 적용됩니다. 예를 들어, 리소스 제한(limits)은 요청(requests)보다 크거나 같아야 하며, 확장 리소스는 필요한 경우 정수로 지정해야 합니다.
베타 버전에서 달라진 점
Kubernetes v1.36에서 베타로 승격됨에 따라 MutablePodResourcesForSuspendedJobs 기능 게이트(feature gate)가 기본적으로 활성화됩니다. 즉, v1.36을 실행하는 클러스터에서는 API 서버의 추가 설정 없이 이 기능을 바로 사용할 수 있습니다.
직접 시도해 보기
클러스터가 Kubernetes v1.36 이상을 실행 중이라면 이 기능은 기본적으로 활성화되어 있습니다. v1.35 클러스터의 경우, kube-apiserver에서 MutablePodResourcesForSuspendedJobs 기능 게이트를 활성화하세요.
중단된 Job을 생성하고 kubectl edit이나 컨트롤러를 통해 컨테이너 리소스를 업데이트한 뒤 Job을 재개하여 테스트해 볼 수 있습니다:
# 중단된 Job 생성
kubectl apply -f my-job.yaml --server-side
# 리소스 요청 수정
kubectl edit job training-job-example-abcd123
# Job 재개
kubectl patch job training-job-example-abcd123 -p '{"spec":{"suspend":false}}'
고려 사항
실행 중이던 Job을 중단하는 경우
이미 실행 중이었던 Job을 중단하는 경우, 리소스를 수정하기 전에 해당 Job의 모든 활성 Pod가 종료될 때까지 기다려야 합니다. API 서버는 status.active가 0보다 큰 동안에는 리소스 수정을 거부합니다. 이는 실행 중인 Pod와 업데이트된 Pod 템플릿 간의 불일치를 방지하기 위함입니다.
Pod 교체 정책 (Pod replacement policy)
실패한 Pod가 발생할 수 있는 Job에서 이 기능을 사용할 때는 podReplacementPolicy: Failed 설정을 고려해 보세요. 이는 이전 Pod가 완전히 종료된 후에만 교체용 Pod가 생성되도록 보장하여, 겹치는 Pod들 사이의 리소스 경합을 방지합니다.
리소스 클레임 (ResourceClaims)
동적 리소스 할당(DRA)의 resourceClaimTemplates는 여전히 불변입니다. 워크로드에서 DRA를 사용하는 경우, 리소스 변경 사항에 맞춰 클레임 템플릿을 별도로 다시 생성해야 합니다.
참여하기
이 기능은 SIG Apps에서 WG Batch의 의견을 수렴하여 개발되었습니다. 두 그룹 모두 이 기능이 안정화(stable) 단계로 나아가는 동안 여러분의 피드백을 환영합니다.
다음 채널을 통해 연락하실 수 있습니다: