Sebagai peraturan, sentiasa ada keperluan untuk menyediakan kumpulan sumber khusus kepada aplikasi untuk operasi yang betul dan stabil. Tetapi bagaimana jika beberapa aplikasi berjalan pada kuasa yang sama? Bagaimana untuk menyediakan setiap daripada mereka dengan sumber minimum yang diperlukan? Bagaimanakah anda boleh mengehadkan penggunaan sumber? Bagaimana untuk mengagihkan beban antara nod dengan betul? Bagaimana untuk memastikan mekanisme penskalaan mendatar berfungsi jika beban aplikasi meningkat?
Anda perlu bermula dengan jenis sumber utama yang wujud dalam sistem - ini, sudah tentu, adalah masa pemproses dan RAM. Dalam manifes k8s jenis sumber ini diukur dalam unit berikut:
- CPU - dalam teras
- RAM - dalam bait
Selain itu, untuk setiap sumber adalah mungkin untuk menetapkan dua jenis keperluan - permintaan ΠΈ had. Permintaan - menerangkan keperluan minimum untuk sumber percuma nod untuk menjalankan bekas (dan pod secara keseluruhan), manakala had menetapkan had keras pada sumber yang tersedia untuk bekas.
Adalah penting untuk memahami bahawa manifes tidak perlu mentakrifkan kedua-dua jenis secara eksplisit, tetapi gelagatnya adalah seperti berikut:
- Jika hanya had sumber dinyatakan secara eksplisit, maka permintaan untuk sumber ini secara automatik mengambil nilai yang sama dengan had (anda boleh mengesahkan ini dengan memanggil entiti huraikan). Itu. sebenarnya, kontena akan dihadkan kepada jumlah sumber yang sama yang diperlukan untuk dijalankan.
- Jika hanya permintaan dinyatakan secara eksplisit untuk sumber, maka tiada sekatan atas ditetapkan pada sumber ini - i.e. bekas hanya dihadkan oleh sumber nod itu sendiri.
Ia juga mungkin untuk mengkonfigurasi pengurusan sumber bukan sahaja pada tahap bekas tertentu, tetapi juga pada peringkat ruang nama menggunakan entiti berikut:
- Julat Had β menerangkan dasar sekatan pada tahap bekas/pod dalam ns dan diperlukan untuk menerangkan had lalai pada bekas/pod, serta menghalang penciptaan bekas/pod yang jelas gemuk (atau sebaliknya), hadkan bilangannya dan tentukan kemungkinan perbezaan dalam nilai dalam had dan permintaan
- Kuota Sumber β menerangkan dasar sekatan secara umum untuk semua bekas dalam ns dan digunakan, sebagai peraturan, untuk mengehadkan sumber antara persekitaran (berguna apabila persekitaran tidak ditandakan dengan ketat pada tahap nod)
Berikut ialah contoh manifes yang menetapkan had sumber:
-
Pada tahap kontena tertentu:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mItu. dalam kes ini, untuk menjalankan bekas dengan nginx, anda memerlukan sekurang-kurangnya 1G RAM percuma dan 0.2 CPU pada nod, manakala paling banyak bekas boleh menggunakan 0.2 CPU dan semua RAM yang tersedia pada nod.
-
Pada tahap integer ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiItu. jumlah semua bekas permintaan dalam ns lalai tidak boleh melebihi 300m untuk CPU dan 1G untuk OP, dan jumlah semua had ialah 700m untuk CPU dan 2G untuk OP.
-
Had lalai untuk bekas dalam 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: 4GiItu. dalam ruang nama lalai untuk semua bekas, permintaan akan ditetapkan kepada 100m untuk CPU dan 1G untuk OP, had - 1 CPU dan 2G. Pada masa yang sama, had juga ditetapkan pada nilai yang mungkin dalam permintaan/had untuk CPU (50m < x < 2) dan RAM (500M < x < 4G).
-
Sekatan peringkat pod ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiItu. untuk setiap pod dalam ns lalai akan ada had 4 vCPU dan 1G.
Sekarang saya ingin memberitahu anda apakah kelebihan yang boleh diberikan oleh penetapan sekatan ini kepada kami.
Mekanisme pengimbangan beban antara nod
Seperti yang anda ketahui, komponen k8s bertanggungjawab untuk pengedaran pod antara nod, seperti penjadual, yang berfungsi mengikut algoritma tertentu. Algoritma ini melalui dua peringkat apabila memilih nod optimum untuk dilancarkan:
- penapisan
- Bermula
Itu. mengikut dasar yang diterangkan, nod pada mulanya dipilih di mana ia mungkin untuk melancarkan pod berdasarkan set predikat (termasuk menyemak sama ada nod mempunyai sumber yang mencukupi untuk menjalankan pod - PodFitsResources), dan kemudian untuk setiap nod ini, mengikut keutamaan mata diberikan (termasuk, lebih banyak sumber percuma yang dimiliki oleh nod, lebih banyak mata yang diberikan - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) dan pod dilancarkan pada nod dengan mata terbanyak (jika beberapa nod memenuhi syarat ini sekaligus, maka satu rawak dipilih) .
Pada masa yang sama, anda perlu memahami bahawa penjadual, apabila menilai sumber yang tersedia bagi nod, dipandu oleh data yang disimpan dalam etcd - i.e. untuk jumlah sumber yang diminta/had bagi setiap pod yang berjalan pada nod ini, tetapi bukan untuk penggunaan sumber sebenar. Maklumat ini boleh diperolehi daripada output arahan kubectl describe node $NODE, sebagai contoh:
# 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 sini kita melihat semua pod berjalan pada nod tertentu, serta sumber yang diminta oleh setiap pod. Dan inilah rupa log penjadual apabila pod cronjob-cron-events-1573793820-xt6q9 dilancarkan (maklumat ini akan muncul dalam log penjadual apabila anda menetapkan tahap pengelogan ke-10 dalam argumen perintah permulaan -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 sini kita melihat bahawa pada mulanya penjadual menapis dan menjana senarai 3 nod yang mana ia boleh dilancarkan (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Kemudian ia mengira skor berdasarkan beberapa parameter (termasuk BalancedResourceAllocation, LeastResourceAllocation) untuk setiap nod ini untuk menentukan nod yang paling sesuai. Akhirnya, pod dijadualkan pada nod dengan bilangan mata tertinggi (di sini dua nod sekaligus mempunyai bilangan mata yang sama 100037, jadi satu rawak dipilih - nxs-k8s-s10).
Output: jika nod menjalankan pod yang tiada sekatan ditetapkan, maka untuk k8s (dari sudut penggunaan sumber) ini akan bersamaan dengan seolah-olah tiada pod sedemikian pada nod ini sama sekali. Oleh itu, jika anda, secara bersyarat, mempunyai pod dengan proses pelahap (contohnya, wowza) dan tiada sekatan ditetapkan untuknya, maka situasi mungkin timbul apabila pod ini benar-benar memakan semua sumber nod, tetapi untuk k8s nod ini dianggap tidak dimuatkan dan ia akan diberikan bilangan mata yang sama apabila kedudukan (tepatnya dalam mata menilai sumber yang tersedia) sebagai nod yang tidak mempunyai pod berfungsi, yang akhirnya boleh menyebabkan pengagihan beban yang tidak sekata antara nod.
Pengusiran Pod
Seperti yang anda ketahui, setiap pod diberikan satu daripada 3 kelas QoS:
- terjamin β diberikan apabila untuk setiap bekas dalam pod permintaan dan had ditentukan untuk memori dan cpu, dan nilai ini mesti sepadan
- boleh pecah β sekurang-kurangnya satu bekas dalam pod mempunyai permintaan dan had, dengan permintaan < had
- usaha terbaik β apabila tiada satu bekas dalam pod adalah sumber terhad
Pada masa yang sama, apabila nod mengalami kekurangan sumber (cakera, memori), kubelet mula memberi kedudukan dan mengusir pod mengikut algoritma tertentu yang mengambil kira keutamaan pod dan kelas QoSnya. Sebagai contoh, jika kita bercakap tentang RAM, maka berdasarkan kelas QoS, mata diberikan mengikut prinsip berikut:
- Dijamin: -998
- Usaha Terbaik: 1000
- Boleh pecah: min(maks(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Itu. dengan keutamaan yang sama, kubelet akan mengusir pod terlebih dahulu dengan usaha terbaik kelas QoS daripada nod.
Output: jika anda ingin mengurangkan kemungkinan pod yang dikehendaki diusir dari nod sekiranya kekurangan sumber padanya, maka bersama-sama dengan keutamaan, anda juga perlu menjaga menetapkan permintaan/had untuknya.
Mekanisme untuk penskalaan auto mendatar pod aplikasi (HPA)
Apabila tugasnya adalah untuk menambah dan mengurangkan bilangan pod secara automatik bergantung pada penggunaan sumber (sistem - CPU/RAM atau pengguna - rps), entiti k8s seperti HPA (Penskala Auto Pod Mendatar). Algoritmanya adalah seperti berikut:
- Bacaan semasa sumber yang diperhatikan ditentukan (currentMetricValue)
- Nilai yang dikehendaki untuk sumber ditentukan (desiredMetricValue), yang untuk sumber sistem ditetapkan menggunakan permintaan
- Bilangan replika semasa ditentukan (Replika semasa)
- Formula berikut mengira bilangan replika yang dikehendaki (Replika yang dikehendaki)
desiredReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]
Dalam kes ini, penskalaan tidak akan berlaku apabila pekali (currentMetricValue / desiredMetricValue) menghampiri 1 (dalam kes ini, kita boleh menetapkan sendiri ralat yang dibenarkan; secara lalai ialah 0.1).
Mari lihat cara hpa berfungsi menggunakan contoh aplikasi ujian aplikasi (diterangkan sebagai Deployment), di mana perlu menukar bilangan replika bergantung pada penggunaan CPU:
-
Manifes permohonan
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-statusItu. kita melihat bahawa pod aplikasi pada mulanya dilancarkan dalam dua keadaan, setiap satunya mengandungi dua bekas nginx dan nginx-pengeksport, untuk setiap satu yang ditentukan permintaan untuk 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: 30Itu. Kami mencipta hpa yang akan memantau ujian aplikasi Deployment dan melaraskan bilangan pod dengan aplikasi berdasarkan penunjuk cpu (kami menjangkakan bahawa pod harus menggunakan 30% daripada CPU yang dimintanya), dengan bilangan replika berada dalam julat 2-10.
Sekarang, mari kita lihat mekanisme operasi hpa jika kita menggunakan beban pada salah satu perapian:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Secara keseluruhan kami mempunyai yang berikut:
- Nilai yang dikehendaki (desiredMetricValue) - mengikut tetapan hpa, kami mempunyai 30%
- Nilai semasa (currentMetricValue) - untuk pengiraan, pengurus-pengawal mengira nilai purata penggunaan sumber dalam %, i.e. bersyarat melakukan perkara berikut:
- Menerima nilai mutlak metrik pod daripada pelayan metrik, i.e. 101m dan 4m
- Mengira nilai mutlak purata, i.e. (101m + 4m) / 2 = 53m
- Mendapat nilai mutlak untuk penggunaan sumber yang diingini (untuk ini, permintaan semua bekas dijumlahkan) 60m + 30m = 90m
- Mengira purata peratusan penggunaan CPU berbanding pod permintaan, i.e. 53m / 90m * 100% = 59%
Sekarang kita mempunyai semua yang kita perlukan untuk menentukan sama ada kita perlu menukar bilangan replika; untuk melakukan ini, kita mengira pekali:
ratio = 59% / 30% = 1.96
Itu. bilangan replika perlu ditambah ~2 kali ganda dan berjumlah [2 * 1.96] = 4.
Kesimpulan: Seperti yang anda lihat, agar mekanisme ini berfungsi, syarat yang diperlukan ialah kehadiran permintaan untuk semua bekas dalam pod yang diperhatikan.
Mekanisme untuk penskalaan auto mendatar nod (Autoscaler Kluster)
Untuk meneutralkan kesan negatif pada sistem semasa lonjakan beban, mempunyai hpa yang dikonfigurasikan tidak mencukupi. Sebagai contoh, mengikut tetapan dalam pengurus pengawal hpa, ia memutuskan bahawa bilangan replika perlu ditambah sebanyak 2 kali ganda, tetapi nod tidak mempunyai sumber percuma untuk menjalankan bilangan pod sedemikian (iaitu nod tidak dapat menyediakan meminta sumber kepada pod permintaan) dan pod ini bertukar kepada keadaan Belum selesai.
Dalam kes ini, jika pembekal mempunyai IaaS/PaaS yang sepadan (contohnya, GKE/GCE, AKS, EKS, dll.), alat seperti Nod Autoscaler. Ia membolehkan anda menetapkan bilangan maksimum dan minimum nod dalam kluster dan secara automatik melaraskan bilangan nod semasa (dengan memanggil API penyedia awan untuk memesan/mengalih keluar nod) apabila kekurangan sumber dalam kluster dan pod tidak boleh dijadualkan (berada dalam keadaan Menunggu).
Kesimpulan: Untuk dapat menskalakan nod secara automatik, adalah perlu untuk menetapkan permintaan dalam bekas pod supaya k8 dapat menilai dengan betul beban pada nod dan dengan itu melaporkan bahawa tiada sumber dalam kelompok untuk melancarkan pod seterusnya.
Kesimpulan
Perlu diingat bahawa menetapkan had sumber kontena bukanlah keperluan untuk aplikasi berjalan dengan jayanya, tetapi masih lebih baik untuk berbuat demikian atas sebab berikut:
- Untuk operasi penjadual yang lebih tepat dari segi pengimbangan beban antara nod k8s
- Untuk mengurangkan kemungkinan peristiwa "pengusiran pod" berlaku
- Untuk penskalaan auto mendatar pod aplikasi (HPA) berfungsi
- Untuk penskalaan auto mendatar nod (Autoscaling Kluster) untuk pembekal awan
Baca juga artikel lain di blog kami:
Sumber: www.habr.com