쿠버네티스에서 AI, 엣지(Edge), 통신(Telecommunications) 워크로드의 인기가 높아짐에 따라 하드웨어 관리에 대한 새로운 요구 사항이 생겨났습니다. 이제 우리는 단순한 CPU 시간과 메모리 할당을 넘어선 하드웨어 사양이 필요합니다. 여기에는 GPU, TPU, 네트워크 인터페이스 및 기타 하드웨어 할당이 포함되며, 때로는 포드(Pod) 시작 후나 시분할(time-sharing) 방식을 통한 할당도 필요합니다.

이러한 특수 하드웨어를 효율적으로 관리하는 것이 **디바이스 관리 작업 그룹(Device Management Working Group)**의 임무입니다. 이들의 핵심 프로젝트인 **동적 리소스 할당(Dynamic Resource Allocation, DRA)**은 최근 정식 출시(GA) 단계로 졸업하며, 프로젝트가 하드웨어 집약적인 워크로드를 대규모로 처리하는 방식에 근본적인 변화를 가져왔습니다.

이번 스포트라이트에서는 작업 그룹 의장인 Kevin Klues, Patrick Ohly, **John Belamaric**과 함께 기존 디바이스 모델의 한계, 스케줄링의 NP-난해(NP-hard) 과제, 그리고 더욱 프로그래밍 가능하고 하드웨어를 인식하는 쿠버네티스의 미래를 어떻게 구축하고 있는지 이야기를 나누어 보았습니다.

디바이스 관리 소개

Natalie Fisher: 자기소개와 역할, 그리고 디바이스 관리 작업 그룹에 어떻게 참여하게 되셨는지 말씀해 주시겠습니까?

Kevin Klues: 제 이름은 Kevin Klues입니다. NVIDIA의 Distinguished Engineer이며, 2024년 KubeCon EU에서 디바이스 관리 작업 그룹이 결성된 이래 공동 의장을 맡고 있습니다. 또한 작업 그룹의 주요 결과물인 DRA의 초기 단계(2019/2020년)부터 참여해 왔습니다. 2019년부터 kubelet 메인테이너로 활동하며 디바이스 관리자, CPU 관리자, 토폴로지 관리자 하위 컴포넌트에 집중해 왔습니다. 외부 가속기(예: GPU)에 의존하는 워크로드에서 이러한 컴포넌트를 사용하며 겪은 한계가 DRA 개발을 시작하게 된 계기가 되었습니다.

Patrick Ohly: 저는 Intel의 Principal Engineer입니다. 쿠버네티스에서는 SIG Testing과 SIG Instrumentation의 테크 리드이며, 디바이스 관리 WG의 공동 의장입니다. 이전에는 WG Structured Logging의 공동 의장이자 운영 위원회 멤버로 활동했습니다. 초기에 임시 CSI 볼륨(ephemeral CSI volumes)과 스토리지 용량 추적 기능을 기여하며 API 설계, 구현 및 스케줄링 경험을 쌓았습니다. 가속기를 위한 대규모 신규 API를 도입하는 것이 어려울 것이라는 점은 알고 있었습니다. 조금 무모하게도 2020년에 그 도전을 받아들여 초기 DRA KEP(현재 "클래식 DRA"로 알려짐)를 작성하고 대부분을 구현했습니다. 이후 현재의 "구조화된 매개변수(structured parameters) DRA"를 위해 두 번째 KEP를 작성하며 다시 시작했습니다. 처음에는 이 작업이 필요하다는 점을 메인테이너들에게 설득하는 것이 쉽지 않았습니다. 2023년경이 되어서야 DRA에 대한 관심이 높아졌고, 그 결과 작업 그룹이 형성되었습니다.

