🥇Üheksa nõuannet Kubernetes'e tootlikkuse tõstmiseks

Tere kõigile! Minu nimi on Oleg Sidorenkov ja ma töötan ettevõttes DomKlik infrastruktuuri meeskonna juhina. Oleme juba üle kolme aasta kasutanud 'Kuubikut' tootmises ning selle aja jooksul oleme selle kasutamisel kogenud palju erinevaid huvitavaid hetki. Täna räägin teile, kuidas õige lähenemise korral saate 'tavalise' Kubernetesest veelgi rohkem jõudlust oma klastrile välja pigistada. Valmis, juba!

Te kõik teate, et Kubernetes on skaleeritav avatud lähtekoodiga süsteem konteinerite orkestreerimiseks; või nagu 5 binaari, mis loovad maagia, hallates teie mikroteenuste elutsükli serverikeskkonnas. See on ka üsna paindlik tööriist, mida saab koguda nagu Lego klotsid, et maksimeerida kohandamist erinevate ülesannete jaoks.

Ja tundub, et kõik on hästi: viska serverid klastrisse nagu küttepuid ahju ja ära muretse. Kuid kui hoolid keskkonnast, siis mõtle: 'Kuidas ma saan ahjus tuld hoida ja metsa säästa?'. Teisisõnu, kuidas leida viise infrastruktuuri parandamiseks ja kulude kärpimiseks.

1. Jälgige meeskondade ja rakenduste ressursse

Üks kõige mõistlikumaid, kuid tõhusamaid meetodeid on requests/limits'i rakendamine. Jagage rakendusi nimedega ruumidesse ja nimetage ruumid arendusmeeskondade järgi. 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

Kogemuste põhjal oleme jõudnud järeldusele, et ei tasu ületada soove piiridele rohkem kui kahekordse erinevusega. Klasteri maht arvutatakse soovide põhjal ja kui määrate rakendustele ressursivahe, näiteks 5–10 korda, siis kujutage ette, mis juhtub teie sõlmega, kui see täitub podidega ja saab järsku koormuse. Mitte midagi head. Minimaalselt throttling, maksimaalselt hüvasti töötajaga ja hakkate saama tsüklilist koormust teistele sõlmedele pärast seda, kui podid hakkavad liikuma.

Lisaks saab abil limitranges võite alguses määrata konteinerile ressursiväärtused - minimaalsed, maksimaalsed ja vaikeväärtused:

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

Ärge unustage piirata nimede ruumi ressursse, et üks meeskond ei saaks kõik klastrite ressursid endale võtta:

➜  ~ 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 kohaselt resourcequotas, kui ops meeskond soovib välja lasta pod'e, mis tarvitavad veel 10 cpu, siis ajakava ei luba seda teha ja tagastab 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

Sarnaste probleemide lahendamiseks võib kirjutada tööriista, näiteks nagu see, mis suudab salvestada ja commit'ida meeskonna ressursse.

2. Valige optimaalne failihaldus

Siin sooviksin puudutada püsivate mahtude ja Kubernetes worker-node diskisüsteemi teemat. Loodan, et keegi ei kasuta „Kuberneete” HDD-l, kuid vahel ei ole tavaline SSD enam piisav. Oleme avanud probleemi, kus logid tapavad ketast sisend-väljund toimingute tõttu, ja siin pole lahendusi eriti palju:

Kasutage kõrgtehnoloogilisi SSD-sid või minge NVMe (kui te ise hallate oma riistvara).
Vähendage logimise taset.
Tehke „nutikas” pod'ide tasakaalustus, mis koormavad ketast (podAntiAffinity).

Ülemine ekraan näitab, mis juhtub nginx-ingress-controller'i all, kui access_logs logimine on sisse lülitatud (~12 tuhat logi/sekundis). Selline olukord võib loomulikult viia kõigi selle nodi rakenduste halvenemiseni.

Mis puutub PV-desse, siis kahjuks ei ole ma proovinud kõiki tüüpe Püsivad mahud. Kasutage parimat varianti, mis teile sobib. Meil on ajalooliselt nii kujunenud, et väike osa teenustest vajab RWX-mahuteid ning kaua aega tagasi hakati selle töö jaoks kasutama NFS-mälukohta. Odav ja… piisab. Loomulikult oleme sellega palju jama näinud — ole terve, kuid oleme õppinud seda häälestama ning pea enam ei valuta. Ja kui võimalik, minge üle objektihoidlatele S3.

3. Koguge optimeeritud pilte

Parim on kasutada konteineritele optimeeritud pilte, et Kubernetes saaks neid kiiremini hankida ja tõhusamalt käitada.

Optimeeritus tähendab, et pildid:

