Әдетте, оның дұрыс және тұрақты жұмыс істеуі үшін қолданбаға ресурстардың арнайы пулын беру әрқашан қажет. Бірақ бірнеше қолданба бір қуатта жұмыс істеп тұрса ше? Олардың әрқайсысын ең аз қажетті ресурстармен қалай қамтамасыз ету керек? Ресурс тұтынуды қалай шектеуге болады? Жүктемені түйіндер арасында қалай дұрыс бөлуге болады? Қолданба жүктемесі артқан жағдайда көлденең масштабтау механизмінің жұмыс істеуін қалай қамтамасыз етуге болады?
Жүйеде қандай негізгі ресурстар түрлері бар екенінен бастау керек - бұл, әрине, процессордың уақыты мен жедел жады. k8s манифестерінде бұл ресурс түрлері келесі бірліктермен өлшенеді:
- CPU - ядроларда
- ЖЖҚ – байтпен
Сонымен қатар, әрбір ресурс үшін талаптардың екі түрін орнатуға болады - сұраулар и шектеулер. Сұраулар - контейнерді іске қосу үшін түйіннің (және тұтастай қосқыш) бос ресурстарына қойылатын минималды талаптарды сипаттайды, ал шектеулер контейнерге қолжетімді ресурстарға қатаң шектеу қояды.
Манифесттің екі түрін де нақты анықтау қажет емес екенін түсіну маңызды, бірақ мінез-құлық келесідей болады:
- Егер ресурстың шектеулері ғана нақты көрсетілген болса, онда бұл ресурсқа арналған сұраулар автоматты түрде шектеулерге тең мәнді қабылдайды (оны сипаттау нысандарына қоңырау шалу арқылы тексеруге болады). Анау. шын мәнінде, контейнер іске қосу үшін қажет ресурстардың бірдей мөлшерімен шектеледі.
- Егер ресурс үшін тек сұраулар нақты көрсетілген болса, онда бұл ресурста ешқандай жоғарғы шектеулер орнатылмайды - яғни. контейнер тек түйіннің ресурстарымен шектеледі.
Сондай-ақ ресурстарды басқаруды тек белгілі бір контейнер деңгейінде ғана емес, сонымен қатар келесі нысандарды пайдаланып аттар кеңістігі деңгейінде конфигурациялауға болады:
- LimitRange — контейнер/под деңгейінде шектеу саясатын ns-де сипаттайды және контейнер/подкадағы әдепкі шектеулерді сипаттау, сондай-ақ айқын майлы ыдыстар/подтар (немесе керісінше) жасалуын болдырмау, олардың санын шектеу үшін қажет. және шектеулер мен сұраныстардағы мәндердегі мүмкін айырмашылықты анықтаңыз
- Ресурс квоталары — ns ішіндегі барлық контейнерлер үшін жалпы шектеу саясатын сипаттаңыз және әдетте орталар арасындағы ресурстарды шектеу үшін қолданылады (орталар түйін деңгейінде қатаң демаркацияланбаған кезде пайдалы)
Төменде ресурс шектеулерін орнататын манифесттердің мысалдары берілген:
-
Арнайы контейнер деңгейінде:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mАнау. бұл жағдайда nginx бар контейнерді іске қосу үшін сізге кемінде 1G бос жедел жады және түйінде 0.2 орталық процессор қажет болады, бұл ретте контейнер ең көбі 0.2 орталық процессорды және түйіндегі барлық қолжетімді жедел жадты тұтына алады.
-
ns бүтін деңгейінде:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiАнау. әдепкі ns ішіндегі барлық сұрау контейнерлерінің қосындысы орталық процессор үшін 300 м-ден және ОС үшін 1G-ден аспауы керек, ал барлық шектеулердің қосындысы орталық процессор үшін 700 м және ОС үшін 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 үшін 100 м және ОП үшін 1G, шектеу - 1 CPU және 2G болып орнатылады. Сонымен қатар, CPU (50m < x < 2) және RAM (500M < x < 4G) үшін сұраныс/лимитте мүмкін мәндерге де шектеу қойылады.
-
Pod деңгейіндегі шектеулер:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiАнау. әдепкі ns ішіндегі әрбір подвод үшін 4 vCPU және 1G шегі болады.
Енді осы шектеулерді орнату бізге қандай артықшылықтар бере алатынын айтқым келеді.
Түйіндер арасындағы жүктемені теңестіру механизмі
Өздеріңіз білетіндей, k8s құрамдас бөлігі түйіндер арасында түйіндердің таралуына жауап береді, мысалы жоспарлаушы, ол белгілі бір алгоритм бойынша жұмыс істейді. Бұл алгоритм іске қосу үшін оңтайлы түйінді таңдау кезінде екі кезеңнен өтеді:
- сүзу
- Диапазон
Анау. сипатталған саясатқа сәйкес, бастапқыда жиынтық негізінде подкастты іске қосуға болатын түйіндер таңдалады предикаттар (соның ішінде түйінде қосқышты іске қосу үшін жеткілікті ресурстар бар-жоғын тексеру - PodFitsResources), содан кейін осы түйіндердің әрқайсысы үшін сәйкес басымдықтары ұпайлар беріледі (соның ішінде түйінде неғұрлым бос ресурстар болса, соғұрлым көп ұпай беріледі - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) және подкаст ең көп ұпай жинаған түйінде іске қосылады (егер бірнеше түйін бірден осы шартты қанағаттандырса, онда кездейсоқ біреуі таңдалады).
Сонымен қатар, жоспарлаушы түйіннің қол жетімді ресурстарын бағалау кезінде etcd ішінде сақталған деректерді басшылыққа алатынын түсінуіңіз керек, яғни. осы түйінде іске қосылған әрбір подводтың сұралған/шектеу ресурсының сомасы үшін, бірақ нақты ресурс тұтыну үшін емес. Бұл ақпаратты пәрмен шығысынан алуға болады 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 қосқышы іске қосылғанда жоспарлаушы журналдары қандай болады (бұл ақпарат іске қосу пәрменінің дәлелдерінде -v=10 журналының 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) сүзгілері мен тізімін жасайтынын көреміз. Содан кейін ол ең қолайлы түйінді анықтау үшін осы түйіндердің әрқайсысы үшін бірнеше параметрлерге (соның ішінде BalancedResourceAllocation, LeastResourceAllocation) негізделген ұпайларды есептейді. Сайып келгенде, подкаст ең көп ұпай саны бар түйінге жоспарланған (мұнда бірден екі түйінде бірдей нүктелер саны 100037, сондықтан кездейсоқ біреуі таңдалады - nxs-k8s-s10).
қорытынды: егер түйін шектеулер орнатылмаған подкасттарды іске қосса, онда k8s үшін (ресурсты тұтыну тұрғысынан) бұл осы түйінде мүлде ондай қосқыштар болмағанмен тең болады. Сондықтан, егер сізде, шартты түрде, ашкөз процесі бар (мысалы, wowza) және оған ешқандай шектеулер орнатылмаған болса, онда бұл подвод түйіннің барлық ресурстарын жеген кезде жағдай туындауы мүмкін, бірақ k8s үшін бұл түйін. жүктелмеген болып саналады және оған жұмыс баптары жоқ түйін ретінде рейтингілеу кезінде (дәл қол жетімді ресурстарды бағалайтын ұпайларда) бірдей ұпайлар беріледі, бұл сайып келгенде түйіндер арасында жүктеменің біркелкі бөлінбеуіне әкелуі мүмкін.
Подты шығару
Өздеріңіз білетіндей, әрбір подводқа 3 QoS класының біреуі тағайындалған:
- кепілдік берілген — подкасттағы әрбір контейнер үшін жад пен процессор үшін сұрау мен шектеу көрсетілгенде тағайындалады және бұл мәндер сәйкес болуы керек
- жарылғыш — подкасттағы кем дегенде бір контейнерде сұрау және шектеу бар, сұраныс < шектеуі бар
- ең жақсы күш — қоршаудағы бірде-бір контейнер ресурс шектелмегенде
Сонымен қатар, түйін ресурстардың (диск, жад) жетіспеушілігін сезінгенде, kubelet подкасттың басымдылығын және оның QoS сыныбын ескеретін белгілі бір алгоритмге сәйкес бөлімшелерді дәрежелеуді және шығаруды бастайды. Мысалы, егер біз RAM туралы айтатын болсақ, онда QoS класына негізделген ұпайлар келесі принцип бойынша беріледі:
- Кепілдік: -998
- BestEffort: 1000
- Жарылғыш: мин(макс(2, 1000 - (1000 * жадСұранысБайты) / machineMemoryCapacityBytes), 999)
Анау. бірдей басымдықпен, kubelet алдымен түйіннен QoS класының ең жақсы күш-жігері бар қосқыштарды шығарады.
қорытынды: егер сізде ресурстар жетіспеген жағдайда қалаған подкасттың түйіннен шығарылу ықтималдығын азайтқыңыз келсе, онда басымдылықпен қатар оған сұрау/шектеуді орнату туралы да қамқорлық жасауыңыз керек.
Қолданбалы бөліктерді көлденең автомасштабтау механизмі (HPA)
Тапсырма ресурстарды (жүйе - CPU/RAM немесе пайдаланушы - rps) пайдалануына байланысты блоктардың санын автоматты түрде көбейту және азайту болған кезде, мұндай k8s нысаны HPA (Көлденең Pod Autoscaler). Оның алгоритмі келесідей:
- Бақыланатын ресурстың ағымдағы көрсеткіштері анықталады (currentMetricValue)
- Ресурс үшін қажетті мәндер анықталады (desiredMetricValue), олар жүйелік ресурстар үшін сұрау арқылы орнатылады
- Көшірмелердің ағымдағы саны анықталды (ағымдағы репликалар)
- Келесі формула көшірмелердің қажетті санын есептейді (desiredReplicas)
қалағанРепликалар = [ағымдағыРепликалар * (CurrentMetricValue / қалағанМетрицМән)]
Бұл жағдайда коэффициент (currentMetricValue / wantdMetricValue) 1-ге жақын болғанда масштабтау болмайды (бұл жағдайда рұқсат етілген қатені өзіміз орнатуға болады; әдепкі бойынша ол 0.1).
Процессордың тұтынуына байланысты көшірмелердің санын өзгерту қажет болатын қолданба сынақ қолданбасының (орналастыру ретінде сипатталған) мысалын пайдаланып hpa қалай жұмыс істейтінін қарастырайық:
-
Қолданба манифесті
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 индикаторы негізінде қолданбамен қосқыштар санын реттейтін hpa жасадық (подлок өзі сұраған орталық процессордың 30%-ын тұтынуы керек деп күтеміз). 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м
- Қажетті ресурстарды тұтынудың абсолютті мәнін алады (ол үшін барлық контейнерлердің сұраулары жинақталған) 60м + 30м = 90м
- Сұраныс алаңына қатысты орталық процессорды тұтынудың орташа пайызын есептейді, яғни. 53м / 90м * 100% = 59%
Енді бізде көшірмелердің санын өзгерту керек пе, жоқ па анықтау үшін қажет нәрсенің бәрі бар; ол үшін коэффициентті есептейміз:
ratio = 59% / 30% = 1.96
Анау. көшірмелердің санын ~2 есе көбейту керек және [2 * 1.96] = 4 құрайды.
Қорытынды: Көріп отырғаныңыздай, бұл механизм жұмыс істеуі үшін қажетті шарт - бақыланатын бөлімшедегі барлық контейнерлерге сұраныстардың болуы.
Түйіндерді көлденең автомасштабтау механизмі (Cluster Autoscaler)
Жүктеменің жоғарылауы кезінде жүйеге жағымсыз әсерді бейтараптандыру үшін конфигурацияланған hpa жеткіліксіз. Мысалы, hpa контроллері менеджеріндегі параметрлерге сәйкес, ол көшірмелердің санын 2 есе көбейту керек деп шешеді, бірақ түйіндердің мұндай сандық қосқыштарды іске қосу үшін бос ресурстары жоқ (яғни, түйін сұралған ресурстарды сұраулар бөлімшесіне) және бұл подкасттар Күту күйіне ауысады.
Бұл жағдайда, егер провайдерде сәйкес IaaS/PaaS болса (мысалы, GKE/GCE, AKS, EKS және т.б.), сияқты құрал Түйіннің автоматты масштабтаушысы. Ол кластердегі түйіндердің максималды және ең аз санын орнатуға және кластер мен блоктарда ресурстар жетіспегенде түйіндердің ағымдағы санын автоматты түрде реттеуге мүмкіндік береді (түйінге тапсырыс беру/жою үшін бұлттық провайдер API қызметіне қоңырау шалу арқылы). жоспарлау мүмкін емес (күтуде).
Қорытынды: Түйіндерді автомасштабтау мүмкіндігін алу үшін, k8s түйіндердегі жүктемені дұрыс бағалай алатындай және тиісінше келесі подкастты іске қосу үшін кластерде ресурстардың жоқтығы туралы хабарлауы үшін подконтейнерлерде сұрауларды орнату қажет.
қорытынды
Контейнер ресурстарының шектеулерін орнату қолданбаның сәтті жұмыс істеуі үшін талап емес екенін ескеру керек, бірақ келесі себептерге байланысты мұны жасаған дұрыс:
- k8s түйіндері арасындағы жүктемені теңестіру тұрғысынан жоспарлаушының дәлірек жұмыс істеуі үшін
- «Подты шығару» оқиғасының орын алу ықтималдығын азайту үшін
- Қолданба подкасттарын (HPA) жұмыс істеу үшін көлденең автомасштабтау үшін
- Бұлт провайдерлері үшін түйіндерді көлденең автомасштабтау үшін (Cluster Autoscaling).
Сондай-ақ біздің блогтағы басқа мақалаларды оқыңыз:
Ақпарат көзі: www.habr.com