- K8s가 Infra OS로 자리잡은 현실, GPU Scheduling 생태계, Backend.AI의 위치를 짚음
- Lagrange에서 시작해서 다음 단계 통합 Architecture까지
- K8s 생태계의 현재 → GPU Scheduling의 현실 → Backend.AI의 강점과 한계 → 통합 Architecture 순서
- 본론에 들어가기 전에 이 발표를 왜 하는지부터
- Orchestrator로서의 K8s와 경쟁했던 건 맞음
- 하지만 Infra OS로서의 K8s는 경쟁 대상이 아니라 활용 대상
- 이 발표에서 하나씩 보여줄 예정
- Kueue, Volcano, KAI, Slurm 전부 K8s Scheduler를 피함
- K8s Scheduler는 Stateless 웹 서비스를 위해 설계된 것. GPU는 그 범위 밖
- Backend.AI가 K8s Scheduler를 안 쓰는 건 특이한 게 아니라 업계 전체가 그러고 있음
- 첫 번째 Part
- K8s가 10년간 어떻게 바뀌었는지, 숫자로 확인
- CNCF의 3단계 Framework
- 두 번째 전환이 핵심: CRD와 Operator가 나오면서 K8s 위에 뭐든 올릴 수 있게 됨
- DB, ML Pipeline, Spark Cluster 전부 K8s CRD로 운영하는 시대
- DRA GA로 GPU까지 K8s의 1급 시민
- CNCF가 2026.01에 발표한 Survey
- 제목 자체가 "Kubernetes Established as the De Facto Operating System for AI"
- 82% Production 사용, GenAI Inference도 66%가 K8s 위
- 도입 장벽 1위가 기술적 복잡도가 아니라 문화 변화라는 건 K8s 자체는 이미 성숙했다는 뜻
- GPU만 따로 뽑은 Timeline
- 2017년 Device Plugin 이후 8년간 정수 단위 GPU 모델이 거의 불변
- 2025년 DRA GA로 속성 기반 요청 + Topology 인식 가능
- JobSet, LeaderWorkerSet로 분산 Training/Inference Topology까지 K8s Native
- 두 번째 Part
- K8s 기본 Scheduler의 GPU 한계를 짚고, K8s Native Solution들을 하나씩 살펴봄
- K8s 기본 Scheduler의 GPU 한계는 근본적
- Topology Manager가 GA이긴 한데 kubelet Level이라 Scheduler는 NUMA를 모른 채 배치
- DRA가 상황을 개선하지만 Ecosystem이 따라가는 단계
- NVIDIA가 Run:ai를 인수하고 Open Source로 공개
- K8s Native에서 Fractional GPU를 가장 성숙하게 지원하는 Solution
- 다만 NVIDIA 생태계 중심이고 Community가 아직 작음
- Fractional GPU를 K8s Native로 가장 성숙하게 지원하는 건 KAI
- Gang Scheduling은 K8s 기본에도 Alpha로 들어왔지만 Production 수준 아님
- 각 Solution마다 강점이 있지만 전부를 Cover하는 건 없음
- 이게 이 Section의 핵심 메시지
- K8s가 "AI의 OS"라고 불리지만, 실제 GPU Scheduling은 K8s 기본 Scheduler를 피하면서 이루어짐
- K8s가 쓰이는 이유는 Scheduler가 아니라 API Server + CRD + 운영 편의 때문
- K8s Scheduler는 Stateless 웹 서비스를 위해 설계된 것. GPU Workload는 그 설계 범위 밖
- DRA가 이 격차를 좁히기 시작했지만 아직 초기 단계
- Backend.AI도 이 관점에서 보면 다른 Solution들과 같은 선상에 있음
- Slurm은 앞 Slide에서 본 "Scheduler를 완전히 무시하는" 카테고리
- K8s 밖에서 GPU Scheduling을 독자적으로 다루는 세계
- Slurm의 가장 큰 한계는 Inference/Serving에 맞지 않다는 것
- Service, Ingress, Load Balancer 개념 자체가 없음
- NVIDIA가 SchedMD를 인수한 건 Slurm의 위상을 보여주지만, 설계적 한계는 그대로
- Slinky도 K8s Scheduler를 우회하는 사례: K8s는 배포만, Scheduling은 Slurm
- Backend.AI가 앞의 Solution들과 출발점 자체가 다르다는 것을 보여줌
- fGPU는 K8s Native에서 최근에야 지원되기 시작한 Fractional GPU를 K8s 이전부터 자체 해결
- Sokovan은 NUMA Topology를 보면서 CPU-GPU-Memory를 물리적으로 가까운 조합으로 Mapping
- Gang Scheduling은 Sokovan이 Application Layer에서 보장, K8s 비종속
- Multi-Node Session은 분산 Training을 위한 핵심 기능
- Hardware Agnostic은 KAI가 NVIDIA 전용인 것과 대비
- K8s 없이 돌아간다는 건 장점이자 동시에 고민 포인트
- Backend.AI의 기술적 차별점은 분명
- K8s가 Infra OS가 된 세계에서 K8s 밖에 따로 있으면 고객에게 "또 하나의 Silo"
- 이미 K8s로 Monitoring, CI/CD, GitOps를 다 하고 있는 고객한테 별도 운영 체계를 요구하면 부담
- 왜 통합이 필요한지, 어떤 질문을 던져야 하는지 정리
- 단순히 K8s 위에 Backend.AI를 올리는 게 아님
- Backend.AI가 관리하는 Computing Resource를 K8s 세계에서 자연스럽게 쓸 수 있게 만드는 것
- 반대로 K8s Workload가 Backend.AI Infra 위에서 돌 수 있게 하는 것
- 이 양방향 Bridge가 필요
- Lagrange는 Backend.AI와 K8s를 잇는 첫 번째 시도
- Virtual Kubelet은 K8s Node를 Software로 구현하는 Pattern
- 물리 Server 없이 K8s API Server에 Node로 등록, 뒤에 어떤 Computing Backend든 연결 가능
- AWS Fargate가 대표적, InterLink은 Slurm Cluster를 K8s에 연결
- CNCF Sandbox 단계에 머물러 있음
- 구조는 두 Component: Bridge + Driver Server
- Bridge가 K8s 안에서 Backend.AI Agent당 Virtual Kubelet Instance를 띄워 가상 Node 등록
- 3개의 Reconciler: Node(Agent 상태 → K8s Node), Workload(Session ↔ Pod), Service(Serving → Deployment+Service)
- Driver Server는 gRPC로 Backend.AI 측 정보를 Bridge에 제공 (Direct 또는 Reverse Tunnel 모드)
- Tracked Workload 기능: K8s에서 Pod을 만들면 Backend.AI Session으로 자동 생성도 가능
- Lagrange는 동작함. kubectl로 Backend.AI Resource 확인, Serving의 K8s Service 노출
- 하지만 두 Cluster를 따로 운영하면서 Bridge로 연결하는 형태라 운영 복잡도가 높았음
- 이 경험을 바탕으로 다음 단계 접근이 나옴
- Lagrange에서 배운 것을 바탕으로 다음 단계 통합 Architecture 설명
- Control Plane은 K8s 위에 배포: Manager는 Deployment, DB/etcd/Redis는 StatefulSet
- Agent는 DaemonSet으로 GPU Node에 배포, hostNetwork: true
- GPU Workload Container는 K8s Pod이 아님. Agent가 Host Docker에 직접 생성
- K8s Device Plugin은 명시적으로 비활성화. GPU 할당은 Backend.AI가 etcd를 통해 관리
- DooD = Docker-out-of-Docker. DinD처럼 중첩 Daemon을 띄우는 게 아님
- Host Docker Socket을 Mount해서 Host Level에 Sibling Container로 생성
- Agent Pod 안에서는 Agent Server Process만 동작, GPU Workload는 Host Docker Runtime에서 직접 생성
- K8s 입장에서는 DaemonSet Pod만 보이고, Kernel Container들은 K8s 관리 범위 밖
- GPU Node에 `backendai.io/dedicated=agent:NoSchedule` Taint 적용
- 핵심은 K8s를 Infra OS로만 쓰겠다는 것
- K8s가 잘하는 배포, Service Discovery, Monitoring은 활용
- GPU Workload를 K8s Pod으로 만들지 않음
- 고객은 CPU Workload는 K8s에서, GPU Workload는 Backend.AI UI/CLI로 관리
- GPU Workload를 kubectl로 봐야 한다는 요구는 실제로 별로 없음
- Multi-Node Session의 Networking이 핵심 Challenge
- 현재는 Docker Swarm Overlay Network를 사용해서 K8s CNI와 공존
- CIDR Range를 분리해서 IP 충돌을 방지
- 장기적으로는 containerd로 전환하면서 CNI를 직접 호출하는 방향
- Storage는 Host NFS Pre-Mount로 해결
- CNI 공존이 가장 까다로운 부분: K8s CNI와 Docker Swarm Network가 같은 Host에서 공존
- 보안은 DooD 특성상 Host Docker 전체 제어권을 가지므로 Hardening 필요
- Runtime 전환은 Phase별 접근: Docker → containerd
- 가장 큰 차이: Cluster가 하나냐 둘이냐
- Lagrange는 Backend.AI + K8s 별도 운영 + Bridge, 다음 단계는 K8s 하나에 Backend.AI 배포
- GPU Workload가 K8s에서 안 보인다는 Trade-Off
- Lagrange는 이 Architecture가 자리잡으면 Sunset 예상