Kubernetes v1.35: Job Managed By가 GA
Source: Kubernetes Blog
번역을 진행하려면 실제 블로그 본문 텍스트를 제공해 주시겠어요?
본문을 받는 대로 원본 형식과 코드 블록, URL은 그대로 유지하면서 한국어로 번역해 드리겠습니다.
What This Means
- Full responsibility for Job reconciliation can now be delegated to external controllers. → 작업 조정에 대한 전체 책임을 이제 외부 컨트롤러에 위임할 수 있습니다.
- Enables advanced scheduling patterns, such as multi‑cluster dispatching. → 멀티 클러스터 디스패칭과 같은 고급 스케줄링 패턴을 가능하게 합니다.
예시 사용 사례
MultiKueue 프로젝트는 이 기능을 활용하여 여러 클러스터에 걸쳐 Job을 오케스트레이션합니다.
자세한 내용은 공식 Kubernetes v1.35 릴리스 노트를 참고하십시오.
왜 작업 조정(리컨실리에이션)을 위임할까?
이 기능의 주요 동기는 멀티‑클러스터 배치 스케줄링 아키텍처(예: MultiKueue)를 지원하기 위해서입니다.
아키텍처 개요
MultiKueue는 두 종류의 클러스터를 구분합니다:
| 클러스터 | 역할 |
|---|---|
| 관리 클러스터 | 작업(Job)을 디스패치하지만 실행하지는 않습니다. 상태를 추적하기 위해 Job 객체를 받아들이지만 Pod 생성 및 실행은 건너뜁니다. |
| 워커 클러스터 | 디스패치된 작업을 받아 실제 Pod을 실행합니다. |
- 사용자는 보통 관리 클러스터와 상호작용합니다.
- 상태가 자동으로 되돌아오기 때문에, 사용자는 워커 클러스터에 접근할 필요 없이 실시간으로 작업 진행 상황을 확인할 수 있습니다.
- 워커 클러스터에서는 디스패치된 작업이 내장 Job 컨트롤러에 의해 관리되는 일반 Job으로 실행되며,
.spec.managedBy필드는 설정되지 않습니다.
.spec.managedBy의 역할
.spec.managedBy를 설정하면 관리 클러스터의 MultiKueue 컨트롤러가 작업의 조정을 인계받을 수 있습니다. 워커 클러스터에서 실행 중인 “미러” Job의 상태를 관리 클러스터로 복사합니다.
왜 단순히 Job 컨트롤러를 비활성화하지 않을까?
내장 Job 컨트롤러를 완전히 비활성화하는 것은 다음 두 가지 주요 이유 때문에 불가능하거나 비현실적인 경우가 많습니다:
- 관리형 컨트롤 플레인 – 많은 클라우드 환경에서 Kubernetes 컨트롤 플레인이 잠겨 있어 사용자가 controller‑manager 플래그를 수정할 수 없습니다.
- 하이브리드 클러스터 역할 – 사용자는 종종 관리 클러스터가 원격 클러스터에 무거운 워크로드를 디스패치하면서도 동시에 로컬에서 작은 작업이나 컨트롤‑플레인 관련 작업을 실행해야 하는 “하이브리드” 모드가 필요합니다.
.spec.managedBy는 작업 단위로 필요한 세분성을 제공합니다.
.spec.managedBy 작동 방식
.spec.managedBy 필드는 어떤 컨트롤러가 Job을 담당하는지 나타냅니다. 두 가지 동작 모드를 지원합니다:
| 모드 | 값 | 동작 |
|---|---|---|
| 표준 | unset 또는 kubernetes.io/job-controller (예약됨) | 내장 Job 컨트롤러가 기존대로 Job을 조정합니다. |
| 위임 | 그 외의 문자열 | 내장 Job 컨트롤러가 해당 Job에 대한 조정을 건너뜁니다. |
Note: 이 필드는 불변입니다. 실행 중인 Job을 한 컨트롤러에서 다른 컨트롤러로 옮길 수 없으며, 이는 고아가 된 Pod이나 리소스 누수를 방지하는 데 도움이 됩니다.
외부 컨트롤러 구현
외부 컨트롤러를 구현하려는 경우, Job API 사양을 준수하는지 확인하십시오. 준수 여부는 광범위한 Job 상태 검증 규칙을 통해 강제됩니다.
에코시스템 채택
.spec.managedBy 필드는 쿠버네티스 배치 에코시스템에서 제어 위임을 위한 표준 인터페이스로 빠르게 자리 잡고 있습니다.
다양한 커스텀 워크로드 컨트롤러가 이 필드(또는 동등한 필드)를 추가하여 MultiKueue가 해당 컨트롤러의 리컨실리이션을 인계받고 클러스터 전반에 걸쳐 오케스트레이션할 수 있도록 하고 있습니다:
.spec.managedBy를 사용해 처음부터 커스텀 Job 컨트롤러를 구현하는 것도 가능하지만, 아직은 관찰되지 않았습니다. 이 기능은 MultiKueue와 같은 위임 패턴을 지원하도록 특별히 설계된 것으로, 휠을 다시 발명할 필요가 없습니다.
어떻게 더 배울 수 있나요?
문서
- Jobs –
- Delegation of managing a Job object to an external controller –
- MultiKueue –
설계 이력
- Kubernetes Enhancement Proposal (KEP) – Job의
managedBy메커니즘- Overview: –
- Job‑status validation rules: –
- Kueue KEP – MultiKueue –
실용 가이드
- See how MultiKueue uses
.spec.managedByin the task guide for running Jobs across clusters –
감사 인사
다른 Kubernetes 기능과 마찬가지로, 설계 논의, 리뷰, 테스트 실행 및 버그 보고를 통해 많은 사람들이 이 기능을 형성하는 데 도움을 주었습니다. 특히 다음 분들께 감사드립니다:
- Maciej Szulik – 지도, 멘토링 및 리뷰 제공.
- Filip Křepinský – 지도, 멘토링 및 리뷰 제공.
Get Involved
This work was sponsored by the Kubernetes Batch Working Group in close collaboration with SIG Apps, and with strong input from the SIG Scheduling community.
If you are interested in batch scheduling, multi‑cluster solutions, or further improving the Job API, you can:
- Join us in the Batch WG and SIG Apps meetings.
- Subscribe to the WG Batch Slack channel.