디바이스 플러그인

디바이스 플러그인 (Device Plugins)

GPU, NIC, FPGA, 비휘발성 메모리처럼 벤더별 설정이 필요한 디바이스나 리소스를 클러스터에서 쓰려면 어떻게 해야 할까요? 디바이스 플러그인(device plugin)을 이용하면 이런 기기들을 쿠버네티스가 인식하도록 설정할 수 있어요.

기능 상태: Kubernetes v1.26 [stable]

쿠버네티스는 시스템 하드웨어 리소스를 Kubelet에 알릴 수 있는 디바이스 플러그인 프레임워크를 제공해요. 쿠버네티스 코드 자체를 수정하는 대신, 벤더가 직접 디바이스 플러그인을 구현해서 수동으로 배포하거나 DaemonSet으로 배포하면 됩니다. 대상이 되는 디바이스는 GPU, 고성능 NIC, FPGA, InfiniBand 어댑터처럼 벤더별 초기화와 설정이 필요한 컴퓨팅 리소스예요.

디바이스 플러그인 등록 (Device plugin registration)

Kubelet은 Registration gRPC 서비스를 노출해요.

service Registration {
	rpc Register(RegisterRequest) returns (Empty) {}
}

디바이스 플러그인은 이 gRPC 서비스를 통해 Kubelet에 스스로를 등록할 수 있어요. 등록 과정에서 플러그인은 다음 정보를 보내야 합니다.

• Unix 소켓의 이름
• 플러그인을 빌드할 때 사용한 Device Plugin API 버전
• 광고하고 싶은 ResourceName — 이 이름은 확장 리소스 명명 규칙을 따라 vendor-domain/resourcetype 형태여야 해요. (예를 들어 NVIDIA GPU는 nvidia.com/gpu로 광고됩니다.)

등록이 성공하면 디바이스 플러그인은 관리 중인 디바이스 목록을 Kubelet에 보내고, Kubelet은 이 리소스들을 Kubelet 노드 상태 업데이트의 일부로 API 서버에 광고하는 역할을 맡아요. 예를 들어 디바이스 플러그인이 hardware-vendor.example/foo를 Kubelet에 등록하고 노드에 정상 디바이스 2개를 보고하면, 노드 상태는 'Foo' 디바이스가 2개 설치되어 사용 가능하다고 광고하도록 갱신됩니다.

그 다음 사용자는 Pod 스펙에서 디바이스를 요청할 수 있어요. 확장 리소스를 요청하는 방식은 다른 리소스의 requests와 limits를 관리하는 것과 비슷한데, 두 가지 차이가 있습니다.

• 확장 리소스는 정수 리소스로만 지원되며 초과 할당(overcommit)할 수 없어요.
• 디바이스는 컨테이너끼리 공유할 수 없어요.

예시 (Example)

특정 노드에서 hardware-vendor.example/foo 리소스를 광고하는 디바이스 플러그인이 실행 중인 클러스터를 가정해 볼게요. 데모 워크로드를 실행하기 위해 이 리소스를 요청하는 Pod 예시입니다.

---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container-1
      image: registry.k8s.io/pause:3.8
      resources:
        limits:
          hardware-vendor.example/foo: 2
#
# 이 Pod는 hardware-vendor.example/foo 디바이스를 2개 필요로 하며
# 그 요구를 충족할 수 있는 Node에만 스케줄될 수 있어요.
#
# Node에 이 디바이스가 2개보다 많이 있다면, 나머지는 다른 Pod가
# 사용할 수 있습니다.

디바이스 플러그인 구현 (Device plugin implementation)

디바이스 플러그인의 일반적인 동작 흐름은 다음 단계로 이뤄져요.

초기화(Initialization). 이 단계에서 디바이스 플러그인은 디바이스가 준비 상태가 되도록 벤더별 초기화와 설정을 수행합니다.

플러그인은 호스트 경로 /var/lib/kubelet/device-plugins/ 아래의 Unix 소켓으로 gRPC 서비스를 시작해요 (이 경로는 하드코딩되어 있어 kubelet의 --root-dir 같은 설정에도 영향받지 않습니다). 이 서비스는 다음 인터페이스를 구현합니다.

