🥇Üheksa nõuannet Kubernetes jõudluse tõstmiseks

Tere kõigile! Minu nimi on Oleg Sidorov, töötan ettevõttes DomClick infrastruktuurimeeskonna juhina. Oleme kasutanud "Kubi" tootmisversioonis juba rohkem kui kolm aastat ning selle aja jooksul oleme kogenud palju erinevaid huvitavaid hetki. Täna räägin teile, kuidas õige lähenemisega saate "puhtast" Kubernetesest veel rohkem võimsust välja võtta oma klastri jaoks. Valmis, start, mine!

Te kõik teate, et Kubernetes on avatud koodiga, skaleeritav süsteem konteinerite orkestreerimiseks; või noh, 5 binaarfaili, mis teevad imet, hallates teie mikroteenuste elutsüklit serverikeskkonnas. Lisaks on see üsna paindlik tööriist, mida saab nagu Lego klotse kokku panna, et maksimaalselt kohandada erinevate ülesannete jaoks.

Ja tundub, et kõik on hästi: viska serverid klastri nagu palk tule, ja muret ei tunne. Kuid kui sa hoolid keskkonnast, siis mõtled: „Kuidas ma saan tuld ahjus hoida, kuid metsast säästa?“. Teisisõnu, kuidas leida võimalusi infrastruktuuri täiustamiseks ja kulude vähendamiseks.

1. Jälgige meeskondade ja rakenduste ressursikasutust

Üks kõige tavalisemaid, kuid tõhusaid meetodeid on piirangute ja nõudmiste seadmine. Jagage rakendusi nimeväljade kaupa ning nimeväljad arendusmeeskondade kaupa. Määrake rakendusele enne juurutamist protsessori aja, mälu ja ajutise salvestusruumi tarbimise väärtused.

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

Kogemusest oleme jõudnud järeldusele, et nõudmised ei tohiks olla suuremad kui piirangud rohkem kui kaks korda. Klaster arvutatakse nõudmiste põhjal, ja kui te määrate rakendustele ressursside erinevuse näiteks 5-10 korda, siis kujutage ette, mis juhtub teie solgiga, kui see täitub podidega ja äkitselt koormus suureneb. Midagi head ei juhtu. Kõige vähem põhjustab see trottlingut ja kõige rohkem hüvasti peate te töötajaga ning saad pideva koormuse teistele solgidele, kui podid hakkavad liikuma.

Lisaks saate limitranges Te võite konteinerile alguses määrata ressursside väärtused – minimaalsed, maksimaalsed ja vaikimisi:

➜  ~ 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

Ära unusta piirata nimeliku ruumi ressursse, et üks meeskond ei saaks kogu klastrite ressursse endale haarata:

➜  ~ 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

Nagu näha on kirjelduse järgi resourcequotas, kui ops meeskond soovib juurutada pod'e, mis tarbiks veel 10 cpu, siis planeerija ei lase seda teha ja annab vea:

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

Sarnase probleemi lahendamiseks saab kirjutada tööriista, näiteks nagu seda, mis oskab salvestada ja fikseerida meeskondade ressursside olekuid.

2. Valige optimaalsed failide salvestamiseks

Siin tahaksin käsitleda püsivate mahtude ja Kubernetes'e worker-node'i ketasüsteemi teemat. Loodan, et keegi ei kasuta „Kubi” HDD-l tootmises, kuid mõnikord ei piisa ka tavalise SSD kohta. Oleme sellise probleemiga silmitsi seisnud, et logid hävitavad ketast sisse- ja väljundoperatsioonide tõttu, ja lahendusi ei ole just palju:

Kasutage kõrgvõimekat SSD-d või viige üle NVMe-le (kui teil on oma riistvara käsutuses).
Vähendage logimise taset.
Tehke „nutikas” podide tasakaalustamine, mis koormavad ketast (podAntiAffinity).

