🥇Disa' pariri biex itejbu l-prestazzjoni ta' Kubernetes

Hi kollha! Jisimni Oleg Sidorenkov, naħdem f'DomClick bħala l-kap tat-tim tal-infrastruttura. Ilna nużaw Kubik fil-produzzjoni għal aktar minn tliet snin, u matul dan iż-żmien esperjenzajna ħafna mumenti interessanti differenti magħha. Illum se ngħidlek kif, bl-approċċ it-tajjeb, tista 'tagħfas saħansitra aktar prestazzjoni mill-vanilla Kubernetes għall-cluster tiegħek. Lest għaddej!

Intom ilkoll tafu tajjeb ħafna li Kubernetes hija sistema open source skalabbli għall-orkestrazzjoni tal-kontejners; sew, jew 5 binarji li jaħdmu maġija billi jimmaniġġjaw iċ-ċiklu tal-ħajja tal-mikroservizzi tiegħek f'ambjent ta 'server. Barra minn hekk, hija għodda pjuttost flessibbli li tista 'tiġi mmuntata bħal Lego għal customization massimu għal kompiti differenti.

U kollox jidher li hu tajjeb: itfa s-servers fil-cluster bħal ħatab ġo kaxxa tan-nar, u ma tkun taf l-ebda niket. Imma jekk inti favur l-ambjent, taħseb: "Kif nista 'nżomm in-nar jaħraq u nsalva l-foresta?" Fi kliem ieħor, kif issib modi kif ittejjeb l-infrastruttura u tnaqqas l-ispejjeż.

1. Tissorvelja r-riżorsi tat-tim u l-applikazzjoni

Wieħed mill-aktar metodi komuni, iżda effettivi huwa l-introduzzjoni ta' talbiet/limiti. Aqsam l-applikazzjonijiet bi namespaces, u namespaces minn timijiet ta 'żvilupp. Qabel l-iskjerament, issettja l-valuri tal-applikazzjoni għall-konsum tal-ħin tal-proċessur, il-memorja u l-ħażna effimera.

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

Permezz tal-esperjenza, wasalna għall-konklużjoni: m'għandekx tgħolli t-talbiet mil-limiti b'aktar minn darbtejn. Il-volum tar-raggruppament huwa kkalkulat abbażi tat-talbiet, u jekk tagħti lill-applikazzjonijiet differenza fir-riżorsi, pereżempju, 5-10 darbiet, imbagħad immaġina x'se jiġri min-node tiegħek meta jkun mimli bl-imżiewed u f'daqqa waħda jirċievi tagħbija. Xejn tajjeb. Bħala minimu, throttling, u massimu, int ser tgħid addiju lill-ħaddiem u tikseb tagħbija ċiklika fuq in-nodi li fadal wara li l-imżiewed jibdew jiċċaqilqu.

Barra minn hekk, bl-għajnuna limitranges Fil-bidu, tista 'tissettja valuri tar-riżorsi għall-kontenitur - minimi, massimi u 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

Tinsiex tillimita r-riżorsi tal-ispazju tal-isem sabiex tim wieħed ma jkunx jista' jieħu f'idejh ir-riżorsi kollha tal-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

Kif jidher mid-deskrizzjoni resourcequotas, jekk it-tim tal-ops irid juża pods li se jikkunsmaw 10 cpu oħra, l-iskedar mhux se jippermetti dan u se jarmi żball:

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

Biex issolvi problema bħal din, tista 'tikteb għodda, pereżempju, bħal dan, kapaċi jaħżnu u jimpenjaw ir-riżorsi tal-istat tal-kmand.

2. Agħżel il-ħażna tal-fajl ottimali

Hawnhekk nixtieq tmiss is-suġġett tal-volumi persistenti u s-subsistema tad-disk tan-nodi tal-ħaddiema Kubernetes. Nittama li ħadd ma juża l-"Cube" fuq HDD fil-produzzjoni, iżda kultant SSD regolari m'għadux biżżejjed. Iltqajna ma 'problema fejn ir-zkuk kienu qed joqtlu d-disk minħabba operazzjonijiet I/O, u m'hemmx ħafna soluzzjonijiet:

Uża SSDs ta' prestazzjoni għolja jew taqleb għal NVMe (jekk timmaniġġja l-ħardwer tiegħek).
Naqqas il-livell tal-qtugħ.
Agħmel ibbilanċjar "intelliġenti" tal-imżiewed li jistupru d-diska (podAntiAffinity).

