🥇Nine tips para mapahusay ang performance ng Kubernetes

Kamusta kayong lahat! Ang pangalan ko ay Oleg Sidorenkov, nagtatrabaho ako sa DomClick bilang pinuno ng pangkat ng imprastraktura. Ginagamit namin ang Kubik sa produksyon nang higit sa tatlong taon, at sa panahong ito naranasan namin ang maraming iba't ibang mga kawili-wiling sandali kasama nito. Ngayon ay sasabihin ko sa iyo kung paano, sa tamang diskarte, maaari mong i-squeeze ang higit pang performance ng vanilla Kubernetes para sa iyong cluster. Ready steady go!

Alam na alam ninyong lahat na ang Kubernetes ay isang scalable na open source system para sa container orchestration; mabuti, o 5 binary na gumagana ng magic sa pamamagitan ng pamamahala sa ikot ng buhay ng iyong mga microservice sa isang kapaligiran ng server. Bilang karagdagan, ito ay isang medyo nababaluktot na tool na maaaring tipunin tulad ng Lego para sa maximum na pagpapasadya para sa iba't ibang mga gawain.

At tila maayos ang lahat: itapon ang mga server sa kumpol tulad ng kahoy na panggatong sa isang firebox, at hindi mo malalaman ang anumang kalungkutan. Ngunit kung ikaw ay para sa kapaligiran, iisipin mo: "Paano ko mapapanatili ang apoy na nagniningas at maliligtas ang kagubatan?" Sa madaling salita, kung paano maghanap ng mga paraan upang mapabuti ang imprastraktura at mabawasan ang mga gastos.

1. Subaybayan ang mga mapagkukunan ng koponan at aplikasyon

Isa sa mga pinakakaraniwan, ngunit epektibong pamamaraan ay ang pagpapakilala ng mga kahilingan/limitasyon. Hatiin ang mga application ayon sa mga namespace, at mga namespace ayon sa mga development team. Bago i-deploy, itakda ang mga halaga ng application para sa pagkonsumo ng oras ng processor, memorya, at ephemeral na imbakan.

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

Sa pamamagitan ng karanasan, nakarating kami sa konklusyon: hindi mo dapat palakihin ang mga kahilingan mula sa mga limitasyon ng higit sa dalawang beses. Ang dami ng cluster ay kinakalkula batay sa mga kahilingan, at kung bibigyan mo ang mga application ng pagkakaiba sa mga mapagkukunan, halimbawa, 5-10 beses, pagkatapos ay isipin kung ano ang mangyayari sa iyong node kapag napuno ito ng mga pod at biglang nakatanggap ng load. Walang maganda. Sa pinakamababa, throttling, at sa maximum, magpapaalam ka sa manggagawa at makakuha ng cyclic load sa natitirang mga node pagkatapos magsimulang gumalaw ang mga pod.

Bilang karagdagan, sa tulong limitranges Sa simula, maaari kang magtakda ng mga halaga ng mapagkukunan para sa lalagyan - minimum, maximum at default:

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

Huwag kalimutang limitahan ang mga mapagkukunan ng namespace upang hindi makuha ng isang koponan ang lahat ng mga mapagkukunan ng cluster:

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

Tulad ng makikita mula sa paglalarawan resourcequotas, kung gusto ng ops team na mag-deploy ng mga pod na kukuha ng isa pang 10 cpu, hindi ito papayagan ng scheduler at maglalagay ng error:

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

Upang malutas ang gayong problema, maaari kang magsulat ng isang tool, halimbawa, tulad ng ito, magagawang mag-imbak at gumawa ng estado ng mga mapagkukunan ng command.

2. Piliin ang pinakamainam na imbakan ng file

Dito nais kong hawakan ang paksa ng patuloy na dami at ang disk subsystem ng mga node ng manggagawa ng Kubernetes. Umaasa ako na walang gumagamit ng "Cube" sa isang HDD sa paggawa, ngunit kung minsan ang isang regular na SSD ay hindi na sapat. Nakatagpo kami ng problema kung saan pinapatay ng mga log ang disk dahil sa mga operasyon ng I/O, at walang maraming solusyon:

Gumamit ng mga SSD na may mataas na pagganap o lumipat sa NVMe (kung pinamamahalaan mo ang sarili mong hardware).
Bawasan ang antas ng pag-log.
Gawin ang "matalinong" pagbabalanse ng mga pod na gumahasa sa disk (podAntiAffinity).

