Wekî qaîdeyek, her gav hewce ye ku ji bo xebata wê ya rast û bi îstîqrar hewzek jêderan a serîlêdanê peyda bike. Lê heke çend serîlêdan li ser heman hêzê têne xebitandin? Meriv çawa her yek ji wan çavkaniyên herî hindik ên pêwîst peyda dike? Hûn çawa dikarin serfkariya çavkaniyê sînordar bikin? Meriv çawa barkirinê di navbera nokan de rast belav dike? Ger barkirina serîlêdanê zêde bibe meriv çawa pê ewle dibe ku mekanîzmaya pîvana horizontî dixebite?
Pêdivî ye ku hûn bi kîjan cûreyên sereke yên çavkaniyên di pergalê de hene dest pê bikin - ev, bê guman, dema pêvajoyê û RAM e. Di diyardeyên k8 de ev celeb çavkaniyê di yekîneyên jêrîn de têne pîvandin:
- CPU - di navan de
- RAM - li bytes
Digel vê yekê, ji bo her çavkaniyek gengaz e ku du celeb hewcedar werin danîn - daxwazan и Sînor. Daxwaz - hewcedariyên hindiktirîn ên çavkaniyên belaş ên girêkek diyar dike ku konteynerek (û bi tevahî pod) bi rê ve bibe, dema ku sînor li ser çavkaniyên berdest ên konteynerê sînorek dijwar destnîşan dike.
Girîng e ku meriv fam bike ku manîfesto ne hewce ye ku her du celeb bi eşkere diyar bike, lê tevger dê wiha be:
- Ger tenê sînorên çavkaniyekê bi eşkereyî hatine destnîşan kirin, wê hingê daxwazên vê çavkaniyê bixweber nirxek wekhev bi sînoran digire (hûn dikarin vê yekê bi gazîkirina hebûnên diyarkirî verast bikin). Ewan. di rastiyê de, konteynir dê bi heman mîqdara çavkaniyên ku ji bo xebitandinê hewce dike were sînordar kirin.
- Ger ji bo çavkaniyekê tenê daxwaz bi eşkere têne destnîşan kirin, wê hingê ti sînorkirinên jorîn li ser vê çavkaniyê nayên danîn - ango. konteynir tenê ji hêla çavkaniyên girêk bixwe ve tê sînorkirin.
Di heman demê de gengaz e ku meriv rêveberiya çavkaniyê ne tenê di asta konteynirek taybetî de, lê di heman demê de di asta cîhê navan de jî bi karanîna saziyên jêrîn veava bike:
- LimitRange - Siyaseta sînordarkirinê di asta konteynir/pod de di ns de diyar dike û ji bo danasîna tixûbên xwerû yên li ser konteynir/pod, û hem jî pêşîgirtina çêkirina konteynir/podên eşkere qelew (an jî berevajî), pêdivî ye ku jimara wan sînordar bike. û cûdahiya gengaz di nirxan de di nav sînor û daxwazan de diyar bikin
- ResourceQuotas - Siyaseta sînordarkirinê bi gelemperî ji bo hemî konteynerên di ns-ê de diyar bike û, wekî qaîdeyek, ji bo veqetandina çavkaniyan di nav hawîrdoran de tê bikar anîn (bikêr e dema ku jîngeh bi hişkî di asta girêkê de neyên veqetandin)
Li jêr mînakên diyardeyên ku sînorên çavkaniyê destnîşan dikin hene:
-
Di asta konteynerê taybetî de:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mEwan. Di vê rewşê de, ji bo ku hûn konteynirek bi nginx bimeşînin, hûn ê herî kêm 1G RAM-a belaş û 0.2 CPU li ser girêkê hewce bikin, di heman demê de herî zêde konteynir dikare 0.2 CPU û hemî RAM-a berdest li ser girêkê vexwe.
-
Di asta yekjimar de ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiEwan. berhevoka hemî konteynerên daxwazê yên di nsên xwerû de nikare ji 300 m ji bo CPU û 1G ji bo OP-ê derbas bibe, û berhevoka hemî sînor ji bo CPU 700 m û ji bo OP-ê 2G ye.
-
Sînorên xwerû yên ji bo konteynerên li 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: 4GiEwan. di nav cîhê xwerû ji bo hemî konteyneran de, daxwaz dê ji bo CPU 100 m û ji bo OP 1G, sînor - 1 CPU û 2G were danîn. Di heman demê de, ji bo CPU (50m < x < 2) û RAM (500M < x < 4G) li ser nirxên gengaz ên di daxwaz / sînor de jî sînorek tête danîn.
-
Qedexeyên asta pod ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiEwan. ji bo her podek di nsên xwerû de dê sînorek 4 vCPU û 1G hebe.
Naha ez dixwazim ji we re bibêjim ka danîna van qedexeyan dikare çi feydeyan bide me.
Mekanîzmaya hevsengkirina barkirinê di navbera girêkan de
Wekî ku hûn dizanin, pêkhateya k8s berpirsiyariya belavkirina pods di nav girêkan de ye, wek mînak timedar, ku li gorî algorîtmayek taybetî dixebite. Ev algorîtma dema ku girêka çêtirîn ji bo destpêkirinê hilbijêrin du qonaxan derbas dibe:
- Fîlterkirin
- Ranging
Ewan. li gorî polîtîkaya diyarkirî, di destpêkê de girêk têne hilbijartin ku li ser wan gengaz e ku li ser bingehek pêvekek were destpêkirin predicates (tevî kontrolkirina ka girêk têra xwe çavkaniyên ku pod bimeşîne - PodFitsResources), û dûv re ji bo her yek ji van girêkan, li gorî Peş pûan têne xelat kirin (di nav de, girêkek çiqas bêtir çavkaniyên belaş hebin, ew qas bêtir xal têne destnîşan kirin - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) û pod li ser girêka ku herî zêde pûan lê digire tê dest pê kirin (eger çend girêk bi carekê vê şertê têr bikin, wê hingê yekî rasthatî tê hilbijartin).
Di heman demê de, hûn hewce ne ku fêm bikin ku plansazker, dema ku çavkaniyên berdest ên nodek dinirxîne, ji hêla daneyên ku di etcd de têne hilanîn ve tê rêve kirin - ango. ji bo mîqdara çavkaniya tê xwestin/sînor a her podek ku li ser vê girêkê dimeşe, lê ne ji bo xerckirina çavkaniyê ya rastîn. Ev agahdarî dikare ji derketina fermanê were wergirtin kubectl describe node $NODE, wek nimûne:
# 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%)Li vir em hemî podên ku li ser nodek taybetî dixebitin, û hem jî çavkaniyên ku her pod daxwaz dike dibînin. Û li vir ev e ku dema ku cronjob-cron-events-1573793820-xt6q9 pod dest pê dike, têketinên plansazker çawa xuya dikin (ev agahdarî dê di têketina plansazkerê de xuya bibe dema ku asta 10-emîn têketinê di argumanên fermana destpêkirinê de were danîn -v=10 ):
darbend
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-s10Li vir em dibînin ku di destpêkê de plansazkar fîlter dike û navnîşek ji 3 nodên ku ew dikare were destpêkirin çêdike (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Dûv re ew li ser çend pîvanan (di nav de BalancedResourceAllocation, LeastResourceAllocation) ji bo her yek ji van girêkan puanan hesab dike da ku girêka herî guncaw diyar bike. Di dawiyê de, pod li ser girêka xwedan hejmara xalên herî zêde tê plansaz kirin (li vir du girêk yekcar xwedî heman hejmara xalan in 100037, ji ber vê yekê yek rasthatî tê hilbijartin - nxs-k8s-s10).
encamê: heke girêkek podên ku ji bo wan ti sînor nehatine danîn bimeşîne, wê hingê ji bo k8 (ji hêla xerckirina çavkaniyê ve) ev ê wekhev be mîna ku li ser vê girêkê qet pêlên weha tune bin. Ji ber vê yekê, heke hûn, bi şert, xwedî podek bi pêvajoyek gewre (mînak, wowza) hebe û ji bo wê ti sînordar nehatine danîn, wê hingê dibe ku rewşek çêbibe dema ku vê pod bi rastî hemî çavkaniyên girêk xwar, lê ji bo k8 ev girêk nebarkirî tê hesibandin û dema ku bi rêzgirtinê (bi rastî di xalên ku çavkaniyên berdest dinirxînin) wekî girêkek ku xwedan pêlên xebatê ne, dê heman hejmara xalan werbigire, ku di dawiyê de dikare bibe sedema belavkirina neyeksan a barkirinê di navbera girêkan de.
Derxistina Pod
Wekî ku hûn dizanin, her pod yek ji 3 dersên QoS-ê têne destnîşan kirin:
- garantî kirin - dema ku ji bo her konteynerek di binavê de daxwazek û sînorek ji bo bîranîn û cpu tête diyar kirin, û divê ev nirx li hev bikin.
- teqandin - Bi kêmanî yek konteynir di binavê de daxwazek û sînorek heye, bi daxwaz <sînor
- hewla çêtirîn - gava ku ne yek konteynir di podê de çavkanî sînordar be
Di heman demê de, dema ku nodek kêmbûna çavkaniyan (dîsk, bîranîn) tecrûbir dike, kubelet dest bi rêzkirin û derxistina podan li gorî algorîtmayek taybetî dike ku pêşîniya pod û çîna QoS ya wê digire ber çavan. Mînakî, heke em li ser RAM-ê diaxivin, wê hingê li ser bingeha çîna QoS, xal li gorî prensîba jêrîn têne dayîn:
- Guaranteed:-998
- BestEffort: 1000
- Burstable: min(herî zêde (2, 1000 - (1000 * bîraRequestBytes) / makîneMemoryCapacityBytes), 999)
Ewan. bi heman pêşanî, kubelet dê pêşî bi hewildana herî baş a çîna QoS-ê ji girêkê potan derxe.
encamê: Heke hûn dixwazin di bûyera kêmbûna çavkaniyan de îhtîmala derxistina podê xwestinê ji girêkê kêm bikin, wê hingê digel pêşîniyê, hûn hewce ne ku ji bo danîna daxwaz/sînorê jî baldar bin.
Mekanîzmaya ji bo pîvandina otomatîkî ya horizontî ya podên serîlêdanê (HPA)
Dema ku peywir ew e ku bixweber li gorî karanîna çavkaniyan (pergal - CPU/RAM an bikarhêner - rps) hejmara podan zêde û kêm bike, saziyek k8s wekî HPA (Horizontal Pod Autoscaler). Algorîtmaya wê wiha ye:
- Xwendinên heyî yên çavkaniya çavdêriyê têne destnîşankirin (currentMetricValue)
- Nirxên xwestinê yên ji bo çavkaniyê têne destnîşan kirin (desiredMetricValue), ku ji bo çavkaniyên pergalê bi karanîna daxwazê têne danîn
- Hejmara niha ya kopiyan tê diyarkirin (currentReplicas)
- Formula jêrîn hejmara kopî ya xwestî dihesibîne (Replicayên xwestî)
xwestinReplicas = [Replikayên niha * (NirxMetricValue / nirxMetricValue ya xwestin)]
Di vê rewşê de, pîvandin çênabe dema ku hevseng (currentMetricValue / metricValue tê xwestin) nêzîkê 1 be (di vê rewşê de, em dikarin bi xwe xeletiya destûrdar saz bikin; bi xwerû ew 0.1 e).
Ka em binihêrin ka hpa çawa bi karanîna mînaka serîlêdana testa sepanê (wekî Deployment tê binav kirin), dixebite, li cihê ku pêdivî ye ku li gorî xerckirina CPU-yê hejmara kopiyan biguhezîne:
-
Daxuyaniya serîlêdanê
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-statusEwan. em dibînin ku pod serîlêdanê di destpêkê de di du mînakan de tê destpêkirin, ku her yek ji wan du konteynerên nginx û nginx-exporter dihewîne, ji bo her yekê ji wan yek diyarkirî ye. daxwazan ji bo CPU.
-
Manîfestoya 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: 30Ewan. Me hpaek çêkir ku dê testa sepana Dabeşkirinê bişopîne û bi serîlêdanê re li ser bingeha nîşana cpu-yê hejmara podan birêkûpêk bike (em li bendê ne ku pod divê ji sedî 30% CPU-ya ku ew daxwaz dike vexwe), digel ku hejmara kopiyan di navbera 2-10 de.
Naha, ka em li mekanîzmaya xebata hpa binihêrin ger em barek li yek ji kulman bicîh bikin:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Bi tevahî, me yên jêrîn hene:
- Nirxa xwestinê (xwestîMetricValue) - li gorî mîhengên hpa, %30 me heye
- Nirxa heyî (currentMetricValue) - ji bo hesabkirinê, kontrolker-rêveber nirxa navînî ya xerckirina çavkaniyê bi % dihesibîne, ango. bi şertê jêrîn dike:
- Nirxên bêkêmasî yên metrîkên pod ji servera metrîk distîne, ango. 101 m û 4 m
- Nirxa mutleq ya navîn hesab dike, yanî. (101m + 4m) / 2 = 53m
- Ji bo xerckirina çavkaniya xwestinê nirxa bêkêmasî digire (ji bo vê yekê, daxwazên hemî konteyneran têne berhev kirin) 60m + 30m = 90m
- Rêjeya navînî ya xerckirina CPU-yê li gorî podê daxwazê hesab dike, ango. 53 m / 90 m * 100% = 59%
Naha her tiştê me heye ku em diyar bikin ka em hewce ne ku jimara kopiyan biguhezînin da ku vê yekê bikin, em qasê hesab dikin:
ratio = 59% / 30% = 1.96
Ewan. divê hejmara kopiyan ~ 2 qatan zêde bibe û bibe [2 * 1.96] = 4.
Encam: Wekî ku hûn dikarin bibînin, ji bo ku ev mekanîzma bixebite, şertek pêwîst hebûna daxwazên ji bo hemî konteyneran di binavê çavdêriyê de ye.
Mekanîzmaya ji bo pîvandina xweseriya horîzontal a girêkan (Cluster Autoscaler)
Ji bo bêbandorkirina bandora neyînî ya li ser pergalê di dema barkirinê de, hebûna hpa-ya mîhengkirî ne bes e. Mînakî, li gorî mîhengên di rêvebirê kontrolkerê hpa-yê de, ew biryar dide ku pêdivî ye ku hejmara kopiyan 2 carî were zêdekirin, lê girêkan ne xwediyê çavkaniyên belaş in ku hejmareke weha ji pods bimeşînin (ango nod nikare peyda bike çavkaniyên daxwazkirî ji bo pod daxwazan) û van pods veguherîne rewşa li benda.
Di vê rewşê de, heke pêşkêşker xwediyê IaaS / PaaS-ya têkildar be (mînak, GKE / GCE, AKS, EKS, hwd.), amûrek mîna Node Autoscaler. Ew dihêle hûn di komê de herî zêde û hindiktirîn hejmara girêkan saz bikin û bixweber hejmara girêkên heyî biguhezînin (bi gazîkirina API-ya pêşkêşkarê ewr da ku girêkek ferman bide/derbixe) dema ku di komê û potan de kêmbûna çavkaniyan hebe. nekare were plansaz kirin (di dewleta Li bendê de ne).
Encam: Ji bo ku meriv bikaribe girêkan bixweber bike, pêdivî ye ku di konteynerên pod de daxwaz werin danîn da ku k8 bikarin barkirina li ser girêkan rast binirxînin û li gorî vê yekê rapor bikin ku di komê de çavkanî tune ku podê din bidin destpêkirin.
encamê
Pêdivî ye ku were zanîn ku danîna sînorên çavkaniya konteynerê ne pêdivî ye ku serîlêdan bi serfirazî bixebite, lê dîsa jî çêtir e ku meriv wiya ji ber sedemên jêrîn bike:
- Ji bo xebata rasttir a plansazker di warê hevsengiya barkirinê de di navbera girêkên k8s de
- Ji bo kêmkirina îhtîmala rûdana bûyerek "derxistina pod".
- Ji bo xebitandina xweseriya horizontî ya podên serîlêdanê (HPA).
- Ji bo xweseriya horizontî ya girêkan (Cluster Autoscaling) ji bo pêşkêşkerên ewr
Her weha gotarên din ên li ser bloga me bixwînin:
Source: www.habr.com