ProHoster > Blogs > Administrācija > Deviņi Kubernetes snieguma padomi

Deviņi Kubernetes snieguma padomi

Deviņi Kubernetes snieguma padomi

Sveiki visiem! Mani sauc Oļegs Sidorenkovs, strādāju DomClick par infrastruktÅ«ras komandas vadÄ«tāju. Kubik ražoÅ”anā izmantojam vairāk nekā trÄ«s gadus, un Å”ajā laikā ar to esam piedzÄ«vojuÅ”i daudz dažādu interesantu mirkļu. Å odien es jums pastāstÄ«Å”u, kā, izmantojot pareizo pieeju, jÅ«s varat izspiest vēl vairāk veiktspējas no vaniļas Kubernetes savam klasterim. Uzmanibu gatavibu starts!

JÅ«s visi ļoti labi zināt, ka Kubernetes ir mērogojama atvērtā pirmkoda sistēma konteineru orÄ·estrÄ“Å”anai; labi, vai 5 binārie faili, kas darbojas maÄ£iski, pārvaldot jÅ«su mikropakalpojumu dzÄ«ves ciklu servera vidē. Turklāt tas ir diezgan elastÄ«gs rÄ«ks, ko var salikt kā Lego, lai maksimāli pielāgotu dažādiem uzdevumiem.

Un Ŕķiet, ka viss ir kārtÄ«bā: iemet serverus klasterÄ« kā malku kurtuvē, un tu nezināsi nekādas bēdas. Bet, ja esat par vidi, jÅ«s domājat: "Kā es varu noturēt uguni un saudzēt mežu?" Citiem vārdiem sakot, kā atrast veidus, kā uzlabot infrastruktÅ«ru un samazināt izmaksas.

1. Pārraugiet komandas un lietojumprogrammu resursus

Deviņi Kubernetes snieguma padomi

Viena no visizplatÄ«tākajām, bet efektÄ«vākajām metodēm ir pieprasÄ«jumu/limitu ievieÅ”ana. Sadaliet lietojumprogrammas pēc nosaukumvietām un nosaukumvietas pēc izstrādes komandām. Pirms izvietoÅ”anas iestatiet lietojumprogrammas vērtÄ«bas procesora laika, atmiņas un Ä«slaicÄ«gas krātuves patēriņam.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

Izmantojot pieredzi, mēs nonācām pie secinājuma: jums nevajadzētu palielināt pieprasÄ«jumus no limitiem vairāk nekā divas reizes. Klastera apjoms tiek aprēķināts, pamatojoties uz pieprasÄ«jumiem, un, ja lietojumprogrammām pieŔķirat resursu atŔķirÄ«bu, piemēram, 5-10 reizes, tad iedomājieties, kas notiks ar jÅ«su mezglu, kad tas bÅ«s piepildÄ«ts ar pākstÄ«m un pēkŔņi saņems slodzi. Nekas labs. Vismaz, droseles un maksimums, jÅ«s atvadÄ«sities no darbinieka un saņemsiet ciklisku slodzi uz atlikuÅ”ajiem mezgliem pēc tam, kad podi sāks kustēties.

Turklāt ar palīdzību limitranges Sākumā varat iestatīt konteinera resursu vērtības - minimālo, maksimālo un noklusējuma vērtību:

āžœ  ~ 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

Neaizmirstiet ierobežot nosaukumvietas resursus, lai viena komanda nevarētu pārņemt visus klastera resursus:

āžœ  ~ 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

Kā redzams no apraksta resourcequotas, ja operācijas komanda vēlas izvietot apvidus, kas patērēs vēl 10 CPU, plānotājs to neatļaus un parādīs kļūdu:

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

Lai atrisinātu Ŕādu problēmu, varat uzrakstÄ«t rÄ«ku, piemēram, patÄ«k Å”is, kas spēj uzglabāt un izmantot komandu stāvokļa resursus.

2. Izvēlieties optimālo failu krātuvi

Deviņi Kubernetes snieguma padomi