Ipinapakita ng screen sa itaas kung ano ang nangyayari sa ilalim ng nginx-ingress-controller sa disk kapag pinagana ang access_logs logging (~12 thousand logs/sec). Ang kundisyong ito, siyempre, ay maaaring humantong sa pagkasira ng lahat ng mga aplikasyon sa node na ito.

Sa PV naman, aba, hindi ko pa nasusubukan lahat species Patuloy na Dami. Gamitin ang pinakamahusay na opsyon na nababagay sa iyo. Sa kasaysayan, nangyari sa ating bansa na ang isang maliit na bahagi ng mga serbisyo ay nangangailangan ng mga volume ng RWX, at matagal na ang nakalipas nagsimula silang gumamit ng imbakan ng NFS para sa gawaing ito. Mura at... sapat na. Siyempre, siya at ako ay kumain ng tae - pagpalain ka, ngunit natutunan namin na ibagay ito, at ang aking ulo ay hindi na sumasakit. At kung maaari, lumipat sa S3 object storage.

3. Kolektahin ang mga na-optimize na larawan

Pinakamainam na gumamit ng mga larawang naka-optimize sa lalagyan upang makuha ng Kubernetes ang mga ito nang mas mabilis at maisagawa ang mga ito nang mas mahusay.

Ang ibig sabihin ng na-optimize na ang mga larawan ay:

naglalaman lamang ng isang application o gumanap lamang ng isang function;
maliit ang laki, dahil ang malalaking imahe ay ipinapadala nang mas malala sa network;
magkaroon ng mga endpoint sa kalusugan at kahandaan na nagbibigay-daan sa Kubernetes na kumilos sa kaganapan ng downtime;
gumamit ng mga operating system na madaling gamitin sa lalagyan (tulad ng Alpine o CoreOS), na mas lumalaban sa mga error sa pagsasaayos;
gumamit ng mga multi-stage build para makapag-deploy ka lang ng mga compiled application at hindi ang mga kasamang source.

Mayroong maraming mga tool at serbisyo na nagbibigay-daan sa iyong suriin at i-optimize ang mga larawan sa mabilisang. Mahalagang palaging panatilihing napapanahon ang mga ito at masuri para sa kaligtasan. Bilang resulta makakakuha ka ng:

Binawasan ang pag-load ng network sa buong cluster.
Binabawasan ang oras ng pagsisimula ng container.
Mas maliit na sukat ng iyong buong Docker registry.

4. Gumamit ng DNS cache

Kung pag-uusapan natin ang tungkol sa mataas na pag-load, kung gayon ang buhay ay medyo mahirap nang hindi na-tune ang DNS system ng cluster. Noong unang panahon, sinuportahan ng mga developer ng Kubernetes ang kanilang solusyon sa kube-dns. Ito ay ipinatupad din dito, ngunit ang software na ito ay hindi partikular na nakatutok at hindi gumawa ng kinakailangang pagganap, bagaman ito ay tila isang simpleng gawain. Pagkatapos ay lumitaw ang mga coredns, kung saan kami lumipat at walang kalungkutan; kalaunan ay naging default na serbisyo ng DNS sa K8s. Sa ilang mga punto, lumaki kami sa 40 thousand rps sa DNS system, at ang solusyon na ito ay naging hindi rin sapat. Ngunit, sa pamamagitan ng swerte, lumabas ang Nodelocaldns, aka node local cache, aka NodeLocal DNSCache.

Bakit natin ito ginagamit? Mayroong isang bug sa kernel ng Linux na, kapag maraming tawag sa pamamagitan ng conntrack NAT sa UDP, humahantong sa isang kondisyon ng karera para sa mga entry sa conntrack table, at bahagi ng trapiko sa pamamagitan ng NAT ay nawala (bawat biyahe sa Serbisyo ay NAT). Niresolba ng Nodelocaldns ang problemang ito sa pamamagitan ng pag-alis ng NAT at pag-upgrade ng koneksyon sa TCP sa upstream DNS, pati na rin ang lokal na pag-cache ng upstream na mga query sa DNS (kabilang ang isang maikling 5 segundong negatibong cache).

5. Awtomatikong i-scale ang mga pod nang pahalang at patayo

Masasabi mo ba nang may kumpiyansa na ang lahat ng iyong microservice ay handa na para sa dalawa hanggang tatlong beses na pagtaas ng load? Paano maayos na maglaan ng mga mapagkukunan sa iyong mga aplikasyon? Ang pagpapanatiling isang pares ng mga pod na tumatakbo nang lampas sa workload ay maaaring maging kalabisan, ngunit ang pagpapanatiling pabalik-balik sa kanila ay nagdudulot ng panganib ng downtime mula sa biglaang pagtaas ng trapiko sa serbisyo. Mga serbisyo tulad ng Horizontal Pod Autoscaler и Vertical Pod Autoscaler.

