A Kubernetes scheduler testreszabása a jobb teljesítményért

A felhőalapú infrastruktúrák és konténerizált alkalmazások világában a Kubernetes vált a de facto szabvánnyá a modern alkalmazások telepítésére, skálázására és kezelésére. Számos kulcsfontosságú komponensből áll, amelyek együttesen biztosítják ezt a robusztus működést. Ezen komponensek közül az egyik legfontosabb, mégis gyakran figyelmen kívül hagyott elem a Kubernetes scheduler. Ez a komponens felelős a Podok megfelelő Node-okra történő kiosztásáért, és alapvető szerepet játszik a fürt erőforrásainak hatékony kihasználásában és az alkalmazások optimális teljesítményében.

De mi történik, ha a „gyári beállítások” már nem elegendőek? Mi van akkor, ha a vállalat egyedi igényei, speciális hardverkövetelmények vagy szigorú teljesítménycélok megkövetelik a mélyebb szintű testreszabást? Ebben a cikkben elmélyedünk a Kubernetes scheduler testreszabásának világában, feltárva annak lehetőségeit, előnyeit és legjobb gyakorlatait, hogy Ön kihozhassa a maximumot Kubernetes fürtjéből.

A Kubernetes Scheduler szíve és lelke: Miért olyan fontos az ütemezés?

A kube-scheduler egy olyan irányító sík (control plane) komponens, amely a Podok létrehozására vonatkozó kéréseket figyeli (pontosabban azokat a Podokat, amelyekhez még nincs Node hozzárendelve), majd kiválasztja számukra a legmegfelelőbb Node-ot. Ez a látszólag egyszerű feladat valójában rendkívül komplex folyamat, amely számos szempontot figyelembe vesz, mint például az erőforrásigények (CPU, memória), a Node-ok terhelése, a címkék (labels), a Node affinity/anti-affinity, a Pod affinity/anti-affinity és a taints/tolerations. A scheduler lényegében két fő fázisban működik:

Szűrés (Filtering vagy Predicates): Ez a fázis az összes elérhető Node-ot átvizsgálja, és kiszűri azokat, amelyek nem felelnek meg a Pod által támasztott minimális követelményeknek. Például, ha egy Pod X GB memóriát igényel, akkor az összes olyan Node kiesik, amelyen nincs elegendő szabad memória. A predikátumok tulajdonképpen igen/nem kérdésekre válaszolnak: „Ez a Node alkalmas a Pod futtatására?”
Pontozás (Scoring vagy Priorities): Azok a Node-ok, amelyek átmentek a szűrési fázison, pontozásra kerülnek. Minden Node-hoz hozzárendelnek egy pontszámot különböző kritériumok alapján. Minél magasabb a pontszám, annál alkalmasabb a Node a Pod számára. Például, ha egy Pod egyenletes terheléselosztást szeretne, a scheduler előnyben részesítheti azokat a Node-okat, amelyek kevésbé terheltek. A prioritások tulajdonképpen „mennyire alkalmas ez a Node?” kérdésekre adnak választ.

Miután a pontozás befejeződött, a scheduler kiválasztja a legmagasabb pontszámú Node-ot, és hozzárendeli a Podot ahhoz. Ez a folyamat biztosítja, hogy a Podok hatékonyan és a meghatározott szabályok szerint kerüljenek elosztásra a fürtben.

Miért érdemes testreszabni? Tipikus forgatókönyvek

Bár a default Kubernetes scheduler számos általános felhasználási esetre optimalizált, előfordulhatnak olyan helyzetek, amikor a standard viselkedés nem hozza meg a kívánt teljesítményt vagy nem felel meg a specifikus üzleti logikának. A testreszabás szükségessége a következő tipikus forgatókönyvekben merülhet fel:

