Përshëndetje të gjithëve! Unë quhem Oleg Sidorenko, punoj në kompaninë DomKlik si drejtues i ekipit të infrastrukturës. Ne kemi operuar "Kubikun" në prodhim për më shumë se tre vjet, dhe gjatë kësaj kohe kemi përjetuar shumë momente interesante me të. Sot do t'ju tregoj si, me një qasje të duhur, mund të nxjerrni edhe më shumë performancë nga Kubernetes-i "vanil" për klasterin tuaj. Gati, qëndroni dhe shikoni!
Të gjithë e dini mirë se Kubernetes është një sistem i shkallëzueshëm me kod të hapur për orkestrimin e konteinerëve; në fakt, është 5 binarë që kryejnë magji duke menaxhuar ciklin e jetës së mikroshërbimeve tuaja në një mjedis serveri. Për më tepër, është një mjet mjaft fleksibël, që mund të ndërtohet si një konstruktori Lego, për maksimizimin e personalizimit për detyra të ndryshme.
Dhe duket gjithçka mirë: hedh serverat në klaster, si drutë në zjarr, dhe nuk e di për lodhjen. Por nëse je për ekologjinë, do të mendosh: "Si mund ta mbaj zjarrin në sobë dhe të kem mëshirë për pyllin?". Me fjalë të tjera, si të gjejmë mënyra për të përmirësuar infrastrukturën dhe për të ulur kostot.
1. Ndiqni burimet e ekipeve dhe aplikacioneve
Një nga metodat më të thjeshta, por efektive është vendosja e requests/limits. Përdorni namespace për të ndarë aplikacionet, dhe ndjeni namespace sipas grupeve të zhvillimit. Caktoni vlerat e konsumit të kohës procesor, memories dhe ruajtjes efemere para se të bëni deploy për aplikacionin.
resources:
requests:
memory: 2Gi
cpu: 250m
limits:
memory: 4Gi
cpu: 500mSipas përvojës tonë, nuk duhet të rrisni requests përtej limitit më shumë se dyfish. Vëllimi i klasterit llogaritet bazuar në requests, dhe nëse do të caktoni një ndryshim në burime për aplikacionet, për shembull 5-10 herë, imagjinoni se çfarë do të ndodhë me nodën tuaj kur ajo do të mbushet me pod dhe papritur do të marrë ngarkesë. Absolutisht asgjë e mirë. Në minimum, do të keni trottling, dhe në maksimum, do të përshëndeteni me workerin dhe do të merrni një ngarkesë ciklike në nodat e tjera pasi pod et do të fillojnë të lëvizin.
PĂ«r mĂ« tepĂ«r, me ndihmĂ«n e limitranges mund tĂ« caktoni nga fillimi vlerat pĂ«r burimet e kontejnerit â minimale, maksimale dhe ndryshe:
â ~ 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 2Mos u kujtoni të kufizoni burimet e emërhapësit, në mënyrë që një ekip të mos marrë të gjithë burimet e klasterit:
â ~ 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 0Siç shihet nga përshkrimi resourcequotas, nëse ekipi ops dëshiron të vendosë pod-e që do të konsumonin 10 cpu më shumë, planifikuesi nuk do ta lejojë këtë dhe do të japë një gabim:
Gabim në krijim: pod-et "nginx-proxy-9967d8d78-nh4fs" janë të ndaluara: tejkaloi kuotën: resource-quota, e kërkuar: limits.cpu=5, requests.cpu=5, e përdorur: limits.cpu=77250m, requests.cpu=53850m, e kufizuar: limits.cpu=10, requests.cpu=10Për të zgjidhur një problem të tillë, mund të shkruani një mjet, për shembull, si , që është në gjendje të ruajë dhe të angazhojë gjendjen e burimeve të ekipeve.
2. Zgjidhni ruajtjen optimale të skedarëve
Këtu do të doja të trajtoja temën e volumeve persistente dhe sistemit të disqeve të nodave punëtorë Kubernetes. Shpresoj që askush të mos përdorë "Kub" në HDD në prodhim, por ndonjëherë edhe një SSD i zakonshëm nuk mjafton më. Kemi hasur një problem ku log-et prisnin disqet nga operacionet e hyrje-daljes, dhe këtu opsionet e zgjidhjes nuk janë shumë:
Të përdorim SSD me performancë të lartë ose të kalojmë në NVMe (nëse keni kontroll mbi harduerin tuaj).
Të reduktojmë nivelin e regjistrimit.
Të bëjmë një balansim "të mençur" të pod-ëve që ngarkojnë disqin (
podAntiAffinity).
Screenshot-i më sipër tregon se çfarë ndodh me nginx-ingress-controller në disk kur është aktivizuar regjistrimi i access_logs (~12 mijë regjistrime/sec.). Ky gjendje, natyrisht, mund të çojë në degradimin e të gjitha aplikacioneve në këtë nod.
Sa i pĂ«rket PV, fatkeqĂ«sisht, nuk kam provuar tĂ« gjitha Vullnet e qĂ«ndrueshme. PĂ«rdorni opsionin mĂ« tĂ« mirĂ« qĂ« i pĂ«rshtatet ju. Historikisht, njĂ« pjesĂ« e vogĂ«l e shĂ«rbimeve ka nevojĂ« pĂ«r vĂ«llime RWX, dhe prej kohĂ«sh kemi pĂ«rdorur ruajtjen NFS pĂ«r kĂ«tĂ« qĂ«llim. E lirĂ« dhe... e mjaftueshme. Sigurisht, kemi pasur disa probleme â sidoqoftĂ«, por kemi mĂ«suar ta optimizojmĂ«, dhe tani nuk kemi mĂ« dhimbje koke. Po nĂ«se Ă«shtĂ« e mundur, kaloni nĂ« ruajtjen objektive S3.
3. Mblidhni imazhe të optimizuara
MĂ« mirĂ« Ă«shtĂ« tĂ« pĂ«rdoren imazhe tĂ« optimizuara pĂ«r kontejnerĂ«t, nĂ« mĂ«nyrĂ« qĂ« Kubernetes tĂ« mund t'i nxjerrĂ« ato mĂ« shpejt dhe t'i ekzekutojĂ« mĂ« efikasht.Â
Optimizimi do të thotë që imazhet:
përmbajnë vetëm një aplikacion ose kryejnë vetëm një funksion;
janë të vogla, sepse imazhet e mëdha përhapen më keq në rrjet;
kanë pika fundore për kontrollin e funksionit dhe gatishmërisë, me ndihmën e të cilave Kubernetes mund të ndërmarrë veprime në rast të ndërprerjeve;
përdorin sisteme operative të përshtatshme për kontejnerët (si Alpine ose CoreOS), të cilat janë më të qëndrueshme ndaj gabimeve në konfigurim.
përdorin ndërtimet me shumë etapa, në mënyrë që të mund të shpërndani vetëm aplikacionet e kompiluar dhe jo burimet e shoqëruara.
Ka shumĂ« mjete dhe shĂ«rbime qĂ« lejojnĂ« tĂ« kontrolloni dhe optimizoni imazhet nĂ« flukso. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« t'i mbani gjithmonĂ« ato tĂ« azhurnuara dhe tĂ« verifikuara pĂ«r sigurinĂ«. Si rezultat, merrni:
Reduktimi i ngarkesës në rrjet për të gjithë klasterin.
Përmirësimi i kohës së nisjes së kontenierit.
Vëllimi më i vogël i të gjithë regjistrit tuaj Docker.
4. PĂ«rdorni cache DNS
Nëse flasim për ngarkesa të larta, pa optimizimin e sistemit DNS të klasterit, është mjaft e vështirë. Disa kohë më parë, zhvilluesit e Kubernetes mbështetën zgjidhjen e tyre kube-dns. Kjo ishte implementuar edhe nga ne, por ky softwar nuk u optimizua siç duhet dhe nuk ofronte performancën e nevojshme, megjithëse, duket se detyra ishte e thjeshtë. Pastaj erdhi coredns, në të cilin kaluam dhe u lirua nga shqetësimet, më pas ai u bë shërbimi DNS i parazgjedhur në K8s. Në një moment arritëm deri në 40,000 rps në sistemin DNS, dhe kjo zgjidhje gjithashtu filloi të mos mjaftonte. Por, për një rast të lumtur, doli Nodelocaldns, ai është cache lokal i nodit, ai gjithashtu .
Pse e përdorim këtë? Në bërthamën e Linux-it ka një defekt, i cili gjatë shumë qasjeve përmes conntrack NAT për UDP çon në një gjendje garuese për shkrim në tabelat conntrack, duke bërë që disa nga trafiku përmes NAT të humbasë (çdo vizitë përmes Shërbimit është NAT). Nodelocaldns e zgjidh këtë problem duke e eliminuar NAT dhe duke përmirësuar lidhjen për TCP në DNS-të upstream, si dhe duke bërë keqyerjen lokale të kërkesave DNS në upstream (duke përfshirë një keqyerje negative të shpejtë për 5 sekonda).
5. Shkallëzoni pod-et automatikisht në mënyrë horizontale dhe vertikale.
A mund të thoni me siguri se të gjitha mikro-shërbimet tuaja janë të gatshme për një rritje dy deri në tri herë të ngarkesës? Si të ndani burimet më së miri për aplikacionet tuaja? Të mbani disa pod-e të aktivizuara përtej ngarkesës mund të jetë e tepruar, ndërsa të mbani në kufij rrezikon ndalimin për shkak të rritjes së papritur të trafikut në shërbim. Një mesatare e artë ndihmohet nga formulimi i zmadhuar të këtyre shërbimeve si dhe .
VPA lejon automatikisht rritjen e requests/limits të kontenerëve tuaj në pod në varësi të përdorimit të faktik. Si mund të jetë kjo e dobishme? Nëse keni pod që për arsye të caktuara nuk mund të skalen horizontalisht (të cilat nuk janë krejtësisht të besueshme), mund të provoni t'i besoni VPA-së për ndryshimin e burimeve të tij. Karakteristika e tij qëndron në sistemin e rekomandimeve bazuar në të dhënat historike dhe aktuale nga metric-server, kështu që, nëse nuk dëshiron të ndryshosh automatikisht requests/limits, mund thjesht të ndjekësh burimet e rekomanduara për konteinerët tuaj dhe të optimizosh cilësimet për kursimin e CPU-s dhe memorjes në klaster.
Imazhi është marrë nga https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Planifikuesi nĂ« Kubernetes gjithmonĂ« bazohet nĂ« requests. Ădo vlerĂ« qĂ« vendosni atje, planifikuesi do tĂ« kĂ«rkojĂ« njĂ« nodĂ« tĂ« pĂ«rshtatshme bazuar nĂ« atĂ«. Vlerat e limits janĂ« tĂ« nevojshme pĂ«r kubeletin pĂ«r tĂ« kuptuar kur tĂ« kufizojĂ« ose tĂ« vrasĂ« njĂ« pod. Dhe pasi parametri i vetĂ«m i rĂ«ndĂ«sishĂ«m Ă«shtĂ« vlera e requests, VPA do tĂ« punojĂ« me tĂ«. Sa herĂ« qĂ« pĂ«rcaktoni shkallĂ«zimin vertikal tĂ« aplikacionit, ju pĂ«rcaktoni se çfarĂ« duhet tĂ« jenĂ« requests. Por çfarĂ« do tĂ« ndodhĂ« me limits? Ky parameter do tĂ« shkallĂ«zohet gjithashtu proporcionalisht.
Për shembull, ja konfigurimet e zakonshme të një podi:
resources:
requests:
memory: 250Mi
cpu: 200m
limits:
memory: 500Mi
cpu: 350mMekanizmi i rekomandimeve përcakton se aplikacionit tuaj i nevojiten 300m CPU dhe 500Mi për të funksionuar normalisht. Do të merrni këto konfigurime:
resources:
requests:
memory: 500Mi
cpu: 300m
limits:
memory: 1000Mi
cpu: 525mSiç u përmend më sipër, kjo është shkallëzim proporcional bazuar në raportin requests/limits në manifest:
CPU: 200m â 300m: raporti 1:1.75;
Memory: 250Mi â 500Mi: raporti 1:2.
Sa i përket HPA, atëherë mekanizmi i funksionimit është më transparent. Vlerat kufitare të metrikave, për shembull, të procesorëve dhe memories, vendosen, dhe nëse vlera mesatare e të gjitha replikave kalon kufirin, aplikacioni përmirësohet me +1 pod derisa vlera të bjerë nën kufirin, ose derisa të arrihet numri maksimal i replikave.
Imazhi është marrë nga https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Përveç metrikave të zakonshme, si procesori dhe memoria, ju mund të konfiguroni kufijtë për metrikat tuaja të personalizuara nga Prometheus dhe të punoni me to, nëse e konsideroni këtë përcaktim më të saktë për kur duhet të përmirësoni aplikacionin tuaj. Pasi aplikacioni të stabilizohet nën kufirin e caktuar të metrikës, HPA do të fillojë të reduktojë pod-et deri në numrin minimal të replikave ose deri në gjendjen kur ngarkesa do të përmbushë kufirin e caktuar.
6. Mos harroni për Node Affinity dhe Pod Affinity
Nuk të gjitha nodet punojnë me të njëjtin hardware, dhe jo të gjitha podet duhet të ekzekutojnë aplikacione që kërkojnë llogaritje intensive. Kubernetes lejon përcaktimin e specializimit të nodave dhe podëve me anë të Node Affinity dhe Pod Affinity.
Nëse keni nodë të përshtatshme për operacione me intensitet të lartë, për efikasitet maksimal është më mirë të lidhni aplikacionet me nodat përkatëse. Përdorni nodeSelector me etiketën e nodës.
Le të themi se keni dy nodë: një me CPUType=HIGHFREQ dhe shumë bërthama të shpejta, dhe një tjetër me MemoryType=HIGHMEMORY një sasi të madhe memorie dhe performancë më të lartë. Më e lehtë është të caktoni shpërndarjen e pod-it te nodi HIGHFREQ, duke shtuar në seksionin spec një selektor të tillë:
âŠ
nodeSelector:
CPUType: HIGHFREQNjë mënyrë më të kushtueshme dhe specifike për ta bërë këtë është të përdorni në diskun e atij nodi, të cilit dëshirojmë t'i lidhim Prometheus: në shembull është e caktuar në fushën affinity në seksionin spec. Ka dy opsione:
requiredDuringSchedulingIgnoredDuringExecution: konfigurim i ngurtë (planifikuesi do të shpërndajë pod-et vetëm në nodat specifike (dhe askund tjetër));preferredDuringSchedulingIgnoredDuringExecution: konfigurim i butë (planifikuesi do të përpiqet të shpërndajë në nodat specifike, dhe nëse nuk arrin, do të përpiqet të shpërndajë në nodin tjetër të disponueshëm).
Mund të përcaktoni një sintaksë të caktuar për menaxhimin e etiketave të nodës, për shembull, In, NotIn, Exists, DoesNotExist, Gt ose Lt. Megjithatë, mbani mend se metodat e ndërlikuara në lista të gjata etiketash do ta ngadalësojnë vendimmarrjen në situata kritike. Me fjalë të tjera, mos e kompliko.
Siç u përmend më sipër, Kubernetes lejon të caktosh ngjashmërinë e pods aktuale. Në thelb, mund të bësh që disa pods të punojnë së bashku me pods të tjera në të njëjtën zonë disponibiliteti (relevante për cloud) ose nodes.
Në podAffinity fushat affinity në seksionin spec janë të disponueshme të njëjtat fusha si në rastin e në diskun e atij nodi, të cilit dëshirojmë t'i lidhim Prometheus: në shembull është e caktuar: requiredDuringSchedulingIgnoredDuringExecution dhe preferredDuringSchedulingIgnoredDuringExecution. Dallimi i vetëm është se matchExpressions do të ngjisë pods në node-në ku tashmë ekzekutohet një pod me atë etiketë.
Për më tepër, Kubernetes ofron fushën podAntiAffinity, e cila, nga ana tjetër, nuk e ngjisë podin në nodet me pods të caktuara.
Sa i pĂ«rket shprehjeve nĂ« diskun e atij nodi, tĂ« cilit dĂ«shirojmĂ« t'i lidhim Prometheus: nĂ« shembull Ă«shtĂ« e caktuar mund tĂ« jepet e njĂ«jta kĂ«shillĂ«: pĂ«rpiquni tĂ« ruani thjeshtĂ«sinĂ« dhe logjikĂ«n e rregullave, mos u pĂ«rpoqni tĂ« mbushni specifikimin e pods me njĂ« grup tĂ« ndĂ«rlikuar rregullash. ĂshtĂ« shumĂ« e lehtĂ« tĂ« krijosh njĂ« rregull qĂ« nuk do tĂ« pĂ«rputhet me kushtet e klasterit, duke krijuar njĂ« ngarkesĂ« tĂ« tepruar mbi planifikuesin dhe duke zvogĂ«luar pĂ«rgjithĂ«sisht performancĂ«n.
7. Taints & Tolerations
Ka një mënyrë tjetër për të menaxhuar caktuesin. Nëse keni një grumbull të madh me qindra nyje dhe mijëra mikroshërbime, është shumë e vështirë të parandaloni që disa podë të vendosen në disa nyje të caktuara.
Mekanizmi taints ndihmon në këtë. Për shembull, në disa skenarë mund të ndaloni që disa nyje të ekzekutojnë podë të caktuara. Për të aplikuar një taint në një nyje specifike, duhet të përdorni opsionin taint në kubectl. Specifikoni çelësin dhe vlerën, dhe pastaj taint si NoSchedule ose NoExecute:
$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoScheduleNë të njëjtën kohë, vlen të theksohet se mekanizmi taint mbështet tre efekte kryesore: NoSchedule, NoExecute dhe PreferNoSchedule.
NoScheduledo tĂ« thotĂ« se derisa nĂ« specifikimin e podit tĂ« mos ketĂ« njĂ« shĂ«nim pĂ«rkatĂ«stolerations, ai nuk do tĂ« mund tĂ« vendoset nĂ« nyje (nĂ« kĂ«tĂ« rastnode10).PreferNoScheduleâ njĂ« version i thjeshtuarNoSchedule. NĂ« kĂ«tĂ« rast, caktuesi do tĂ« pĂ«rpiqet tĂ« mos shpĂ«rndajĂ« podĂ«t qĂ« nuk kanĂ« njĂ« shĂ«nim pĂ«rkatĂ«stolerationsnĂ« nyje, por kjo nuk Ă«shtĂ« njĂ« kufizim i rreptĂ«. NĂ«se nĂ« grumbull nuk ka burime, atĂ«herĂ« podĂ«t do tĂ« fillojnĂ« tĂ« vendosen nĂ« kĂ«tĂ« nyje.NoExecuteâ ky efekt aktivizon njĂ« evakuim tĂ« menjĂ«hershĂ«m tĂ« podĂ«ve qĂ« nuk kanĂ« njĂ« shĂ«nim pĂ«rkatĂ«s.tolerations.
ĂshtĂ« interesante qĂ« kjo sjellje mund tĂ« anulohet me mekanizmin e tolerancave. Kjo Ă«shtĂ« e dobishme kur ka njĂ« nodĂ« "tĂ« ndaluar" dhe ju nevojitet tĂ« vendosni aty vetĂ«m shĂ«rbimet infrastrukturore. Si ta bĂ«ni kĂ«tĂ«? Lejoni vetĂ«m ato pod-e pĂ«r tĂ« cilat ka tolerancĂ« pĂ«rkatĂ«se.
Ja si do të duket specifikimi i podit:
spec:
tolerations:
- key: "node-role.kubernetes.io/ingress"
operator: "Equal"
value: "true"
effect: "NoSchedule"Kjo nuk do të thotë se në depolimin e ardhshëm pod-i do të bjerë saktësisht në këtë nodë, nuk është mekanizmi i Node Affinity dhe nodeSelector. Por duke kombinuar disa karakteristika, mund të arrini një konfigurim shumë fleksibël të planifikuesit.
8. Konfiguroni prioritetin e zhvillimit të pod-eve
Ajo që keni konfiguroni lidhjen e pod-eve me nodat, nuk do të thotë se të gjitha pod-et duhet të përpunohen me të njëjtin prioritet. Për shembull, mund të dëshironi të zhvilloni disa pod-e përpara të tjerëve.
Kubernetes ofron mënyra të ndryshme për të konfiguruar prioritetin e pod-eve (Pod Priority and Preemption). Konfigurimi përbëhet nga disa pjesë: objekti PriorityClass dhe përshkrimi i fushës priorityClassName në specifikimin e podit. Le të shohim një shembull:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 99999
globalDefault: false
description: "Kjo klasë prioriteti duhet të përdoret vetëm për pod-të shumë të rëndësishëm"Ne krijojmë PriorityClass, i japim emrin, përshkrimin dhe vlerën e tij. Sa më e lartë vlera, aq më i lartë është prioriteti. Vlera mund të jetë çdo numër i plotë 32-bitësh, më i vogël ose i barabartë me 1 000 000 000. Vlerat më të larta rezervohen për pod-të sistemikë kritikë, të cilët, si rregull, nuk mund të zëvendësohen. Zëvendësimi do të ndodhë vetëm nëse pod-i me prioritet të lartë nuk ka vend për t'u implementuar, atëherë një pjesë e pod-eve nga një nodë specifike do të evakuohet. Nëse ky mekanizëm është shumë i ashpër për ju, mund të shtoni opsionin preemptionPolicy: Never, dhe atëherë do të mos ketë zëvendësim, pod-i do të kërkojë për burime të lira kur planifikuesi të gjejë.
Pas kësaj, krijojmë një pod, ku specifikojmë emrin 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
Mund të krijoni sa më shumë klasa prioritare të dëshironi, megjithatë rekomandohet të mos e teproni me këtë (p.sh., të kufizoheni në prioritet të ulët, mesatar dhe të lartë).
Kështu, në rast nevoje, do të keni mundësi të rrisni efektivitetin e shpërndarjes së shërbimeve kritike, si p.sh. nginx-ingress-controller, coredns etj.
9. Optimizoni klasterin ETCD
ETCD mund tĂ« quhet truri i gjithĂ« klasterit. ĂshtĂ« shumĂ« e rĂ«ndĂ«sishme tĂ« mbani funksionalitetin e kĂ«saj baze tĂ« dhĂ«nash nĂ« njĂ« nivel tĂ« lartĂ«, sepse pikĂ«risht nga ajo varet shpejtĂ«sia e operacioneve nĂ« "Kube". NjĂ« zgjidhje standarde dhe e mirĂ« do tĂ« ishte tĂ« mbani klasterin ETCD nĂ« nodat master, nĂ« mĂ«nyrĂ« qĂ« tĂ« keni vonesĂ«n minimale deri te kube-apiserver. NĂ«se nuk Ă«shtĂ« e mundur, poziciononi ETCD sa mĂ« afĂ«r qĂ« tĂ« jetĂ« e mundur, duke pasur njĂ« kapacitet tĂ« mirĂ« kalimi midis pjesĂ«marrĂ«sve. Gjithashtu, kushtojini vĂ«mendje numrit tĂ« nodave tĂ« ETCD qĂ« mund tĂ« dalin jashtĂ« funksionit pa dĂ«m pĂ«r klasterin.
Kini parasysh se rritja e tepërt e numrit të pjesëmarrësve në klaster mund të rrisë qëndrueshmërinë, por me kosto përperformancën, gjithçka duhet të jetë në masë.
Kur flasim për konfigurimin e shërbimit, rekomandimet janë të pakta:
Të keni pajisje të mira, në përputhje me përmasat e klasterit (mund të lexoni) ).
Rregulloni disa parametra nëse keni shpërndarë klasterin në disa DC ose nëse rrjeti dhe diskët tuaj nuk janë në nivelin e duhur (mund të lexoni ).
PĂ«rfundimi
Ky artikull përshkruan piketat që ekipi ynë përpiqet të respektojë. Kjo nuk është një udhëzues hap pas hapi, por mundësi që mund të jenë të dobishme për optimizimin e kostove të klasterit. E kuptojmë se çdo klaster është unik, dhe vendimet për konfigurim mund të ndryshojnë ndjeshëm, prandaj do të ishte interesante të merrnim nga ju një feedback: si e monitoroni klasterin tuaj Kubernetes, me çfarë e përmirësoni funksionimin e tij. Ndani përvojën tuaj në komentet, do të ishte interesante ta dimë.
Burimi: habr.com
