Cloud Native Operations

한국어

English

한국어

English

Appearance

Kubeflow Trainer와 분산 학습 퀴즈 ​

이 퀴즈는 레거시 Training Operator의 프레임워크별 CRD, Kubeflow Trainer v2의 통합 TrainJob/런타임 모델로의 전환, Kubernetes에서의 분산 학습 메커니즘에 대한 이해를 확인합니다.

객관식 문제 ​

  1. 2021년에 통합된 기존(v1) Training Operator의 근본적인 아키텍처 방식은 무엇이었습니까?
    • A) 모든 프레임워크가 공유하는 단일 CRD를 두고 런타임에 프레임워크를 감지
    • B) ML 프레임워크마다 별도의 CRD(예: PyTorchJob, TFJob, MPIJob)를 두고, 각각 그 프레임워크의 분산 학습 규약을 구현하는 자체 컨트롤러를 가짐
    • C) CRD가 전혀 없고 학습 인자를 이미지에 박아 넣은 kubectl run 컨테이너로 작업을 직접 제출
    • D) framework 필드를 가진 단일 TrainingJob CRD와 하나의 공유 컨트롤러
정답 보기

정답: B) ML 프레임워크마다 별도의 CRD(예: PyTorchJob, TFJob, MPIJob)를 두고, 각각 그 프레임워크의 분산 학습 규약을 구현하는 자체 컨트롤러를 가짐

설명: v1 Training Operator는 PyTorchJob, TFJob, MPIJob 등 프레임워크당 하나의 CRD를 제공했고, 각 CRD는 해당 프레임워크만의 분산 학습 규약(PyTorch의 랭크/환경 변수 모델 vs. TensorFlow의 TF_CONFIG)을 이해하는 자체 컨트롤러가 뒷받침했습니다.

  1. PyTorchJob 컨트롤러가 워커들이 torch.distributed 프로세스 그룹을 구성할 수 있도록 주입한 환경 변수는 무엇입니까?
    • A) TF_CONFIG만
    • B) MASTER_ADDR, RANK, WORLD_SIZE
    • C) KUBEFLOW_HOST와 KUBEFLOW_PORT
    • D) POD_IP와 POD_NAMESPACE
정답 보기

정답: B) MASTER_ADDR, RANK, WORLD_SIZE

설명:PyTorchJob 컨트롤러는 각 워커 Pod에 MASTER_ADDR, RANK, WORLD_SIZE를 주입해 PyTorch의 torch.distributed 메커니즘이 프로세스 그룹을 구성하고 조율할 수 있게 했습니다.

  1. v1 Training Operator와 비교했을 때 Kubeflow Trainer v2가 도입한 핵심 아키텍처 변화는 무엇입니까?
    • A) 기존 CRD 위에 프레임워크별 CRD를 더 추가한다
    • B) 프레임워크별 CRD를 통합 TrainJob API와 재사용 가능한 TrainingRuntime/ClusterTrainingRuntime 템플릿으로 대체한다
    • C) 컨트롤러를 완전히 제거하고 어드미션 웹훅에만 의존한다
    • D) TrainJob과 ClusterTrainingRuntime을 다시 하나의 프레임워크별 CRD로 합친다
정답 보기

정답: B) 프레임워크별 CRD를 통합 TrainJob API와 재사용 가능한 TrainingRuntime/ClusterTrainingRuntime 템플릿으로 대체한다

설명: 프레임워크마다 CRD와 컨트롤러를 두는 대신, Trainer v2는 TrainJob(무엇을 실행할지)과 TrainingRuntime/ClusterTrainingRuntime(어떻게 실행할지 — 재사용 가능한 프레임워크별 실행 템플릿)을 도입해 작업 제출과 분산 실행 메커니즘을 분리합니다.

  1. TrainJob / ClusterTrainingRuntime 구조에서, 일반적으로 플랫폼 팀이 소유하고 여러 학습 실행에 걸쳐 재사용되는 객체는 무엇입니까?
    • A) TrainJob
    • B) ClusterTrainingRuntime
    • C) 두 객체 모두 실행마다 새로 생성된다
    • D) 둘 다 아니고 대신 PyTorchJob이 생성된다
정답 보기

정답: B) ClusterTrainingRuntime

설명:ClusterTrainingRuntime(또는 네임스페이스 범위의 TrainingRuntime)은 플랫폼 팀이 한 번 정의해두는 재사용 가능한 템플릿으로, 컨테이너 이미지와 분산 실행 메커니즘을 담습니다. 개별 TrainJob은 kind/name으로 참조하고 허용된 실행별 설정을 지정합니다. numNodes는 학습 Pod 수이며 EC2 인스턴스 수와 동일하지 않습니다.

  1. Kubeflow Trainer v2.2가 정식으로 지원을 추가한 두 가지 학습 런타임은 무엇입니까?
    • A) TensorFlow와 MXNet
    • B) JAX와 XGBoost
    • C) Scikit-learn과 ONNX
    • D) Spark MLlib과 H2O
정답 보기

정답: B) JAX와 XGBoost