Ülalloolev ekraan näitab, mis juhtub nginx-ingress-controlleriga, kui ketas on logimise access_logs kostus (~12 tuhat logi/s). See seisund võib muidugi põhjustada kõigi rakenduste halvenemist selle node'i peal.

Mis puutub PV-de, siis kahjuks ei ole ma kõiki liike proovinud Püsivad mahutid. Kasutage parimat varianti, mis sobib just teile. Meil on ajalooliselt olnud nii, et väike osa teenustest vajab RWX-mahtu, ja juba ammu on selleks otstarbeks kasutatud NFS-salvestust. Odav ja... piisav. Muidugi, me oleme sellest tüdinud — olgu see nii, kuid oleme õppinud seda häälestama, ja peavalu pole enam. Ja kui võimalik, minge üle objekti salvestusele S3.

3. Koguge optimeeritud pilte

Parim on kasutada konteinerite jaoks optimeeritud pilte, et Kubernetes saaks neid kiiremini kätte ja tõhusamalt täita.

Optimeeritus tähendab, et pildid:

sisaldavad ainult ühte rakendust või täidavad ainult ühte funktsiooni;
on väikesed, sest suured pildid edastatakse halvemini võrgus;
on lõpp-punktid töökindluse ja valmiduse kontrollimiseks, millega Kubernetes saab ettevõtta mingit tegevust seisakute korral;
kasutavad konteinerite sõbralikke operatsioonisüsteeme (nagu Alpine või CoreOS), mis on konfiguratsioonivigade suhtes vastupidavamad;
kasutavad mitmeastmelisi kogumise meetodeid, et saaksite juurutada ainult kompileeritud rakendusi, mitte kaasnevaid lähtekode.

On palju tööriistu ja teenuseid, mis võimaldavad reaalajas pilte kontrollida ja optimeerida. Oluline on hoida need alati ajakohased ja turvaliseks kontrollitud. Selle tulemuseks on:

Võrgu koormuse vähenemine kogu klastrile.
Konteineri käivitamise aja vähenemine.
Teie kogu Docker registry väiksem maht.

4. Kasutage DNS-i vahemälu

Kui rääkida kõrgetest koormustest, siis ilma klastris DNS-süsteemi häälestamiseta on elu üsna kehv. Aegade alguses toetas Kubernetes oma lahendust kube-dns. See viidi ellu ka meie süsteemis, kuid seda tarkvara ei häälestatud eriti ja see ei näidanud vajalikke jõudluse tulemusi, kuigi ülesanne näib olema lihtne. Siis tuli coredns, millele me ülemineku tegime ja ei kahetsenud, kuna see sai hiljem K8s-is vaikimisi DNS-teenuseks. Ühel hetkel jõudsime 40 000 rps DNS-süsteemile, ja sellest lahendusest hakkas samuti puudust tundma. Kuid õnneliku juhuse tõttu ilmus Nodelocaldns, tuntud ka kui node local cache, samuti. NodeLocal DNSCache.

Miks me seda kasutame? Linuxi tuumas on viga, mis mitme võrgukonfiguratsiooni korral conntrack NAT kaudu UDP kaudu viib joonte kirjutamise rivelikriisi ning osa NAT kaudu liikuvast liiklusest kaob (iga kord, kui läbi teenuse minnakse — see on NAT). Nodelocaldns lahendab selle probleemi, kõrvaldades NAT ja uuendades ühenduse TCP-le allstrateegiate DNS-idega ning pakkudes ka kohaliku DNS-i päringute vahemälu (sealhulgas lühike 5-sekundiline negatiivne vahemälu).

5. Skaalige podid automaatselt horisontaalselt ja vertikaalselt

