🥇Siyam ka mga tip aron mapausbaw ang performance sa Kubernetes

Kumusta tanan! Ang akong ngalan mao si Oleg Sidorenkov, nagtrabaho ko sa DomClick isip lider sa team sa imprastraktura. Gigamit namo ang Cube alang sa pagbaligya sa sobra sa tulo ka tuig, ug niining panahona kami nakasinati og daghang lain-laing mga makapaikag nga mga higayon uban niini. Karon sultihan ko ikaw kung giunsa, sa husto nga pamaagi, mahimo nimong ipislit ang labi pa nga pasundayag gikan sa vanilla Kubernetes alang sa imong cluster. Andam makanunayong go!

Kamong tanan nahibal-an pag-ayo nga ang Kubernetes usa ka scalable nga open source system alang sa container orchestration; maayo, o 5 binary nga naghimo sa salamangka pinaagi sa pagdumala sa siklo sa kinabuhi sa imong mga microservice sa usa ka palibot sa server. Dugang pa, kini usa ka medyo flexible nga himan nga mahimong tipunon sama sa usa ka Lego constructor alang sa maximum customization alang sa lain-laing mga buluhaton.

Ug ang tanan ingon og maayo: ihulog ang mga server sa pungpong, sama sa sugnod sa usa ka firebox, ug wala mahibal-an ang kasubo. Apan kung ikaw alang sa kalikupan, unya maghunahuna ka: "Unsaon nako pagtipig ang kalayo sa stove ug magbasol sa lasang?". Sa laing pagkasulti, unsaon pagpangita og mga paagi aron mapaayo ang imprastraktura ug makunhuran ang gasto.

1. Pagsubay sa mga kapanguhaan sa team ug aplikasyon

Usa sa pinakabanal apan epektibo nga pamaagi mao ang pagpaila sa mga hangyo/limitasyon. Ibulag ang mga aplikasyon pinaagi sa mga namespace, ug mga namespace pinaagi sa mga development team. Itakda ang aplikasyon sa dili pa i-deploy ang mga kantidad alang sa pagkonsumo sa oras sa processor, memorya, ephemeral nga pagtipig.

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

Pinaagi sa kasinatian, nakaabot kami sa konklusyon: dili kini angay nga ipataas ang mga hangyo gikan sa mga limitasyon sa sobra sa duha ka beses. Ang gidaghanon sa cluster gikalkulo base sa mga hangyo, ug kung imong ibutang ang kalainan sa mga kahinguhaan sa mga aplikasyon, pananglitan, sa 5-10 ka beses, unya hunahunaa kung unsa ang mahitabo sa imong node kung kini mapuno sa mga pod ug kalit nga makadawat og load. . Walay maayo. Sa labing gamay, throttling, ug ingon sa usa ka maximum, panamilit sa trabahante ug pagkuha sa usa ka cyclic load sa uban nga mga nodes human sa pods magsugod sa paglihok.

Dugang pa, uban sa tabang limitranges mahimo nimong itakda ang mga kantidad sa kapanguhaan alang sa sulud sa pagsugod - minimum, maximum ug 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

Hinumdumi nga limitahan ang mga kapanguhaan sa namespace aron dili makuha sa usa ka mando ang tanan nga mga kapanguhaan sa 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

Sama sa imong makita gikan sa paghulagway resourcequotas, kung gusto sa ops command nga mag-deploy og mga pod nga mukonsumo og laing 10 nga cpu, nan ang scheduler dili motugot niini nga buhaton ug mag-isyu og sayop:

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

Aron masulbad ang parehas nga problema, mahimo ka magsulat usa ka himan, pananglitan, ingon kini, nga makatipig ug makatugyan sa kahimtang sa mga kapanguhaan sa mando.

2. Pilia ang labing maayo nga pagtipig sa file

