A Kubernetes használatának megkezdésekor gyakran megfeledkeznek a tárolóerőforrások beállításáról. Ezen a ponton elég gondoskodni arról, hogy a Docker-kép működik, és telepíthető legyen a Kubernetes-fürtben.
Később azonban az alkalmazást más alkalmazásokkal együtt egy éles fürtben kell üzembe helyezni. Ehhez erőforrásokat kell lefoglalnia a tárolóhoz, és meg kell győződnie arról, hogy elegendő belőlük van-e az alkalmazás üzembe helyezéséhez és futtatásához, valamint hogy a többi futó alkalmazásnál nem lesz probléma.
Csapat lefordított egy cikket a tárolóerőforrásokról (CPU és MEM), a kérésekről és az erőforrás-korlátozásokról. Megismerheti ezen beállítások előnyeit és azt, hogy mi történik, ha nem állítja be őket.
Számítástechnikai erőforrások
Kétféle erőforrásunk van a következő egységekkel:
- Központi feldolgozó egység (CPU) - magok;
- Memória (MEM) - bájtok.
Az erőforrások minden tárolóhoz meg vannak adva. A következő Pod YAML fájlban egy erőforrásszakasz jelenik meg, amely tartalmazza a kért és korlátozott erőforrásokat:
- Requested Pod Resources = az összes tároló kért erőforrásainak összege;
- Pod erőforrás korlát = az összes pod erőforrás korlát összege.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiPélda a kért és korlátozott erőforrásokra
Mező resources.requested a specifikációból A Pod az egyik elem, amely a kívánt csomópont megtalálására szolgál. Már meg is tervezheti a Pod telepítését. Hogyan találhat megfelelő csomópontot?
A Kubernetes több összetevőből áll, köztük egy főcsomópontból vagy egy főcsomópontból (Kubernetes Control Plane). A fő csomópontnak több folyamata van: kube-apiserver, kube-controller-manager és kube-scheduler.
A kube-ütemező folyamat felelős az újonnan létrehozott sorba rendezések áttekintéséért és az összes podkérésnek megfelelő munkavégző csomópontok megtalálásáért, beleértve a kért erőforrások számát is. A kube-scheduler által talált csomópontok listája rangsorolva van. A pod a legmagasabb pontszámot elérő csomóponton van ütemezve.
Hol lesz elhelyezve a lila tok?
A képen látható, hogy a kube-ütemezőnek új lila Podot kell ütemeznie. A Kubernetes-fürt két csomópontot tartalmaz: A-t és B-t. Mint látható, a kube-ütemező nem tud ütemezést ütemezni az A csomóponton – a rendelkezésre álló (nem kért) erőforrások nem egyeznek a lila Pod kéréseivel. Tehát a lila Pod által kért 1 GB memória nem fér el az A csomóponton, mivel a rendelkezésre álló memória 0,5 GB. De a B csomópontnak elegendő erőforrása van. Ennek eredményeként a kube-ütemező úgy dönt, hogy a lila Pod rendeltetési helye a B csomópont.
Most már tudjuk, hogy a kért erőforrások hogyan befolyásolják a Pod futtatásához szükséges csomópont kiválasztását. De mi a hatása a marginális erőforrásoknak?
Az erőforráskorlát egy olyan határ, amelyet a CPU/MEM nem léphet át. A CPU-erőforrás azonban rugalmas, így a CPU-korlátokat elérő tárolók nem okozzák a Pod kilépését. Ehelyett elindul a CPU-szabályozás. Ha eléri a MEM-használati korlátot, a tároló leáll az OOM-Killer miatt, és újraindul, ha a RestartPolicy beállítása lehetővé teszi.
A kért és maximális erőforrások részletesen
Erőforrás-kommunikáció a Docker és a Kubernetes között
A kért és erőforrás-korlátok működésének elmagyarázásának legjobb módja a Kubernetes és a Docker közötti kapcsolat bemutatása. A fenti képen láthatja, hogy a Kubernetes mezők és a Docker indítási jelzői hogyan kapcsolódnak egymáshoz.
Memória: kérés és korlátozás
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Mint fentebb említettük, a memória mérése bájtokban történik. Alapján , megadhatjuk a memóriát számként. Általában ez egy egész szám, például 2678 - azaz 2678 bájt. Használhat utótagokat is G и Gi, a legfontosabb az, hogy ne feledje, hogy nem egyenértékűek. Az első decimális, a második pedig bináris. Mint a k8s dokumentációjában említett példa: 128974848, 129e6, 129M, 123Mi - gyakorlatilag egyenértékűek.
Kubernetes opció limits.memory megegyezik a zászlóval --memory a Dockertől. Esetében request.memory Nincs nyíl a Docker számára, mert a Docker nem használja ezt a mezőt. Kérdezheti, hogy ez egyáltalán szükséges? Igen kell. Ahogy korábban mondtam, Kubernetes számára a mezőny számít. Az ebből származó információk alapján a kube-ütemező eldönti, hogy melyik csomópont ütemezi a Pod-ot.
Mi történik, ha nem állít be elegendő memóriát egy kéréshez?
Ha a tároló elérte a kért memória korlátait, akkor a Pod a Pod-ok csoportjába kerül, amelyek leállnak, ha nincs elég memória a csomópontban.
Mi történik, ha túl alacsonyra állítja a memóriakorlátot?
Ha a tároló túllépi a memóriakorlátot, az OOM-Killed miatt leáll. És ha lehetséges, újraindul a RestartPolicy alapján, ahol az alapértelmezett érték Always.
Mi történik, ha nem adja meg a kért memóriát?
A Kubernetes felveszi a határértéket, és beállítja alapértelmezett értékként.
Mi történhet, ha nem ad meg memóriakorlátot?
A tárolónak nincsenek korlátozásai; annyi memóriát használhat, amennyit csak akar. Ha elkezdi használni a csomópont összes rendelkezésre álló memóriáját, akkor az OOM megöli. A tároló ezután újraindul, ha lehetséges a RestartPolicy alapján.
Mi történik, ha nem ad meg memóriakorlátokat?
Ez a legrosszabb forgatókönyv: az ütemező nem tudja, mennyi erőforrást igényel a tároló, és ez komoly problémákat okozhat a csomóponton. Ebben az esetben jó lenne, ha alapértelmezett korlátok lennének a névtérben (a LimitRange által beállított). Nincsenek alapértelmezett korlátok – a Pod-nak nincsenek korlátai, annyi memóriát használhat, amennyit csak akar.
Ha a kért memória több, mint amennyit a csomópont kínálni tud, a Pod nem lesz ütemezve. Ezt fontos megjegyezni Requests.memory - nem a minimális érték. Ez a tároló folyamatos működéséhez elegendő memória mennyiségének leírása.
Általában ajánlott ugyanazt az értéket beállítani request.memory и limit.memory. Ez biztosítja, hogy a Kubernetes ne ütemezzen ütemezést egy olyan csomóponton, amely elegendő memóriával rendelkezik a Pod futtatásához, de nem elegendő a futtatásához. Ne feledje: a Kubernetes Pod tervezése csak akkor veszi figyelembe requests.memoryÉs limits.memory nem veszi figyelembe.
CPU: kérés és korlát
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
CPU-val minden kicsit bonyolultabb. Visszatérve a Kubernetes és Docker kapcsolatának képére, láthatjuk request.cpu megfelel a --cpu-shares, mivel limit.cpu megegyezik a zászlóval cpus a Dockerben.
A Kubernetes által kért CPU-t megszorozzák 1024-gyel, a CPU-ciklusok arányával. Ha 1 teljes magot szeretne kérni, akkor hozzá kell adnia cpu: 1ahogy fentebb látható.
A teljes kernel kérése (arány = 1024) nem jelenti azt, hogy a tároló megkapja azt. Ha a gazdagépnek csak egy magja van, és egynél több tárolót futtat, akkor minden tárolónak meg kell osztania a rendelkezésre álló CPU-t. Hogyan történik ez? Nézzük a képet.
CPU-kérés – egymagos rendszer
Képzeljük el, hogy van egy egymagos gazdagépe, amely konténereket futtat. Anya (Kubernetes) pitét (CPU) sütött, és szeretné szétosztani a gyerekek között (konténerek). Három gyerek egy egész pitét akar (arány = 1024), egy másik gyerek egy fél pitét (512). Anya igazságos akar lenni, és egyszerű számítást végez.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%A számítás alapján három gyerek a mag 28%-át kapja, és nem a teljes magot. A negyedik gyermek a teljes kernel 14%-át kapja, nem a felét. De minden más lesz, ha többmagos rendszered van.
CPU-kérés – többmagos (4) rendszer
A fenti képen látható, hogy három gyerek egy egész pitét akar, egy pedig a felét. Mivel anya négy pitét sütött, minden gyermeke annyit kap, amennyit akar. A többmagos rendszerekben a processzorerőforrások az összes elérhető processzormag között vannak elosztva. Ha egy tároló egynél kevesebb teljes CPU magra van korlátozva, akkor is 100%-osan tudja használni.
A fenti számításokat leegyszerűsítettük, hogy megértsük, hogyan oszlik meg a CPU a tárolók között. Természetesen a konténereken kívül vannak más folyamatok is, amelyek szintén CPU erőforrásokat használnak. Amikor az egyik tárolóban lévő folyamatok tétlenek, mások használhatják az erőforrást. CPU: "200m" megfelel a CPU: 0,2, ami egy mag körülbelül 20%-át jelenti.
Most beszéljünk róla limit.cpu. A Kubernetes által korlátozott CPU-t megszorozzák 100-zal. Az eredmény az az idő, ameddig a tároló 100 µs-onként használhatja (cpu-period).
limit.cpu megegyezik a Docker zászlóval --cpus. Ez a régi új kombinációja --cpu-period и --cpu-quota. Beállításával jelezzük, hogy a tároló hány rendelkezésre álló CPU-erőforrást tud maximálisan felhasználni a szabályozás megkezdése előtt:
- CPU - kombináció
cpu-periodиcpu-quota. cpus = 1.5beállítással egyenértékűcpu-period = 100000иcpu-quota = 150000; - CPU-periódus - időszak , alapértelmezett 100 mikroszekundum;
- cpu-kvóta - belüli mikroszekundumok száma
cpu-period, amelyet a konténer határol.
Mi történik, ha nem telepít elég kért CPU-t?
Ha a tárolónak többre van szüksége, mint amennyit telepített, akkor ellopja a CPU-t más folyamatoktól.
Mi történik, ha túl alacsonyra állítja a CPU-korlátot?
Mivel a CPU erőforrása állítható, a fojtás bekapcsol.
Mi történik, ha nem ad meg CPU kérést?
Akárcsak a memória esetében, a kérés értéke megegyezik a korláttal.
Mi történik, ha nem ad meg CPU-korlátot?
A tároló annyi CPU-t használ, amennyire szüksége van. Ha egy alapértelmezett CPU-házirend (LimitRange) van megadva a névtérben, akkor ez a korlát a tárolóhoz is használatos.
Mi történik, ha nem ad meg sem kérést, sem CPU-korlátot?
Akárcsak a memória esetében, ez a legrosszabb forgatókönyv. Az ütemező nem tudja, hány erőforrásra van szüksége a tárolónak, és ez komoly problémákat okozhat a csomóponton. Ennek elkerülése érdekében alapértelmezett korlátokat kell beállítania a névterekre (LimitRange).
Ne feledje: ha több CPU-t kér, mint amennyit a csomópontok képesek biztosítani, a Pod nem lesz ütemezve. Requests.cpu - nem a minimális érték, hanem olyan érték, amely elegendő a Pod indításához és hibamentes működéséhez. Ha az alkalmazás nem végez összetett számításokat, a legjobb megoldás a telepítés request.cpu <= 1 és indítson el annyi replikát, amennyi szükséges.
Ideális mennyiségű kért erőforrás vagy erőforráskorlát
Megismertük a számítási erőforrások korlátozottságát. Most itt az ideje, hogy válaszoljunk a következő kérdésre: „Hány erőforrásra van szüksége a Pod-omnak az alkalmazás problémamentes futtatásához? Mi az ideális összeg?
Sajnos ezekre a kérdésekre nincs egyértelmű válasz. Ha nem tudja, hogyan működik az alkalmazás, vagy mennyi CPU-ra vagy memóriára van szüksége, a legjobb megoldás, ha sok memóriát és CPU-t ad az alkalmazásnak, majd teljesítményteszteket futtat.
A teljesítményteszteken kívül egy hétig figyelje az alkalmazás viselkedését a megfigyelés során. Ha a grafikonok azt jelzik, hogy az alkalmazás kevesebb erőforrást fogyaszt, mint amennyit kért, csökkentheti a igényelt CPU vagy memória mennyiségét.
Példaként lásd ezt . Megjeleníti a kért erőforrások vagy erőforráskorlátok és az aktuális erőforráshasználat közötti különbséget.
Következtetés
Az erőforrások igénylése és korlátozása segít megőrizni a Kubernetes-fürt egészségét. A limit megfelelő beállítása minimalizálja a költségeket, és folyamatosan futnak az alkalmazások.
Röviden, néhány dolgot érdemes szem előtt tartani:
- A kért erőforrások olyan konfigurációk, amelyeket a rendszer az indításkor figyelembe vesz (amikor a Kubernetes az alkalmazást tervezi tárolni). Ezzel szemben az erőforrások korlátozása fontos futásidőben – amikor az alkalmazás már fut a csomóponton.
- A memóriához képest a CPU szabályozott erőforrás. Ha nincs elég CPU, a Pod nem kapcsol le, és a fojtómechanizmus bekapcsol.
- Az igényelt erőforrások és forráskorlátok nem minimum és maximum értékek! A kért erőforrások meghatározásával biztosítja, hogy az alkalmazás problémamentesen fusson.
- Jó gyakorlat, ha a memóriakérést a memóriakorláttal egyenlőnek állítja be.
- Rendben telepítés kért
CPU <=1, ha az alkalmazás nem végez összetett számításokat. - Ha több erőforrást kér, mint amennyi egy csomóponton elérhető, a Pod soha nem lesz ütemezve ahhoz a csomóponthoz.
- A kért erőforrások/erőforráskorlátok megfelelő mennyiségének meghatározásához használja a terhelési tesztelést és a figyelést.
Remélem, ez a cikk segít megérteni az erőforrás-korlátozás alapvető fogalmát. És ezt a tudást a munkád során is alkalmazni tudod majd.
Sok szerencsét!
Mit kell még olvasni:
- .
- .
- .
Forrás: will.com