Cloud Native Operations

한국어

English

한국어

English

Appearance

Kubeflow Notebooks 퀴즈 ​

이 퀴즈는 Kubeflow Notebooks의 아키텍처, Profile 기반 멀티테넌시 모델, 스토리지 및 유휴 컬링 동작, EKS에서의 GPU 스케줄링, 커스텀 노트북 이미지에 대한 이해도를 테스트합니다.

객관식 문제 ​

  1. Kubeflow Notebooks는 사용자가 스포너에서 선택한 항목(이미지, CPU/메모리/GPU, 스토리지)을 실행 중인 노트북 서버로 전환하기 위해 어떤 Kubernetes 네이티브 메커니즘을 사용하나요?
    • A) 대시보드가 kubectl을 직접 실행하는 셸 스크립트
    • B) 컨트롤러가 StatefulSet/Pod로 조정(reconcile)하는 Notebook 커스텀 리소스
    • C) 대시보드의 데이터베이스를 1분마다 조회하는 cron job
    • D) 사용자가 직접 설치하는 Helm 차트
정답 보기

정답: B) 컨트롤러가 StatefulSet/Pod로 조정(reconcile)하는 Notebook 커스텀 리소스

설명: Central Dashboard의 스포너는 원하는 환경을 기술하는 Notebook 커스텀 리소스를 생성합니다. 컨트롤러가 이 리소스를 감시하고 일반적인 Kubernetes 오브젝트(요청된 이미지, 리소스, PVC를 가진 StatefulSet/Pod)로 조정하며, 대시보드가 Pod를 직접 생성하지는 않습니다.

  1. 26.03 Kubeflow Community Distribution 기준으로 Kubeflow Notebooks v2의 정확한 현재 상태는 무엇인가요?
    • A) 이미 GA에 도달했고 v1을 완전히 대체했다
    • B) 알파 단계조차 아직 존재하지 않는다
    • C) 새로운 Workspace/WorkspaceKind CRD를 중심으로 테스트용 알파 매니페스트가 제공되며 릴리스에 다가가고 있지만 아직 GA는 아니다
    • D) v1을 무기한 유지하기로 결정되어 취소되었다
정답 보기

정답: C) 새로운 Workspace/WorkspaceKind CRD를 중심으로 테스트용 알파 매니페스트가 제공되며 릴리스에 다가가고 있지만 아직 GA는 아니다

설명: 26.03 배포 시점 기준으로, 새로운 Workspace와 WorkspaceKind 커스텀 리소스를 중심으로 구축되는 Notebooks v2는 테스트용 알파 매니페스트를 제공하지만 아직 정식 출시(GA)에 도달하지 않았습니다. v1의 Notebook CRD가 여전히 프로덕션에서 사용되는 아키텍처이며, v2가 GA 준비가 되면 유지보수 전용 상태로 전환될 것으로 예상됩니다.

  1. Kubeflow Notebooks의 멀티테넌시 모델에서 Profile이란 무엇인가요?
    • A) 사용자가 저장한 노트북 UI 테마와 키보드 단축키
    • B) 해당 사용자의 접근을 제한하는 RBAC 바인딩과 Istio 인가 정책을 프로비저닝하는 사용자별 네임스페이스 구조
    • C) 사용자가 이전에 스폰(spawn)한 이미지 기록
    • D) 사용자의 AWS IAM identity와 연결된 결제 계정
정답 보기

정답: B) 해당 사용자의 접근을 제한하는 RBAC 바인딩과 Istio 인가 정책을 프로비저닝하는 사용자별 네임스페이스 구조