Dinhi gusto nakong hisgotan ang hilisgutan sa padayon nga mga volume ug ang disk subsystem sa Kubernetes worker nodes. Nanghinaut ko nga walay usa nga naggamit sa "Cube" sa HDD sa produksyon, apan usahay bisan ang usa ka regular nga SSD dili na igo. Nag-atubang kami sa ingon nga problema nga ang mga troso nagpatay sa disk pinaagi sa mga operasyon sa I / O, ug wala’y daghang mga solusyon dinhi:

Gamit ug high-performance SSDs o switch sa NVMe (kung nagdumala ka sa imong kaugalingong hardware).
Ipaubos ang lebel sa logging.
Buhata ang "intelihenteng" pagbalanse sa mga pod nga nanglugos sa disk (podAntiAffinity).

Ang screenshot sa ibabaw nagpakita kung unsa ang mahitabo sa ilawom sa nginx-ingress-controller nga adunay usa ka disk kung ang access_logs gipagana (~ 12k logs / sec). Ang ingon nga kahimtang, siyempre, mahimong mosangput sa pagkadaot sa tanan nga mga aplikasyon sa kini nga node.

Bahin sa PV, sayang, wala pa nako nasulayan ang tanan. mga tan-aw Nagpadayon nga mga volume. Gamita ang pinakamaayo nga opsyon nga haum kanimo. Sa kasaysayan nahitabo sa atong nasud nga ang usa ka gamay nga bahin sa mga serbisyo nanginahanglan mga volume sa RWX, ug sa dugay na nga panahon nagsugod sila sa paggamit sa pagtipig sa NFS alang sa kini nga buluhaton. Barato ug ... igo. Siyempre, mikaon kami uban kaniya - mahimong himsog, apan nakakat-on kami unsaon sa pag-tune kaniya, ug ang iyang ulo dili na masakit. Ug kung mahimo, ibalhin sa pagtipig sa butang nga S3.

3. Paghimo og Optimized nga mga Imahen

Labing maayo nga gamiton ang mga imahe nga gi-optimize sa sulud aron makuha kini sa mga Kubernetes nga mas paspas ug mahimo kini nga mas episyente.

Ang pag-optimize nagpasabut nga ang mga imahe:

naglangkob lamang sa usa ka aplikasyon o pagbuhat lamang sa usa ka function;
gamay nga gidak-on, tungod kay ang dagkong mga imahe mas grabe nga gipasa sa network;
adunay mga endpoint sa kahimsog ug kaandam nga magamit sa Kubernetes aron molihok kung adunay oras sa paghunong;
gamita ang container-friendly nga mga operating system (sama sa Alpine o CoreOS) nga mas makasugakod sa mga sayop sa pag-configure;
gamita ang mga multi-stage build aron mahimo ra nimo nga i-deploy ang mga gihugpong nga aplikasyon ug dili ang kauban nga mga gigikanan.

Adunay daghang mga himan ug serbisyo nga nagtugot kanimo sa pagsusi ug pag-optimize sa mga imahe sa langaw. Importante nga kanunay kining ipadayon ug luwas. Ingon usa ka sangputanan, makuha nimo:

Gipakunhod ang load sa network sa tibuok cluster.
Gipakunhod ang oras sa pagsugod sa sudlanan.
Mas gamay nga gidak-on sa imong tibuok Docker registry.

4. Gamit ug DNS cache

Kung maghisgot kita bahin sa taas nga mga karga, kung wala’y pag-tune sa sistema sa DNS sa kumpol, ang kinabuhi labi ka daotan. Kaniadto, gisuportahan sa mga developer sa Kubernetes ang ilang solusyon sa kube-dns. Gipatuman usab kini sa atong nasud, apan kini nga software wala ilabi na nga nag-tune ug wala maghatag sa gikinahanglan nga pasundayag, bisan pa, ingon og, ang buluhaton yano ra. Unya mitungha ang mga coredns, diin mibalhin kami ug wala makahibalo sa kasubo, sa ulahi nahimo kini nga default nga serbisyo sa DNS sa K8s. Sa usa ka punto, kami nagdako hangtod sa 40 ka libo nga rps sa sistema sa DNS, ug kini nga solusyon dili usab igo. Apan, sa usa ka swerte nga higayon, ang Nodelocaldns migawas, aka node local cache, aka NodeLocal DNSCache.