Speciális hardverkövetelmények: Bizonyos alkalmazásoknak speciális hardverre (pl. GPU-k, nagy sebességű SSD-k, FPGA-k) van szükségük. A default scheduler nehezen tudja optimalizálni az ütemezést ezen erőforrások alapján anélkül, hogy manuálisan definiálnánk Node affinity szabályokat minden Podnál. Egy testreszabott scheduler automatikusan felismerheti és rangsorolhatja ezeket a Node-okat.
Költségoptimalizálás: Egyre több vállalat használja a felhőszolgáltatók által biztosított spot (példány) instancokat a költségek csökkentésére. Ezek az instancok olcsóbbak, de bármikor visszavehetők. Egy egyedi scheduler preferálhatja ezeket a Node-okat a nem kritikus, hibatűrő munkafolyamatokhoz, vagy éppen elkerülheti őket a kritikus alkalmazások esetében. Zóna-specifikus ütemezés is optimalizálható a hálózati költségek csökkentése érdekében.
Teljesítménykritikus alkalmazások (alacsony késleltetés): Pénzügyi szolgáltatások, valós idejű játékok vagy IoT adatelemzés esetén a mikroszekundumos késleltetés is számít. A scheduler testreszabásával finomhangolhatók a pontozási algoritmusok, hogy a Podok olyan Node-okra kerüljenek, amelyek a legközelebb vannak egymáshoz hálózati topológiailag, vagy amelyek minimális versenyt biztosítanak az erőforrásokért.
Multi-tenant környezetek: Nagyvállalati vagy szolgáltatói környezetben több felhasználó vagy csapat osztozhat egy Kubernetes fürtön. A testreszabott scheduler biztosíthatja az „fair-share” elosztást, elkerülheti a „noisy neighbor” problémát, vagy akár garantált erőforrásokat allokálhat a prioritásos felhasználóknak.
Adatlokalitás: Ha az adatok egy bizonyos Node-on vagy rack-ben találhatóak, előnyös lehet, ha a Podok, amelyek ezeket az adatokat használják, ugyanarra a Node-ra vagy rack-be kerülnek. Ez csökkenti a hálózati forgalmat és javítja a teljesítményt.

A testreszabás módszerei: Mélységben

A Kubernetes scheduler testreszabására számos módszer létezik, a legegyszerűbb konfigurációs változtatásoktól egészen a komplex, teljesen egyedi megoldásokig. Fontos megérteni, hogy melyik megközelítés mikor a legmegfelelőbb.

1. Scheduler Policy (Konfigurációs térkép – ConfigMap) – Hagyományos megközelítés

Ez volt a kube-scheduler testreszabásának hagyományos módja egészen a Kubernetes 1.19-es verziójáig. Egy JSON vagy YAML formátumú konfigurációs fájlt kell létrehozni, amelyet egy ConfigMap-be helyezünk, majd ezt a ConfigMap-et a schedulernek továbbítjuk. Ez a fájl lehetővé teszi a beépített Predikátumok és Prioritások sorrendjének módosítását, ki-bekapcsolását, vagy akár egyéni súlyok megadását a prioritásokhoz.

Előnyök:

Viszonylag egyszerű implementálni, nem igényel kódírást.
Jó kiindulópont az alapvető finomhangolásokhoz.

Hátrányok:

Korlátozott rugalmasság: Csak a meglévő predikátumokat és prioritásokat tudja befolyásolni.
Nehezen bővíthető egyedi logika bevezetésére.
Nehéz több, különböző ütemezési stratégiát kezelni ugyanabban a schedulerben.
Elavulóban van a Scheduler Profiles megjelenésével.

Egy példa a Policy ConfigMap-re (részlet):

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-scheduler-config
  namespace: kube-system
data:
  scheduler-policy.json: |
    {
      "apiVersion" : "v1",
      "kind" : " "Policy",
      "predicates" : [
        {"name" : "NoVolumeZoneConflict"},
        {"name" : "NoDiskConflict"},
        {"name" : "PodFitsHostPorts"},
        {"name" : "MatchNodeSelector"},
        {"name" : "HostName"},
        {"name" : "PodFitsResources"}
      ],
      "priorities" : [
        {"name" : "SelectorSpreadPriority", "weight" : 1},
        {"name" : "InterPodAffinityPriority", "weight" : 2},
        {"name" : "LeastRequestedPriority", "weight" : 1}
      ]
    }

