Nodyn. traws.: Mae awduron yr erthygl hon yn beirianwyr o gwmni Tsiec bach, pipetail. Llwyddasant i lunio rhestr wych o [weithiau'n waharddol, ond yn dal i fod] o broblemau a chamsyniadau enbyd yn ymwneud â gweithrediad clystyrau Kubernetes.
Dros y blynyddoedd o ddefnyddio Kubernetes, rydym wedi gweithio gyda nifer fawr o glystyrau (wedi'u rheoli a heb eu rheoli - ar GCP, AWS ac Azure). Dros amser, dechreuon ni sylwi bod rhai camgymeriadau'n cael eu hailadrodd yn gyson. Fodd bynnag, nid oes unrhyw gywilydd yn hyn: rydym wedi gwneud y rhan fwyaf ohonynt ein hunain!
Mae'r erthygl yn cynnwys y gwallau mwyaf cyffredin a hefyd yn sôn am sut i'w cywiro.
1. Adnoddau: ceisiadau a therfynau
Mae'r eitem hon yn bendant yn haeddu'r sylw agosaf a'r lle cyntaf ar y rhestr.
Cais CPU fel arfer naill ai heb ei nodi o gwbl neu sydd â gwerth isel iawn (i osod cymaint o godau ar bob nod â phosib). Felly, mae'r nodau'n cael eu gorlwytho. Yn ystod cyfnodau o lwyth uchel, mae pŵer prosesu'r nod yn cael ei ddefnyddio'n llawn ac mae llwyth gwaith penodol yn derbyn dim ond yr hyn y mae'n "gofyn amdano" ganddo. CPU throtling. Mae hyn yn arwain at fwy o hwyrni ymgeisio, seibiannau, a chanlyniadau annymunol eraill. (Darllenwch fwy am hyn yn ein cyfieithiad diweddar arall: “" - tua. cyfieithu.)
Ymdrech Orau (hynod dim argymhellir):
resources: {}Cais CPU hynod o isel (hynod dim argymhellir):
resources:
Requests:
cpu: "1m"Ar y llaw arall, gall presenoldeb terfyn CPU arwain at hepgor yn afresymol o gylchoedd cloc gan godennau, hyd yn oed os nad yw'r prosesydd nod wedi'i lwytho'n llawn. Unwaith eto, gall hyn arwain at fwy o oedi. Mae dadlau yn parhau o amgylch y paramedr Cwota CPU CFS yn y cnewyllyn Linux a throtling CPU yn dibynnu ar y terfynau a osodwyd, yn ogystal ag analluogi'r cwota CFS... Ysywaeth, gall terfynau CPU achosi mwy o broblemau nag y gallant eu datrys. Mae rhagor o wybodaeth am hyn ar gael yn y ddolen isod.
Detholiad gormodol (gorymrwymo) gall problemau cof arwain at broblemau mwy. Mae cyrraedd y terfyn CPU yn golygu hepgor cylchoedd cloc, tra bod cyrraedd y terfyn cof yn golygu lladd y pod. Ydych chi erioed wedi arsylwi OOMkill? Ie, dyna'n union yr ydym yn sôn amdano.
Ydych chi am leihau'r tebygolrwydd y bydd hyn yn digwydd? Peidiwch â gor-ddyrannu cof a defnyddio QoS Gwarantedig (Ansawdd Gwasanaeth) trwy osod y cais cof i'r terfyn (fel yn yr enghraifft isod). Darllenwch fwy am hyn yn (Peiriannydd Arweiniol yn Zalando).
Byrstable (siawns uwch o gael OOMkilled):
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: 2Gwarantedig:
resources:
requests:
memory: "128Mi"
cpu: 2
limits:
memory: "128Mi"
cpu: 2Beth allai fod o gymorth wrth sefydlu adnoddau?
Gyda metrig-gweinydd gallwch weld y defnydd o adnoddau CPU cyfredol a defnydd cof gan godennau (a chynwysyddion y tu mewn iddynt). Yn fwyaf tebygol, rydych chi eisoes yn ei ddefnyddio. Dim ond rhedeg y gorchmynion canlynol:
kubectl top pods
kubectl top pods --containers
kubectl top nodesFodd bynnag, dim ond y defnydd cyfredol y maent yn ei ddangos. Gall roi syniad bras i chi o drefn maint, ond yn y pen draw bydd angen hanes newidiadau mewn metrigau dros amser (i ateb cwestiynau fel: “Beth oedd y llwyth CPU brig?”, “Beth oedd y llwyth bore ddoe?”, ac ati). Ar gyfer hyn gallwch chi ddefnyddio Prometheus, Ci Data ac offer eraill. Yn syml, maen nhw'n cael metrigau o metrics-server a'u storio, a gall y defnyddiwr eu holi a'u plotio yn unol â hynny.
yn caniatáu awtomeiddio y broses hon. Mae'n olrhain hanes defnydd CPU a chof ac yn sefydlu ceisiadau a therfynau newydd yn seiliedig ar y wybodaeth hon.
Nid yw defnyddio pŵer cyfrifiadurol yn effeithlon yn dasg hawdd. Mae fel chwarae Tetris drwy'r amser. Os ydych chi'n talu gormod am bŵer cyfrifo gyda defnydd cyfartalog isel (dyweder ~ 10%), rydym yn argymell edrych ar gynhyrchion yn seiliedig ar AWS Fargate neu Virtual Kubelet. Maent wedi'u hadeiladu ar fodel bilio di-weinydd/talu fesul defnydd, a all fod yn rhatach mewn amodau o'r fath.
2. Bywioldeb a chwilwyr parod
Yn ddiofyn, nid yw gwiriadau bywiogrwydd a pharodrwydd wedi'u galluogi yn Kubernetes. Ac weithiau maen nhw'n anghofio eu troi ymlaen ...
Ond sut arall allwch chi gychwyn gwasanaeth ailgychwyn os bydd gwall angheuol? A sut mae'r cydbwysedd llwyth yn gwybod bod pod yn barod i dderbyn traffig? Neu y gall ymdopi â mwy o draffig?
Mae'r profion hyn yn aml yn cael eu drysu â'i gilydd:
- Bywoliaeth — gwiriad “goroesedd”, sy'n ailgychwyn y pod os yw'n methu;
- Parodrwydd — gwiriad parodrwydd, os bydd yn methu, mae'n datgysylltu'r pod o wasanaeth Kubernetes (gellir gwirio hyn gan ddefnyddio
kubectl get endpoints) ac nid yw traffig yn cyrraedd ato nes bod y gwiriad nesaf wedi'i gwblhau'n llwyddiannus.
Y ddau wiriad hyn PERFFEITHIR YN YSTOD CYLCH BYWYD HYFAN Y POD. Mae'n bwysig iawn.
Camsyniad cyffredin yw mai dim ond wrth gychwyn y caiff stilwyr parodrwydd eu rhedeg er mwyn i'r cydbwyseddwr wybod bod y pod yn barod (Ready) a gall ddechrau prosesu traffig. Fodd bynnag, dim ond un o'r opsiynau ar gyfer eu defnyddio yw hwn.
Un arall yw'r posibilrwydd o ddarganfod bod y traffig ar y pod yn ormodol a yn ei orlwytho (neu mae'r pod yn gwneud cyfrifiadau sy'n defnyddio llawer o adnoddau). Yn yr achos hwn, mae'r gwiriad parodrwydd yn helpu lleihau'r llwyth ar y pod a'i "oeri".. Mae cwblhau gwiriad parodrwydd yn llwyddiannus yn y dyfodol yn caniatáu cynyddu'r llwyth ar y pod eto. Yn yr achos hwn (os bydd y prawf parodrwydd yn methu), byddai methiant y prawf bywiogrwydd yn wrthgynhyrchiol iawn. Pam ailgychwyn pod sy'n iach ac yn gweithio'n galed?
Felly, mewn rhai achosion, nid oes unrhyw wiriadau o gwbl yn well na'u galluogi gyda pharamedrau sydd wedi'u ffurfweddu'n anghywir. Fel y dywedwyd uchod, os gwiriad bywiogrwydd copïau gwirio, yna rydych mewn trafferth mawr. Yr opsiwn posibl yw ffurfweddu Ac gadael o'r neilltu.
Ni ddylai'r ddau fath o wiriad fethu pan fydd dibyniaethau cyffredin yn methu, fel arall bydd hyn yn arwain at fethiant rhaeadru (fel eirlithriad) ym mhob codennau. Mewn geiriau eraill, .
3. LoadBalancer ar gyfer pob gwasanaeth HTTP
Yn fwyaf tebygol, mae gennych chi wasanaethau HTTP yn eich clwstwr yr hoffech chi eu hanfon ymlaen i'r byd y tu allan.
Os byddwch yn agor y gwasanaeth fel type: LoadBalancer, bydd ei reolwr (yn dibynnu ar y darparwr gwasanaeth) yn darparu ac yn negodi LoadBalancer allanol (nid o reidrwydd yn rhedeg ar L7, ond yn hytrach hyd yn oed ar L4), a gall hyn effeithio ar y gost (cyfeiriad IPv4 statig allanol, pŵer cyfrifiadurol, bilio fesul eiliad ) oherwydd yr angen i greu nifer fawr o adnoddau o'r fath.
Yn yr achos hwn, mae'n llawer mwy rhesymegol i ddefnyddio un balancer llwyth allanol, agor gwasanaethau fel type: NodePort. Neu well eto, ehangu rhywbeth tebyg nginx-mynediad-rheolwr (Neu traefik), pwy fydd yr unig un NodePort diweddbwynt sy'n gysylltiedig â'r cydbwysedd llwyth allanol a bydd yn cyfeirio traffig yn y clwstwr gan ddefnyddio dod i mewn-Adnoddau Kubernetes.
Gall gwasanaethau o fewn clwstwr (micro) sy'n rhyngweithio â'i gilydd “gyfathrebu” gan ddefnyddio gwasanaethau fel ClwstwrIP a mecanwaith darganfod gwasanaeth adeiledig trwy DNS. Peidiwch â defnyddio eu DNS/IP cyhoeddus, gan y gall hyn effeithio ar hwyrni a chynyddu cost gwasanaethau cwmwl.
4. Autoscaling clwstwr heb gymryd i ystyriaeth ei nodweddion
Wrth ychwanegu nodau at glwstwr a'u tynnu oddi yno, ni ddylech ddibynnu ar rai metrigau sylfaenol fel defnydd CPU ar y nodau hynny. Rhaid i gynllunio codennau ystyried llawer cyfyngiadau, megis affinedd cod/nôd, llygredigaethau a goddefgarwch, ceisiadau am adnoddau, QoS, ac ati. Gall defnyddio autoscaler allanol nad yw'n ystyried yr arlliwiau hyn arwain at broblemau.
Dychmygwch y dylid amserlennu pod penodol, ond gofynnir am / dadosod yr holl bŵer CPU sydd ar gael a'r pod yn mynd yn sownd mewn cyflwr Pending. Mae autoscaler allanol yn gweld y llwyth CPU cyfredol cyfartalog (nid yr un y gofynnwyd amdano) ac nid yw'n cychwyn ehangu (graddio allan) - nid yw'n ychwanegu nod arall. O ganlyniad, ni fydd y pod hwn yn cael ei amserlennu.
Yn yr achos hwn, graddio gwrthdro (graddfa i mewn) — mae tynnu nod o glwstwr bob amser yn anoddach ei weithredu. Dychmygwch fod gennych god urddasol (gyda storfa barhaus wedi'i chysylltu). Cyfrolau parhaus fel arfer yn perthyn i parth argaeledd penodol ac nid ydynt yn cael eu hailadrodd yn y rhanbarth. Felly, os bydd autoscaler allanol yn dileu nod gyda'r pod hwn, ni fydd y trefnydd yn gallu amserlennu'r pod hwn ar nod arall, gan mai dim ond yn y parth argaeledd lle mae'r storfa barhaus y gellir gwneud hyn. Bydd y pod yn sownd yn y cyflwr Pending.
Yn boblogaidd iawn yng nghymuned Kubernetes . Mae'n rhedeg ar glwstwr, yn cefnogi APIs gan ddarparwyr cwmwl mawr, yn ystyried yr holl gyfyngiadau ac yn gallu graddio yn yr achosion uchod. Mae hefyd yn gallu ehangu tra'n cynnal yr holl derfynau a osodwyd, a thrwy hynny arbed arian (a fyddai fel arall yn cael ei wario ar gapasiti nas defnyddiwyd).
5. Esgeuluso galluoedd IAM/RBAC
Byddwch yn wyliadwrus o ddefnyddio defnyddwyr IAM gyda chyfrinachau parhaus ar gyfer peiriannau a chymwysiadau. Trefnu mynediad dros dro gan ddefnyddio rolau a chyfrifon gwasanaeth (cyfrifon gwasanaeth).
Rydym yn aml yn dod ar draws y ffaith bod allweddi mynediad (a chyfrinachau) wedi'u codio caled yng nghyfluniad y cais, yn ogystal ag esgeuluso cylchdroi cyfrinachau er gwaethaf cael mynediad i Cloud IAM. Defnyddiwch rolau IAM a chyfrifon gwasanaeth yn lle defnyddwyr lle bo'n briodol.
Anghofiwch am kube2iam ac ewch yn syth i rolau IAM ar gyfer cyfrifon gwasanaeth (fel y disgrifir yn Štěpán Vraný):
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
name: my-serviceaccount
namespace: defaultUn anodiad. Ddim mor anodd â hynny, iawn?
Hefyd, peidiwch â rhoi breintiau cyfrifon gwasanaeth a phroffiliau enghraifft admin и cluster-adminos nad oes ei angen arnynt. Mae hyn ychydig yn anoddach i'w weithredu, yn enwedig yn RBAC K8s, ond yn bendant yn werth yr ymdrech.
6. Peidiwch â dibynnu ar wrth-affinedd awtomatig ar gyfer codennau
Dychmygwch fod gennych dri atgynhyrchiad o rywfaint o ddefnydd ar nod. Mae'r nod yn disgyn, ac ynghyd ag ef mae'r holl atgynyrchiadau. Sefyllfa annymunol, iawn? Ond pam roedd yr holl atgynhyrchiadau ar yr un nod? Onid yw Kubernetes i fod i ddarparu argaeledd uchel (HA)?!
Yn anffodus, nid yw amserlennydd Kubernetes, ar ei liwt ei hun, yn cydymffurfio â rheolau bodolaeth ar wahân (gwrth-affinedd) ar gyfer codennau. Rhaid iddynt gael eu datgan yn benodol:
// опущено для краткости
labels:
app: zk
// опущено для краткости
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
Dyna i gyd. Nawr bydd codennau'n cael eu trefnu ar wahanol nodau (dim ond yn ystod yr amserlennu y caiff yr amod hwn ei wirio, ond nid yn ystod eu llawdriniaeth - felly requiredDuringSchedulingIgnoredDuringExecution).
Yma rydym yn siarad am podAntiAffinity ar nodau gwahanol: topologyKey: "kubernetes.io/hostname", - ac nid am wahanol barthau argaeledd. Er mwyn gweithredu HA llawn, bydd yn rhaid i chi gloddio'n ddyfnach i'r pwnc hwn.
7. Anwybyddu Cyllidebau PodAmhariad
Dychmygwch fod gennych lwyth cynhyrchu ar glwstwr Kubernetes. O bryd i'w gilydd, mae'n rhaid diweddaru (neu ddatgomisiynu) nodau a'r clwstwr ei hun. Mae PodDisruptionBudget (PDB) yn rhywbeth fel cytundeb gwarantu gwasanaeth rhwng gweinyddwyr clwstwr a defnyddwyr.
Mae PDB yn caniatáu ichi osgoi ymyriadau gwasanaeth a achosir gan ddiffyg nodau:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeperYn yr enghraifft hon, rydych chi, fel defnyddiwr y clwstwr, yn dweud wrth y gweinyddwyr: “Hei, mae gen i wasanaeth ceidwad sw, a waeth beth rydych chi'n ei wneud, hoffwn i gael o leiaf 2 atgynhyrchiad o'r gwasanaeth hwn bob amser ar gael.”
Gallwch ddarllen mwy am hyn .
8. Defnyddwyr lluosog neu amgylcheddau mewn clwstwr cyffredin
bylchau enwau Kubernetes (mannau enwau) peidiwch â darparu inswleiddio cryf.
Camsyniad cyffredin yw os ydych chi'n defnyddio llwyth nad yw'n gynnyrch i un gofod enw a llwyth prod i le arall, yna maen nhw ni fyddant yn dylanwadu ar ei gilydd mewn unrhyw ffordd... Fodd bynnag, gellir cyflawni lefel benodol o ynysu trwy ddefnyddio ceisiadau/cyfyngiadau adnoddau, gosod cwotâu, a gosod Dosbarthiadau blaenoriaeth. Mae rhywfaint o arwahanrwydd “corfforol” yn yr awyren ddata yn cael ei ddarparu gan gysylltiadau, goddefiannau, llygrwyr (neu ddetholwyr nodau), ond mae gwahaniad o'r fath yn eithaf. anodd gweithredu.
Bydd yn rhaid i’r rhai sydd angen cyfuno’r ddau fath o lwythi gwaith yn yr un clwstwr ymdrin â chymhlethdod. Os nad oes angen o'r fath, a gallwch fforddio cael un un clwstwr arall (dyweder, mewn cwmwl cyhoeddus), yna mae'n well gwneud hynny. Bydd hyn yn cyflawni lefel llawer uwch o inswleiddio.
9. externalTrafficPolicy: Clwstwr
Yn aml iawn rydym yn gweld bod yr holl draffig y tu mewn i'r clwstwr yn dod trwy wasanaeth fel NodePort, y mae'r polisi diofyn wedi'i osod ar ei gyfer externalTrafficPolicy: Cluster... Mae'n golygu hynny NodePort yn agored ar bob nod yn y clwstwr, a gallwch ddefnyddio unrhyw un ohonynt i ryngweithio â'r gwasanaeth a ddymunir (set o godennau).
Ar yr un pryd, mae codennau go iawn sy'n gysylltiedig â'r gwasanaeth NodePort a grybwyllir uchod ar gael ar ryw fath yn unig. is-set o'r nodau hyn. Mewn geiriau eraill, os byddaf yn cysylltu â nod nad oes ganddo'r pod gofynnol, bydd yn anfon traffig ymlaen i nod arall, ychwanegu hop a hwyrni cynyddol (os lleolir nodau mewn gwahanol barthau argaeledd/canolfannau data, gall yr hwyrni fod yn eithaf uchel; yn ogystal, bydd costau traffig allanfeydd yn cynyddu).
Ar y llaw arall, os oes gan wasanaeth Kubernetes penodol set bolisi externalTrafficPolicy: Local, yna mae NodePort yn agor yn unig ar y nodau hynny lle mae'r codennau gofynnol yn rhedeg mewn gwirionedd. Wrth ddefnyddio balancer llwyth allanol sy'n gwirio'r cyflwr (gwirio iechyd) diweddbwyntiau (sut mae'n ei wneud AWS ELB), Ef yn anfon traffig i'r nodau angenrheidiol yn unig, a fydd yn cael effaith fuddiol ar oedi, anghenion cyfrifiadurol, biliau mynediad (a synnwyr cyffredin sy'n pennu'r un peth).
Mae siawns uchel eich bod chi eisoes yn defnyddio rhywbeth tebyg traefik neu nginx-mynediad-rheolwr fel pwynt terfyn NodePort (neu LoadBalancer, sydd hefyd yn defnyddio NodePort) i gyfeirio traffig mynediad HTTP, a gall gosod yr opsiwn hwn leihau'r hwyrni ar gyfer ceisiadau o'r fath yn sylweddol.
В Gallwch ddysgu mwy am BolisiTraffig Allanol, ei fanteision a'i anfanteision.
10. Peidiwch â mynd yn gaeth i glystyrau a pheidiwch â chamddefnyddio'r awyren reoli
Yn flaenorol, roedd yn arferol galw gweinyddwyr yn ôl enwau priodol: , HAL9000 a Colossus... Heddiw maent wedi cael eu disodli gan ddynodwyr a gynhyrchir ar hap. Fodd bynnag, parhaodd yr arferiad, a bellach mae enwau priod yn mynd i glystyrau.
Stori nodweddiadol (yn seiliedig ar ddigwyddiadau go iawn): dechreuodd y cyfan gyda phrawf o gysyniad, felly roedd gan y clwstwr enw balch profion… Mae blynyddoedd wedi mynd heibio ac mae'n dal i gael ei ddefnyddio wrth gynhyrchu, ac mae pawb yn ofni ei gyffwrdd.
Nid oes dim byd hwyl am glystyrau yn troi'n anifeiliaid anwes, felly rydym yn argymell cael gwared arnynt o bryd i'w gilydd wrth ymarfer adferiad trychineb (bydd hyn yn helpu - tua. cyfieithu.). Yn ogystal, ni fyddai'n brifo gweithio ar yr haen reoli (awyren reoli). Nid yw bod ofn cyffwrdd ag ef yn arwydd da. Etc. marw? Bois, rydych chi mewn trwbwl mewn gwirionedd!
Ar y llaw arall, ni ddylech fod ar ben ei gilydd â'i drin. Gydag amser gall yr haen reoli ddod yn araf. Yn fwyaf tebygol, mae hyn oherwydd bod nifer fawr o wrthrychau yn cael eu creu heb eu cylchdroi (sefyllfa gyffredin wrth ddefnyddio Helm gyda gosodiadau diofyn, a dyna pam nad yw ei gyflwr mewn configmaps / cyfrinachau yn cael ei ddiweddaru - o ganlyniad, mae miloedd o wrthrychau'n cronni i mewn yr haen reoli) neu gyda golygu cyson o wrthrychau kube-api (ar gyfer graddio awtomatig, ar gyfer CI / CD, ar gyfer monitro, logiau digwyddiadau, rheolwyr, ac ati).
Yn ogystal, rydym yn argymell gwirio'r cytundebau CLG / SLO gyda'r darparwr Kubernetes a reolir a thalu sylw i'r gwarantau. Gall y gwerthwr warantu argaeledd haen reoli (neu ei is-gydrannau), ond nid yr oedi o ran t99 y ceisiadau y byddwch yn eu hanfon ato. Mewn geiriau eraill, gallwch chi fynd i mewn kubectl get nodes, a derbyn ateb dim ond ar ôl 10 munud, ac ni fydd hyn yn groes i delerau'r cytundeb gwasanaeth.
11. Bonws: defnyddio'r tag diweddaraf
Ond mae hwn eisoes yn glasur. Yn ddiweddar rydym wedi dod ar draws y dechneg hon yn llai aml, gan fod llawer, ar ôl dysgu o brofiad chwerw, wedi rhoi'r gorau i ddefnyddio'r tag :latest a dechrau pinio fersiynau. Hwre!
ECR ; Rydym yn argymell eich bod yn ymgyfarwyddo â'r nodwedd hynod hon.
Crynodeb
Peidiwch â disgwyl i bopeth weithio dros nos: nid yw Kubernetes yn ateb i bob problem. Ap drwg (ac mae'n debyg y bydd yn gwaethygu). Bydd diofalwch yn arwain at ormod o gymhlethdod, gwaith araf a dirdynnol yr haen reoli. Yn ogystal, rydych mewn perygl o gael eich gadael heb strategaeth adfer ar ôl trychineb. Peidiwch â disgwyl i Kubernetes ddarparu arwahanrwydd ac argaeledd uchel allan o'r bocs. Treuliwch ychydig o amser yn gwneud eich cais yn wirioneddol gwmwl brodorol.
Gallwch ddod yn gyfarwydd â phrofiadau aflwyddiannus timau amrywiol yn gan Henning Jacobs.
Gall y rhai sy'n dymuno ychwanegu at y rhestr o wallau a roddir yn yr erthygl hon gysylltu â ni ar Twitter (, ).
PS gan y cyfieithydd
Darllenwch hefyd ar ein blog:
- «";
- «";
- «"(adroddiad adolygu a fideo);
- «'.
Ffynhonnell: hab.com