Å eit es gribētu pieskarties tēmai par noturÄ«giem sējumiem un Kubernetes darbinieku mezglu diska apakÅ”sistēmai. Ceru, ka ražoÅ”anā cietajā diskā esoÅ”o ā€œCubeā€ neviens neizmanto, bet reizēm ar parasto SSD vairs nepietiek. Mēs saskārāmies ar problēmu, kad žurnāli iznÄ«cināja disku I/O darbÄ«bu dēļ, un nav daudz risinājumu:

  • Izmantojiet augstas veiktspējas SSD vai pārslēdzieties uz NVMe (ja pārvaldāt savu aparatÅ«ru).

  • Samaziniet reÄ£istrÄ“Å”anas lÄ«meni.

  • Veiciet ā€œgudruā€ to pākstÄ«m, kas izvaro disku, balansÄ“Å”anu (podAntiAffinity).

IepriekÅ” redzamajā ekrānā ir parādÄ«ts, kas notiek diskā zem nginx-ingress-controller, kad ir iespējota access_logs reÄ£istrÄ“Å”ana (~12 tÅ«kstoÅ”i žurnālu/s). Å is nosacÄ«jums, protams, var izraisÄ«t visu Ŕī mezgla lietojumprogrammu degradāciju.

Kas attiecas uz PV, ak, neesmu visu izmēģinājis sugas PastāvÄ«gi sējumi. Izmantojiet sev piemērotāko iespēju. Vēsturiski mÅ«su valstÄ« ir gadÄ«jies, ka nelielai daļai servisu ir nepiecieÅ”ami RWX apjomi, un jau sen viņi Å”im uzdevumam sāka izmantot NFS krātuvi. Lēti un... pietiekami. Protams, viņŔ un es ēdām sÅ«dus - svētÄ« jÅ«s, bet mēs iemācÄ«jāmies to noregulēt, un mana galva vairs nesāp. Un, ja iespējams, pārejiet uz S3 objektu krātuvi.

3. Apkopojiet optimizētus attēlus

Deviņi Kubernetes snieguma padomi

Vislabāk ir izmantot konteineram optimizētus attēlus, lai Kubernetes varētu tos ātrāk ienest un izpildÄ«t efektÄ«vāk. 

Optimizēts nozīmē, ka attēli:

  • satur tikai vienu lietojumprogrammu vai veic tikai vienu funkciju;

  • mazs izmērs, jo lielie attēli tÄ«klā tiek pārraidÄ«ti sliktāk;

  • ir veselÄ«bas un gatavÄ«bas parametri, kas ļauj Kubernetes rÄ«koties dÄ«kstāves gadÄ«jumā;

  • izmantojiet konteineriem draudzÄ«gas operētājsistēmas (piemēram, Alpine vai CoreOS), kas ir izturÄ«gākas pret konfigurācijas kļūdām;

  • izmantojiet vairākpakāpju bÅ«vējumus, lai varētu izvietot tikai apkopotas lietojumprogrammas, nevis pievienotos avotus.

Ir daudz rÄ«ku un pakalpojumu, kas ļauj pārbaudÄ«t un optimizēt attēlus lidojuma laikā. Ir svarÄ«gi tos vienmēr atjaunināt un pārbaudÄ«t, lai nodroÅ”inātu droŔību. Rezultātā jÅ«s iegÅ«stat:

  1. Samazināta tīkla slodze visā klasterī.

  2. Samazina konteinera palaiŔanas laiku.

  3. Mazāks visa Docker reģistra izmērs.

4. Izmantojiet DNS keÅ”atmiņu

Deviņi Kubernetes snieguma padomi

Ja mēs runājam par lielām slodzēm, tad bez klastera DNS sistēmas noregulÄ“Å”anas dzÄ«ve ir diezgan draņķīga. Savulaik Kubernetes izstrādātāji atbalstÄ«ja savu kube-dns risinājumu. Tas tika ieviests arÄ« Å”eit, taču Ŕī programmatÅ«ra nebija Ä«paÅ”i noregulēta un neradÄ«ja nepiecieÅ”amo veiktspēju, lai gan Ŕķita, ka tas ir vienkārÅ”s uzdevums. Tad parādÄ«jās coredns, uz kuru mēs pārgājām, un mums nebija bēdu; vēlāk tas kļuva par noklusējuma DNS pakalpojumu K8s. Kādā brÄ«dÄ« DNS sistēmai izaugām lÄ«dz 40 tÅ«kstoÅ”iem rps, un arÄ« Å”is risinājums kļuva nepietiekams. Bet, par laimi, iznāca Nodelocaldns, aka node local cache, aka NodeLocal DNSCache.