Kas saate kindlalt öelda, et kõik teie mikroteenused on valmis kahekordseks või kolmekordseks koormuse kasvuks? Kuidas jagada ressursse oma rakendustele õigesti? Paari podi käitamine töötamise koormusest üle võib osutuda liialdatuks, samas riskite, et äkilise liikluse kasvu korral teenusel tekib seisak. Kulda keskteed aitab saavutada sellised teenused nagu Horisontaalne Pod Autoscaler ja Vertikaalne Pod Autoscaler.

VPA võimaldab automaatselt tõsta oma konteinerite requests/limits podis, sõltuvalt tegelikust kasutusest. Kuidas see kasulik on? Kui teil on podid, mida mingil põhjusel ei saa horisontaalselt skaleerida (mis pole tavaliselt usaldusväärne), siis võite proovida usaldada VPA, et muuta selle ressursse. Selle funktsioon seisneb soovituste süsteemis, mis põhineb ajaloolistel ja praegustel andmetel metric-serverist, seega kui te ei soovi automaatselt muuta requests/limits, saate lihtsalt jälgida soovitatud ressursse oma konteineritele ja optimeerida seadeid, et säästa CPU-d ja mälu klastris.

Pilt on võetud aadressilt https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Kubernetesi planeerija põhineb alati requests'idel. Ükskõik, millise väärtuse sinna määrate, otsib planeerija sobivat sõlme lähtuvalt sellest. Limits väärtused on kubeletile vajalikud, et mõista, millal pod'i piirata või lõpetada. Ja kuna ainus oluline parameeter on requests väärtus, töötab VPA selle alusel. Iga kord, kui määrate rakenduse vertikaalses skaleerimises, määrate, millised peaksid olema requests. Aga mis juhtub siis limits'itega? See parameeter skaleeritakse ka proportsionaalselt.

Näiteks siin on tavalised pod'i seadistused:

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

Soovituste mehhanism määrab, et teie rakendusele on normatiivseks töötamiseks vajalik 300m CPU ja 500Mi. Saate sellised seadistused:

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

Nagu eelnevalt mainitud, toimub see proportsionaalne skaleerimine requests/limits suhetes manifestis:

CPU: 200m → 300m: suhe 1:1.75;
Mälu: 250Mi → 500Mi: suhe 1:2.

As for HPA, siis on siin töömehhanism selgem. Künnise väärtused seadistatakse näiteks protsessori ja mälu kohta, ja kui kõigi replikate keskmine väärtus ületab künnise, siis rakendus skaleeritakse +1 pod vähemalt seni, kuni väärtus langeb alla künnise või kuni maksimaalne replikate arv on saavutatud.

Pilt on võetud aadressilt https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Lisaks tavapärastele mõõdikutel, nagu protsessor ja mälu, saate seadistada künnised oma kohandatud mõõdikutel Prometheuses ja töötada nendega, kui peate neid kõige täpsemaks määratluseks, millal rakendust skaleerida. Kui rakendus stabiliseerub allpool määratud mõõtmispiiri, alustab HPA podide skaleerimist allapoole kuni minimaalsete replikate arvuni või kuni koormus vastab määratud künnisele.

6. Ärge unustage Node Affinity ja Pod Affinity

Kõik sõlmed ei tööta sama riistvara peal, kõigile podidele ei pea olema vajalikud intensiivsete arvutusvajadusega rakenduste täitmine. Kubernetes võimaldab määrata sõlmede ja podide spetsialiseerumist kasutades Node Affinity ja Pod Affinity.

Kui teil on noodid, mis sobivad intensiivseteks arvutusteks, on parima efektiivsuse saavutamiseks parem rakendused vastavatele nootidele siduda. Selleks kasutage nodeSelector sõlmeliimiga.

Oletame, et teil on kaks nooti: üks on varustatud CPUType=HIGHFREQ ja suure hulga kiirete tuumadega, teine aga on MemoryType=HIGHMEMORY suure hulga mälu ja paremaga täitmisvõimega. Kõige lihtsam on määrata podi juurutamine noodele HIGHFREQ, lisades sektsioonis spec sellise valiku:

