Салом ба ҳама! Номи ман Олег Сидоренков, ман дар DomClick ба ҳайси роҳбари дастаи зерсохтор кор мекунам. Мо зиёда аз се сол аст, ки Кубикро дар истехсолот истифода мебарем ва дар ин муддат бо он лахзахои гуногуни шавковарро аз cap гузарондаем. Имрӯз ман ба шумо мегӯям, ки чӣ гуна бо равиши дуруст шумо метавонед аз ванили Кубернетес барои кластери худ иҷрои боз ҳам бештарро фишурда кунед. Тайёрии устувор!
Ҳамаи шумо хуб медонед, ки Kubernetes як системаи васеъшавандаи кушодаасос барои оркестрсозии контейнерҳо мебошад; хуб, ё 5 бинарӣ, ки бо идоракунии давраи ҳаёти микросервисҳои шумо дар муҳити сервер ҷодугарӣ кор мекунанд. Илова бар ин, он як асбоби хеле чандир аст, ки метавонад ба монанди Lego барои мутобиқсозии ҳадди аксар барои вазифаҳои гуногун ҷамъ карда шавад.
Ва ба назар чунин мерасад, ки ҳама чиз хуб аст: серверҳоро ба кластер ба мисли ҳезум ба қуттии оташ партоед ва шумо ҳеҷ гуна ғаму андӯҳро намедонед. Аммо агар шумо тарафдори муҳити зист бошед, шумо фикр мекунед: "Чӣ гуна метавонам оташро фурӯзон нигоҳ дошта, ҷангалро нигоҳ дошта метавонам?" Ба ибораи дигар, роҳҳои беҳтар кардани инфрасохтор ва кам кардани хароҷотро чӣ гуна бояд ёфт.
1. Мониторинги даста ва захираҳои барнома
Яке аз усулҳои маъмултарин, вале самаранок ин ҷорӣ намудани дархостҳо/лимҳотҳо мебошад. Барномаҳоро аз рӯи фазоҳои номҳо ва фазоҳои номҳоро аз ҷониби гурӯҳҳои таҳиякунанда тақсим кунед. Пеш аз ҷойгиркунӣ, арзишҳои барномаро барои истеъмоли вақти протсессор, хотира ва нигаҳдории эфемерӣ муқаррар кунед.
resources:
requests:
memory: 2Gi
cpu: 250m
limits:
memory: 4Gi
cpu: 500mТавассути таҷриба мо ба хулосае омадем: шумо набояд дархостҳоро аз ҳудуди ду маротиба зиёд кунед. Ҳаҷми кластер дар асоси дархостҳо ҳисоб карда мешавад ва агар шумо ба замимаҳо дар захираҳо фарқият диҳед, масалан, 5-10 маротиба, пас тасаввур кунед, ки гиреҳи шумо ҳангоми пур шудани он ва ногаҳон бори аввал чӣ мешавад. Ҳеҷ чиз хуб нест. Ҳадди ақал, дросселкунӣ ва ҳадди аксар, шумо бо коргар хайрухуш мекунед ва пас аз ба ҳаракат даромадани қубурҳо ба гиреҳҳои боқимонда бори даврӣ мегиред.
Илова бар ин, бо ёрии limitranges Дар оғоз, шумо метавонед арзишҳои захираҳоро барои контейнер муқаррар кунед - ҳадди аққал, ҳадди аксар ва пешфарз:
➜ ~ kubectl describe limitranges --namespace ops
Name: limit-range
Namespace: ops
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 50m 10 100m 100m 2
Container ephemeral-storage 12Mi 8Gi 128Mi 4Gi -
Container memory 64Mi 40Gi 128Mi 128Mi 2Маҳдуд кардани захираҳои фазои номро фаромӯш накунед, то як даста тамоми захираҳои кластерро аз худ карда натавонад:
➜ ~ kubectl describe resourcequotas --namespace ops
Name: resource-quota
Namespace: ops
Resource Used Hard
-------- ---- ----
limits.cpu 77250m 80
limits.memory 124814367488 150Gi
pods 31 45
requests.cpu 53850m 80
requests.memory 75613234944 150Gi
services 26 50
services.loadbalancers 0 0
services.nodeports 0 0Чунон ки аз тавсиф дида мешавад resourcequotas, агар дастаи опсия мехоҳад, ки подкладҳоро ҷойгир кунад, ки 10 CPU-и дигарро истеъмол мекунанд, нақшакаш ба ин иҷозат намедиҳад ва хато мекунад:
Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10Барои ҳалли чунин мушкилот шумо метавонед асбоберо нависед, масалан, монанди , қодир ба захира ва содир намудани ҳолати захираҳои фармон.
2. Анбори оптималии файлро интихоб кунед
Дар ин ҷо ман мехоҳам ба мавзӯи ҳаҷмҳои доимӣ ва зерсистемаи диски гиреҳҳои кории Kubernetes дахл кунам. Ман умедворам, ки ҳеҷ кас "Cube" -ро дар HDD дар истеҳсолот истифода намебарад, аммо баъзан SSD муқаррарӣ дигар кофӣ нест. Мо бо мушкилоте рӯ ба рӯ шудем, ки дар он гузоришҳо дискро аз сабаби амалиёти вуруд/чор мекушанд ва роҳҳои ҳалли он зиёд нест:
-
SSD-ҳои баландсифатро истифода баред ё ба NVMe гузаред (агар шумо сахтафзори худро идора кунед).
-
Коҳиш додани сатҳи сабт.
-
Мувозинати "ақлонаи" қуттиҳое, ки дискро таҷовуз мекунанд (
podAntiAffinity).
Экрани боло нишон медиҳад, ки дар зери nginx-ingress-controller дар диск ҳангоми фаъол кардани сабти access_logs чӣ рӯй медиҳад (~12 ҳазор logs/sc). Ин ҳолат, албатта, метавонад ба таназзули ҳамаи замимаҳо дар ин гиреҳ оварда расонад.
Дар мавриди PV, афсӯс, ки ман ҳама чизро санҷидаам Ҳаҷмҳои доимӣ. Беҳтарин вариантеро, ки ба шумо мувофиқ аст, истифода баред. Таърихан, дар кишвари мо чунин рӯй дод, ки як қисми ками хидматҳо ҳаҷми RWX-ро талаб мекунад ва муддати тӯлонӣ онҳо барои ин вазифа нигоҳдории NFS-ро истифода бурданд. Арзон ва... басанда. Албатта, ману ӯ хӯрдаем - баракат диҳед, аммо мо танзим кардани онро ёд гирифтем ва сарам дигар дард намекунад. Ва агар имконпазир бошад, ба нигаҳдории объекти S3 гузаред.
3. Тасвирҳои оптимизатсияшударо ҷамъ кунед
Беҳтар аст, ки тасвирҳои барои контейнер оптимизатсияшударо истифода баред, то Kubernetes онҳоро зудтар ба даст орад ва онҳоро самараноктар иҷро кунад.
Optimized маънои онро дорад, ки тасвирҳо:
-
дорои танҳо як барнома ё иҷрои танҳо як вазифа;
-
андозаи хурд, зеро тасвирҳои калон тавассути шабака бадтар интиқол дода мешаванд;
-
нуқтаҳои ниҳоии саломатӣ ва омодагӣ дошта бошед, ки ба Кубернетес имкон медиҳанд, ки дар ҳолати бекорӣ чора андешанд;
-
системаҳои оператсионии ба контейнер мувофиқро истифода баред (ба монанди Alpine ё CoreOS), ки ба хатогиҳои конфигуратсия бештар тобоваранд;
-
сохтани бисёрмарҳиларо истифода баред, то шумо метавонед танҳо замимаҳои тартибдодашударо ҷойгир кунед, на манбаъҳои ҳамроҳ.
Воситаҳо ва хидматҳои зиёде мавҷуданд, ки ба шумо имкон медиҳанд, ки тасвирҳоро дар парвоз тафтиш ва оптимизатсия кунед. Муҳим аст, ки онҳоро ҳамеша навсозӣ кунед ва барои бехатарӣ санҷида шавад. Дар натиҷа шумо ба даст меоред:
-
Камшавии сарбории шабака дар тамоми кластер.
-
Коҳиш додани вақти оғози контейнер.
-
Андозаи хурдтари тамоми феҳристи Docker-и шумо.
4. Кэши DNS-ро истифода баред
Агар мо дар бораи сарбории баланд сухан ронем, пас зиндагӣ бидуни танзими системаи DNS кластер хеле бад аст. Як вақтҳо, таҳиягарони Кубернетес ҳалли kube-dns-и онҳоро дастгирӣ мекарданд. Он дар ин ҷо низ амалӣ карда шуд, аммо ин нармафзор махсусан танзим карда нашудааст ва иҷрои лозимиро намедиҳад, гарчанде ки ин кори оддӣ ба назар мерасид. Сипас кореднҳо пайдо шуданд, ки мо ба онҳо гузаштем ва ғамгин набудем; он баъдтар хидмати пешфарз DNS дар K8s шуд. Дар баъзе мавридҳо, мо ба системаи DNS ба 40 ҳазор rps расидем ва ин ҳалли низ нокифоя шуд. Аммо, бо баракат, Nodelocaldns баромад, aka гиреҳи кэши маҳаллӣ, ака .
Чаро мо инро истифода мебарем? Дар ядрои Linux хатогӣ мавҷуд аст, ки ҳангоми зангҳои сершумор тавассути conntrack NAT тавассути UDP, ба ҳолати мусобиқа барои воридшавӣ дар ҷадвалҳои conntrack оварда мерасонад ва як қисми трафик тавассути NAT гум мешавад (ҳар сафар тавассути хидмат NAT аст). Nodelocaldns ин мушкилотро тавассути бартараф кардани NAT ва такмил додани пайвастшавӣ ба TCP ба DNS болооб, инчунин ба таври маҳаллӣ кэшкунии дархостҳои болооби DNS (аз ҷумла кэши манфии кӯтоҳи 5 сония) ҳал мекунад.
5. Миқёси подкҳо ба таври уфуқӣ ва амудӣ ба таври худкор
Оё шумо бо итминон гуфта метавонед, ки тамоми хидматрасониҳои хурди шумо барои ду то се баробар афзоиш додани сарборӣ омодаанд? Чӣ тавр бояд захираҳоро ба барномаҳои худ дуруст тақсим кард? Нигоҳ доштани якчанд подкҳо аз сарбории корӣ метавонад зиёдатӣ бошад, аммо ба қафо нигоҳ доштани онҳо хатари бекорӣ аз афзоиши ногаҳонии трафик ба хидматро дорад. Хизматрасонӣ ба монанди и .
VPA ба шумо имкон медиҳад, ки ба таври худкор дархостҳо / маҳдудиятҳои контейнерҳои худро дар подк вобаста ба истифодаи воқеӣ афзоиш диҳед. Чӣ тавр он метавонад муфид бошад? Агар шумо қуттиҳо дошта бошед, ки бо ягон сабаб ба таври уфуқӣ васеъ карда намешаванд (ки он комилан боэътимод нест), шумо метавонед кӯшиш кунед, ки тағиротро ба захираҳои он ба VPA бовар кунед. Хусусияти он як системаи тавсияест, ки ба маълумоти таърихӣ ва ҷории метрик-сервер асос ёфтааст, бинобар ин, агар шумо намехоҳед, ки дархостҳо/маҳдудиятҳоро ба таври худкор тағир диҳед, шумо метавонед танҳо захираҳои тавсияшударо барои контейнерҳои худ назорат кунед ва танзимотро барои сарфаи CPU ва оптимизатсия кунед. хотира дар кластер.
Тасвир аз https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 гирифта шудааст.
Нақшасоз дар Кубернетес ҳамеша ба дархостҳо асос ёфтааст. Новобаста аз он ки шумо ба он ҷо гузоштаед, нақшакаш гиреҳи мувофиқро дар асоси он ҷустуҷӯ мекунад. Қиматҳои маҳдудиятҳо барои кубелет лозиманд, то фаҳманд, ки кай дроссел кардан ё куштан pod. Ва азбаски ягона параметри муҳим арзиши дархостҳост, VPA бо он кор хоҳад кард. Ҳар вақте ки шумо як барномаро амудӣ васеъ мекунед, шумо муайян мекунед, ки дархостҳо бояд чӣ гуна бошанд. Он гоҳ бо маҳдудиятҳо чӣ мешавад? Ин параметр низ мутаносибан миқёс карда мешавад.
Масалан, дар ин ҷо танзимоти муқаррарии pod ҳастанд:
resources:
requests:
memory: 250Mi
cpu: 200m
limits:
memory: 500Mi
cpu: 350mМуҳаррики тавсиявӣ муайян мекунад, ки барномаи шумо барои дуруст кор кардан 300м CPU ва 500Mi лозим аст. Шумо танзимоти зеринро мегиред:
resources:
requests:
memory: 500Mi
cpu: 300m
limits:
memory: 1000Mi
cpu: 525mТавре ки дар боло зикр гардид, ин миқёси мутаносиб дар асоси таносуби дархостҳо/маҳдудиятҳо дар манифест аст:
-
CPU: 200m → 300m: таносуби 1:1.75;
-
Хотира: 250Mi → 500Mi: таносуби 1:2.
Дар робита ба HPA, пас механизми кор шаффофтар мешавад. Метрикҳо, ба монанди CPU ва хотира, ҳадди ақалл муқаррар карда мешаванд ва агар миёнаи ҳамаи репликаҳо аз ҳадди ниҳоӣ зиёд бошад, барнома то он даме, ки арзиш аз ҳадди ақал афтад ё ба шумораи максималии репликаҳо расид, бо +1 зер андоза карда мешавад.
Тасвир аз https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 гирифта шудааст.
Илова ба ченакҳои муқаррарӣ, ба монанди CPU ва хотира, шумо метавонед дар ченакҳои фармоишии худ аз Prometheus ҳадди муқаррар кунед ва бо онҳо кор кунед, агар шумо фикр кунед, ки ин дақиқтарин нишондиҳандаи кай миқёси барномаи шумост. Пас аз мӯътадил шудани барнома аз ҳадди меъёри муқарраршуда, HPA миқёси подкҳоро то ҳадди ақали репликаҳо ё то он даме, ки сарборӣ ба ҳадди муқарраршуда мувофиқат кунад, оғоз мекунад.
6. Дар бораи Node Affinity ва Pod Affinity фаромӯш накунед
На ҳама гиреҳҳо дар як сахтафзор кор мекунанд ва на ҳама подкҳо бояд барномаҳои пуршиддати ҳисоббарориро иҷро кунанд. Kubernetes ба шумо имкон медиҳад, ки тахассусии гиреҳҳо ва подкҳоро истифода баред Пайвастагии гиреҳ и Пайвастагии под.
Агар шумо гиреҳҳое дошта бошед, ки барои амалиётҳои пуршиддати ҳисоббарор мувофиқанд, пас барои самаранокии максималӣ беҳтар аст, ки барномаҳоро ба гиреҳҳои мувофиқ пайваст кунед. Барои ин истифода баред nodeSelector бо нишони гиреҳ.
Фарз мекунем, ки шумо ду гиреҳ доред: яке бо CPUType=HIGHFREQ ва шумораи зиёди cores рӯза, дигаре бо MemoryType=HIGHMEMORY хотираи бештар ва иҷрои тезтар. Роҳи осонтарини таъин кардани ҷойгиркунӣ ба гиреҳ аст HIGHFREQбо илова ба бахш spec ин интихобкунанда:
…
nodeSelector:
CPUType: HIGHFREQРоҳи гаронтар ва мушаххаси иҷрои ин истифода аст nodeAffinity дар саҳро affinity ҷудокунӣ spec. Ду вариант вуҷуд дорад:
-
requiredDuringSchedulingIgnoredDuringExecution: танзимоти сахт (нақшасоз подкҳоро танҳо дар гиреҳҳои мушаххас ҷойгир мекунад (ва дар ҷои дигар)); -
preferredDuringSchedulingIgnoredDuringExecution: танзимоти нарм (нақшасоз кӯшиш мекунад, ки ба гиреҳҳои мушаххас ҷойгир кунад ва агар ин ноком шавад, он кӯшиш мекунад, ки ба гиреҳи дастраси оянда ҷойгир кунад).
Шумо метавонед синтаксиси мушаххасро барои идоракунии тамғакоғазҳои гиреҳ муайян кунед, масалан In, NotIn, Exists, DoesNotExist, Gt ё Lt. Аммо, дар хотир доред, ки усулҳои мураккаб дар рӯйхатҳои тӯлонии тамғакоғазҳо қабули қарорро дар ҳолатҳои муҳим суст мекунанд. Ба ибораи дигар, онро оддӣ нигоҳ доред.
Тавре ки дар боло зикр гардид, Kubernetes ба шумо имкон медиҳад, ки наздикии подкҳои ҷорӣро муқаррар кунед. Яъне, шумо метавонед итминон ҳосил кунед, ки подкҳои муайян дар як минтақаи мавҷудият (ба абрҳо мувофиқанд) ё гиреҳҳо якҷоя бо дигар подкҳо кор мекунанд.
В podAffinity майдонҳо affinity ҷудокунӣ spec ҳамон майдонҳо, ки дар мавриди nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Ягона фарқият дар он аст matchExpressions подкҳоро ба гиреҳе мепайвандад, ки аллакай бо ин тамға кор мекунад.
Кубернетес инчунин майдонро пешниҳод мекунад podAntiAffinity, ки баръ-акс, подшохро ба гирех бо порахои мушаххас намепайвандад.
Дар бораи ифодаҳо nodeAffinity Ҳамин маслиҳатро додан мумкин аст: кӯшиш кунед, ки қоидаҳоро оддӣ ва мантиқӣ нигоҳ доред, кӯшиш накунед, ки тавсифи подкастро бо маҷмӯи қоидаҳои мураккаб аз ҳад зиёд пур кунед. Эҷоди қоидае хеле осон аст, ки ба шароити кластер мувофиқат накунад, сарбории нолозимро ба нақшакаш эҷод кунад ва иҷрои умумиро коҳиш диҳад.
7. Зангҳо ва таҳаммулпазирӣ
Роҳи дигари идоракунии ҷадвал вуҷуд дорад. Агар шумо як кластери калон бо садҳо гиреҳ ва ҳазорҳо хидматрасонии микросервис дошта бошед, он гоҳ имкон надиҳед, ки поддонҳои муайян дар гиреҳҳои муайян ҷойгир карда шаванд.
Дар ин бобат механизми таънахо — коидахои манъкунй ёрй мерасонад. Масалан, дар сенарияҳои муайян шумо метавонед гиреҳҳои муайянро аз кор кардани pods манъ кунед. Барои истифода бурдани доғ ба гиреҳи мушаххас шумо бояд интихобро истифода баред taint дар kubectl. Калид ва арзишро муайян кунед ва сипас монанди NoSchedule ё NoExecute:
$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoScheduleИнчунин бояд қайд кард, ки механизми доғ се таъсири асосиро дастгирӣ мекунад: NoSchedule, NoExecute и PreferNoSchedule.
-
NoScheduleмаънои онро дорад, ки ҳоло дар мушаххасоти pod ягон вуруди мувофиқ вуҷуд нахоҳад доштtolerations, он наметавонад дар гиреҳ ҷойгир карда шавад (дар ин мисолnode10). -
PreferNoSchedule- версияи соддакардашудаNoSchedule. Дар ин ҳолат, нақшакаш мекӯшад, ки подкладҳоро, ки вуруди мувофиқ надоранд, ҷудо накунадtolerationsбарои як гиреҳ, аммо ин маҳдудияти сахт нест. Агар дар кластер захираҳо мавҷуд набошанд, пас дар ин гиреҳ ҷойгоҳҳо оғоз мекунанд. -
NoExecute- ин таъсир ба эвакуатсияи фаврии қуттиҳое, ки вуруди мувофиқ надоранд, бармеангезадtolerations.
Ҷолиб он аст, ки ин рафтор метавонад бо истифода аз механизми таҳаммулпазирӣ бекор карда шавад. Ин қулай аст, вақте ки гиреҳи "маънӣ" вуҷуд дорад ва ба шумо танҳо лозим аст, ки дар он хидматҳои инфрасохторӣ ҷойгир кунед. Инро чӣ тавр бояд кард? Иҷозат диҳед, ки танҳо он қубурҳое, ки барои онҳо таҳаммулпазирии мувофиқ мавҷуд аст.
Ин аст, ки мушаххасоти pod чӣ гуна хоҳад буд:
spec:
tolerations:
- key: "node-role.kubernetes.io/ingress"
operator: "Equal"
value: "true"
effect: "NoSchedule"Ин маънои онро надорад, ки дубора ҷойгиркунии навбатӣ ба ин гиреҳи мушаххас меафтад, ин механизми наздикии гиреҳ нест ва nodeSelector. Аммо бо омезиши якчанд хусусиятҳо, шумо метавонед танзимоти хеле фасеҳ ба нақша гиред.
8. Афзалияти густариши Pod-ро муқаррар кунед
Танҳо аз он сабаб, ки шумо подкҳоро ба гиреҳҳо таъин кардаед, маънои онро надорад, ки ҳамаи подкҳо бояд бо як афзалият муносибат карда шаванд. Масалан, шумо метавонед мехоҳед, ки баъзе подкҳоро пеш аз дигарон ҷойгир кунед.
Kubernetes роҳҳои гуногуни танзим кардани Priority ва Preemption-ро пешниҳод мекунад. Танзимот аз якчанд қисм иборат аст: объект PriorityClass ва тавсифи майдонҳо priorityClassName дар мушаххасоти pod. Биёед як мисолро дида бароем:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"Мо эҷод мекунем PriorityClass, ба он ном, тавсиф ва арзиш диҳед. Дар олӣ value, афзалияти баландтар аст. Қимат метавонад ҳар як адади бутуни 32-бит камтар ё баробар ба 1 бошад. Қиматҳои баландтар барои порчаҳои системаҳои муҳими миссия ҳифз карда шудаанд, ки онҳоро умуман пешгири кардан мумкин нест. Ҷойивазкунӣ танҳо дар сурате ба амал меояд, ки як паҳлӯи афзалиятнок ҷойе барои гардиш надошта бошад, пас баъзе аз қуттиҳои гиреҳи муайян эвакуатсия карда мешаванд. Агар ин механизм барои шумо хеле сахт бошад, шумо метавонед вариантро илова кунед preemptionPolicy: Never, ва он гоҳ ҳеҷ гуна имтиёз вуҷуд надорад, подкаст аввал дар навбат меистад ва интизор мешавад, ки нақшакаш барои он захираҳои ройгон пайдо кунад.
Баъдан, мо як паҳлӯ эҷод мекунем, ки дар он номро нишон медиҳем priorityClassName:
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
priorityClassName: high-priority
Шумо метавонед шумораи зиёди синфҳои афзалиятнокро, ки мехоҳед, эҷод кунед, гарчанде ки тавсия дода мешавад, ки бо ин кор нашавед (бигӯед, ки худро бо афзалиятҳои паст, миёна ва баланд маҳдуд кунед).
Ҳамин тариқ, дар ҳолати зарурӣ, шумо метавонед самаранокии ҷойгиркунии хидматҳои муҳимро ба монанди nginx-ingress-controller, coredns ва ғайра афзоиш диҳед.
9. Кластери ETCD-ро оптимизатсия кунед
ETCD-ро метавон мағзи тамоми кластер номид. Дар сатҳи баланд нигоҳ доштани кори ин база хеле муҳим аст, зеро суръати амалиёт дар Cube аз он вобаста аст. Як роҳи хеле стандартӣ ва ҳамзамон, ҳалли хуб ин аст, ки кластери ETCD дар гиреҳҳои асосӣ нигоҳ дошта шавад, то ҳадди ақал таъхир ба kube-apiserver дошта бошад. Агар шумо ин корро карда натавонед, пас ETCD-ро ба қадри имкон наздик, бо фарохмаҷрои хуби байни иштирокчиён ҷойгир кунед. Ҳамчунин диққат диҳед, ки чӣ қадар гиреҳҳои ETCD метавонанд бе зарар ба кластер афтанд
Дар хотир доред, ки аз ҳад зиёд зиёд кардани шумораи аъзоён дар кластер метавонад таҳаммулпазирии хатогиҳоро аз ҳисоби иҷроиш зиёд кунад, ҳама чиз бояд дар миёнарав бошад.
Агар мо дар бораи таъсиси хидмат гап занем, чанд тавсия вуҷуд дорад:
-
Дар асоси андозаи кластер сахтафзори хуб дошта бошед (шумо метавонед хонед ).
-
Якчанд параметрҳоро тағир диҳед, агар шумо кластерро байни як ҷуфт DC ё шабакаи худ паҳн карда бошед ва дискҳо чизи дилхоҳро тарк кунед (шумо метавонед хонед ).
хулоса
Ин мақола нуктаҳоеро тавсиф мекунад, ки дастаи мо кӯшиш мекунад, ки онҳоро риоя кунад. Ин тавсифи зина ба зина амалҳо нест, балки имконотест, ки метавонанд барои оптимизатсияи сарбории кластер муфид бошанд. Равшан аст, ки ҳар як кластер ба таври худ беназир аст ва ҳалли конфигуратсия метавонад хеле фарқ кунад, аз ин рӯ гирифтани фикру мулоҳизаҳои шумо дар бораи чӣ гуна назорат кардани кластери Kubernetes ва чӣ гуна беҳтар кардани кори он ҷолиб хоҳад буд. Таҷрибаи худро дар шарҳҳо мубодила кунед, донистани он ҷолиб хоҳад буд.
Манбаъ: will.com