Nganong gigamit nato kini? Adunay usa ka bug sa Linux kernel nga, kung daghang mga pag-access pinaagi sa conntrack NAT sa UDP, mosangpot sa usa ka kondisyon sa lumba alang sa pagsulat sa conntrack nga mga lamesa, ug ang bahin sa trapiko pinaagi sa NAT nawala (matag biyahe pinaagi sa Serbisyo mao ang NAT). Gisulbad sa Nodelocaldns kini nga problema pinaagi sa pagtangtang sa NAT ug pag-upgrade sa koneksyon sa TCP ngadto sa upstream DNS, ingon man ang pag-cache sa upstream nga DNS nga mga pangutana sa lokal (lakip ang mubo nga 5 segundos nga negatibo nga cache).

5. Awtomatikong i-scale ang mga pod sa horizontal ug vertically

Makasulti ka ba uban ang pagsalig nga ang tanan nimong microservice andam na alang sa duha hangtod tulo ka pilo nga pagtaas sa karga? Giunsa ang husto nga paggahin sa mga kapanguhaan sa imong mga aplikasyon? Ang pagpadayon sa usa ka pares nga mga pod nga nagdagan nga sobra sa kabug-at sa trabaho mahimo’g sobra, ug ang pagtago niini nga magbalikbalik adunay peligro nga pag-downtime gikan sa kalit nga pagtaas sa trapiko sa serbisyo. Ang bulawan nga kahulogan makatabang sa pagkab-ot sa spell sa pagpadaghan sa mga serbisyo sama sa Horizontal Pod Autoscaler и Vertical Pod Autoscaler.

VPA nagtugot kanimo sa awtomatikong pagpataas sa mga hangyo/limitasyon sa imong mga sudlanan sa usa ka pod base sa aktuwal nga paggamit. Sa unsang paagi kini mahimong mapuslanon? Kung ikaw adunay mga Pod nga sa usa ka hinungdan dili masukod nga pahalang (nga dili hingpit nga kasaligan), nan mahimo nimong sulayan ang pagsalig sa VPA nga usbon ang mga kahinguhaan niini. Ang bahin niini usa ka sistema sa rekomendasyon nga gibase sa makasaysayanon ug karon nga datos gikan sa metric-server, mao nga kung dili nimo gusto nga awtomatiko nga usbon ang mga hangyo/limitasyon, mahimo nimong bantayan ang girekomenda nga mga kapanguhaan alang sa imong mga sudlanan ug ma-optimize ang mga setting aron makatipig sa CPU ug memorya. sa cluster.

Ang hulagway gikuha gikan sa https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Ang scheduler sa Kubernetes kanunay gibase sa mga hangyo. Bisan unsa nga bili ang imong ibutang didto, ang scheduler mangita alang sa usa ka angay nga node base niini. Ang mga limitasyon nga kantidad gikinahanglan sa kublet aron mahibal-an kung kanus-a i-throttle o patyon ang usa ka pod. Ug tungod kay ang hinungdanon ra nga parameter mao ang kantidad sa mga hangyo, ang VPA molihok uban niini. Sa matag higayon nga imong sukdon ang imong aplikasyon nga patindog, imong gipasabut kung unsa ang mga hangyo. Ug unsa ang mahitabo sa mga limitasyon unya? Kini nga parameter mahimo usab nga proporsyonal nga sukdon.

Pananglitan, ania ang kasagarang mga setting sa pod:

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