…
nodeSelector:
	CPUType: HIGHFREQ

Rohkem kulukas ja spetsiifiline meetod selle tegemiseks on kasutada nodeAffinity väljal affinity sektsioonis spec. On kaks varianti:

requiredDuringSchedulingIgnoredDuringExecution: rangeerimine (planeerija juurutab podid ainult konkreetsetele nodidele (ja mitte kuhugi mujale));
preferredDuringSchedulingIgnoredDuringExecution: pehme seadistus (planeerija püüab juurutada konkreetsetele nodidele ning kui see ei õnnestu, proovib juurutada järgmisele kättesaadavale noodi).

Saate määrata kindla sildistamisjuhtimise süntaksi, näiteks In, NotIn, Exists, DoesNotExist, Gt või Lt. Kuid pidage meeles, et keerulised meetodid pikkade märgisüsteemide puhul aeglustavad otsuste tegemist kriitilistes olukordades. Teisisõnu, ärge keerutage asju liialt komplikeerituks.

Nagu eelnevalt mainitud, võimaldab Kubernetes seadistada praeguste podide sidumise. See tähendab, et saate teha nii, et teatud podid töötaksid koos teiste podidega samas saadavuspiirkonnas (mis on oluline pilveteenuste puhul) või noodides.

V podAffinity väljad affinity sektsioonis spec saadaval on samad väljad nagu ka nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution ja preferredDuringSchedulingIgnoredDuringExecution. Ainuke erinevus on see, et matchExpressions sidumine paneb podid nodi külge, kus juba töötab pod, millel on selline märk.

Lisaks pakub Kubernetes välja podAntiAffinity, mis seevastu ei seosta podi nodiga, kus on teatud podid.

Väljendite osas nodeAffinity võib anda sama nõu: püüdke hoida reeglid lihtsad ja loogilised, vältige podide spetsifikatsiooni liialt keeruliseks muutmist. On väga lihtne luua reegel, mis ei vasta klastritingimustele, luues lisakoormuse planeerijale ja vähendades üldist jõudlust.

7. Taints & Tolerations

On olemas veel üks võimalus planeerija haldamiseks. Kui teil on suur klaster, kus on sadu sõlmi ja tuhandeid mikroteenuseid, on väga keeruline mitte lubada teatud podide paigutamist teatud sõlmedesse.

Sellele aitab kaasa taint-mehhanism — keelavaid reegleid. Näiteks on teatud stsenaariumides võimalik keelata teatud sõlmedel podide käivitamine. Taint'i rakendamiseks konkreetsele sõlmele tuleb kasutada valikut taint kubectl. Näidake võtme ja väärtuse ning seejärel taint nagu NoSchedule või NoExecute:

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

Samuti väärib märkimist, et taint-mehhanism toetab kolme peamist efekti: NoSchedule, NoExecute ja PreferNoSchedule.

NoSchedule tähendab, et seni kuni podi spetsifikatsioonis ei ole vastavat kirjet tolerations, ei saa see olla sõlmes juurutatud (antud näites node10).
PreferNoSchedule — lihtsustatud versioon NoSchedule. Sel juhul püüab planeerija mitte jaotada podisid, millel ei ole vastavat kirjet tolerations sõlmele, kuid see ei ole range piirang. Kui klastris ei ole ressursse, hakkavad podid selle sõlme juurutama.
NoExecute — see efekt käivitab kohe podide evakueerimise, millel ei ole vastavat kirjet. tolerations.

Huvitav, et sellist käitumist saab tühistada toleratsioonimehhanismi abil. See on mugav, kui on olemas "keelatud" sõlm ja soovite sellele paigutada ainult infrastruktuuri teenuseid. Kuidas seda teha? Luba ainult need podid, millel on sobiv toleratsioon.

Nii näeb välja podi spetsifikatsioon:

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