sisaldavad ainult ühte rakendust või täidavad ainult ühte funktsiooni;
on väikese suurusega, sest suured pildid edastatakse võrgus halvemini;
omavad lõpp-punkte töökindluse ja valmiduse kontrollimiseks, mille abil Kubernetes saab ettevõtta samme häirete korral;
kasutavad konteinerisõbralikke operatsioonisüsteeme (nt Alpine või CoreOS), mis on konfigureerimisvigade suhtes vastupidavamad;
kasutavad mitmeastmelisi kogumisi, et saaksite juurutada ainult kompileeritud rakendusi, mitte kaasnevaid lähtekoode.

On palju tööriistu ja teenuseid, mis võimaldavad pilte jooksvalt kontrollida ja optimeerida. Oluline on hoida neid alati ajakohasena ja turvalisuse mõttes kontrollituna. Lõpuks saate:

Võrgu koormuse vähendamine kogu klastril.
Konteineri käivitamise aja lühendamine.
Teie kogu Docker registry väiksem maht.

4. Kasutage DNS-i vahemälu

Kui rääkida kõrgest koormusest, siis ilma klastrite DNS-süsteemi häälestamiseta on elu üsna vilets. Kui kunagi ammu toetasid Kubernetes arendajad oma lahendust kube-dns. See rakendus paigaldati ka meile, kuid seda tarkvara ei häälestatud eriti ja see ei andnud vajalikku jõudlust, kuigi ülesanne tundus olevat lihtne. Siis ilmus coredns, millele me üle läksime ja muretsesime vähem, sellest sai ka K8s-i vaikimisi DNS-teenus. Ühel hetkel jõudsime 40 000 rps DNS-süsteemi ja sellest lahendusest ei piisanud enam. Aga õnnelikul juhusel ilmus Nodelocaldns, tuntud ka kui node local cache, samuti NodeLocal DNSCache.

Miks me seda kasutame? Linuxi tuumas on viga, mis mitme korraga NAT-i kaudu UDP-ile juurdepääsemisel viib ühtlase koondumise tabelisse ja osa NAT-i kaudu liiklusest kaob (iga teenuse külastamine on NAT). Nodelocaldns lahendab selle probleemi, eemaldades NAT-i ja värskendades ühendust TCP kaudu kõrgemale DNS-ile, samuti kohaliku vahemäluga DNS-päringutele kõrgemate (sealhulgas lühike 5-sekundiline negatiivne vahemälu).

5. Skaalake pod'ide horisontaalset ja vertikaalset automaatset skaleerimist

Kas saate kindlalt öelda, et kõik teie mikroteenused on valmis kahekordseks või kolmeks koormuse kasvuks? Kuidas määrata õigesti oma rakendustele ressursse? Kaks pod'i, mis töötavad üle koormuse, võivad osutuda liigseks, kuid kitsas hoidmine tähendab, et olete riskis teenusele äkilise suure liikluse tõttu seisaku saamisega. Kuldeesmärki aitavad saavutada skaleerimist teenuseid, nagu Horizontal Pod Autoscaler ja Vertical Pod Autoscaler.

VPA võimaldab automaatset tõstmist teie konteinerite requests/limits pod'is vastavalt tegelikule kasutusele. Kuidas see võib olla kasulik? Kui teil on pod'e, mida mingil põhjusel ei saa horisontaalselt skaleerida (mis ei ole eriti usaldusväärne), siis võite proovida usaldada VPA-le oma ressursside muutmist. Selle eripära 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 konteinerite jaoks ja optimeerida seadeid, et säästa protsessorit ja mälu klastris.

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

Kubernetes'i planifikaator põhineb alati requests'il. Olgu see, mis tahes väärtus, mida te sinna panete, planifikaator otsib sobivat sõlme vastavalt sellele. Limit'i väärtused on vajalikud küblile, et mõista, millal piirata või tappa pod. Kuna ainus oluline parameeter on requests'i väärtus, töötab VPA sellega. Iga kord, kui määrate oma rakendusele vertikaalse skaleerimise, määrate, millised peaksid olema requests'id. Aga mis saab siis limit'itest? See parameeter skaleeritakse proportsionaalselt.

Näiteks siin on tavalised pod'i seaded:

ressursid:
   taotlused:
     mälu: 250Mi
     cpu: 200m
   piirangud:
     mälu: 500Mi
     cpu: 350m

Soovitusmehhanism määrab, et teie rakendusele on vajalik normaalne tööks 300m CPU ja 500Mi. Te saate järgmised seaded:

ressursid:
   taotlused:
     mälu: 500Mi
     cpu: 300m
   piirangud:
     mälu: 1000Mi
     cpu: 525m

Nagu eelnevalt mainitud, on see proportsionaalne skaleerimine, mis põhineb taotluste/piirangute suhte mansiifis:

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