Gitino sa makina sa rekomendasyon nga ang imong aplikasyon nanginahanglan 300m CPU ug 500Mi aron modagan sa husto. Makuha nimo kini nga mga setting:

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

Sama sa nahisgutan sa ibabaw, kini ang proporsyonal nga pag-scale base sa ratio sa mga hangyo / limitasyon sa gipakita:

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

Bahin sa HPA, unya ang mekanismo sa operasyon mas transparent. Ang mga sukaranan gitakda alang sa mga sukatan sama sa processor ug memorya, ug kung ang kasagaran sa tanan nga mga replika molapas sa threshold, nan ang aplikasyon nga mga timbangan sa +1 pod hangtod nga ang kantidad mahulog ubos sa threshold, o hangtod ang labing kadaghan nga mga replika maabot.

Ang hulagway gikuha gikan sa https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Dugang pa sa naandan nga mga sukatan sama sa CPU ug Memorya, mahimo nimong itakda ang mga threshold sa imong naandan nga sukatan sa Prometheus ug magtrabaho kauban nila kung gibati nimo nga kini ang labing tukma nga paagi aron mahibal-an kung kanus-a i-scale ang imong aplikasyon. Sa higayon nga ang aplikasyon mo-stabilize ubos sa espesipikong metric threshold, ang HPA magsugod sa pag-scale sa mga pods ngadto sa minimum nga gidaghanon sa mga replika o hangtud nga ang load makaabot sa piho nga threshold.

6. Ayaw Kalimti ang Bahin sa Node Affinity ug Pod Affinity

Dili tanan nga mga node nagdagan sa parehas nga hardware, ug dili tanan nga mga pod kinahanglan nga modagan sa compute-intensive nga mga aplikasyon. Gitugotan ka sa Kubernetes nga ipiho ang espesyalisasyon sa mga node ug pod nga gigamit Node Affinity и Pod Affinity.

Kung ikaw adunay mga node nga angay alang sa compute-intensive nga mga operasyon, nan alang sa labing taas nga kahusayan, mas maayo nga ibugkos ang mga aplikasyon sa angay nga mga node. Aron mahimo kini, gamita nodeSelector nga adunay label sa node.

Ingnon ta nga ikaw adunay duha ka node: ang usa adunay CPUType=HIGHFREQ ug usa ka dako nga gidaghanon sa paspas nga mga core, lain nga adunay MemoryType=HIGHMEMORY dugang nga memorya ug mas paspas nga performance. Ang pinakasayon nga paagi mao ang pag-assign og pod deployment sa usa ka node HIGHFREQpinaagi sa pagdugang sa seksyon spec usa ka tigpili sama niini:

…
nodeSelector:
	CPUType: HIGHFREQ

Ang mas mahal ug espesipikong paagi sa pagbuhat niini mao ang paggamit nodeAffinity sa uma affinity seksyon spec. Adunay duha ka kapilian:

requiredDuringSchedulingIgnoredDuringExecution: lisud nga setting (ang scheduler mag-deploy lamang sa mga pod sa piho nga mga node (ug wala nay lain));
preferredDuringSchedulingIgnoredDuringExecution: humok nga setting (ang scheduler mosulay sa pag-deploy sa piho nga mga node, ug kung kini mapakyas, kini mosulay sa pag-deploy sa sunod nga magamit nga node).

Mahimo nimong itakda ang usa ka piho nga syntax alang sa pagdumala sa mga label sa node, pananglitan, In, NotIn, Exists, DoesNotExist, Gt o Lt. Bisan pa, hinumdomi nga ang komplikado nga mga pamaagi sa taas nga mga lista sa mga label makapahinay sa paghimog desisyon sa mga kritikal nga sitwasyon. Sa laing pagkasulti, ayaw pagpakomplikado.

Sama sa gihisgutan sa ibabaw, gitugotan ka sa Kubernetes nga itakda ang pagbugkos sa mga karon nga pod. Kana mao, mahimo nimong himoon ang pipila ka mga pod nga magtrabaho kauban ang ubang mga pod sa parehas nga availability zone (relevant for clouds) o nodes.