service DevicePlugin {
      // GetDevicePluginOptions는 Device Manager와 통신할 옵션을 반환해요.
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch는 Device 목록의 스트림을 반환해요.
      // Device의 상태가 바뀌거나 Device가 사라지면 ListAndWatch가
      // 새 목록을 반환합니다.
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate는 컨테이너 생성 중에 호출되어 Device Plugin이
      // 디바이스별 작업을 실행하고 Kubelet에 디바이스를 컨테이너에서
      // 사용할 수 있게 만드는 단계를 알려줘요.
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // GetPreferredAllocation은 사용 가능한 디바이스 목록에서
      // 선호하는 할당 집합을 반환해요. 반환된 선호 할당이 실제로
      // devicemanager가 수행하는 할당이라고 보장되지는 않습니다.
      // 단지 가능할 때 devicemanager가 더 정보에 입각한 할당 결정을
      // 내리도록 돕기 위한 것이에요.
      rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}

      // PreStartContainer는 등록 단계에서 Device Plugin이 표시하면
      // 각 컨테이너 시작 전에 호출돼요. Device Plugin은 컨테이너에
      // 디바이스를 제공하기 전에 디바이스 리셋 같은 디바이스별
      // 작업을 실행할 수 있어요.
      rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
}

참고: 플러그인은 GetPreferredAllocation()이나 PreStartContainer()에 유용한 구현을 제공할 필요는 없어요. 이 호출들의 가용성을 나타내는 플래그는 GetDevicePluginOptions() 호출이 돌려보내는 DevicePluginOptions 메시지에 설정하면 됩니다. Kubelet은 이 중 어떤 함수를 호출하기 전에 항상 GetDevicePluginOptions()를 호출해서 선택적 함수가 어떤 것이 있는지 확인해요.

플러그인은 호스트 경로 /var/lib/kubelet/device-plugins/kubelet.sock의 Unix 소켓을 통해 Kubelet에 스스로를 등록합니다.

참고: 작업 순서가 중요해요. 플러그인은 Kubelet에 등록하기 전에 반드시 gRPC 서비스를 제공하기 시작해야 성공적으로 등록할 수 있습니다.

성공적으로 등록된 후 디바이스 플러그인은 서빙(serving) 모드로 실행되면서 디바이스 상태를 계속 모니터링하고, 디바이스 상태가 바뀌면 Kubelet에 보고해요. 또한 Allocate gRPC 요청을 처리할 책임도 있어요. Allocate 동안 플러그인은 디바이스별 준비 작업을 수행할 수 있는데, 예를 들어 GPU 정리나 QRNG 초기화 같은 작업이죠. 작업이 성공하면 플러그인은 할당된 디바이스에 접근하기 위한 컨테이너 런타임 설정을 담은 AllocateResponse를 반환하고, Kubelet은 이 정보를 컨테이너 런타임에 전달합니다.

AllocateResponse는 0개 이상의 ContainerAllocateResponse 객체를 포함할 수 있어요. 이 객체들에서 디바이스 플러그인은 디바이스에 접근할 수 있도록 컨테이너 정의에 적용해야 하는 수정 사항을 정의합니다. 여기에는 주석(annotations), 디바이스 노드, 환경 변수, 마운트, 정규화된 CDI 디바이스 이름 등이 포함됩니다.

참고: Device Manager가 정규화된 CDI 디바이스 이름을 처리하려면 kubelet과 kube-apiserver 양쪽에서 DevicePluginCDIDevices 기능 게이트가 활성화되어 있어야 해요. 이 기능은 Kubernetes v1.28에서 alpha로 추가되었고, v1.29에서 beta로, v1.31에서 GA로 승격되었습니다.

Kubelet 재시작 처리 (Handling kubelet restarts)

디바이스 플러그인은 Kubelet 재시작을 감지해서 새 Kubelet 인스턴스에 다시 등록해야 합니다. 새 Kubelet 인스턴스는 시작할 때 /var/lib/kubelet/device-plugins(디바이스 플러그인의 하드코딩된 경로) 아래의 모든 기존 Unix 소켓을 삭제해요. 디바이스 플러그인은 자신의 Unix 소켓 삭제를 감시하고, 그런 이벤트가 발생하면 다시 등록할 수 있습니다.

디바이스 플러그인과 비정상 디바이스 (Device plugin and unhealthy devices)

디바이스가 고장나거나 종료되는 경우가 있어요. 이때 디바이스 플러그인의 책임은 ListAndWatchResponse API를 사용해 Kubelet에 상황을 알리는 것입니다.