John Belamaric: 저는 Google의 Senior Staff SWE이며, 디바이스 관리 WG가 결성된 이래 세 번째 공동 의장을 맡고 있습니다. 2019년부터 SIG Architecture의 공동 의장도 맡고 있습니다. Patrick이 언급했듯이, 2023년 말에 DRA에 대한 관심이 급증했습니다. 초기 구현은 오토스케일링을 매우 어렵게 만들었기 때문에 이를 베타로 발전시키는 것에 대해 커뮤니티 내부의 우려가 있었습니다. 저는 이러한 우려를 해결하는 것을 돕기 위해 참여하게 되었고, 우리 셋은 Tim Hockin과 함께 몇 달 동안 새로운 디자인에 대한 합의를 이끌어내기 위해 노력했습니다. 이러한 협업을 촉진하기 위해 2024년 파리 KubeCon에서의 논의를 거쳐 작업 그룹을 구성했습니다.

문제와 해결책

작업 그룹은 쿠버네티스가 특수 하드웨어와 상호작용하는 방식에 대한 근본적인 재고를 통해 탄생했습니다. 이 진화의 핵심은 **동적 리소스 할당(DRA)**입니다. 디바이스를 단순히 정수(integer)로 취급하는 대신, DRA는 디바이스 관리를 네 가지 고유한 단계로 나누는 구조화된 프레임워크를 제공합니다.

• 모델링(Modeling): 벤더는 ResourceSlice API를 사용하여 하드웨어의 세부적인 기능과 용량을 광고합니다.
• 요청(Requesting): 사용자는 ResourceClaim API를 통해 GPU 메모리나 상호 연결(interconnect) 요구 사항과 같은 구체적인 하드웨어 요구 사항을 정의합니다.
• 스케줄링(Scheduling): 쿠버네티스 스케줄러는 이러한 API를 사용하여 워크로드 요구 사항을 가용 하드웨어와 지능적으로 매칭합니다.
• 작동(Actuation): 매칭이 완료되면 시스템은 포드가 사용할 디바이스를 준비하고 보안을 확보하는 "핸드셰이크(handshake)"를 처리합니다.

NF: 잘 모르시는 독자들을 위해, 디바이스 관리 작업 그룹은 무엇이며 어떤 문제를 해결하려고 하나요?

KK: 디바이스 관리 작업 그룹은 쿠버네티스 워크로드 전반에서 가속기 및 기타 특수 하드웨어의 간단하고 효율적인 구성, 공유 및 할당을 가능하게 하기 위해 결성되었습니다. 전통적인 쿠버네티스 리소스 모델에 깔끔하게 들어맞지 않는 GPU, TPU, FPGA 같은 디바이스들을 생각하시면 됩니다.

우리가 해결하고자 한 문제는 쿠버네티스에서 하드웨어 가속기를 노출하는 주요 메커니즘이었던 기존의 디바이스 플러그인(Device Plugin) API가 근본적으로 제한적이라는 점이었습니다. 이 API는 디바이스를 불투명한 정수로 취급합니다. 즉, "GPU 2개"를 요청할 수는 있지만, 어떤 GPU가 필요한지, 그것들이 서로 어떻게 연결되어야 하는지, 공유가 가능한지, 또는 어떻게 분할되어야 하는지에 대해서는 유의미한 내용을 전달할 수 없습니다. 단순한 사례에는 괜찮았지만, 현대의 AI/ML 워크로드는 결코 단순하지 않습니다. 이러한 워크로드는 여러 노드에 걸쳐 있고, 특정 상호 연결 토폴로지를 요구하며, 하드웨어를 동적으로 공유하거나 분할해야 하는 경우가 점점 늘어나고 있습니다.

작업 그룹의 주요 결과물은 경직된 디바이스 플러그인 모델을 유연하고 선언적인 API로 대체하는 새로운 프레임워크인 동적 리소스 할당(DRA)입니다. DRA를 사용하면 워크로드는 하드웨어 요구 사항(예: GPU 유형, 메모리 용량, 상호 연결 토폴로지, 원하는 파티셔닝)을 기술할 수 있고, 드라이버는 스케줄러가 작업할 수 있는 세밀한 디바이스 속성을 게시할 수 있습니다. DRA는 쿠버네티스 1.34에서 정식 출시(GA)되었으며, 이를 둘러싼 생태계(드라이버, 도구, 새로운 API 확장 등)가 빠르게 성장하고 있습니다.