В podAffinity kapatagan affinity seksyon spec ang parehas nga mga natad magamit sama sa kaso sa nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Ang bugtong kalainan mao kana matchExpressions igapos ang mga pod sa usa ka node nga nagpadagan na sa usa ka pod nga adunay label.

Daghang Kubernetes ang nagtanyag og field podAntiAffinity, nga, sa kasukwahi, wala magbugkos sa usa ka pod sa usa ka node nga adunay piho nga mga pod.

Mahitungod sa mga ekspresyon nodeAffinity parehas nga tambag ang mahatag: paningkamuti nga huptan ang mga lagda nga yano ug lohikal, ayaw pagsulay sa pag-overload sa detalye sa pod nga adunay usa ka komplikado nga hugpong sa mga lagda. Sayon ra kaayo ang paghimo og usa ka lagda nga dili motakdo sa mga kondisyon sa cluster, pagbutang og dugang nga load sa scheduler ug makapaubos sa kinatibuk-ang performance.

7. Mga Mantsa ug mga Pagtugot

Adunay laing paagi sa pagdumala sa scheduler. Kung ikaw adunay usa ka dako nga cluster nga adunay gatusan ka mga node ug liboan nga mga microservice, lisud kaayo nga mapugngan ang pipila ka mga pod nga ma-host sa pipila ka mga node.

Ang mekanismo sa mga hugaw - nagdili sa mga lagda - makatabang niini. Pananglitan, mahimo nimong mapugngan ang pipila ka mga node sa pagpadagan sa mga pod sa pipila ka mga senaryo. Aron magamit ang taint sa usa ka piho nga node, gamita ang kapilian taint sa kubectl. Ipiho ang yawe ug bili ug dayon hugaw sama NoSchedule o NoExecute:

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

Angay usab nga matikdan nga ang mekanismo sa taint nagsuporta sa tulo ka mga nag-unang epekto: NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule nagpasabot nga hangtud adunay katugbang nga entry sa pod specification tolerations, dili kini ma-deploy sa node (sa kini nga pananglitan node10).
PreferNoSchedule - gipasimple nga bersyon NoSchedule. Sa kini nga kaso, ang scheduler mosulay sa dili paggahin pod nga walay usa ka matching entry. tolerations matag node, apan dili kini lisud nga limitasyon. Kung walay mga kahinguhaan sa cluster, ang mga pod magsugod sa pag-deploy niini nga node.
NoExecute - kini nga epekto magpahinabog hinanaling pagbakwit sa mga pod nga walay katugbang nga entry tolerations.

Katingad-an, kini nga pamatasan mahimong mabawi gamit ang mekanismo sa pagtugot. Kombenyente kini kung adunay "gidili" nga node ug kinahanglan nimo nga ibutang lamang ang mga serbisyo sa imprastraktura niini. Unsaon pagbuhat niini? Itugot lamang ang mga pod nga adunay angay nga pagtugot.

Ania kung unsa ang hitsura sa pod spec:

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

Wala kini magpasabot nga sa sunod nga pag-redeploy, ang pod moigo gayud niini nga node, dili kini ang mekanismo sa Node Affinity ug nodeSelector. Apan pinaagi sa paghiusa sa daghang mga bahin, mahimo nimong makab-ot ang usa ka labi ka dali nga pag-setup sa scheduler.

8. Itakda ang Pod Deployment Priority

Tungod lang kay imong gi-configure ang pod-to-node bindings wala magpasabot nga ang tanang pods kinahanglang trataron sa samang prayoridad. Pananglitan, mahimo nimong i-deploy ang pipila ka mga Pod una sa uban.