VPA nagbibigay-daan sa iyong awtomatikong itaas ang mga kahilingan/limitasyon ng iyong mga lalagyan sa pod depende sa aktwal na paggamit. Paano ito magiging kapaki-pakinabang? Kung mayroon kang mga pod na hindi mai-scale nang pahalang sa ilang kadahilanan (na hindi lubos na maaasahan), maaari mong subukang ipagkatiwala ang mga pagbabago sa mga mapagkukunan nito sa VPA. Ang tampok nito ay isang sistema ng rekomendasyon batay sa makasaysayang at kasalukuyang data mula sa metric-server, kaya kung ayaw mong awtomatikong baguhin ang mga kahilingan/limitasyon, maaari mo lamang subaybayan ang mga inirerekomendang mapagkukunan para sa iyong mga lalagyan at i-optimize ang mga setting para makatipid ng CPU at memorya sa kumpol.

Kinuha ang larawan mula sa https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Ang scheduler sa Kubernetes ay palaging nakabatay sa mga kahilingan. Anuman ang halaga na iyong ilagay doon, ang scheduler ay maghahanap ng angkop na node batay dito. Ang mga halaga ng limitasyon ay kailangan para maunawaan ng cubelet kung kailan dapat i-throttle o papatayin ang pod. At dahil ang tanging mahalagang parameter ay ang halaga ng mga kahilingan, gagana ang VPA dito. Sa tuwing i-scale mo ang isang application nang patayo, tutukuyin mo kung ano dapat ang mga kahilingan. Ano ang mangyayari sa mga limitasyon kung gayon? Ang parameter na ito ay i-scale din nang proporsyonal.

Halimbawa, narito ang karaniwang mga setting ng pod:

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

Tinutukoy ng engine ng rekomendasyon na ang iyong application ay nangangailangan ng 300m CPU at 500Mi upang gumana nang maayos. Makukuha mo ang mga sumusunod na setting:

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

Gaya ng nabanggit sa itaas, ito ay proporsyonal na pag-scale batay sa ratio ng mga kahilingan/limitasyon sa manifest:

CPU: 200m → 300m: ratio 1:1.75;
Memorya: 250Mi → 500Mi: ratio 1:2.

tungkol sa HPA, kung gayon ang mekanismo ng operasyon ay mas transparent. Ang mga sukatan gaya ng CPU at memory ay may threshold, at kung ang average ng lahat ng mga replika ay lumampas sa threshold, ang application ay na-scale ng +1 sub hanggang sa bumaba ang halaga sa threshold o hanggang sa maabot ang maximum na bilang ng mga replika.

Kinuha ang larawan mula sa https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Bilang karagdagan sa mga karaniwang sukatan tulad ng CPU at memorya, maaari kang magtakda ng mga threshold sa iyong mga custom na sukatan mula sa Prometheus at makipagtulungan sa kanila kung sa tingin mo iyon ang pinakatumpak na indikasyon kung kailan dapat sukatin ang iyong aplikasyon. Kapag na-stabilize na ang application sa ibaba ng tinukoy na metric threshold, sisimulan ng HPA na i-scale ang mga pod pababa sa minimum na bilang ng mga replica o hanggang sa maabot ng load ang tinukoy na threshold.

6. Huwag kalimutan ang tungkol sa Node Affinity at Pod Affinity

Hindi lahat ng node ay tumatakbo sa parehong hardware, at hindi lahat ng pod ay kailangang magpatakbo ng mga compute-intensive na application. Binibigyang-daan ka ng Kubernetes na itakda ang espesyalisasyon ng mga node at pod na ginagamit Node Affinity и Pod Affinity.

Kung mayroon kang mga node na angkop para sa compute-intensive na mga operasyon, pagkatapos ay para sa maximum na kahusayan mas mahusay na itali ang mga application sa kaukulang mga node. Upang gawin ang paggamit na ito nodeSelector na may label na node.

Sabihin nating mayroon kang dalawang node: ang isa ay may CPUType=HIGHFREQ at isang malaking bilang ng mga mabilis na core, isa pang may MemoryType=HIGHMEMORY mas maraming memorya at mas mabilis na pagganap. Ang pinakamadaling paraan ay ang magtalaga ng deployment sa isang node HIGHFREQsa pamamagitan ng pagdaragdag sa seksyon spec tagapili na ito:

