Kama sheria, kila wakati kuna haja ya kutoa rasilimali iliyojitolea kwa programu kwa operesheni yake sahihi na thabiti. Lakini vipi ikiwa maombi kadhaa yanaendeshwa kwa nguvu sawa? Jinsi ya kutoa kila mmoja wao na rasilimali za chini zinazohitajika? Unawezaje kupunguza matumizi ya rasilimali? Jinsi ya kusambaza kwa usahihi mzigo kati ya nodi? Jinsi ya kuhakikisha kuwa utaratibu wa kuongeza usawa unafanya kazi ikiwa mzigo wa programu unaongezeka?
Unahitaji kuanza na aina gani kuu za rasilimali zilizopo kwenye mfumo - hii, bila shaka, ni wakati wa processor na RAM. Katika k8s hudhihirisha aina hizi za rasilimali hupimwa katika vitengo vifuatavyo:
- CPU - katika cores
- RAM - kwa ka
Kwa kuongeza, kwa kila rasilimali inawezekana kuweka aina mbili za mahitaji - maombi ΠΈ mipaka. Maombi - inaelezea mahitaji ya chini ya rasilimali za bure za nodi ya kuendesha kontena (na ganda kwa ujumla), wakati vikomo vinaweka kikomo ngumu kwenye rasilimali zinazopatikana kwenye kontena.
Ni muhimu kuelewa kwamba faili ya maelezo si lazima ifafanue kwa uwazi aina zote mbili, lakini tabia itakuwa kama ifuatavyo:
- Iwapo tu mipaka ya rasilimali imebainishwa kwa uwazi, basi maombi ya rasilimali hii huchukua thamani sawa na kikomo kiotomatiki (unaweza kuthibitisha hili kwa kupiga simu huluki zinazoelezea). Wale. kwa kweli, kontena itapunguzwa kwa kiwango sawa cha rasilimali inayohitaji kuendeshwa.
- Ikiwa maombi pekee yamebainishwa kwa uwazi kwa rasilimali, basi hakuna vikwazo vya juu vilivyowekwa kwenye rasilimali hii - i.e. chombo ni mdogo tu na rasilimali za node yenyewe.
Inawezekana pia kusanidi usimamizi wa rasilimali sio tu katika kiwango cha kontena fulani, lakini pia katika kiwango cha nafasi ya majina kwa kutumia vyombo vifuatavyo:
- LimitRange β inafafanua sera ya kizuizi katika kiwango cha kontena/ganda katika ns na inahitajika ili kuelezea vikomo chaguo-msingi kwenye chombo/ganda, na pia kuzuia uundaji wa vyombo/viganda vya mafuta (au kinyume chake), punguza idadi yao na kuamua tofauti iwezekanavyo katika maadili katika mipaka na maombi
- RasilimaliQuota - Eleza sera ya vizuizi kwa jumla kwa kontena zote katika ns na hutumiwa, kama sheria, kuweka mipaka kati ya rasilimali kati ya mazingira (inafaa wakati mazingira hayajatengwa kabisa katika kiwango cha nodi)
Ifuatayo ni mifano ya maonyesho ambayo huweka mipaka ya rasilimali:
-
Katika kiwango maalum cha chombo:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mWale. katika kesi hii, ili kuendesha kontena iliyo na nginx, utahitaji angalau 1G ya RAM isiyolipishwa na 0.2 CPU kwenye nodi, wakati chombo kinaweza kutumia 0.2 CPU na RAM yote inayopatikana kwenye nodi.
-
Katika kiwango kamili ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiWale. jumla ya kontena zote za ombi katika ns chaguo-msingi haziwezi kuzidi 300m kwa CPU na 1G kwa OP, na jumla ya kikomo yote ni 700m kwa CPU na 2G kwa OP.
-
Vikomo chaguomsingi vya kontena katika 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: 4GiWale. katika nafasi chaguomsingi ya majina kwa vyombo vyote, ombi litawekwa kuwa 100m kwa CPU na 1G kwa OP, kikomo - 1 CPU na 2G. Wakati huo huo, kikomo pia kinawekwa kwa thamani zinazowezekana katika ombi/kikomo cha CPU (50m <x <2) na RAM (500M <x <4G).
-
Vizuizi vya kiwango cha ganda ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiWale. kwa kila ganda katika ns chaguo-msingi kutakuwa na kikomo cha 4 vCPU na 1G.
Sasa ningependa kukuambia ni faida gani kuweka vikwazo hivi kunaweza kutupa.
Utaratibu wa kusawazisha mzigo kati ya nodi
Kama unavyojua, sehemu ya k8s inawajibika kwa usambazaji wa maganda kati ya nodi, kama vile mpangilio, ambayo inafanya kazi kulingana na algorithm maalum. Algorithm hii inapitia hatua mbili wakati wa kuchagua nodi bora ya kuzindua:
- kuchuja
- Kuanzia
Wale. kwa mujibu wa sera iliyoelezwa, nodes huchaguliwa awali ambayo inawezekana kuzindua pod kulingana na seti vihusishi (pamoja na kuangalia ikiwa nodi ina rasilimali za kutosha kuendesha ganda - PodFitsResources), na kisha kwa kila nodi hizi, kulingana na Vipaumbele pointi zinatolewa (ikiwa ni pamoja na, kadiri nodi inavyokuwa na rasilimali za bure, ndivyo inavyopewa pointi zaidi - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) na ganda linazinduliwa kwenye nodi yenye pointi nyingi (ikiwa nodi kadhaa zinakidhi hali hii mara moja, basi moja huchaguliwa bila mpangilio).
Wakati huo huo, unahitaji kuelewa kwamba mpangilio, wakati wa kutathmini rasilimali zilizopo za node, huongozwa na data ambayo imehifadhiwa katika etcd - i.e. kwa kiasi cha rasilimali iliyoombwa/kikomo cha kila ganda linaloendesha kwenye nodi hii, lakini si kwa matumizi halisi ya rasilimali. Habari hii inaweza kupatikana kutoka kwa pato la amri kubectl describe node $NODE, kwa mfano:
# 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%)Hapa tunaona maganda yote yanayoendesha kwenye nodi maalum, pamoja na rasilimali ambazo kila pod inaomba. Na hii ndio jinsi magogo ya mpangilio yanaonekana wakati cronjob-cron-events-1573793820-xt6q9 pod inazinduliwa (habari hii itaonekana kwenye logi ya mpangilio wakati kiwango cha 10 cha ukataji miti kimewekwa katika hoja za amri ya uzinduzi -v=10 ):
logi
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-s10Hapa tunaona kwamba mwanzoni mpangaji huchuja na kutoa orodha ya nodi 3 ambazo zinaweza kuzinduliwa (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Kisha hukokotoa alama kulingana na vigezo kadhaa (ikiwa ni pamoja na BalancedResourceAllocation, LeastResourceAllocation) kwa kila nodi hizi ili kubaini nodi inayofaa zaidi. Hatimaye, pod imepangwa kwenye node yenye idadi kubwa zaidi ya pointi (hapa nodi mbili mara moja zina idadi sawa ya pointi 100037, hivyo moja ya random huchaguliwa - nxs-k8s-s10).
Pato: ikiwa node inaendesha maganda ambayo hakuna vikwazo vilivyowekwa, basi kwa k8s (kutoka kwa mtazamo wa matumizi ya rasilimali) hii itakuwa sawa na kana kwamba hapakuwa na pods vile kwenye node hii kabisa. Kwa hivyo, ikiwa wewe, kwa masharti, una ganda na mchakato wa ulafi (kwa mfano, wowza) na hakuna vizuizi vilivyowekwa kwa hiyo, basi hali inaweza kutokea wakati ganda hili lilikula rasilimali zote za nodi, lakini kwa k8 nodi hii. inachukuliwa kuwa haijapakuliwa na itapewa idadi sawa ya pointi wakati wa kuorodheshwa (haswa katika pointi zinazotathmini rasilimali zilizopo) kama nodi ambayo haina maganda ya kufanya kazi, ambayo hatimaye inaweza kusababisha usambazaji usio sawa wa mzigo kati ya nodi.
Kufukuzwa kwa Pod
Kama unavyojua, kila ganda limepewa moja ya madarasa 3 ya QoS:
- imehakikishwa - imepewa wakati kwa kila chombo kwenye ganda ombi na kikomo vimeainishwa kwa kumbukumbu na cpu, na maadili haya lazima yalingane
- ya kupasuka - Angalau chombo kimoja kwenye ganda kina ombi na kikomo, na ombi <kikomo
- juhudi bora - wakati hakuna kontena moja kwenye ganda iliyo na rasilimali chache
Wakati huo huo, wakati nodi inakabiliwa na ukosefu wa rasilimali (diski, kumbukumbu), kubelet huanza kuweka na kufukuza maganda kulingana na algorithm maalum ambayo inazingatia kipaumbele cha pod na darasa lake la QoS. Kwa mfano, ikiwa tunazungumza juu ya RAM, basi kulingana na darasa la QoS, alama hupewa kulingana na kanuni ifuatayo:
- Imethibitishwa:-998
- Juhudi nzuri: 1000
- Kupasuka: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Wale. kwa kipaumbele sawa, kubelet kwanza itaondoa maganda kwa bidii bora ya darasa la QoS kutoka kwa nodi.
Pato: ikiwa unataka kupunguza uwezekano wa pod inayotakiwa kufukuzwa kutoka kwa node katika tukio la ukosefu wa rasilimali juu yake, basi pamoja na kipaumbele, unahitaji pia kutunza kuweka ombi / kikomo kwa ajili yake.
Utaratibu wa kuongeza usawa wa maganda ya maombi (HPA)
Wakati kazi ni kuongeza na kupunguza kiotomati idadi ya maganda kulingana na matumizi ya rasilimali (mfumo - CPU/RAM au mtumiaji - rps), chombo cha k8 kama HPA (Horizontal Pod Autoscaler). Algorithm ambayo ni kama ifuatavyo:
- Usomaji wa sasa wa rasilimali iliyoangaliwa umebainishwa (currentMetricValue)
- Thamani zinazohitajika za rasilimali zimedhamiriwa (desiredMetricValue), ambayo kwa rasilimali za mfumo huwekwa kwa kutumia ombi.
- Nambari ya sasa ya nakala imebainishwa (currentReplicas)
- Fomula ifuatayo hukokotoa nambari inayotakiwa ya nakala (desiredReplicas)
takaReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]
Katika kesi hii, kuongeza hakutatokea wakati mgawo (currentMetricValue / desiredMetricValue) iko karibu na 1 (katika kesi hii, tunaweza kuweka hitilafu inayoruhusiwa sisi wenyewe; kwa chaguo-msingi ni 0.1).
Wacha tuangalie jinsi hpa inavyofanya kazi kwa kutumia mfano wa programu ya jaribio la programu (iliyoelezewa kama Usambazaji), ambapo inahitajika kubadilisha idadi ya nakala kulingana na utumiaji wa CPU:
-
Onyesho la programu
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-statusWale. tunaona kwamba ganda la maombi limezinduliwa awali katika matukio mawili, ambayo kila moja ina vyombo viwili vya nginx na nginx-exporter, kwa kila moja ambayo maalum maombi kwa CPU.
-
Ilani ya 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: 30Wale. Tumeunda hpa ambayo itafuatilia jaribio la programu ya Usambazaji na kudhibiti idadi ya maganda na programu kulingana na kiashirio cha cpu (tunatarajia kuwa ganda litumie asilimia 30 ya CPU inayoomba), huku idadi ya nakala ikiwa. katika safu ya 2-10.
Sasa, hebu tuangalie utaratibu wa operesheni ya hpa ikiwa tutaweka mzigo kwenye moja ya makao:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Kwa jumla tunayo yafuatayo:
- Thamani inayotakiwa (desiredMetricValue) - kulingana na mipangilio ya hpa, tuna 30%
- Thamani ya sasa (currentMetricValue) - kwa hesabu, msimamizi-mtawala huhesabu thamani ya wastani ya matumizi ya rasilimali katika%, i.e. kwa masharti hufanya yafuatayo:
- Hupokea maadili kamili ya vipimo vya pod kutoka kwa seva ya kipimo, i.e. 101m na 4m
- Huhesabu thamani kamili ya wastani, i.e. (101m + 4m) / 2 = 53m
- Inapata thamani kamili ya matumizi ya rasilimali inayotakiwa (kwa hili, maombi ya vyombo vyote yana muhtasari) 60m + 30m = 90m
- Huhesabu asilimia ya wastani ya matumizi ya CPU ikilinganishwa na ganda la ombi, i.e. 53m / 90m * 100% = 59%
Sasa tuna kila kitu tunachohitaji ili kuamua ikiwa tunahitaji kubadilisha idadi ya nakala ili kufanya hivyo, tunahesabu mgawo:
ratio = 59% / 30% = 1.96
Wale. idadi ya nakala inapaswa kuongezwa kwa ~ mara 2 na kiasi hadi [2 * 1.96] = 4.
Hitimisho: Kama unaweza kuona, ili utaratibu huu ufanye kazi, hali ya lazima ni kuwepo kwa maombi ya vyombo vyote kwenye pod iliyozingatiwa.
Utaratibu wa uwekaji usawa wa nodi (Cluster Autoscaler)
Ili kupunguza athari mbaya kwenye mfumo wakati wa kuongezeka kwa mzigo, kuwa na hpa iliyosanidiwa haitoshi. Kwa mfano, kulingana na mipangilio katika meneja wa mtawala wa hpa, inaamua kwamba idadi ya nakala zinahitaji kuongezeka kwa mara 2, lakini nodi hazina rasilimali za bure za kuendesha idadi kama hiyo ya maganda (yaani, nodi haiwezi kutoa aliomba rasilimali kwa ganda la maombi) na maganda haya swichi kwa hali Inasubiri.
Katika hali hii, ikiwa mtoaji ana IaaS/PaaS inayolingana (kwa mfano, GKE/GCE, AKS, EKS, n.k.), zana kama vile. Node Autoscaler. Inakuruhusu kuweka idadi ya juu na ya chini ya nodi kwenye nguzo na kurekebisha kiotomati nambari ya sasa ya nodi (kwa kupiga API ya mtoaji wa wingu ili kuagiza / kuondoa nodi) wakati kuna ukosefu wa rasilimali kwenye nguzo na maganda. haiwezi kuratibiwa (ziko katika hali inayosubiri).
Hitimisho: Ili kuweza kusawazisha nodi otomatiki, ni muhimu kuweka maombi katika vyombo vya ganda ili k8s ziweze kutathmini kwa usahihi mzigo kwenye nodi na ipasavyo ripoti kwamba hakuna rasilimali katika nguzo ya kuzindua pod inayofuata.
Hitimisho
Ikumbukwe kwamba kuweka mipaka ya rasilimali ya kontena sio hitaji kwa programu kufanya kazi kwa mafanikio, lakini bado ni bora kufanya hivyo kwa sababu zifuatazo:
- Kwa operesheni sahihi zaidi ya mpangilio kwa suala la kusawazisha mzigo kati ya nodi za k8s
- Ili kupunguza uwezekano wa tukio la "kufukuzwa kwa ganda" kutokea
- Kwa uwekaji usawa wa maganda ya programu (HPA) kufanya kazi
- Kwa upanuzi otomatiki wa nodi (Cluster Autoscaling) kwa watoa huduma za wingu
Pia soma nakala zingine kwenye blogi yetu:
Chanzo: mapenzi.com