Sakumaha aturan, sok aya kabutuhan pikeun nyayogikeun sumber daya khusus pikeun aplikasi pikeun operasi anu leres sareng stabil. Tapi kumaha upami sababaraha aplikasi dijalankeun dina kakuatan anu sami? Kumaha cara nyayogikeun masing-masing sumber daya anu diperyogikeun? Kumaha anjeun tiasa ngawatesan konsumsi sumberdaya? Kumaha leres ngadistribusikaeun beban antara titik? Kumaha carana mastikeun mékanisme skala horizontal jalan lamun beban aplikasi naek?
Anjeun kedah mimitian ku naon jinis sumber utama anu aya dina sistem - ieu, tangtosna, waktos prosésor sareng RAM. Dina k8s manifests jenis sumberdaya ieu diukur dina unit handap:
- CPU - dina cores
- RAM - dina bait
Sumawona, pikeun unggal sumber tiasa nyetél dua jinis syarat - requests и wates. Requests - ngajelaskeun sarat minimum pikeun bebas sumberdaya titik pikeun ngajalankeun wadahna (jeung pod sakabéhna), bari wates nangtukeun hiji wates teuas dina sumberdaya sadia pikeun wadahna.
Kadé ngartos yen manifest teu kudu eksplisit nangtukeun duanana jenis, tapi kabiasaan bakal kieu:
- Upami ngan ukur wates sumberdaya anu ditetepkeun sacara eksplisit, teras pamundut sumberdaya ieu otomatis nyandak nilai anu sami sareng wates (anjeun tiasa pariksa ku nelepon ngajelaskeun éntitas). Jelema. komo, wadahna bakal dugi ka jumlah sarua sumberdaya merlukeun ngajalankeun.
- Lamun ngan requests anu eksplisit dieusian pikeun sumberdaya a, lajeng euweuh larangan luhur diatur dina sumberdaya ieu - i.e. wadahna diwatesan ngan ku sumberdaya titik sorangan.
Éta ogé mungkin pikeun ngonpigurasikeun manajemén sumberdaya sanés ngan ukur dina tingkat wadah khusus, tapi ogé dina tingkat ngaranspasi ngagunakeun éntitas ieu:
- LimitRange — ngajelaskeun kabijakan larangan dina tingkat wadah/pod di ns sareng dipikabutuh pikeun ngajelaskeun larangan standar dina wadah/pod, ogé nyegah nyiptakeun wadah/pods anu jelas lemak (atanapi sabalikna), ngawatesan jumlahna jeung nangtukeun kamungkinan bédana dina nilai dina wates jeung requests
- SumberdayaKuota - ngajelaskeun kabijakan larangan sacara umum pikeun sadaya wadah dina ns sareng dianggo, sakumaha aturan, pikeun ngawatesan sumberdaya diantara lingkungan (mangpaat nalika lingkungan henteu didemarkasi sacara ketat dina tingkat titik)
Di handap ieu conto manifests nu nangtukeun wates sumberdaya:
-
Dina tingkat wadah husus:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mJelema. dina hal ieu, pikeun ngajalankeun wadah kalawan nginx, anjeun bakal kedah sahanteuna 1G RAM bébas tur 0.2 CPU on node, bari di paling wadahna bisa meakeun 0.2 CPU jeung sagala RAM sadia on node.
-
Dina tingkat integer ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiJelema. jumlah sadaya peti pamundut di ns standar teu bisa ngaleuwihan 300m pikeun CPU jeung 1G pikeun OP, sarta jumlah sadaya wates nyaéta 700m pikeun CPU jeung 2G pikeun OP.
-
Wates standar pikeun wadah dina 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: 4GiJelema. dina namespace standar pikeun sakabéh peti, pamundut bakal disetel ka 100m pikeun CPU jeung 1G pikeun OP, wates - 1 CPU jeung 2G. Dina waktos anu sami, wates ogé disetél dina nilai anu mungkin dina pamundut / wates pikeun CPU (50m <x <2) sareng RAM (500M <x <4G).
-
Watesan tingkat pod ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiJelema. pikeun tiap pod di ns standar bakal aya wates 4 vCPU na 1G.
Ayeuna kuring hoyong nyarioskeun ka anjeun naon kauntungan anu tiasa dipasihkeun ku netepkeun larangan ieu.
Mékanisme kasaimbangan beban antara titik
Anjeun terang, komponén k8s jawab sebaran pods diantara titik, kayaning scheduler, nu gawéna nurutkeun algoritma husus. Algoritma ieu ngalangkungan dua tahap nalika milih titik anu optimal pikeun diluncurkeun:
- nyaring
- ngariung
Jelema. Numutkeun kabijakan anu dijelaskeun, titik-titik mimitina dipilih dimana anjeun tiasa ngaluncurkeun pod dumasar kana set predikat (kaasup mariksa naha titik boga cukup sumberdaya pikeun ngajalankeun pod - PodFitsResources), lajeng pikeun tiap titik ieu, nurutkeun prioritas titik dileler (kaasup, sumber daya leuwih bébas hiji node, beuki titik eta ditugaskeun - LeastResourceAllocation / LeastRequestedPriority / BalanceResourceAllocation) jeung pod diluncurkeun dina titik kalawan titik paling (lamun sababaraha titik nyugemakeun kaayaan ieu sakaligus, lajeng hiji acak dipilih).
Dina waktos anu sami, anjeun kedah ngartos yén penjadwal, nalika ngira-ngira sumber daya anu aya tina titik, dipandu ku data anu disimpen dina etcd - i.e. pikeun jumlah dipénta / sumberdaya wates unggal pod ngajalankeun on titik ieu, tapi teu keur konsumsi sumberdaya sabenerna. Inpo ieu tiasa didapet tina kaluaran paréntah kubectl describe node $NODEContona:
# 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%)Di dieu urang ningali sadaya pods ngajalankeun dina titik husus, kitu ogé sumberdaya nu unggal pod requests. Sareng ieu sapertos kumaha log penjadwal nalika pod cronjob-cron-events-1573793820-xt6q9 diluncurkeun (inpormasi ieu bakal muncul dina log scheduler nalika anjeun nyetél tingkat logging ka-10 dina argumen paréntah ngamimitian -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-s10Di dieu urang tingali yén mimitina scheduler nyaring sarta dibangkitkeun daptar 3 titik dimana eta bisa dibuka (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Lajeng ngitung skor dumasar kana sababaraha parameter (kaasup BalancedResourceAllocation, LeastResourceAllocation) pikeun tiap titik ieu guna nangtukeun titik paling merenah. Pamustunganana, pod dijadwalkeun dina titik kalawan jumlah pangluhurna titik (di dieu dua titik sakaligus boga angka sarua titik 100037, jadi hiji acak dipilih - nxs-k8s-s10).
kacindekan: lamun hiji titik ngajalankeun pods nu euweuh larangan diatur, lajeng pikeun k8s (ti sudut pandang konsumsi sumberdaya) ieu bakal sarua jeung saolah-olah euweuh pods misalna dina titik ieu pisan. Ku alatan éta, lamun anjeun, conditionally, boga pod kalawan prosés gluttonous (contona, wowza) jeung euweuh larangan diatur pikeun eta, kaayaan bisa timbul nalika pod ieu sabenerna ngahakan sagala sumberdaya titik, tapi pikeun k8s titik ieu. dianggap unloaded sarta eta bakal dileler jumlah sarua titik nalika ranking (persis dina titik assessing sumberdaya sadia) salaku titik nu teu boga pods digawé, nu pamustunganana bisa ngakibatkeun distribusi henteu rata beban antara titik.
pangusir Pod
Sakumaha anjeun terang, unggal pod ditugaskeun salah sahiji tina 3 kelas QoS:
- dijamin - ditugaskeun nalika unggal wadah dina pod aya pamundut sareng wates pikeun mémori sareng CPU, sareng nilai-nilai ieu kedah cocog.
- burstable - sahanteuna hiji wadah dina pod boga pamundut na wates, kalawan pamundut < wates
- usaha pangsaéna - lamun teu wadah tunggal dina pod nu sumberdaya kawates
Dina waktos anu sami, nalika node ngalaman kakurangan sumberdaya (disk, mémori), kubelet mimiti pangkat sareng ngusir pods dumasar kana algoritma khusus anu tumut kana prioritas pod sareng kelas QoS na. Salaku conto, upami urang ngobrol ngeunaan RAM, teras dumasar kana kelas QoS, poin dileler dumasar kana prinsip ieu:
- dijamin: -998
- BestEffort: 1000
- Burstable: mnt(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Jelema. kalawan prioritas sarua, kubelet bakal mimiti nundung pods kalawan pangalusna usaha kelas QoS ti titik.
kacindekan: upami anjeun hoyong ngirangan kamungkinan pod anu dipikahoyong diusir tina titik upami aya kakurangan sumber daya, teras sareng prioritas, anjeun ogé kedah ngurus netepkeun pamundut / wates pikeun éta.
Mékanisme pikeun autoscaling horizontal tina pod aplikasi (HPA)
Nalika tugasna nyaéta sacara otomatis ningkatkeun sareng ngirangan jumlah pods gumantung kana pamakean sumberdaya (sistem - CPU / RAM atanapi pangguna - rps), éntitas k8s sapertos. HPA (Horizontal Pod Autoscaler). Algoritma di antarana nyaéta kieu:
- Bacaan ayeuna tina sumber anu dititénan ditangtukeun (currentMetricValue)
- Nilai-nilai anu dipikahoyong pikeun sumberdaya ditangtukeun (desiredMetricValue), anu pikeun sumber sistem diatur nganggo pamundut.
- Jumlah réplika ayeuna ditangtukeun (currentReplicas)
- Rumus di handap ieu ngitung jumlah réplika anu dipikahoyong (Replicas anu dipikahoyong)
desiredReplicas = [Replicas ayeuna * (currentMetricValue / desiredMetricValue)]
Dina hal ieu, skala moal lumangsung nalika koefisien (currentMetricValue / desiredMetricValue) deukeut ka 1 (dina hal ieu, urang tiasa nyetel kasalahan diidinan sorangan; sacara standar éta 0.1).
Hayu urang tingali kumaha hpa dianggo nganggo conto aplikasi uji-aplikasi (digambarkeun salaku Deployment), dimana anjeun kedah ngarobih jumlah réplika gumantung kana konsumsi CPU:
-
Manifestasi aplikasi
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-statusJelema. urang tingali yén pod aplikasi mimitina diluncurkeun dina dua instansi, anu masing-masing ngandung dua wadah nginx sareng eksportir nginx, anu masing-masing ditunjukkeun. requests pikeun CPU.
-
Manifesto 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: 30Jelema. Kami nyiptakeun hpa anu bakal ngawas tés aplikasi Deployment sareng nyaluyukeun jumlah pod sareng aplikasi dumasar kana indikator cpu (kami ngarepkeun yén pod kedah ngonsumsi 30% tina CPU anu dipénta), kalayan jumlah réplika anu aya. rentang 2-10.
Ayeuna, hayu urang tingali mékanisme operasi hpa upami urang nerapkeun beban ka salah sahiji tungku:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Dina total urang gaduh di handap:
- Nilai anu dipikahoyong (desiredMetricValue) - dumasar kana setélan hpa, urang gaduh 30%
- nilai ayeuna (currentMetricValue) - pikeun itungan, controller-manajer ngitung nilai rata konsumsi sumberdaya di%, i.e. conditionally ngalakukeun di handap:
- Nampi nilai mutlak métrik pod tina server métrik, nyaéta. 101m jeung 4m
- Ngitung nilai mutlak rata, i.e. (101m + 4m) / 2 = 53m
- Kéngingkeun nilai mutlak pikeun konsumsi sumber daya anu dipikahoyong (pikeun ieu, paménta sadaya wadah dijumlahkeun) 60m + 30m = 90m
- Ngitung persentase rata-rata konsumsi CPU relatif ka pod pamundut, i.e. 53m / 90m * 100% = 59%
Ayeuna urang gaduh sadayana anu urang peryogikeun pikeun nangtukeun naha urang kedah ngarobih jumlah réplika; pikeun ngalakukeun ieu, urang ngitung koefisien:
ratio = 59% / 30% = 1.96
Jelema. Jumlah réplika kedah dironjatkeun ku ~2 kali sareng jumlahna [2 * 1.96] = 4.
kacindekan: Sakumaha anjeun tiasa tingali, supados mékanisme ieu tiasa dianggo, kaayaan anu dipikabutuh nyaéta ayana paménta pikeun sadaya wadah dina pod anu dititénan.
Mékanisme pikeun autoscaling horisontal titik (Cluster Autoscaler)
Pikeun nétralisasi dampak négatip dina sistem nalika beban surge, gaduh hpa ngonpigurasi henteu cekap. Salaku conto, dumasar kana setélan dina manajer pangontrol hpa, éta mutuskeun yén jumlah réplika kedah dironjatkeun ku 2 kali, tapi titik henteu gaduh sumber daya gratis pikeun ngajalankeun sajumlah pods sapertos kitu (nyaéta titik henteu tiasa nyayogikeun sumberdaya dipénta kana requests pod) jeung pods ieu pindah ka kaayaan Pending.
Dina hal ieu, upami panyadia gaduh IaaS / PaaS anu saluyu (contona, GKE / GCE, AKS, EKS, jsb.), alat sapertos Node Autoscaler. Éta ngamungkinkeun anjeun nyetél jumlah maksimum sareng minimum titik dina kluster sareng sacara otomatis nyaluyukeun jumlah titik ayeuna (ku nyauran API panyadia awan pikeun mesen / ngahapus titik) nalika aya kakurangan sumberdaya dina kluster sareng pods. teu bisa dijadwalkeun (aya dina kaayaan Pending).
kacindekan: Pikeun bisa autoscale titik, perlu pikeun ngeset requests dina wadah pod ambéh k8s bener bisa assess beban dina titik jeung sasuai ngalaporkeun yén euweuh sumberdaya di kluster pikeun ngajalankeun pod salajengna.
kacindekan
Ieu kudu dicatet yén netepkeun wates sumberdaya wadahna teu sarat pikeun aplikasi pikeun ngajalankeun suksés, tapi tetep hadé pikeun ngalakukeunana pikeun alesan ieu:
- Pikeun operasi leuwih akurat tina scheduler dina watesan beban balancing antara titik k8s
- Pikeun ngirangan kamungkinan kajadian "pengusiran pod".
- Pikeun autoscaling horizontal pod aplikasi (HPA) jalan
- Pikeun autoscaling horizontal titik (Cluster Autoscaling) pikeun panyadia awan
Baca ogé artikel séjén dina blog urang:
sumber: www.habr.com