Geekly articles weekly

Kubernetes: mengapa begitu penting untuk mengatur manajemen sumber daya sistem?

Sebagai aturan, selalu ada kebutuhan untuk menyediakan kumpulan sumber daya khusus untuk aplikasi apa pun untuk operasi yang benar dan stabil. Tetapi bagaimana jika beberapa aplikasi bekerja pada kapasitas yang sama sekaligus? Bagaimana menyediakan sumber daya minimum yang diperlukan untuk masing-masing sumber daya tersebut? Bagaimana saya bisa membatasi konsumsi sumber daya? Bagaimana cara mendistribusikan beban antar node dengan benar? Bagaimana memastikan mekanisme penskalaan horizontal jika terjadi peningkatan beban pada aplikasi?



Anda harus mulai dengan jenis sumber daya dasar apa yang ada dalam sistem - tentu saja, waktu prosesor dan RAM. Dalam manifes k8, jenis sumber daya ini diukur dalam unit berikut:


  • CPU - di dalam inti
  • RAM - dalam byte

Selain itu, untuk setiap sumber daya ada peluang untuk menetapkan dua jenis persyaratan - permintaan dan batasan . Permintaan - menguraikan persyaratan minimum untuk sumber daya bebas simpul untuk menjalankan wadah (dan perapian secara keseluruhan), sementara batas menetapkan batas ketat pada sumber daya yang tersedia untuk wadah.


Penting untuk dipahami bahwa dalam manifes tidak perlu mendefinisikan kedua jenis secara eksplisit, dan perilaku tersebut adalah sebagai berikut:


  • Jika hanya batas sumber daya yang ditetapkan secara eksplisit, maka permintaan untuk sumber daya ini secara otomatis mengambil nilai yang sama dengan batas (ini dapat diverifikasi dengan memanggil entitas yang dijelaskan). Yaitu pada kenyataannya, pengoperasian wadah akan dibatasi oleh jumlah sumber daya yang sama yang diperlukan untuk menjalankannya.
  • Jika hanya permintaan yang ditetapkan secara eksplisit untuk sumber daya, maka tidak ada batasan yang ditetapkan di atas sumber daya ini - yaitu. wadah hanya dibatasi oleh sumber daya dari simpul itu sendiri.

Dimungkinkan juga untuk mengkonfigurasi manajemen sumber daya tidak hanya pada level wadah tertentu, tetapi juga pada tingkat namespace menggunakan entitas berikut:


  • LimitRange - menguraikan kebijakan pembatasan di tingkat wadah / perapian di ns dan diperlukan untuk menjelaskan batasan default pada wadah / perapian, serta untuk mencegah penciptaan wadah / perapian yang jelas-jelas gemuk (atau sebaliknya), batasi jumlah mereka dan tentukan perbedaan yang mungkin dalam nilai dalam batas-batas dan permintaan
  • ResourceQuotas - menggambarkan kebijakan pembatasan secara umum untuk semua kontainer di ns dan digunakan, sebagai aturan, untuk membedakan sumber daya antara lingkungan (berguna ketika lingkungan tidak dibatasi secara kaku pada tingkat node)

Berikut ini adalah contoh manifes di mana batas sumber daya ditetapkan:


  • Di tingkat wadah khusus:


    containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200m

    Yaitu dalam hal ini, untuk memulai sebuah wadah dengan nginx, Anda akan memerlukan setidaknya ketersediaan 1G OP dan 0,2 CPU pada node, sedangkan wadah maksimum dapat memakan 0,2 CPU dan semua OP yang tersedia pada node.


  • Pada tingkat integer ns:


     apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2Gi

    Yaitu jumlah semua kontainer permintaan dalam ns default tidak dapat melebihi 300m untuk CPU dan 1G untuk OP, dan jumlah semua batas adalah 700m untuk CPU dan 2G untuk OP.


  • Pembatasan default untuk wadah di 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: 4Gi

    Yaitu di namespace default untuk semua kontainer, secara default, permintaan akan diatur ke 100m untuk CPU dan 1G untuk OP, batas - 1 CPU dan 2G. Pada saat yang sama, pembatasan juga ditetapkan pada nilai yang mungkin dalam permintaan / batas untuk CPU (50m <x <2) dan RAM (500M <x <4G).


  • Keterbatasan pada tingkat perapian ns


     apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1Gi

    Yaitu untuk setiap perapian di ns default, batas 4 vCPU dan 1G akan ditetapkan.



Sekarang saya ingin memberi tahu Anda apa keuntungan yang dapat diberikan pemasangan pembatasan ini kepada kami.


Mekanisme load balancing antar node


Seperti yang Anda ketahui, komponen k8s seperti scheduler , yang bekerja sesuai dengan algoritma tertentu, bertanggung jawab untuk distribusi perapian di atas node. Algoritma ini dalam proses memilih node optimal untuk dijalankan melalui dua tahap:


  1. Penyaringan
  2. Peringkat