PO: Kevin이 말했듯이, 작업 그룹은 기존의 DRA 개발 노력을 중심으로 형성되었습니다. 초기 작업은 소수의 인원만이 적극적으로 참여하여 수행되었는데, 어쩌면 그런 구성이었기에 성공할 수 있었을지도 모릅니다. 하지만 이 작업은 쿠버네티스의 매우 다양한 영역에 걸쳐 있기 때문에, 쿠버네티스 메인테이너, 디바이스 벤더, 그리고 어느 정도는 최종 사용자까지 포함하는 더 넓은 커뮤니티와 논의할 장소가 필요했습니다. 작업 그룹은 온라인 정기 회의(미주/EMEA 시간대와 EMEA/아시아 시간대 각 1개씩)와 KubeCon 행사를 통해 그 장소를 제공합니다.

JB: DRA는 WG가 해결한 첫 번째 문제입니다. 디바이스의 선택, 할당 및 구성에 중점을 두었습니다. 우리는 문제를 네 가지 부분으로 나누었습니다. 벤더가 디바이스를 모델링하고 용량을 광고하는 방법, 사용자가 이를 요청하는 방법, 광고된 용량을 기반으로 요청을 스케줄링하는 방법, 그리고 그 결과를 작동시키는 방법(즉, 디바이스를 포드에서 사용할 수 있도록 준비하는 방법)입니다.

우리가 취한 접근 방식에서 근본적인 한 가지는 하드웨어의 엄청난 다양성과 하드웨어 산업의 빠른 변화 속도를 인식하는 것이었습니다. 하드웨어 유형이 바뀔 때마다 쿠버네티스 API를 변경해야 한다면 그 속도를 따라갈 수 없다는 것을 알았습니다. 대신, 쿠버네티스에 중요한 하드웨어 측면을 다루는 일반적인 접근 방식을 만들었습니다. 지금까지 우리가 한 일은 디바이스의 스케줄링과 구성 측면에 집중한 것입니다. 벤더가 디바이스의 스케줄링 특성을 모델링하는 데 사용하는 디바이스 모델링 API(ResourceSlice API)를 구축했고, 사용자가 임의의 구성을 해당 디바이스에 전달할 수 있도록 했습니다. 이를 통해 쿠버네티스를 수정하지 않고도 디바이스의 이러한 측면을 이해하도록 "프로그래밍"할 수 있습니다.

하지만 현재의 DRA는 스케줄링에 매우 집중되어 있습니다. WG의 범위 내에는 다른 디바이스 관리 측면도 있습니다. 특히 디바이스 장애 감지 및 완화, 그리고 쿠버네티스에 내장하여 도움을 줄 수 있는 더 나은 지원 기능이 있는지 살펴보고 있습니다.

또한 Kevin이 언급했듯이, 디바이스는 개별적으로보다는 그룹으로 할당되어 사용되는 경우가 많습니다. 그룹 내에서 함께 작동할 적절한 디바이스를 선택하는 것은 디바이스들이 어떻게 상호 연결되어 있는지에 달려 있습니다. 예를 들어, NVIDIA GPU는 NVLINK 도메인 내에서 any-to-any 패브릭 구조일 수 있고, TPU는 3D 토러스(torus) 상호 연결 구조를 가질 수 있습니다. 이는 디바이스의 "선택, 할당 및 구성"에 영향을 미치며, 이러한 사용 사례를 해결하기 위해 아직 해야 할 일이 많습니다.

SIG 간의 협력 노력

디바이스 관리는 스케줄링, 노드 운영, 오토스케일링, 네트워킹 및 API 설계에 걸쳐 있기 때문에, 이 작업은 자연스럽게 쿠버네티스 프로젝트의 여러 SIG(Special Interest Groups)에 걸쳐 진행됩니다.

NF: 이러한 SIG 간의 협업은 실제로 어떻게 이루어지며, 왜 필요한가요?

