GKE의 동적 리소스 할당 정보

동적 리소스 할당 (DRA) 을 사용하여 Google Kubernetes Engine (GKE) 워크로드에 GPU를 할당할 수 있습니다. 이 문서에서는 DRA의 기본사항, GKE에서 DRA를 사용하는 방법, DRA 사용의 이점을 설명합니다.

이 문서는 다음 역할을 대상으로 합니다.

다음 사항에 이미 익숙해야 합니다.

DRA 소개

DRA는 클러스터 내에서 포드와 컨테이너 간에 하드웨어를 유연하게 요청하고 할당하며 공유할 수 있도록 해주는 Kubernetes의 기본 제공 기능입니다. DRA를 사용하면 기기 공급업체와 플랫폼 관리자가 요청하고 할당할 수 있는 기기의 클래스 를 선언할 수 있으므로 가속기와 같은 연결된 하드웨어를 할당하는 환경이 개선됩니다. 앱 운영자는 이러한 클래스 내에서 특정 기기 구성을 요청한 후 워크로드에서 이러한 구성을 요청할 수 있습니다. Kubernetes 및 GKE는 워크로드 요청에 따라 포드 예약, 노드 할당, 기기 할당을 관리합니다.

예를 들어 플랫폼 관리자는 NVIDIA A100 GPU만 있는 기기 클래스를 정의할 수 있습니다. 그러면 앱 운영자는 GPU 메모리 80GB 이상 필터링과 같은 워크로드 요구사항에 따라 해당 기기 클래스의 기기를 필터링할 수 있습니다. 앱 운영자가 필터링된 구성을 요청하는 워크로드를 배포하면 GKE는 선택한 기준을 충족하는 노드에 포드를 배치합니다. 이 예시에서 GKE는 사용 가능한 A100 (80GB) GPU가 있는 노드를 찾습니다. 앱 운영자는 워크로드 매니페스트에서 특정 노드 또는 기기 구성을 선택할 필요가 없습니다.

DRA의 이점

DRA가 없으면 Kubernetes에서 하드웨어 기기를 할당할 때 기기 플러그인에 의존합니다. 기기 플러그인을 사용하여 포드에 하드웨어 리소스를 연결하려면 노드 라벨을 사용하여 포드를 특정 노드에 배치합니다. 또한 전체 노드의 리소스를 단일 포드에 할당하려면 노드에 연결된 정확한 수의 기기를 요청합니다.

DRA를 사용하면 포드에 기기를 할당하는 것이 스토리지에 볼륨을 할당하는 것과 비슷합니다. 기기 클래스를 정의하고, 해당 클래스 내에서 기기를 요청한 후, 요청된 기기를 워크로드에 할당합니다. DRA는 워크로드 및 비즈니스 요구사항에 따라 기기를 필터링할 수 있는 훨씬 더 확장 가능한 표면을 제공합니다. 표현식과 템플릿을 사용하여 하드웨어를 요청하고 포드를 예약하는 DRA 접근 방식에는 다음과 같은 이점이 있습니다.

  • 선언적 기기 할당: 플랫폼 관리자는 특정 유형의 워크로드 또는 팀에 대한 기기 구성을 정의할 수 있습니다.
  • 팀 간 복잡성 감소: 플랫폼 관리자가 전문 하드웨어 구성이 있는 노드를 프로비저닝할 때 앱 운영자는 특정 구성이 있는 노드를 알 필요가 없습니다. 플랫폼 관리자는 노드에 라벨을 지정하거나 특정 노드 및 기기에 관한 정보를 운영자에게 전달할 필요가 없습니다.
  • 개발자 복잡성 감소: Kubernetes는 참조된 기기 구성에 따라 포드를 예약합니다. 앱 운영자는 워크로드에서 특정 노드를 선택할 필요가 없으며 각 포드가 해당 노드에 연결된 정확한 수의 기기를 요청하는지 확인할 필요가 없습니다.
  • 중앙 집중식 인프라 관리: 플랫폼 관리자는 특정 비즈니스 요구사항을 충족하는 하드웨어 구성을 중앙에서 정의할 수 있습니다. 예를 들어 플랫폼 관리자는 Tesla T4 GPU가 있는 소규모 추론 구성과 함께 H100 GPU가 있는 고성능 구성을 선언할 수 있습니다.
  • 유연한 하드웨어 선택: CEL 표현식을 사용하여 특정 속성이 있는 기기를 필터링할 수 있습니다. 표현식을 사용하면 특정 워크로드에 최적화된 기기를 유연하게 필터링할 수 있습니다.

