Ingon sa usa ka lagda, adunay kanunay nga panginahanglan sa paghatag usa ka gipahinungod nga pool sa mga kapanguhaan sa usa ka aplikasyon alang sa husto ug lig-on nga operasyon niini. Apan unsa man kung daghang mga aplikasyon ang nagdagan sa parehas nga gahum? Giunsa paghatag ang matag usa kanila sa labing gamay nga kinahanglanon nga mga kapanguhaan? Unsaon nimo limitahan ang konsumo sa kahinguhaan? Sa unsa nga paagi sa husto nga pag-apod-apod sa load sa taliwala sa mga node? Giunsa pagsiguro nga ang mekanismo sa pinahigda nga pag-scale molihok kung ang pagkarga sa aplikasyon nagdugang?
Kinahanglan ka magsugod sa kung unsang mga nag-unang matang sa mga kahinguhaan ang anaa sa sistema - kini, siyempre, ang oras sa processor ug RAM. Sa k8s manifests kini nga mga matang sa kapanguhaan gisukod sa mosunod nga mga yunit:
- CPU - sa mga cores
- RAM - sa mga byte
Dugang pa, alang sa matag kapanguhaan posible nga magtakda og duha ka matang sa mga kinahanglanon - Mga hangyo ΠΈ limitasyon. Mga hangyo - naghulagway sa minimum nga mga kinahanglanon alang sa libre nga mga kapanguhaan sa usa ka node sa pagpadagan sa usa ka sudlanan (ug pod sa kinatibuk-an), samtang ang mga limitasyon nagtakda og lisud nga limitasyon sa mga kapanguhaan nga anaa sa sudlanan.
Importante nga masabtan nga ang manifest dili kinahanglan nga tin-aw nga naghubit sa duha ka matang, apan ang kinaiya mahimong sama sa mosunod:
- Kung ang mga limitasyon lamang sa usa ka kahinguhaan ang tin-aw nga gipiho, nan ang mga hangyo alang niini nga kapanguhaan awtomatik nga magkuha usa ka kantidad nga katumbas sa mga limitasyon (mahimo nimo kini mapamatud-an pinaagi sa pagtawag sa paghulagway sa mga entidad). Mga. sa pagkatinuod, ang sudlanan mahimong limitado ngadto sa sama nga kantidad sa mga kapanguhaan nga gikinahanglan sa pagdagan.
- Kung ang mga hangyo lamang ang tin-aw nga gipiho alang sa usa ka kapanguhaan, nan walaβy taas nga mga pagdili nga gibutang sa kini nga kapanguhaan - i.e. ang sudlanan limitado lamang sa mga kahinguhaan sa node mismo.
Posible usab nga i-configure ang pagdumala sa kapanguhaan dili lamang sa lebel sa usa ka piho nga sudlanan, apan usab sa lebel sa namespace gamit ang mga musunud nga entidad:
- LimitRange β naghulagway sa polisiya sa pagdili sa lebel sa sudlanan/pod sa ns ug gikinahanglan aron mahulagway ang default nga mga limitasyon sa sudlanan/pod, ingon man mapugngan ang paghimo sa klarong tambok nga mga sudlanan/pod (o vice versa), limitahan ang ilang gidaghanon ug mahibal-an ang posible nga kalainan sa mga kantidad sa mga limitasyon ug mga hangyo
- ResourceQuotas β ihulagway ang palisiya sa pagdili sa kinatibuk-an alang sa tanan nga mga sudlanan sa ns ug gigamit, ingon usa ka lagda, aron limitahan ang mga kapanguhaan taliwala sa mga palibot (mapuslan kung ang mga palibot dili estrikto nga gimarkahan sa lebel sa node)
Ang mosunod mao ang mga pananglitan sa mga pagpakita nga nagtakda og mga limitasyon sa kahinguhaan:
-
Sa piho nga lebel sa sudlanan:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mMga. sa kini nga kaso, aron makadagan ang usa ka sudlanan nga adunay nginx, kinahanglan nimo labing menos 1G nga libre nga RAM ug 0.2 CPU sa node, samtang ang labing kadaghan nga sulud mahimoβg mag-ut-ot sa 0.2 CPU ug tanan nga magamit nga RAM sa node.
-
Sa integer nga lebel ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiMga. ang sumada sa tanang hangyo nga sudlanan sa default ns dili molapas sa 300m para sa CPU ug 1G para sa OP, ug ang sumada sa tanang limitasyon kay 700m para sa CPU ug 2G para sa OP.
-
Default nga mga limitasyon para sa mga sudlanan sa 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: 4GiMga. sa default namespace para sa tanan nga mga sudlanan, ang hangyo itakda sa 100m alang sa CPU ug 1G alang sa OP, limitahan - 1 CPU ug 2G. Sa samang higayon, gitakda usab ang limitasyon sa posibleng mga kantidad sa hangyo/limitasyon para sa CPU (50m < x <2) ug RAM (500M < x <4G).
-
Mga pagdili sa lebel sa pod ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiMga. para sa matag pod sa default ns naay limit nga 4 vCPU ug 1G.
Karon gusto nako isulti kanimo kung unsa nga mga bentaha ang mahatag kanamo sa paghimo niini nga mga pagdili.
Ang mekanismo sa pagbalanse sa load tali sa mga node
Sama sa imong nahibal-an, ang k8s nga sangkap mao ang responsable sa pag-apod-apod sa mga pod sa mga node, sama sa iskedyul, nga naglihok sumala sa usa ka piho nga algorithm. Kini nga algorithm moagi sa duha ka yugto sa pagpili sa labing maayo nga node nga ilunsad:
- pagsala
- Naglangkob
Mga. sumala sa gihulagway nga palisiya, ang mga node sa sinugdanan gipili diin posible nga maglunsad og usa ka pod base sa usa ka set mga predicate (lakip ang pagsusi kung ang node adunay igo nga mga kapanguhaan sa pagpadagan sa pod - PodFitsResources), ug dayon alang sa matag usa niini nga mga node, sumala sa prayoridad Gihatag ang mga puntos (lakip na, ang labi ka libre nga mga kapanguhaan nga adunay usa ka node, ang daghang mga punto nga na-assign niini - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ug ang pod gilansad sa node nga adunay labing daghang puntos (kung daghang mga node ang makatagbaw niini nga kondisyon sa usa ka higayon, dayon usa ka random ang gipili).
Sa parehas nga oras, kinahanglan nimo nga masabtan nga ang scheduler, kung gisusi ang magamit nga mga kapanguhaan sa usa ka node, gigiyahan sa datos nga gitipigan sa etcd - i.e. alang sa kantidad sa gipangayo/limitahan nga kapanguhaan sa matag pod nga nagdagan niini nga node, apan dili alang sa aktuwal nga konsumo sa kapanguhaan. Kini nga impormasyon makuha gikan sa command output kubectl describe node $NODEsama pananglit:
# 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%)Dinhi atong makita ang tanan nga mga pod nga nagdagan sa usa ka piho nga node, ingon man ang mga kapanguhaan nga gihangyo sa matag pod. Ug ania kung unsa ang hitsura sa mga log sa scheduler kung ang cronjob-cron-events-1573793820-xt6q9 pod gilusad (kini nga impormasyon makita sa scheduler log kung imong gibutang ang ika-10 nga lebel sa logging sa startup command arguments -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-s10Dinhi atong makita nga sa sinugdanan ang scheduler nagsala ug nagmugna og usa ka listahan sa 3 ka mga node diin kini mahimong ilunsad (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Dayon kini kalkulado ang mga iskor base sa pipila ka mga parametro (lakip ang BalancedResourceAllocation, LeastResourceAllocation) para sa matag usa niini nga mga node aron sa pagtino sa labing angay nga node. Sa katapusan, ang pod naka-iskedyul sa node nga adunay pinakataas nga ihap sa mga punto (dinhi ang duha ka node sa usa ka higayon adunay parehas nga gidaghanon sa mga puntos 100037, mao nga gipili ang usa ka random - nxs-k8s-s10).
konklusyon: kung ang usa ka node nagpadagan sa mga pod nga walaβy gitakda nga mga pagdili, nan alang sa mga k8 (gikan sa punto sa pagtan-aw sa pagkonsumo sa kapanguhaan) kini katumbas sa ingon nga walaβy ingon nga mga pod sa kini nga node. Busa, kung ikaw, sa kondisyon, adunay usa ka pod nga adunay usa ka gluttonous nga proseso (pananglitan, wowza) ug walay mga pagdili nga gitakda alang niini, nan ang usa ka sitwasyon mahimong motumaw kung kini nga pod tinuod nga mikaon sa tanan nga mga kapanguhaan sa node, apan alang sa k8s kini nga node gikonsiderar nga unloaded ug kini pagahatagan sa sama nga gidaghanon sa mga puntos sa diha nga ang ranggo (eksaktong sa mga punto nga nag-assess sa anaa nga mga kapanguhaan) isip usa ka node nga walay nagtrabaho nga mga pod, nga sa katapusan mahimong mosangpot sa dili patas nga pag-apod-apod sa load tali sa mga node.
Pagpalayas pod
Sama sa imong nahibal-an, ang matag pod gi-assign sa usa sa 3 ka klase sa QoS:
- gigarantiyahan - gi-assign kung alang sa matag sudlanan sa pod usa ka hangyo ug limitasyon ang gitakda alang sa memorya ug cpu, ug kini nga mga kantidad kinahanglan nga magkatugma
- mabuak β labing menos usa ka sudlanan sa pod adunay hangyo ug limitasyon, nga adunay hangyo < limit
- labing paningkamot β kung walay bisan usa ka sudlanan sa pod nga limitado ang kahinguhaan
Sa samang higayon, kung ang usa ka node makasinati og kakulang sa mga kahinguhaan (disk, memorya), ang kubelet magsugod sa pagranggo ug pagpalayas sa mga pod sumala sa usa ka piho nga algorithm nga nagkonsiderar sa prayoridad sa pod ug sa iyang QoS nga klase. Pananglitan, kung naghisgot kita bahin sa RAM, unya base sa klase sa QoS, ang mga puntos gihatagan sumala sa mosunod nga prinsipyo:
- Gigarantiya:-998
- Labing Maayong Paningkamot: 1000
- Burstable: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Mga. nga adunay parehas nga prayoridad, ang kubelet una nga papahawaon ang mga pod nga adunay labing kaayo nga paningkamot sa klase sa QoS gikan sa node.
konklusyon: kung gusto nimo nga makunhuran ang posibilidad nga ang gusto pod nga mapahawa gikan sa node kung adunay kakulang sa mga kahinguhaan niini, unya kauban ang prayoridad, kinahanglan nimo usab nga atimanon ang pagtakda sa hangyo / limitasyon alang niini.
Mekanismo alang sa pinahigda nga autoscaling sa mga pod sa aplikasyon (HPA)
Kung ang tahas mao ang awtomatik nga pagdugang ug pagkunhod sa gidaghanon sa mga pod depende sa paggamit sa mga kahinguhaan (system - CPU / RAM o user - rps), usa ka k8s entity sama sa HPA (Horizontal Pod Autoscaler). Ang algorithm niini mao ang mosunod:
- Ang kasamtangan nga mga pagbasa sa naobserbahan nga kapanguhaan gitino (currentMetricValue)
- Ang gitinguha nga mga kantidad alang sa kapanguhaan gitino (gitinguhaMetricValue), nga alang sa mga kapanguhaan sa sistema gitakda gamit ang hangyo
- Ang kasamtangan nga gidaghanon sa mga replika gitino (karonReplicas)
- Ang mosunud nga pormula nagkalkula sa gitinguha nga gidaghanon sa mga replika (gitinguha nga Replicas)
gusto ngaReplicas = [karonReplicas * (karonMetricValue / gustoMetricValue)]
Sa kini nga kaso, ang pag-scale dili mahitabo kung ang coefficient (currentMetricValue / desiredMetricValue) hapit sa 1 (sa kini nga kaso, mahimo namon nga itakda ang gitugotan nga sayup sa among kaugalingon; sa default kini 0.1).
Atong tan-awon kung giunsa ang pagtrabaho sa hpa gamit ang panig-ingnan sa aplikasyon sa pagsulay sa app (gihulagway nga Deployment), kung diin kinahanglan nga usbon ang gidaghanon sa mga replika depende sa konsumo sa CPU:
-
Pagpadayag sa aplikasyon
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-statusMga. atong makita nga ang application pod sa sinugdan gilusad sa duha ka mga higayon, ang matag usa niini adunay duha ka nginx ug nginx-exporter nga mga sudlanan, alang sa matag usa niini usa ka espesipikong Mga hangyo alang sa CPU.
-
Manipesto sa 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: 30Mga. Naghimo kami og hpa nga mag-monitor sa Deployment app-test ug mag-adjust sa gidaghanon sa mga pod gamit ang aplikasyon base sa cpu indicator (naglaum kami nga ang pod kinahanglan nga mokonsumo sa 30% sa CPU nga gipangayo niini), uban ang gidaghanon sa mga replika nga anaa. range sa 2-10.
Karon, atong tan-awon ang mekanismo sa operasyon sa hpa kung atong i-apply ang usa ka load sa usa sa mga hearth:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Sa kinatibuk-an aduna kami sa mosunod:
- Ang gitinguha nga kantidad (desiredMetricValue) - sumala sa mga setting sa hpa, kami adunay 30%
- Kasamtangang kantidad (currentMetricValue) - alang sa kalkulasyon, ang controller-manager nagkalkula sa kasagaran nga kantidad sa konsumo sa kapanguhaan sa%, i.e. conditional naghimo sa mosunod:
- Nakadawat ug hingpit nga kantidad sa pod metrics gikan sa metric server, i.e. 101m ug 4m
- Gikalkulo ang kasagaran nga hingpit nga bili, i.e. (101m + 4m) / 2 = 53m
- Nakuha ang hingpit nga kantidad alang sa gitinguha nga konsumo sa kapanguhaan (alang niini, ang mga hangyo sa tanan nga mga sulud gisumada) 60m + 30m = 90m
- Gikalkulo ang kasagaran nga porsyento sa konsumo sa CPU kalabot sa hangyo pod, i.e. 53m / 90m * 100% = 59%
Karon naa na namo ang tanan nga among gikinahanglan aron mahibal-an kung kinahanglan ba namon nga usbon ang gidaghanon sa mga replika; aron mahimo kini, kalkulado namon ang coefficient:
ratio = 59% / 30% = 1.96
Mga. ang gidaghanon sa mga replika kinahanglan nga madugangan sa ~2 ka beses ug kantidad sa [2 * 1.96] = 4.
Panapos: Sama sa imong makita, aron kini nga mekanismo molihok, usa ka kinahanglanon nga kondisyon mao ang presensya sa mga hangyo alang sa tanan nga mga sudlanan sa naobserbahan nga pod.
Mekanismo alang sa pinahigda nga autoscaling sa mga node (Cluster Autoscaler)
Aron ma-neutralize ang negatibo nga epekto sa sistema sa panahon sa pag-load sa mga surge, dili igo ang pag-configure sa hpa. Pananglitan, sumala sa mga setting sa hpa controller manager, kini nagdesisyon nga ang gidaghanon sa mga replika kinahanglan nga madugangan sa 2 ka beses, apan ang mga node walay libre nga mga kapanguhaan sa pagpadagan sa ingon nga gidaghanon sa mga pods (ie ang node dili makahatag sa gihangyo nga mga kapanguhaan sa mga hangyo pod) ug kini nga mga pod mobalhin sa kahimtang sa Pending.
Niini nga kaso, kung ang provider adunay katugbang nga IaaS/PaaS (pananglitan, GKE/GCE, AKS, EKS, ug uban pa), usa ka himan sama sa Node Autoscaler. Gitugotan ka nga itakda ang labing kadaghan ug minimum nga gidaghanon sa mga node sa cluster ug awtomatiko nga i-adjust ang kasamtangan nga gidaghanon sa mga node (pinaagi sa pagtawag sa cloud provider API aron mag-order / magtangtang sa usa ka node) kung adunay kakulang sa mga kapanguhaan sa cluster ug ang mga pod. dili ma-iskedyul (naa sa kahimtang sa Pending).
Panapos: Aron makahimo sa pag-autoscale sa mga node, gikinahanglan ang pag-set sa mga hangyo sa mga sudlanan sa pod aron ang mga k8s makahimo sa husto nga pag-assess sa load sa mga node ug sumala niana nga report nga walay mga kapanguhaan sa cluster aron ilunsad ang sunod nga pod.
konklusyon
Kinahanglang hinumdoman nga ang pagtakda sa mga limitasyon sa kahinguhaan sa sudlanan dili usa ka kinahanglanon alang sa aplikasyon nga malampuson nga modagan, apan mas maayo pa nga buhaton kini alang sa mosunod nga mga hinungdan:
- Para sa mas tukma nga operasyon sa scheduler sa termino sa load balancing tali sa k8s nodes
- Aron makunhuran ang posibilidad nga adunay mahitabo nga "pod eviction".
- Para sa horizontal autoscaling sa mga application pods (HPA) nga mutrabaho
- Para sa pinahigda nga autoscaling sa mga node (Cluster Autoscaling) para sa mga cloud providers
Basaha usab ang ubang mga artikulo sa among blog:
Source: www.habr.com