KK: 디바이스 관리는 쿠버네티스 스택의 거의 모든 계층에 영향을 미치기 때문에, 작업 그룹은 처음부터 교차 SIG 노력으로 헌장이 만들어졌습니다. 우리는 sig-node, sig-scheduling, sig-autoscaling, sig-network, sig-architecture라는 5개의 이해관계자 SIG를 두고 있습니다.

실제로 작업 그룹은 조율 레이어 역할을 합니다. 우리는 직접 코드를 소유하지 않습니다. 대신, 우리의 결과물은 각 SIG에 상주하는 KEP(Kubernetes Enhancement Proposals)와 구현체의 형태를 취합니다. 우리가 제공하는 것은 스케줄러, kubelet, 오토스케일러 및 네트워크 플레인을 구축하는 사람들이 고립되지 않고 함께 설계할 수 있는 통합된 포럼입니다.

이것이 왜 필요할까요? 간단한 예를 들어보겠습니다. 사용자가 NVLink를 통해 통신해야 하는 GPU 세트를 요청합니다. 이 요구 사항에는 스케줄러(포드를 적절한 노드에 배치), kubelet(디바이스를 구성하고 컨테이너에 노출), 그리고 잠재적으로 오토스케일링(적절한 노드 유형이 없는 경우 프로비저닝)이 관여합니다.

이 세 그룹이 독립적으로 설계한다면 일관성 없는 추상화, 중복된 로직, 그리고 운영 환경에서만 드러나는 통합 버그가 발생하게 됩니다. 작업 그룹은 이러한 모든 컴포넌트를 관통하는 하나의 일관된 API와 데이터 모델을 보장합니다.

교차 SIG 모델은 또한 설계 결정이 여러 각도에서 검토됨을 의미합니다. sig-scheduling 담당자는 sig-node 기여자가 간과할 수 있는 스케줄러 복잡성을 포착할 것이고, 그 반대의 경우도 마찬가지입니다. 이는 개별 결정을 약간 늦출 수 있지만, 훨씬 더 견고한 결과를 만들어냅니다.

현재 집중 분야

DRA가 정식 출시됨에 따라, 작업 그룹의 초점은 더 고급 스케줄링 모델, 공유 시맨틱, 운영 가시성, 그리고 점점 복잡해지는 하드웨어 토폴로지 지원으로 확장되었습니다.

NF: 작업 그룹이 현재 집중하고 있는 주요 이니셔티브나 결과물은 무엇인가요?

KK: 우리는 Kubernetes Project Board에서 이니셔티브와 진행 상황을 실시간으로 추적하고 있습니다.

PO: 핵심 DRA의 범위와 기능 세트는 합리적인 시간 내에 GA로 졸업할 수 있도록 의도적으로 제한되었습니다. 추가 KEP들은 각자의 일정에 따라 더 많은 기능을 추가합니다. 이는 크게 세 가지 범주로 나뉩니다.

1. 더 복잡한 디바이스와 스케줄링 시나리오를 지원하기 위해 DRA의 표현력을 확장합니다.
2. 상태 모니터링과 같은 Day 2 운영을 지원합니다.
3. 주로 워크로드 인식 스케줄링과 통합하여 멀티 노드 지원을 개선합니다.

프로젝트 보드 외에도 현재 진행 중인 모든 KEP를 요약한 표를 유지하고 있습니다. 다음은 1.36 기준 상태이며, 1.37에서 더 추가될 예정입니다.

NF: 핵심 과제 중 하나는 효율적인 디바이스 활용과 공유입니다. 이 분야에서 어떤 진전이 있나요?

JB: 좋은 질문입니다. 우리가 두 가지 주요 API인 ResourceClaim과 ResourceSlice에서 무엇을 하고 있는지 생각해보면 이해하기 쉽습니다.

ResourceClaim API는 사용자가 디바이스를 요청하는 방식입니다. 우리는 사용자가 요청 시 더 유연해질 수 있도록 몇 가지 기능을 구축했습니다. 예를 들어, 특정 모델의 GPU를 요청하는 대신 "최소 특정 용량 이상의 메모리를 가진 GPU"를 요청할 수 있습니다. 또는 대안 목록을 요청할 수도 있습니다. "A100(80GB) GPU 1개를 원하지만, 없다면 A100(40GB) GPU 2개도 괜찮습니다." 이는 스케줄러에게 요청을 충족시킬 수 있는 더 많은 옵션을 제공하며, 이는 하드웨어 획득 가능성을 높이고 활용되지 못할 수도 있는 하드웨어의 활용도를 높이는 결과로 이어집니다.

