Wrth ddechrau gyda Kubernetes, mae'n gyffredin anghofio am sefydlu adnoddau cynhwysydd. Ar y pwynt hwn, mae'n ddigon i sicrhau bod delwedd y Docker yn gweithio ac y gellir ei defnyddio i glwstwr Kubernetes.
Ond yn ddiweddarach mae angen defnyddio'r cais mewn clwstwr cynhyrchu ynghyd â chymwysiadau eraill. I wneud hyn, mae angen i chi ddyrannu adnoddau ar gyfer y cynhwysydd a gwneud yn siŵr bod digon ohonynt i gael y cais ar waith, ac na fydd rhaglenni rhedeg eraill yn cael problemau.
Tîm cyfieithu erthygl am adnoddau cynhwysydd (CPU & MEM), ceisiadau a chyfyngiadau adnoddau. Byddwch yn dysgu manteision y gosodiadau hyn a beth sy'n digwydd os na fyddwch yn eu gosod.
Adnoddau cyfrifiadurol
Mae gennym ddau fath o adnoddau gyda'r unedau canlynol:
- Uned brosesu ganolog (CPU) - creiddiau;
- Cof (MEM) - beit.
Nodir adnoddau ar gyfer pob cynhwysydd. Yn y ffeil Pod YAML ganlynol, fe welwch adran adnoddau sy'n cynnwys yr adnoddau y gofynnwyd amdanynt a chyfyngiadau:
- Adnoddau Pod Gofynnol = swm yr adnoddau y gofynnwyd amdanynt o'r holl gynwysyddion;
- Terfyn Adnoddau Pod = Swm yr holl Derfynau Adnoddau Pod.
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: 1GiEnghraifft o Adnoddau Gofynnol a Chyfyngedig
Maes resources.requested o'r fanyleb Mae pod yn un o'r elfennau a ddefnyddir i ddod o hyd i'r nod a ddymunir. Gallwch chi eisoes gynllunio defnydd Pod ar ei gyfer. Sut ydych chi'n dod o hyd i nod addas?
Mae Kubernetes yn cynnwys sawl cydran, gan gynnwys prif nod neu brif nod (Kubernetes Control Plane). Mae gan y prif nod sawl proses: kube-apiserver, kube-controller-rheolwr a kube-scheduler.
Mae'r broses kube-scheduler yn gyfrifol am adolygu codennau sydd newydd eu creu a dod o hyd i nodau gweithiwr posibl sy'n cyfateb i bob cais am god, gan gynnwys nifer yr adnoddau y gofynnir amdanynt. Mae'r rhestr o nodau a ddarganfuwyd gan kube-scheduler wedi'i rhestru. Mae'r pod wedi'i amserlennu ar y nod gyda'r sgoriau uchaf.
Ble bydd y Pod piws yn cael ei osod?
Yn y llun gallwch weld y dylai kube-scheduler amserlennu Pod porffor newydd. Mae clwstwr Kubernetes yn cynnwys dau nod: A a B. Fel y gwelwch, ni all kube-scheduler amserlennu Pod ar nod A - nid yw'r adnoddau sydd ar gael (heb eu gofyn) yn cyfateb i geisiadau'r Pod porffor. Felly, ni fydd yr 1 GB o gof y gofynnir amdano gan y Pod porffor yn ffitio ar nod A, gan mai 0,5 GB yw'r cof sydd ar gael. Ond mae gan nod B ddigon o adnoddau. O ganlyniad, mae kube-scheduler yn penderfynu mai nod B yw cyrchfan y Pod porffor.
Nawr rydyn ni'n gwybod sut mae'r adnoddau y gofynnwyd amdanynt yn effeithio ar y dewis o nod i redeg y Pod. Ond beth yw effaith adnoddau ymylol?
Mae'r terfyn adnoddau yn ffin na all y CPU/MEM ei chroesi. Fodd bynnag, mae'r adnodd CPU yn hyblyg, felly ni fydd cynwysyddion sy'n cyrraedd eu terfynau CPU yn achosi i'r Pod ymadael. Yn lle hynny, bydd throtling CPU yn dechrau. Os cyrhaeddir y terfyn defnydd MEM, bydd y cynhwysydd yn cael ei stopio oherwydd OOM-Killer a'i ailgychwyn os caniateir gan y gosodiad RestartPolicy.
Yr adnoddau y gofynnwyd amdanynt a'r adnoddau mwyaf posibl yn fanwl
Cyfathrebu adnoddau rhwng Docker a Kubernetes
Y ffordd orau o esbonio sut mae ceisiadau am adnoddau a chyfyngiadau adnoddau yn gweithio yw cyflwyno'r berthynas rhwng Kubernetes a Docker. Yn y ddelwedd uchod gallwch weld sut mae meysydd Kubernetes a baneri cychwyn Docker yn gysylltiedig.
Cof: cais a chyfyngiad
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Fel y soniwyd uchod, mae cof yn cael ei fesur mewn beit. Yn seiliedig ar , gallwn nodi cof fel rhif. Fel arfer mae'n gyfanrif, er enghraifft 2678 - hynny yw, 2678 beit. Gallwch hefyd ddefnyddio ôl-ddodiaid G и Gi, y prif beth yw cofio nad ydynt yn gyfwerth. Mae'r cyntaf yn ddegol a'r ail yn ddeuaidd. Fel yr enghraifft a grybwyllir yn nogfennaeth k8s: 128974848, 129e6, 129M, 123Mi - maent yn cyfateb yn ymarferol.
Opsiwn Kubernetes limits.memory yn cyfateb i'r faner --memory o Docker. Rhag ofn request.memory Nid oes saeth ar gyfer Docker oherwydd nid yw Docker yn defnyddio'r maes hwn. Efallai y byddwch yn gofyn, a yw hyn hyd yn oed yn angenrheidiol? Oes angen. Fel y dywedais o'r blaen, mae'r maes yn bwysig i Kubernetes. Yn seiliedig ar y wybodaeth ohono, mae kube-scheduler yn penderfynu pa nod i amserlennu'r Pod.
Beth sy'n digwydd os byddwch chi'n gosod cof annigonol ar gyfer cais?
Os yw'r cynhwysydd wedi cyrraedd terfynau'r cof y gofynnwyd amdano, yna rhoddir y Pod mewn grŵp o Godennau sy'n stopio pan nad oes digon o gof yn y nod.
Beth sy'n digwydd os ydych chi'n gosod terfyn y cof yn rhy isel?
Os yw'r cynhwysydd yn fwy na'r terfyn cof, bydd yn cael ei derfynu oherwydd OOM-Killed. A bydd yn ailgychwyn os yn bosibl yn seiliedig ar RestartPolicy lle mae'r gwerth diofyn Always.
Beth sy'n digwydd os na fyddwch chi'n nodi'r cof y gofynnwyd amdano?
Bydd Kubernetes yn cymryd y gwerth terfyn a'i osod fel y gwerth diofyn.
Beth all ddigwydd os na fyddwch chi'n nodi terfyn cof?
Nid oes unrhyw gyfyngiadau ar y cynhwysydd; gall ddefnyddio cymaint o gof ag y mae ei eisiau. Os bydd yn dechrau defnyddio'r holl gof sydd ar gael o'r nod, yna bydd OOM yn ei ladd. Yna bydd y cynhwysydd yn cael ei ailgychwyn os yn bosibl yn seiliedig ar RestartPolicy.
Beth sy'n digwydd os na fyddwch chi'n nodi terfynau cof?
Dyma'r sefyllfa waethaf: nid yw'r trefnydd yn gwybod faint o adnoddau sydd eu hangen ar y cynhwysydd, a gall hyn achosi problemau difrifol ar y nod. Yn yr achos hwn, byddai'n braf cael terfynau diofyn ar y gofod enw (a osodwyd gan LimitRange). Nid oes unrhyw derfynau rhagosodedig - nid oes gan y Pod unrhyw derfynau, gall ddefnyddio cymaint o gof ag y mae ei eisiau.
Os yw'r cof y gofynnwyd amdano yn fwy nag y gall y nod ei gynnig, ni fydd y Pod yn cael ei amserlennu. Mae’n bwysig cofio hynny Requests.memory - nid y gwerth lleiaf. Mae hwn yn ddisgrifiad o faint o gof sy'n ddigonol i gadw'r cynhwysydd i redeg yn barhaus.
Fel arfer argymhellir gosod yr un gwerth ar gyfer request.memory и limit.memory. Mae hyn yn sicrhau na fydd Kubernetes yn amserlennu Pod ar nod sydd â digon o gof i redeg y Pod ond dim digon i'w redeg. Cadwch mewn cof: Mae cynllunio Kubernetes Pod yn cymryd i ystyriaeth yn unig requests.memoryAc limits.memory nid yw'n cymryd i ystyriaeth.
CPU: cais a therfyn
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Gyda CPU mae popeth ychydig yn fwy cymhleth. Gan ddychwelyd at y llun o'r berthynas rhwng Kubernetes a Docker, gallwch weld hynny request.cpu соответствуетт --cpu-shares, tra limit.cpu yn cyfateb i'r faner cpus yn Docker.
Mae'r CPU y mae Kubernetes yn gofyn amdano yn cael ei luosi â 1024, sef cyfran y cylchoedd CPU. Os ydych chi am ofyn am 1 craidd llawn, rhaid i chi ychwanegu cpu: 1fel y dangosir uchod.
Nid yw gofyn am gnewyllyn llawn (cyfran = 1024) yn golygu y bydd eich cynhwysydd yn ei dderbyn. Os mai dim ond un craidd sydd gan eich peiriant gwesteiwr a'ch bod yn rhedeg mwy nag un cynhwysydd, yna rhaid i bob cynhwysydd rannu'r CPU sydd ar gael rhyngddynt. Sut mae hyn yn digwydd? Gadewch i ni edrych ar y llun.
Cais CPU - System Graidd Sengl
Gadewch i ni ddychmygu bod gennych system cynnal un craidd yn rhedeg cynwysyddion. Pobodd mam (Kubernetes) bastai (CPU) ac mae eisiau ei rannu rhwng plant (cynwysyddion). Mae tri phlentyn eisiau pastai gyfan (cyfran = 1024), mae plentyn arall eisiau hanner pastai (512). Mae mam eisiau bod yn deg ac yn gwneud cyfrifiad syml.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Yn seiliedig ar y cyfrifiad, bydd tri phlentyn yn derbyn 28% o'r craidd, ac nid y craidd cyfan. Bydd y pedwerydd plentyn yn cael 14% o'r cnewyllyn llawn, nid hanner. Ond bydd pethau'n wahanol os oes gennych chi system aml-graidd.
Cais CPU - System Aml-Graidd (4).
Yn y ddelwedd uchod gallwch weld bod tri phlentyn eisiau pastai gyfan, ac mae un eisiau hanner. Ers i fam bobi pedair peis, bydd pob un o'i phlant yn cael cymaint ag y dymunant. Mewn system aml-graidd, mae adnoddau prosesydd yn cael eu dosbarthu ar draws yr holl greiddiau prosesydd sydd ar gael. Os yw cynhwysydd wedi'i gyfyngu i lai nag un craidd CPU llawn, gall ei ddefnyddio o hyd ar 100%.
Mae'r cyfrifiadau uchod yn cael eu symleiddio i ddeall sut mae CPU yn cael ei ddosbarthu ymhlith cynwysyddion. Wrth gwrs, ar wahân i'r cynwysyddion eu hunain, mae yna brosesau eraill sydd hefyd yn defnyddio adnoddau CPU. Pan fydd prosesau mewn un cynhwysydd yn segur, gall eraill ddefnyddio ei adnodd. CPU: "200m" соответствуетт CPU: 0,2, sy'n golygu tua 20% o un craidd.
Nawr gadewch i ni siarad am limit.cpu. Mae'r CPU y mae Kubernetes yn ei gyfyngu yn cael ei luosi â 100. Y canlyniad yw faint o amser y gall y cynhwysydd ei ddefnyddio bob 100 µs (cpu-period).
limit.cpu yn cyfateb i faner y Docker --cpus. Mae hwn yn gyfuniad newydd o hen --cpu-period и --cpu-quota. Trwy ei osod, rydym yn nodi faint o adnoddau CPU sydd ar gael y gall y cynhwysydd eu defnyddio i'r eithaf cyn i'r sbardun ddechrau:
- cpus - cyfuniad
cpu-periodиcpu-quota. cpus = 1.5cyfateb i osodiadcpu-period = 100000иcpu-quota = 150000; - CPU-cyfnod - cyfnod , rhagosodedig 100 microseconds;
- cpu-cwota - nifer y microseconds y tu mewn
cpu-period, sydd wedi'i ffinio gan y cynhwysydd.
Beth sy'n digwydd os ydych chi'n gosod CPU annigonol y gofynnwyd amdano?
Os oes angen mwy ar y cynhwysydd nag y mae wedi'i osod, bydd yn dwyn CPU o brosesau eraill.
Beth sy'n digwydd os ydych chi'n gosod terfyn y CPU yn rhy isel?
Gan fod yr adnodd CPU yn addasadwy, bydd throtling yn troi ymlaen.
Beth sy'n digwydd os na fyddwch yn nodi cais CPU?
Fel gyda'r cof, mae gwerth y cais yn hafal i'r terfyn.
Beth sy'n digwydd os na fyddwch chi'n nodi terfyn CPU?
Bydd y cynhwysydd yn defnyddio cymaint o CPU ag sydd ei angen. Os diffinnir polisi CPU rhagosodedig (LimitRange) yn y gofod enw, yna defnyddir y terfyn hwn hefyd ar gyfer y cynhwysydd.
Beth sy'n digwydd os na fyddwch yn nodi naill ai cais neu derfyn CPU?
Fel gyda'r cof, dyma'r senario waethaf. Nid yw'r trefnydd yn gwybod faint o adnoddau sydd eu hangen ar eich cynhwysydd, a gall hyn achosi problemau difrifol ar y nod. Er mwyn osgoi hyn, mae angen i chi osod terfynau rhagosodedig ar gyfer bylchau enw (LimitRange).
Cofiwch: os gofynnwch am fwy o CPU nag y gall y nodau ei ddarparu, ni fydd y Pod yn cael ei amserlennu. Requests.cpu - nid y gwerth lleiaf, ond gwerth sy'n ddigonol i gychwyn y Pod a gweithio heb fethiannau. Os nad yw'r cais yn perfformio cyfrifiadau cymhleth, yr opsiwn gorau yw gosod request.cpu <= 1 a lansio cymaint o atgynyrchiadau ag sydd angen.
Swm delfrydol o adnoddau y gofynnir amdanynt neu derfyn adnoddau
Dysgon ni am y cyfyngiad ar adnoddau cyfrifiadurol. Nawr mae'n bryd ateb y cwestiwn: “Faint o adnoddau sydd eu hangen ar fy Pod i redeg y rhaglen heb unrhyw broblemau? Beth yw'r swm delfrydol?
Yn anffodus, nid oes atebion clir i'r cwestiynau hyn. Os nad ydych chi'n gwybod sut mae'ch cais yn gweithio na faint o CPU neu gof sydd ei angen arno, yr opsiwn gorau yw rhoi llawer o gof a CPU i'r cais ac yna rhedeg profion perfformiad.
Yn ogystal â phrofion perfformiad, monitro ymddygiad y cais wrth fonitro am wythnos. Os yw'r graffiau'n dangos bod eich cais yn defnyddio llai o adnoddau nag y gofynnoch chi, gallwch leihau faint o CPU neu gof y gofynnwyd amdano.
Fel enghraifft gweler hyn . Mae'n dangos y gwahaniaeth rhwng yr adnoddau y gofynnwyd amdanynt neu'r terfyn adnoddau a'r defnydd presennol o adnoddau.
Casgliad
Mae gofyn a chyfyngu ar adnoddau yn helpu i gadw'ch clwstwr Kubernetes yn iach. Mae cyfluniad terfyn cywir yn lleihau costau ac yn cadw cymwysiadau i redeg bob amser.
Yn fyr, mae yna ychydig o bethau i'w cadw mewn cof:
- Mae'r adnoddau y gofynnir amdanynt yn gyfluniad sy'n cael ei ystyried ar yr amser cychwyn (pan fydd Kubernetes yn bwriadu cynnal y cais). Mewn cyferbyniad, mae cyfyngu adnoddau yn bwysig yn ystod amser rhedeg - pan fydd y cymhwysiad eisoes yn rhedeg ar y nod.
- O'i gymharu â'r cof, mae'r CPU yn adnodd rheoledig. Os nad oes digon o CPU, ni fydd eich Pod yn cau a bydd y mecanwaith sbardun yn troi ymlaen.
- Nid yw'r adnoddau y gofynnir amdanynt a'r terfyn adnoddau yn werthoedd gofynnol ac uchaf! Trwy ddiffinio'r adnoddau y gofynnir amdanynt, rydych chi'n sicrhau y bydd y rhaglen yn rhedeg heb unrhyw broblemau.
- Arfer da yw gosod y cais cof yn gyfartal â therfyn y cof.
- Gofyn am osod iawn
CPU <=1, os nad yw'r cais yn perfformio cyfrifiadau cymhleth. - Os gofynnwch am fwy o adnoddau nag sydd ar gael ar nod, ni fydd y Pod byth yn cael ei amserlennu i'r nod hwnnw.
- I bennu'r swm cywir o adnoddau/cyfyngiadau adnoddau y gofynnir amdanynt, defnyddiwch brofion llwyth a monitro.
Rwy'n gobeithio y bydd yr erthygl hon yn eich helpu i ddeall y cysyniad sylfaenol o gyfyngu ar adnoddau. A byddwch yn gallu cymhwyso'r wybodaeth hon yn eich gwaith.
Pob lwc!
Beth arall i'w ddarllen:
- .
- .
- .
Ffynhonnell: hab.com