KEP-5945: jak DRA Optional Node Operations eliminuje no-op DaemonSety w Kubernetes

Dynamic Resource Allocation (DRA) to mechanizm przydzielania zasobów sprzętowych w Kubernetes — GPU, FPGA, sieciowych akceleratorów — znacznie elastyczniejszy niż stare resources.limits. Ale ma jeden uciążliwy wymóg: na każdym węźle, gdzie może wylądować pod korzystający z zasobu DRA, musi działać lokalny driver jako DaemonSet. Nawet jeśli ten driver nie ma nic do zrobienia.

Problem: gRPC w pętli nawet gdy nie trzeba

Kiedy pod żąda zasobu przez DRA, kubelet wysyła do lokalnego drivera dwa wywołania gRPC:

  • NodePrepareResources — przed startem kontenera
  • NodeUnprepareResources — po zakończeniu poda

Dla urządzeń zarządzanych centralnie (np. sieciowych kart wirtualnych konfigurowanych przez kontroler w warstwie control plane) te wywołania są puste. Driver nie ma nic do przygotowania na węźle — zasoby są gotowe zanim kubelet się w ogóle odezwie.

Efekt: operatorzy (zespoły platformowe/administratorzy) piszą DaemonSety składające się wyłącznie z obsługi tych dwóch wywołań, które zawsze odpowiadają „OK". Jeśli DaemonSet nie działa na węźle — np. podczas aktualizacji lub awarii — kończący się pod wisi w stanie Terminating, bo kubelet czeka na NodeUnprepareResources, które nigdy nie nadejdzie.

Rozwiązanie: skipNodeOperations

KEP-5945 dodaje pole skipNodeOperations do ResourceSliceSpec. Driver deklaruje w nim, których operacji kubelet nie powinien wywoływać:

apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
  name: my-network-devices
spec:
  driver: network.example.com
  skipNodeOperations:
    - NodePrepareResources
    - NodeUnprepareResources
  # lub krócej:
  # skipNodeOperations: ["*"]
  nodeName: worker-01
  devices:
    - name: vnic-0
      basic:
        attributes:
          type:
            string: virtual-nic

Wartość "*" pomija oba wywołania. Jeśli chcesz pominąć tylko jedno — możesz, ale z ograniczeniem: NodePrepareResources można pominąć tylko razem
z NodeUnprepareResources (lub przez *). Logika jest prosta: pod może startować bez prepare, ale jeśli przy terminacji nie ma komu wywołać unprepare — i nie zadeklarowałeś wcześniej, że tego nie potrzebujesz — kubelet utknąłby na oczekiwaniu.

Jak to przepływa przez system

Starsze kubelety bez obsługi DRAOptionalNodeOperations zachowują się defensywnie: jeśli claim żąda skipa, a kubelet go nie rozumie — preparacja kończy się błędem zamiast cicho kontynuować z nieprzygotowanym zasobem. To świadoma decyzja — fail fast zamiast trudnego do debugowania silent failure.

Zmiana skipNodeOperations na istniejącym driverze nie dotyczy aktywnych claimów — zachowują oryginalne zachowanie do końca swojego życia. Migracja wymaga zatem odnowienia claimów po aktualizacji drivera.

Status i dostępność

WersjaStatusBrama
v1.37AlphaDRAOptionalNodeOperations=false
v1.38BetaDRAOptionalNodeOperations=true (domyślnie)
v1.40Stable (cel)—

Od v1.38 funkcja działa bez żadnej konfiguracji — wystarczy zaktualizować driver, żeby deklarował skipNodeOperations.

Dlaczego to ważne

DRA jest jeszcze młodym mechanizmem, ale kierunek jest jasny: zastąpi device plugins przy zarządzaniu GPU, FPGA i specjalizowanym sprzętem sieciowym. Problemy operacyjne — jak konieczność utrzymywania no-op DaemonSetów — spowalniają adopcję. KEP-5945 usuwa jeden z nich.

Jeśli używasz DRA dla zasobów sieciowych lub storage'u zarządzanego przez centralny kontroler, warto już teraz sprawdzić, czy twój driver obsługuje to pole i zaplanować aktualizację na po wydaniu v1.38 w grudniu.

Źródła: KEP-5945 — k8s.dev, LWKD Week Ending Oct 11, 2026