ஒரு விதியாக, அதன் சரியான மற்றும் நிலையான செயல்பாட்டிற்காக ஒரு பயன்பாட்டிற்கு ஒரு பிரத்யேக வளங்களை வழங்க வேண்டிய அவசியம் எப்போதும் உள்ளது. ஆனால் பல பயன்பாடுகள் ஒரே சக்தியில் இயங்கினால் என்ன செய்வது? அவை ஒவ்வொன்றிற்கும் தேவையான குறைந்தபட்ச ஆதாரங்களை எவ்வாறு வழங்குவது? வள நுகர்வு எவ்வாறு கட்டுப்படுத்த முடியும்? முனைகளுக்கு இடையில் சுமைகளை எவ்வாறு சரியாக விநியோகிப்பது? பயன்பாட்டு சுமை அதிகரித்தால் கிடைமட்ட அளவிடுதல் பொறிமுறையை எவ்வாறு உறுதி செய்வது?
கணினியில் என்ன முக்கிய வகையான வளங்கள் உள்ளன என்பதை நீங்கள் தொடங்க வேண்டும் - இது, நிச்சயமாக, செயலி நேரம் மற்றும் ரேம். k8s வெளிப்பாடுகளில் இந்த வள வகைகள் பின்வரும் அலகுகளில் அளவிடப்படுகின்றன:
- CPU - கோர்களில்
- ரேம் - பைட்டுகளில்
மேலும், ஒவ்வொரு வளத்திற்கும் இரண்டு வகையான தேவைகளை அமைக்க முடியும் - கோரிக்கைகளை и வரம்புகளை. கோரிக்கைகள் - ஒரு கன்டெய்னரை (மற்றும் ஒட்டுமொத்தமாக பாட்) இயக்க ஒரு முனையின் இலவச ஆதாரங்களுக்கான குறைந்தபட்சத் தேவைகளை விவரிக்கிறது, அதே சமயம் வரம்புகள் கொள்கலனுக்குக் கிடைக்கும் வளங்களில் கடினமான வரம்பை அமைக்கிறது.
மேனிஃபெஸ்ட்டானது இரண்டு வகைகளையும் வெளிப்படையாக வரையறுக்க வேண்டியதில்லை என்பதை புரிந்துகொள்வது முக்கியம், ஆனால் நடத்தை பின்வருமாறு இருக்கும்:
- ஒரு வளத்தின் வரம்புகள் மட்டுமே வெளிப்படையாகக் குறிப்பிடப்பட்டிருந்தால், இந்த ஆதாரத்திற்கான கோரிக்கைகள் தானாகவே வரம்புகளுக்கு சமமான மதிப்பை எடுக்கும் (நீங்கள் விவரிக்கும் நிறுவனங்களை அழைப்பதன் மூலம் இதை சரிபார்க்கலாம்). அந்த. உண்மையில், கொள்கலன் இயக்குவதற்குத் தேவைப்படும் அதே அளவு வளங்களுக்கு மட்டுப்படுத்தப்படும்.
- ஒரு ஆதாரத்திற்கான கோரிக்கைகள் மட்டுமே வெளிப்படையாகக் குறிப்பிடப்பட்டிருந்தால், இந்த ஆதாரத்தில் மேல் கட்டுப்பாடுகள் எதுவும் அமைக்கப்படாது - அதாவது. கொள்கலன் முனையின் வளங்களால் மட்டுமே வரையறுக்கப்பட்டுள்ளது.
ஒரு குறிப்பிட்ட கொள்கலனின் மட்டத்தில் மட்டுமல்லாமல், பின்வரும் நிறுவனங்களைப் பயன்படுத்தி பெயர்வெளி மட்டத்திலும் வள நிர்வாகத்தை உள்ளமைக்க முடியும்:
- வரம்பு வரம்பு — ns இல் கண்டெய்னர்/பாட் மட்டத்தில் கட்டுப்பாட்டுக் கொள்கையை விவரிக்கிறது மற்றும் கொள்கலன்/பாட் மீது இயல்புநிலை வரம்புகளை விவரிக்கவும், அத்துடன் வெளிப்படையாக கொழுப்புள்ள கொள்கலன்கள்/காய்களை உருவாக்குவதைத் தடுக்கவும் (அல்லது நேர்மாறாகவும்) அவற்றின் எண்ணிக்கையைக் கட்டுப்படுத்தவும். வரம்புகள் மற்றும் கோரிக்கைகளில் உள்ள மதிப்புகளில் சாத்தியமான வேறுபாட்டைத் தீர்மானிக்கவும்
- வள ஒதுக்கீடுகள் - ns இல் உள்ள அனைத்து கொள்கலன்களுக்கும் பொதுவாக கட்டுப்பாடு கொள்கையை விவரிக்கவும், ஒரு விதியாக, சுற்றுச்சூழலில் உள்ள வளங்களை வரையறுக்கப் பயன்படுகிறது (சுற்றுச்சூழல்கள் முனை மட்டத்தில் கண்டிப்பாக வரையறுக்கப்படாத போது பயனுள்ளதாக இருக்கும்)
ஆதார வரம்புகளை அமைக்கும் மேனிஃபெஸ்ட்களின் எடுத்துக்காட்டுகள் பின்வருமாறு:
-
குறிப்பிட்ட கொள்கலன் மட்டத்தில்:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mஅந்த. இந்த வழக்கில், nginx உடன் ஒரு கொள்கலனை இயக்க, உங்களுக்கு குறைந்தபட்சம் 1G இலவச ரேம் மற்றும் 0.2 CPU ஆகியவை தேவைப்படும், அதே சமயம் அதிகபட்சமாக கன்டெய்னர் 0.2 CPU மற்றும் கணுவில் உள்ள அனைத்து RAM ஐயும் உட்கொள்ளலாம்.
-
முழு எண் மட்டத்தில் ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2Giஅந்த. இயல்புநிலை ns இல் உள்ள அனைத்து கோரிக்கை கொள்கலன்களின் கூட்டுத்தொகை CPU க்கு 300m மற்றும் OP க்கு 1G ஐ தாண்டக்கூடாது, மேலும் அனைத்து வரம்புகளின் கூட்டுத்தொகை CPU க்கு 700m மற்றும் OP க்கு 2G ஆகும்.
-
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அந்த. அனைத்து கொள்கலன்களுக்கான இயல்புநிலை பெயர்வெளியில், கோரிக்கை CPU க்கு 100m ஆகவும், OP க்கு 1G ஆகவும் அமைக்கப்படும், வரம்பு - 1 CPU மற்றும் 2G. அதே நேரத்தில், CPU (50m < x < 2) மற்றும் RAM (500M < x < 4G) ஆகியவற்றுக்கான கோரிக்கை/வரம்பில் சாத்தியமான மதிப்புகளிலும் வரம்பு அமைக்கப்பட்டுள்ளது.
-
பாட்-லெவல் கட்டுப்பாடுகள்:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1Giஅந்த. இயல்புநிலையில் உள்ள ஒவ்வொரு பாட்க்கும் 4 vCPU மற்றும் 1G வரம்பு இருக்கும்.
இந்தக் கட்டுப்பாடுகள் நமக்கு என்ன நன்மைகளைத் தரும் என்பதை இப்போது நான் உங்களுக்குச் சொல்ல விரும்புகிறேன்.
முனைகளுக்கு இடையில் ஏற்ற சமநிலை பொறிமுறை
உங்களுக்குத் தெரியும், k8s கூறு முனைகளில் காய்களின் விநியோகத்திற்கு பொறுப்பாகும் அட்டவணைப்படுத்தி, இது ஒரு குறிப்பிட்ட அல்காரிதம் படி வேலை செய்கிறது. தொடங்குவதற்கு உகந்த முனையைத் தேர்ந்தெடுக்கும்போது இந்த வழிமுறை இரண்டு நிலைகளைக் கடந்து செல்கிறது:
- வடித்தல்
- ரேங்கிங்
அந்த. விவரிக்கப்பட்ட கொள்கையின்படி, கணுக்கள் ஆரம்பத்தில் தேர்ந்தெடுக்கப்படுகின்றன, அதில் ஒரு தொகுப்பின் அடிப்படையில் ஒரு பாட் தொடங்க முடியும் முன்னறிவிக்கிறது (பாட் - PodFitsResources ஐ இயக்குவதற்கு முனையில் போதுமான ஆதாரங்கள் உள்ளதா என்பதைச் சரிபார்ப்பது உட்பட), பின்னர் இந்த ஒவ்வொரு முனைக்கும், படி முன்னுரிமைகள் புள்ளிகள் வழங்கப்படுகின்றன (ஒரு முனையில் எவ்வளவு இலவச ஆதாரங்கள் இருக்கிறதோ, அவ்வளவு புள்ளிகள் ஒதுக்கப்படும் - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) மேலும் பாட் அதிக புள்ளிகளுடன் முனையில் தொடங்கப்படும் (பல முனைகள் ஒரே நேரத்தில் இந்த நிபந்தனையை பூர்த்தி செய்தால், பிறகு ஒரு சீரற்ற ஒன்று தேர்ந்தெடுக்கப்பட்டது) .
அதே நேரத்தில், திட்டமிடுபவர், ஒரு முனையின் கிடைக்கக்கூடிய ஆதாரங்களை மதிப்பிடும் போது, முதலியன சேமிக்கப்பட்ட தரவால் வழிநடத்தப்படுகிறார் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும் - அதாவது. இந்த முனையில் இயங்கும் ஒவ்வொரு பாட்டின் கோரப்பட்ட/வரம்பு வளத்தின் அளவிற்கு, ஆனால் உண்மையான வள நுகர்வுக்கு அல்ல. இந்த தகவலை கட்டளை வெளியீட்டில் இருந்து பெறலாம் kubectl describe node $NODEஎடுத்துக்காட்டாக:
# 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%)ஒரு குறிப்பிட்ட முனையில் இயங்கும் அனைத்து காய்களையும், ஒவ்வொரு பாட் கோரும் ஆதாரங்களையும் இங்கே காண்கிறோம். cronjob-cron-events-1573793820-xt6q9 பாட் தொடங்கப்படும் போது திட்டமிடல் பதிவுகள் எப்படி இருக்கும் என்பது இங்கே உள்ளது (தொடக்க கட்டளை வாதங்களில் 10 வது பதிவு நிலையை அமைக்கும் போது இந்த தகவல் திட்டமிடல் பதிவில் தோன்றும்):
பதிவு
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தொடக்கத்தில் திட்டமிடுபவர் 3 முனைகளின் பட்டியலை வடிகட்டுவதையும் உருவாக்குவதையும் இங்கு காண்கிறோம் (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). மிகவும் பொருத்தமான முனையைத் தீர்மானிக்க, இந்த ஒவ்வொரு முனைக்கும் பல அளவுருக்கள் (சமச்சீர் வள ஒதுக்கீடு, குறைந்த வள ஒதுக்கீடு உட்பட) அடிப்படையில் மதிப்பெண்களைக் கணக்கிடுகிறது. இறுதியில், பாட் அதிக எண்ணிக்கையிலான புள்ளிகளைக் கொண்ட முனையில் திட்டமிடப்பட்டுள்ளது (இங்கே இரண்டு முனைகளில் ஒரே எண்ணிக்கையிலான புள்ளிகள் 100037 உள்ளது, எனவே ஒரு சீரற்ற ஒன்று தேர்ந்தெடுக்கப்பட்டது - nxs-k8s-s10).
முடிவுக்கு: ஒரு கணு எந்த கட்டுப்பாடுகளும் அமைக்கப்படாத காய்களை இயக்கினால், k8sக்கு (வள நுகர்வுக் கண்ணோட்டத்தில்) இது இந்த முனையில் அத்தகைய காய்கள் எதுவும் இல்லை என்பதற்குச் சமமாக இருக்கும். எனவே, நீங்கள் நிபந்தனையுடன், பெருந்தீனி செயல்முறையுடன் கூடிய ஒரு பாட் வைத்திருந்தால் (உதாரணமாக, wowza) அதற்கு எந்த கட்டுப்பாடுகளும் அமைக்கப்படவில்லை என்றால், இந்த நெற்று உண்மையில் முனையின் அனைத்து வளங்களையும் சாப்பிடும் போது ஒரு சூழ்நிலை ஏற்படலாம், ஆனால் k8 களுக்கு இந்த முனை இறக்கப்பட்டதாகக் கருதப்படுகிறது மேலும் அது வேலை செய்யும் காய்களைக் கொண்டிராத ஒரு முனையாக தரவரிசைப்படுத்தும்போது (துல்லியமாக இருக்கும் ஆதாரங்களை மதிப்பிடும் புள்ளிகளில்) அதே எண்ணிக்கையிலான புள்ளிகள் வழங்கப்படும், இது இறுதியில் முனைகளுக்கு இடையில் சுமையின் சீரற்ற விநியோகத்திற்கு வழிவகுக்கும்.
பாட்டின் வெளியேற்றம்
உங்களுக்கு தெரியும், ஒவ்வொரு பாட்க்கும் 3 QoS வகுப்புகளில் ஒன்று ஒதுக்கப்பட்டுள்ளது:
- உத்தரவாதம் - நினைவகம் மற்றும் சிபியு ஆகியவற்றில் உள்ள ஒவ்வொரு கொள்கலனுக்கும் கோரிக்கை மற்றும் வரம்பு குறிப்பிடப்படும் போது ஒதுக்கப்படும், மேலும் இந்த மதிப்புகள் பொருந்த வேண்டும்
- வெடிக்கக்கூடிய - குறைந்தபட்சம் ஒரு கொள்கலனில் ஒரு கோரிக்கை மற்றும் வரம்பு உள்ளது, கோரிக்கை < வரம்பு
- மிகச்சிறந்த முயற்சி - காய்களில் ஒரு கொள்கலன் கூட வளம் குறைவாக இல்லாதபோது
அதே நேரத்தில், ஒரு முனை வளங்கள் (வட்டு, நினைவகம்) பற்றாக்குறையை அனுபவிக்கும் போது, குபெலெட் ஒரு குறிப்பிட்ட அல்காரிதம் மற்றும் அதன் QoS வகுப்பின் முன்னுரிமையை கணக்கில் எடுத்துக் கொள்ளும் ஒரு குறிப்பிட்ட வழிமுறையின்படி காய்களை தரவரிசைப்படுத்தவும் வெளியேற்றவும் தொடங்குகிறது. எடுத்துக்காட்டாக, நாம் RAM பற்றி பேசுகிறோம் என்றால், QoS வகுப்பின் அடிப்படையில், பின்வரும் கொள்கையின்படி புள்ளிகள் வழங்கப்படுகின்றன:
- உத்தரவாதம்: -998
- சிறந்த முயற்சி: 1000
- வெடிக்கக்கூடியது: குறைந்தபட்சம்(அதிகபட்சம்(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
அந்த. அதே முன்னுரிமையுடன், kubelet முதலில் முனையிலிருந்து QoS வகுப்பின் சிறந்த முயற்சியுடன் காய்களை வெளியேற்றும்.
முடிவுக்கு: நீங்கள் விரும்பிய காய் முனையிலிருந்து வெளியேற்றப்படுவதற்கான வாய்ப்பைக் குறைக்க விரும்பினால், அதில் வளங்கள் இல்லாத பட்சத்தில், முன்னுரிமையுடன், அதற்கான கோரிக்கை/வரம்பை அமைப்பதையும் நீங்கள் கவனித்துக் கொள்ள வேண்டும்.
பயன்பாட்டு காய்களின் (HPA) கிடைமட்ட ஆட்டோஸ்கேலிங்கிற்கான வழிமுறை
வளங்களின் (சிஸ்டம் - சிபியு/ரேம் அல்லது யூசர் - ஆர்பிஎஸ்) காய்களின் எண்ணிக்கையை தானாக அதிகரிக்கவும் குறைக்கவும் பணி செய்யும்போது, இது போன்ற ஒரு k8s நிறுவனம் HPA (கிடைமட்ட பாட் ஆட்டோஸ்கேலர்). இதன் அல்காரிதம் பின்வருமாறு:
- கவனிக்கப்பட்ட வளத்தின் தற்போதைய அளவீடுகள் தீர்மானிக்கப்படுகின்றன (தற்போதைய மெட்ரிக் மதிப்பு)
- வளத்திற்கான விரும்பிய மதிப்புகள் தீர்மானிக்கப்படுகின்றன (desiredMetricValue), இது கணினி ஆதாரங்களுக்கான கோரிக்கையைப் பயன்படுத்தி அமைக்கப்படுகிறது
- தற்போதைய பிரதிகளின் எண்ணிக்கை தீர்மானிக்கப்படுகிறது (தற்போதைய பிரதிகள்)
- பின்வரும் சூத்திரம் விரும்பிய பிரதிகளின் எண்ணிக்கையைக் கணக்கிடுகிறது (விரும்பிய பிரதிகள்)
விரும்பிய பிரதிகள் = [ தற்போதைய பிரதிகள் * (தற்போதைய மெட்ரிக் மதிப்பு / விரும்பியமெட்ரிக் மதிப்பு )]
இந்த வழக்கில், குணகம் (தற்போதைய மெட்ரிக் மதிப்பு / விரும்பிய மெட்ரிக் மதிப்பு) 1 க்கு அருகில் இருக்கும்போது அளவிடுதல் ஏற்படாது (இந்த விஷயத்தில், அனுமதிக்கப்பட்ட பிழையை நாமே அமைக்கலாம்; இயல்பாக இது 0.1 ஆகும்).
ஆப்-சோதனை பயன்பாட்டின் உதாரணத்தைப் பயன்படுத்தி hpa எவ்வாறு செயல்படுகிறது என்பதைப் பார்ப்போம் (வரிசைப்படுத்தல் என விவரிக்கப்படுகிறது), அங்கு CPU நுகர்வைப் பொறுத்து பிரதிகளின் எண்ணிக்கையை மாற்றுவது அவசியம்:
-
விண்ணப்ப மேனிஃபெஸ்ட்
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அந்த. பயன்பாட்டு பாட் ஆரம்பத்தில் இரண்டு நிகழ்வுகளில் தொடங்கப்பட்டதைக் காண்கிறோம், ஒவ்வொன்றும் இரண்டு nginx மற்றும் nginx-ஏற்றுமதி கொள்கலன்களைக் கொண்டுள்ளது, ஒவ்வொன்றிற்கும் ஒரு குறிப்பிட்ட கோரிக்கைகளை CPU க்கு.
-
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அந்த. வரிசைப்படுத்தல் ஆப்-சோதனையைக் கண்காணித்து, cpu இன்டிகேட்டர் அடிப்படையில் (பாட் கோரும் CPU-வில் 30% சதவீதத்தைப் பயன்படுத்த வேண்டும் என்று நாங்கள் எதிர்பார்க்கிறோம்), பிரதிகளின் எண்ணிக்கையுடன், பயன்பாட்டிற்கான காய்களின் எண்ணிக்கையை ஒழுங்குபடுத்தும் hpa ஐ உருவாக்கினோம். 2-10 வரம்பில்.
இப்போது, அடுப்புகளில் ஒன்றில் ஒரு சுமையைப் பயன்படுத்தினால், hpa செயல்பாட்டின் பொறிமுறையைப் பார்ப்போம்:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
மொத்தத்தில் எங்களிடம் பின்வருபவை உள்ளன:
- விரும்பிய மதிப்பு (desiredMetricValue) - hpa அமைப்புகளின்படி, எங்களிடம் 30% உள்ளது
- தற்போதைய மதிப்பு (currentMetricValue) - கணக்கிடுவதற்கு, கட்டுப்படுத்தி-மேலாளர் வள நுகர்வு சராசரி மதிப்பை % இல் கணக்கிடுகிறார், அதாவது. நிபந்தனையுடன் பின்வருவனவற்றைச் செய்கிறது:
- மெட்ரிக் சர்வரில் இருந்து பாட் அளவீடுகளின் முழுமையான மதிப்புகளைப் பெறுகிறது, அதாவது. 101 மீ மற்றும் 4 மீ
- சராசரி முழுமையான மதிப்பைக் கணக்கிடுகிறது, அதாவது. (101 மீ + 4 மீ) / 2 = 53 மீ
- விரும்பிய வள நுகர்வுக்கான முழுமையான மதிப்பைப் பெறுகிறது (இதற்காக, அனைத்து கொள்கலன்களின் கோரிக்கைகளும் சுருக்கப்பட்டுள்ளன) 60m + 30m = 90m
- கோரிக்கை பாட் தொடர்பான CPU நுகர்வு சராசரி சதவீதத்தைக் கணக்கிடுகிறது, அதாவது. 53 மீ / 90 மீ * 100% = 59%
இதைச் செய்ய, பிரதிகளின் எண்ணிக்கையை மாற்ற வேண்டுமா என்பதைத் தீர்மானிக்க வேண்டிய அனைத்தும் இப்போது எங்களிடம் உள்ளன, நாங்கள் குணகத்தைக் கணக்கிடுகிறோம்:
ratio = 59% / 30% = 1.96
அந்த. பிரதிகளின் எண்ணிக்கையை ~2 மடங்கு அதிகரிக்க வேண்டும் மற்றும் அளவு [2 * 1.96] = 4 ஆக அதிகரிக்க வேண்டும்.
முடிவுக்கு: நீங்கள் பார்க்க முடியும் என, இந்த பொறிமுறையானது வேலை செய்ய, கவனிக்கப்பட்ட காய்களில் உள்ள அனைத்து கொள்கலன்களுக்கான கோரிக்கைகளின் இருப்பு அவசியமான நிபந்தனையாகும்.
கணுக்களின் கிடைமட்ட ஆட்டோஸ்கேலிங்கிற்கான வழிமுறை (கிளஸ்டர் ஆட்டோஸ்கேலர்)
சுமை ஏற்றங்களின் போது கணினியில் எதிர்மறையான தாக்கத்தை நடுநிலையாக்க, ஒரு கட்டமைக்கப்பட்ட hpa போதுமானதாக இல்லை. எடுத்துக்காட்டாக, hpa கன்ட்ரோலர் மேலாளரில் உள்ள அமைப்புகளின்படி, பிரதிகளின் எண்ணிக்கையை 2 மடங்கு அதிகரிக்க வேண்டும் என்று முடிவு செய்கிறது, ஆனால் கணுக்களில் இவ்வளவு காய்களை இயக்க இலவச ஆதாரங்கள் இல்லை (அதாவது கணு வழங்க முடியாது கோரிக்கைகளுக்கான ஆதாரங்களைக் கோரியது) மேலும் இந்த காய்கள் நிலுவையில் உள்ள நிலைக்கு மாறுகின்றன.
இந்த வழக்கில், வழங்குநரிடம் தொடர்புடைய IaaS/PaaS (உதாரணமாக, GKE/GCE, AKS, EKS போன்றவை) இருந்தால், இது போன்ற ஒரு கருவி முனை ஆட்டோஸ்கேலர். கிளஸ்டரில் உள்ள அதிகபட்ச மற்றும் குறைந்தபட்ச முனைகளை அமைக்கவும், க்ளஸ்டர் மற்றும் காய்களில் ஆதாரங்கள் இல்லாதபோது, தற்போதைய முனைகளின் எண்ணிக்கையை (கிளவுட் வழங்குநர் API ஐ ஆர்டர் செய்ய/அகற்றுவதற்கு அழைப்பதன் மூலம்) தானாகவே சரிசெய்ய உங்களை அனுமதிக்கிறது. திட்டமிட முடியாது (நிலுவையில் உள்ளன).
முடிவுக்கு: கணுக்களை தானாக அளவிடுவதற்கு, பாட் கொள்கலன்களில் கோரிக்கைகளை அமைக்க வேண்டியது அவசியம், இதனால் k8கள் கணுக்களின் சுமையை சரியாக மதிப்பிட முடியும், அதன்படி அடுத்த பாட் தொடங்குவதற்கு கிளஸ்டரில் எந்த ஆதாரங்களும் இல்லை என்று தெரிவிக்கும்.
முடிவுக்கு
பயன்பாடு வெற்றிகரமாக இயங்குவதற்கு கொள்கலன் வள வரம்புகளை அமைப்பது அவசியமில்லை என்பதைக் கவனத்தில் கொள்ள வேண்டும், ஆனால் பின்வரும் காரணங்களுக்காக அவ்வாறு செய்வது இன்னும் சிறந்தது:
- k8s முனைகளுக்கு இடையில் சுமை சமநிலையின் அடிப்படையில் திட்டமிடுபவரின் மிகவும் துல்லியமான செயல்பாட்டிற்கு
- "பாட் எவிக்ஷன்" நிகழ்வின் வாய்ப்பைக் குறைக்க
- பயன்பாட்டு காய்களின் (HPA) கிடைமட்ட ஆட்டோஸ்கேலிங் வேலை செய்ய
- கிளவுட் வழங்குநர்களுக்கான முனைகளின் (கிளஸ்டர் ஆட்டோஸ்கேலிங்) கிடைமட்ட ஆட்டோஸ்கேலிங்
எங்கள் வலைப்பதிவில் உள்ள மற்ற கட்டுரைகளையும் படிக்கவும்:
ஆதாரம்: www.habr.com