설명: Kubeflow Trainer의 릴리스 노트에 따르면, 2026년 3월 20일 출시된 v2.2는 기존 PyTorch 지원에 더해 JAX와 XGBoost 학습 런타임을 정식으로 추가했고, Flux 정책·통합도 추가했습니다. trainerStatus는 alpha TrainJobStatus gate가 기본 false이며 학습 코드의 명시적 보고가 필요합니다.

  1. Kubeflow Community Distribution 26.03.1 릴리스 기준으로, v1에서 Trainer v2로의 마이그레이션 현황을 가장 정확하게 설명한 것은 무엇입니까?
    • A) 마이그레이션은 완전히 끝났고 모든 배포판에서 레거시 Training Operator가 제거되었다
    • B) 26.03.1 배포판에는 레거시 Training Operator(1.9.2)가 Trainer v2와 함께 여전히 포함되어 있으며, 기존 API와 TrainJob은 별도로 검증해 이전해야 한다
    • C) Kubeflow Trainer v2는 폐기되었고 v1 CRD로 되돌아갔다
    • D) TrainJob과 PyTorchJob은 단순히 동일한 CRD의 다른 이름일 뿐이다
정답 보기

정답: B) 26.03.1 배포판에는 레거시 Training Operator(1.9.2)가 Trainer v2와 함께 여전히 포함되어 있으며, 기존 API와 TrainJob은 별도로 검증해 이전해야 한다

설명: Kubeflow Community Distribution 26.03.1은 Trainer v2와 함께 레거시 Training Operator 1.9.2를 여전히 배포하며, 이는 두 API가 함께 제공된다는 뜻이며 특정 팀의 이전 진행률은 알 수 없습니다.

  1. 동기식 분산 학습에서 선택적 갱 스케줄링이 도움이 되는 이유는 무엇입니까?
    • A) Kubernetes는 기본적으로 네임스페이스 내 모든 Pod를 갱 스케줄링하도록 요구한다
    • B) 통신에 필요한 워커를 확보하지 못해 일부 자원만 점유하는 상황을 줄일 수 있다
    • C) 갱 스케줄링은 스테이트리스 웹 워크로드에만 필요하다
    • D) 클라우드 제공업체가 부과하는 과금 요건이다
정답 보기

정답: B) 통신에 필요한 워커를 확보하지 못해 일부 자원만 점유하는 상황을 줄일 수 있다

설명: 고정 크기 동기식 작업은 필요한 프로세스가 rendezvous에 참여해야 합니다. 그러나 Trainer 설치만으로 gang scheduling이 켜지지 않으며 기본 Torch runtime에는 podGroupPolicy가 없습니다. 별도 scheduler·CRD·정책이 필요하고, 순차 프로비저닝도 timeout 안에 준비되면 가능합니다.

단답형 문제 ​

  1. Kubernetes에서 다중 워커 분산 학습 작업을 조율할 때 헤드리스 Service는 어떤 역할을 합니까?
정답 보기

정답: 재스케줄링 시 바뀔 수 있는 Pod IP에 의존하지 않고, 각 워커 Pod에 안정적이고 조회 가능한 DNS 이름을 부여해 다른 워커들이 그것을 찾을 수 있게 합니다.

설명: 분산 학습 워커들은 서로를 안정적으로 찾아야 합니다. 워커 Pod 앞에 둔 헤드리스 Service는 Pod 이름·hostname/subdomain과 네트워크 설정이 맞을 때 DNS 기반 탐색을 제공합니다. 상태나 IP의 영구 보존은 아닙니다.

  1. 이 문서의 Katib 참고 내용에서, TrainJob은 Katib Trial 안에서 어떤 역할을 합니까?
정답 보기

정답: 호환되는 Trial 템플릿·런타임·상태 조건·메트릭 수집이 설정된 경우 Katib은 TrainJob을 생성하여, 해당 Trial에서 선택된 하이퍼파라미터 값을 스크립트 인자로 주입하고, 보고된 메트릭을 읽어 탐색 방향을 결정합니다.

설명: Katib 자체는 분산 실행 메커니즘을 알 필요가 없습니다 — 플랫폼 팀이 이미 정의해둔 런타임을 대상으로 Trial마다 TrainJob을 찍어내며, 하이퍼파라미터 탐색 로직과 학습 실행 메커니즘을 분리해 둡니다.

  1. 기존 v1 CRD 매니페스트(예: PyTorchJob)를 Kubeflow Trainer v2로 옮기는 필드 단위의 권위 있는 참고 자료는 이 문서 대신 어디에서 찾아야 합니까?
정답 보기

정답: kubeflow.org의 "Migrating to Kubeflow Trainer v2" 가이드입니다.

설명: 이 문서는 개념적 전환과 메커니즘을 개괄적으로 다루지만 모든 마이그레이션 단계를 의도적으로 다시 나열하지 않습니다. 공식 마이그레이션 문서는 PyTorchJob 예제를 제공하지만 모든 프레임워크·필드의 완전한 매핑은 아닙니다. 실제 명령, 역할, 재시도, 스토리지·네트워크를 비교해야 합니다.

학습 자료로 돌아가기