L-iskrin ta 'hawn fuq juri x'jiġri taħt nginx-ingress-controller għad-diska meta l-illoggjar access_logs ikun attivat (~ 12 elf zkuk/sek). Din il-kundizzjoni, ovvjament, tista 'twassal għad-degradazzjoni tal-applikazzjonijiet kollha fuq dan in-node.

Fir-rigward tal-PV, sfortunatament, ma ppruvajtx kollox speċi Volumi Persistenti. Uża l-aħjar għażla li taqbel għalik. Storikament, ġara f'pajjiżna li parti żgħira mis-servizzi jeħtieġu volumi RWX, u żmien twil ilu bdew jużaw il-ħażna NFS għal dan il-kompitu. Irħis u... biżżejjed. Ovvjament, jien u hu kilna l-ħmieġ - bierkuk, imma tgħallimna nirranġawha, u rasi ma tweġġax aktar. U jekk possibbli, imxi għall-ħażna tal-oġġett S3.

3. Iġbor immaġini ottimizzati

L-aħjar huwa li tuża immaġini ottimizzati għall-kontejners sabiex Kubernetes ikun jista' jġibhom aktar malajr u jesegwixxihom b'mod aktar effiċjenti.

Ottimizzat ifisser li l-immaġini:

fihom applikazzjoni waħda biss jew iwettqu funzjoni waħda biss;
żgħar fid-daqs, minħabba li stampi kbar huma trażmessi agħar fuq in-netwerk;
ikollhom endpoints ta’ saħħa u prontezza li jippermettu lil Kubernetes jieħu azzjoni f’każ ta’ waqfien;
uża sistemi operattivi li jiffavorixxu l-kontejners (bħal Alpine jew CoreOS), li huma aktar reżistenti għall-iżbalji tal-konfigurazzjoni;
uża bini f'diversi stadji sabiex tkun tista' tuża biss applikazzjonijiet ikkumpilati u mhux is-sorsi li jakkumpanjawhom.

Hemm ħafna għodod u servizzi li jippermettulek tiċċekkja u tottimizza l-immaġini fuq il-fly. Huwa importanti li dejjem iżżommhom aġġornati u ttestjati għas-sigurtà. Bħala riżultat ikollok:

Tnaqqis tat-tagħbija tan-netwerk fuq il-cluster kollu.
Tnaqqis tal-ħin tal-istartjar tal-kontenitur.
Daqs iżgħar tar-reġistru Docker kollu tiegħek.

4. Uża DNS cache

Jekk nitkellmu dwar tagħbijiet għoljin, allura l-ħajja hija pjuttost ħażina mingħajr irfinar tas-sistema DNS tal-cluster. Darba, l-iżviluppaturi Kubernetes appoġġaw is-soluzzjoni kube-dns tagħhom. Ġie implimentat ukoll hawn, iżda dan is-software ma kienx partikolarment irranġat u ma pproduċiex il-prestazzjoni meħtieġa, għalkemm deher li kien kompitu sempliċi. Imbagħad dehru l-coredns, li qlibna għalihom u ma kellna l-ebda niket; aktar tard sar is-servizz DNS default fil-K8s. F'xi punt, aħna kiber għal 40 elf rps għas-sistema DNS, u din is-soluzzjoni wkoll saret insuffiċjenti. Iżda, b'xortih, ħareġ Nodelocaldns, aka node local cache, aka NodeLocal DNSCache.

Għaliex nużaw dan? Hemm bug fil-kernel tal-Linux li, meta sejħiet multipli permezz ta 'conntrack NAT fuq UDP, iwasslu għal kundizzjoni ta' tellieqa għal entrati fit-tabelli ta 'conntrack, u tintilef parti mit-traffiku permezz ta' NAT (kull vjaġġ permezz tas-Servizz huwa NAT). Nodelocaldns issolvi din il-problema billi jeħles minn NAT u jaġġorna l-konnessjoni ma 'TCP għal DNS upstream, kif ukoll caching lokalment mistoqsijiet DNS upstream (inkluż cache negattiv qasir ta' 5 sekondi).

5. Skala l-imżiewed orizzontalment u vertikalment awtomatikament

Tista' tgħid b'kunfidenza li l-mikroservizzi kollha tiegħek huma lesti għal żieda ta' darbtejn jew tliet darbiet fit-tagħbija? Kif talloka sew ir-riżorsi għall-applikazzjonijiet tiegħek? Iż-żamma ta 'koppja ta' mżiwed li jaħdmu lil hinn mill-piż tax-xogħol jista 'jkun żejjed, iżda ż-żamma tagħhom lura ma' dahar iġġib ir-riskju ta 'waqfien minn żieda f'daqqa fit-traffiku għas-servizz. Servizzi bħal Pod Autoscaler Orizzontali и Vertikali Pod Autoscaler.