또한 ResourceClaim API를 통해 사용자는 명시적으로 디바이스를 공유할 수 있습니다. (동일하거나 다른 포드의) 여러 컨테이너가 하나의 ResourceClaim을 가리키도록 할 수 있습니다. 이를 통해 해당 claim에 의해 할당된 디바이스를 디바이스가 지원하는 경우 모든 컨테이너에서 사용할 수 있습니다.

ResourceSlice API는 벤더가 자신의 디바이스를 모델링하고 광고하는 방식입니다. 여기서 다른 공유 모델에 대한 지원을 구현합니다. 예를 들어, "중첩된 파티션(overlapping partitions)"을 표현하는 방법이 있습니다. 이를 통해 스케줄러는 MIG 파티션을 동적으로 선택하고, 중첩되는 다른 MIG 파티션들은 자동으로 사용 불가능하게 만들 수 있습니다. 이는 "20GB 이상의 메모리를 가진 GPU 아무거나"와 같은 요청과 결합하여 잘 작동합니다. 스케줄러는 이를 MIG나 실제 GPU로 충족시킬 수 있습니다.

일부 기능은 두 API 모두에 변경이 필요합니다. "소모 가능한 용량(consumable capacity)"이라고 부르는 또 다른 공유 방식이 있습니다. 위에서 설명한 명시적 공유의 경우, 사용자가 컨테이너들이 동일한 ResourceClaim을 가리키도록 설정해야 합니다. 즉, 하나의 ResourceClaim이 여러 컨테이너와 포드 사이에서 공유됩니다. 반면 소모 가능한 용량 방식에서 디바이스 공유는 포드가 노드를 공유하는 방식과 더 유사하게 작동합니다. 사용자는 일정량의 리소스를 요구하는 ResourceClaim을 생성합니다. 예를 들어 "2Gbps 대역폭을 가진 NIC가 필요합니다"라고 요청합니다. 스케줄러는 40Gbps 대역폭의 가용 NIC가 있음을 알고, 그 40Gbps 중에서 2Gbps를 할당하여 해당 ResourceClaim에 제공합니다. 이 경우 각 포드는 자신만의 ResourceClaim을 갖지만, 기저의 디바이스는 여러 claim 간에 공유됩니다. 이러한 종류의 공유를 위해 디바이스를 적절히 설정하는 것은 노드 상의 DRA 드라이버의 몫입니다(NIC의 경우 서브인터페이스를 생성하는 방식일 것입니다). 우리는 이를 명시적인 "사용자 매개 공유(user-mediated sharing)"와 구별하기 위해 "플랫폼 매개 공유(platform-mediated sharing)"라고 부릅니다.

실세계의 영향

많은 작업이 고도의 기술적인 내용을 담고 있지만, 근본적인 목표는 실용적입니다. 바로 쿠버네티스가 실세계의 AI/ML 및 하드웨어 집약적인 워크로드를 대규모로 더 잘 지원하도록 하는 것입니다.

NF: 오늘날 쿠버네티스에서 AI/ML과 같은 하드웨어 집약적 워크로드를 실행할 때 사용자가 겪는 가장 큰 어려움은 무엇인가요?

PO: 이러한 워크로드는 여러 면에서 전통적인 컨테이너 워크로드와 다릅니다. 동시에 실행되어야 하는 여러 통신 포드들로 구성될 수 있습니다("갱 스케줄링, gang scheduling"). 종종 실행 시간이 길고 초기화 비용이 많이 들며, 성능이 실행 위치(노드 내 토폴로지 및 여러 포드 간의 노드 간 상호 연결)에 민감합니다. 쿠버네티스 스케줄러는 전통적으로 포드를 하나씩 스케줄링하고 노드 내의 토폴로지를 인식하지 못했기 때문에 이러한 워크로드를 잘 지원하지 못했습니다. 여러 외부 스케줄러가 이 간극을 메우려 노력하고 있지만, 특히 쿠버네티스 스케줄러가 동일한 클러스터에 다른 포드들을 스케줄링할 때 이상적이지 않은 경우가 많습니다.