Kāpēc mēs to izmantojam? Linux kodolā ir kļūda, kas, ja vairāki izsaukumi, izmantojot conntrack NAT, izmantojot UDP, rada sacensÄ«bu nosacÄ«jumu ierakstiem conntrack tabulās, un tiek zaudēta daļa trafika caur NAT (katrs brauciens caur pakalpojumu ir NAT). Nodelocaldns atrisina Å”o problēmu, atbrÄ«vojoties no NAT un jauninot savienojumu ar TCP uz augÅ”upstraumes DNS, kā arÄ« lokāli saglabājot keÅ”atmiņu augÅ”upējās DNS vaicājumos (tostarp Ä«su 5 sekunžu negatÄ«vo keÅ”atmiņu).

5. Automātiski mērogojiet pākstis horizontāli un vertikāli

Deviņi Kubernetes snieguma padomi

Vai varat ar pārliecÄ«bu teikt, ka visi jÅ«su mikropakalpojumi ir gatavi slodzes palielināŔanai divas lÄ«dz trÄ«s reizes? Kā pareizi pieŔķirt resursus savām lietojumprogrammām? Dažu bloku uzturÄ“Å”ana, kas pārsniedz darba slodzi, var bÅ«t lieki, taču, turot tos kopā, pastāv dÄ«kstāves risks, ko izraisa pēkŔņa pakalpojuma trafika palielināŔanās. Tādi pakalpojumi kā Horizontal Pod Autoscaler Šø Vertikālais pods Autoscaler.

BPN ļauj automātiski palielināt pieprasÄ«jumus/ierobežojumus jÅ«su podā esoÅ”ajiem konteineriem atkarÄ«bā no faktiskā lietojuma. Kā tas var bÅ«t noderÄ«gs? Ja jums ir podi, kurus kāda iemesla dēļ nevar mērogot horizontāli (kas nav pilnÄ«gi uzticams), varat mēģināt uzticēt tā resursu izmaiņas VPA. Tā funkcija ir ieteikumu sistēma, kuras pamatā ir vēsturiskie un paÅ”reizējie dati no metrikas servera, tādēļ, ja nevēlaties automātiski mainÄ«t pieprasÄ«jumus/ierobežojumus, varat vienkārÅ”i pārraudzÄ«t ieteicamos resursus saviem konteineriem un optimizēt iestatÄ«jumus, lai ietaupÄ«tu CPU un atmiņa klasterÄ«.

Deviņi Kubernetes snieguma padomiAttēls ņemts no https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Kubernetes plānotājs vienmēr ir balstÄ«ts uz pieprasÄ«jumiem. NeatkarÄ«gi no tā, kādu vērtÄ«bu jÅ«s tur ievietojat, plānotājs meklēs piemērotu mezglu, pamatojoties uz to. RobežvērtÄ«bas ir nepiecieÅ”amas, lai kubelets saprastu, kad gāzēt vai nogalināt pāksti. Un tā kā vienÄ«gais svarÄ«gais parametrs ir pieprasÄ«jumu vērtÄ«ba, VPA darbosies ar to. Ikreiz, kad mērogojat lietojumprogrammu vertikāli, jÅ«s definējat, kādiem pieprasÄ«jumiem jābÅ«t. Kas tad notiks ar robežām? ArÄ« Å”is parametrs tiks proporcionāli mērogots.

Piemēram, Å”eit ir parastie pod iestatÄ«jumi:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

Ieteikumu programma nosaka, ka jÅ«su lietojumprogrammai ir nepiecieÅ”ams 300 m CPU un 500 Mi, lai tā darbotos pareizi. JÅ«s saņemsiet Ŕādus iestatÄ«jumus:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