…
nodeSelector:
	CPUType: HIGHFREQ

Ang isang mas mahal at tiyak na paraan upang gawin ito ay ang paggamit nodeAffinity sa bukid affinity seksyon spec. Mayroong dalawang mga pagpipilian:

requiredDuringSchedulingIgnoredDuringExecution: mahirap na setting (ang scheduler ay magpapakalat ng mga pod lamang sa mga partikular na node (at wala saanman));
preferredDuringSchedulingIgnoredDuringExecution: soft setting (susubukan ng scheduler na mag-deploy sa mga partikular na node, at kung nabigo iyon, susubukan nitong i-deploy sa susunod na available na node).

Maaari kang tumukoy ng partikular na syntax para sa pamamahala ng mga label ng node, gaya ng In, NotIn, Exists, DoesNotExist, Gt o Lt. Gayunpaman, tandaan na ang mga kumplikadong pamamaraan sa mahabang listahan ng mga label ay magpapabagal sa paggawa ng desisyon sa mga kritikal na sitwasyon. Sa madaling salita, panatilihin itong simple.

Gaya ng nabanggit sa itaas, pinapayagan ka ng Kubernetes na itakda ang affinity ng mga kasalukuyang pod. Iyon ay, maaari mong gawin ang ilang mga pod na gumana nang magkasama sa iba pang mga pod sa parehong availability zone (nauugnay para sa mga ulap) o mga node.

В podAffinity mga patlang affinity seksyon spec ang parehong mga patlang ay magagamit tulad ng sa kaso ng nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Ang pagkakaiba lang ay iyon matchExpressions ibubuklod ang mga pod sa isang node na nagpapatakbo na ng pod na may label na iyon.

Nag-aalok din ang Kubernetes ng field podAntiAffinity, na, sa kabaligtaran, ay hindi nagbubuklod sa pod sa isang node na may mga partikular na pod.

Tungkol sa mga expression nodeAffinity Ang parehong payo ay maaaring ibigay: subukang panatilihing simple at lohikal ang mga patakaran, huwag subukang i-overload ang detalye ng pod na may isang kumplikadong hanay ng mga patakaran. Napakadaling gumawa ng panuntunan na hindi tumutugma sa mga kundisyon ng cluster, na lumilikha ng hindi kinakailangang pag-load sa scheduler at binabawasan ang pangkalahatang pagganap.

7. Mga Mantsa at Pagpapahintulot

May isa pang paraan upang pamahalaan ang scheduler. Kung mayroon kang malaking kumpol na may daan-daang node at libu-libong microservice, napakahirap na hindi payagan ang ilang pod na ma-host sa ilang partikular na node.

Ang mekanismo ng mga bahid—mga panuntunan sa pagbabawal—ay nakakatulong dito. Halimbawa, sa ilang partikular na sitwasyon maaari mong pagbawalan ang ilang partikular na node sa pagpapatakbo ng mga pod. Upang maglapat ng taint sa isang partikular na node kailangan mong gamitin ang opsyon taint sa kubectl. Tukuyin ang susi at halaga at pagkatapos ay marumi NoSchedule o NoExecute:

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

Kapansin-pansin din na ang mekanismo ng taint ay sumusuporta sa tatlong pangunahing epekto: NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule nangangahulugan na sa ngayon ay wala nang katumbas na entry sa detalye ng pod tolerations, hindi ito mai-deploy sa node (sa halimbawang ito node10).
PreferNoSchedule - pinasimple na bersyon NoSchedule. Sa kasong ito, susubukan ng scheduler na huwag maglaan ng mga pod na walang katugmang entry tolerations bawat node, ngunit hindi ito isang mahirap na limitasyon. Kung walang mga mapagkukunan sa cluster, magsisimulang mag-deploy ang mga pod sa node na ito.
NoExecute - ang epektong ito ay nagti-trigger ng agarang paglisan ng mga pod na walang katumbas na entry tolerations.

Kapansin-pansin, ang pag-uugaling ito ay maaaring kanselahin gamit ang mekanismo ng pagpapaubaya. Maginhawa ito kapag mayroong "ipinagbabawal" na node at kailangan mo lamang maglagay ng mga serbisyo sa imprastraktura dito. Paano ito gagawin? Pahintulutan lamang ang mga pod kung saan mayroong angkop na pagpapaubaya.

Narito kung ano ang magiging hitsura ng detalye ng pod:

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

Hindi ito nangangahulugan na ang susunod na redeploy ay mahuhulog sa partikular na node na ito, hindi ito ang mekanismo ng Node Affinity at nodeSelector. Ngunit sa pamamagitan ng pagsasama-sama ng ilang feature, makakamit mo ang napaka-flexible na mga setting ng scheduler.

