요약
엔비디아가 베어메탈 GPU 서버 위에 고객별 쿠버네티스 클러스터를 만들어 주는 관리 도구 NVKE를 공개했습니다.
엔비디아가 GitHub에 Apache 2.0 라이선스로 올린 프로젝트입니다. 플랫폼 팀이 설치해 고객용 클러스터를 만들고 운영하는 관리 플레인(클러스터를 만들고 관리하는 상위 계층)이며, 아직 프리뷰 단계라 운영 환경에는 권하지 않는다고 밝혔습니다.
왜 중요한가
- GPU 서버를 여러 고객에게 나눠 빌려주는 사업자가 고객마다 독립된 클러스터를 자동으로 만들 수 있게 하려는 도구입니다.
- 지금 지원하는 인프라 공급자가 엔비디아의 NICo 하나뿐이라, 서버부터 클러스터 운영까지 엔비디아 제품으로 이어집니다.
핵심 내용
- 쿠버네티스 배포판이 아니라 클러스터를 찍어 내는 공장이라고 스스로 설명합니다.
- 임시 시드 클러스터가 관리 클러스터를 세우고, 관리 클러스터가 고객용 클러스터를 필요할 때마다 만듭니다.
- 고객용 클러스터마다 컨트롤 플레인과 etcd(클러스터 상태 저장소), 노드 풀을 따로 둡니다.
- 노드는 TPM(보안 칩)으로 신원을 증명한 뒤에야 클러스터에 들어갈 자격을 받습니다.
- 프리뷰라서 API 인증이 기본으로 꺼져 있고, 관리 클러스터의 업그레이드와 백업 절차도 아직 없습니다.
HN 반응
- 일반 쿠버네티스나 k3s로도 GPU를 쓸 수 있는데 왜 필요한지 모르겠다는 반응이 많았고, 엔비디아 클라우드 파트너 인증을 노리는 사업자용이라는 설명이 나왔습니다.
- Cluster API나 Kamaji처럼 따로 있어야 할 기능을 한데 섞어 무겁고 한 업체에 묶인다는 비판이 나왔고, 오픈소스로 공개한 것 자체를 반기는 목소리도 있었습니다.
NVIDIA의 DSX 레퍼런스 스택을 쓰는, 테넌트별로 격리된 k8s 클러스터를 위한 것입니다. NICo / BlueField로 격리된 네트워크를 구성하고, 테넌트가 바뀔 때마다 각 호스트를 초기화한 뒤 다시 증명(re-attest)합니다. NVIDIA Cloud Partner 지위를 노리거나 스택 전체에 걸쳐 NVIDIA의 지원이 필요할 때 주로 쓸모가 있습니다.
클라우드 파트너 지위나 지원에는 관심이 없는데, 격리된 워크로드를 돌리라고 나눠줘야 할 엔비디아 하드웨어가 많이 있다면요? 그냥 k8s를 바로 배포하는 게 맞는 길 같은데요?
저도 이 도구는 잘 모르지만 k8s 관리자입니다. 워크로드를 얼마나 격리해야 하느냐에 달린 문제라고 생각합니다. 클러스터 수준의 격리를 원한다면 잘 맞을 것 같습니다. 다만 Cluster API(CAPI)를 구현한 다른 프로젝트도 있고, 그쪽에서도 테넌트 클러스터를 선언적으로 관리하는 식의 비슷한 기능을 제공합니다.
이 스택을 오픈소스로 공개한 건 정말 반가운 일이에요.
HN에서 부정적인 말을 쏟아내는 사람들은 보통 AWS나 GCP의 관리형 서비스로 단일 리전에 쿠버네티스 클러스터 3개쯤 굴리는 분들이죠.
저도 러스트로 API 서버 호환 엔진을 만들어 보려고 했을 때 욕을 엄청 먹었어요 [1]
[1] https://github.com/debarshibasak/superkube
OpenStack이나 EMC Rex-ray 같은, 오래전에 잊고 있던 것들이 한꺼번에 떠올랐어요. https://www.openstack.org https://github.com/rexray/rexray
브로드컴이 vmware 고객 대부분을 화나게 한 뒤로 OpenStack이 여기저기서 많이 보이더라고요.
방금 Kolla Ansible 인스톨러로 OpenStack을 배포했습니다. 스토리지는 Ceph와 묶어서 쓰는데 아주 잘 돌아갑니다. 브로드컴 덕분에 우리가 올바른 방향으로 가고 있네요. 대안으로 Proxmox를 생각해 뒀지만, OpenStack이 탄탄해 보입니다.
너무 무겁고 조합하기도 어려운 데다, 여러 면에서 한 벤더에 종속시키는 것으로 보입니다. 저는 기존 인프라를 유닉스 방식으로 보강해 주는 도구를 보고 싶습니다.
CAPI, Kamaji, gpu-operator처럼 원래는 따로 다뤄야 할 여러 관심사를 한데 섞어 놓은 것 같습니다.
여기서 제가 가져가고 싶은 건 관리 클러스터용 kind 기반 부트스트래퍼와 SPIFFE/TPM 연동뿐입니다.
맞아요, CAPI와 Kamaji에 관심이 좀 더 쏠렸으면 좋겠어요.
솔직히 글을 읽어서는, 검증된 하이퍼스케일러 관리형 k8s 바깥의 환경이 고민이라면 왜 그냥 rke2/k3s를 쓰지 않는지 모르겠어요.
AI가 PR을 써 주면 이런 꼴이 됩니다. FAQ 말이에요. 데이터를 그냥 쏟아붓지 말고, 제품이 뭘 하는지를 설명해야 합니다.
저도 보통은 그 말에 동의하는데, 첫 문단에서 이게 뭔지는 말하고 있어요.
“NVIDIA Kubernetes® Engine(NVKE)은 플랫폼 팀이 설치해서 고객용 쿠버네티스 클러스터를 만들고 운영하는 데 쓰는 관리 플레인을 제공합니다.”
그러니까 k8s나 k3s를 설치할 플랫폼 팀이 이미 있다면, 왜 NVKE가 필요한 거죠? 그리고 제 쿠버네티스를 고객에게 재판매하려면 어떻게 하나요? 스트라이프 연동 같은 것도 있나요?
이 설명을 읽는 것보다 제품 이름만 보고 짐작하는 편이 오히려 덜 헷갈리겠어요.
그 문장이 무슨 뜻인지 이해하려면 좀 더 읽어야 합니다...
NVKE는 쿠버네티스 배포판도 아니고 Cluster API 플레이버도 아닙니다. 쿠버네티스 클러스터를 위한 셀프 호스팅 팩토리입니다. 일회용 시드 클러스터가 관리 클러스터를 세우고, 그 위의 관리 플레인이 격리된 워크로드 클러스터를 필요할 때마다 프로비저닝하고 수명 주기를 관리합니다.
그 문장은 아무 말도 안 하는 거나 마찬가지예요. 제가 품을 만한 질문에 단 하나도 답을 안 해 주잖아요.
어쩌면 대상 사용자가 아닌 걸지도 몰라요.
그냥 쿠버네티스도 GPU에 배포할 수 있지 않나요?
네, 됩니다. https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/
쿠버네티스 관련 글이 메인 페이지에 올라왔네요! 몇 년 전 BAI 시절에는 k8s 헤드라인이 한두 개씩은 늘 HN 메인 페이지를 장식하고 있었어요.
그게 끝나서 좀 다행이에요. k8s가 나쁘다는 건 아니지만, 한동안은 좀 과했거든요.
방금 "AI 이전"이라는 뜻의 약어를 만드신 거예요?
네, 그런데 제가 처음은 아니더라고요. 혹시 내가 처음인가 싶어서 찾아봤는데, 학계에서 비공식적으로 한동안 돌아다니던 말인 모양이에요. 저는 전에 본 적이 없으니, 적어도 독자적으로 생각해 냈다고는 말할 수 있겠죠.
저는 가끔 이런 걸 생각해 내요. 미국 등록 상표 중 적어도 하나는 제 거고요.
미래의 역사책은 이렇게 쓰이겠죠. 고대 레거시 기술 복합기업 구글은 24BAI 무렵에 설립되었다고요.
우리가 "AI"라는 말을 끊임없이 입에 올리고, 지금의 기술을 바탕으로 p(doom)을 끝도 없이 논쟁하는 모습이 미래에는 꽤 웃기게 보일 것 같아요.
19세기 후반에 철도와 전신 덕분에 우리가 한계 없는 기술적 특이점 속에 살고 있다고 쉬지 않고 떠들어 대는 에세이를 읽는 기분이죠. 요즘 해커칼립스 담론에는 벌써 20년대의 "폭격기는 언제나 뚫고 들어온다" 같은 기운이 있어요.
"르네상스 이후 모든 시대 사람들이 자기들이야말로 유례없이 변혁적이고 어쩌면 파국적일 수도 있는 기술 변화의 문턱에 서 있다고 어리석게 믿어 온 건 맞지만... 이번엔 다르다니까"
60년대에도 누가 똑같은 말을 했을 거라고 상상할 수 있어요. 핵실험 금지 조약에 서명하지 마라, 1300년대부터의 귀납적 근거가 있다... 아, 잠깐, 시점을 흑사병 직후로 잡아 보죠. 르네상스 때부터의 귀납적 근거가 보여 주듯 우리는 이런 일을 늘 지나치게 걱정해 왔으니, 이번이라고 다를 건 없다는 거죠.
아니면 32BAGI 같은 것도 있겠네요.
"3차 세계대전 이전"이 우선할 게 거의 확실한데요.