Kā minēts iepriekÅ”, Ŕī ir proporcionāla mērogoÅ”ana, pamatojoties uz pieprasÄ«jumu/ierobežojumu attiecÄ«bu manifestā:

  • Centrālais procesors: 200 m ā†’ 300 m: attiecÄ«ba 1:1.75;

  • Atmiņa: 250Mi ā†’ 500Mi: attiecÄ«ba 1:2.

AttiecÄ«bā HPA, tad darbÄ«bas mehānisms ir pārskatāmāks. Metrika, piemēram, centrālais procesors un atmiņa, tiek ierobežota, un, ja visu reprodukciju vidējais rādÄ«tājs pārsniedz slieksni, lietojumprogramma tiek mērogota par +1 apakÅ”punktu, lÄ«dz vērtÄ«ba nokrÄ«tas zem sliekŔņa vai tiek sasniegts maksimālais reprodukciju skaits.

Deviņi Kubernetes snieguma padomiAttēls ņemts no https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Papildus parastajiem rādÄ«tājiem, piemēram, centrālajam procesoram un atmiņai, varat iestatÄ«t sliekŔņus saviem Prometheus pielāgotajiem rādÄ«tājiem un strādāt ar tiem, ja uzskatāt, ka tā ir visprecÄ«zākā norāde par to, kad mērogot lietojumprogrammu. Kad lietojumprogramma stabilizējas zem noteiktā metrikas sliekŔņa, HPA sāks samazināt aplikumu skaitu lÄ«dz minimālajam kopiju skaitam vai lÄ«dz slodze sasniegs norādÄ«to slieksni.

6. Neaizmirstiet par Node Affinity un Pod Affinity

Deviņi Kubernetes snieguma padomi

Ne visi mezgli darbojas ar vienu un to paÅ”u aparatÅ«ru, un ne visiem podiem ir jāpalaiž skaitļoÅ”anas ietilpÄ«gas lietojumprogrammas. Kubernetes ļauj iestatÄ«t mezglu un podiņu specializāciju, izmantojot Mezgla afinitāte Šø Pod Afinity.

Ja jums ir mezgli, kas ir piemēroti skaitļoÅ”anas ietilpÄ«gām darbÄ«bām, tad, lai nodroÅ”inātu maksimālu efektivitāti, labāk ir piesaistÄ«t lietojumprogrammas attiecÄ«gajiem mezgliem. Lai to izdarÄ«tu, izmantojiet nodeSelector ar mezgla etiÄ·eti.

Pieņemsim, ka jums ir divi mezgli: viens ar CPUType=HIGHFREQ un liels skaits ātro kodolu, cits ar MemoryType=HIGHMEMORY vairāk atmiņas un ātrāka veiktspēja. VienkārŔākais veids ir izvietoÅ”anu pieŔķirt mezglam HIGHFREQpievienojot sadaļai spec Å”is atlasÄ«tājs:

ā€¦
nodeSelector:
	CPUType: HIGHFREQ

Dārgāks un specifiskāks veids, kā to izdarīt, ir izmantot nodeAffinity laukā affinity razdela spec. Ir divas iespējas:

  • requiredDuringSchedulingIgnoredDuringExecution: cietais iestatÄ«jums (plānotājs izvietos aplikumus tikai noteiktos mezglos (un nekur citur));

  • preferredDuringSchedulingIgnoredDuringExecution: mÄ«kstais iestatÄ«jums (plānotājs mēģinās izvietot konkrētus mezglus, un, ja tas neizdodas, tas mēģinās izvietot nākamo pieejamo mezglu).

Varat norādÄ«t konkrētu sintaksi mezglu etiÄ·eÅ”u pārvaldÄ«bai, piemēram, In, NotIn, Exists, DoesNotExist, Gt vai Lt. Tomēr atcerieties, ka sarežģītas metodes garos etiÄ·eÅ”u sarakstos palēninās lēmumu pieņemÅ”anu kritiskās situācijās. Citiem vārdiem sakot, rÄ«kojieties vienkārÅ”i.