VPA jippermettilek li awtomatikament tqajjem talbiet/limiti tal-kontenituri tiegħek fil-pod skont l-użu attwali. Kif jista’ jkun utli? Jekk għandek imżiewed li ma jistgħux jiġu skalati orizzontalment għal xi raġuni (li mhix kompletament affidabbli), allura tista 'tipprova tafda l-bidliet fir-riżorsi tagħha lill-VPA. Il-karatteristika tiegħu hija sistema ta’ rakkomandazzjoni bbażata fuq data storika u kurrenti mill-metric-server, għalhekk jekk ma tridx tbiddel awtomatikament it-talbiet/limiti, tista’ sempliċement tissorvelja r-riżorsi rakkomandati għall-kontenituri tiegħek u tottimizza s-settings biex issalva CPU u memorja fil-cluster.

Immaġni meħuda minn https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

L-iskeder f'Kubernetes huwa dejjem ibbażat fuq talbiet. Tkun xi tkun il-valur li tpoġġi hemmhekk, l-iskeder se jfittex node adattat ibbażat fuqu. Il-valuri tal-limiti huma meħtieġa biex il-cubelet jifhem meta throttle jew joqtol il-powd. U peress li l-uniku parametru importanti huwa l-valur tat-talbiet, il-VPA se jaħdem miegħu. Kull meta tiskala applikazzjoni vertikalment, tiddefinixxi x'għandhom ikunu t-talbiet. X'se jiġri mil-limiti allura? Dan il-parametru se jkun ukoll skalat proporzjonalment.

Pereżempju, hawn huma s-settings tas-soltu tal-pods:

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

Il-magna ta 'rakkomandazzjoni tiddetermina li l-applikazzjoni tiegħek teħtieġ 300m CPU u 500Mi biex taħdem sew. Int ser tirċievi s-settings li ġejjin:

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

Kif imsemmi hawn fuq, dan huwa skalar proporzjonali bbażat fuq il-proporzjon talbiet/limiti fil-manifest:

CPU: 200m → 300m: proporzjon 1:1.75;
Memorja: 250Mi → 500Mi: proporzjon 1:2.

Fir-rigward HPA, allura l-mekkaniżmu ta 'operazzjoni huwa aktar trasparenti. Metriċi bħal CPU u memorja huma thresholded, u jekk il-medja tar-repliki kollha taqbeż il-limitu, l-applikazzjoni tiġi skalata b'+1 sub sakemm il-valur jaqa 'taħt il-limitu jew sakemm jintlaħaq in-numru massimu ta' repliki.

Immaġni meħuda minn https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Minbarra l-metriċi tas-soltu bħal CPU u memorja, tista 'tissettja limiti fuq il-metriċi tad-dwana tiegħek minn Prometheus u taħdem magħhom jekk taħseb li dik hija l-indikazzjoni l-aktar preċiża ta' meta tiskala l-applikazzjoni tiegħek. Ladarba l-applikazzjoni tistabbilizza taħt il-limitu metriku speċifikat, l-HPA se tibda tiskala l-imżiewed 'l isfel għan-numru minimu ta' repliki jew sakemm it-tagħbija tilħaq il-limitu speċifikat.

6. Tinsiex dwar Node Affinity u Pod Affinity

Mhux in-nodi kollha jaħdmu fuq l-istess ħardwer, u mhux il-miżwed kollha jeħtieġ li jmexxu applikazzjonijiet li jagħmlu użu intensiv minn komputazzjoni. Kubernetes jippermettilek li tissettja l-ispeċjalizzazzjoni tan-nodi u l-imżiewed bl-użu Nodu Affinità и Pod Affinità.

Jekk għandek nodi li huma adattati għal operazzjonijiet intensivi ta 'komputazzjoni, allura għal effiċjenza massima huwa aħjar li torbot l-applikazzjonijiet man-nodi korrispondenti. Biex tagħmel dan uża nodeSelector b'tikketta node.

Ejja ngħidu li għandek żewġ nodi: wieħed bi CPUType=HIGHFREQ u numru kbir ta ' qlub veloċi, ieħor bil MemoryType=HIGHMEMORY aktar memorja u prestazzjoni aktar mgħaġġla. L-eħfef mod huwa li tassenja l-iskjerament għal nodu HIGHFREQbilli żżid mat-taqsima spec dan is-selettur:

…
nodeSelector:
	CPUType: HIGHFREQ

Mod aktar għali u speċifiku biex tagħmel dan huwa li tuża nodeAffinity fil-qasam affinity razdela spec. Hemm żewġ għażliet:

