Kubernetes v1.35에서, 외부 Job 컨트롤러를 지정하는 기능(.spec.managedBy`를 통해)이 정식 출시(General Availability)되었습니다.
이 기능은 외부 컨트롤러가 Job 조정(reconciliation)에 대한 완전한 책임을 지도록 하여, MultiKueue를 사용한 다중 클러스터 디스패치와 같은 강력한 스케줄링 패턴을 가능하게 합니다.
왜 Job 조정을 위임해야 하는가?
이 기능의 주요 동기는 MultiKueue와 같은 다중 클러스터 배치 스케줄링 아키텍처를 지원하는 것입니다.MultiKueue 아키텍처는 관리 클러스터(Management Cluster)와 워커 클러스터(Worker Cluster) 풀을 구분합니다.
- 관리 클러스터는 Job을 디스패치하는 역할을 하지만, 실행하지는 않습니다. 상태 추적을 위해 Job 객체를 수신해야 하지만, Pod 생성 및 실행은 건너뜁니다.
- 워커 클러스터는 디스패치된 Job을 수신하여 실제 Pod를 실행합니다.
- 사용자는 일반적으로 관리 클러스터와 상호 작용합니다. 상태가 자동으로 다시 전파되므로, 워커 클러스터에 직접 접근하지 않고도 Job의 진행 상황을 '실시간으로' 확인할 수 있습니다.
- 워커 클러스터에서는 디스패치된 Job이
.spec.managedBy가 설정되지 않은 상태로 내장 Job 컨트롤러가 관리하는 일반 Job으로 실행됩니다.
.spec.managedBy를 사용함으로써, 관리 클러스터의 MultiKueue 컨트롤러가 Job 조정(reconciliation)을 인계받을 수 있습니다. 이는 워커 클러스터에서 실행 중인 "미러" Job의 상태를 관리 클러스터로 다시 복사합니다.
왜 Job 컨트롤러를 그냥 비활성화하면 안 되나요? 내장 Job 컨트롤러를 완전히 비활성화하여 이론적으로 이를 달성할 수도 있지만, 두 가지 이유로 인해 종종 불가능하거나 비실용적입니다.
- 관리형 컨트롤 플레인: 많은 클라우드 환경에서 Kubernetes 컨트롤 플레인은 잠겨 있어 사용자가 컨트롤러 매니저 플래그를 수정할 수 없습니다.
- 하이브리드 클러스터 역할: 사용자는 종종 관리 클러스터가 일부 무거운 워크로드를 원격 클러스터로 디스패치하지만, 더 작거나 컨트롤 플레인 관련 Job은 여전히 관리 클러스터에서 실행하는 "하이브리드" 모드를 필요로 합니다. `.spec.managedBy`는 Job 단위로 이러한 세분화된 제어를 가능하게 합니다.
.spec.managedBy의 작동 방식
`.spec.managedBy` 필드는 어떤 컨트롤러가 Job을 담당하는지 나타내며, 특히 두 가지 작동 모드가 있습니다.
- 표준: 설정되지 않았거나 예약된 값
kubernetes.io/job-controller로 설정된 경우, 내장 Job 컨트롤러는 평소와 같이 Job을 조정(일반적인 동작)합니다. - 위임: 다른 값으로 설정된 경우, 내장 Job 컨트롤러는 해당 Job에 대한 조정을 전적으로 건너뜁니다.
고아 Pod 또는 리소스 누출을 방지하기 위해 이 필드는 변경 불가능(immutable)합니다. 실행 중인 Job을 한 컨트롤러에서 다른 컨트롤러로 전송할 수 없습니다.
외부 컨트롤러 구현을 고려하고 있다면, 해당 컨트롤러가 Job API 정의에 부합해야 한다는 점을 유의하십시오. 이 부합성을 강제하기 위해 상당한 노력이 광범위한 Job 상태 유효성 검사 규칙을 도입하는 데 사용되었습니다. 자세한 내용은 더 자세히 알아보려면? 섹션을 참조하십시오.
생태계 채택
`.spec.managedBy` 필드는 Kubernetes 배치(batch) 생태계에서 제어를 위임하기 위한 표준 인터페이스로 빠르게 자리 잡고 있습니다.다양한 커스텀 워크로드 컨트롤러는 MultiKueue가 자신들의 조정을 인계받아 여러 클러스터에 걸쳐 오케스트레이션할 수 있도록 이 필드(또는 동등한 필드)를 추가하고 있습니다.
.spec.managedBy를 사용하여 처음부터 커스텀 Job 컨트롤러를 구현하는 것도 가능하지만, 아직 그러한 사례는 관찰되지 않았습니다. 이 기능은 바퀴를 재발명하지 않고 MultiKueue와 같은 위임 패턴을 지원하도록 특별히 설계되었습니다.
더 자세히 알아보려면?
더 자세히 알아보려면 다음을 참조하십시오:사용자 문서 읽기:
설계 역사 심층 탐구:
- 광범위한 Job 상태 유효성 검사 규칙 도입을 포함한 Kubernetes KEP(Enhancement Proposal) Job의 managed-by 메커니즘.
- MultiKueue에 대한 Kueue KEP.
클러스터 간 Job 실행을 위한 작업 가이드에서 MultiKueue가 실제로 .spec.managedBy를 어떻게 사용하는지 살펴보십시오.
감사의 말씀
다른 Kubernetes 기능과 마찬가지로, 많은 분들이 설계 논의, 검토, 테스트 실행, 버그 보고를 통해 이 기능을 구체화하는 데 도움을 주셨습니다.특히 다음 분들께 감사드립니다:
- Maciej Szulik - 지도, 멘토링, 검토에 감사드립니다.
- Filip Křepinský - 지도, 멘토링, 검토에 감사드립니다.
참여하기
이 작업은 Kubernetes [배치 워킹 그룹](https://github.com/kubernetes/community/tree/master/wg-batch)이 [SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)와의 긴밀한 협력과 [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling) 커뮤니티의 강력한 기여를 통해 후원되었습니다.배치 스케줄링, 다중 클러스터 솔루션, 또는 Job API 개선에 관심이 있다면:
- 배치 WG 및 SIG Apps 회의에 참여하십시오.
- WG Batch Slack 채널을 구독하십시오.