DRA를 사용해야 하는 경우

GKE에서 DRA를 사용하는 주된 이유는 워크로드에 기기를 요청할 수 있는 유연성 때문입니다. 매니페스트를 한 번 작성하고 매니페스트를 변경하지 않고도 기기 유형이 다른 여러 클러스터에 워크로드를 배포할 수 있습니다. 이러한 유연성은 다음과 같은 사용 사례에 적합합니다.

  • GPU 획득 가능성 개선: GPU 하드웨어에 액세스해야 하는 워크로드의 경우 DRA를 사용하여 GPU 모델을 지정할 필요 없이 클러스터에서 사용 가능한 모든 GPU를 요청할 수 있습니다. 이러한 워크로드에 특정 GPU 메모리 (VRAM) 요구사항이 있는 경우 최소 메모리 용량이 있는 클러스터의 모든 GPU를 요청할 수 있습니다. 이러한 유형의 유연한 요청은 워크로드를 실행할 수 있는 GPU 노드 집합을 확장하여 리소스 부족으로 인해 워크로드가 예약되지 않을 위험을 줄입니다.

  • 확장 중 노드 가용성 최적화: 워크로드에 필요한 기기 수량은 기기 유형 및 기능과 같은 요인에 따라 변경될 수 있습니다. GKE ComputeClasses 를 사용하여 기기 가용성에 따라 가속화된 포드를 특정 노드 풀에 배치할 수 있습니다. 그런 다음 GKE가 포드를 배치하는 모든 노드에서 기기를 요청하도록 포드를 구성할 수 있습니다.

    ComputeClasses와 함께 DRA를 사용하면 최적화된 하드웨어에서 워크로드를 실행하는 데 도움이 되면서 예약되지 않은 워크로드의 위험을 최소화할 수 있습니다.

용어

오픈소스 Kubernetes 및 GKE와 같은 관리형 Kubernetes 제공업체는 다음과 같은 핵심 DRA API 종류를 사용합니다.

ResourceSlice
ResourceSlice는 노드가 액세스할 수 있는 클러스터의 하나 이상의 하드웨어 기기를 나열합니다. 예를 들어 단일 GPU에 액세스할 수 있는 노드에서 ResourceSlice는 GPU와 노드 이름을 나열합니다. 각 노드의 DRA 기기 드라이버는 ResourceSlice를 만듭니다. Kubernetes 스케줄러는 ResourceSlice를 사용하여 워크로드 요청을 충족하기 위해 할당할 기기를 결정합니다.
DeviceClass
DeviceClass는 워크로드에 요청할 수 있는 기기 카테고리(예: GPU)를 정의합니다. 일부 기기 드라이버는 NVIDIA GPU용 gpu.nvidia.com DeviceClass와 같은 기본 제공 DeviceClass를 제공합니다. 플랫폼 관리자는 특정 기기 구성을 정의하는 커스텀 DeviceClass를 만들 수도 있습니다.
ResourceClaim

ResourceClaim을 사용하면 포드 또는 사용자가 DeviceClass 내에서 특정 파라미터를 필터링하여 하드웨어 리소스를 요청할 수 있습니다. 워크로드가 ResourceClaim을 참조하면 Kubernetes는 지정된 파라미터와 일치하는 기기를 해당 ResourceClaim에 할당합니다.

예를 들어 A100 (40GB) GPU 1개에 대한 ResourceClaim을 만든 후 해당 ResourceClaim을 선택하는 워크로드를 배포하는 시나리오를 생각해 보세요. Kubernetes는 사용 가능한 A100 (40GB) GPU를 ResourceClaim에 할당하고 해당 GPU에 액세스할 수 있는 노드에 포드를 예약합니다.

ResourceClaimTemplate

ResourceClaimTemplate은 포드에서 새 포드별 ResourceClaim을 자동으로 만드는 데 사용할 수 있는 템플릿을 정의합니다. ResourceClaimTemplate은 특히 배포 또는 StatefulSet과 같은 워크로드 컨트롤러를 사용할 때 유사한 기기 구성에 액세스해야 하는 워크로드가 여러 개 있는 경우에 유용합니다.

