Kubernetes(쿠버네티스) 기술 블로그 최신 글
Kubernetes(쿠버네티스, K8s) 기반 배포, 컨테이너 운영과 인프라 개선 사례를 다룬 회사 기술 블로그 글입니다.
Kubernetes 관련 최신 기술 블로그 글
[기술 가이드] Kubernetes의 핵심 변화: DRA를 통한 GPU 자원 동적 할당
kt cloud Container Service팀 박지선 님 요약 SUMMARY 이 글에서는 Kubernetes 1.34에서 GA로 전환된 DRA를 중심으로 GPU 자원 동적 할당과 ResourceClaim 활용 방법을 다룹니다. CDI 기반 장치 주입과 MIG 연계 방식 등 GPU 운영에 필요한 주요 변화를 정리합니다. #Kubernetes #DRA #GPU스케줄링 #ResourceClaim #CDI AI/ML 워크로드가 기업 인프라의 핵심으로 자리 잡으면서, GPU 자원을 얼마나 효율적으로 스케줄링하고 관리하느냐가 경쟁력의 척도가 되고 있습니다. Kubernetes 1.34(2025년 8월 출시)는 바로 이 지점에서 중요한 전환점을 마련했습니다. Kubernetes 1.34 버전 릴리스의 주요 enhancement 중 하나는 DRA(Dynamic Resource Allocation)의 GA 승격입니다. 기존 Device Plugin 방식의 정적이고 경직된 GPU 할당 방식에서 벗어나, 이제는 "메모리 20GB 이상의 GPU 아무거나 주세요" 와 같이 조건 기반의 유연한 자원 요청이 가능해졌습니다. 이는 LLM 학습, 추론 서비스, 멀티테넌트 GPU 공유 등 다양한 시나리오에서 운영 효율을 획기적으로 높여줍니다. 또한 지난 2026년 3월 KubeCon Europe에서 NVIDIA는 GPU용 DRA 드라이버를 CNCF에 기증하며 커뮤니티 주도의 GPU 오케스트레이션 생태계로의 전환을 공식화했습니다. 이 포스팅에서는 Kubernetes 1.34에서 GPU 관련 변화에 대해 자세히 살펴보겠습니다. 핵심 변화 Kubernetes 1.34 에서 본격적인 Feature 변경사항에 대해 설명합니다. 변화 1: DRA (Dynamic Resource Allocation) - 드디어 GA [DRA란?] DRA(Dynamic Resource Allocation) 는 resource.k8s.io API 그룹 기반의 Kubernetes 프레임워크입니다. ResourceClaim 이나 ResourceClaimTemplate 리소스를 생성하여 여러 GPU 자원 중 NVLink로 묶인 자원만 Pod에 할당하거나, Pod가 실행될 때만 GPU를 동적으로 예약하는 등 보다 유연하게 활용할 수 있는 특장점을 가집니다. DRA Driver 사용 시 Kubernetes v1.34.2 이상을 사용하세요. v1.34.0/v1.34.1에는 알려진 이슈가 있습니다. ResourceClaim / ResourceClaimTemplate ResourceClaim은 특정 Pod가 실행되기 위해 필요한 하드웨어 자원의 구체적인 명세와 예약 현황을 기록하는 객체이며, ResourceClaimTemplate은 이 ResourceClaim을 동적으로 자동 생성하기 위해 미리 정의해 둔 템플릿입니다. ResourceClaim 과 Pod는 1:1 바인딩되며 GPU 자원을 락(Lock)을 걸어, Pod에만 독점합니다. Deployment나 StatefulSet 아키텍처에서는, ResourceClaimTemplate 을 사용하여 Pod replicas 변화될때 마다 자동으로 ResourceClaim 복제본이 생성되도록 사용할 수 있습니다. [DRA 사용 방법] DeviceClass 확인 NVIDIA GPU Operator 를 설치하면 nvidia.com/gpu 이름의 DeviceClass가 자동 생성됩니다. # kubectl get deviceclasses apiVersion: resource.k8s.io/v1 kind: DeviceClass metadata: name: nvidia.com/gpu spec: selectors: - cel: expression: device.driver == "gpu.nvidia.com" ResourceClaim 리소스를 생성 사용자가 이 DeviceClass를 사용하는 ResourceClaim 또는 ResourceClaimTemplate 을 생성합니다. 다양한 조건 기반으로 GPU 자원 할당을 요청합니다. # 16GiB 이상 메모리를 가진
기술 블로그 (Tech) | kt cloud2026년 11월 4일컨테이너처럼 쓰고, VM처럼 격리하기
네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다. 컨테이너처럼 쓰고, VM처럼 격리하기: kata-containers with GPU NAVER D2 | 컨테이너처럼 쓰고, VM처럼 격리하기: kata-containers with GPU naver.me 발표 내용 Kubernetes GPU 노드를 VM으로 격리해 나눠 쓰면서, 호스트 수준의 성능까지 최적화한 방법을 소개합니다. 발표 대상 여러 사용자가 GPU node를 함께 쓰는 환경에서 격리를 강화하려는 플랫폼 개발자 Kubernetes에서 kata-containers나 VM 기반 runtime 도입을 검토하는 개발자 DRA로 GPU·NIC 같은 device 할당을 직접 구현하려는 개발자 VM 환경에서 GPU·IB·storage 성능을 bare metal 수준으로 맞추려는 개발자 발표자료 국문 영문 목차 도입 배경과 kata-containers의 구조 GPU와 NIC를 VM에 함께 할당하기 VM 부팅 시간과 성능 개선하기 마무리: 사용자가 작성하는 Pod spec과 bare metal 대비 성능 ◎ NAVER Engineering Day란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로도 많은 관심과 팔로우 부탁드리겠습니다.
NAVER D22026년 11월 2일사이드카의 선언적 관리: OpenKruise SidecarSet 도입과 운영
Kubernetes에서 서비스를 운영하다 보면 메인 컨테이너 옆에 사이드카(sidecar) 컨테이너를 붙이는 일이 흔합니다. 사이드카에는 로그와 메트릭 수집, 프록시처럼 주 기능은 아니지만 같은 Pod 안에서 함께 실행되어야 하는 기능이 포함됩니다. 저희 팀이 운영하는 관리형 데이터베이스 서비스도 DB 인스턴스를 Pod 단위로 실행하고, 그 Pod에 DB 컨테이너 외에 헬스 체크, 메트릭과 로그 수집 등을 위한 사이드카를 함께 둡니다. 이 사이드카들은 DB와 같은 데이터 볼륨에 접근해야 하므로 같은 Pod 안에 있어야 하지만, 라이프사이클은 DB와 다릅니다. DB는 한 번 실행하면 몇 달씩 그대로 운영하는 반면, 사이드카는 기능 추가와 버그 수정, 보안 패치로 훨씬 자주 바뀝니다. 사이드카가 바뀔 때마다 그 변경을 모든 인스턴스에 반영해야 하는데, DB 서비스는 유지한 채 실행 중인 Pod의 사이드카만 바꿔야 합니다. 사이드카는 모든 DB Pod에 붙으므로 이 작업은 인스턴스 수만큼 반복됩니다. 그 결과 반영 시점이 인스턴스마다 다를 수 있고, 사이드카 종류가 여럿이면 버전 조합도 인스턴스마다 제각각이 됩니다. DB Pod는 오래 실행되니 이 상태가 그대로 굳어지고, 어떤 인스턴스에 어떤 버전이 실행 중인지 알려면 Pod를 하나씩 조회해야 합니다. 사이드카 수가 늘수록 형상 관리와 배포, 모니터링이 모두 어려워집니다. 이 글은 Kubernetes 환경에서 사이드카를 운영하는 독자를 대상으로, 사이드카를 선언적으로 관리할 수단으로 OpenKruise SidecarSet을 도입한 이유, SidecarSet의 기능과 동작 방식, 운영하며 알게 된 점을 다룹니다. 사이드카 관리의 어려움: 형상 관리, 배포, 모니터링 사이드카를 관리하려면 사이드카 이미지를 한곳에 선언하는 형상 관리, 선언을 실행 중인 Pod에 적용하는 배포, 결과를 조회하는 모니터링이 필요합니다. 그런데 Kubernetes만으로는 이 세 가지가 모두 어렵습니다. 예를 들어 로그 수집 사이드카의 이미지를 바꾸면, 그 사이드카가 들어간 모든 DB Pod에 같이 적용되어야 합니다. 하지만 Kubernetes에서 사이드카 이미지는 Pod 스펙이나 Deployment, StatefulSet의 Pod 템플릿마다 따로 지정되어 있어서 한 번에 바꿀 방법이 없습니다. Pod 템플릿을 고치면 Kubernetes가 Pod를 다시 만들면서 새 이미지를 적용합니다. 하지만 이 과정에서 DB 컨테이너도 함께 재시작되므로 사이드카를 바꿀 때마다 이 방법을 쓸 수는 없습니다. DB는 그대로 둔 채 사이드카만 바꾸려면 실행 중인 Pod의 이미지를 직접 수정(in-place 갱신)해야 합니다. 이때 kubelet은 이미지가 바뀐 컨테이너만 다시 시작하므로 DB 컨테이너는 영향을 받지 않습니다. 다만 이렇게 수정할 수 있는 컨테이너 스펙은 이미지뿐이고, 수정도 Pod마다 따로 해야 합니다. 사이드카 이미지가 바뀔 때마다 대상 Pod를 찾아 하나씩 고치는 일은 Kubernetes가 해 주지 않습니다. 조회도 같은 한계가 있습니다. Deployment, StatefulSet의 status에 updatedReplicas가 있지만 템플릿 기준이므로, Pod에서 직접 바꾼 이미지는 집계되지 않습니다. 반영 여부를 확인하려면 Pod마다 status에 기록된 이미지를 선언과 하나씩 비교해야 합니다. Kubernetes는 워크로드 단위의 재생성과 Pod 하나의 이미지 교체까지만 제공합니다. 여러 워크로드의 사이드카를 한곳에 선언하고, DB를 유지한 채 실행 중인 Pod에 반영하며, 그 결과를 조회하려면 별도의 수단이 필요합니다. 직접 만들 것인가, 가져다 쓸 것인가 가장 단순하게는 대상 Pod를 순회하며 사이드카 이미지를 패치하는 스크립트를 만들 수 있습니다. 그런데 스크립트는 실행한 순간의 Pod 목록에 패치를 보내고 끝나므로, 패치가 실제로 반영됐는지 확인하고 실패한 Pod에 패치를 다시 보내려면 또 다른 스크립트가 필요합니다. 실행 뒤에 생긴 변화도 마찬가지입니다. 사람이 직접 이미지를 되돌린
NAVER D22026년 10월 29일