설명: Profile은 사용자(또는 팀)를 위한 전용 네임스페이스, 해당 네임스페이스로 권한을 한정하는 RBAC 바인딩, 그리고 그 안의 서비스에 접근할 수 있는 identity를 제한하는 Istio AuthorizationPolicy를 프로비저닝합니다. 노트북은 항상 Profile 네임스페이스 안에서 생성되며, 이것이 기본적으로 사용자 간 노트북을 서로 격리시키는 장치입니다.

  1. 노트북의 PersistentVolumeClaim(PVC)이 Pod 재시작에 대한 복원력에 왜 중요한가요?
    • A) Pod가 재시작될 때마다 PVC도 자동으로 삭제되고 재생성되기 때문에
    • B) Pod가 아니라 클레임이 영속적인 객체이며, 여기에 마운트된 파일과 설치된 패키지는 Pod 재시작, 노드 교체, 중지/재시작 사이클을 거쳐도 유지되기 때문에
    • C) PVC는 RStudio 이미지에서만 의미가 있고 JupyterLab에는 해당하지 않기 때문에
    • D) PVC는 사용자 파일이 아니라 로그를 저장하는 데만 사용되기 때문에
정답 보기

정답: B) Pod가 아니라 클레임이 영속적인 객체이며, 여기에 마운트된 파일과 설치된 패키지는 Pod 재시작, 노드 교체, 중지/재시작 사이클을 거쳐도 유지되기 때문에

설명: 스포너는 사용자가 보통 노트북의 홈 디렉터리에 마운트하는 PVC를 연결할 수 있게 해줍니다. PVC는 Pod의 라이프사이클과 독립적으로 유지되기 때문에, Pod 재시작, 노드 교체, 의도적인 중지/재시작 사이클을 거쳐도 사용자의 작업물이 보존됩니다. 노트북을 삭제가 아니라 중지시키는 컬링 역시 PVC를 그대로 남겨둡니다.

  1. 유휴 컬링(idle culling)이 특히 GPU가 연결된 노트북에서 중요한 이유는 무엇인가요?
    • A) 노트북 Pod는 GPU를 전혀 요청할 수 없으므로 컬링과 무관하기 때문에
    • B) 실행 중인 노트북 Pod는 실제 사용 여부와 무관하게 존재하는 동안 계속 GPU 할당을 점유하므로, 유휴 상태의 GPU 노트북이 몇 시간씩 비싼 용량을 붙잡고 있을 수 있기 때문에
    • C) 컬링이 GPU 메모리를 회수하기 위해 노트북의 PVC를 삭제하기 때문에
    • D) GPU 노드는 용량을 회수하려면 클러스터 전체 재시작이 필요하며 컬링이 이를 트리거하기 때문에
정답 보기

정답: B) 실행 중인 노트북 Pod는 실제 사용 여부와 무관하게 존재하는 동안 계속 GPU 할당을 점유하므로, 유휴 상태의 GPU 노트북이 몇 시간씩 비싼 용량을 붙잡고 있을 수 있기 때문에

설명: 노트북 Pod는 실행 중인 동안 누군가 실제로 사용하고 있는지와 무관하게 요청한 CPU, 메모리, GPU 할당을 계속 점유합니다. 컬링은 설정된 기간 동안 유휴 상태인 노트북을 (삭제 없이) 중지시키는데, GPU가 연결된 서버는 자리를 비운 뒤에도 비싼 가속기 용량을 무기한 붙잡고 있을 수 있기 때문에 특히 유용합니다.

  1. EKS에서 노트북 Pod는 GPU 접근을 어떻게 요청하며, 이것이 클러스터 오토스케일링과 어떻게 상호작용하나요?
    • A) 클러스터의 나머지 부분과 분리된 Notebooks 전용 GPU 스케줄러를 사용한다
    • B) 다른 Pod와 마찬가지로 resources.limits."nvidia.com/gpu"를 설정하며, 학습 작업이나 추론 워크로드가 사용하는 것과 동일한 GPU 지원 노드 풀(예: Karpenter가 관리하는 NodePool)을 두고 경쟁한다
    • C) 노트북의 GPU 접근은 관리자가 노드에 SSH로 접속해 수동으로 할당해야 한다
    • D) 노트북 Pod는 GPU를 요청할 수 없으며 KServe 엔드포인트만 가능하다
정답 보기

정답: B) 다른 Pod와 마찬가지로 resources.limits."nvidia.com/gpu"를 설정하며, 학습 작업이나 추론 워크로드가 사용하는 것과 동일한 GPU 지원 노드 풀(예: Karpenter가 관리하는 NodePool)을 두고 경쟁한다

