Mae llawer o bobl yn credu ei bod yn ddigon i fudo'r cais i Kubernetes (naill ai gan ddefnyddio Helm neu â llaw) a byddant yn hapus. Ond nid yw mor syml â hynny.
Tîm cyfieithu erthygl gan beiriannydd DevOps Julian Gindi. Mae'n rhannu'r peryglon y daeth ei gwmni ar eu traws yn ystod y broses fudo fel nad ydych yn camu ar yr un rhaca.
Cam Un: Sefydlu Ceisiadau a Therfynau Pod
Gadewch i ni ddechrau trwy sefydlu amgylchedd glân lle bydd ein codennau'n rhedeg. Mae Kubernetes yn gwneud gwaith gwych o amserlennu codennau a thrin amodau methiant. Ond daeth i'r amlwg na all y trefnydd weithiau osod pod os yw'n anodd amcangyfrif faint o adnoddau sydd eu hangen arno i weithio'n llwyddiannus. Dyma lle mae ceisiadau am adnoddau a chyfyngiadau yn codi. Mae llawer o ddadlau ynghylch y dull gorau o osod ceisiadau a therfynau. Weithiau mae'n wir yn teimlo fel ei fod yn fwy celf na gwyddoniaeth. Dyma ein hymagwedd.
Ceisiadau pod - Dyma'r prif werth a ddefnyddir gan yr amserlennydd i osod y pod yn y ffordd orau bosibl.
O'r : Mae'r cam hidlo yn pennu'r set o nodau lle gellir trefnu'r pod. Er enghraifft, mae hidlydd PodFitsResources yn gwirio a oes gan nod ddigon o adnoddau i fodloni ceisiadau adnoddau penodol pod.
Rydym yn defnyddio ceisiadau cais fel y gellir eu defnyddio i amcangyfrif faint o adnoddau mewn gwirionedd Mae angen i'r cais weithio'n iawn. Fel hyn gall y trefnydd osod nodau yn realistig. I ddechrau, roeddem am osod ceisiadau gydag ymyl i sicrhau bod gan bob pod nifer ddigon mawr o adnoddau, ond fe wnaethom sylwi bod amseroedd amserlennu yn cynyddu'n sylweddol ac nid oedd rhai codennau erioed wedi'u hamserlennu'n llawn, fel pe na bai unrhyw geisiadau am adnoddau wedi'u derbyn ar eu cyfer.
Yn yr achos hwn, byddai'r rhaglennydd yn aml yn gwthio codennau allan ac yn methu â'u haildrefnu oherwydd nad oedd gan yr awyren reoli unrhyw syniad faint o adnoddau y byddai eu hangen ar y rhaglen, sy'n elfen allweddol o'r algorithm amserlennu.
Terfynau pod - dyma derfyn cliriach ar gyfer y pod. Mae'n cynrychioli uchafswm yr adnoddau y bydd y clwstwr yn eu dyrannu i'r cynhwysydd.
Eto, oddi wrth : Os oes gan gynhwysydd derfyn cof 4 GiB, yna bydd y kubelet (a'r amser rhedeg cynhwysydd) yn ei orfodi. Nid yw'r amser rhedeg yn caniatáu i'r cynhwysydd ddefnyddio mwy na'r terfyn adnoddau penodedig. Er enghraifft, pan fydd proses mewn cynhwysydd yn ceisio defnyddio mwy na'r swm a ganiateir o gof, mae cnewyllyn y system yn terfynu'r broses gyda gwall "allan o gof" (OOM).
Gall cynhwysydd bob amser ddefnyddio mwy o adnoddau nag a nodir yn y cais am adnoddau, ond ni all byth ddefnyddio mwy na'r hyn a nodir yn y terfyn. Mae'r gwerth hwn yn anodd ei osod yn gywir, ond mae'n bwysig iawn.
Yn ddelfrydol, rydym am i ofynion adnoddau pod newid dros gylch oes proses heb ymyrryd â phrosesau eraill yn y system—dyna'r nod o osod terfynau.
Yn anffodus, ni allaf roi cyfarwyddiadau penodol ar ba werthoedd i'w gosod, ond rydym ni ein hunain yn cadw at y rheolau canlynol:
- Gan ddefnyddio offeryn profi llwyth, rydym yn efelychu lefel sylfaenol o draffig ac yn monitro'r defnydd o adnoddau pod (cof a phrosesydd).
- Rydym yn gosod y ceisiadau pod i werth mympwyol isel (gyda therfyn adnoddau o tua 5 gwaith gwerth y ceisiadau) ac arsylwi. Pan fydd ceisiadau'n rhy isel, ni all y broses ddechrau, gan achosi gwallau amser rhedeg Go dirgel yn aml.
Sylwch fod terfynau adnoddau uwch yn ei gwneud yn anoddach amserlennu oherwydd bod angen nod targed ar y pod gyda digon o adnoddau ar gael.
Dychmygwch sefyllfa lle mae gennych weinydd gwe ysgafn gyda therfyn adnoddau uchel iawn, dyweder 4 GB o gof. Mae'n debyg y bydd yn rhaid i'r broses hon raddfa'n llorweddol, a bydd yn rhaid i bob modiwl newydd gael ei amserlennu ar nod gydag o leiaf 4 GB o gof ar gael. Os nad oes nod o'r fath yn bodoli, rhaid i'r clwstwr gyflwyno nod newydd i brosesu'r cod hwnnw, a all gymryd peth amser. Mae'n bwysig cadw'r gwahaniaeth rhwng ceisiadau am adnoddau a chyfyngiadau i'r lleiafswm er mwyn sicrhau graddio cyflym a llyfn.
Cam dau: sefydlu profion Bywiogrwydd a Pharodrwydd
Mae hwn yn bwnc cynnil arall sy'n cael ei drafod yn aml yn y gymuned Kubernetes. Mae'n bwysig cael dealltwriaeth dda o brofion Bywiogrwydd a Pharodrwydd gan eu bod yn darparu mecanwaith i feddalwedd redeg yn esmwyth a lleihau amser segur. Fodd bynnag, gallant achosi trawiad perfformiad difrifol i'ch cais os na chânt eu ffurfweddu'n gywir. Isod mae crynodeb o sut beth yw'r ddau sampl.
Bywoliaeth yn dangos a yw'r cynhwysydd yn rhedeg. Os bydd yn methu, mae'r kubelet yn lladd y cynhwysydd ac mae polisi ailgychwyn wedi'i alluogi ar ei gyfer. Os nad oes gan y cynhwysydd chwiliwr Bywiogrwydd, yna bydd y cyflwr diofyn yn llwyddiant - dyma mae'n ei ddweud yn .
Dylai stilwyr bywiogrwydd fod yn rhad, sy'n golygu na ddylent ddefnyddio llawer o adnoddau, oherwydd eu bod yn rhedeg yn aml ac mae angen iddynt hysbysu Kubernetes bod y cymhwysiad yn rhedeg.
Os byddwch yn gosod yr opsiwn i redeg bob eiliad, bydd hyn yn ychwanegu 1 cais yr eiliad, felly byddwch yn ymwybodol y bydd angen adnoddau ychwanegol i drin y traffig hwn.
Yn ein cwmni, mae profion Liveness yn gwirio cydrannau craidd cymhwysiad, hyd yn oed os nad yw'r data (er enghraifft, o gronfa ddata anghysbell neu storfa) yn gwbl hygyrch.
Rydym wedi ffurfweddu'r apps gyda diweddbwynt "iechyd" sy'n syml yn dychwelyd cod ymateb o 200. Mae hyn yn arwydd bod y broses yn rhedeg ac yn gallu prosesu ceisiadau (ond nid traffig eto).
Sampl Parodrwydd yn nodi a yw'r cynhwysydd yn barod i gyflwyno ceisiadau. Os bydd y stiliwr parodrwydd yn methu, mae'r rheolydd pwynt terfyn yn tynnu cyfeiriad IP y pod o bwyntiau terfyn yr holl wasanaethau sy'n cyfateb i'r pod. Mae hyn hefyd wedi'i nodi yn nogfennaeth Kubernetes.
Mae chwilwyr parodrwydd yn defnyddio mwy o adnoddau oherwydd mae'n rhaid eu hanfon i'r pen ôl mewn ffordd sy'n dangos bod y cais yn barod i dderbyn ceisiadau.
Mae llawer o ddadlau yn y gymuned ynghylch a ddylid cael mynediad uniongyrchol i'r gronfa ddata. O ystyried y gorbenion (gwiriadau yn aml, ond gellir eu haddasu), penderfynwyd ar gyfer rhai ceisiadau, mai dim ond ar ôl gwirio bod cofnodion yn cael eu dychwelyd o'r gronfa ddata y caiff parodrwydd i wasanaethu traffig ei gyfrif. Sicrhaodd treialon parodrwydd wedi'u cynllunio'n dda lefelau uwch o argaeledd a dileu amser segur yn ystod y defnydd.
Os penderfynwch gwestiynu’r gronfa ddata i brofi parodrwydd eich cais, gwnewch yn siŵr ei fod mor rhad â phosibl. Gadewch i ni gymryd y cais hwn:
SELECT small_item FROM table LIMIT 1Dyma enghraifft o sut rydyn ni'n ffurfweddu'r ddau werth hyn yn Kubernetes:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Gallwch ychwanegu rhai opsiynau ffurfweddu ychwanegol:
initialDelaySeconds— sawl eiliad fydd yn mynd heibio rhwng lansio'r cynhwysydd a dechrau'r samplau.periodSeconds— y cyfnod aros rhwng rhediadau sampl.timeoutSeconds— nifer yr eiliadau ar ôl hynny yr ystyrir yr uned yn argyfwng. Seibiant rheolaidd.failureThreshold— nifer y methiannau prawf cyn anfon signal ailgychwyn i'r pod.successThreshold- nifer y stilwyr llwyddiannus cyn i'r pod fynd i'r cyflwr parod (ar ôl methiant, pan fydd y pod yn dechrau neu'n gwella).
Cam tri: sefydlu polisïau rhwydwaith diofyn ar gyfer y pod
Mae gan Kubernetes dopograffeg rhwydwaith “fflat”; yn ddiofyn, mae pob cod yn cyfathrebu'n uniongyrchol â'i gilydd. Mewn rhai achosion nid yw hyn yn ddymunol.
Mater diogelwch posibl yw y gallai ymosodwr ddefnyddio un cymhwysiad bregus i anfon traffig i bob cod ar y rhwydwaith. Fel gyda llawer o feysydd diogelwch, mae egwyddor y fraint leiaf yn berthnasol yma. Yn ddelfrydol, dylai polisïau rhwydwaith nodi'n benodol pa gysylltiadau rhwng codennau a ganiateir a pha rai na chaniateir.
Er enghraifft, isod mae polisi syml sy'n gwadu'r holl draffig sy'n dod i mewn ar gyfer gofod enw penodol:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Delweddu'r ffurfweddiad hwn:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Mewn manylion .
Cam pedwar: ymddygiad arferol gan ddefnyddio bachau a chynwysyddion init
Un o'n prif nodau oedd darparu lleoliadau i Kubernetes heb amser segur i ddatblygwyr. Mae hyn yn anodd oherwydd mae yna lawer o opsiynau ar gyfer cau cymwysiadau a rhyddhau'r adnoddau a ddefnyddiwyd ganddynt.
Cododd anhawsderau neillduol gyda . Gwelsom pan oedd y codennau hyn yn cael eu defnyddio'n ddilyniannol, bod cysylltiadau gweithredol yn cael eu gollwng cyn eu cwblhau'n llwyddiannus.
Ar ôl ymchwil helaeth ar-lein, mae'n ymddangos nad yw Kubernetes yn aros i gysylltiadau Nginx wacáu ei hun cyn terfynu'r pod. Gan ddefnyddio bachyn cyn-stopio, fe wnaethom weithredu'r swyddogaeth ganlynol a chael gwared ar amser segur yn llwyr:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Ond nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
Paradeim hynod ddefnyddiol arall yw'r defnydd o gynwysyddion init i drin cychwyn cymwysiadau penodol. Mae hyn yn arbennig o ddefnyddiol os oes gennych chi broses mudo cronfa ddata sy'n defnyddio llawer o adnoddau y mae angen iddi redeg cyn i'r cais ddechrau. Gallwch hefyd bennu terfyn adnoddau uwch ar gyfer y broses hon heb osod terfyn o'r fath ar gyfer y prif gais.
Cynllun cyffredin arall yw cyrchu cyfrinachau mewn cynhwysydd init sy'n darparu'r tystlythyrau hynny i'r prif fodiwl, sy'n atal mynediad heb awdurdod i gyfrinachau o'r prif fodiwl cais ei hun.
Yn ôl yr arfer, dyfynnwch o'r ddogfennaeth: Mae cynwysyddion Init yn rhedeg yn ddiogel cod arferiad neu gyfleustodau a fyddai fel arall yn lleihau diogelwch delwedd cynhwysydd y cais. Trwy gadw offer diangen ar wahân, rydych chi'n cyfyngu ar wyneb ymosodiad delwedd cynhwysydd y cais.
Cam Pump: Ffurfweddu'r Cnewyllyn
Yn olaf, gadewch i ni siarad am dechneg fwy datblygedig.
Mae Kubernetes yn blatfform hynod hyblyg sy'n caniatáu ichi redeg llwythi gwaith fel y gwelwch yn dda. Mae gennym nifer o gymwysiadau perfformiad uchel sy'n defnyddio llawer iawn o adnoddau. Ar ôl cynnal profion llwyth helaeth, fe wnaethom ddarganfod bod un cais yn cael trafferth i drin y llwyth traffig disgwyliedig pan oedd gosodiadau diofyn Kubernetes i bob pwrpas.
Fodd bynnag, mae Kubernetes yn caniatáu ichi redeg cynhwysydd breintiedig sy'n newid paramedrau cnewyllyn yn unig ar gyfer pod penodol. Dyma beth a ddefnyddiwyd gennym i newid y nifer uchaf o gysylltiadau agored:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Mae hon yn dechneg fwy datblygedig nad oes ei hangen yn aml. Ond os yw'ch cais yn cael trafferth ymdopi â llwyth trwm, gallwch geisio tweaking rhai o'r gosodiadau hyn. Mwy o fanylion am y broses hon a gosod gwerthoedd gwahanol - fel bob amser .
I gloi
Er y gall Kubernetes ymddangos fel datrysiad parod allan o'r bocs, mae yna ychydig o gamau allweddol y mae'n rhaid i chi eu cymryd i gadw'ch cymwysiadau i redeg yn llyfn.
Trwy gydol eich mudo Kubernetes, mae'n bwysig dilyn y "cylch profi llwyth": lansio'r cais, ei lwytho i brofi, arsylwi metrigau ac ymddygiad graddio, addasu'r cyfluniad yn seiliedig ar y data hwnnw, yna ailadrodd y cylch eto.
Byddwch yn realistig am eich traffig disgwyliedig a cheisiwch wthio y tu hwnt iddo i weld pa gydrannau sy'n torri gyntaf. Gyda'r dull ailadroddol hwn, dim ond ychydig o'r argymhellion a restrir a allai fod yn ddigon i sicrhau llwyddiant. Neu efallai y bydd angen addasu dyfnach.
Gofynnwch y cwestiynau hyn i chi'ch hun bob amser:
- Faint o adnoddau y mae cymwysiadau'n eu defnyddio a sut bydd y swm hwn yn newid?
- Beth yw'r gwir ofynion graddio? Faint o draffig fydd yr ap yn ei drin ar gyfartaledd? Beth am draffig brig?
- Pa mor aml y bydd angen i'r gwasanaeth raddfa'n llorweddol? Pa mor gyflym y mae angen dod â phodiau newydd ar-lein i dderbyn traffig?
- Pa mor gywir mae'r codennau'n cau? A yw hyn yn angenrheidiol o gwbl? A yw'n bosibl cyflawni lleoliad heb amser segur?
- Sut allwch chi leihau risgiau diogelwch a chyfyngu ar y difrod o unrhyw godennau sydd dan fygythiad? A oes gan unrhyw wasanaethau ganiatâd neu fynediad nad oes eu hangen arnynt?
Mae Kubernetes yn darparu platfform anhygoel sy'n eich galluogi i drosoli arferion gorau ar gyfer defnyddio miloedd o wasanaethau mewn clwstwr. Fodd bynnag, mae pob cais yn wahanol. Weithiau mae gweithredu yn gofyn am ychydig mwy o waith.
Yn ffodus, mae Kubernetes yn darparu'r cyfluniad angenrheidiol i gyflawni'r holl nodau technegol. Gan ddefnyddio cyfuniad o geisiadau a therfynau adnoddau, chwilwyr Bywiogrwydd a Pharodrwydd, cynwysyddion init, polisïau rhwydwaith, a thiwnio cnewyllyn arferol, gallwch gyflawni perfformiad uchel ynghyd â goddefgarwch namau a scalability cyflym.
Beth arall i'w ddarllen:
- .
- .
- .
Ffynhonnell: hab.com