See ei tähenda, et järgmisel redploy-l satub pod kindlasti sellele sõlmele, see ei ole Node Affinity mehhanism ja nodeSelector. Kuid kombineerides mitmeid funktsioone, saate saavutada väga paindlikud plaanijate seadistused.

8. Konfigureerige podide juurutamise prioriteet

See, et olete seadistatud podide seondumise sõlmedega, ei tähenda, et kõik podid peaksid olema töödeldud sama prioriteediga. Näiteks võite soovida juurutada teatud podid varem kui teised.

Kubernetes pakub erinevaid viise podide prioriteedi seadistamiseks (Pod Priority and Preemption). Seadistamine koosneb mitmest osast: objektist PriorityClass ja kirjelduse väljast priorityClassName podi spetsifikatsioonis. Vaadakem näiteks:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "Seda prioriteed tuleb kasutada ainult väga tähtsate pod'ide jaoks"

Me loome PriorityClass, anname sellele nime, kirjelduse ja väärtuse. Mida kõrgem value, seda kõrgem on prioriteet. Väärtus võib olla mis tahes 32-bitine täisarv, mis on väiksem või võrdne 1 000 000 000. Kõrgemad väärtused on reserveeritud kriitilistele süsteemipod'idele, mida üldiselt ei saa sunniviisil välja lülitada. Väljalülitamine toimub ainult siis, kui kõrge prioriteediga pod'il pole kuhugi paigutuda, siis teatud sõlmedelt osad pod'id evakueeritakse. Kui see mehhanism tundub teile liiga jäik, siis võite lisada valiku preemptionPolicy: Never, ja siis ei ole väljalülitamist, pod jääb järjekorras esimeseks ja ootab, kuni planeerija leiab sellele vabade ressurside.

Seejärel loome pod'i, kus määrame nime 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

Võib luua piiramatult prioriteediklasside arvu, kuigi soovitatakse sellega mitte liialdada (näiteks piirduda madala, keskmise ja kõrge prioriteediga).

Seega, vajadusel saate tõsta kriitiliste teenuste, nagu nginx-ingress-controller, coredns jne, tõhusust.

9. Optimeerige ETCD-klaster

ETCD võib olla kogu klastrite teaduse keskpunkt. On äärmiselt oluline hoida selle andmebaasi töö kvaliteet kõrgel, kuna just sellest sõltub operatsioonide kiirus "Klastes". Tavaline ja suhteliselt hea lahendus on hoida ETCD klaster peatöötajatel, et tagada minimaalne viivitus kube-apiserverini. Kui see pole võimalik, proovige paigutada ETCD nii lähedale kui võimalik, tagades osalejate vahel hea ribalaiuse. Samuti pidage meeles, kui palju ETCD sõlmi saab välja langeda ilma klastrile kahjustamata.

Pidage meeles, et liiga paljude osalejate lisamine klastrisse võib suurendada rikke taluvust, kuid see võib pärssida jõudlust — kõik peaks olema mõõdukalt.

Kui rääkida teenuse seadistamisest, siis soovitusi on vähe:

Omada head riistvara, sõltuvalt klastrite suurusest (võite lugeda) siin).
Reguleerige mõned seaded, kui olete klastrit levitanud paari andmeruumi vahel või kui teie võrk ja kettad jätavad soovida (saate lugeda siin).

Kokkuvõte

Selles artiklis kirjeldatakse punkte, mida meie meeskond püüab järgida. See ei ole samm-sammult juhend, vaid variandid, mis võivad aidata klastrikulu optimeerida. On selge, et iga klaster on omamoodi ainulaadne ja seadistamise lahendused võivad oluliselt erineda, seetõttu oleks huvitav saada teilt tagasisidet: kuidas te jälgite oma Kubernetes klastrit, millega te parandate selle tööd. Jagage oma kogemusi kommentaarides, oleks huvitav neid teada.

Allikas: habr.com