2. Scheduler Profiles (Kubernetes 1.19+) – A modern megközelítés

Ez a módszer váltja fel a régi policy alapú megközelítést, és sokkal nagyobb rugalmasságot biztosít. A scheduler profilok lehetővé teszik, hogy a kube-schedulert egy plugin-alapú architektúra segítségével testreszabjuk. Egy futó scheduler több profillal is rendelkezhet, és a Podok a schedulerName mezőjük segítségével választhatják ki, melyik profilt használják.

A profilok különböző „plugin”-eket tartalmazhatnak, amelyek a scheduler életciklusának különböző pontjain futnak. Ezek a plugin-ek a következők lehetnek:

QueueSort: Meghatározza a Podok sorrendjét a várólistában.
PreFilter: Előzetes ellenőrzéseket végez a Podokon, még mielőtt a szűrési fázis elindulna.
Filter (Predicates): Szűri a Node-okat a Pod követelményei alapján.
PostFilter: Akkor fut, ha egy Podhoz nem található alkalmas Node (pl. hibaüzenet naplózása, vagy alternatív Node keresése).
PreScore: Előkészítő munkát végez a pontozási fázis előtt.
Score (Priorities): Pontozza a szűrt Node-okat, hogy kiválassza a legmegfelelőbbet.
NormalizeScore: Normalizálja a pontszámokat a különböző plugin-ek között.
Reserve: Erőforrásokat foglal le a Node-on a Pod számára.
Permit: Végleges ellenőrzéseket végez, mielőtt a Pod binding folyamata elindulna (akár késleltetheti is a bindinget).
PreBind: Módosíthatja a Podot vagy a Node-ot a binding előtt (pl. CSI volume pre-provisioning).
Bind: Hozzárendeli a Podot a kiválasztott Node-hoz.
PostBind: Végleges műveleteket hajt végre a binding után (pl. metrikák gyűjtése).

Előnyök:

Rendkívül rugalmas és bővíthető, mind a beépített, mind az egyedi plugin-ekkel.
Támogatja a több ütemezési stratégia futtatását egyetlen scheduler instance-en belül.
Tiszta és moduláris architektúra.

Hátrányok:

Magasabb kezdeti tanulási görbe.
A komplex konfiguráció hibalehetőséget rejt.

Egy példa egy egyszerű Scheduler Profile konfigurációra:

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        enabled:
          - name: NodeResourcesMostAllocated
            weight: 2
          - name: NodeResourcesLeastAllocated
            weight: 1
      filter:
        enabled:
          - name: NodeUnschedulable
          - name: PodFitsResources
          # További beépített vagy egyedi filterek

3. Külső Kiterjesztések (Scheduler Extenders)

Amikor a beépített plugin-ek és a policy konfigurációk nem elegendőek, és nem akarunk teljesen új schedulert írni, a scheduler extenders nyújthatnak megoldást. Ezek a külső programok REST API-n keresztül kommunikálnak a kube-schedulerrel, és részt vesznek a szűrési és pontozási fázisokban.

A scheduler átadja a Node-ok listáját és a Pod adatait az extendernek, amely visszaküldi a szűrt Node-okat vagy a pontszámokat. Ez különösen hasznos, ha a döntéshozatalhoz olyan külső információkra van szükség, amelyekről a schedulernek nincs tudomása (pl. egy külső erőforrás-kezelő rendszer állapota).

Előnyök:

Nagyobb rugalmasság, mint a policy alapú testreszabás.
Lehetővé teszi komplex, külső logikák integrálását anélkül, hogy a scheduler forráskódját módosítanánk.

Hátrányok:

Hálózati késleltetést adhat az ütemezési folyamathoz.
A külső extender karbantartásának felelőssége.
A hálózati hibák vagy az extender leállása lelassíthatja vagy leállíthatja az ütemezést.

4. Teljesen egyedi Scheduler (Custom Scheduler)

Ez a legátfogóbb, de egyben legkomplexebb megközelítés. Ahelyett, hogy a meglévő kube-schedulert módosítanánk, teljesen új schedulert írunk a nulláról. Ez akkor indokolt, ha a speciális ütemezési logika annyira eltér a Kubernetes alapértelmezett működésétől, hogy a fenti módszerek már nem elegendőek.