디바이스가 비정상(unhealthy)으로 표시되면, Kubelet은 새 Pod를 스케줄할 때 사용할 수 있는 디바이스 수를 반영하도록 이 리소스의 할당 가능(allocatable) 개수를 줄여요. 리소스의 capacity 개수는 바뀌지 않습니다.

고장난 디바이스에 할당되었던 Pod는 계속 그 디바이스에 할당된 채로 남아 있어요. 디바이스에 의존하는 코드가 실패하기 시작하는 것이 일반적이며, Pod의 restartPolicy가 Always가 아니면 Pod가 Failed 단계에 들어가거나, 그 외에는 크래시 루프에 빠질 수 있습니다.

Kubernetes v1.31 이전에는 Pod가 고장난 디바이스와 연결되어 있는지 확인하려면 PodResources API를 사용해야 했어요.

기능 상태: Kubernetes v1.36부터 beta, 기본 활성화

ResourceHealthStatus 기능 게이트가 활성화되면(v1.36부터 beta이자 기본 활성화), 각 Pod의 .status 안에 있는 각 컨테이너 status에 allocatedResourcesStatus 필드가 추가돼요. allocatedResourcesStatus 필드는 컨테이너에 할당된 각 디바이스의 상태 정보를 보고합니다. 각 리소스 상태 항목에는 오류 세부정보나 실패 이유 같은 상태에 대한 추가적인 사람이 읽을 수 있는 맥락을 담는 선택적 message 필드가 있을 수 있습니다.

실패한 Pod나 결함이 의심되는 Pod에서, 이 status를 사용해서 Pod의 동작이 디바이스 고장과 관련이 있는지 이해할 수 있어요. 예를 들어 가속기가 과열 이벤트를 보고하면 allocatedResourcesStatus 필드가 이를 보고할 수 있습니다.

디바이스 플러그인 배포 (Device plugin deployment)

디바이스 플러그인은 DaemonSet으로, 노드 OS용 패키지로, 또는 수동으로 배포할 수 있어요.

표준 디렉터리 /var/lib/kubelet/device-plugins(kubelet에 하드코딩된 경로)는 특권(privileged) 접근이 필요하므로, 디바이스 플러그인은 특권 보안 컨텍스트에서 실행되어야 합니다. DaemonSet으로 배포한다면 /var/lib/kubelet/device-plugins를 플러그인의 PodSpec에서 Volume으로 마운트해야 해요.

DaemonSet 방식을 선택하면 쿠버네티스의 도움을 받을 수 있어요. 노드에 디바이스 플러그인 Pod를 배치해 주고, 데몬 Pod가 실패하면 재시작해 주며, 업그레이드 자동화도 지원합니다.

API 호환성 (API compatibility)

이전에는 버전 관리 방식이 디바이스 플러그인의 API 버전이 정확히 Kubelet 버전과 일치하도록 요구했어요. 이 기능이 v1.12에서 Beta로 승격된 이후로는 더 이상 엄격한 요구사항이 아닙니다. API는 버전 관리되며 이 기능이 Beta로 승격된 이후 안정적으로 유지되고 있어요. 이 때문에 kubelet 업그레이드는 매끄러울 수 있지만, 안정화 전에는 API가 바뀔 여지가 있으므로 업그레이드가 반드시 중단 없이(non-breaking) 이뤄진다고 보장되지는 않습니다.

참고: 쿠버네티스의 Device Manager 컴포넌트는 GA 기능이지만, 디바이스 플러그인 API는 안정적이지 않아요. 디바이스 플러그인 API와 버전 호환성에 대한 자세한 내용은 Device Plugin API versions 문서를 참고하세요.

쿠버네티스 프로젝트는 디바이스 플러그인 개발자들에게 다음을 권장합니다.

• 향후 릴리스에서 Device Plugin API 변경을 주시할 것
• 하위/상위 호환성을 위해 여러 버전의 디바이스 플러그인 API를 지원할 것

더 새로운 디바이스 플러그인 API 버전을 쓰는 쿠버네티스 릴리스로 업그레이드해야 하는 노드에서 디바이스 플러그인을 실행하려면, 해당 노드를 업그레이드하기 전에 디바이스 플러그인이 두 버전을 모두 지원하도록 업그레이드하세요. 이렇게 하면 업그레이드 중에도 디바이스 할당이 계속 동작한다는 것을 보장할 수 있어요.