NF: 플랫폼 엔지니어들은 쿠버네티스 플랫폼을 설계할 때 디바이스 관리에 대해 어떻게 생각해야 할까요?

JB: 우리는 아직 배워가는 단계이지만, DRA의 아이디어 중 하나는 더 "요구 사항 중심(requirements driven)"인 사양으로 전환하는 것을 가능하게 하는 것입니다. 이를 통해 워크로드 사양을 작성하는 최종 사용자와 클러스터를 구축하는 클러스터 관리자 간의 결합도를 낮출 수 있습니다. 라벨링 규칙에 합의하고 사용자가 클러스터 토폴로지를 이해하도록 요구하는 대신, 사용자는 워크로드에 필요한 것을 지정하고 스케줄러가 이를 충족하는 방법을 찾게 할 수 있습니다. 이것이 제대로 작동한다면 복잡한 워크로드라도 여러 클러스터 간의 이식성을 높일 수 있습니다.

과제와 트레이드오프

쿠버네티스의 많은 영역과 마찬가지로, 유연성과 표현력을 높이는 것은 특히 스케줄링과 최적화 측면에서 새로운 복잡성을 야기합니다.

NF: 작업 그룹이 오늘날 직면한 가장 어려운 기술적 과제는 무엇인가요?

PO: 유연성과 스케줄링 복잡성 사이에는 본질적인 충돌이 있습니다. 현재 구현은 요청된 리소스를 만족하는 해결책을 찾는 데 집중하고 있지만, 그것이 반드시 최적의 해결책은 아닐 수도 있습니다. "최적"이 무엇을 의미하는지도 항상 명확하지 않습니다. 또 다른 큰 과제는 노드 할당 가능 리소스(RAM, CPU)를 추가 메타데이터가 있는 디바이스로 노출하는 것입니다. 이는 최적의 성능을 위해 노드 상에서 완벽한 정렬이 필요한 워크로드의 스케줄링을 미세 조정하기 위해 필요합니다.

JB: Patrick의 목록이 아주 좋습니다. 복잡한 디바이스 모델링은 어렵고, 우리가 구축하는 시맨틱이 다양한 하드웨어에 적용될 수 있도록 올바르게 만드는 것은 항상 까다로운 일입니다.

그뿐만 아니라 스케줄링은 일반적으로 매우 복잡하며 NP-난해 문제입니다. DRA가 추가하는 모든 메타데이터와 유연성은 스케줄러에게 더 많은 옵션을 제공하는데, 이는 장단점이 있습니다. 선택의 폭이 좁은 상황에서는 더 많은 옵션이 도움이 되어, 그렇지 않았으면 스케줄링하지 못했을 것을 가능하게 합니다. 하지만 클러스터 내에 가능성이 많을 때 최적의 해결책을 찾는 것이 훨씬 더 어려워진다는 의미이기도 합니다. DRA는 현재까지의 일반적인 사용 사례에서는 잘 작동하고 있지만, 선택된 스케줄링 솔루션의 최적성을 개선하고 그러한 선택을 하는 과정의 성능을 보장하기 위해 더 많은 노력이 필요합니다.

향후 전망

어려움에도 불구하고, 작업 그룹의 기여러들은 혁신의 속도와 디바이스 관리를 중심으로 형성되고 있는 커뮤니티의 성장에 고무되어 있습니다.

NF: 앞으로 쿠버네티스 디바이스 관리의 미래에서 가장 기대되는 점은 무엇인가요?

KK: NVIDIA는 최근 GPU용 DRA 드라이버를 쿠버네티스 프로젝트에 기증했습니다. 더 많은 커뮤니티 멤버들이 프로젝트에 기여하고 미래의 방향을 정의하기 시작하는 것이 개인적으로 가장 기대됩니다.