Kā minēts iepriekÅ”, Kubernetes ļauj iestatÄ«t paÅ”reizējo pākstu afinitāti. Tas nozÄ«mē, ka varat pārliecināties, ka noteikti podi darbojas kopā ar citiem podiem tajā paŔā pieejamÄ«bas zonā (attiecas uz mākoņiem) vai mezgliem.

Š’ podAffinity robežas affinity razdela spec ir pieejami tie paÅ”i lauki kā gadÄ«jumā nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution Šø preferredDuringSchedulingIgnoredDuringExecution. VienÄ«gā atŔķirÄ«ba ir tā matchExpressions saistÄ«s aplikumus ar mezglu, kurā jau darbojas pods ar Å”o etiÄ·eti.

Kubernetes piedāvā arī lauku podAntiAffinity, kas, gluži pretēji, nesaista pāksti ar mezglu ar specifiskiem pākstiem.

Par izteicieniem nodeAffinity Var dot to paÅ”u padomu: mēģiniet saglabāt noteikumus vienkārÅ”us un loÄ£iskus, nemēģiniet pārslogot pod specifikāciju ar sarežģītu noteikumu kopumu. Ir ļoti vienkārÅ”i izveidot noteikumu, kas neatbilst klastera nosacÄ«jumiem, radot nevajadzÄ«gu slodzi plānotājam un samazinot kopējo veiktspēju.

7. Bojājumi un pielaides

Ir vēl viens veids, kā pārvaldÄ«t plānotāju. Ja jums ir liels klasteris ar simtiem mezglu un tÅ«kstoÅ”iem mikropakalpojumu, ir ļoti grÅ«ti neļaut noteiktos mezglos mitināt noteiktus pākstis.

SasmērÄ“Å”anās mehānisms ā€” aizliedzoÅ”ie noteikumi ā€” palÄ«dz Å”ajā jautājumā. Piemēram, noteiktos scenārijos varat aizliegt noteiktiem mezgliem palaist podziņus. Lai piemērotu piesārņojumu konkrētam mezglam, ir jāizmanto opcija taint in kubectl. Norādiet atslēgu un vērtÄ«bu un pēc tam sabojājiet NoSchedule vai NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

Ir arÄ« vērts atzÄ«mēt, ka bojājuma mehānisms atbalsta trÄ«s galvenos efektus: NoSchedule, NoExecute Šø PreferNoSchedule.

  • NoSchedule nozÄ«mē, ka pagaidām pod specifikācijā atbilstoÅ”a ieraksta nebÅ«s tolerations, to nevarēs izvietot mezglā (Å”ajā piemērā node10).

  • PreferNoSchedule - vienkārÅ”ota versija NoSchedule. Å ajā gadÄ«jumā plānotājs mēģinās nepieŔķirt aplikumus, kuriem nav atbilstoÅ”a ieraksta tolerations katram mezglam, taču tas nav stingrs ierobežojums. Ja klasterÄ« nav resursu, Å”ajā mezglā tiks izvietoti podi.

  • NoExecute - Å”is efekts izraisa tÅ«lÄ«tēju to pākstÄ«m, kurām nav atbilstoÅ”a ieraksta, evakuāciju tolerations.

Interesanti, ka Å”o uzvedÄ«bu var atcelt, izmantojot pielaides mehānismu. Tas ir ērti, ja ir ā€œaizliegtsā€ mezgls un tajā ir jāizvieto tikai infrastruktÅ«ras pakalpojumi. Kā to izdarÄ«t? Atļaut tikai tās pākstis, kurām ir piemērota pielaide.

Lūk, kā izskatītos pod specifikācija:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

Tas nenozÄ«mē, ka nākamā pārizvietoÅ”ana notiks Å”ajā konkrētajā mezglā, tas nav mezgla afinitātes mehānisms un nodeSelector. Bet, apvienojot vairākas funkcijas, varat sasniegt ļoti elastÄ«gus plānotāja iestatÄ«jumus.

8. Iestatiet Pod izvietoŔanas prioritāti

Tas, ka jums ir mezgliem pieŔķirti podi, nenozÄ«mē, ka visi podi ir jāapstrādā ar vienādu prioritāti. Piemēram, iespējams, vēlēsities izvietot dažus aplikumus pirms citiem.