디바이스 플러그인 리소스 모니터링 (Monitoring device plugin resources)

기능 상태: Kubernetes v1.28부터 stable

디바이스 플러그인이 제공하는 리소스를 모니터링하려면, 모니터링 에이전트가 노드에서 사용 중인 디바이스 집합을 발견하고 메트릭을 어떤 컨테이너와 연관지어야 하는지 설명하는 메타데이터를 얻을 수 있어야 합니다. 디바이스 모니터링 에이전트가 노출하는 Prometheus 메트릭은 쿠버네티스 계측 가이드라인을 따라야 하며, 컨테이너를 pod, namespace, container Prometheus 레이블로 식별해야 해요.

Kubelet은 사용 중인 디바이스의 발견과 디바이스 메타데이터 제공을 위한 gRPC 서비스를 제공합니다.

// PodResourcesLister는 kubelet이 제공하는 서비스로, 노드에서
// pod와 container가 소비하는 노드 리소스에 대한 정보를 제공해요.
service PodResourcesLister {
    rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
    rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
    rpc Get(GetPodResourcesRequest) returns (GetPodResourcesResponse) {}
}

List gRPC 엔드포인트

List 엔드포인트는 실행 중인 Pod의 리소스 정보를 제공하는데, 독점 할당된 CPU의 id, 디바이스 플러그인이 보고한 디바이스 id, 이 디바이스들이 할당된 NUMA 노드의 id 같은 세부정보를 담고 있어요. 또한 NUMA 기반 머신에서는 컨테이너에 예약된 메모리와 hugepages 정보도 포함합니다.

Kubernetes v1.27부터 List 엔드포인트는 DynamicResourceAllocation API가 ResourceClaims로 할당한 실행 중인 Pod의 리소스 정보도 제공할 수 있어요. Kubernetes v1.34부터 이 기능은 기본적으로 활성화됩니다.

// ListPodResourcesResponse는 List 함수가 반환하는 응답이에요.
message ListPodResourcesResponse {
    repeated PodResources pod_resources = 1;
}

// PodResources는 pod에 할당된 노드 리소스에 대한 정보를 담아요.
message PodResources {
    string name = 1;
    string namespace = 2;
    repeated ContainerResources containers = 3;
}

// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보예요.
message ContainerResources {
    string name = 1;
    repeated ContainerDevices devices = 2;
    repeated int64 cpu_ids = 3;
    repeated ContainerMemory memory = 4;
    repeated DynamicResource dynamic_resources = 5;
}

// ContainerMemory는 컨테이너에 할당된 메모리와 hugepages 정보를 담아요.
message ContainerMemory {
    string memory_type = 1;
    uint64 size = 2;
    TopologyInfo topology = 3;
}

// Topology는 리소스의 하드웨어 토폴로지를 설명해요.
message TopologyInfo {
        repeated NUMANode nodes = 1;
}

// NUMA는 NUMA 노드를 나타내요.
message NUMANode {
        int64 ID = 1;
}

// ContainerDevices는 컨테이너에 할당된 디바이스에 대한 정보를 담아요.
message ContainerDevices {
    string resource_name = 1;
    repeated string device_ids = 2;
    TopologyInfo topology = 3;
}

// DynamicResource는 Dynamic Resource Allocation이 컨테이너에 할당한
// 디바이스에 대한 정보를 담아요.
message DynamicResource {
    string class_name = 1;
    string claim_name = 2;
    string claim_namespace = 3;
    repeated ClaimResource claim_resources = 4;
}

// ClaimResource는 플러그인별 리소스 정보를 담아요.
message ClaimResource {
    repeated CDIDevice cdi_devices = 1 [(gogoproto.customname) = "CDIDevices"];
}

// CDIDevice는 CDI 디바이스 정보를 지정해요.
message CDIDevice {
    // 정규화된 CDI 디바이스 이름
    // 예: vendor.com/gpu=gpudevice1
    // 자세한 내용은 CDI 스펙을 참고하세요:
    // https://github.com/container-orchestrated-devices/container-device-interface/blob/main/SPEC.md
    string name = 1;
}