8. Itakda ang Pod Deployment Priority

Dahil lamang sa mayroon kang mga pod na nakatalaga sa mga node ay hindi nangangahulugan na ang lahat ng pod ay dapat tratuhin nang may parehong priyoridad. Halimbawa, maaaring gusto mong mag-deploy ng ilang pod bago ang iba.

Nag-aalok ang Kubernetes ng iba't ibang paraan para i-configure ang Pod Priority at Preemption. Ang setting ay binubuo ng ilang bahagi: object PriorityClass at mga paglalarawan sa larangan priorityClassName sa detalye ng pod. Tingnan natin ang isang halimbawa:

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"

Lumilikha kami PriorityClass, bigyan ito ng pangalan, paglalarawan at halaga. Ang mas mataas value, mas mataas ang priyoridad. Ang value ay maaaring maging anumang 32-bit integer na mas mababa sa o katumbas ng 1. Ang mas matataas na value ay nakalaan para sa mission-critical system pods na sa pangkalahatan ay hindi maaaring preempted. Ang paglilipat ay magaganap lamang kung ang isang mataas na priyoridad na pod ay walang lugar upang lumiko, pagkatapos ay ang ilan sa mga pod mula sa isang partikular na node ay ililikas. Kung ang mekanismong ito ay masyadong mahigpit para sa iyo, maaari mong idagdag ang opsyon preemptionPolicy: Never, at pagkatapos ay walang preemption, tatayo muna ang pod sa pila at hihintayin ang scheduler na makahanap ng mga libreng mapagkukunan para dito.

Susunod, lumikha kami ng isang pod kung saan ipinapahiwatig namin ang pangalan 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

Maaari kang lumikha ng maraming priyoridad na klase hangga't gusto mo, bagama't inirerekumenda na huwag madala dito (sabihin, limitahan ang iyong sarili sa mababa, katamtaman at mataas na priyoridad).

Kaya, kung kinakailangan, maaari mong dagdagan ang kahusayan ng pag-deploy ng mga kritikal na serbisyo tulad ng nginx-ingress-controller, coredns, atbp.

9. I-optimize ang ETCD cluster

Ang ETCD ay maaaring tawaging utak ng buong kumpol. Napakahalaga na mapanatili ang pagpapatakbo ng database na ito sa isang mataas na antas, dahil ang bilis ng mga operasyon sa Cube ay nakasalalay dito. Ang isang medyo pamantayan, at sa parehong oras, magandang solusyon ay upang panatilihin ang ETCD cluster sa mga master node upang magkaroon ng isang minimum na pagkaantala sa kube-apiserver. Kung hindi mo ito magagawa, ilagay ang ETCD nang mas malapit hangga't maaari, na may magandang bandwidth sa pagitan ng mga kalahok. Bigyang-pansin din kung gaano karaming mga node mula sa ETCD ang maaaring mahulog nang walang pinsala sa cluster

Tandaan na ang labis na pagtaas ng bilang ng mga miyembro sa isang cluster ay maaaring magpataas ng fault tolerance sa kapinsalaan ng performance, lahat ay dapat nasa moderation.

Kung pag-uusapan natin ang tungkol sa pag-set up ng serbisyo, may ilang mga rekomendasyon:

Magkaroon ng mahusay na hardware, batay sa laki ng kumpol (maaari mong basahin dito).
Mag-tweak ng ilang mga parameter kung nag-spread ka ng isang kumpol sa pagitan ng isang pares ng mga DC o ang iyong network at mga disk ay nag-iiwan ng maraming nais (maaari mong basahin dito).

Konklusyon

Inilalarawan ng artikulong ito ang mga puntong sinusubukang sundin ng aming team. Ito ay hindi isang sunud-sunod na paglalarawan ng mga aksyon, ngunit mga opsyon na maaaring maging kapaki-pakinabang para sa pag-optimize ng cluster overhead. Malinaw na ang bawat cluster ay natatangi sa sarili nitong paraan, at ang mga solusyon sa pagsasaayos ay maaaring mag-iba nang malaki, kaya magiging interesante na makuha ang iyong feedback sa kung paano mo sinusubaybayan ang iyong Kubernetes cluster at kung paano mo pinagbubuti ang pagganap nito. Ibahagi ang iyong karanasan sa mga komento, magiging kawili-wiling malaman.

Pinagmulan: www.habr.com

Siyam na Kubernetes Performance Tips