requiredDuringSchedulingIgnoredDuringExecution: iffissar iebes (l-iskedar se juża pods biss fuq nodi speċifiċi (u mkien ieħor));
preferredDuringSchedulingIgnoredDuringExecution: issettjar artab (l-iskeder se jipprova juża għal nodi speċifiċi, u jekk dan ifalli, jipprova juża għan-nodu disponibbli li jmiss).

Tista' tispeċifika sintassi speċifika għall-ġestjoni tat-tikketti tan-nodi, bħal In, NotIn, Exists, DoesNotExist, Gt jew Lt. Madankollu, ftakar li metodi kumplessi f'listi twal ta 'tikketti se jrażżnu t-teħid ta' deċiżjonijiet f'sitwazzjonijiet kritiċi. Fi kliem ieħor, żommha sempliċi.

Kif imsemmi hawn fuq, Kubernetes jippermettilek li tissettja l-affinità tal-miżwed attwali. Jiġifieri, tista 'tiżgura li ċerti imżiewed jaħdmu flimkien ma' mżiewed oħra fl-istess żona ta 'disponibbiltà (rilevanti għas-sħab) jew nodi.

В podAffinity marġini affinity razdela spec l-istess oqsma huma disponibbli bħal fil-każ ta nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. L-unika differenza hija li matchExpressions se jorbot il-miżwed ma 'node li diġà qed iħaddem pod b'dik it-tikketta.

Kubernetes joffri wkoll qasam podAntiAffinity, li, għall-kuntrarju, ma torbotx il-miżwed ma 'node b'imżiewed speċifiċi.

Dwar espressjonijiet nodeAffinity L-istess parir jista 'jingħata: ipprova żomm ir-regoli sempliċi u loġiċi, tippruvax tgħabbi żżejjed l-ispeċifikazzjoni tal-pod b'sett kumpless ta' regoli. Huwa faċli ħafna li tinħoloq regola li ma taqbilx mal-kundizzjonijiet tar-raggruppament, u toħloq tagħbija bla bżonn fuq l-iskeder u tnaqqas il-prestazzjoni ġenerali.

7. Taints & Tolleranzi

Hemm mod ieħor biex timmaniġġja l-iskedar. Jekk għandek raggruppament kbir b'mijiet ta 'nodi u eluf ta' mikroservizzi, allura huwa diffiċli ħafna li ma tippermettix li ċerti pods jiġu ospitati fuq ċerti nodi.

Il-mekkaniżmu ta’ tbajja—regoli li jipprojbixxu—jgħin f’dan. Pereżempju, f'ċerti xenarji tista' tipprojbixxi ċerti nodi milli jmexxu l-imżiewed. Biex tapplika t-tbajja għal nodu speċifiku trid tuża l-għażla taint f'kubectl. Speċifika ċ-ċavetta u l-valur u mbagħad taint simili NoSchedule jew NoExecute:

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

Ta 'min jinnota wkoll li l-mekkaniżmu ta' tbajja jappoġġja tliet effetti ewlenin: NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule ifisser li għalissa mhux se jkun hemm dħul korrispondenti fl-ispeċifikazzjoni tal-pod tolerations, mhux se jkun jista 'jiġi skjerat fuq in-node (f'dan l-eżempju node10).
PreferNoSchedule - verżjoni simplifikata NoSchedule. F'dan il-każ, l-iskeder jipprova ma jallokax imżiewed li m'għandhomx dħul li jaqblu tolerations għal kull node, iżda din mhix limitazzjoni iebsa. Jekk ma jkun hemm l-ebda riżorsi fil-cluster, allura l-imżiewed jibdew jintużaw fuq dan in-node.
NoExecute - dan l-effett jikkawża l-evakwazzjoni immedjata tal-imżiewed li m'għandhomx dħul korrispondenti tolerations.

Interessanti, din l-imġieba tista 'tiġi kkanċellata bl-użu tal-mekkaniżmu ta' tollerazzjonijiet. Dan huwa konvenjenti meta jkun hemm node "projbit" u għandek bżonn biss li tpoġġi s-servizzi tal-infrastruttura fuqu. Kif tagħmel dan? Ħalli biss dawk il-miżwed li għalihom hemm tolleranza xierqa.

Hawn kif tkun tidher l-ispeċifikazzjoni tal-pod:

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

Dan ma jfissirx li l-iskjerament mill-ġdid li jmiss se jaqa 'fuq dan in-node partikolari, dan mhuwiex il-mekkaniżmu Node Affinity u nodeSelector. Iżda billi tgħaqqad diversi karatteristiċi, tista 'tikseb settings ta' Scheduler flessibbli ħafna.