Yaitu sesuai dengan kebijakan yang dijelaskan, node pada awalnya dipilih di mana perapian dapat diluncurkan berdasarkan seperangkat predikat (termasuk apakah node memiliki sumber daya yang cukup untuk menjalankan perapian - PodFitsResources), dan kemudian poin diberikan untuk masing-masing node, sesuai dengan prioritas (termasuk, semakin banyak sumber daya gratis yang dimiliki node - semakin banyak poin yang ditetapkan - LeastResourceAllocation / LeastRequestedPriority / BalancedResourceAllocation) dan dijalankan pada node dengan poin terbanyak (jika beberapa node memenuhi kondisi ini sekaligus, maka yang acak dipilih).


Pada saat yang sama, Anda perlu memahami bahwa penjadwal, ketika mengevaluasi sumber daya yang tersedia dari node, berfokus pada data yang disimpan dalam etcd - yaitu. dengan jumlah sumber daya yang diminta / dibatasi dari setiap pod yang berjalan pada node ini, tetapi tidak oleh konsumsi sumber daya yang sebenarnya. Informasi ini dapat diperoleh dalam output dari kubectl describe node $NODE perintah, misalnya:


 # 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, ie, 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 node tertentu, serta sumber daya yang diminta masing-masing pod. Dan inilah tampilan log scheduler ketika memulai cronjob-cron-events-1573793820-xt6q9 pod (informasi ini muncul di log scheduler ketika mengatur level 10 logging dalam argumen pada perintah start --v = 10):


camar yang luas
 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-s10