설명: 스포너에서 선택한 GPU 옵션은 Pod 스펙의 표준적인 nvidia.com/gpu 리소스 요청으로 변환되며, NVIDIA 디바이스 플러그인이 이를 할당 가능한 리소스로 알립니다. 이는 별도의 GPU 서브시스템이 아니며, 노트북 Pod는 다른 GPU 워크로드와 동일한 GPU 노드 풀을 두고 경쟁합니다. EKS에서는 이러한 용량이 흔히 Karpenter를 통해 동적으로 프로비저닝됩니다.

  1. 팀들이 기본 제공되는 스포너 이미지를 그대로 쓰는 대신 커스텀 노트북 이미지를 빌드하는 일반적인 이유는 무엇인가요?
    • A) Kubeflow에서는 커스텀 이미지가 필수이며 스톡 이미지는 전혀 사용할 수 없기 때문에
    • B) 모든 데이터 과학자가 실행 중인 컨테이너 안에서 손으로 패키지를 설치하는 대신, 팀 고유의 의존성이 미리 설치된 동일하고 재현 가능한 환경에서 시작할 수 있도록 하기 위해
    • C) 스톡 이미지는 PVC 마운트를 지원하지 않기 때문에
    • D) 커스텀 이미지를 쓰면 Profile 네임스페이스가 필요 없어지기 때문에
정답 보기

정답: B) 모든 데이터 과학자가 실행 중인 컨테이너 안에서 손으로 패키지를 설치하는 대신, 팀 고유의 의존성이 미리 설치된 동일하고 재현 가능한 환경에서 시작할 수 있도록 하기 위해

설명: 프로덕션에서 노트북을 운영하는 대부분의 팀은 업스트림 Kubeflow/Jupyter 베이스 이미지 위에 고정된 Python/R 패키지, 내부 라이브러리, 맞춰진 GPU 프레임워크 버전을 레이어로 추가한 커스텀 이미지를 빌드하고, 이를 레지스트리(EKS에서는 보통 Amazon ECR)에 푸시한 뒤 스포너에서 직접 참조합니다. 이렇게 하면 동일한 이미지 태그를 사용하는 두 사용자가 수작업 설치로 인해 서로 달라지는 대신 완전히 동일한 패키지 집합을 갖게 됩니다.

단답형 문제 ​

  1. 노트북 Pod의 GPU 요청이 EKS의 Karpenter와 어떻게 상호작용하는지, 그리고 이것이 비용 측면에서 왜 중요한지 한두 문장으로 설명하세요.
정답 보기

정답: 노트북 Pod 스펙이 nvidia.com/gpu 리소스를 요청하고 기존 노드에 여유 용량이 없으면, Karpenter가 대기 중인 Pod를 충족시키기 위해 새로운 GPU 기반 EC2 인스턴스를 프로비저닝합니다. GPU 인스턴스는 비용이 크기 때문에, 유휴 노트북 컬링과 GPU 요청량을 적절히 조정하는 것이 활성 세션 사이에 팀이 얼마나 많은 미사용 GPU 용량에 비용을 지불하는지를 직접적으로 좌우합니다.

  1. 네임스페이스별 Istio 격리는 일반적인 Kubernetes 네임스페이스 RBAC만으로는 얻을 수 없는 무엇을 Kubeflow Profile에 추가로 제공하나요?
정답 보기

정답: RBAC은 네임스페이스 안에서 누가 Kubernetes API 오브젝트를 생성/조회/수정할 수 있는지를 제어하지만, 네트워크 트래픽에 대해서는 아무것도 규정하지 않습니다. Istio의 네임스페이스별 AuthorizationPolicy는 여기에 더해 어떤 서비스가 실제로 네트워크 계층에서 사용자의 노트북 Pod로 요청을 보낼 수 있는지를 제한하므로, RBAC만으로는 일부 네임스페이스 간 오브젝트 접근이 허용되더라도 사용자 노트북 서버 간의 격리를 보장합니다.

학습 자료로 돌아가기