8. Issettja l-Prijorità tal-Iskjerament tal-Pods

Sempliċement għax għandek imżiewed assenjati lil nodi ma jfissirx li l-imżiewed kollha għandhom jiġu ttrattati bl-istess prijorità. Pereżempju, tista 'tkun trid tuża xi imżiewed qabel oħrajn.

Kubernetes joffri modi differenti biex jiġi kkonfigurat Pod Prijorità u Preemption. L-issettjar jikkonsisti f'diversi partijiet: oġġett PriorityClass u deskrizzjonijiet tal-qasam priorityClassName fl-ispeċifikazzjoni tal-pod. Ejja nħarsu lejn eżempju:

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"

Noħolqu PriorityClass, agħtiha isem, deskrizzjoni u valur. L-ogħla value, iktar tkun għolja l-prijorità. Il-valur jista 'jkun kwalunkwe numru sħiħ ta' 32 bit inqas minn jew ugwali għal 1 000 000 000. Valuri ogħla huma riżervati għall-imżiewed tas-sistema kritiċi għall-missjoni li ġeneralment ma jistgħux jiġu preemptati. L-ispostament iseħħ biss jekk pod ta 'prijorità għolja m'għandux post fejn idur, allura xi wħud mill-imżiewed minn ċertu nodu jiġu evakwati. Jekk dan il-mekkaniżmu huwa riġidu wisq għalik, tista 'żżid l-għażla preemptionPolicy: Never, u mbagħad ma jkun hemm l-ebda preemption, il-pod se joqgħod l-ewwel fil-kju u stenna li l-iskeduler isib riżorsi b'xejn għalih.

Sussegwentement, noħolqu pod li fih nindikaw l-isem 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

Tista 'toħloq klassijiet prijoritarji kemm trid, għalkemm huwa rakkomandat li ma titlaqx 'il bogħod minn dan (jiġifieri, tillimita lilek innifsek għal prijorità baxxa, medja u għolja).

Għalhekk, jekk meħtieġ, tista 'żżid l-effiċjenza tal-iskjerament ta' servizzi kritiċi bħal nginx-ingress-controller, coredns, eċċ.

9. Ottimizza l-cluster ETCD

ETCD jista 'jissejjaħ il-moħħ tal-cluster kollu. Huwa importanti ħafna li tinżamm l-operat ta 'din id-database f'livell għoli, peress li l-veloċità tal-operazzjonijiet f'Cube tiddependi minnha. Soluzzjoni pjuttost standard, u fl-istess ħin, tajba tkun li jinżamm il-cluster ETCD fuq in-nodi prinċipali sabiex ikun hemm dewmien minimu għall-kube-apiserver. Jekk ma tistax tagħmel dan, imbagħad poġġi l-ETCD qrib kemm jista 'jkun, b'bandwidth tajjeb bejn il-parteċipanti. Oqgħod attent ukoll għal kemm nodi minn ETCD jistgħu jaqgħu mingħajr ħsara lill-cluster

Żomm f'moħħok li ż-żieda eċċessiva tan-numru ta 'membri fi cluster tista' żżid it-tolleranza tal-ħsarat għad-detriment tal-prestazzjoni, kollox għandu jkun moderat.

Jekk nitkellmu dwar it-twaqqif tas-servizz, hemm ftit rakkomandazzjonijiet:

Ikollok ħardwer tajjeb, ibbażat fuq id-daqs tal-cluster (tista 'taqra hawn).
Tweek ftit parametri jekk inti xerred cluster bejn par ta 'DCs jew in-netwerk tiegħek u diski jħallu ħafna x'jixtieq (tista' taqra hawn).

Konklużjoni

Dan l-artikolu jiddeskrivi l-punti li t-tim tagħna jipprova jikkonforma magħhom. Din mhix deskrizzjoni pass pass tal-azzjonijiet, iżda għażliet li jistgħu jkunu utli għall-ottimizzazzjoni tal-overhead tal-cluster. Huwa ċar li kull cluster huwa uniku fil-mod tiegħu, u s-soluzzjonijiet ta 'konfigurazzjoni jistgħu jvarjaw ħafna, għalhekk ikun interessanti li tikseb ir-rispons tiegħek dwar kif timmonitorja l-cluster Kubernetes tiegħek u kif ittejjeb il-prestazzjoni tiegħu. Aqsam l-esperjenza tiegħek fil-kummenti, ikun interessanti li tkun taf.

Sors: www.habr.com

Disa' Suġġerimenti dwar il-Prestazzjoni ta' Kubernetes