PO: 저에게는 무엇보다 새로운 기여자와 도움을 주려는 사람들의 수입니다. 이는 제안서를 검토하고 개발자들이 이를 구현하고 병합하도록 돕는 면에서 새로운 과제를 던져주기도 합니다. 다른 사람들이 성공하는 것을 보는 것은 보람찬 일이며, 더 많은 사람들이 이 주제에 익숙해지고 있다는 점에서 미래가 밝다고 생각합니다.

JB: 기대되는 점이 정말 많습니다. 커뮤니티는 정말로 성장했고, 더 복잡한 디바이스를 모델링하고 멀티 노드 디바이스를 더 잘 모델링하기 위한 흥미로운 기능들이 많이 준비되고 있습니다.

저는 사람들이 이 API들을 사용할 창의적인 방식들이 정말 기대됩니다. 원래는 "디바이스"를 다루기 위해 설계되었지만, 유닉스/리눅스에서 "모든 것이 파일"인 것처럼 이 API들 자체도 무엇을 모델링할지에 대해 매우 유연합니다. 이들은 실제로 더 프로그래밍 가능한 스케줄러를 구축하며, 이는 흥미로운 애플리케이션으로 이어질 수 있습니다. 예를 들어, 최근 저는 대규모 AI 모델이 이미 로컬에 캐싱된 노드에 포드를 스케줄링하기 위해 DRA를 사용하는 프로토타입을 만들었습니다. 정말 유연하며 커뮤니티의 창의성을 믿기 때문에, 생태계에서 예상치 못한 해결책들이 나올 것이라고 생각합니다.

참여 방법

NF: 기여자들이 디바이스 관리 작업 그룹에 어떻게 참여할 수 있을까요?

KK: 가장 쉬운 첫 단계는 [email protected] 메일링 리스트에 가입하는 것입니다. 구독하면 격주 회의 일정이 자동으로 캘린더에 추가됩니다.

다양한 시간대를 고려하여 두 가지 회의 시간대를 운영하고 있습니다.

• 유럽/미주: 화요일 오전 8:30 PT (격주)
• 아시아/유럽: 수요일 오전 9:00 CET (격주)

회의록, 의제 및 녹화본은 모두 공개적으로 접근 가능합니다(디바이스 관리 페이지에서 링크 확인 가능). 첫 회의에 참석하기 전에 진행 중인 작업의 분위기를 파악할 수 있습니다.

Slack에서는 쿠버네티스 Slack 워크스페이스의 #wg-device-management 채널에서 저희를 찾을 수 있습니다. 간단한 질문을 하거나 자기소개를 하기에 가장 좋은 장소입니다.

더 직접적인 기여를 원하신다면, 이제 커뮤니티 프로젝트가 된 NVIDIA GPU용 DRA 드라이버가 좋은 시작점이 될 것입니다. 이는 더 넓은 커뮤니티가 함께 만들어가고 있는 실제 운영 등급의 구현체입니다.

API 설계, 스케줄러 내부, 드라이버 개발, 또는 문서화 등 모든 수준의 기여자를 환영합니다. 오셔서 인사해 주세요.

요약

쿠버네티스가 AI/ML 혁명과 고성능 컴퓨팅을 지원하기 위해 진화함에 따라, WG 디바이스 관리 내에서 이루어지는 작업은 현대적인 워크로드가 대규모로 스케줄링되고 운영되는 방식의 토대가 되고 있습니다.

동적 리소스 할당(DRA)의 정식 출시부터 상태 모니터링 및 토폴로지 인식 스케줄링의 다음 단계에 이르기까지, 이 그룹은 소프트웨어와 하드웨어 사이의 "핸드셰이크"를 효과적으로 다시 쓰고 있습니다.

하드웨어 인식 오케스트레이션의 미래를 설계하는 데 관심이 있다면 지금이 참여하기에 가장 좋은 시기입니다. API를 개선하든, 드라이버를 구축하든, 문서를 보완하든, 작업 그룹은 커뮤니티 전반의 모든 경험 수준과 관점을 환영합니다.