Bir qayda olaraq, proqramın düzgün və sabit işləməsi üçün onun ayrılmış resursları fondunun təmin edilməsinə həmişə ehtiyac var. Bəs bir neçə proqram eyni gücdə işləyirsə? Onların hər birini minimum zəruri resurslarla necə təmin etmək olar? Resurs istehlakını necə məhdudlaşdırmaq olar? Düyünlər arasında yükü necə düzgün paylamaq olar? Tətbiq yükü artarsa, üfüqi miqyaslama mexanizminin işləməsini necə təmin etmək olar?
Sistemdə hansı əsas resurs növlərinin mövcudluğundan başlamalısınız - bu, əlbəttə ki, prosessor vaxtı və RAMdır. K8s manifestlərində bu resurs növləri aşağıdakı vahidlərlə ölçülür:
- CPU - nüvələrdə
- RAM - baytlarda
Üstəlik, hər bir resurs üçün iki növ tələb təyin etmək mümkündür - sorğu и hədd. Sorğular - konteyneri (və bütövlükdə pod) işlətmək üçün qovşağın pulsuz resursları üçün minimum tələbləri təsvir edir, limitlər isə konteyner üçün mövcud olan resurslara sərt məhdudiyyət qoyur.
Anlamaq lazımdır ki, manifest hər iki növü açıq şəkildə müəyyən etməməlidir, lakin davranış aşağıdakı kimi olacaqdır:
- Yalnız resursun limitləri açıq şəkildə göstərilibsə, bu resurs üçün sorğular avtomatik olaraq limitlərə bərabər dəyər alır (bunu təsvir edən obyektlərə zəng etməklə yoxlaya bilərsiniz). Bunlar. əslində konteyner işləmək üçün tələb olunan eyni miqdarda resurslarla məhdudlaşacaq.
- Resurs üçün yalnız sorğular açıq şəkildə göstərilibsə, bu resursda heç bir yuxarı məhdudiyyət qoyulmur - yəni. konteyner yalnız node özünün resursları ilə məhdudlaşır.
Resurs idarəçiliyini yalnız müəyyən bir konteyner səviyyəsində deyil, həm də aşağıdakı obyektlərdən istifadə edərək ad məkanı səviyyəsində konfiqurasiya etmək mümkündür:
- LimitRange — ns ilə konteyner/pod səviyyəsində məhdudiyyət siyasətini təsvir edir və konteyner/pod üzrə standart məhdudiyyətləri təsvir etmək, həmçinin açıq-aşkar yağlı qabların/podların yaradılmasının qarşısını almaq (və ya əksinə), onların sayını məhdudlaşdırmaq üçün lazımdır. və limitlər və sorğulardakı dəyərlərdəki mümkün fərqi müəyyənləşdirin
- Resurs Kvotaları — ns-dəki bütün konteynerlər üçün ümumiyyətlə məhdudlaşdırma siyasətini təsvir edin və bir qayda olaraq, mühitlər arasında resursları ayırmaq üçün istifadə olunur (mühitlər qovşaq səviyyəsində ciddi şəkildə demarkasiya edilmədikdə faydalıdır)
Aşağıdakılar resurs məhdudiyyətlərini təyin edən manifestlərin nümunələridir:
-
Xüsusi konteyner səviyyəsində:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mBunlar. bu halda, nginx ilə konteyneri işə salmaq üçün sizə ən azı 1G pulsuz RAM və qovşaqda 0.2 CPU lazımdır, halbuki konteyner ən çox 0.2 CPU və qovşaqdakı bütün mövcud RAM istehlak edə bilər.
-
ns tam səviyyəsində:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiBunlar. standart ns-də bütün sorğu konteynerlərinin cəmi CPU üçün 300m-dən və OP üçün 1G-dən çox ola bilməz və bütün limitin cəmi CPU üçün 700m və OP üçün 2G-dir.
-
Ns-də konteynerlər üçün defolt limitlər:
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: 4GiBunlar. bütün konteynerlər üçün standart ad məkanında sorğu CPU üçün 100m və OP üçün 1G, limit - 1 CPU və 2G olaraq təyin ediləcək. Eyni zamanda, CPU (50m < x < 2) və RAM (500M < x < 4G) üçün sorğu/limitdə mümkün dəyərlərə də limit qoyulur.
-
Pod səviyyəli məhdudiyyətlər:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiBunlar. standart ns-də hər pod üçün 4 vCPU və 1G limiti olacaq.
İndi sizə bu məhdudiyyətlərin qoyulması bizə hansı üstünlükləri verə biləcəyini söyləmək istərdim.
Düyünlər arasında yük balanslaşdırma mexanizmi
Bildiyiniz kimi, k8s komponenti podların qovşaqlar arasında paylanmasına cavabdehdir, məsələn planlayıcı, müəyyən bir alqoritmə uyğun işləyən. Bu alqoritm işə salmaq üçün optimal nodu seçərkən iki mərhələdən keçir:
- filtreleme
- Menzilli
Bunlar. təsvir edilən siyasətə əsasən, əvvəlcə dəst əsasında pod işə salmaq mümkün olan qovşaqlar seçilir predikatlar (qovşağın podu işə salmaq üçün kifayət qədər resurslara malik olub-olmadığını yoxlamaq daxil olmaqla - PodFitsResources) və sonra bu qovşaqların hər biri üçün uyğun olaraq prioritetləri xallar verilir (o cümlədən, bir node nə qədər çox pulsuz resurs varsa, bir o qədər çox xal verilir - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) və pod ən çox xal toplayan qovşaqda işə salınır (əgər bir neçə qovşaq eyni anda bu şərti ödəyirsə, onda təsadüfi biri seçilir).
Eyni zamanda, planlaşdırıcının bir qovşağın mövcud resurslarını qiymətləndirərkən, etcd-də saxlanılan məlumatları rəhbər tutduğunu başa düşməlisiniz - yəni. bu qovşaqda işləyən hər bir podun tələb olunan/məhdud resursunun məbləği üçün, lakin faktiki resurs istehlakı üçün deyil. Bu məlumatı komanda çıxışından əldə etmək olar kubectl describe node $NODE, məsələn:
# 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%)Burada biz müəyyən bir node üzərində işləyən bütün podları, həmçinin hər bir podun tələb etdiyi resursları görürük. Və cronjob-cron-events-1573793820-xt6q9 pod işə salındıqda planlaşdırıcı qeydləri necə görünür (bu məlumat başlanğıc əmri arqumentlərində 10-cu giriş səviyyəsini təyin edərkən planlaşdırıcı jurnalında görünəcək -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-s10Burada görürük ki, planlaşdırıcı əvvəlcə işə salına biləcəyi 3 qovşaqdan (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10) süzgəcdən keçir və siyahısını yaradır. Sonra o, ən uyğun qovşağı müəyyən etmək üçün bu qovşaqların hər biri üçün bir neçə parametrə (o cümlədən BalancedResourceAllocation, LeastResourceAllocation) əsaslanan xalları hesablayır. Nəhayət, pod ən çox xal toplayan qovşaqda planlaşdırılır (burada eyni anda iki qovşaq eyni sayda 100037 nöqtəyə malikdir, buna görə təsadüfi biri seçilir - nxs-k8s-s10).
Buraxılış: əgər qovşaq heç bir məhdudiyyət qoyulmayan podları işlədirsə, o zaman k8-lər üçün (resurs istehlakı baxımından) bu, bu qovşaqda ümumiyyətlə belə podlar olmadığına bərabər olacaq. Buna görə də, şərti olaraq, acgöz prosesi olan bir podunuz varsa (məsələn, wowza) və bunun üçün heç bir məhdudiyyət qoyulmursa, bu pod əslində düyünün bütün resurslarını yedikdə vəziyyət yarana bilər, lakin k8s üçün bu node boşaldılmış hesab olunur və nəticədə yükün qovşaqlar arasında qeyri-bərabər paylanmasına gətirib çıxara bilən işlək qovşaqları olmayan qovşaq kimi sıralanarkən (dəqiq mövcud resursları qiymətləndirən ballarda) eyni sayda xal veriləcəkdir.
Podun çıxarılması
Bildiyiniz kimi, hər bir pod 3 QoS sinifindən birinə təyin olunur:
- zəmanət verilmişdir — poddakı hər bir konteyner üçün yaddaş və cpu üçün sorğu və limit müəyyən edildikdə təyin edilir və bu dəyərlər uyğun olmalıdır
- partlaya bilən — poddakı ən azı bir konteynerin tələbi və limiti var, sorğu < limiti
- ən yaxşı səy — podda heç bir konteynerin resurs məhdud olmadığı zaman
Eyni zamanda, node resurs çatışmazlığı (disk, yaddaş) ilə qarşılaşdıqda kubelet podun prioritetini və onun QoS sinifini nəzərə alan xüsusi alqoritmə uyğun olaraq podları sıralamağa və çıxarmağa başlayır. Məsələn, RAM haqqında danışırıqsa, QoS sinifinə əsaslanaraq xallar aşağıdakı prinsipə uyğun olaraq verilir:
- Zəmanətli: -998
- Yükzək əzm: 1000
- Burstable: min(maks(2, 1000 - (1000 * yaddaşRequestBytes) / machineMemoryCapacityBytes), 999)
Bunlar. eyni prioritetlə kubelet əvvəlcə ən yaxşı QoS sinfi ilə podları qovşaqdan çıxaracaq.
Buraxılış: İstədiyiniz podun üzərində resurs çatışmazlığı halında qovşaqdan çıxarılması ehtimalını azaltmaq istəyirsinizsə, o zaman prioritetlə yanaşı, onun üçün sorğu/limit təyin etməyə də diqqət yetirməlisiniz.
Tətbiq podlarının üfüqi avtomatik miqyası (HPA) mexanizmi
Vəzifə resursların istifadəsindən (sistem - CPU/RAM və ya istifadəçi - rps) asılı olaraq podların sayını avtomatik olaraq artırmaq və azaltmaq olduqda, belə bir k8s varlığı HPA (Üfüqi Pod Autoscaler). Alqoritmi aşağıdakı kimidir:
- Müşahidə olunan resursun cari oxunuşları müəyyən edilir (currentMetricValue)
- Resurs üçün arzu olunan dəyərlər müəyyən edilir (desiredMetricValue), sistem resursları üçün sorğudan istifadə etməklə müəyyən edilir.
- Replikaların cari sayı müəyyən edilir (cari Replikalar)
- Aşağıdakı düstur istədiyiniz replika sayını hesablayır (desiredReplicas)
arzu olunan Replikalar = [ cari Replikalar * ( cariMetricValue / desiredMetricValue )]
Bu halda, əmsal (currentMetricValue / arzu olunanMetricValue) 1-ə yaxın olduqda miqyaslama baş verməyəcək (bu halda icazə verilən xətanı özümüz təyin edə bilərik; standart olaraq 0.1-dir).
Prosessor istehlakından asılı olaraq replikaların sayını dəyişdirmək lazım olan tətbiq test tətbiqi nümunəsindən istifadə edərək hpa-nın necə işlədiyinə baxaq (yerləşdirmə kimi təsvir olunur):
-
Tətbiq manifest
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-statusBunlar. proqram podunun əvvəlcə iki halda işə salındığını görürük, bunların hər birində iki nginx və nginx-exporter konteyneri var, hər biri üçün müəyyən edilmiş sorğu CPU üçün.
-
HPA Manifestosu
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: 30Bunlar. Biz Yerləşdirmə tətbiqi testinə nəzarət edəcək və cpu göstəricisinə əsaslanaraq proqram ilə podların sayını tənzimləyən hpa yaratdıq (biz gözləyirik ki, pod tələb etdiyi CPU-nun 30%-ni istehlak etməlidir) və replikaların sayı buradadır. 2-10 aralığı.
İndi ocaqlardan birinə yük tətbiq etsək, hpa işləmə mexanizminə baxaq:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Ümumilikdə bizdə aşağıdakılar var:
- İstədiyiniz dəyər (desiredMetricValue) - hpa parametrlərinə görə bizdə 30% var
- Cari dəyər (currentMetricValue) - hesablama üçün nəzarətçi-menecer resurs istehlakının orta dəyərini % ilə hesablayır, yəni. şərti olaraq aşağıdakıları edir:
- Metrik serverdən pod ölçülərinin mütləq dəyərlərini alır, yəni. 101 m və 4 m
- Orta mütləq dəyəri hesablayır, yəni. (101m + 4m) / 2 = 53m
- İstədiyiniz resurs istehlakı üçün mütləq dəyəri alır (bunun üçün bütün konteynerlərin sorğuları yekunlaşdırılır) 60m + 30m = 90m
- Sorğu poduna nisbətən CPU istehlakının orta faizini hesablayır, yəni. 53m / 90m * 100% = 59%
İndi replikaların sayını dəyişdirməyimiz lazım olub olmadığını müəyyən etmək üçün lazım olan hər şey var; bunun üçün əmsalı hesablayırıq:
ratio = 59% / 30% = 1.96
Bunlar. replikaların sayı ~2 dəfə artırılmalı və [2 * 1.96] = 4 olmalıdır.
Nəticə: Gördüyünüz kimi, bu mexanizmin işləməsi üçün zəruri şərt müşahidə olunan podda bütün konteynerlər üçün sorğuların olmasıdır.
Düyünlərin üfüqi avtomatik miqyası üçün mexanizm (Cluster Autoscaler)
Yük artımları zamanı sistemə mənfi təsirləri neytrallaşdırmaq üçün konfiqurasiya edilmiş hpa-nın olması kifayət deyil. Məsələn, hpa nəzarətçi menecerindəki parametrlərə əsasən, o, replikaların sayını 2 dəfə artırmaq lazım olduğunu qərara alır, lakin qovşaqların bu qədər sayda podları işə salmaq üçün pulsuz resursları yoxdur (yəni, qovşaq lazımi məlumatları təmin edə bilməz. sorğular bölməsinə tələb olunan resurslar) və bu podlar Gözləmə vəziyyətinə keçir.
Bu halda, provayderdə müvafiq IaaS/PaaS varsa (məsələn, GKE/GCE, AKS, EKS və s.), kimi alət Node Autoscaler. O, klasterdəki qovşaqların maksimum və minimum sayını təyin etməyə və klasterdə və qovşaqlarda resurs çatışmazlığı olduqda qovşaqların cari sayını avtomatik tənzimləməyə imkan verir (qovşağı sifariş etmək/çıxarmaq üçün bulud provayderi API-yə zəng etməklə). planlaşdırıla bilməz (Gözləyən vəziyyətdədir).
Nəticə: Düyünləri avtomatik ölçə bilmək üçün pod konteynerlərində sorğular təyin etmək lazımdır ki, k8-lər qovşaqlardakı yükü düzgün qiymətləndirə bilsin və müvafiq olaraq növbəti podu işə salmaq üçün klasterdə heç bir resurs olmadığını bildirsin.
Nəticə
Qeyd etmək lazımdır ki, konteyner resurs limitlərinin təyin edilməsi tətbiqin uğurla işləməsi üçün tələb deyil, lakin aşağıdakı səbəblərə görə bunu etmək daha yaxşıdır:
- k8s qovşaqları arasında yük balansı baxımından planlaşdırıcının daha dəqiq işləməsi üçün
- “Pod çıxarılması” hadisəsinin baş vermə ehtimalını azaltmaq üçün
- Tətbiq podlarının (HPA) işləməsi üçün üfüqi avtomatik miqyaslama üçün
- Bulud provayderləri üçün qovşaqların üfüqi avtomatik miqyası (Cluster Autoscaling) üçün
Bloqumuzdakı digər məqalələri də oxuyun:
Mənbə: www.habr.com