앱 운영자는 ResourceClaimTemplate을 배포한 후 워크로드에서 템플릿을 참조합니다. Kubernetes는 지정된 템플릿을 기반으로 각 포드에 대한 ResourceClaim을 만들고, 기기를 할당하고, 포드를 예약합니다. 포드가 종료되면 Kubernetes는 해당 ResourceClaim을 정리합니다.

DRA API 종류에 대한 자세한 내용은 DRA 용어를 참조하세요.

DRA 작동 방식

클러스터 및 워크로드에서 DRA를 사용하는 것은 StorageClass, PersistentVolumeClaim, PersistentVolume을 사용하여 포드의 볼륨을 동적으로 프로비저닝하는 것과 비슷한 프로세스입니다.

다음 다이어그램은 클러스터 관리자와 앱 운영자가 DRA를 사용하여 기기를 할당하는 단계를 보여줍니다.

이 다이어그램에서 클러스터 관리자와 앱 운영자는 다음을 수행합니다.

  1. 클러스터 관리자는 노드에서 DRA를 지원하는 기기 드라이버를 설치합니다.
  2. 클러스터 관리자는 40GB 이상의 메모리가 있는 모든 GPU와 같이 특정 요구사항을 충족하는 하드웨어를 필터링하는 DeviceClass를 만듭니다. 일부 기기에는 기본 제공 DeviceClass가 포함될 수도 있습니다.
  3. 애플리케이션 운영자는 기기 구성을 요청하는 ResourceClaimTemplate 또는 ResourceClaim을 만듭니다. 각 클레임 유형의 기본 사용 사례는 다음과 같습니다.
    • ResourceClaim을 사용하면 여러 포드가 동일한 기기에 대한 액세스를 공유할 수 있습니다.
    • ResourceClaimTemplate을 사용하면 포드별 ResourceClaim을 자동으로 생성하여 여러 포드가 유사한 개별 기기에 액세스할 수 있습니다.
  4. 애플리케이션 운영자는 워크로드 매니페스트에 ResourceClaimTemplate 또는 ResourceClaim을 추가합니다.
  5. 애플리케이션 운영자는 워크로드를 배포합니다.

ResourceClaimTemplate 또는 ResourceClaim을 참조하는 워크로드를 배포하면 Kubernetes는 다음 예약 단계를 수행합니다.

  1. 워크로드가 ResourceClaimTemplate을 참조하는 경우 Kubernetes는 워크로드의 모든 인스턴스 (예: 배포의 모든 복제본)에 대해 새 ResourceClaim 객체를 만듭니다.
  2. Kubernetes 스케줄러는 클러스터의 ResourceSlice를 사용하여 사용 가능한 적격 기기를 각 포드의 ResourceClaim에 할당합니다.
  3. 스케줄러는 포드의 ResourceClaim에 할당된 기기에 액세스할 수 있는 노드에 각 포드를 배치합니다.
  4. 대상 노드의 kubelet은 노드 내 DRA 드라이버를 호출하여 할당된 하드웨어를 포드에 연결하여 리소스 요청을 충족합니다.

ResourceClaim 및 ResourceClaimTemplate을 사용해야 하는 경우

ResourceClaim 또는 ResourceClaimTemplate을 사용하여 특정 요구사항을 충족하는 기기를 원한다고 Kubernetes에 표시할 수 있습니다. 포드에서 ResourceClaim이 참조되면 Kubernetes는 Kubernetes API 서버의 해당 ResourceClaim API 리소스에 기기를 할당합니다. 이 할당은 ResourceClaim을 만들었는지 아니면 Kubernetes가 ResourceClaimTemplate에서 ResourceClaim을 만들었는지에 관계없이 발생합니다.

ResourceClaim을 만든 후 여러 포드에서 이를 참조하면 이러한 모든 포드가 Kubernetes가 해당 ResourceClaim에 할당하는 기기에 액세스할 수 있습니다. 예를 들어 복제본이 여러 개 있는 배포 매니페스트에서 특정 ResourceClaim을 참조하는 경우 이러한 공유 액세스가 발생할 수 있습니다. 하지만 할당된 기기가 여러 프로세스에서 공유되도록 구성되지 않은 경우 포드 간의 이러한 공유 기기 액세스로 인해 의도하지 않은 동작이 발생할 수 있습니다.