참고: List 엔드포인트의 ContainerResources 안의 cpu_ids는 특정 컨테이너에 독점 할당된 CPU에 해당해요. 만약 공유 풀(shared pool)에 속한 CPU를 평가하는 것이 목표라면 아래에서 설명하듯 GetAllocatableResources 엔드포인트와 함께 List 엔드포인트를 사용해야 합니다.

1. GetAllocatableResources를 호출해 모든 할당 가능 CPU 목록을 얻는다.
2. 시스템의 모든 ContainerResources에서 GetCpuIds를 호출한다.
3. GetAllocatableResources 호출 결과에서 GetCpuIds 호출 결과의 모든 CPU를 뺀다.

GetAllocatableResources gRPC 엔드포인트

기능 상태: Kubernetes v1.28부터 stable

GetAllocatableResources는 워커 노드에서 처음에 사용 가능한 리소스에 대한 정보를 제공해요. Kubelet이 APIServer에 내보내는 것보다 더 많은 정보를 제공합니다.

참고: GetAllocatableResources는 노드의 할당 가능 리소스를 평가하는 데만 사용해야 해요. 사용 가능한/미할당 리소스를 평가하는 것이 목표라면 List() 엔드포인트와 함께 사용해야 합니다. GetAllocatableResources가 돌려주는 결과는 kubelet에 노출된 기본 리소스가 바뀌지 않는 한 동일하게 유지돼요. 이런 일은 드물게 일어나지만(예: hotplug/hotunplug, 디바이스 상태 변경) 발생하면 클라이언트가 GetAllocatableResources 엔드포인트를 호출해야 합니다.

그러나 CPU나 메모리 갱신의 경우 GetAllocatableResources 엔드포인트만 호출하는 것으로는 충분하지 않으며, 정확한 리소스 capacity와 allocatable을 반영하려면 Kubelet을 재시작해야 해요.

// AllocatableResourcesResponses는 kubelet이 알고 있는 모든 디바이스에 대한 정보를 담아요.
message AllocatableResourcesResponse {
    repeated ContainerDevices devices = 1;
    repeated int64 cpu_ids = 2;
    repeated ContainerMemory memory = 3;
}

ContainerDevices는 디바이스가 어느 NUMA 셀에 affinity가 있는지 선언하는 토폴로지 정보를 노출해요. NUMA 셀은 불투명한 정수 ID로 식별되며, 이 값은 디바이스 플러그인이 Kubelet에 등록할 때 보고하는 값과 일치합니다.

gRPC 서비스는 kubelet 루트 디렉터리 내의 pod-resources/kubelet.sock(보통 /var/lib/kubelet/pod-resources/kubelet.sock)의 Unix 소켓으로 제공됩니다. 디바이스 플러그인 리소스용 모니터링 에이전트는 데몬이나 DaemonSet으로 배포할 수 있어요. kubelet 루트 디렉터리 내의 표준 디렉터리 pod-resources(보통 /var/lib/kubelet/pod-resources)는 특권 접근이 필요하므로, 모니터링 에이전트는 특권 보안 컨텍스트에서 실행되어야 합니다. 디바이스 모니터링 에이전트가 DaemonSet으로 실행 중이라면 pod-resources 디렉터리를 에이전트의 PodSpec에서 Volume으로 마운트해야 해요.

참고: DaemonSet이나 호스트에 컨테이너로 배포된 다른 앱에서 pod-resources/kubelet.sock에 접근할 때, 소켓 파일 대신 pod-resources 디렉터리를 마운트하는 것이 좋은 관행이에요. 이렇게 하면 kubelet 재시작 후에도 컨테이너가 이 소켓에 다시 연결할 수 있습니다.

일반적인 Linux 노드에서는 /var/lib/kubelet/pod-resources/kubelet.sock 대신 /var/lib/kubelet/pod-resources/를 마운트한다는 뜻이에요. 컨테이너 마운트는 무엇을 마운트했는지에 따라 소켓이나 디렉터리를 참조하는 inode로 관리됩니다. kubelet이 재시작하면 소켓은 삭제되고 새 소켓이 생성되는 반면, 디렉터리는 그대로 남아 있어요. 그래서 소켓의 원래 inode는 사용할 수 없게 되지만, 디렉터리의 inode는 계속 동작합니다.

Get gRPC 엔드포인트

기능 상태: Kubernetes v1.34부터 beta

