Fel rheol, mae bob amser angen darparu cronfa benodol o adnoddau ar gyfer cais i'w weithredu'n gywir a sefydlog. Ond beth os yw sawl cais yn rhedeg ar yr un pŵer? Sut i ddarparu'r adnoddau lleiaf angenrheidiol i bob un ohonynt? Sut allwch chi gyfyngu ar y defnydd o adnoddau? Sut i ddosbarthu'r llwyth rhwng nodau yn gywir? Sut i sicrhau bod y mecanwaith graddio llorweddol yn gweithio os yw llwyth y cais yn cynyddu?
Mae angen i chi ddechrau gyda'r prif fathau o adnoddau sy'n bodoli yn y system - mae hyn, wrth gwrs, yn amser prosesydd a RAM. Mewn maniffestau k8s caiff y mathau hyn o adnoddau eu mesur yn yr unedau canlynol:
- CPU - mewn creiddiau
- RAM - mewn beit
Ar ben hynny, ar gyfer pob adnodd mae'n bosibl gosod dau fath o ofyniad - ceisiadau и terfynau. Ceisiadau - yn disgrifio'r gofynion sylfaenol ar gyfer adnoddau rhad ac am ddim o nod i redeg cynhwysydd (a pod yn ei gyfanrwydd), tra bod terfynau yn gosod terfyn caled ar yr adnoddau sydd ar gael i'r cynhwysydd.
Mae'n bwysig deall nad oes rhaid i'r maniffest ddiffinio'r ddau fath yn benodol, ond bydd yr ymddygiad fel a ganlyn:
- Os mai dim ond terfynau adnodd sydd wedi'u nodi'n benodol, yna mae ceisiadau am yr adnodd hwn yn awtomatig yn cymryd gwerth sy'n hafal i derfynau (gallwch wirio hyn trwy ffonio disgrifiwch endidau). Y rhai. mewn gwirionedd, bydd y cynhwysydd yn gyfyngedig i'r un faint o adnoddau y mae eu hangen i redeg.
- Os mai dim ond ceisiadau a nodir yn benodol am adnodd, yna ni osodir unrhyw gyfyngiadau uchaf ar yr adnodd hwn - h.y. mae'r cynhwysydd wedi'i gyfyngu gan adnoddau'r nod ei hun yn unig.
Mae hefyd yn bosibl ffurfweddu rheolaeth adnoddau nid yn unig ar lefel cynhwysydd penodol, ond hefyd ar lefel gofod enw gan ddefnyddio'r endidau canlynol:
- Amrediad Terfyn — yn disgrifio’r polisi cyfyngu ar lefel y cynhwysydd/pod mewn ns ac sydd ei angen er mwyn disgrifio’r terfynau rhagosodedig ar y cynhwysydd/pod, yn ogystal ag atal creu cynwysyddion/podiau sy’n amlwg yn dew (neu i’r gwrthwyneb), cyfyngu ar eu nifer a phennu'r gwahaniaeth posibl yn y gwerthoedd mewn terfynau a cheisiadau
- Cwotâu Adnoddau — disgrifiwch y polisi cyfyngu yn gyffredinol ar gyfer pob cynhwysydd mewn ns ac fe'i defnyddir, fel rheol, i gyfyngu ar adnoddau ymhlith amgylcheddau (defnyddiol pan nad yw amgylcheddau wedi'u diffinio'n llym ar lefel y nodau)
Mae'r canlynol yn enghreifftiau o faniffestau sy'n gosod terfynau adnoddau:
-
Ar lefel cynhwysydd penodol:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mY rhai. yn yr achos hwn, i redeg cynhwysydd gyda nginx, bydd angen o leiaf 1G o RAM am ddim a 0.2 CPU ar y nod, tra ar y mwyaf gall y cynhwysydd ddefnyddio 0.2 CPU a'r holl RAM sydd ar gael ar y nod.
-
Ar lefel cyfanrif ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiY rhai. ni all swm yr holl gynwysyddion cais yn yr ns rhagosodedig fod yn fwy na 300m ar gyfer y CPU ac 1G ar gyfer yr OP, a swm yr holl derfyn yw 700m ar gyfer y CPU a 2G ar gyfer yr OP.
-
Terfynau rhagosodedig ar gyfer cynwysyddion yn ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4GiY rhai. yn y gofod enw rhagosodedig ar gyfer pob cynhwysydd, bydd y cais yn cael ei osod i 100m ar gyfer CPU ac 1G ar gyfer OP, terfyn - 1 CPU a 2G. Ar yr un pryd, gosodir terfyn hefyd ar y gwerthoedd posibl yn y cais / terfyn ar gyfer CPU (50m < x < 2) a RAM (500M < x < 4G).
-
Cyfyngiadau lefel pod ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiY rhai. ar gyfer pob pod yn yr ns rhagosodedig bydd terfyn o 4 vCPU ac 1G.
Nawr hoffwn ddweud wrthych pa fanteision y gall gosod y cyfyngiadau hyn eu rhoi inni.
Mecanwaith cydbwyso llwyth rhwng nodau
Fel y gwyddoch, mae'r gydran k8s yn gyfrifol am ddosbarthu codennau ymhlith nodau, megis trefnwr, sy'n gweithio yn unol ag algorithm penodol. Mae'r algorithm hwn yn mynd trwy ddau gam wrth ddewis y nod gorau posibl i'w lansio:
- hidlo
- Amrediad
Y rhai. yn ôl y polisi a ddisgrifir, dewisir nodau i ddechrau lle mae'n bosibl lansio pod yn seiliedig ar set rhagfynegi (gan gynnwys gwirio a oes gan y nod ddigon o adnoddau i redeg y pod - PodFitsResources), ac yna ar gyfer pob un o'r nodau hyn, yn ôl blaenoriaethau pwyntiau a ddyfernir (gan gynnwys, po fwyaf o adnoddau rhydd sydd gan nod, y mwyaf o bwyntiau a roddir iddo - DyraniadAdnodd Lleiaf/Blaenoriaeth y Cais Lleiaf/DyraniadAdnodd Cytbwys) a chaiff y pod ei lansio ar y nod gyda’r mwyaf o bwyntiau (os yw sawl nod yn bodloni’r amod hwn ar unwaith, yna dewisir un ar hap).
Ar yr un pryd, mae angen i chi ddeall bod yr amserlennydd, wrth asesu'r adnoddau sydd ar gael o nod, yn cael ei arwain gan y data sy'n cael ei storio yn ac ati - h.y. ar gyfer swm yr adnodd y gofynnwyd amdano/cyfyngiad ar gyfer pob pod sy'n rhedeg ar y nod hwn, ond nid ar gyfer y defnydd adnoddau gwirioneddol. Gellir cael y wybodaeth hon o'r allbwn gorchymyn kubectl describe node $NODE, er enghraifft:
# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d
kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d
nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d
nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d
nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 487m (3%) 822m (5%)
memory 15856217600 (2%) 749976320 (3%)
ephemeral-storage 0 (0%) 0 (0%)Yma gwelwn yr holl godennau'n rhedeg ar nod penodol, yn ogystal â'r adnoddau y mae pob pod yn gofyn amdanynt. A dyma sut olwg sydd ar logiau'r rhaglennydd pan fydd y pod cronjob-cron-events-1573793820-xt6q9 yn cael ei lansio (bydd y wybodaeth hon yn ymddangos yn y log amserlennwr pan fydd y lefel logio 10fed wedi'i gosod yn nadleuon y gorchymyn lansio -v=10 ):
log
I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.
I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.
I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.
I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.
I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.
I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.
I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9
I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8
I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9
I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8
I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037
I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034
I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037
I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"
I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do
I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10Yma gwelwn fod y rhaglennydd i ddechrau yn hidlo ac yn cynhyrchu rhestr o 3 nod y gellir ei lansio arnynt (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Yna mae'n cyfrifo sgoriau yn seiliedig ar sawl paramedr (gan gynnwys BalancedResourceAllocation, LeastResourceAllocation) ar gyfer pob un o'r nodau hyn er mwyn pennu'r nod mwyaf addas. Yn y pen draw, mae'r pod wedi'i drefnu ar y nod gyda'r nifer uchaf o bwyntiau (yma mae gan ddau nod ar unwaith yr un nifer o bwyntiau 100037, felly dewisir un ar hap - nxs-k8s-s10).
Allbwn: os yw nod yn rhedeg codennau nad oes unrhyw gyfyngiadau ar eu cyfer, yna ar gyfer k8s (o safbwynt y defnydd o adnoddau) bydd hyn yn cyfateb i fel pe na bai codennau o'r fath ar y nod hwn o gwbl. Felly, os oes gennych chi, yn amodol, god gyda phroses gluttonous (er enghraifft, wowza) ac nad oes unrhyw gyfyngiadau wedi'u gosod ar ei gyfer, yna gall sefyllfa godi pan fydd y pod hwn mewn gwirionedd yn bwyta holl adnoddau'r nod, ond ar gyfer k8s y nod hwn yn cael ei ystyried wedi'i ddadlwytho a bydd yn cael yr un nifer o bwyntiau wrth raddio (yn union mewn pwyntiau sy'n asesu'r adnoddau sydd ar gael) â nod nad oes ganddo godau gweithio, a all yn y pen draw arwain at ddosbarthiad anwastad yn y llwyth rhwng nodau.
Pod yn troi allan
Fel y gwyddoch, neilltuir un o 3 dosbarth QoS i bob pod:
- gwarantedig — yn cael ei neilltuo pan nodir cais a therfyn ar gyfer cof a cpu ar gyfer pob cynhwysydd yn y pod, a rhaid i'r gwerthoedd hyn gyfateb
- byrstable — mae gan o leiaf un cynhwysydd yn y pod gais a therfyn, gyda chais < terfyn
- ymdrech orau — pan nad yw un cynhwysydd yn y pod yn gyfyngedig o ran adnoddau
Ar yr un pryd, pan fydd nod yn profi diffyg adnoddau (disg, cof), mae kubelet yn dechrau graddio a dadfeddiannu codennau yn unol ag algorithm penodol sy'n ystyried blaenoriaeth y pod a'i ddosbarth QoS. Er enghraifft, os ydym yn sôn am RAM, yna yn seiliedig ar y dosbarth QoS, dyfernir pwyntiau yn ôl yr egwyddor ganlynol:
- Gwarantedig:-998
- Ymdrech Orau: 1000
- Byrstable: mun(uchafswm(2, 1000 - (1000 * cofRequestBytes) / peiriantMemoryCapacityBytes), 999)
Y rhai. gyda'r un flaenoriaeth, bydd y kubelet yn dadfeddiannu codennau yn gyntaf gyda'r ymdrech orau dosbarth QoS o'r nod.
Allbwn: os ydych chi am leihau'r tebygolrwydd y bydd y pod a ddymunir yn cael ei droi allan o'r nod os bydd diffyg adnoddau arno, yna ynghyd â'r flaenoriaeth, mae angen i chi hefyd ofalu am osod y cais / terfyn ar ei gyfer.
Mecanwaith ar gyfer graddoli awtomatig llorweddol o godennau cais (HPA)
Pan mai'r dasg yw cynyddu a lleihau'n awtomatig nifer y codennau yn dibynnu ar y defnydd o adnoddau (system - CPU/RAM neu ddefnyddiwr - rps), endid o'r fath k8s fel HPA (Awtoscaler Pod Llorweddol). Mae'r algorithm fel a ganlyn:
- Pennir darlleniadau cyfredol yr adnodd a arsylwyd (gwerth cyfredolMetrig)
- Mae'r gwerthoedd dymunol ar gyfer yr adnodd yn cael eu pennu (desiredMetricValue), sydd ar gyfer adnoddau system yn cael eu gosod gan ddefnyddio cais
- Pennir nifer presennol y copïau (Replicas Current)
- Mae'r fformiwla ganlynol yn cyfrifo'r nifer dymunol o atgynyrchiadau (dymunol Replicas)
DesireReplicas = [ currentReplicas * ( currentMetricValue / DesireMetricValue )]
Yn yr achos hwn, ni fydd graddio yn digwydd pan fydd y cyfernod (currentMetricValue / DesireMetricValue) yn agos at 1 (yn yr achos hwn, gallwn osod y gwall a ganiateir ein hunain; yn ddiofyn, 0.1 ydyw).
Gadewch i ni edrych ar sut mae hpa yn gweithio gan ddefnyddio enghraifft y cymhwysiad app-brawf (a ddisgrifir fel Defnyddio), lle mae angen newid nifer y copïau yn dibynnu ar ddefnydd CPU:
-
Maniffest y cais
kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-statusY rhai. gwelwn fod y pod cais yn cael ei lansio i ddechrau mewn dau achos, gyda phob un ohonynt yn cynnwys dau gynwysydd nginx a nginx-allforiwr, y mae pob un ohonynt yn cynnwys ceisiadau ar gyfer CPU.
-
Maniffesto HPA
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30Y rhai. Fe wnaethon ni greu hpa a fydd yn monitro'r app-brawf Defnyddio ac yn addasu nifer y codennau gyda'r cymhwysiad yn seiliedig ar y dangosydd cpu (rydym yn disgwyl y dylai'r pod ddefnyddio 30% o'r CPU y mae'n gofyn amdano), gyda nifer y atgynyrchiadau ynddo yr ystod o 2-10.
Nawr, gadewch i ni edrych ar fecanwaith gweithrediad hpa os ydyn ni'n rhoi llwyth ar un o'r aelwydydd:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Yn gyfan gwbl mae gennym y canlynol:
- Y gwerth a ddymunir (DeiredMetricValue) - yn ôl y gosodiadau hpa, mae gennym 30%
- Gwerth cyfredol (gwerth cyfredolMetrig) - ar gyfer cyfrifo, mae rheolwr-rheolwr yn cyfrifo gwerth cyfartalog y defnydd o adnoddau mewn %, h.y. yn amodol yn gwneud y canlynol:
- Yn derbyn gwerthoedd absoliwt metrigau pod gan y gweinydd metrig, h.y. 101m a 4m
- Yn cyfrifo'r gwerth absoliwt cyfartalog, h.y. (101m + 4m) / 2 = 53m
- Yn cael y gwerth absoliwt am y defnydd o adnoddau a ddymunir (ar gyfer hyn, mae ceisiadau'r holl gynwysyddion yn cael eu crynhoi) 60m + 30m = 90m
- Yn cyfrifo canran gyfartalog y defnydd CPU o'i gymharu â'r cod cais, h.y. 53m / 90m * 100% = 59%
Nawr mae gennym bopeth sydd ei angen arnom i benderfynu a oes angen i ni newid nifer y copïau; i wneud hyn, rydym yn cyfrifo'r cyfernod:
ratio = 59% / 30% = 1.96
Y rhai. dylid cynyddu nifer y copïau o ~2 gwaith a dod i [2 * 1.96] = 4.
Casgliad: Fel y gwelwch, er mwyn i'r mecanwaith hwn weithio, amod angenrheidiol yw presenoldeb ceisiadau am yr holl gynwysyddion yn y pod a welwyd.
Mecanwaith ar gyfer awtoraddio nodau yn llorweddol (Clwster Autoscaler)
Er mwyn niwtraleiddio'r effaith negyddol ar y system yn ystod ymchwyddiadau llwyth, nid yw cael hpa wedi'i ffurfweddu yn ddigon. Er enghraifft, yn ôl y gosodiadau yn y rheolwr rheolydd hpa, mae'n penderfynu bod angen cynyddu nifer y replicas 2 waith, ond nid oes gan y nodau adnoddau rhad ac am ddim i redeg y fath nifer o godennau (h.y. ni all y nod ddarparu'r adnoddau y gofynnwyd amdanynt i'r pod ceisiadau) ac mae'r codennau hyn yn newid i'r cyflwr Arfaethedig.
Yn yr achos hwn, os oes gan y darparwr IaaS/PaaS cyfatebol (er enghraifft, GKE/TAG, AKS, EKS, ac ati), offeryn fel Graddiwr Awtomatig Nod. Mae'n caniatáu ichi osod uchafswm ac isafswm nifer y nodau yn y clwstwr ac addasu'r nifer gyfredol o nodau yn awtomatig (trwy ffonio API darparwr y cwmwl i archebu / tynnu nod) pan fo diffyg adnoddau yn y clwstwr a'r codennau ni ellir eu hamserlennu (yn y cyflwr Arfaethedig).
Casgliad: Er mwyn gallu graddio nodau'n awtomatig, mae angen gosod ceisiadau yn y cynwysyddion pod fel y gall k8s asesu'r llwyth ar y nodau yn gywir ac adrodd yn unol â hynny nad oes unrhyw adnoddau yn y clwstwr i lansio'r pod nesaf.
Casgliad
Dylid nodi nad yw gosod terfynau adnoddau cynhwysydd yn ofyniad er mwyn i'r cais redeg yn llwyddiannus, ond mae'n dal yn well gwneud hynny am y rhesymau canlynol:
- Ar gyfer gweithrediad mwy cywir o'r amserlennydd o ran cydbwyso llwyth rhwng nodau k8s
- Er mwyn lleihau'r tebygolrwydd y bydd digwyddiad “troi allan codennau” yn digwydd
- Ar gyfer awtoraddio llorweddol o godennau cais (HPA) i weithio
- Ar gyfer awtoraddio nodau yn llorweddol (Clwster Autoscaling) ar gyfer darparwyr cwmwl
Darllenwch erthyglau eraill ar ein blog hefyd:
Ffynhonnell: hab.com