Helo pawb! Fy enw i yw Oleg Sidorenkov, rwy'n gweithio yn DomClick fel arweinydd tîm seilwaith. Rydym wedi bod yn defnyddio'r Ciwb ar werth am fwy na thair blynedd, ac yn ystod y cyfnod hwn rydym wedi profi llawer o wahanol eiliadau diddorol ag ef. Heddiw dywedaf wrthych sut, gyda'r dull cywir, y gallwch chi wasgu hyd yn oed mwy o berfformiad allan o Kubernetes fanila ar gyfer eich clwstwr. Parod yn raddol fynd!
Rydych chi i gyd yn gwybod yn iawn bod Kubernetes yn system ffynhonnell agored scalable ar gyfer offeryniaeth cynwysyddion; wel, neu 5 deuaidd sy'n gwneud hud trwy reoli cylch bywyd eich microwasanaethau mewn amgylchedd gweinydd. Yn ogystal, mae hwn yn offeryn eithaf hyblyg y gellir ei ymgynnull fel adeiladwr Lego i'w addasu i'r eithaf ar gyfer gwahanol dasgau.
Ac mae'n ymddangos bod popeth yn iawn: taflwch weinyddion i'r clwstwr, fel coed tân i mewn i flwch tân, a ddim yn gwybod galar. Ond os ydych chi dros yr amgylchedd, yna byddwch chi'n meddwl: "Sut alla i gadw'r tân yn y stôf a difaru'r goedwig?". Mewn geiriau eraill, sut i ddod o hyd i ffyrdd o wella seilwaith a lleihau costau.
1. Cadw golwg ar adnoddau tîm a chymhwysiad
Un o'r dulliau mwyaf gwaharddol ond effeithiol yw cyflwyno ceisiadau/cyfyngiadau. Cymwysiadau ar wahân yn ôl gofodau enwau, a gofodau enwau gan dimau datblygu. Gosodwch y cymhwysiad cyn defnyddio gwerthoedd ar gyfer defnyddio amser prosesydd, cof, storio byrhoedlog.
resources:
requests:
memory: 2Gi
cpu: 250m
limits:
memory: 4Gi
cpu: 500mTrwy brofiad, daethom i'r casgliad: nid yw'n werth chwyddo ceisiadau o derfynau fwy na dwywaith. Mae maint y clwstwr yn cael ei gyfrifo yn seiliedig ar geisiadau, ac os ydych chi'n gosod y cais i wahaniaeth mewn adnoddau, er enghraifft, 5-10 gwaith, yna dychmygwch beth fydd yn digwydd i'ch nod pan fydd yn llawn codennau ac yn derbyn llwyth yn sydyn. Dim byd da. Ar y lleiaf, throtlo, ac fel uchafswm, ffarwelio â'r gweithiwr a chael llwyth cylchol ar weddill y nodau ar ôl i'r codennau ddechrau symud.
Yn ogystal, gyda chymorth limitranges gallwch osod gwerthoedd adnoddau ar gyfer y cynhwysydd ar y cychwyn - lleiafswm, uchafswm a rhagosodedig:
➜ ~ 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 2Cofiwch gyfyngu ar yr adnoddau gofod enwau fel na all un gorchymyn gymryd holl adnoddau'r clwstwr:
➜ ~ 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 0Fel y gwelwch o'r disgrifiad resourcequotas, os yw'r gorchymyn ops eisiau defnyddio codennau a fydd yn defnyddio 10 cpu arall, yna ni fydd y trefnydd yn caniatáu iddo gael ei wneud a bydd yn cyhoeddi gwall:
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=10I ddatrys problem debyg, gallwch ysgrifennu offeryn, er enghraifft, fel , sy'n gallu storio ac ymrwymo cyflwr adnoddau gorchymyn.
2. Dewiswch y storfa ffeiliau orau
Yma hoffwn gyffwrdd â phwnc cyfrolau parhaus ac is-system ddisg nodau gweithwyr Kubernetes. Rwy'n gobeithio nad oes neb yn defnyddio'r "Cube" ar y HDD wrth gynhyrchu, ond weithiau nid yw hyd yn oed SSD rheolaidd eisoes yn ddigon. Roeddem yn wynebu cymaint o broblem nes bod y boncyffion yn lladd y ddisg gan weithrediadau I / O, ac nid oes llawer o atebion yma:
-
Defnyddiwch SSDs perfformiad uchel neu newidiwch i NVMe (os ydych chi'n rheoli'ch caledwedd eich hun).
-
Gostwng lefel y logio.
-
Cydbwyso codennau sy'n treisio'r ddisg yn "smart" (
podAntiAffinity).
Mae'r sgrinlun uchod yn dangos beth sy'n digwydd o dan nginx-ingress-controller gyda disg pan fydd access_logs wedi'i alluogi (~ 12k logs / eiliad). Gall cyflwr o'r fath, wrth gwrs, arwain at ddiraddio pob cais ar y nod hwn.
O ran PV, gwaetha'r modd, nid wyf wedi rhoi cynnig ar bopeth. Cyfrolau parhaus. Defnyddiwch yr opsiwn gorau sy'n addas i chi. Mae wedi digwydd yn hanesyddol yn ein gwlad bod angen cyfeintiau RWX ar ran fach o wasanaethau, ac amser maith yn ôl dechreuon nhw ddefnyddio storfa NFS ar gyfer y dasg hon. Rhad a ... digon. Wrth gwrs, fe wnaethon ni fwyta cachu gydag ef - byddwch yn iach, ond dysgon ni sut i'w diwnio, ac nid yw ei ben yn brifo mwyach. Ac os yn bosibl, newidiwch i storfa gwrthrychau S3.
3. Adeiladu Delweddau Optimized
Mae'n well defnyddio delweddau wedi'u optimeiddio mewn cynhwysydd fel y gall Kubernetes eu nôl yn gyflymach a'u gweithredu'n fwy effeithlon.
Mae optimeiddio yn golygu bod delweddau:
-
cynnwys dim ond un cymhwysiad neu gyflawni un swyddogaeth yn unig;
-
maint bach, oherwydd bod delweddau mawr yn cael eu trosglwyddo'n waeth dros y rhwydwaith;
-
bod â phwyntiau terfyn iechyd a pharodrwydd y gall Kubernetes eu defnyddio i weithredu os bydd amser segur;
-
defnyddio systemau gweithredu sy'n gyfeillgar i gynwysyddion (fel Alpaidd neu CoreOS) sy'n gallu gwrthsefyll gwallau ffurfweddu yn well;
-
defnyddiwch adeiladau aml-gam fel mai dim ond cymwysiadau wedi'u crynhoi y gallwch eu defnyddio ac nid y ffynonellau cysylltiedig.
Mae yna lawer o offer a gwasanaethau sy'n eich galluogi i wirio a gwneud y gorau o ddelweddau ar y hedfan. Mae'n bwysig eu cadw'n gyfredol ac yn ddiogel bob amser. O ganlyniad, byddwch yn cael:
-
Llwyth rhwydwaith llai ar y clwstwr cyfan.
-
Llai o amser cychwyn cynhwysydd.
-
Maint llai eich cofrestrfa Docker gyfan.
4. Defnyddiwch storfa DNS
Os ydym yn siarad am lwythi uchel, yna heb diwnio system DNS y clwstwr, mae bywyd yn eithaf lousy. Un tro, cefnogodd datblygwyr Kubernetes eu datrysiad kube-dns. Fe'i gweithredwyd hefyd yn ein gwlad, ond nid oedd y feddalwedd hon yn arbennig o diwnio ac nid oedd yn rhoi'r perfformiad gofynnol, er, mae'n ymddangos, mae'r dasg yn syml. Yna ymddangosodd coredns, y gwnaethom newid iddo ac nid oeddem yn gwybod am alar, yn ddiweddarach daeth yn wasanaeth DNS diofyn yn K8s. Ar ryw adeg, fe wnaethom dyfu hyd at 40 mil rps i'r system DNS, ac nid oedd yr ateb hwn hefyd yn ddigon. Ond, yn ffodus, daeth Nodelocaldns allan, aka node local cache, aka .
Pam ydym ni'n ei ddefnyddio? Mae nam yn y cnewyllyn Linux, pan fydd mynediad lluosog trwy conntrack NAT dros CDU, yn arwain at amod rasio ar gyfer ysgrifennu at y tablau conntrack, a bod rhan o'r traffig trwy NAT yn cael ei golli (mae pob taith trwy'r Gwasanaeth yn NAT). Mae Nodelocaldns yn datrys y broblem hon trwy gael gwared ar NAT ac uwchraddio i gysylltedd TCP i DNS i fyny'r afon, yn ogystal â chadw ymholiadau DNS i fyny'r afon yn lleol (gan gynnwys storfa negyddol 5 eiliad byr).
5. Graddio codennau yn llorweddol ac yn fertigol yn awtomatig
A allwch ddweud yn hyderus bod eich holl ficrowasanaethau yn barod ar gyfer cynnydd o ddau i driphlyg yn y llwyth? Sut i ddyrannu adnoddau'n briodol i'ch ceisiadau? Gall fod yn ddiangen cadw ychydig o godennau i redeg dros y llwyth gwaith, ac mae eu cadw gefn wrth gefn yn peryglu amser segur oherwydd cynnydd sydyn yn y traffig i'r gwasanaeth. Mae'r cymedr aur yn helpu i gyflawni'r cyfnod o luosi gwasanaethau fel и .
VPA yn caniatáu ichi godi ceisiadau / terfynau eich cynwysyddion yn awtomatig mewn pod yn seiliedig ar ddefnydd gwirioneddol. Sut gall fod yn ddefnyddiol? Os oes gennych Podiau na ellir eu graddio'n llorweddol am ryw reswm (nad yw'n gwbl ddibynadwy), yna gallwch geisio ymddiried yn VPA i newid ei adnoddau. Ei nodwedd yw system argymell sy'n seiliedig ar ddata hanesyddol a chyfredol o'r gweinydd metrig, felly os nad ydych am newid ceisiadau / terfynau yn awtomatig, gallwch fonitro'r adnoddau a argymhellir ar gyfer eich cynwysyddion a gwneud y gorau o'r gosodiadau i arbed CPU a chof yn y clwstwr.
Delwedd a gymerwyd o https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Mae'r amserlennydd yn Kubernetes bob amser yn seiliedig ar geisiadau. Pa bynnag werth a roddwch yno, bydd y trefnydd yn chwilio am nod addas yn seiliedig arno. Mae angen y gwerth terfyn ar y kublet er mwyn gwybod pryd i sbardunu neu ladd codennau. A chan mai'r unig baramedr pwysig yw gwerth y ceisiadau, bydd VPA yn gweithio gydag ef. Pryd bynnag y byddwch chi'n graddio'ch cais yn fertigol, rydych chi'n diffinio pa geisiadau ddylai fod. A beth fydd yn digwydd i derfynau wedyn? Bydd y paramedr hwn hefyd yn cael ei raddio'n gymesur.
Er enghraifft, dyma'r gosodiadau pod nodweddiadol:
resources:
requests:
memory: 250Mi
cpu: 200m
limits:
memory: 500Mi
cpu: 350mMae'r peiriant argymell yn pennu bod angen 300m CPU a 500Mi ar eich cais i redeg yn iawn. Byddwch yn cael y gosodiadau hyn:
resources:
requests:
memory: 500Mi
cpu: 300m
limits:
memory: 1000Mi
cpu: 525mFel y soniwyd uchod, mae hwn yn raddfa gymesur yn seiliedig ar y gymhareb ceisiadau/terfynau yn y maniffest:
-
CPU: 200m → 300m: cymhareb 1:1.75;
-
Cof: 250Mi → cymhareb 500Mi: 1:2.
O ran HPA, yna mae'r mecanwaith gweithredu yn fwy tryloyw. Mae trothwyon yn cael eu gosod ar gyfer metrigau fel prosesydd a chof, ac os yw cyfartaledd yr holl atgynhyrchiadau yn fwy na'r trothwy, yna mae'r cais yn graddio o +1 pod nes bod y gwerth yn disgyn o dan y trothwy, neu hyd nes y cyrhaeddir y nifer uchaf o atgynyrchiadau.
Delwedd a gymerwyd o https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Yn ogystal â'r metrigau arferol fel CPU a Memory, gallwch osod trothwyon ar eich metrigau Prometheus arferol a gweithio gyda nhw os ydych chi'n teimlo mai dyma'r ffordd fwyaf cywir i benderfynu pryd i raddio'ch cais. Unwaith y bydd y cais yn sefydlogi o dan y trothwy metrig penodedig, bydd HPA yn dechrau graddio'r codennau i lawr i'r nifer lleiaf o atgynyrchiadau neu nes bod y llwyth yn cyrraedd y trothwy penodedig.
6. Peidiwch ag Anghofio Am Affinedd Nodau ac Affinedd Pod
Nid yw pob nod yn rhedeg ar yr un caledwedd, ac nid oes angen i bob cod redeg cymwysiadau cyfrifiadurol-ddwys. Mae Kubernetes yn caniatáu ichi nodi arbenigedd nodau a chodau gan ddefnyddio Affinedd Nôd и Pod Affinedd.
Os oes gennych nodau sy'n addas ar gyfer gweithrediadau cyfrifiadurol-ddwys, yna er mwyn sicrhau'r effeithlonrwydd mwyaf, mae'n well rhwymo cymwysiadau i'r nodau priodol. I wneud hyn, defnyddiwch nodeSelector gyda label nod.
Gadewch i ni ddweud bod gennych ddau nod: un gyda CPUType=HIGHFREQ a nifer fawr o greiddiau cyflym, un arall gyda MemoryType=HIGHMEMORY mwy o gof a pherfformiad cyflymach. Y ffordd hawsaf yw neilltuo gosodiad pod i nod HIGHFREQtrwy ychwanegu at yr adran spec dewisydd fel hyn:
…
nodeSelector:
CPUType: HIGHFREQFfordd fwy costus a phenodol o wneud hyn yw defnyddio nodeAffinity yn y maes affinity adran spec. Mae dau opsiwn:
-
requiredDuringSchedulingIgnoredDuringExecution: gosodiad caled (bydd yr amserlennydd ond yn defnyddio codennau ar nodau penodol (ac yn unman arall)); -
preferredDuringSchedulingIgnoredDuringExecution: gosodiad meddal (bydd y trefnydd yn ceisio ei ddefnyddio i nodau penodol, ac os bydd yn methu, bydd yn ceisio ei ddefnyddio i'r nod nesaf sydd ar gael).
Gallwch nodi cystrawen benodol ar gyfer rheoli labeli nodau, er enghraifft, In, NotIn, Exists, DoesNotExist, Gt neu Lt. Fodd bynnag, cofiwch y bydd dulliau cymhleth mewn rhestrau hir o labeli yn arafu'r broses o wneud penderfyniadau mewn sefyllfaoedd argyfyngus. Mewn geiriau eraill, peidiwch â gor-gymhlethu.
Fel y soniwyd uchod, mae Kubernetes yn caniatáu ichi osod rhwymiad codennau cyfredol. Hynny yw, gallwch chi wneud i godenni penodol weithio gyda'i gilydd â chodau eraill yn yr un parth argaeledd (sy'n berthnasol ar gyfer cymylau) neu nodau.
В podAffinity caeau affinity adran spec mae'r un meysydd ar gael ag yn achos nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Yr unig wahaniaeth yw hynny matchExpressions yn rhwymo codennau i nod sydd eisoes yn rhedeg pod gyda'r label hwnnw.
Mwy o Kubernetes yn cynnig maes podAntiAffinity, nad yw, mewn cyferbyniad, yn rhwymo pod i nôd gyda chodennau penodol.
Am ymadroddion nodeAffinity Gellir rhoi'r un cyngor: ceisiwch gadw'r rheolau yn syml ac yn rhesymegol, peidiwch â cheisio gorlwytho manyleb y pod gyda set gymhleth o reolau. Mae'n hawdd iawn creu rheol nad yw'n cyd-fynd ag amodau'r clwstwr, gan roi llwyth ychwanegol ar y rhaglennydd a diraddio perfformiad cyffredinol.
7. Llygredd a Goddefiadau
Mae ffordd arall o reoli'r trefnydd. Os oes gennych glwstwr mawr gyda channoedd o nodau a miloedd o ficrowasanaethau, mae'n anodd iawn atal rhai codennau rhag cael eu cynnal gan nodau penodol.
Mae mecanwaith llygru - rheolau gwahardd - yn helpu gyda hyn. Er enghraifft, gallwch atal rhai nodau rhag rhedeg codennau mewn rhai senarios. I roi lliw ar nod penodol, defnyddiwch yr opsiwn taint yn kubectl. Nodwch allwedd a gwerth ac yna lliwiwch fel NoSchedule neu NoExecute:
$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoScheduleMae'n werth nodi hefyd bod y mecanwaith llygru yn cefnogi tri phrif effaith: NoSchedule, NoExecute и PreferNoSchedule.
-
NoScheduleyn golygu nes bod cofnod cyfatebol yn y fanyleb podtolerations, ni ellir ei ddefnyddio i'r nod (yn yr enghraifft honnode10). -
PreferNoSchedule- fersiwn symlachNoSchedule. Yn yr achos hwn, bydd y trefnydd yn ceisio peidio â dyrannu codennau nad oes ganddynt gofnod cyfatebol.tolerationsfesul nod, ond nid yw hwn yn derfyn caled. Os nad oes adnoddau yn y clwstwr, yna bydd y codennau'n dechrau eu defnyddio ar y nod hwn. -
NoExecute- mae'r effaith hon yn sbarduno gwacáu codennau nad oes ganddynt gofnod cyfateboltolerations.
Yn rhyfedd iawn, gellir dadwneud yr ymddygiad hwn gan ddefnyddio'r mecanwaith goddefgarwch. Mae hyn yn gyfleus pan fo nod “gwaharddedig” a bod angen i chi osod gwasanaethau seilwaith yn unig arno. Sut i'w wneud? Caniatewch dim ond y codennau hynny y mae goddefgarwch addas ar eu cyfer.
Dyma sut olwg fyddai ar y pod spec:
spec:
tolerations:
- key: "node-role.kubernetes.io/ingress"
operator: "Equal"
value: "true"
effect: "NoSchedule"Nid yw hyn yn golygu, yn ystod yr adleoli nesaf, y bydd y pod yn taro'r nod hwn yn union, nid dyma'r mecanwaith Affinedd Node a nodeSelector. Ond trwy gyfuno sawl nodwedd, gallwch chi gyflawni gosodiad amserlennu hyblyg iawn.
8. Gosod Blaenoriaeth Gosod Podiau
Nid yw'r ffaith eich bod wedi ffurfweddu rhwymiadau pod-i-nôd yn golygu y dylai pob cod gael ei drin â'r un flaenoriaeth. Er enghraifft, efallai y byddwch am ddefnyddio rhai Podiau cyn eraill.
Mae Kubernetes yn cynnig gwahanol ffyrdd o osod Blaenoriaeth Pod a Rhagbryniant. Mae'r gosodiad yn cynnwys sawl rhan: gwrthrych PriorityClass a disgrifiadau maes priorityClassName yn y fanyleb pod. Ystyriwch enghraifft:
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"Rydym yn creu PriorityClass, rhowch enw, disgrifiad, a gwerth iddo. Po uchaf value, po uchaf yw'r flaenoriaeth. Gall y gwerth fod yn unrhyw gyfanrif 32-did yn llai na neu'n hafal i 1. Cedwir gwerthoedd uwch ar gyfer codennau system sy'n hanfodol i genhadaeth, na ellir eu rhag-atal fel arfer. Dim ond os nad oes gan y cod blaenoriaeth uchel unrhyw le i droi o gwmpas y bydd y dadfeddiant yn digwydd, yna bydd rhai o'r codennau o nod penodol yn cael eu gwacáu. Os yw'r mecanwaith hwn yn rhy anhyblyg i chi, yna gallwch chi ychwanegu'r opsiwn preemptionPolicy: Never, ac yna ni fydd unrhyw preemption, y pod fydd y cyntaf yn y ciw ac aros i'r trefnydd ddod o hyd i adnoddau am ddim ar ei gyfer.
Nesaf, rydyn ni'n creu pod, lle rydyn ni'n nodi'r enw 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
Gallwch greu cymaint o ddosbarthiadau â blaenoriaeth ag y dymunwch, er yr argymhellir peidio â mynd dros ben llestri â hyn (dywedwch, cyfyngu eich hun i flaenoriaeth isel, canolig ac uchel).
Felly, os oes angen, gallwch gynyddu effeithlonrwydd defnyddio gwasanaethau hanfodol, megis nginx-ingress-controller, coredns, ac ati.
9. Optimeiddiwch eich clwstwr ETCD
Gellir galw ETCD yn ymennydd y clwstwr cyfan. Mae'n bwysig iawn cynnal gweithrediad y gronfa ddata hon ar lefel uchel, gan fod cyflymder gweithrediadau yn y "Cube" yn dibynnu arno. Yn weddol safonol, ac ar yr un pryd, ateb da fyddai cadw clwstwr ETCD ar y prif nodau er mwyn cael yr oedi lleiaf posibl i kube-apiserver. Os nad yw hyn yn bosibl, yna rhowch yr ETCD mor agos â phosibl, gyda lled band da rhwng y cyfranogwyr. Rhowch sylw hefyd i faint o nodau o ETCD all syrthio allan heb niwed i'r clwstwr.
Cofiwch y gall cynnydd gormodol yn nifer y cyfranogwyr yn y clwstwr gynyddu goddefgarwch bai ar draul perfformiad, dylai popeth fod yn gymedrol.
Os soniwn am sefydlu’r gwasanaeth, yna ychydig o argymhellion sydd:
-
Meddu ar galedwedd da, yn seiliedig ar faint y clwstwr (gallwch ddarllen ).
-
Tweak ychydig o baramedrau os ydych wedi lledaenu clwstwr rhwng pâr o DCs neu eich rhwydwaith a disgiau yn gadael llawer i'w ddymuno (gallwch ddarllen ).
Casgliad
Mae'r erthygl hon yn disgrifio'r pwyntiau y mae ein tîm yn ceisio cydymffurfio â nhw. Nid yw hwn yn ddisgrifiad cam wrth gam o gamau gweithredu, ond yn opsiynau a all fod yn ddefnyddiol i wneud y gorau o orbenion clwstwr. Mae'n amlwg bod pob clwstwr yn unigryw yn ei ffordd ei hun, a gall atebion tiwnio amrywio'n fawr, felly byddai'n ddiddorol cael adborth gennych chi: sut ydych chi'n monitro'ch clwstwr Kubernetes, sut ydych chi'n gwella ei berfformiad. Rhannwch eich profiad yn y sylwadau, bydd yn ddiddorol ei wybod.
Ffynhonnell: hab.com