포드에 별도의 기기를 할당하려면 Kubernetes가 개별 ResourceClaim을 자동으로 만드는 데 사용하는 템플릿인 ResourceClaimTemplate을 사용하면 됩니다. 예를 들어 복제본이 여러 개 있는 배포에서 ResourceClaimTemplate을 참조하면 Kubernetes는 복제된 각 포드에 대해 별도의 ResourceClaim을 만듭니다. 따라서 각 포드는 다른 포드와 기기에 대한 액세스를 공유하는 대신 자체 할당된 기기를 가져옵니다. 이러한 자동 생성된 ResourceClaim은 해당 포드의 수명에 바인딩되며 포드가 종료되면 삭제됩니다. 유사한 기기 구성에 액세스해야 하는 독립적인 포드가 있는 경우 ResourceClaimTemplate을 사용하여 각 포드에 기기를 별도로 할당합니다.

다음 표에서는 ResourceClaim을 수동으로 만드는 것과 Kubernetes가 ResourceClaimTemplate에서 ResourceClaim을 만들도록 하는 것의 차이점을 설명합니다.

표 1. ResourceClaim과 ResourceClaimTemplate 비교
수동으로 만든 ResourceClaim 자동으로 만든 ResourceClaim
내가 관리 중인 계획 Kubernetes에서 관리
여러 포드에서 동일한 기기에 대한 액세스 제공 단일 포드에서 기기에 대한 액세스 제공
포드와 독립적으로 클러스터에 존재 해당 포드의 수명 주기에 바인딩됨
특정 기기를 공유해야 하는 여러 워크로드에 적합 독립적인 기기 액세스가 필요한 여러 워크로드에 적합

DRA와 수동 기기 할당 비교

DRA를 사용하면 연결된 기기를 할당하는 것이 PersistentVolume을 동적으로 프로비저닝하는 것과 비슷한 환경이 됩니다. Kubernetes는 기기 플러그인 을 사용하여 기기를 할당하는 것도 지원합니다. 이 메서드에는 다음 단계가 포함됩니다.

  1. 클러스터 관리자는 GPU와 같은 연결된 기기가 있는 노드를 만듭니다.
  2. 클러스터 관리자는 특정 노드 및 연결된 기기에 관한 정보를 워크로드 운영자에게 전달합니다.
  3. 워크로드 운영자는 다음과 같이 워크로드 매니페스트에서 기기를 요청합니다.
    • nodeSelector 필드를 사용하여 GPU 모델과 같이 필요한 기기 구성이 있는 노드를 선택합니다.
    • 포드 사양의 resources 필드를 사용하여 컨테이너에서 사용할 정확한 수의 기기를 지정합니다.

이 수동 할당 메서드를 사용하려면 애플리케이션 운영자와 클러스터 관리자가 특정 기기 구성이 있는 특정 노드 또는 노드 풀에 관해 소통해야 합니다. 노드의 기기와 일치하도록 워크로드 요청을 조정해야 합니다. 그렇지 않으면 배포가 실패합니다. 이와 비교하여 DRA를 사용하면 표현식을 사용하여 속성을 기반으로 기기를 유연하게 필터링할 수 있으며 워크로드 운영자가 클러스터의 노드 구성을 정확히 알 필요가 없습니다.

다음 표에서는 DRA와 기기 플러그인을 비교합니다.

표 2. DRA와 수동 기기 할당 비교
DRA 수동 할당
CEL 표현식을 사용한 유연한 기기 선택 선택기 및 리소스 요청을 사용한 특정 노드 선택
Kubernetes에서 내린 예약 결정 노드 선택기를 사용하여 운영자가 내린 예약 결정
기기 필터링은 워크로드 생성과 별개임 기기 필터링은 워크로드 매니페스트에서 수행해야 함
플랫폼 관리자가 관리하는 중앙 집중식 기기 필터링 및 요구사항 기반 클래스 애플리케이션 운영자의 격리된 기기 필터링
앱 운영자는 각 노드의 노드 용량, 노드 라벨 정보, 또는 연결된 기기 모델을 알 필요가 없음 앱 운영자는 특정 기기의 특정 모델과 수량이 연결된 노드를 알아야 함

DRA 및 인프라 자동 확장