Ang Kubernetes nagtanyag ug lain-laing mga paagi sa pagtakda sa Pod Priority ug Preemption. Ang setting naglangkob sa daghang mga bahin: butang PriorityClass ug mga paghulagway sa uma priorityClassName sa pod specification. Tagda ang usa ka pananglitan:

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"

Kami nagmugna PriorityClass, hatagi kini og ngalan, deskripsyon, ug bili. Ang labi ka taas value, mas taas ang prayoridad. Ang kantidad mahimong bisan unsang 32-bit integer nga ubos o katumbas sa 1. Ang mas taas nga mga kantidad gireserba alang sa mission-critical system pods, nga kasagarang dili ma-preempted. Ang pagpalayas mahitabo lamang kung ang taas nga prayoridad nga pod walay bisan asa nga makalingi, unya ang pipila sa mga pod gikan sa usa ka partikular nga node ibakwit. Kung kini nga mekanismo estrikto kaayo alang kanimo, mahimo nimong idugang ang kapilian preemptionPolicy: Never, ug unya wala nay preemption, ang pod mao ang una sa pila ug maghulat sa scheduler nga makapangita ug libre nga mga kapanguhaan alang niini.

Sunod, maghimo kami usa ka pod, diin among gitino ang ngalan 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

Makahimo ka og daghang mga klase sa prayoridad nga gusto nimo, bisan kung girekomenda nga dili madala niini (ingon, limitahan ang imong kaugalingon sa ubos, medium ug taas nga prayoridad).

Sa ingon, kung gikinahanglan, mahimo nimong madugangan ang kaepektibo sa pag-deploy sa mga kritikal nga serbisyo, sama sa nginx-ingress-controller, coredns, ug uban pa.

9. I-optimize ang imong ETCD cluster

Ang ETCD matawag nga utok sa tibuok cluster. Importante kaayo ang pagpadayon sa operasyon niini nga database sa taas nga lebel, tungod kay ang katulin sa mga operasyon sa "Cube" nagdepende niini. Usa ka patas nga sumbanan, ug sa samang higayon, usa ka maayong solusyon mao ang pagtipig sa usa ka ETCD cluster sa mga master node aron adunay usa ka minimum nga paglangan sa kube-apiserver. Kung dili kini mahimo, unya ibutang ang ETCD sa labing duol nga mahimo, nga adunay maayo nga bandwidth tali sa mga partisipante. Hatagi usab ug pagtagad kung pila ka mga node gikan sa ETCD ang mahimong mahulog nga dili makadaot sa cluster.

Hinumdomi nga ang sobra nga pagtaas sa gidaghanon sa mga partisipante sa cluster makadugang sa fault tolerance sa gasto sa performance, ang tanan kinahanglan nga kasarangan.

Kung maghisgot kami bahin sa pag-set up sa serbisyo, nan adunay pipila nga mga rekomendasyon:

Pagbaton og maayo nga hardware, base sa gidak-on sa cluster (mahimo nimong basahon dinhi).
Pag-tweak og pipila ka mga parameter kung nagsabwag ka og cluster tali sa usa ka parisan sa DCs o sa imong network ug mga disk nga daghan ang gusto (mahimo nimong basahon dinhi).

konklusyon

Gihubit niini nga artikulo ang mga punto nga gipaningkamotan sa among team nga sundon. Dili kini usa ka sunod-sunod nga paghulagway sa mga aksyon, apan mga kapilian nga mahimong mapuslanon aron ma-optimize ang overhead sa usa ka cluster. Klaro nga ang matag cluster talagsaon sa kaugalingon nga paagi, ug ang mga solusyon sa pag-tune mahimong magkalahi kaayo, mao nga makapainteres nga makakuha og feedback gikan kanimo: unsaon nimo pagmonitor ang imong Kubernetes cluster, unsaon nimo pagpalambo ang performance niini. Ipakigbahin ang imong kasinatian sa mga komento, kini makapaikag nga mahibal-an kini.

Source: www.habr.com

Siyam ka Kubernetes Performance Tips