Heddiw rwy'n bwriadu siarad am sut i ysgrifennu ceisiadau a beth yw'r gofynion i'ch cais weithio'n dda yn Kubernetes. Fel nad oes cur pen gyda'r cais, fel nad oes rhaid i chi ddyfeisio ac adeiladu unrhyw “cratches” o'i gwmpas - ac mae popeth yn gweithio fel y bwriadodd Kubernetes ei hun.
Mae'r ddarlith hon yn rhan o "" Gallwch weld darlithoedd damcaniaethol agored yr Ysgol Hwyrol . I'r rhai y mae'n well ganddynt destun yn hytrach na fideo, rydym wedi paratoi'r erthygl hon.
Fy enw i yw Pavel Selivanov, ar hyn o bryd fi yw'r prif beiriannydd DevOps yn Mail.ru Cloud Solutions, rydyn ni'n gwneud cymylau, rydyn ni'n gwneud kubernetes rheoli ac yn y blaen. Mae fy nhasgau bellach yn cynnwys cymorth i ddatblygu, cyflwyno'r cymylau hyn, cyflwyno'r cymwysiadau rydyn ni'n eu hysgrifennu a datblygu'r offer rydyn ni'n eu darparu ar gyfer ein defnyddwyr yn uniongyrchol.
Rydw i wedi bod yn gwneud DevOps, rwy'n meddwl am y tair blynedd diwethaf, yn ôl pob tebyg. Ond, mewn egwyddor, rydw i wedi bod yn gwneud yr hyn y mae DevOps yn ei wneud ers tua phum mlynedd bellach yn ôl pob tebyg. Cyn hynny, roeddwn i'n ymwneud yn bennaf â phethau gweinyddol. Dechreuais weithio gyda Kubernetes amser maith yn ôl - mae'n debyg bod tua phedair blynedd wedi mynd heibio ers i mi ddechrau gweithio gydag ef.
Yn gyffredinol, dechreuais pan oedd Kubernetes yn fersiwn 1.3, yn ôl pob tebyg, ac efallai 1.2 - pan oedd yn dal yn ei fabandod. Nawr nid yw yn ei fabandod bellach - ac mae'n amlwg bod galw enfawr yn y farchnad am beirianwyr a hoffai allu gwneud Kubernetes. Ac mae gan gwmnïau alw mawr iawn am bobl o'r fath. Felly, mewn gwirionedd, ymddangosodd y ddarlith hon.
Os siaradwn yn ol cynllun yr hyn y soniaf am dano, y mae yn edrych fel hyn, mewn cromfachau y mae yn ysgrifenedig (TL;DR) — “ rhy hir; peidiwch â darllen". Bydd fy nghyflwyniad heddiw yn cynnwys rhestrau diddiwedd.
Mewn gwirionedd, nid wyf fi fy hun yn hoffi cyflwyniadau o'r fath pan fyddant yn cael eu gwneud, ond mae hwn yn bwnc o'r fath fel nad oeddwn yn gwybod sut i drefnu'r wybodaeth hon yn wahanol pan oeddwn yn paratoi'r cyflwyniad hwn.
Oherwydd, ar y cyfan, mae'r wybodaeth hon yn “ctrl+c, ctrl+v”, o, ymhlith pethau eraill, ein Wiki yn yr adran DevOps, lle mae gennym ofynion ysgrifenedig ar gyfer datblygwyr: “Bois, fel ein bod yn lansio'ch cais yn Kubernetes, fe ddylai fod fel hyn."
Dyna pam y trodd y cyflwyniad yn rhestr mor fawr. Mae'n ddrwg gennyf. Byddaf yn ceisio dweud cymaint â phosibl fel nad yw'n ddiflas os yn bosibl.
Beth rydyn ni'n mynd i edrych arno nawr:
- mae'r rhain, yn gyntaf, yn logiau (logiau cais?), beth i'w wneud â nhw yn Kubernetes, beth i'w wneud â nhw, beth ddylent fod;
- beth i'w wneud â chyfluniadau yn Kubernetes, beth yw'r ffyrdd gorau a gwaethaf o ffurfweddu cais ar gyfer Kubernetes;
- Gadewch i ni siarad am beth yw gwiriadau hygyrchedd yn gyffredinol, sut y dylent edrych;
- gadewch i ni siarad am beth yw cau i lawr gosgeiddig;
- gadewch i ni siarad am adnoddau eto;
- Gadewch i ni gyffwrdd â'r pwnc storio data unwaith eto;
- ac ar y diwedd mi a ddywedaf wrthych beth yw y term y cymhwysiad cwmwl-frodorol dirgel hwn. Cymylogrwydd, fel ansoddair o'r term hwn.
Logiau
Rwy'n awgrymu dechrau gyda'r logiau - gyda lle mae angen gwthio'r boncyffion hyn yn Kubernetes. Nawr rydych chi wedi lansio cais yn Kubernetes. Yn ôl y clasuron, roedd ceisiadau blaenorol bob amser yn ysgrifennu logiau rhywle mewn ffeil. Ysgrifennodd ceisiadau gwael logiau i ffeil yng nghyfeirlyfr cartref y datblygwr a lansiodd y cais. Ysgrifennodd cymwysiadau da logiau i ffeil rhywle ynddi /var/log.
Yn unol â hynny, ymhellach, roedd gan weinyddwyr da rai pethau wedi'u ffurfweddu yn eu seilweithiau y gallai'r logiau hyn eu cylchdroi - yr un rsyslog, sy'n edrych ar y logiau hyn a phan fydd rhywbeth yn digwydd iddynt, mae yna lawer ohonynt, mae'n creu copïau wrth gefn, yn rhoi logiau yno , yn dileu hen ffeiliau, mwy nag wythnos, chwe mis a rhai mwy. Mewn egwyddor, dylem gael darpariaethau fel bod y gofod ar y gweinyddwyr cynhyrchu (gweinyddwyr ymladd?) Nid yw'n rhedeg allan oherwydd bod y rhaglen yn ysgrifennu logiau. Ac, yn unol â hynny, ni ddaeth y cynhyrchiad cyfan i ben oherwydd y logiau.
Pan symudwn i fyd Kubernetes a rhedeg yr un peth yno, y peth cyntaf y gallwch chi roi sylw iddo yw'r ffaith bod pobl, wrth iddynt ysgrifennu logiau mewn ffeil, yn parhau i'w hysgrifennu.
Mae'n ymddangos, os ydym yn siarad am Kubernetes, y lle iawn i ysgrifennu logiau yn rhywle o gynhwysydd docwr yw eu hysgrifennu o'r cymhwysiad i'r hyn a elwir yn Stdout / Stderr, hynny yw, ffrydiau allbwn safonol y system weithredu, yr allbwn gwall safonol . Dyma'r ffordd fwyaf cywir, symlaf a mwyaf rhesymegol i roi boncyffion mewn egwyddor yn Docker ac yn benodol yn Kubernetis. Oherwydd os yw'ch cais yn ysgrifennu logiau i Stdout / Stderr, yna Docker ac ategyn Kubernetes sydd i benderfynu beth i'w wneud â'r logiau hyn. Bydd Docker yn ddiofyn yn adeiladu ei ffeiliau arbennig mewn fformat JSON.
Yma mae'r cwestiwn yn codi, beth fyddwch chi'n ei wneud nesaf gyda'r logiau hyn? Mae'r ffordd hawsaf yn glir, mae gennym y gallu i wneud kubectl logs ac edrychwch ar y logiau hyn o'r “pods” hyn. Ond, yn ôl pob tebyg, nid yw hwn yn opsiwn da iawn - mae angen gwneud rhywbeth arall gyda'r logiau.
Am y tro, gadewch i ni siarad ar yr un pryd, ers i ni gyffwrdd â'r pwnc o logiau, am y fath beth ag y dylai logiau edrych. Hynny yw, nid yw hyn yn berthnasol yn uniongyrchol i Kubernetes, ond pan fyddwn yn dechrau meddwl am beth i'w wneud â logiau, byddai'n dda meddwl am hyn hefyd.
Mae arnom angen rhyw fath o offeryn, mewn ffordd gyfeillgar, a fydd yn cymryd y logiau hyn y mae ein docwr yn eu rhoi yn ei ffeiliau a'u hanfon i rywle. Ar y cyfan, rydyn ni fel arfer yn lansio rhyw fath o asiant y tu mewn i Kubernetes ar ffurf DaemonSet - casglwr boncyffion, sy'n cael gwybod yn syml ble mae'r logiau y mae Docker yn eu casglu wedi'u lleoli. Ac mae'r asiant casglu hwn yn syml yn eu cymryd, efallai hyd yn oed rywsut yn eu dosrannu ar hyd y ffordd, efallai yn eu cyfoethogi â rhywfaint o feta-wybodaeth ychwanegol ac, yn y pen draw, yn eu hanfon i'w storio yn rhywle. Mae amrywiadau eisoes yn bosibl yno. Mae'n debyg mai'r mwyaf cyffredin yw Elasticsearch, lle gallwch chi storio boncyffion a gallwch chi eu hadalw'n gyfleus oddi yno. Yna, gan ddefnyddio cais, gan ddefnyddio Kibana, er enghraifft, adeiladu graffiau yn seiliedig arnynt, adeiladu rhybuddion yn seiliedig arnynt, ac ati.
Y syniad pwysicaf, yr wyf am ei ailadrodd eto, yw bod storio'ch logiau mewn ffeil y tu mewn i Docker, yn enwedig y tu mewn i Kubernetes, yn syniad gwael iawn.
Oherwydd yn gyntaf, mae'n anodd cael y logiau y tu mewn i'r cynhwysydd mewn ffeil. Yn gyntaf rhaid i chi fynd i mewn i'r cynhwysydd, exec yno, ac yna edrych ar y boncyffion. Y pwynt nesaf yw, os oes gennych logiau mewn ffeil, yna fel arfer mae gan y cynwysyddion amgylchedd minimalaidd ac nid oes unrhyw gyfleustodau sydd eu hangen fel arfer ar gyfer gwaith arferol gyda logiau. Claddwch nhw, edrychwch arnyn nhw, agorwch nhw mewn golygydd testun. Y foment nesaf yw pan fydd gennym logiau mewn ffeil y tu mewn i gynhwysydd, os caiff y cynhwysydd hwn ei ddileu, rydych chi'n deall, bydd y logiau'n marw ynghyd ag ef. Yn unol â hynny, mae unrhyw ailgychwyn y cynhwysydd yn golygu nad oes mwy o logiau. Unwaith eto, opsiwn gwael.
A'r pwynt olaf yw bod y tu mewn i gynwysyddion fel arfer yn cael eich cais a dyna ni - fel arfer dyma'r unig broses sy'n rhedeg. Nid oes unrhyw sôn o gwbl am unrhyw broses a fyddai'n cylchdroi ffeiliau gyda'ch logiau. Cyn gynted ag y bydd y logiau'n dechrau cael eu hysgrifennu i ffeil, mae hyn yn golygu, esgusodwch fi, y byddwn yn dechrau colli'r gweinydd cynhyrchu. Oherwydd, yn gyntaf, maent yn anodd dod o hyd iddynt, nid oes neb yn eu tracio, ac nid oes neb yn eu rheoli - yn unol â hynny, mae'r ffeil yn tyfu'n ddiddiwedd nes bod y gofod ar y gweinydd yn rhedeg allan. Felly, dywedaf eto fod mewngofnodi Docker, yn enwedig yn Kubernetes, i ffeil yn syniad drwg.
Y pwynt nesaf, yma rwyf am siarad am hyn eto - gan ein bod yn cyffwrdd â'r pwnc o foncyffion, byddai'n dda siarad am sut y dylai logiau edrych er mwyn ei gwneud yn gyfleus i weithio gyda nhw. Fel y dywedais, nid yw'r pwnc yn uniongyrchol gysylltiedig â Kubernetes, ond mae'n ymwneud yn dda iawn â phwnc DevOps. Ar y pwnc o ddatblygiad diwylliant a chyfeillgarwch rhwng y ddwy adran wahanol - Dev a Ops, fel bod pawb yn gyfforddus.
Mae hyn yn golygu, yn ddelfrydol, heddiw, y dylid ysgrifennu logiau ar ffurf JSON. Os oes gennych chi rywfaint o gymhwysiad annealladwy eich hun, sy'n ysgrifennu logiau mewn fformatau annealladwy oherwydd eich bod chi'n mewnosod rhyw fath o brint neu rywbeth felly, yna mae'n bryd google rhyw fath o fframwaith, rhyw fath o ddeunydd lapio sy'n eich galluogi i weithredu logio arferol; galluogi paramedrau logio yn JSON yno, oherwydd JSON yn fformat syml, dosrannu mae'n syml.
Os nad yw eich JSON yn gweithio yn ôl rhai meini prawf, nid oes neb yn gwybod beth, yna o leiaf ysgrifennwch logiau mewn fformat y gellir ei ddosrannu. Yma, yn hytrach, mae'n werth meddwl am y ffaith, er enghraifft, os ydych chi'n rhedeg criw o gynwysyddion neu ddim ond prosesau gyda nginx, a bod gan bob un ei osodiadau logio ei hun, yna mae'n debyg ei bod yn ymddangos y bydd yn anghyfleus iawn i chi. dosrannu nhw. Oherwydd ar gyfer pob enghraifft nginx newydd mae angen i chi ysgrifennu eich parser eich hun, oherwydd maen nhw'n ysgrifennu logiau'n wahanol. Unwaith eto, mae'n debyg ei bod yn werth meddwl am sicrhau bod gan yr holl achosion nginx hyn yr un ffurfwedd logio a'u bod yn ysgrifennu eu holl logiau yn hollol unffurf. Mae'r un peth yn wir am bob cais.
Yn y diwedd, rwyf hefyd am ychwanegu tanwydd i'r tân y dylid, yn ddelfrydol, logiau fformat aml-linell gael eu hosgoi. Dyma'r peth, os ydych chi erioed wedi gweithio gyda chasglwyr boncyffion, yna mae'n debyg eich bod chi wedi gweld yr hyn maen nhw'n ei addo i chi, y gallant weithio gyda logiau aml-linell, gwybod sut i'w casglu, ac ati. Mewn gwirionedd, yn fy marn i, ni all un casglwr heddiw gasglu logiau aml-linell fel arfer, yn llawn a heb wallau. Mewn ffordd ddynol, fel ei fod yn gyfleus ac yn ddi-wall.
Ond mae olrhain pentwr bob amser yn logiau aml-linell a sut i'w hosgoi. Y cwestiwn yma yw bod log yn gofnod o ddigwyddiad, ac nid yw stactrace yn log mewn gwirionedd. Os byddwn yn casglu logiau a'u rhoi yn rhywle yn Elasticsearch ac yna'n tynnu graffiau ohonynt, adeiladu rhai adroddiadau o weithgarwch defnyddwyr ar eich gwefan, yna pan fyddwch chi'n cael olrhain pentwr, mae'n golygu bod rhywbeth annisgwyl yn digwydd mewn sefyllfa heb ei drin yn eich cais. Ac mae'n gwneud synnwyr lanlwytho olrhain pentwr yn awtomatig yn rhywle i mewn i system sy'n gallu eu holrhain.
Mae hwn yn feddalwedd (yr un Sentry) sy'n cael ei wneud yn benodol i weithio gydag olrhain pentwr. Gall greu tasgau awtomataidd ar unwaith, eu neilltuo i rywun, rhybuddio pan fydd olion stac yn digwydd, grwpio'r olion stac hyn yn ôl un math, ac ati. Mewn egwyddor, nid yw'n gwneud llawer o synnwyr i siarad am stacraces pan fyddwn yn siarad am logiau, oherwydd mae'r rhain, wedi'r cyfan, yn bethau gwahanol gyda gwahanol ddibenion.
Ffurfweddiad
Nesaf rydym yn siarad am gyfluniad yn Kubernetes: beth i'w wneud ag ef a sut y dylid ffurfweddu cymwysiadau y tu mewn i Kubernetes. Yn gyffredinol, dywedaf fel arfer nad yw Docker yn ymwneud â chynwysyddion. Mae pawb yn gwybod bod Docker yn ymwneud â chynwysyddion, hyd yn oed y rhai nad ydyn nhw wedi gweithio llawer gyda Docker. Dywedaf eto, nid yw Docker yn ymwneud â chynwysyddion.
Mae Docker, yn fy marn i, yn ymwneud â safonau. Ac mae safonau ar gyfer bron popeth: safonau ar gyfer adeiladu eich cais, safonau ar gyfer gosod eich cais.
A'r peth hwn - rydym yn ei ddefnyddio o'r blaen, daeth yn arbennig o boblogaidd gyda dyfodiad cynwysyddion - gelwir y peth hwn yn newidynnau ENV (amgylchedd), hynny yw, newidynnau amgylchedd sydd yn eich system weithredu. Yn gyffredinol, mae hon yn ffordd ddelfrydol o ffurfweddu'ch cais, oherwydd os oes gennych chi gymwysiadau yn JAVA, Python, Go, Perl, mae Duw yn gwahardd, a gallant i gyd ddarllen gwesteiwr y gronfa ddata, defnyddiwr cronfa ddata, newidynnau cyfrinair cronfa ddata, yna mae'n ddelfrydol. Mae gennych chi gymwysiadau mewn pedair iaith wahanol wedi'u ffurfweddu yn y cynllun cronfa ddata yn yr un modd. Nid oes mwy o gyfluniadau gwahanol.
Gellir ffurfweddu popeth gan ddefnyddio newidynnau ENV. Pan fyddwn yn siarad am Kubernetes, mae ffordd wych o ddatgan newidynnau ENV y tu mewn i Deployment. Yn unol â hynny, os ydym yn sôn am ddata cyfrinachol, yna gallwn wthio data cyfrinachol o newidynnau ENV (cyfrineiriau i gronfeydd data, ac ati) yn gyfrinach ar unwaith, creu clwstwr cyfrinachol a nodi yn y disgrifiad ENV yn Defnyddio nad ydym yn datgan yn uniongyrchol. bydd gwerth y newidyn hwn, a gwerth y newidyn cyfrinair cronfa ddata hwn yn cael eu darllen o'r gyfrinach. Mae hwn yn ymddygiad safonol Kubernetes. A dyma'r opsiwn mwyaf delfrydol i ffurfweddu'ch cymwysiadau. Dim ond ar lefel y cod, eto mae hyn yn berthnasol i ddatblygwyr. Os ydych chi'n DevOps, gallwch ofyn: “Bois, dysgwch eich cais i ddarllen newidynnau amgylchedd. A byddwn ni i gyd yn hapus.”
Os yw pawb yn y cwmni yn darllen yr un newidynnau amgylchedd a enwir, yna mae hynny'n wych. Fel nad yw'n digwydd bod rhai yn aros am y gronfa ddata postgres, mae eraill yn aros am enw'r gronfa ddata, mae eraill yn aros am rywbeth arall, mae eraill yn aros am dbn o ryw fath, fel bod, yn unol â hynny, unffurfiaeth.
Daw'r broblem pan fydd gennych chi gymaint o newidynnau amgylchedd eich bod chi'n agor Defnydd - ac mae yna bum cant o linellau o newidynnau amgylchedd. Yn yr achos hwn, yn syml, mae gennych newidynnau amgylchedd sydd wedi tyfu'n rhy fawr - ac nid oes angen i chi arteithio'ch hun mwyach. Yn yr achos hwn, byddai'n gwneud synnwyr i ddechrau defnyddio configs. Hynny yw, hyfforddwch eich cais i ddefnyddio configs.
Yr unig gwestiwn yw nad yw cyfluniadau yn eich barn chi. Nid yw Config.pi yn config sy'n gyfleus i'w ddefnyddio. Neu ryw ffurfwedd yn eich fformat eich hun, fel arall yn ddawnus - nid dyma'r cyfluniad yr wyf yn ei olygu ychwaith.
Yr hyn rwy'n sôn amdano yw ffurfweddiad mewn fformatau derbyniol, hynny yw, y safon fwyaf poblogaidd o bell ffordd yw'r safon .yaml. Mae'n amlwg sut i'w ddarllen, mae'n ddarllenadwy gan bobl, mae'n amlwg sut i'w ddarllen o'r cais.
Yn unol â hynny, yn ogystal â YAML, gallwch hefyd, er enghraifft, ddefnyddio JSON, mae dosrannu bron mor gyfleus ag YAML o ran darllen cyfluniad y cais oddi yno. Mae'n amlwg yn fwy anghyfleus i bobl ddarllen. Gallwch roi cynnig ar y fformat, a la ini. Mae'n eithaf cyfleus i'w ddarllen, o safbwynt dynol, ond gall fod yn anghyfleus i'w brosesu'n awtomatig, yn yr ystyr, os ydych chi erioed eisiau cynhyrchu eich cyfluniadau eich hun, efallai y bydd y fformat ini eisoes yn anghyfleus i'w gynhyrchu.
Ond beth bynnag, pa bynnag fformat a ddewiswch, y pwynt yw ei fod yn gyfleus iawn o safbwynt Kubernetes. Gallwch chi roi'ch cyfluniad cyfan y tu mewn i Kubernetes, yn y ConfigMap. Ac yna cymerwch y configmap hwn a gofynnwch iddo gael ei osod y tu mewn i'ch pod mewn rhyw gyfeiriadur penodol, lle bydd eich cais yn darllen y ffurfweddiad o'r configmap hwn fel pe bai'n ffeil yn unig. Dyma, mewn gwirionedd, yw'r hyn sy'n dda i'w wneud pan fydd gennych lawer o opsiynau ffurfweddu yn eich cais. Neu dim ond rhyw fath o strwythur cymhleth ydyw, mae yna nythu.
Os oes gennych chi configmap, yna gallwch chi ddysgu'ch cais yn dda iawn, er enghraifft, olrhain newidiadau yn awtomatig yn y ffeil lle mae'r configmap wedi'i osod, a hefyd ail-lwytho'ch cais yn awtomatig pan fydd y cyfluniadau'n newid. Yn gyffredinol byddai hwn yn opsiwn delfrydol.
Unwaith eto, siaradais am hyn eisoes - nid yw gwybodaeth gyfrinachol yn y configmap, nid yw gwybodaeth gyfrinachol mewn newidynnau, nid yw gwybodaeth gyfrinachol mewn cyfrinachau. Oddi yno, cysylltwch y wybodaeth gyfrinachol hon â diplomyddiaeth. Fel arfer rydym yn storio pob disgrifiad o wrthrychau Kubernetes, gosodiadau, configmaps, gwasanaethau mewn git. Yn unol â hynny, mae rhoi'r cyfrinair i'r gronfa ddata mewn git, hyd yn oed os mai dyma'ch git, sydd gennych yn fewnol yn y cwmni, yn syniad drwg. Oherwydd, o leiaf, mae git yn cofio popeth ac nid yw tynnu cyfrineiriau oddi yno mor hawdd.
Gwiriad iechyd
Y pwynt nesaf yw'r peth hwn a elwir yn Archwiliad iechyd. Yn gyffredinol, gwiriad Iechyd yw gwirio bod eich cais yn gweithio. Ar yr un pryd, rydym yn fwyaf aml yn sôn am rai cymwysiadau gwe, y maent, yn unol â hynny, o safbwynt gwiriad iechyd (mae'n well peidio â chyfieithu yma ac ymhellach) bydd hwn yn URL arbennig, y maent yn ei brosesu fel safon, maen nhw'n ei wneud fel arfer /health.
Wrth gyrchu'r URL hwn, yn unol â hynny, mae ein cais yn dweud naill ai “ie, iawn, mae popeth yn iawn gyda mi, 200” neu “na, nid yw popeth yn iawn gyda mi, rhyw 500.” Yn unol â hynny, os nad http yw ein cais, nid cymhwysiad gwe, rydym bellach yn sôn am ryw fath o ellyll, gallwn ddarganfod sut i wneud gwiriadau iechyd. Hynny yw, nid oes angen, os nad http yw'r cais, yna mae popeth yn gweithio heb wiriad iechyd ac ni ellir gwneud hyn mewn unrhyw ffordd. Gallwch chi ddiweddaru rhywfaint o wybodaeth yn y ffeil o bryd i'w gilydd, gallwch chi ddod o hyd i orchymyn arbennig ar gyfer eich ellyll, fel, daemon status, a fydd yn dweud “ie, mae popeth yn iawn, mae'r ellyll yn gweithio, mae'n fyw.”
Beth yw ei ddiben? Mae'n debyg mai'r peth cyntaf ac amlycaf yw pam mae angen gwiriad iechyd - i ddeall bod y cais yn gweithio. Hynny yw, mae'n wirion, pan mae i fyny nawr, mae'n edrych fel ei fod yn gweithio, felly gallwch chi fod yn siŵr ei fod yn gweithio. Ac mae'n ymddangos bod y cymhwysiad yn rhedeg, mae'r cynhwysydd yn rhedeg, mae'r enghraifft yn gweithio, mae popeth yn iawn - ac yna mae'r defnyddwyr eisoes wedi torri'r holl rifau ffôn o gefnogaeth dechnegol i ffwrdd ac yn dweud “beth ydych chi ..., chi syrthio i gysgu, does dim byd yn gweithio.”
Mae gwiriad iechyd yn ffordd o weld o safbwynt y defnyddiwr ei fod yn gweithio. Un o'r dulliau. Gadewch i ni ei roi fel hyn. O safbwynt Kubernetes, mae hyn hefyd yn ffordd o ddeall pryd mae'r cais yn dechrau, oherwydd rydym yn deall bod gwahaniaeth rhwng pryd y lansiwyd, creu a chychwyn y cynhwysydd, a phryd y lansiwyd y cais yn uniongyrchol yn y cynhwysydd hwn. Oherwydd os byddwn yn cymryd rhywfaint o gais java ar gyfartaledd ac yn ceisio ei lansio yn y doc, yna am ddeugain eiliad, neu hyd yn oed munud, neu hyd yn oed ddeg, gall ddechrau'n iawn. Yn yr achos hwn, gallwch chi o leiaf guro ar ei borthladdoedd, ni fydd yn ateb yno, hynny yw, nid yw eto'n barod i dderbyn traffig.
Unwaith eto, gyda chymorth gwiriad iechyd a gyda chymorth y ffaith ein bod yn troi yma, gallwn ddeall yn Kubernetes bod nid yn unig y cynhwysydd wedi codi yn y cais, ond mae'r cais ei hun wedi dechrau, mae eisoes yn ymateb i'r gwiriad iechyd, sy'n golygu y gallwn anfon traffig yno.
Yr hyn rydw i'n siarad amdano nawr yw profion Parodrwydd / Bywiogrwydd o fewn Kubernetes; yn unol â hynny, mae ein profion parodrwydd yn gyfrifol am argaeledd y cais wrth gydbwyso. Hynny yw, os cynhelir profion parodrwydd yn y cais, yna mae popeth yn iawn, mae traffig cleientiaid yn mynd i'r cais. Os na chynhelir profion parodrwydd, yna nid yw'r cais yn cymryd rhan, nid yw'r achos penodol hwn yn cymryd rhan mewn cydbwyso, caiff ei dynnu oddi wrth gydbwyso, nid yw traffig cleientiaid yn llifo. Yn unol â hynny, mae angen profion bywoliaeth o fewn Kubernetes fel y gellir ei ailgychwyn os aiff y cais yn sownd. Os nad yw'r prawf bywiogrwydd yn gweithio ar gyfer cais sy'n cael ei ddatgan yn Kubernetes, yna nid yw'r cais yn cael ei dynnu oddi ar y cydbwysedd yn unig, mae'n cael ei ailgychwyn.
A dyma bwynt pwysig yr hoffwn ei grybwyll: o safbwynt ymarferol, mae'r prawf parodrwydd fel arfer yn cael ei ddefnyddio'n amlach ac mae ei angen yn amlach na'r prawf bywiogrwydd. Hynny yw, nid yw datgan yn ddifeddwl y ddau brawf parodrwydd a bywiogrwydd, oherwydd gall Kubernetes wneud hynny, a gadewch i ni ddefnyddio popeth y gall ei wneud, yn syniad da iawn. Byddaf yn egluro pam. Oherwydd pwynt rhif dau mewn profion yw y byddai'n syniad da gwirio'r gwasanaeth sylfaenol yn eich gwiriadau iechyd. Mae hyn yn golygu os oes gennych raglen we sy'n rhoi rhywfaint o wybodaeth, y mae'n rhaid iddo yn ei dro, yn naturiol, ei gymryd o rywle. Mewn cronfa ddata, er enghraifft. Wel, mae'n arbed y wybodaeth sy'n dod i mewn i'r API REST hwn i'r un gronfa ddata. Yna, yn unol â hynny, os yw'ch gwiriad iechyd yn ymateb yn syml fel slashhealth y cysylltwyd ag ef, mae'r rhaglen yn dweud “200, iawn, mae popeth yn iawn,” ac ar yr un pryd mae cronfa ddata eich cais yn anhygyrch, ac mae'r rhaglen archwiliad iechyd yn dweud “200, iawn, mae popeth yn iawn ” - Mae hwn yn wiriad iechyd gwael. Nid dyma sut y dylai weithio.
Hynny yw, eich cais, pan ddaw cais ato /health, nid yw'n ymateb yn unig, “200, iawn”, mae'n mynd yn gyntaf, er enghraifft, i'r gronfa ddata, yn ceisio cysylltu ag ef, yn gwneud rhywbeth sylfaenol iawn yno, fel dewis un, dim ond yn gwirio bod cysylltiad yn y cronfa ddata a gallwch gwestiynu'r gronfa ddata. Pe bai hyn i gyd yn llwyddiannus, yna'r ateb yw "200, iawn." Os nad yw'n llwyddiannus, mae'n dweud bod gwall, nid yw'r gronfa ddata ar gael.
Felly, yn hyn o beth, dychwelaf eto at y profion Parodrwydd / Bywiogrwydd - pam mae'n debygol y bydd angen prawf parodrwydd arnoch chi, ond mae prawf bywiogrwydd dan sylw. Oherwydd os disgrifiwch wiriadau iechyd yn union fel yr wyf newydd ei ddweud, yna bydd yn troi allan nad yw ar gael yn yr enghraifftв или со всех instancemewn cronfa ddata, er enghraifft. Pan wnaethoch chi ddatgan prawf parodrwydd, dechreuodd ein harchwiliadau iechyd fethu, ac yn unol â hynny mae'r holl gymwysiadau nad yw'r gronfa ddata yn hygyrch ohonynt, yn syml yn cael eu troi i ffwrdd o gydbwyso ac mewn gwirionedd yn “hongian” mewn cyflwr esgeulus ac yn aros i'w cronfeydd data ddod i ben. gwaith.
Os ydym wedi datgan prawf bywiogrwydd, yna dychmygwch, mae ein cronfa ddata wedi torri, ac yn eich Kubernetes mae hanner popeth yn dechrau ailgychwyn oherwydd bod y prawf bywiogrwydd yn methu. Mae hyn yn golygu bod angen i chi ailgychwyn. Nid dyma'r hyn rydych chi ei eisiau o gwbl, roedd gen i brofiad personol yn ymarferol hyd yn oed. Cawsom raglen sgwrsio a ysgrifennwyd yn JS a'i fwydo i gronfa ddata Mongo. A'r broblem oedd ei fod ar ddechrau fy ngwaith gyda Kubernetes, fe wnaethom ddisgrifio parodrwydd, bywiogrwydd profion ar yr egwyddor y gall Kubernetes ei wneud, felly byddwn yn ei ddefnyddio. Yn unol â hynny, ar ryw adeg daeth Mongo ychydig yn “ddiflas” a dechreuodd y sampl fethu. Yn unol â hynny, yn ôl y prawf glaw, dechreuodd y codennau “lladd”.
Fel y deallwch, pan fyddant yn cael eu “lladd”, sgwrs yw hon, hynny yw, mae yna lawer o gysylltiadau gan gleientiaid yn hongian arno. Maent hefyd yn cael eu "lladd" - na, nid cleientiaid, dim ond cysylltiadau - nid i gyd ar yr un pryd, ac oherwydd y ffaith nad ydynt yn cael eu lladd ar yr un pryd, rhai yn gynharach, rhai yn ddiweddarach, nid ydynt yn dechrau ar yr un pryd. amser. Yn ogystal â hap safonol, ni allwn ragweld gyda chywirdeb milieiliadau amser cychwyn y cais bob tro, felly maen nhw'n ei wneud un achos ar y tro. Mae un infospot yn codi, yn cael ei ychwanegu at y cydbwysedd, mae pob cleient yn dod yno, ni all wrthsefyll llwyth o'r fath, oherwydd ei fod ar ei ben ei hun, ac, yn fras, mae dwsin ohonynt yn gweithio yno, ac mae'n disgyn. Mae'r un nesaf yn codi, mae'r llwyth cyfan arno, mae hefyd yn cwympo. Wel, mae'r cwympiadau hyn yn parhau i raeadru. Yn y diwedd, sut y cafodd hyn ei ddatrys - roedd yn rhaid i ni atal traffig defnyddwyr yn llym i'r cais hwn, gadael i bob achos godi ac yna cychwyn yr holl draffig defnyddwyr ar unwaith fel ei fod eisoes wedi'i ddosbarthu ymhlith pob un o'r deg achos.
Oni bai am y prawf bywiogrwydd hwn yn cael ei gyhoeddi, a fyddai'n gorfodi'r cyfan i ailgychwyn, byddai'r cais wedi delio'n iawn. Ond mae popeth o gydbwyso yn anabl i ni, oherwydd bod y cronfeydd data yn anhygyrch ac mae pob defnyddiwr wedi “syrthio”. Yna, pan fydd y gronfa ddata hon ar gael, mae popeth yn cael ei gynnwys wrth gydbwyso, ond nid oes angen i geisiadau ddechrau eto, ac nid oes angen gwastraffu amser ac adnoddau ar hyn. Maen nhw i gyd yma eisoes, maen nhw'n barod ar gyfer traffig, felly mae traffig yn agor, mae popeth yn iawn - mae'r cais yn ei le, mae popeth yn parhau i weithio.
Felly, mae profion parodrwydd a bywiogrwydd yn wahanol, hyd yn oed ar ben hynny, yn ddamcaniaethol gallwch chi wneud gwahanol wiriadau iechyd, un math radii, un math liv, er enghraifft, a gwirio gwahanol bethau. Yn ystod profion parodrwydd, gwiriwch eich ôl-lenni. Ac ar brawf bywiogrwydd, er enghraifft, nid ydych yn gwirio o safbwynt mai dim ond cais sy'n ymateb yw'r prawf bywiogrwydd yn gyffredinol, os yw'n gallu ymateb o gwbl.
Oherwydd mai’r prawf bywoliaeth, ar y cyfan, yw pan rydyn ni’n “sownd.” Mae dolen ddiddiwedd wedi dechrau neu rywbeth arall - a dim mwy o geisiadau'n cael eu prosesu. Felly, mae'n gwneud synnwyr hyd yn oed eu gwahanu - a gweithredu rhesymeg wahanol ynddynt.
O ran yr hyn y mae angen i chi ei ateb pan fyddwch chi'n cael prawf, pan fyddwch chi'n cynnal gwiriadau iechyd. Dim ond poen mewn gwirionedd ydyw. Mae’n debyg y bydd y rhai sy’n gyfarwydd â hyn yn chwerthin – ond o ddifrif, rwyf wedi gweld gwasanaethau yn fy mywyd sy’n ateb “200” mewn XNUMX% o achosion. Hynny yw, pwy sy'n llwyddiannus. Ond ar yr un pryd yng nghorff yr ymateb maen nhw'n ysgrifennu "cyfryw gamgymeriad."
Hynny yw, mae'r statws ymateb yn dod i chi - mae popeth yn llwyddiannus. Ond ar yr un pryd, rhaid i chi ddosrannu'r corff, oherwydd mae'r corff yn dweud "sori, daeth y cais i ben gyda gwall" a dim ond realiti yw hyn. Gwelais hyn mewn bywyd go iawn.
Ac fel nad yw rhai pobl yn ei chael hi'n ddoniol, ac eraill yn ei chael hi'n boenus iawn, mae'n dal yn werth cadw at reol syml. Mewn gwiriadau iechyd, ac mewn egwyddor wrth weithio gyda chymwysiadau gwe.
Os aeth popeth yn iawn, yna atebwch gyda'r ddau ganfed ateb. Mewn egwyddor, bydd unrhyw ateb dau gant yn addas i chi. Os darllenwch ragsy yn dda iawn ac yn gwybod bod rhai statws ymateb yn wahanol i rai eraill, atebwch gyda'r rhai priodol: 204, 5, 10, 15, beth bynnag. Os nad yw'n dda iawn, yna dim ond “dau sero sero.” Os aiff popeth yn wael ac nad yw'r gwiriad iechyd yn ymateb, yna atebwch gydag unrhyw bum canfed. Unwaith eto, os ydych chi'n deall sut i ymateb, sut mae gwahanol statws ymateb yn wahanol i'w gilydd. Os nad ydych chi'n deall, yna 502 yw eich opsiwn i ymateb i wiriadau iechyd os aiff rhywbeth o'i le.
Mae hwn yn bwynt arall, rwyf am ddychwelyd ychydig am wirio'r gwasanaethau sylfaenol. Os byddwch chi'n dechrau, er enghraifft, gwirio'r holl wasanaethau sylfaenol sy'n sefyll y tu ôl i'ch cais - popeth yn gyffredinol. Yr hyn a gawn o safbwynt pensaernïaeth microwasanaeth, mae gennym gysyniad o'r fath â "cyplu isel" - hynny yw, pan fo'ch gwasanaethau'n dibynnu'n fach iawn ar ei gilydd. Os bydd un ohonynt yn methu, bydd y lleill heb y swyddogaeth hon yn parhau i weithio. Nid yw rhai o'r swyddogaethau yn gweithio. Yn unol â hynny, os ydych yn clymu'r holl wiriadau iechyd â'i gilydd, yna byddwch yn y pen draw ag un peth yn methu yn y seilwaith, ac oherwydd iddo ostwng, mae holl wiriadau iechyd yr holl wasanaethau hefyd yn dechrau methu - ac mae mwy o seilwaith yn gyffredinol ar gyfer y pensaernïaeth microservice gyfan Rhif. Aeth popeth yn dywyll yno.
Felly, rwyf am ailadrodd hyn eto bod angen ichi wirio’r gwasanaethau sylfaenol, y rheini hebddynt na all eich cais mewn cant y cant o achosion wneud ei waith. Hynny yw, mae'n rhesymegol, os oes gennych API REST lle mae'r defnyddiwr yn arbed i'r gronfa ddata neu'n adfer o'r gronfa ddata, yna yn absenoldeb cronfa ddata, ni allwch warantu gwaith gyda'ch defnyddwyr.
Ond os yw'ch defnyddwyr, pan fyddwch chi'n eu tynnu allan o'r gronfa ddata, wedi'u cyfoethogi hefyd â rhywfaint o fetadata arall, o backend arall, y byddwch chi'n ei nodi cyn anfon ymateb i'r blaen - ac nid yw'r ôl-wyneb hwn ar gael, mae hyn yn golygu eich bod chi'n rhoi eich ateb heb unrhyw ran o'r metadata.
Nesaf, mae gennym hefyd un o'r materion poenus wrth lansio ceisiadau.
Mewn gwirionedd, nid yw hyn yn berthnasol i Kubernetes yn unig ar y cyfan; fe ddigwyddodd felly bod diwylliant rhyw fath o ddatblygiad torfol a DevOps yn benodol wedi dechrau lledaenu tua'r un amser â Kubernetes. Felly, ar y cyfan, mae'n ymddangos bod angen i chi gau'ch cais yn osgeiddig heb Kubernetes. Hyd yn oed cyn Kubernetes, gwnaeth pobl hyn, ond gyda dyfodiad Kubernetes, dechreuon ni siarad amdano en masse.
Diffoddwch Graceful
Yn gyffredinol, beth yw Diffoddwch Graceful a pham mae ei angen? Mae hyn yn ymwneud â phan fydd eich cais yn chwalu am ryw reswm, mae angen ichi ei wneud app stop - neu os ydych yn derbyn, er enghraifft, signal o'r system weithredu, rhaid i'ch cais ei ddeall a gwneud rhywbeth yn ei gylch. Y senario waethaf, wrth gwrs, yw pan fydd eich cais yn derbyn SITERM ac mae fel “SITERM, gadewch i ni aros, gweithio, gwneud dim byd.” Mae hwn yn opsiwn hollol wael.
Opsiwn sydd bron yr un mor ddrwg yw pan fydd eich cais yn derbyn SIGTERM ac mae fel “fe ddywedon nhw segterm, mae hynny'n golygu ein bod ni'n dod i ben, nid wyf wedi gweld, nid wyf yn gwybod unrhyw geisiadau gan ddefnyddwyr, nid wyf yn gwybod pa fath o ceisiadau rydw i wedi gweithio arnyn nhw ar hyn o bryd, medden nhw SITERM, mae hynny'n golygu ein bod ni'n dod i ben " Mae hwn hefyd yn opsiwn gwael.
Pa opsiwn sy'n dda? Y pwynt cyntaf yw cymryd i ystyriaeth cwblhau gweithrediadau. Opsiwn da yw i'ch gweinydd barhau i ystyried yr hyn y mae'n ei wneud os yw'n derbyn SITERM.
Mae SITERM yn gau meddal, mae wedi'i ddylunio'n arbennig, gellir ei ryng-gipio ar lefel y cod, gellir ei brosesu, dywedwch nawr, arhoswch, byddwn yn gorffen y gwaith sydd gennym yn gyntaf, yna byddwn yn gadael.
O safbwynt Kubernetes, dyma sut olwg sydd arno. Pan rydyn ni'n dweud wrth god sy'n rhedeg yng nghlwstwr Kubernetes, “stopiwch, ewch i ffwrdd,” neu rydyn ni'n cael ein hailddechrau, neu mae diweddariad yn digwydd pan fydd Kubernetes yn ail-greu'r codennau, mae Kubernetes yn anfon yr un neges SITERM yn unig i'r pod, yn aros am peth amser, a , dyma'r amser y mae'n aros, mae hefyd wedi'i ffurfweddu, mae paramedr mor arbennig mewn diplomâu ac fe'i gelwir yn Graceful ShutdownTimeout. Fel y deallwch, nid yw'n cael ei alw'n hynny am ddim, ac nid am ddim yr ydym yn siarad amdano nawr.
Yno, gallwn ddweud yn benodol pa mor hir y mae angen i ni aros rhwng yr amser y byddwn yn anfon SITERM i'r cais a phan ddeallwn ei bod yn ymddangos bod y cais wedi mynd yn wallgof am rywbeth neu ei fod yn “sownd” ac nad yw'n mynd i ddod i ben - ac mae angen i ni wneud hynny. anfon SIGKILL iddo, hynny yw, caled gwblhau ei waith. Hynny yw, yn unol â hynny, mae gennym ryw fath o daemon yn rhedeg, mae'n prosesu gweithrediadau. Rydym yn deall nad yw ein gweithrediadau y mae'r ellyll yn gweithio arnynt ar gyfartaledd yn para mwy na 30 eiliad ar y tro. Yn unol â hynny, pan fydd SITERM yn cyrraedd, rydym yn deall y gall ein daemon, ar y mwyaf, orffen 30 eiliad ar ôl SITERM. Rydyn ni'n ei ysgrifennu, er enghraifft, 45 eiliad rhag ofn ac yn dweud bod SITERM. Ar ôl hynny rydym yn aros 45 eiliad. Mewn theori, yn ystod y cyfnod hwn dylai'r cythraul fod wedi cwblhau ei waith a dod i ben ei hun. Ond os na allai yn sydyn, mae'n golygu ei fod yn fwyaf tebygol o fynd yn sownd - nid yw bellach yn prosesu ein ceisiadau fel arfer. Ac mewn 45 eiliad gallwch chi, mewn gwirionedd, ei hoelio i lawr yn ddiogel.
Ac yma, mewn gwirionedd, gellir cymryd hyd yn oed 2 agwedd i ystyriaeth. Yn gyntaf, deallwch, os cawsoch gais, eich bod wedi dechrau gweithio gydag ef rywsut ac na wnaethoch roi ymateb i'r defnyddiwr, ond cawsoch SITERM, er enghraifft. Mae'n gwneud synnwyr ei fireinio a rhoi ateb i'r defnyddiwr. Dyma bwynt rhif un yn hyn o beth. Pwynt rhif dau yma yw os byddwch chi'n ysgrifennu'ch cais eich hun, yn gyffredinol yn adeiladu'r bensaernïaeth yn y fath fodd fel eich bod chi'n derbyn cais am eich cais, yna rydych chi'n dechrau rhywfaint o waith, yn dechrau lawrlwytho ffeiliau o rywle, yn lawrlwytho cronfa ddata, a beth bynnag. - Hynny. Yn gyffredinol, mae eich defnyddiwr, eich cais yn hongian am hanner awr ac yn aros i chi ei ateb - yna, yn fwyaf tebygol, mae angen i chi weithio ar y bensaernïaeth. Hynny yw, ystyriwch hyd yn oed synnwyr cyffredin, os yw'ch gweithrediadau'n fyr, yna mae'n gwneud synnwyr anwybyddu SITERM a'i addasu. Os yw eich gweithrediadau yn hir, yna nid yw'n gwneud unrhyw synnwyr i anwybyddu SITERM yn yr achos hwn. Mae'n gwneud synnwyr i ailgynllunio'r bensaernïaeth i osgoi gweithrediadau mor hir. Fel nad yw defnyddwyr yn hongian o gwmpas ac yn aros. Nid wyf yn gwybod, gwnewch ryw fath o websocket yno, gwnewch fachau gwrthdroi y bydd eich gweinydd eisoes yn eu hanfon at y cleient, unrhyw beth arall, ond peidiwch â gorfodi'r defnyddiwr i hongian am hanner awr a dim ond aros am sesiwn nes i chi atebwch ef. Oherwydd mae'n anrhagweladwy lle gallai dorri.
Pan ddaw eich cais i ben, dylech ddarparu cod ymadael priodol. Hynny yw, os gofynnwyd i'ch cais gau, stopio, ac roedd yn gallu atal ei hun fel arfer, yna nid oes angen ichi ddychwelyd rhyw fath o god ymadael 1,5,255 ac ati. Mae unrhyw beth nad yw'n god sero, o leiaf mewn systemau Linux, rwy'n siŵr o hyn, yn cael ei ystyried yn aflwyddiannus. Hynny yw, ystyrir bod eich cais yn yr achos hwn wedi dod i ben gyda gwall. Yn unol â hynny, mewn ffordd gyfeillgar, os cwblhawyd eich cais heb wall, rydych chi'n dweud 0 ar yr allbwn. Os bydd eich cais yn methu am ryw reswm, rydych yn dweud non-0 yn yr allbwn. A gallwch chi weithio gyda'r wybodaeth hon.
A'r opsiwn olaf. Mae'n ddrwg pan fydd eich defnyddiwr yn anfon cais ac yn hongian am hanner awr wrth i chi ei brosesu. Ond yn gyffredinol, hoffwn ddweud hefyd am yr hyn sy'n werth chweil yn gyffredinol o ochr y cleient. Nid oes ots a oes gennych raglen symudol, pen blaen, ac ati. Mae angen cymryd i ystyriaeth y gellir terfynu sesiwn y defnyddiwr yn gyffredinol, gall unrhyw beth ddigwydd. Gall cais gael ei anfon, er enghraifft, heb ei brosesu'n ddigonol a dim ymateb yn cael ei ddychwelyd. Dylai eich pen blaen neu'ch cymhwysiad symudol - unrhyw ben blaen yn gyffredinol, gadewch i ni ei roi felly - gymryd hyn i ystyriaeth. Os ydych chi'n gweithio gyda gwe-socedi, dyma'r boen waethaf i mi ei chael erioed.
Pan nad yw datblygwyr rhai sgyrsiau rheolaidd yn gwybod hynny, mae'n troi allan, gall y websocket dorri. Iddyn nhw, pan fydd rhywbeth yn digwydd yn y dirprwy, rydyn ni'n newid y ffurfwedd, ac mae'n ail-lwytho. Yn naturiol, mae pob sesiwn hirhoedlog yn cael ei rhwygo yn yr achos hwn. Daw datblygwyr atom a dweud: “Bois, beth ydych chi'n ei wneud, mae'r sgwrs wedi torri i lawr ar gyfer ein holl gleientiaid!” Rydyn ni'n dweud wrthyn nhw: “Beth ydych chi'n ei wneud? Ydy'ch cleientiaid yn methu ag ailgysylltu? Maen nhw’n dweud: “Na, rydyn ni angen i’r sesiynau beidio â chael eu rhwygo.” Yn fyr, mae hyn mewn gwirionedd yn nonsens. Mae angen ystyried ochr y cleient. Yn enwedig, fel y dywedaf, gyda sesiynau hirhoedlog fel gwe-socedi, gall dorri ac, heb i'r defnyddiwr sylwi, mae angen i chi allu ailosod sesiynau o'r fath. Ac yna mae popeth yn berffaith.
Adnoddau
A dweud y gwir, yma byddaf yn dweud stori syth wrthych. Eto o fywyd go iawn. Y peth salaf a glywais erioed am adnoddau.
Adnoddau yn yr achos hwn, rwy'n golygu, rhyw fath o geisiadau, terfynau y gallwch eu rhoi ar godau yn eich clystyrau Kubernetes. Y peth mwyaf doniol a glywais gan ddatblygwr... Dywedodd un o fy nghyd-ddatblygwyr mewn gweithle blaenorol unwaith: “Ni fydd fy nghais yn dechrau yn y clwstwr.” Edrychais i weld nad oedd yn dechrau, ond naill ai nid oedd yn ffitio i mewn i'r adnoddau, neu roeddent wedi gosod terfynau bach iawn. Yn fyr, ni all y cais ddechrau oherwydd adnoddau. Rwy’n dweud: “Ni fydd yn dechrau oherwydd adnoddau, chi sy’n penderfynu faint sydd ei angen arnoch ac yn gosod gwerth digonol.” Dywed: “Pa fath o adnoddau?” Dechreuais egluro iddo fod angen gosod Kubernetes, cyfyngiadau ar geisiadau a blah, blah, blah. Gwrandawodd y dyn am bum munud, nodio a dweud: “Fe ddes i yma i weithio fel datblygwr, dydw i ddim eisiau gwybod dim am unrhyw adnoddau. Des i yma i ysgrifennu cod a dyna ni.” Mae'n drist. Mae hwn yn gysyniad trist iawn o safbwynt datblygwr. Yn enwedig yn y byd modern, fel petai, o ddevops blaengar.
Pam fod angen adnoddau o gwbl? Mae 2 fath o adnoddau yn Kubernetes. Gelwir rhai yn geisiadau, gelwir eraill yn derfynau. Yn ôl adnoddau byddwn yn deall mai dim ond dau gyfyngiad sylfaenol sydd bob amser yn y bôn. Hynny yw, terfynau amser CPU a therfynau RAM ar gyfer cynhwysydd sy'n rhedeg yn Kubernetes.
Mae terfyn yn gosod terfyn uchaf ar sut y gellir defnyddio adnodd yn eich cais. Hynny yw, yn unol â hynny, os ydych chi'n dweud 1GB o RAM yn y terfynau, yna ni fydd eich cais yn gallu defnyddio mwy na 1GB o RAM. Ac os yw'n sydyn eisiau ac yn ceisio gwneud hyn, yna bydd proses o'r enw oom killer, allan o gof, hynny yw, yn dod i ladd eich cais - hynny yw, bydd yn ailgychwyn yn syml. Ni fydd ceisiadau yn ailgychwyn yn seiliedig ar CPU. O ran CPU, os yw cais yn ceisio defnyddio llawer, yn fwy na'r hyn a nodir yn y terfynau, bydd y CPU yn cael ei ddewis yn llym. Nid yw hyn yn arwain at ailgychwyn. Dyma'r terfyn - dyma'r terfyn uchaf.
Ac mae cais. Cais yw sut mae Kubernetes yn deall sut mae'r nodau yn eich clwstwr Kubernetes yn cael eu llenwi â chymwysiadau. Hynny yw, mae cais yn fath o ymrwymiad yn eich cais. Mae'n dweud yr hyn rydw i eisiau ei ddefnyddio: “Hoffwn i chi gadw cymaint â hyn o CPU a chymaint o gof i mi.” Cyfatebiaeth mor syml. Beth os oes gennym ni nod sydd â chyfanswm o 8 CPU, wn i ddim. Ac mae pod yn cyrraedd yno, y mae ei geisiadau'n dweud 1 CPU, sy'n golygu bod gan y nod 7 CPUs ar ôl. Hynny yw, yn unol â hynny, cyn gynted ag y bydd codennau 8 yn cyrraedd y nod hwn, ac mae gan bob un ohonynt 1 CPU yn eu ceisiadau, mae'r nod, fel pe bai o safbwynt Kubernetes, wedi rhedeg allan o CPU ac ni all mwy o godau gyda cheisiadau fod. ei lansio ar y nod hwn. Os yw'r holl nodau'n rhedeg allan o CPU, yna bydd Kubernetes yn dechrau dweud nad oes nodau addas yn y clwstwr i redeg eich codennau oherwydd bod y CPU wedi rhedeg allan.
Pam mae angen ceisiadau a pham heb geisiadau, rwy'n meddwl nad oes angen lansio unrhyw beth yn Kubernetes? Gadewch i ni ddychmygu sefyllfa ddamcaniaethol. Rydych chi'n lansio'ch cais heb geisiadau, nid yw Kubernetes yn gwybod faint o'r hyn sydd gennych chi, pa nodau y gallwch chi ei wthio iddo. Wel, mae'n gwthio, yn gwthio, yn gwthio i'r nodau. Ar ryw adeg, byddwch yn dechrau cael traffig i'ch cais. Ac mae un o'r cymwysiadau yn sydyn yn dechrau defnyddio adnoddau hyd at y terfynau sydd ganddo yn ôl y terfynau. Mae'n ymddangos bod cais arall gerllaw ac mae angen adnoddau hefyd. Mae'r nod mewn gwirionedd yn dechrau rhedeg allan o adnoddau, er enghraifft, OP. Mae'r nod mewn gwirionedd yn dechrau rhedeg allan o adnoddau, er enghraifft, cof mynediad ar hap (RAM). Pan fydd nod yn rhedeg allan o bŵer, yn gyntaf oll bydd y docwr yn rhoi'r gorau i ymateb, yna'r cubelet, yna'r OS. Yn syml, byddant yn mynd yn anymwybodol a bydd POPETH yn bendant yn rhoi'r gorau i weithio i chi. Hynny yw, bydd hyn yn arwain at eich nod yn mynd yn sownd a bydd angen i chi ei ailgychwyn. Yn fyr, nid yw'r sefyllfa'n dda iawn.
A phan fydd gennych geisiadau, nid yw'r terfynau'n wahanol iawn, o leiaf ddim llawer mwy na'r terfynau neu'r ceisiadau, yna gallwch chi gael y fath lenwad mor normal, rhesymegol o geisiadau ar draws nodau clystyrau Kubernetes. Ar yr un pryd, mae Kubernetes yn gwybod yn fras faint o'r hyn y mae'n ei roi ble, faint o'r hyn a ddefnyddir, ble. Hynny yw, dim ond y fath foment yw hi. Mae'n bwysig ei ddeall. Ac mae'n bwysig rheoli bod hyn yn cael ei nodi.
Storio data
Mae ein pwynt nesaf yn ymwneud â storio data. Beth i'w wneud â nhw ac yn gyffredinol, beth i'w wneud â dyfalbarhad yn Kubernetes?
Rwy'n meddwl, unwaith eto, o fewn ein , roedd pwnc am y gronfa ddata yn Kubernetes. Ac mae'n ymddangos i mi fy mod hyd yn oed yn gwybod yn fras yr hyn a ddywedodd eich cydweithwyr wrthych pan ofynnwyd iddynt: “A yw'n bosibl rhedeg cronfa ddata yn Kubernetes?” Am ryw reswm, mae'n ymddangos i mi y dylai eich cydweithwyr fod wedi dweud wrthych, os ydych chi'n gofyn y cwestiwn a yw'n bosibl rhedeg cronfa ddata yn Kubernetes, yna mae'n amhosibl.
Mae'r rhesymeg yma yn syml. Rhag ofn, byddaf yn esbonio unwaith eto, os ydych chi'n ddyn cŵl iawn sy'n gallu adeiladu system eithaf goddefgar o storio rhwydwaith dosbarthedig, deall sut i ffitio cronfa ddata yn yr achos hwn, sut y dylai cwmwl brodorol mewn cynwysyddion weithio mewn cronfa ddata yn gyffredinol. Yn fwyaf tebygol, nid oes gennych unrhyw gwestiwn am sut i'w redeg. Os oes gennych gwestiwn o'r fath, a'ch bod am sicrhau bod y cyfan yn datblygu ac yn sefyll yn iawn i farwolaeth wrth gynhyrchu a byth yn disgyn, yna nid yw hyn yn digwydd. Rydych chi'n sicr o saethu'ch hun yn y droed gyda'r dull hwn. Felly mae'n well peidio.
Beth ddylem ni ei wneud gyda'r data yr hoffai ein cymhwysiad ei storio, rhai lluniau y mae defnyddwyr yn eu llwytho i fyny, rhai pethau y mae ein rhaglen yn eu cynhyrchu yn ystod ei weithrediad, wrth gychwyn, er enghraifft? Beth i'w wneud â nhw yn Kubernetes?
Yn gyffredinol, yn ddelfrydol, ie, wrth gwrs, mae Kubernetes wedi'i ddylunio'n dda iawn ac fe'i lluniwyd yn gyffredinol i ddechrau ar gyfer cymwysiadau di-wladwriaeth. Hynny yw, ar gyfer y cymwysiadau hynny nad ydynt yn storio gwybodaeth o gwbl. Mae hyn yn ddelfrydol.
Ond, wrth gwrs, nid yw'r opsiwn delfrydol bob amser yn bodoli. Felly beth? Y pwynt cyntaf a symlaf yw cymryd rhyw fath o S3, dim ond nid un cartref, sydd hefyd yn aneglur sut mae'n gweithio, ond gan ryw ddarparwr. Darparwr da, arferol - a dysgwch eich cais i ddefnyddio S3. Hynny yw, pan fydd eich defnyddiwr eisiau uwchlwytho ffeil, dywedwch “yma, os gwelwch yn dda, uwchlwythwch hi i S3.” Pan fydd am ei dderbyn, dywedwch: “Dyma ddolen i S3 yn ôl a chymerwch ef o fan hyn.” Mae hyn yn ddelfrydol.
Os yn sydyn am ryw reswm nad yw'r opsiwn delfrydol hwn yn addas, mae gennych chi gais na wnaethoch chi ei ysgrifennu, nid ydych chi'n ei ddatblygu, neu mae'n rhyw fath o etifeddiaeth ofnadwy, ni all ddefnyddio'r protocol S3, ond mae'n rhaid iddo weithio gyda chyfeiriaduron lleol yn ffolderi lleol . Cymerwch rywbeth mwy neu lai syml, defnyddiwch Kubernetes. Hynny yw, mae ffensio Ceph ar unwaith ar gyfer rhai tasgau lleiaf posibl, mae'n ymddangos i mi, yn syniad drwg. Oherwydd mae Ceph, wrth gwrs, yn dda ac yn ffasiynol. Ond os nad ydych chi wir yn deall beth rydych chi'n ei wneud, yna ar ôl i chi roi rhywbeth ar Ceph, gallwch chi'n hawdd iawn ac yn syml byth ei gael allan o'r fan honno eto. Oherwydd, fel y gwyddoch, mae Ceph yn storio data yn ei glwstwr ar ffurf ddeuaidd, ac nid ar ffurf ffeiliau syml. Felly, os bydd clwstwr Ceph yn torri i lawr yn sydyn, yna mae tebygolrwydd llwyr ac uchel na fyddwch byth yn cael eich data oddi yno eto.
Bydd gennym gwrs ar Ceph, gallwch chi .
Felly, mae'n well gwneud rhywbeth syml fel gweinydd NFS. Gall Kubernetes weithio gyda nhw, gallwch chi osod cyfeiriadur o dan weinydd NFS - mae eich cais yn union fel cyfeiriadur lleol. Ar yr un pryd, yn naturiol, mae angen i chi ddeall, unwaith eto, bod angen i chi wneud rhywbeth gyda'ch NFS, mae angen i chi ddeall y gallai weithiau ddod yn anhygyrch ac ystyried y cwestiwn o beth fyddwch chi'n ei wneud yn yr achos hwn. Efallai y dylid ei wneud wrth gefn yn rhywle ar beiriant ar wahân.
Y pwynt nesaf y siaradais amdano yw beth i'w wneud os yw'ch cais yn cynhyrchu rhai ffeiliau yn ystod y llawdriniaeth. Er enghraifft, pan fydd yn cychwyn, mae'n cynhyrchu rhywfaint o ffeil statig, sy'n seiliedig ar rywfaint o wybodaeth y mae'r cais yn ei chael ar adeg ei lansio yn unig. Am eiliad. Os nad oes llawer o ddata o'r fath, yna nid oes rhaid i chi drafferthu o gwbl, gosodwch y cymhwysiad hwn i chi'ch hun a gweithio. Yr unig gwestiwn yma yw beth, edrychwch. Yn aml iawn, mae pob math o systemau etifeddiaeth, fel WordPress ac yn y blaen, yn enwedig gyda rhyw fath o ategion clyfar wedi'u haddasu, datblygwyr PHP clyfar, yn aml yn gwybod sut i'w wneud fel eu bod yn cynhyrchu rhyw fath o ffeil drostynt eu hunain. Yn unol â hynny, mae un yn cynhyrchu un ffeil, mae'r ail yn cynhyrchu ail ffeil. Maent yn wahanol. Mae cydbwyso'n digwydd yng nghlwstwr Kubernetes y cleientiaid ar hap. Yn unol â hynny, mae'n troi allan nad ydyn nhw'n gwybod sut i gydweithio er enghraifft. Mae un yn rhoi gwybodaeth i un, mae'r llall yn rhoi gwybodaeth arall i'r defnyddiwr. Mae hyn yn rhywbeth y dylech ei osgoi. Hynny yw, yn Kubernetes, mae popeth rydych chi'n ei lansio yn sicr o allu gweithio mewn sawl achos. Achos mae Kubernetes yn beth teimladwy. Yn unol â hynny, gall symud unrhyw beth, pryd bynnag y bydd yn dymuno, heb ofyn i neb o gwbl. Felly, mae angen ichi ddibynnu ar hyn. Bydd popeth a lansiwyd mewn un achos yn methu yn hwyr neu'n hwyrach. Po fwyaf o amheuon sydd gennych, gorau oll. Ond eto, rwy'n dweud, os oes gennych ychydig o ffeiliau o'r fath, yna gallwch chi eu cywiro o dan chi, maen nhw'n pwyso ychydig bach. Os oes ychydig mwy ohonynt, mae'n debyg na ddylech eu gwthio y tu mewn i'r cynhwysydd.
Byddwn yn cynghori bod yna beth mor wych yn Kubernetes, gallwch chi ddefnyddio cyfaint. Yn benodol, mae cyfaint o dir gwag math. Hynny yw, dim ond y bydd Kubernetes yn creu cyfeiriadur yn awtomatig yn ei gyfeirlyfrau gwasanaeth ar y gweinydd lle gwnaethoch chi ddechrau. Ac efe a'i rhoddes i ti fel y galloch ei ddefnyddio. Dim ond un pwynt pwysig sydd. Hynny yw, ni fydd eich data yn cael ei storio y tu mewn i'r cynhwysydd, ond yn hytrach ar y gwesteiwr rydych chi'n rhedeg arno. Ar ben hynny, gall Kubernetes reoli tirs gwag o'r fath o dan gyfluniad arferol ac mae'n gallu rheoli eu maint mwyaf a pheidio â chaniatáu iddo fynd y tu hwnt iddo. Yr unig bwynt yw nad yw'r hyn rydych chi wedi'i ysgrifennu mewn dir gwag yn cael ei golli wrth ailgychwyn codennau. Hynny yw, os bydd eich pod yn cwympo trwy gamgymeriad ac yn codi eto, ni fydd y wybodaeth yn y cyfeiriad gwag yn mynd i unrhyw le. Gall ei ddefnyddio eto ar ddechrau newydd - ac mae hynny'n dda. Os bydd eich pod yn gadael rhywle, yna yn naturiol bydd yn gadael heb ddata. Hynny yw, cyn gynted ag y bydd y pod o'r nod lle cafodd ei lansio gyda dir gwag yn diflannu, caiff cyfeiriad gwag ei ddileu.
Beth arall sy'n dda am dir gwag? Er enghraifft, gellir ei ddefnyddio fel storfa. Gadewch i ni ddychmygu bod ein cymhwysiad yn cynhyrchu rhywbeth ar y hedfan, yn ei roi i ddefnyddwyr, ac yn ei wneud am amser hir. Felly, mae'r cais, er enghraifft, yn ei gynhyrchu a'i roi i ddefnyddwyr, ac ar yr un pryd yn ei storio yn rhywle, fel y tro nesaf y daw'r defnyddiwr am yr un peth, bydd yn gyflymach i'w roi ar unwaith. Gellir gofyn am dir gwag i Kubernetes ei greu er cof. Ac felly, yn gyffredinol gall eich caches weithio ar gyflymder mellt - o ran cyflymder mynediad disg. Hynny yw, mae gennych dir gwag yn y cof, yn yr OS mae'n cael ei storio yn y cof, ond i chi, i'r defnyddiwr y tu mewn i'r pod, mae'n edrych fel cyfeiriadur lleol yn unig. Nid oes angen yr app arnoch i ddysgu unrhyw hud yn benodol. Rydych chi'n cymryd a rhoi eich ffeil yn uniongyrchol mewn cyfeiriadur, ond, mewn gwirionedd, er cof ar yr OS. Mae hon hefyd yn nodwedd gyfleus iawn o ran Kubernetes.
Pa broblemau sydd gan Minio? Y brif broblem gyda Minio yw, er mwyn i'r peth hwn weithio, mae angen iddo fod yn rhedeg yn rhywle, a rhaid bod rhyw fath o system ffeiliau, hynny yw, storio. A dyma ni'n dod ar draws yr un problemau ag sydd gan Ceph. Hynny yw, mae'n rhaid i Minio storio ei ffeiliau yn rhywle. Yn syml, rhyngwyneb HTTP i'ch ffeiliau ydyw. Ar ben hynny, mae'r ymarferoldeb yn amlwg yn dlotach nag un Amazon's S3. Yn flaenorol, nid oedd yn gallu awdurdodi'r defnyddiwr yn iawn. Nawr, cyn belled ag y gwn, gall eisoes greu bwcedi gyda gwahanol awdurdodiadau, ond eto, mae'n ymddangos i mi mai'r brif broblem, fel petai, yw'r system storio sylfaenol o leiaf.
Sut mae baw gwag yn y cof yn effeithio ar y terfynau? Nid yw'n effeithio ar derfynau mewn unrhyw ffordd. Mae'n gorwedd yng nghof y gwesteiwr, ac nid yng nghof eich cynhwysydd. Hynny yw, nid yw eich cynhwysydd yn gweld y dir gwag yn y cof fel rhan o'i gof meddiannu. Mae'r gwesteiwr yn gweld hyn. Yn unol â hynny, ie, o safbwynt kubernetes, pan fyddwch chi'n dechrau defnyddio hyn, byddai'n dda deall eich bod yn neilltuo rhan o'ch cof i dir gwag. Ac yn unol â hynny, deallwch y gall cof redeg allan nid yn unig oherwydd cymwysiadau, ond hefyd oherwydd bod rhywun yn ysgrifennu at y cyfarwyddiadau gwag hyn.
Cymylogrwydd
A'r subtopic olaf yw beth yw Cloudnative. Pam fod ei angen? Cymylogrwydd ac ati.
Hynny yw, y cymwysiadau hynny sy'n alluog ac wedi'u hysgrifennu er mwyn gweithio mewn seilwaith cwmwl modern. Ond, mewn gwirionedd, mae gan Cloudnative agwedd arall o'r fath. Bod hwn nid yn unig yn gymhwysiad sy'n ystyried holl ofynion seilwaith cwmwl modern, ond hefyd yn gwybod sut i weithio gyda'r seilwaith cwmwl modern hwn, manteisio ar fanteision ac anfanteision y ffaith ei fod yn gweithio yn y cymylau hyn. Peidiwch â mynd dros ben llestri a gweithio yn y cymylau yn unig, ond manteisiwch ar fuddion gweithio yn y cwmwl.
Gadewch i ni gymryd Kubernetes fel enghraifft. Mae eich cais yn rhedeg yn Kubernetes. Gall eich cais bob amser, neu yn hytrach gall y gweinyddwyr ar gyfer eich cais, bob amser greu cyfrif gwasanaeth. Hynny yw, cyfrif am awdurdodiad yn Kubernetes ei hun yn ei weinydd. Ychwanegwch rai hawliau sydd eu hangen arnom yno. A gallwch gael mynediad at Kubernetes o'ch cais. Beth allwch chi ei wneud fel hyn? Er enghraifft, o'r cais, derbyniwch ddata am ble mae'ch cymwysiadau eraill, achosion tebyg eraill wedi'u lleoli, a gyda'i gilydd rywsut clystyru ar ben Kubernetes, os oes angen o'r fath.
Eto, yn llythrennol cawsom achos yn ddiweddar. Mae gennym un rheolydd sy'n monitro'r ciw. A phan fydd rhai tasgau newydd yn ymddangos yn y ciw hwn, mae'n mynd i Kubernetes - a thu mewn i Kubernetes mae'n creu pod newydd. Yn rhoi rhywfaint o dasg newydd i'r pod hwn ac o fewn fframwaith y pod hwn, mae'r pod yn cyflawni'r dasg, yn anfon ymateb at y rheolydd ei hun, ac yna mae'r rheolydd yn gwneud rhywbeth gyda'r wybodaeth hon. Er enghraifft, mae'n ychwanegu cronfa ddata. Hynny yw, unwaith eto, mae hyn yn fantais o'r ffaith bod ein cais yn rhedeg yn Kubernetes. Gallwn ddefnyddio'r swyddogaeth Kubernetes adeiledig ei hun er mwyn ehangu rhywsut a gwneud ymarferoldeb ein cymhwysiad yn fwy cyfleus. Hynny yw, peidiwch â chuddio rhyw fath o hud ynghylch sut i lansio cais, sut i lansio gweithiwr. Yn Kubernetes, rydych chi'n anfon cais yn yr app os yw'r cais wedi'i ysgrifennu yn Python.
Mae'r un peth yn wir os awn y tu hwnt i Kubernetes. Mae gennym ein Kubernetes yn rhedeg yn rhywle - mae'n dda os yw mewn rhyw fath o gwmwl. Unwaith eto, gallwn ddefnyddio, a dylem hyd yn oed, rwy'n credu, ddefnyddio galluoedd y cwmwl ei hun lle rydym yn rhedeg. O'r pethau elfennol y mae'r cwmwl yn eu darparu i ni. Wrth gydbwyso, hynny yw, gallwn greu balanswyr cwmwl a'u defnyddio. Mae hyn yn fantais uniongyrchol o'r hyn y gallwn ei ddefnyddio. Oherwydd bod cydbwyso cwmwl, yn gyntaf, yn dwp yn syml yn tynnu cyfrifoldeb oddi wrthym ni am sut mae'n gweithio, sut mae wedi'i ffurfweddu. Hefyd mae'n gyfleus iawn, oherwydd gall Kubernetes rheolaidd integreiddio â chymylau.
Mae'r un peth yn wir am raddio. Gall Kubernetes rheolaidd integreiddio â darparwyr cwmwl. Yn gwybod sut i ddeall, os yw'r clwstwr yn rhedeg allan o nodau, hynny yw, bod y gofod nod wedi dod i ben, yna mae angen ichi ychwanegu - bydd Kubernetes ei hun yn ychwanegu nodau newydd i'ch clwstwr ac yn dechrau lansio codennau arnynt. Hynny yw, pan ddaw eich llwyth, mae nifer yr aelwydydd yn dechrau cynyddu. Pan fydd y nodau yn y clwstwr yn rhedeg allan ar gyfer y codennau hyn, mae Kubernetes yn lansio nodau newydd ac, yn unol â hynny, gall nifer y codennau gynyddu o hyd. Ac mae'n gyfleus iawn. Mae hwn yn gyfle uniongyrchol i raddio'r clwstwr ar y hedfan. Ddim yn gyflym iawn, yn yr ystyr nad yw'n eiliad, mae'n debycach i funud er mwyn ychwanegu nodau newydd.
Ond o fy mhrofiad i, unwaith eto, dyma'r peth cŵl a welais erioed. Pan raddiodd y clwstwr Cloudnative yn seiliedig ar amser o'r dydd. Roedd yn wasanaeth backend a oedd yn cael ei ddefnyddio gan bobl yn y swyddfa gefn. Hynny yw, maen nhw'n dod i weithio am 9 am, yn dechrau mewngofnodi i'r system, ac yn unol â hynny, mae clwstwr Cloudnative, lle mae'r cyfan yn rhedeg, yn dechrau chwyddo, gan lansio codennau newydd fel y gall pawb sy'n dod i'r gwaith weithio gyda'r cais. Pan fyddant yn gadael y gwaith am 8 pm neu 6 pm, mae clystyrau Kubernetes yn sylwi nad oes unrhyw un yn defnyddio'r cymhwysiad mwyach ac yn dechrau crebachu. Gwarantir arbedion o hyd at 30 y cant. Roedd yn gweithio yn Amazon bryd hynny; bryd hynny nid oedd unrhyw un yn Rwsia a allai ei wneud mor dda.
Fe ddywedaf wrthych yn syth, mae'r arbedion yn 30 y cant yn syml oherwydd ein bod yn defnyddio Kubernetes ac yn manteisio ar alluoedd y cwmwl. Nawr gellir gwneud hyn yn Rwsia. Ni fyddaf yn hysbysebu i unrhyw un, wrth gwrs, ond gadewch i ni ddweud bod yna ddarparwyr a all wneud hyn, rhowch fotwm iddo allan o'r bocs.
Mae un pwynt olaf yr hoffwn innau dynnu eich sylw ato hefyd. Er mwyn i'ch cais, eich seilwaith fod yn Gymylol, mae'n gwneud synnwyr o'r diwedd i ddechrau addasu'r dull a elwir yn Isadeiledd fel Cod, Hynny yw, mae hyn yn golygu bod angen eich cais, neu yn hytrach eich seilwaith, yn union yr un ffordd â'r cod Disgrifiwch eich cais, eich rhesymeg busnes ar ffurf cod. A gweithio gydag ef fel cod, hynny yw, ei brofi, ei gyflwyno, ei storio mewn git, cymhwyso CICD iddo.
A dyma'n union beth sy'n eich galluogi chi, yn gyntaf, i gael rheolaeth dros eich seilwaith bob amser, i ddeall bob amser ym mha gyflwr y mae. Yn ail, osgoi gweithrediadau llaw sy'n achosi gwallau. Yn drydydd, ceisiwch osgoi'r hyn a elwir yn drosiant yn syml, pan fydd angen i chi gyflawni'r un tasgau llaw yn gyson. Yn bedwerydd, mae'n caniatáu ichi adfer yn gynt o lawer os bydd methiant. Yn Rwsia, bob tro rwy'n siarad am hyn, mae yna bob amser nifer enfawr o bobl sy'n dweud: “Ie, mae'n amlwg, ond mae gennych chi ddulliau, yn fyr, nid oes angen trwsio unrhyw beth.” Ond mae'n wir. Os oes rhywbeth wedi torri yn eich seilwaith, yna o safbwynt y dull Cloudnative ac o safbwynt Isadeiledd fel Cod, yn hytrach na'i drwsio, mynd at y gweinydd, darganfod beth sydd wedi torri a'i drwsio, mae'n haws i ddileu'r gweinydd a'i greu eto. Ac mi a adferaf hyn oll.
Trafodir yr holl faterion hyn yn fanylach yn . Trwy ddilyn y ddolen gallwch ymgyfarwyddo â'r rhaglen a'r amodau. Y peth cyfleus yw y gallwch chi feistroli Kubernetes trwy astudio gartref neu weithio am 1-2 awr y dydd.
Ffynhonnell: hab.com