Kubernetes piedāvā dažādus veidus, kā konfigurēt Pod Priority un Preemption. Iestatījums sastāv no vairākām daļām: objekts PriorityClass un lauku apraksti priorityClassName pod specifikācijā. Apskatīsim piemēru:

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"

Mēs radām PriorityClass, pieŔķiriet tai nosaukumu, aprakstu un vērtÄ«bu. Jo augstāks value, jo augstāka prioritāte. VērtÄ«ba var bÅ«t jebkurÅ” 32 bitu vesels skaitlis, kas ir mazāks vai vienāds ar 1 000 000 000. Augstākas vērtÄ«bas ir rezervētas uzdevumiem kritiskām sistēmas aplikācijām, kuras parasti nevar novērst. PārvietoÅ”anās notiks tikai tad, ja augstas prioritātes podam nav kur apgriezties, tad daļa no noteikta mezgla pākstÄ«m tiks evakuēta. Ja Å”is mehānisms jums ir pārāk stingrs, varat pievienot opciju preemptionPolicy: Never, un tad nebÅ«s priekÅ”rocÄ«bu, pods stāvēs pirmais rindā un gaidÄ«s, kamēr plānotājs atradÄ«s tam brÄ«vus resursus.

Tālāk mēs izveidojam podiņu, kurā norādām nosaukumu 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

Jūs varat izveidot tik daudz prioritāro nodarbību, cik vēlaties, lai gan ieteicams ar to neaizrauties (teiksim, ierobežot sevi ar zemu, vidēju un augstu prioritāti).

Tādējādi, ja nepiecieÅ”ams, varat palielināt kritisko pakalpojumu, piemēram, nginx-ingress-controller, coredns utt., izvietoÅ”anas efektivitāti.

9. Optimizējiet ETCD kopu

Deviņi Kubernetes snieguma padomi

ETCD var saukt par visa klastera smadzenēm. Ir ļoti svarÄ«gi uzturēt Ŕīs datu bāzes darbÄ«bu augstā lÄ«menÄ«, jo no tā ir atkarÄ«gs operāciju ātrums Cube. Diezgan standarta un tajā paŔā laikā labs risinājums bÅ«tu saglabāt ETCD klasteru galvenajos mezglos, lai kube-apiserveram bÅ«tu minimāla aizkave. Ja nevarat to izdarÄ«t, novietojiet ETCD pēc iespējas tuvāk, nodroÅ”inot labu joslas platumu starp dalÄ«bniekiem. Pievērsiet uzmanÄ«bu arÄ« tam, cik mezglu no ETCD var izkrist, nekaitējot klasterim

Deviņi Kubernetes snieguma padomi

Paturiet prātā, ka pārmērÄ«ga klastera dalÄ«bnieku skaita palielināŔana var palielināt kļūdu toleranci uz veiktspējas rēķina, visam jābÅ«t mērenam.

Ja mēs runājam par pakalpojuma iestatÄ«Å”anu, ir daži ieteikumi:

  1. Ir laba aparatūra, pamatojoties uz klastera lielumu (varat lasīt Ŕeit).

  2. Pielāgojiet dažus parametrus, ja esat izplatÄ«jis kopu starp DC pāriem vai tÄ«klu un diski atstāj daudz vēlamo (varat lasÄ«t Å”eit).

Secinājums

Å ajā rakstā ir aprakstÄ«ti punkti, kurus mÅ«su komanda cenÅ”as ievērot. Å is nav detalizēts darbÄ«bu apraksts, bet gan opcijas, kas var bÅ«t noderÄ«gas klastera pieskaitāmās izmaksas. Ir skaidrs, ka katrs klasteris ir unikāls savā veidā, un konfigurācijas risinājumi var ievērojami atŔķirties, tāpēc bÅ«tu interesanti uzzināt jÅ«su atsauksmes par to, kā uzraugāt savu Kubernetes klasteru un kā uzlabojat tā veiktspēju. Dalieties pieredzē komentāros, bÅ«s interesanti uzzināt.

Avots: www.habr.com