Egy egyedi schedulernek figyelnie kell az API szervert a Podok változásaiért, majd implementálnia kell a szűrési és pontozási logikát, végül pedig frissítenie kell a Pod állapotát az API szerveren a kiválasztott Node-al. A Kubernetes lehetővé teszi több scheduler futtatását egy fürtben; a Podok a .spec.schedulerName mezővel választhatják ki, melyiket használják.

Előnyök:

Teljes kontroll az ütemezési logika felett.
Lehetőséget ad rendkívül speciális, magas optimalizálási igények kielégítésére.

Hátrányok:

Rendkívül komplex implementáció és karbantartás.
Önnek kell kezelnie a skálázást, a hibatűrést és a Kubernetes API-val való interakciót.
Nagyobb a hibalehetőség.

Gyakorlati tippek és bevált gyakorlatok a testreszabáshoz

A scheduler testreszabása hatékony eszköz, de felelősséggel jár. Íme néhány bevált gyakorlat:

Kezdj kicsiben és iterálj: Ne próbáljon meg egyszerre mindent megváltoztatni. Kezdje a legfontosabb módosításokkal, tesztelje, figyelje, majd fokozatosan finomhangolja.
Alapos tesztelés és validáció: A testreszabott schedulert alaposan tesztelni kell fejlesztési és staging környezetben, mielőtt éles környezetbe kerülne. Használjon terheléses teszteket és edge case forgatókönyveket.
Monitoring: Figyelje szorosan a scheduler metrikáit (pl. ütemezési késleltetés, sikeres/sikertelen ütemezések száma), valamint a Podok és Node-ok állapotát. A Kubernetes számos beépített metrikát biztosít a Prometheus segítségével.
Dokumentáció: Dokumentálja részletesen a testreszabott logika célját, működését és konfigurációját. Ez elengedhetetlen a karbantartáshoz és a csapat többi tagjának tájékoztatásához.
Verziókövetés: Minden konfigurációs fájlt és egyedi kódot verziókövetés alatt kell tartani (pl. Git).
Ne feledkezzen meg az alapokról: Mielőtt a schedulert testreszabná, győződjön meg arról, hogy a Podok resource requests/limits, nodeSelector, node affinity/anti-affinity, pod affinity/anti-affinity és tolerations beállításai a lehető legjobban vannak konfigurálva. Sok esetben ezekkel már elérhető a kívánt viselkedés. A scheduler testreszabása ezeken felül finomhangol.
Futtasson több schedulert: Ha különböző típusú munkafolyamatai vannak, érdemes lehet több schedulert futtatni (mindegyiknek saját profillal vagy konfigurációval), és a Podoknak a schedulerName mezővel megmondani, melyiket használják.

Összefoglalás és jövőbeli kilátások

A Kubernetes scheduler testreszabása egy erőteljes eszköz, amely lehetővé teszi, hogy a fürt erőforrásait a legoptimálisabban használja fel, és maximalizálja az alkalmazások teljesítményét. Legyen szó speciális hardverek kihasználásáról, költségoptimalizálásról vagy alacsony késleltetésű alkalmazások támogatásáról, a scheduler finomhangolásával jelentős előnyökre tehet szert.

A Kubernetes közösség folyamatosan fejleszti a scheduler képességeit, és a scheduler profilok bevezetése nagy lépést jelent a rugalmasabb és modulárisabb ütemezés felé. Bár a testreszabás növeli a komplexitást, a gondos tervezés, a szigorú tesztelés és a folyamatos monitoring segítségével Ön is a mestere lehet a Kubernetes erőforrás-kezelésének, és egy truly optimalizált infrastruktúrát hozhat létre.

Ne feledje, a kulcs a megfelelő egyensúly megtalálása az alapértelmezett beállítások egyszerűsége és a testreszabott megoldások ereje között. Ismerje meg alaposan igényeit, és válassza ki a legmegfelelőbb megközelítést a Kubernetes scheduler testreszabásához!