Get 엔드포인트는 실행 중인 Pod의 리소스에 대한 정보를 제공해요. List 엔드포인트에 설명된 것과 비슷한 정보를 노출합니다. Get 엔드포인트는 실행 중인 Pod의 PodName과 PodNamespace를 필요로 해요.

// GetPodResourcesRequest는 pod에 대한 정보를 담아요.
message GetPodResourcesRequest {
    string pod_name = 1;
    string pod_namespace = 2;
}

Get 엔드포인트는 동적 리소스 할당 API가 할당한 동적 리소스와 관련된 Pod 정보도 제공할 수 있어요. Kubernetes v1.34부터 이 기능은 기본적으로 활성화됩니다.

Topology Manager와의 디바이스 플러그인 통합 (Device plugin integration with the Topology Manager)

기능 상태: Kubernetes v1.27부터 stable

Topology Manager는 리소스가 토폴로지에 정렬된 방식으로 조정될 수 있게 하는 Kubelet 컴포넌트예요. 이를 위해 Device Plugin API가 TopologyInfo 구조체를 포함하도록 확장되었습니다.

message TopologyInfo {
    repeated NUMANode nodes = 1;
}

message NUMANode {
    int64 ID = 1;
}

Topology Manager를 활용하려는 디바이스 플러그인은 디바이스 등록 시 디바이스 ID와 디바이스 상태와 함께 채워진 TopologyInfo 구조체를 다시 보낼 수 있어요. 디바이스 매니저는 이 정보를 사용해 Topology Manager와 상의하고 리소스 할당 결정을 내립니다.

TopologyInfo는 nodes 필드를 nil 또는 NUMA 노드 목록으로 설정하는 것을 지원해요. 이를 통해 디바이스 플러그인이 여러 NUMA 노드에 걸친 디바이스를 광고할 수 있습니다.

특정 디바이스에 대해 TopologyInfo를 nil로 설정하거나 빈 NUMA 노드 목록을 제공하면, 디바이스 플러그인이 그 디바이스에 대한 NUMA affinity 선호도가 없음을 나타내요.

디바이스 플러그인이 디바이스에 대해 채워 넣은 TopologyInfo 구조체 예시입니다.

pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}}

디바이스 플러그인 예시 (Device plugin examples)

참고: 이 섹션은 쿠버네티스가 필요로 하는 기능을 제공하는 서드파티 프로젝트를 링크해요. 쿠버네티스 프로젝트 저자들은 이 프로젝트들에 대해 책임지지 않으며, 알파벳 순으로 나열됩니다.

디바이스 플러그인 구현 예시는 다음과 같습니다.

• Akri — IP 카메라나 USB 장치 같은 이기종 리프(leaf) 디바이스를 손쉽게 노출할 수 있어요.
• AMD GPU 디바이스 플러그인
• 일반 Linux 디바이스와 USB 디바이스를 위한 범용 디바이스 플러그인
• 이기종 AI 컴퓨팅 가상화 미들웨어(예: NVIDIA, Cambricon, Hygon, Iluvatar, MThreads, Ascend, Metax)를 위한 HAMi
• Intel GPU, FPGA, QAT, VPU, SGX, DSA, DLB, IAA 디바이스를 위한 Intel 디바이스 플러그인
• 하드웨어 지원 가상화를 위한 KubeVirt 디바이스 플러그인
• NVIDIA GPU를 노출하고 GPU 상태를 모니터링하는 NVIDIA의 공식 디바이스 플러그인인 NVIDIA GPU 디바이스 플러그인
• Container-Optimized OS용 NVIDIA GPU 디바이스 플러그인
• RDMA 디바이스 플러그인
• SocketCAN 디바이스 플러그인
• Solarflare 디바이스 플러그인
• SR-IOV 네트워크 디바이스 플러그인
• Xilinx FPGA 디바이스를 위한 Xilinx FPGA 디바이스 플러그인

다음 내용 (What's next)

• 디바이스 플러그인으로 GPU 리소스를 스케줄링하는 방법 알아보기
• 노드에서 확장 리소스를 광고하는 방법 알아보기
• Topology Manager 알아보기
• 쿠버네티스에서 TLS 인그레스에 하드웨어 가속을 사용하는 방법 읽어보기
• DRA에 의한 확장 리소스 할당에 대해 더 읽어보기