A múlt héten pont belefutottam egy klasszikus szívásba: podok kerültek olyan node-okra, ahol a CNI plugin még nem állt készen. Ismerős helyzet. A node feljön, a kubelet szerint Ready, aztán a pod szépen beragad ContainerCreating állapotban, mert a Calico még matat a háttérben. Ezt én is kerülgettem már mindenféle init containeres és postStart-os trükkel.

Aztán szembejött velem a Node Readiness Controller a Kubernetes blogon. Ez egy friss SIG projekt (v0.1.1), és pont azt adja, ami rég hiányzott: egyedi readiness kapuk node-okhoz, deklaratívan, CRD-vel.

Mi a gond a mostani modellel?

A Kubernetes alapból egyetlen readiness jelzést ad node-ra: a Ready conditiont. Csakhogy ez a gyakorlatban nem ugyanaz, mint hogy “erre már nyugodtan mehet a workload”. Nálam tipikusan ezeknek kell késznek lenniük, mielőtt kiengedem rá a podokat:

  • CNI plugin teljes inicializáció
  • GPU driver betöltve és ellenőrizve
  • Storage CSI driver regisztrálva
  • Egyedi health checkek zöldek
  • Nagy image-ek előre lehúzva

Korábban ezt taintekkel, kézi scripteléssel, DaemonSet readiness próbákkal, meg néha ronda kerülőutakkal oldottam meg. Működött, csak törékeny volt.

NodeReadinessRule a gyakorlatban

A controller behoz egy NodeReadinessRule CRD-t. Leírom a feltételeket, a controller pedig intézi a taintelést és feloldást. Ezt például CNI readinessre használom:

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: cni-readiness
spec:
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

Itt mi történik:

  1. NoSchedule taint kerül a kiválasztott worker node-okra.
  2. A controller figyeli, hogy a NetworkReady condition True legyen.
  3. Ha az lett, leveszi a taintet.
  4. Mivel bootstrap-only, az első sikeres kör után nem foglalkozik vele tovább.

Két enforcement mód

Itt dől el, mennyire szigorúan akarom védeni a schedulert.

bootstrap-only: induláskor ellenőriz, aztán kész. Jó az egyszeri init jellegű dolgokra, például image warmup vagy driver setup.

continuous: folyamatosan figyel node-életciklus alatt. Ha például hajnalban szétesik a GPU driver, a node visszakapja a taintet, és nem ülnek rá új podok, amíg helyre nem áll.

GPU-s node-okra nálam egyértelműen continuous menne:

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: gpu-driver-readiness
spec:
  conditions:
    - type: "gpu.mycompany.io/DriverHealthy"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/gpu-unavailable"
    effect: "NoSchedule"
    value: "unhealthy"
  enforcementMode: "continuous"
  nodeSelector:
    matchLabels:
      accelerator: "nvidia-a100"

Honnan jönnek a conditionök?

Fontos: a controller nem health checkel, hanem a node conditionökre reagál. Kell valami, ami ezeket beállítja.

A két kézenfekvő opció:

1. Node Problem Detector (NPD): ha már fut nálad, mehetnek rá egyedi scriptek, amik patchelik a conditiont.

2. Readiness Condition Reporter: egy könnyű agent a projektből. DaemonSetként felrakod, rákötöd egy lokális HTTP endpointra, és patcheli a node conditiont.

# Controller telepítése
kubectl apply -f https://github.com/kubernetes-sigs/node-readiness-controller/releases/download/v0.1.1/install.yaml

# Ellenőrzés
kubectl get pods -n node-readiness-system

Dry run: előbb nézzem meg, mit csinálna

Ami szerintem kifejezetten jó benne: van dry run. Mielőtt élesben taintelnék vele egy teljes klasztert, meg tudom nézni, mit tenne:

spec:
  enforcementMode: "continuous"
  dryRun: true

Dry runban nem nyúl ténylegesen a tainthez, csak logolja a tervezett lépéseket és frissíti a rule státuszát az érintett node-okkal. Nálunk stagingen ez már egyszer megfogott egy rossz node selectort, ami a fél klasztert véletlenül kizárta volna.

Röviden, nekem miért tetszik

Ez még alpha (v0.1.1), szóval kritikus productionbe én is óvatosan tenném csak be. Ettől függetlenül az irány nagyon rendben van:

  • Deklaratív: nincs több kézzel tákolt taint-menedzsment script.
  • Szétválasztott felelősség: bármilyen condition reporterrel együtt tud élni.
  • Biztonságos bevezetés: dry run, bootstrap-only, értelmes státusz-visszajelzés.

Nekem külön pluszpont, hogy szépen együttműködik a meglévő NPD-s setupokkal. Ha az már úgyis fut, a readiness szabályok bevezetése tényleg kis lépés.

Ha vegyes klasztert futtatsz (GPU, nagy memóriás, speciális hardveres node-ok), ez végre egy normális válasz egy régóta fájó problémára. Mi jövő héten visszük be dev klaszterbe, és ha meglesznek a tapasztalatok, írok róla folytatást.

Nézd meg a dokumentációt és a GitHub repót. Ha mész a KubeCon EU 2026-ra, erről lesz maintainer track session is.