Standard 모드 노드 풀 내에서 노드 수를 자동으로 조정하려면 클러스터 자동 확장 처리를 사용합니다. DRA 드라이버가 있는 노드 풀을 비롯하여 수동으로 만든 노드 풀에서 클러스터 자동 확장 처리를 사용 설정할 수 있습니다.

DRA를 사용하는 노드 풀의 경우 기기 사용률은 클러스터 자동 확장 처리에서 노드 풀에 노드를 추가하고 삭제하는 방식에 영향을 미칩니다. 노드 풀에서 기기 사용률을 계산하기 위해 클러스터 자동 확장 처리는 다음 요소를 고려합니다.

  • 리소스 풀의 모든 기기는 특정 노드의 로컬이어야 합니다. ResourceSlice에 여러 노드에 연결된 기기 풀이 있는 경우 클러스터 자동 확장 처리는 이러한 기기를 무시합니다.
  • 노드 풀의 모든 기기는 똑같이 중요하며 동일합니다.
  • DRA 기기는 CPU 또는 메모리보다 우선순위가 높습니다. DRA 노드 풀에서 클러스터 자동 확장 처리는 CPU 및 메모리 사용량을 무시합니다.

이러한 요인으로 인해 DRA 노드 풀에서 다른 노드 풀과 다른 축소 동작이 발생할 수 있습니다.

DRA를 지원하는 GKE 기기

다음 표에서는 GKE에서 DRA를 사용하여 워크로드에 할당할 수 있는 기기를 설명합니다.

표 3. GKE에서 DRA를 지원하는 기기
DRA를 지원하는 기기
GPU 내 위치에서 사용할 수 있는 모든 GPU 유형입니다. 자세한 내용은 GPU 위치를 참조하세요.
네트워크 인터페이스 관리형 DRANET 드라이버를 설치하여 RDMA 지원 인터페이스와 같은 여러 유형의 네트워크 인터페이스를 사용할 수 있습니다. 자세한 내용은 GKE 관리형 DRANET을 사용하여 네트워크 리소스 할당을 참조하세요.

제한사항

DRA를 사용할 때 다음 제한사항이 적용됩니다.

  • 작동 모드: DRA는 Standard 모드 클러스터에서만 사용할 수 있습니다.

  • 가속기 유형: 미리보기 중에 GKE의 DRA는 GPU만 지원합니다.

  • GPU:

  • 네트워크 인터페이스 (미리보기): 'GKE 관리형 DRANET을 사용하여 네트워크 리소스 할당'의 제한사항을 참조하세요.

  • 자동 확장:

    • 설치하는 서드 파티 DRA 드라이버의 경우 클러스터 자동 확장 처리에는 노드 풀에 노드가 하나 이상 있어야 합니다. 서드 파티 드라이버를 사용하는 노드 풀이 노드 0개로 확장되지 않도록 하려면 최소 노드 수를 1 이상으로 설정하세요.1
    • 클러스터 자동 확장 처리가 서드 파티 DRA 드라이버와 올바르게 작동하지 않을 수 있습니다. 서드 파티 드라이버를 사용하는 경우 드라이버가 특정 노드의 로컬 기기에 대한 정보만 게시하는지 확인하세요.
    • 포드 간에 기기 액세스를 공유하기 위해 정적 ResourceClaim을 사용하는 자동 확장된 노드 풀의 DaemonSet의 경우 자동 확장은 최대 128개의 DaemonSet 포드를 지원합니다. 이 제한을 피하려면 다음 중 하나를 수행하세요.
    • 포드가 ResourceClaim을 참조하고 선점 정책을 PreemptLowerPriority로 설정하는 PriorityClass가 있는 경우 자동 확장 지연 시간이 늘어날 수 있습니다. PreemptLowerPriority 는 PriorityClass의 기본 선점 정책이므로 PriorityClass가 preemptionPolicy 필드를 Never로 명시적으로 설정하는지 확인하세요. 자세한 내용은 비선점 PriorityClass를 참조하세요.

이 섹션에서는 DRA를 사용하여 워크로드에 기기를 할당하려는 플랫폼 관리자 또는 앱 운영자를 위한 권장사항을 제공합니다. DRA는 GKE와 Kubernetes 모두에서 연결된 기기를 요청하는 방식을 크게 변경합니다. 교차 기기 대체 또는 세분화된 기기 필터링 및 선택과 같은 고급 사용 사례를 활용하려면 다음 안내를 고려하세요.

다음 단계