Silav hemû! Navê min Oleg Sidorenkov e, ez li DomClick wekî serokê tîmê binesaziyê dixebitim. Em ji sê salan zêdetir Kubik di hilberînê de bikar tînin, û di vê demê de me bi wê re gelek demên balkêş ên cihêreng jiyan kirin. Iro ez ê ji we re vebêjim ka hûn çawa, bi nêzîkatiya rast, hûn dikarin hê bêtir performansê ji vanilla Kubernetes ji bo koma xwe derxînin. Bi domdarî amade ne!
Hûn hemî baş dizanin ku Kubernetes ji bo orkestrasyona konteyneran pergalek çavkaniyek vekirî ya berbelav e; baş, an 5 binaryên ku bi rêvebirina çerxa jiyanê ya mîkroxizmetên we di hawîrdorek serverê de sêrbaz dixebitin. Wekî din, ew amûrek pir maqûl e ku dikare mîna Lego were berhev kirin ji bo xwerûkirina herî zêde ji bo karên cihêreng.
Û her tişt baş xuya dike: pêşkêşkeran bavêjin nav komê mîna daristanên agirînek, û hûn ê xemgîniyê nizanin. Lê eger hûn alîgirê jîngehê bin, hûn ê bifikirin: “Ez çawa dikarim agir bişewitînim û daristanê biparêzim?” Bi gotinek din, meriv çawa rêyên çêtirkirina binesaziyê û kêmkirina lêçûnên peyda dike.
1. Tîm û çavkaniyên serîlêdanê bişopînin
Yek ji rêgezên herî gelemperî, lê bi bandor danasîna daxwazan / sînoran e. Serlêdan li gorî navan, û cîhên navan ji hêla tîmên pêşkeftinê ve dabeş bikin. Berî bicîhkirinê, nirxên serîlêdanê ji bo xerckirina dema pêvajoyê, bîranîn, û hilanîna efemeral saz bikin.
resources:
requests:
memory: 2Gi
cpu: 250m
limits:
memory: 4Gi
cpu: 500mBi ezmûnê, em gihîştin vê encamê: divê hûn daxwazên ji sînoran ji du caran zêdetir zêde nekin. Hêjmara komê li ser bingeha daxwazan tê hesibandin, û heke hûn serîlêdanan di çavkaniyan de cûdahiyek bidin, mînakî, 5-10 carî, wê hingê bifikirin ka dê çi bi girêka we re bibe gava ku ew bi potan dagirtî ye û ji nişkê ve barek werdigire. Tiştek baş nîne. Bi kêmanî, rijandin, û herî zêde, hûn ê xatirê xwe ji xebatkarê bixwazin û piştî ku pez dest bi tevgerê bikin, li ser girêkên mayî barek dorhêl bistînin.
Ji bilî vê, bi alîkariya limitranges Di destpêkê de, hûn dikarin ji bo konteynerê nirxên çavkaniyê bicîh bikin - herî kêm, herî zêde û xwerû:
➜ ~ 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 2Ji bîr nekin ku çavkaniyên cîhê navan sînordar bikin da ku yek tîm nikaribe hemî çavkaniyên komê bigire:
➜ ~ 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 0Wek ku ji ravekirinê tê dîtin resourcequotas, heke tîmê ops bixwaze podên ku dê 10 cpu-ya din bixwin bicîh bike, plansaz dê destûrê nede û dê xeletiyek bavêje:
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=10Ji bo çareserkirina pirsgirêkek wusa, hûn dikarin amûrek binivîsin, mînakî, mîna , karibe rewşa çavkaniyên fermanê hilîne û pêk bîne.
2. Hilberîna pelê ya çêtirîn hilbijêrin
Li vir ez dixwazim li ser mijara cildên domdar û binpergala dîskê ya girêkên karker ên Kubernetes bisekinim. Ez hêvî dikim ku kes "Cube" li ser HDD-ê di hilberînê de bikar neyîne, lê carinan SSD-ya birêkûpêk êdî têrê nake. Me rastî pirsgirêkek hat ku têketin ji ber operasyonên I/O dîskê dikujin, û gelek çareserî tune:
-
SSD-yên performansa bilind bikar bînin an jî veguherînin NVMe (heke hûn hardware-ya xwe birêve bibin).
-
Asta tomarkirinê kêm bikin.
-
Hevsengkirina "aqilmend" ya kulîlkên ku destavêtina dîskê dikin (
podAntiAffinity).
Dîmendera li jor destnîşan dike ka di binê nginx-ingress-kontroller de çi diqewime dema ku têketinên access_logs çalak e (~ 12 hezar têketin / saniye). Ev rewş, bê guman, dikare bibe sedema hilweşandina hemî serîlêdanên li ser vê nodê.
Ji bo PV, mixabin, min her tişt ceriband Volumes Persistent. Vebijarka çêtirîn ku li gorî we tê bikar bînin. Ji hêla dîrokî ve, li welatê me çêbûye ku beşek piçûk karûbar hewceyê cildên RWX dikin, û demek dirêj berê wan dest bi karanîna hilanîna NFS ji bo vî karî kir. Erzan û... bes. Bê guman, min û wî şîr xwar - pîroz be, lê me fêrî ahenga wê kir, û serê min êdî neêşe. Û heke gengaz be, biçin hilanîna tiştên S3.
3. Wêneyên xweşbînkirî berhev bikin
Çêtir e ku hûn wêneyên konteynerê-optimîzekirî bikar bînin da ku Kubernetes bikaribe wan zûtir bîne û wan bi bandortir bixebite.
Optimized tê vê wateyê ku wêne:
-
tenê yek serîlêdanê heye an tenê fonksiyonek pêk tîne;
-
mezinahiya piçûk, ji ber ku wêneyên mezin li ser torê xirabtir têne şandin;
-
Xalên dawî yên tenduristî û amadebûnê hene ku dihêle Kubernetes di bûyera betalbûnê de tevbigerin;
-
pergalên xebitandinê yên konteyner-heval bikar bînin (mîna Alpine an CoreOS), ku li hember xeletiyên mîhengê bêtir berxwedêr in;
-
avahiyên pir-qonaxa bikar bînin da ku hûn tenê serîlêdanên berhevkirî û ne çavkaniyên pêvekirî bicîh bikin.
Gelek alav û karûbar hene ku destûrê didin we ku hûn wêneyên li ser firînê kontrol bikin û xweşbîn bikin. Girîng e ku meriv wan her gav nûve bike û ji bo ewlehiyê were ceribandin. Di encamê de hûn bistînin:
-
Barkirina torê li ser tevahiya komê kêm kir.
-
Kêmkirina dema destpêkirina konteyneran.
-
Mezinahiya piçûktir a tevahiya qeydiya weya Docker.
4. DNS cache bikar bînin
Ger em li ser barkirinên bilind biaxivin, wê hingê jiyan bêyî ku pergala DNS-ê ya komê biguhezîne pir xirab e. Carekê, pêşdebirên Kubernetes piştgirî da çareseriya kube-dns. Di heman demê de ew li vir hate bicîh kirin, lê ev nermalava bi taybetî nehate guheztin û performansa pêwîst çênekir, her çend ew karekî hêsan xuya bû. Dûv re coredns xuya bûn, ku me veguherand û xemgîniyek tune bû; ew paşê bû karûbarê DNS-ya xwerû di K8s de. Di demekê de, em gihîştin 40 hezar rps ji bo pergala DNS, û ev çareserî jî têrê nake. Lê, bi şens, Nodelocaldns derket, ango node cache herêmî, ango .
Çima em vê bikar tînin? Di kernel Linux-ê de xeletiyek heye ku, dema ku pirjimar bi navgîniya NAT-ê ya UDP-yê ve tê bang kirin, dibe sedema şertek pêşbaziyê ji bo têketinên di tabloyên kontrakê de, û beşek ji seyrûsefera bi NAT-ê winda dibe (her gera Karûbar NAT e). Nodelocaldns vê pirsgirêkê bi derxistina NAT-ê û nûvekirina pêwendiya TCP-ê bi DNS-ya jorîn re, û hem jî bi cachkirina herêmî pirsên DNS-ê yên jorîn (tevî cacheyek neyînî ya kurt a 5-saniye) çareser dike.
5. Scale pods horîzontal û vertîkal bixweber
Ma hûn dikarin bi pêbaweriyê bibêjin ku hemî mîkroxizmetên we ji bo du-sê qatan zêdekirina barkirinê amade ne? Meriv çawa bi rêkûpêk çavkaniyan ji serîlêdanên xwe re veqetîne? Dibe ku girtina çend potan ji ber bargiraniya xebatê zêde zêde be, lê girtina wan li dû hev metirsiya daketinê ji zêdebûna nişkave ya seyrûsefera karûbarê dimeşîne. Xizmetên wekî и .
VPA destûrê dide te ku hûn bixweber daxwaz / sînorên konteynerên xwe yên di podê de li gorî karanîna rastîn zêde bikin. Çawa dikare kêrhatî be? Ger hûn pod hene ku ji ber hin sedeman nekarin bi rengek horizontî werin pîvandin (ya ku bi tevahî ne pêbawer e), wê hingê hûn dikarin biceribînin ku guheztinên çavkaniyên wê bi VPA-yê re spartin. Taybetmendiya wê pergalek pêşniyarê ye ku li ser bingeha daneyên dîrokî û heyî yên ji servera metrîkê ye, ji ber vê yekê heke hûn nexwazin bixweber daxwaz / sînor biguhezin, hûn dikarin tenê çavkaniyên pêşniyarkirî yên ji bo konteynerên xwe bişopînin û mîhengan xweş bikin da ku CPU û CPU hilînin û hilînin. bîra di komê de.
Wêne ji https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 hatiye girtin
Plansazker li Kubernetes her gav li ser bingeha daxwazan e. Çi nirxa ku hûn li wir danîne jî, plansaz dê li ser bingeha wê li nodek maqûl bigere. Nirxên sînoran hewce ne ku kubelet fêm bike ka kengê difûre an bikuje. Û ji ber ku yekane pîvana girîng nirxa daxwazan e, VPA dê pê re bixebite. Kengê ku hûn serîlêdanek vertîkal mezin dikin, hûn diyar dikin ka daxwaz divê çi bin. Wê demê dê çi bibe ser sînoran? Ev parametre jî dê bi rêjeyî were pîvandin.
Mînakî, li vir mîhengên podê yên gelemperî hene:
resources:
requests:
memory: 250Mi
cpu: 200m
limits:
memory: 500Mi
cpu: 350mMotora pêşniyarê destnîşan dike ku serîlêdana we 300m CPU û 500Mi hewce dike ku bi rêkûpêk bixebite. Hûn ê mîhengên jêrîn bistînin:
resources:
requests:
memory: 500Mi
cpu: 300m
limits:
memory: 1000Mi
cpu: 525mWekî ku li jor hatî behs kirin, ev pîvana rêjeyî ye ku li gorî rêjeya daxwaz / sînoran di diyardeyê de ye:
-
CPU: 200m → 300m: rêjeya 1:1.75;
-
Bîr: 250Mi → 500Mi: Rêjeya 1:2.
Li gorî HPA, wê demê mekanîzmaya operasyonê zelaltir e. Metrîkên wekî CPU û bîranîn têne sînorkirin, û heke navînî ya hemî kopyayan ji bend derbas bibe, serîlêdan bi +1 sub tê pîvandin heya ku nirx dakeve binê bendê an jî heya ku hejmara herî zêde ya kopiyan bigihîje.
Wêne ji https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 hatiye girtin
Ji bilî metrîkên asayî yên mîna CPU û bîranîn, hûn dikarin li ser metrîkên xweya xwerû ji Prometheus bend danîn û bi wan re bixebitin ger hûn difikirin ku ew nîşana herî rast e ku kengê hûn serlêdana xwe pîvandin. Dema ku serîlêdan li binê sînorê metrîkê yê diyarkirî stabîl bibe, HPA dê dest bi pîvandina podan bike heya hejmara herî kêm a kopiyan an jî heya ku bar digihîje sînorê diyarkirî.
6. Têkiliya Node û Pod Affinity ji bîr nekin
Ne hemî nod li ser heman hardware dimeşin, û ne hewce ne ku hemî pods serîlêdanên bihejmar-dijwar bimeşînin. Kubernetes destûrê dide te ku hûn pisporiya girêk û podan bikar bînin Têkiliya Node и Pod Affinity.
Ger girêkên we hene ku ji bo operasyonên bihejmar-dijwar guncan in, wê hingê ji bo karîgeriya herî zêde çêtir e ku hûn serîlêdanan bi girêkên têkildar ve girêdin. Ji bo vê yekê bikar bînin nodeSelector bi labelê node.
Em bibêjin du girêkên we hene: yek bi CPUType=HIGHFREQ û hejmareke mezin ji core bi lez, yekî din bi MemoryType=HIGHMEMORY bîra zêdetir û performansa zûtir. Rêya herî hêsan ev e ku meriv veqetandinê li girêkek veqetîne HIGHFREQbi lêzêdekirina beşê spec ev hilbijêr:
…
nodeSelector:
CPUType: HIGHFREQRêbazek bihatir û taybetî ya kirina vê yekê karanîna e nodeAffinity li zeviyê affinity razdela spec. Du vebijark hene:
-
requiredDuringSchedulingIgnoredDuringExecution: mîhengê dijwar (sazker dê podan tenê li ser girêkên taybetî (û li cîhek din) bicîh bike); -
preferredDuringSchedulingIgnoredDuringExecution: mîhengê nerm (sazker dê hewl bide ku li girêkên taybetî bi cîh bike, û heke ew têk neçe, ew ê hewl bide ku li girêka din a berdest bicîh bike).
Hûn dikarin hevoksaziyek taybetî ji bo birêvebirina etîketên girêk diyar bikin, wek mînak In, NotIn, Exists, DoesNotExist, Gt an Lt. Lêbelê, ji bîr mekin ku rêbazên tevlihev ên di navnîşên dirêj ên nîşanan de dê biryargirtinê di rewşên krîtîk de hêdî bikin. Bi gotineke din, sade bimîne.
Wekî ku li jor behs kir, Kubernetes destûrê dide we ku hûn pêwendiya pêlên heyî saz bikin. Ango, hûn dikarin pê ewle bin ku hin pod bi podên din re di heman devera hebûna (ji bo ewran re têkildar) an girêkan bi hev re dixebitin.
В podAffinity zevî affinity razdela spec heman qadên ku di rewşê de hene hene nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Cudahiya tenê ew e matchExpressions dê podan bi girêkek ku jixwe bi wê etîketê ve podek dimeşîne ve girêde.
Kubernetes jî zeviyek pêşkêşî dike podAntiAffinity, ku, berevajî vê, podê bi girêkek bi potanên taybetî ve girê nade.
Derbarê îfadeyan nodeAffinity Heman şîret dikare were dayîn: hewl bidin ku qaîdeyan sade û mentiqî bihêlin, hewl nekin ku taybetmendiya pod bi komek rêzikên tevlihev re bar bikin. Pir hêsan e ku meriv qaîdeyek biafirîne ku dê bi şert û mercên komê re nebe hev, barek nehewce li ser plansazker biafirîne û performansa giştî kêm bike.
7. Taints & Tolerances
Rêyek din heye ku meriv plansazker birêve bibe. Ger we komek mezin a bi sedan girêk û bi hezaran mîkroservîs hene, wê hingê pir dijwar e ku hûn nehêlin ku hin pod li ser hin girêkan werin mêvan kirin.
Mekanîzmaya tansiyonên - qaîdeyên qedexekirinê - bi vê re dibe alîkar. Mînakî, di hin senaryoyan de hûn dikarin hin girêkan ji xebitandina podan qedexe bikin. Ji bo sepandina taint li ser nodek taybetî hûn hewce ne ku vebijarkê bikar bînin taint li kubectl. Kilît û nirxê diyar bikin û dûv re mîna reng bikin NoSchedule an NoExecute:
$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoScheduleDi heman demê de hêjayî gotinê ye ku mekanîzmaya tîrêjê sê bandorên sereke piştgirî dike: NoSchedule, NoExecute и PreferNoSchedule.
-
NoScheduletê vê wateyê ku heya niha dê di navnîşa pod de têketinek têkildar tune betolerations, ew ê nikaribe li ser nodê were bicîh kirin (di vê nimûneyê denode10). -
PreferNoSchedule- guhertoya hêsankirîNoSchedule. Di vê rewşê de, plansaz dê hewl bide ku podên ku têketinek lihevhatî tune ne veqetînetolerationsper node, lê ev ne sînorek dijwar e. Ger di komê de çavkanî tunebin, wê hingê dê pods dest bi danîna li ser vê girêkê bikin. -
NoExecute- ev bandor dibe sedema valakirina tavilê ya polên ku têketinek têkildar tune netolerations.
Balkêş e, ev tevger dikare bi karanîna mekanîzmaya tolerasyonê were betal kirin. Dema ku girêkek "qedexe" hebe ev hêsan e û hûn tenê hewce ne ku karûbarên binesaziyê li ser wê bicîh bikin. Çawa bike? Destûr bidin tenê wan zozanên ku ji bo wan toleransek maqûl heye.
Li vir taybetmendiya pod dê çawa xuya bike:
spec:
tolerations:
- key: "node-role.kubernetes.io/ingress"
operator: "Equal"
value: "true"
effect: "NoSchedule"Ev nayê vê wateyê ku ji nû ve veguheztina paşîn dê têkeve ser vê girêka taybetî, ev ne mekanîzmaya Têkiliya Node ye û nodeSelector. Lê bi berhevkirina çend taybetmendiyan, hûn dikarin mîhengên plansazkerê pir maqûl bi dest bixin.
8. Pêşîniya Dabeşkirina Pod Set
Tenê ji ber ku we podên ku ji girêkan re hatine veqetandin nayê vê wateyê ku divê hemî pod bi heman pêşîniyê bêne derman kirin. Mînakî, dibe ku hûn bixwazin ku hin pods berî yên din bicîh bikin.
Kubernetes awayên cihêreng pêşkêşî dike ji bo mîhengkirina Pod Priority û Preemption. Mîheng ji çend beşan pêk tê: obje PriorityClass û danasînên zeviyê priorityClassName di taybetmendiya pod de. Ka em li mînakekê binêrin:
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"Em diafirînin PriorityClass, nav, danasîn û qîmetê bide wê. Ya bilindtir value, pêşanî bilindtir e. Nirx dikare ji 32 jimarek 1-bit kêmtir an wekhev be. Nirxên bilindtir ji bo pelên pergalê-krîtîk ên ku bi gelemperî nekarin pêşî lê bigirin têne veqetandin. Dê jicîhûwarî tenê çêbibe ger ku podek pêşanî ya bilind cîhek tune ku li dora xwe bizivire, wê hingê hin kulpên ji girêkek diyarkirî dê bêne vala kirin. Ger ev mekanîzma ji bo we pir hişk e, hûn dikarin vebijarkê lê zêde bikin preemptionPolicy: Never, û wê hingê dê pêşîgirtin tune be, pod dê pêşî di rêzê de bisekine û li benda plansazker bimîne ku jê re çavkaniyên belaş bibîne.
Dûv re, em pêçekek çêdikin ku tê de em nav destnîşan dikin 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
Hûn dikarin bi qasî ku hûn dixwazin dersên pêşîn biafirînin, her çend tê pêşniyar kirin ku hûn bi vê yekê neçin (bibêjin, xwe bi pêşengiya kêm, navîn û bilind sînordar bikin).
Bi vî rengî, ger hewce be, hûn dikarin karbidestiya bicîhkirina karûbarên krîtîk ên wekî nginx-ingress-kontroller, coredns, hwd zêde bikin.
9. Klustera ETCDê xweşbîn bikin
ETCD dikare mêjiyê tevahiya komê tê gotin. Pir girîng e ku xebata vê databasê di astek bilind de were domandin, ji ber ku leza operasyonên li Cube bi wê ve girêdayî ye. Çareserek pir standard, û di heman demê de, çareseriyek baş dê ev be ku komika ETCD li ser girêkên sereke bihêle da ku ji kube-apiserver re derengiyek herî kêm hebe. Ger hûn nikaribin vê yekê bikin, wê hingê ETCD-ê bi qasî ku pêkan nêzîk, bi bandwîdeyek baş di navbera beşdaran de cîh bikin. Di heman demê de bala xwe bidin ka çend girêkên ETCD dikarin bêyî zirarê bidin komê derkevin
Bînin bîra xwe ku zêde zêdekirina hejmara endamên di komekê de dikare li ser hesabê performansê tolerasyona xeletiyê zêde bike, divê her tişt bi nermî be.
Ger em li ser sazkirina karûbarê biaxivin, çend pêşniyar hene:
-
Li ser bingeha mezinahiya komê, hardware baş hebe (hûn dikarin bixwînin ).
-
Ger we komik di navbera cotek DC-yan an tora xwe û dîskên xwe de belav kiribe, çend pîvanan biguhezînin (hûn dikarin bixwînin ).
encamê
Ev gotar xalên ku tîmê me hewl dide ku pê re bişopîne vedibêje. Ev ne ravekirinek gav-bi-gav a çalakiyan e, lê vebijarkên ku dibe ku ji bo xweşbînkirina serê komê bikêr bin. Eşkere ye ku her kom bi awayê xwe yekta ye, û çareseriyên mîhengê dikarin pir cûda bibin, ji ber vê yekê dê balkêş be ku hûn nerînên xwe bistînin ka hûn çawa koma Kubernetes-a xwe çavdêrî dikin û hûn çawa performansa wê baştir dikin. Tecrûbeya xwe di şîroveyan de parve bikin, ew ê balkêş be ku hûn zanibin.
Source: www.habr.com