Mis puudutab HPA, siis siin töömehhanism on läbipaistvam. Seatud on künnise väärtused mõõdikute jaoks, nagu näiteks CPU ja mälu, ja kui kõikide replikate keskmine väärtus ületab künnise, skaleeritakse rakendus +1 podini, kuni väärtus langeb künnisest madalamale või kuni maksimaalne replikate arv on saavutatud.

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

Lisaks tavapärastele mõõdikutele, nagu CPU ja mälu, saate seada künniseid oma kohandatud mõõdikutele Prometheuses ja töötada nendega, kui arvate, et see on kõige täpsem määratlemine, kui tuleb teie rakendust skaleerida. Kui rakendus stabiliseerub määratud mõõdiku alla, hakkab HPA skaleerima pode allapoole minimaalse replikate arvuni või kuni olek, mil koormus vastab määratud künnisele.

6. Ärge unustage Node Affinity ja Pod Affinity

Kauglülitused, kus toimub töötlemine, ei tööta kõik ühesugustes seadmetes, ja mitte kõik podid ei pea jooksutama rakendusi, mis nõuavad intensiivseid arvutusi. Kubernetes võimaldab määrata node'id ja podid spetsialiseerimisega. Node Affinity ja Pod Affinity.

Kui teil on node'id, mis sobivad intensiivsete arvutuste jaoks, on maksimaalse efektiivsuse tagamiseks parem siduda rakendused vastavatele node'idele. Selleks kasutage nodeSelector sildi määratluses.

Oletame, et teil on kaks node'i: üks, millel on CPUType=HIGHFREQ ja palju kiireid tuumasid, teine, millel on MemoryType=HIGHMEMORY palju mälu ja kõrgem jõudlus. Lihtsaim on määrata pod'i rakendamine node'ile HIGHFREQ, lisades jaotisesse spec selline valija:

…
nodeSelector:
	CPUType: HIGHFREQ

Rohkem kulukas ja spetsiifiline viis seda teha on kasutada nodeAffinity väljal affinity jaotises spec. On kaks varianti:

requiredDuringSchedulingIgnoredDuringExecution: rangeerimine (planeerija rakendab pode ainult kindlates node'ides (ja mitte kuskil mujal));
preferredDuringSchedulingIgnoredDuringExecution: pehme kohandamine (planifier püüab juurutada konkreetsetele sõlmedele ning kui see ei õnnestu, siis püüab ta juurutada järgmisele saadaval olevale sõlmele).

Saate määrata konkreetse sõlme märgendusjuhtimise süntaksit, näiteks In, NotIn, Exists, DoesNotExist, Gt või Lt. Kuid pidage meeles, et keerulised meetodid pikkades märgendusloendites aeglustavad kriitilistes olukordades otsuste tegemist. Teisisõnu, ärge keerake seda keeruliseks.

Kuidas mainitud, võimaldab Kubernetes määrata jooksvaid podide sidumisi. See tähendab, et saate seadistada teatud podide töötamise koos teiste podidega samas kättesaadavuse tsoonis (aktuaalne pilveteenustes) või sõlmedes.

Uues podAffinity väljad affinity jaotises spec on saadaval samad väljad nagu nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution ja preferredDuringSchedulingIgnoredDuringExecution. Ainus erinevus on see, et matchExpressions sidub podid sõlmega, millel juba töötab pod sellise sildiga.

Kubernetes pakub ka välja podAntiAffinity, mis seevastu ei seo podi teatud podidega olevate sõlmega.

Mis puudutab väljendeid, nodeAffinity on sama nõuanne: püüdke säilitada lihtsust ja loogilisust regulaatsioonides, ärge proovige üle koormata podide spetsiifikatsiooni keeruliste reeglite kogumiga. On väga lihtne luua reegel, mis ei vasta klastritingimustele, luues lisakoormust planeerijale ja vähendades üldist jõudlust.

7. Taints & Tolerations

On veel üks viis planeerija juhtimiseks. Kui teil on suur klaster, mis sisaldab sadu sõlmi ja tuhandeid mikroteenuseid, on väga keeruline mitte lubada teatud podide asukohaks teatud sõlmed.

Sellele aitab kaasa taintide mehhanism — keeldude reeglid. Näiteks võib teatud stsenaariumites keelata teatud sõlmedel oma podide käitamise. Tainti rakendamiseks konkreetsele sõlmele peate kasutama valikut taint kubectl'is. Määrake võti ja väärtus ning seejärel taint nagu NoSchedule või NoExecute:

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

Samuti on oluline märkida, et taintide mehhanism toetab kolme põhiefekti: NoSchedule, NoExecute ja PreferNoSchedule.

NoSchedule signifitseerib, et kuni podi spesifikatsioonis ei ole vastavat kirjet tolerations, ei saa ta olla juurutatud sõlmesse (selles näites node10).
PreferNoSchedule — lihtsustatud versioon. NoScheduleSel juhul püüab planeerija mitte jaotada podisid, millel pole vastavat kirjet tolerations sõlmele, kuid see ei ole range piirang. Kui klastris ei ole ressursse, hakkavad podid sellel sõlmel juurutama.
NoExecute — see efektiga aktiveerib kohe sadamate evakueerimise, millel pole vastavat kirjet tolerations.

Huvitav, et sellist käitumist saab tagasi võtta tolerantside mehhanismi abil. See on mugav, kui on olemas "keelatud" sõlm ja teil on vaja paigutada sinna ainult infrastruktuuri teenuseid. Kuidas seda teha? Lubada ainult need sadamad, millel on sobiv tolerants.

Nii näeb välja sadama spetsifikatsioon:

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

See ei tähenda, et järgmise redeploy korral paigutatakse sadam just sellele sõlmele, see ei ole Node Affinity mehhanism ja nodeSelector. Kuid kombineerides mitmeid funktsioone, võite saavutada väga painduva planeerija seadistuse.

8. Seadistage sadamate juurutamise prioriteet

See, et olete seadistanud sadamate sidumise sõlmedega, ei tähenda, et kõik sadamad peaksid olema töötlemisel sama prioriteediga. Näiteks võite soovida juurutada teatud sadamaid varem kui teisi.

Kubernetes pakub erinevaid viise sadamate prioriteetide seadistamiseks (Pod Priority and Preemption). Seadistus koosneb mitmest osast: objektist PriorityClass ja välja kirjeldusega priorityClassName sadama spetsifikatsioonis. Vaatame näidet:

apiVersion: scheduling.k8s.io\/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "See prioriteediklass peaks olema kasutusel ainult väga oluliste sadamate jaoks"

Loome PriorityClass, anname sellele nime, kirjelduse ja väärtuse. Mida kõrgem value, seda kõrgem prioriteet. Väärtus võib olla ükskõik milline 32-bitine täisarv, mis on väiksem või võrdne 1 000 000 000. Kõrgemad väärtused on reserveeritud kriitiliselt olulistele süsteemi sadamatele, mida tavaliselt ei saa eemaldada. Eemaldamine toimub ainult siis, kui kõrge prioriteediga sadamal pole kohta, kuhu juurutada, siis osa sadamatest teatud sõlmel evakueeritakse. Kui see mehhanism on teie jaoks liiga rangetu, võite lisada valiku preemptionPolicy: Never, ja siis ei toimu eemaldamisi, sadam ootab esimesena järjekorras ja ootab, kuni planeerija leiab talle vabad ressursid.

Edasi loome sadama, 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

Saate luua piiramatult prioriteediklasse, kuigi soovitatav on jääda mõõdukaks (näiteks piirduda madala, keskmise ja kõrge prioriteediga).

Seega, vajaduse korral suudate tõsta kriitiliste teenuste, nagu nginx-ingress-controller, coredns jms, tõhusust.

9. Optimeerige ETCD-klaster

ETCD-d võib nimetada kogu klastriteks. On väga oluline hoida selle andmebaasi töö kvaliteet kõrge, kuna just temast sõltub operatsioonide kiirus 'Kubes'. Tavaline ja samas üsna mõistlik lahendus on hoida ETCD klaster master-node'ides, et minimeerida latentsust kube-apiserverisse. Kui see ei ole võimalik, siis asetage ETCD võimalikult lähedale, tagades hea läbilaskevõime osalejate vahel. Samuti jälgige, kui palju ETCD sõlmi võib välja kukkuda ilma, et klaster kannataks.

Pidage meeles, et üleliigne osalejate arvu suurendamine klastris võib tõsta jätkusuutlikkust tootlikkuse arvelt; kõik peaks olema mõõdukas.

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

Omama head riistvara vastavalt klastrite suurusele (võite lugeda siit).
Reguleerida mõningaid parameetreid, kui olete klastrit jaotanud mitme andmekeskuse vahel või teie võrk ja kettad jätavad soovida (võite lugeda siit).

Kokkuvõte

Selles artiklis kirjeldatakse punkte, mille järgimist meie meeskond püüab. See ei ole samm-sammuline tegevusjuhend, vaid võimalused, mis võivad olla kasulikud klastrite haldamise kulude optimeerimiseks. Selge on, et iga klaster on omamoodi ainulaadne ja seadistuslahendused võivad oluliselt erineda, seega oleks huvitav saada tagasisidet: kuidas te jälgite oma Kubernetes klastrit, mille abil te selle tööd parandate. Jagage oma kogemusi kommentaarides, oleks huvitav neid kuulda.

Allikas: habr.com