A matsayinka na mai mulki, akwai ko da yaushe bukatar samar da wani kwazo tafkin albarkatun zuwa aikace-aikace don daidai da kuma barga aiki. Amma idan aikace-aikace da yawa suna gudana akan wuta ɗaya fa? Ta yaya za a samar wa kowannensu da mafi ƙarancin albarkatun da ake bukata? Ta yaya za ku iya iyakance amfani da albarkatu? Yadda za a rarraba kaya daidai tsakanin nodes? Yadda za a tabbatar da tsarin sikelin kwance yana aiki idan nauyin aikace-aikacen ya karu?
Kuna buƙatar farawa da menene manyan nau'ikan albarkatun da ke cikin tsarin - wannan, ba shakka, shine lokacin processor da RAM. A cikin k8s yana bayyana waɗannan nau'ikan albarkatun ana auna su a cikin raka'a masu zuwa:
- CPU - a cikin cores
- RAM - a cikin bytes
Haka kuma, ga kowane albarkatu yana yiwuwa a saita nau'ikan buƙatu guda biyu - buƙatun и iyaka. Buƙatun - yana bayyana mafi ƙarancin buƙatun don albarkatun kyauta na kumburi don gudanar da akwati (da kwaf ɗin gabaɗaya), yayin da iyaka ke saita iyaka mai ƙarfi akan albarkatun da ake samu ga kwantena.
Yana da mahimmanci a fahimci cewa bayyanar ba dole ba ne ta bayyana nau'ikan nau'ikan biyu a sarari, amma yanayin zai kasance kamar haka:
- Idan iyakokin albarkatun kawai aka bayyana a sarari, to buƙatun wannan albarkatun suna ɗaukar ƙimar daidai da iyaka ta atomatik (zaka iya tabbatar da wannan ta hanyar kiran ƙungiyoyin siffantawa). Wadancan. a gaskiya ma, kwandon zai iyakance ga adadin albarkatun da ake bukata don gudanar da shi.
- Idan kawai buƙatun da aka bayyana a sarari don albarkatu, to ba a saita babban hani akan wannan albarkatun - watau. kwandon yana iyakance kawai ta albarkatun kumburin kanta.
Hakanan yana yiwuwa a daidaita sarrafa albarkatun ba kawai a matakin takamaiman akwati ba, har ma a matakin sunan suna ta amfani da abubuwan da ke biyowa:
- Iyakance Range - ya bayyana manufar ƙuntatawa a matakin kwantena / kwasfa a cikin ns kuma ana buƙata don bayyana iyakokin tsoho akan akwati / kwasfa, da kuma hana ƙirƙirar kwantena masu kitse / kwasfa (ko akasin haka), iyakance adadin su. da kuma ƙayyade yiwuwar bambanci a cikin ƙididdiga a cikin iyaka da buƙatun
- ResourceQuotas - bayyana manufar ƙuntatawa gabaɗaya don duk kwantena a cikin ns kuma ana amfani dashi, a matsayin mai mulkin, don iyakance albarkatun tsakanin mahalli (mai amfani lokacin da ba'a keɓance mahalli a matakin kumburi)
Wadannan su ne misalan bayyanar da ke saita iyakokin albarkatu:
-
A takamaiman matakin kwantena:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mWadancan. A wannan yanayin, don gudanar da akwati tare da nginx, kuna buƙatar aƙalla 1G na RAM kyauta da 0.2 CPU akan kumburi, yayin da yawancin kwandon zai iya cinye 0.2 CPU da duk RAM ɗin da ke kan node.
-
A matakin lamba ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiWadancan. jimlar duk kwantenan buƙatun da ke cikin tsoho ns ba zai iya wuce 300m na CPU da 1G na OP ba, kuma jimlar duk iyaka shine 700m na CPU da 2G na OP.
-
Iyakoki na asali don kwantena a 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: 4GiWadancan. a cikin tsoffin sunaye don duk kwantena, za a saita buƙatar zuwa 100m don CPU da 1G don OP, iyaka - 1 CPU da 2G. A lokaci guda kuma, an saita iyaka akan yuwuwar ƙima a cikin buƙata/iyaka don CPU (50m <x <2) da RAM (500M <x <4G).
-
Hane-hane-mataki ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiWadancan. ga kowane pods a cikin tsoho ns za a sami iyaka na 4 vCPU da 1G.
Yanzu ina so in gaya muku fa'idodin kafa waɗannan hane-hane na iya ba mu.
Na'urar daidaita nauyi tsakanin nodes
Kamar yadda kuka sani, sashin k8s yana da alhakin rarraba kwasfa a tsakanin nodes, kamar mai tsara shirye-shirye, wanda ke aiki bisa ga takamaiman algorithm. Wannan algorithm yana tafiya ta matakai biyu lokacin zabar kumburi mafi kyau don ƙaddamarwa:
- tacewa
- Ragewa
Wadancan. bisa ga manufar da aka bayyana, an fara zaɓar nodes wanda zai yiwu a ƙaddamar da kwasfa bisa saiti tsinkaya (ciki har da bincika ko kumburin yana da isassun albarkatun don gudanar da kwas ɗin - PodFitsResources), sannan ga kowane ɗayan waɗannan nodes, bisa ga manyan al'amurra ana ba da maki (ciki har da, ƙarin albarkatu kyauta da kumburi yana da, ƙarin maki ana sanya shi - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) kuma ana ƙaddamar da kwaf ɗin akan kumburi tare da mafi yawan maki (idan nodes da yawa sun gamsar da wannan yanayin lokaci ɗaya, sannan an zaɓi bazuwar) .
A lokaci guda kuma, kuna buƙatar fahimtar cewa mai tsarawa, lokacin da ake kimanta albarkatun da ke akwai na kumburi, yana jagorantar bayanan da aka adana a cikin da dai sauransu - watau. don adadin albarkatun da ake buƙata/iyakance na kowane kwas ɗin da ke gudana akan wannan kumburin, amma ba don ainihin amfanin albarkatu ba. Ana iya samun wannan bayanin daga fitowar umarni kubectl describe node $NODE, alal misali:
# 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%)Anan muna ganin duk kwas ɗin suna gudana akan takamaiman kumburi, da kuma albarkatun da kowane kwas ɗin ke buƙata. Kuma ga abin da rajistan ayyukan tsarawa yayi kama lokacin da aka ƙaddamar da cronjob-cron-events-1573793820-xt6q9 pod (wannan bayanin zai bayyana a cikin log ɗin mai tsara lokacin da kuka saita matakin shiga na 10 a cikin muhawarar umarni na farawa -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-s10Anan mun ga cewa da farko mai tsara jadawalin yana tacewa kuma ya haifar da jerin nodes 3 waɗanda za a iya ƙaddamar da su (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Sannan yana ƙididdige ƙididdigewa bisa sigogi da yawa (ciki har da BalancedResourceAllocation, LeastResourceAllocation) ga kowane ɗayan waɗannan nodes don tantance kullin da ya fi dacewa. Daga ƙarshe, an tsara kwafsa akan kumburi tare da mafi girman adadin maki (a nan nodes biyu a lokaci ɗaya suna da adadin maki 100037, don haka an zaɓi bazuwar - nxs-k8s-s10).
ƙarshe: idan node yana gudanar da kwasfa waɗanda ba a saita su ba, to don k8s (daga ma'anar amfani da albarkatu) wannan zai yi daidai da kamar babu irin wannan kwas ɗin kwata-kwata. Don haka, idan ku, a cikin sharadi, kuna da kwasfa tare da tsari na cin abinci (misali, wowza) kuma ba a saita shi ba, to wani yanayi na iya tasowa lokacin da wannan kwaf ɗin ya cinye duk albarkatun kumburin, amma ga k8s wannan kumburi. ana ɗauka an sauke shi kuma za a ba shi adadin adadin maki lokacin matsayi (daidai a cikin abubuwan da ke tantance albarkatun da ake da su) azaman kumburin da ba shi da kwas ɗin aiki, wanda a ƙarshe zai iya haifar da rarraba kaya tsakanin nodes.
Korar Pod
Kamar yadda kuka sani, kowane kwas ɗin ana sanya ɗaya daga cikin azuzuwan QoS 3:
- garanti - an sanya lokacin don kowane akwati a cikin kwas ɗin buƙatu da iyaka an ƙayyade don ƙwaƙwalwar ajiya da CPU, kuma dole ne waɗannan ƙimar su daidaita.
- fashewa - aƙalla akwati ɗaya a cikin kwas ɗin yana da buƙatu da iyaka, tare da buƙata < iyaka
- mafi kyau kokarin - lokacin da babu kwantena ɗaya a cikin kwas ɗin da ke iyakance albarkatun
A lokaci guda, lokacin da kumburi ya sami ƙarancin albarkatu (disk, ƙwaƙwalwar ajiya), kubelet ya fara matsayi da fitar da kwasfa bisa ga takamaiman algorithm wanda ke la'akari da fifikon kwafsa da aji na QoS. Misali, idan muna magana ne game da RAM, to bisa ga ajin QoS, ana ba da maki bisa ga ka'ida mai zuwa:
- Tabbas: -998
- Mafi Kokari: 1000
- Fashewa: min (max (2, 1000 - (1000 * ƙwaƙwalwar ajiyaRequestBytes) / injiMemoryCapacityBytes), 999)
Wadancan. tare da fifiko iri ɗaya, kubelet zai fara korar kwas ɗin tare da mafi kyawun ajin QoS daga kumburi.
ƙarshe: idan kuna son rage yiwuwar fitar da kwaf ɗin da ake so daga kumburi a cikin yanayin rashin albarkatu akan shi, to tare da fifikon, kuna buƙatar kula da saita buƙatu / iyakance don shi.
Mechanism don a kwance autoscaling na aikace-aikace pods (HPA)
Lokacin da aikin shine ƙarawa ta atomatik da rage adadin kwasfan fayiloli dangane da amfani da albarkatun (tsarin - CPU / RAM ko mai amfani - rps), irin wannan mahallin k8s kamar HPA (Horizontal Pod Autoscaler). Algorithm nasa shine kamar haka:
- An ƙaddara karatun yanzu na albarkatun da aka lura (currentMetricValue)
- An ƙaddara ƙimar da ake so don albarkatun (desiredMetricValue), wanda don tsarin albarkatun an saita ta amfani da buƙata.
- An ƙayyade adadin kwafi na yanzu (currentReplicas)
- Dabarar mai zuwa tana ƙididdige adadin da ake so na kwafi (desiredReplicas)
da ake soReplicas = [Replicas na yanzu * ( currentMetricValue / soMetricValue)]
A wannan yanayin, sikelin ba zai faru ba lokacin da ƙididdiga (currentMetricValue / soMetricValue) ke kusa da 1 (a wannan yanayin, zamu iya saita kuskuren halal da kanmu; ta tsohuwa shine 0.1).
Bari mu kalli yadda hpa ke aiki ta amfani da misalin aikace-aikacen gwajin-app (wanda aka kwatanta da Ƙaddamarwa), inda ya zama dole a canza adadin kwafi dangane da amfani da CPU:
-
Bayanin aikace-aikacen
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-statusWadancan. Mun ga cewa an fara ƙaddamar da kwafin aikace-aikacen a cikin lokuta biyu, kowannensu ya ƙunshi kwantena nginx guda biyu da nginx-exporter, ga kowannensu ƙayyadaddun. buƙatun za CPU.
-
HPA Manifesto
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: 30Wadancan. Mun ƙirƙiri wani hpa wanda zai sa ido kan gwajin gwajin Deployment kuma ya tsara adadin kwasfan fayiloli tare da aikace-aikacen dangane da alamar cpu (muna tsammanin kwaf ɗin ya kamata ya cinye kashi 30% na CPU ɗin da yake buƙata), tare da adadin kwafin kasancewa. a cikin kewayon 2-10.
Yanzu, bari mu kalli tsarin aikin hpa idan muka sanya kaya zuwa ɗaya daga cikin murhu:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Gabaɗaya muna da abubuwa masu zuwa:
- Ƙimar da ake so (desiredMetricValue) - bisa ga saitunan hpa, muna da 30%
- Ƙimar halin yanzu (currentMetricValue) - don ƙididdigewa, mai sarrafawa-mai sarrafa yana ƙididdige matsakaicin ƙimar amfani da albarkatu a cikin%, watau. bisa sharadi yana yin haka:
- Yana karɓar cikakkiyar ƙimar ma'aunin ma'auni daga uwar garken awo, i.e. 101m da 4m
- Yana ƙididdige matsakaiciyar cikakkiyar ƙima, i.e. (101m + 4m) / 2 = 53m
- Yana samun cikakkiyar ƙimar amfanin albarkatun da ake so (don wannan, an taƙaita buƙatun duk kwantena) 60m + 30m = 90m
- Yana ƙididdige matsakaicin kaso na yawan amfanin CPU dangane da buƙatun buƙatun, watau. 53m / 90m * 100% = 59%
Yanzu muna da duk abin da muke buƙata don sanin ko muna buƙatar canza adadin kwafin; don yin wannan, muna ƙididdige ƙididdiga:
ratio = 59% / 30% = 1.96
Wadancan. ya kamata a ƙara adadin kwafi da ~ 2 sau kuma adadin zuwa [2 * 1.96] = 4.
Kammalawa: Kamar yadda kake gani, don wannan aikin ya yi aiki, yanayin da ya dace shine kasancewar buƙatun ga duk kwantena a cikin kwas ɗin da aka lura.
Injiniyanci na kwance autoscaling na nodes (Cluster Autoscaler)
Don kawar da mummunan tasiri akan tsarin yayin hawan hawan kaya, da ciwon da aka tsara hpa bai isa ba. Misali, bisa ga saitunan da ke cikin manajan mai kula da hpa, ya yanke shawarar cewa adadin kwafin yana buƙatar ƙara sau 2, amma nodes ɗin ba su da albarkatun kyauta don gudanar da irin wannan adadin kwasfa (watau kumburi ba zai iya samar da buƙatun albarkatu zuwa buƙatun buƙatun) kuma waɗannan kwas ɗin suna canzawa zuwa jihar mai jiran gado.
A wannan yanayin, idan mai bayarwa yana da daidai IaaS/PaaS (misali, GKE/GCE, AKS, EKS, da sauransu), kayan aiki kamar Node Autoscaler. Yana ba ku damar saita matsakaicin matsakaici da ƙananan adadin nodes a cikin tari kuma ta atomatik daidaita adadin nodes na yanzu (ta hanyar kiran API mai ba da girgije don yin oda / cire kumburi) lokacin da akwai ƙarancin albarkatu a cikin gungu da kwasfa. ba za a iya tsarawa ba (suna cikin Jigon Jigon).
Kammalawa: Don samun ikon sarrafa nodes, ya zama dole a saita buƙatun a cikin kwantena na kwaf ɗin don k8s su iya tantance nauyin da ke kan nodes daidai kuma don haka bayar da rahoton cewa babu albarkatu a cikin gungu don ƙaddamar da kwafsa na gaba.
ƙarshe
Ya kamata a lura cewa saita iyakokin albarkatun kwantena ba buƙatun ba ne don aiwatar da aikace-aikacen cikin nasara, amma har yanzu yana da kyau a yi hakan saboda dalilai masu zuwa:
- Don ƙarin ingantaccen aiki na mai tsarawa dangane da daidaita nauyi tsakanin nodes k8s
- Don rage yuwuwar faruwar lamarin "korar da tafki".
- Don a kwance autoscaling na aikace-aikace pods (HPA) aiki
- Don a kwance autoscaling na nodes (Cluster Autoscaling) don masu samar da girgije
Hakanan karanta wasu labarai akan shafinmu:
source: www.habr.com