Di sini kita melihat bahwa pada awalnya penjadwal melakukan penyaringan dan membentuk daftar 3 simpul yang memungkinkan untuk dijalankan (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Ini kemudian menghitung poin sesuai dengan beberapa parameter (termasuk BalancedResourceAllocation, LeastResourceAllocation) untuk masing-masing node ini untuk menentukan simpul yang paling cocok. Pada akhirnya, ini direncanakan di bawah simpul dengan poin terbanyak (di sini, dua node sekaligus memiliki jumlah poin yang sama 100037, jadi yang dipilih secara acak - nxs-k8s-s10).


Kesimpulan : jika pod bekerja pada node yang tidak ada batasan, maka untuk k8 (dari sudut pandang konsumsi sumber daya) ini akan sama dengan jika pod tersebut benar-benar tidak ada pada node ini. Oleh karena itu, jika Anda memiliki pod dengan proses yang rakus (misalnya, wowza) dan tidak ada batasan untuk itu, maka sebuah situasi dapat muncul ketika sebenarnya yang diberikan telah memakan semua sumber daya dari node, tetapi untuk k8s node ini dianggap diturunkan dan itu akan diberikan jumlah poin yang sama ketika peringkat (yaitu, dalam poin dengan penilaian sumber daya yang tersedia), serta simpul yang tidak memiliki lapangan kerja, yang pada akhirnya dapat menyebabkan distribusi beban yang tidak merata antara node.


Penggusuran perapian


Seperti yang Anda ketahui, masing-masing pod diberikan salah satu dari 3 kelas QoS:


  1. dijamin - ditugaskan ketika permintaan dan batas ditetapkan untuk setiap wadah di perapian untuk memori dan cpu, dan nilai-nilai ini harus cocok
  2. burstable - setidaknya satu kontainer di perapian memiliki permintaan dan batas, sementara permintaan <batas
  3. upaya terbaik - ketika tidak ada wadah di perapian yang terbatas sumber dayanya

Pada saat yang sama, ketika ada kekurangan sumber daya (disk, memori) pada node, kubelet mulai membuat peringkat dan mengusir pod menurut algoritma tertentu yang memperhitungkan prioritas pod dan kelas QoS-nya. Sebagai contoh, jika kita berbicara tentang RAM, maka berdasarkan poin kelas QoS diberikan sesuai dengan prinsip berikut:


  • Dijamin : -998
  • Usaha Terbaik : 1000
  • Burstable : min (maks (2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

Yaitu dengan prioritas yang sama, kubelet pertama-tama akan mengeluarkan pod dengan upaya QoS class terbaik dari node.


Kesimpulan : jika Anda ingin mengurangi kemungkinan penggusuran pod yang diperlukan dari node jika sumber daya tidak mencukupi, maka bersama dengan prioritas, Anda juga harus berhati-hati dalam mengatur permintaan / batas untuk itu.


Mekanisme auto-scaling horizontal hearth aplikasi (HPA)


Ketika tugas adalah untuk secara otomatis menambah dan mengurangi jumlah pod tergantung pada penggunaan sumber daya (sistem - CPU / RAM atau pengguna - rps), k8s seperti HPA (Horizontal Pod Autoscaler) dapat membantu dalam solusinya. Algoritanya adalah sebagai berikut:


  1. Pembacaan saat ini dari sumber daya yang diamati (currentMetricValue) ditentukan
  2. Nilai yang diinginkan untuk sumber daya (NilaiMetri yang diinginkan) ditentukan, yang ditetapkan untuk sumber daya sistem menggunakan permintaan
  3. Jumlah replika saat ini ditentukan (currentReplicas)
  4. Rumus berikut menghitung jumlah replika yang diinginkan (Replika yang diinginkan)
    diinginkanReplicas = [currentReplicas * (currentMetricValue / diinginkanMetricValue)]

Namun, penskalaan tidak akan terjadi ketika koefisien (currentMetricValue / diinginkanMetricValue) mendekati 1 (kita dapat mengatur sendiri kesalahan yang diijinkan, secara default adalah 0,1).


Pertimbangkan hpa menggunakan aplikasi uji aplikasi (dijelaskan sebagai Penempatan), di mana perlu untuk mengubah jumlah replika, tergantung pada konsumsi CPU:


  • Manifes 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-status

    Yaitu kita melihat bahwa di bawah dengan aplikasi itu awalnya diluncurkan dalam dua contoh, yang masing-masing berisi dua kontainer nginx dan nginx-eksportir, untuk masing-masing permintaan CPU diberikan.


  • Manifes 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: 30

    Yaitu kami menciptakan hpa yang akan memantau uji aplikasi Penempatan dan menyesuaikan jumlah perapian dengan aplikasi berdasarkan indikator cpu (kami berharap bahwa perapian harus mengkonsumsi 30% persen dari CPU yang diminta olehnya), sementara jumlah replika berada dalam kisaran 2-10.


    Sekarang, kami akan mempertimbangkan mekanisme operasi hpa jika kami menerapkan beban ke salah satu perapian:


      # kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi


Total kami memiliki yang berikut:


  • Nilai yang diinginkan (diinginkanMetricValue) - sesuai dengan pengaturan hpa, kami memiliki 30%
  • Nilai saat ini (currentMetricValue) - untuk perhitungan, pengontrol-manajer menghitung nilai rata-rata konsumsi sumber daya dalam%, mis. kondisional melakukan hal berikut:
    1. Mendapat nilai absolut metrik perapian dari server metrik, mis. 101 m dan 4 m
    2. Menghitung nilai absolut rata-rata, mis. (101m + 4m) / 2 = 53m
    3. Mendapat nilai absolut untuk konsumsi sumber daya yang diinginkan (untuk ini, permintaan semua kontainer dijumlahkan) 60m + 30m = 90m
    4. Menghitung persentase rata-rata konsumsi CPU relatif terhadap perapian permintaan, mis. 53m / 90m * 100% = 59%

Sekarang kita memiliki semua yang diperlukan untuk menentukan apakah perlu mengubah jumlah replika, untuk ini kita menghitung koefisien:


ratio = 59% / 30% = 1.96


Yaitu jumlah replika harus ditambah ~ 2 kali dan make up [2 * 1.96] = 4.


Kesimpulan: Seperti yang Anda lihat, agar mekanisme ini berfungsi, prasyarat termasuk ketersediaan permintaan untuk semua kontainer di perapian yang diamati.


Mekanisme penskalaan otomatis antar node (Cluster Autoscaler)


Untuk menetralkan dampak negatif pada sistem selama semburan beban, keberadaan hpa yang disetel tidak cukup. Misalnya, menurut pengaturan di manajer pengontrol hpa memutuskan bahwa jumlah replika perlu ditingkatkan 2 kali, namun, tidak ada sumber daya gratis pada node untuk menjalankan sejumlah pod (mis. Node tidak dapat menyediakan sumber daya yang diminta untuk permintaan pod) dan pod ini masukkan status Tertunda.


Dalam hal ini, jika penyedia memiliki IaaS / PaaS yang sesuai (misalnya, GKE / GCE, AKS, EKS, dll.), Alat seperti Node Autoscaler dapat membantu kami. Ini memungkinkan Anda untuk mengatur jumlah node maksimum dan minimum dalam cluster dan secara otomatis menyesuaikan jumlah node saat ini (dengan mengakses API penyedia cloud untuk memesan / menghapus node) ketika ada kekurangan sumber daya dalam cluster dan pod tidak dapat dijadwalkan (dalam kondisi Pending).


Kesimpulan: untuk dapat secara otomatis skala node, perlu untuk menentukan permintaan dalam wadah perapian sehingga k8s dapat dengan benar mengevaluasi beban node dan karenanya melaporkan bahwa tidak ada sumber daya dalam cluster untuk memulai perapian berikutnya.



Kesimpulan


Perlu dicatat bahwa pengaturan batas sumber daya untuk wadah bukanlah prasyarat untuk keberhasilan peluncuran aplikasi, tetapi masih lebih baik untuk melakukan ini karena alasan berikut:


  1. Untuk operasi penjadwal yang lebih akurat dalam hal load balancing antara node k8s
  2. Untuk mengurangi kemungkinan terjadinya peristiwa penggusuran jantung
  3. Untuk perapian aplikasi penskalaan horizontal (HPA)
  4. Untuk penskalaan otomatis antar titik (Cluster Autoscaling) untuk penyedia cloud

Baca juga artikel lain di blog kami:


Source: https://habr.com/ru/post/id480072/

More articles:


All Articles