Mae Kubernetes yn offeryn gwych ar gyfer rhedeg cynwysyddion Docker mewn amgylchedd cynhyrchu clystyrog. Fodd bynnag, mae yna broblemau na all Kubernetes eu datrys. Ar gyfer defnydd cynhyrchu aml, mae angen gosodiad Glas/Gwyrdd cwbl awtomataidd arnom i osgoi amser segur yn y broses, sydd hefyd angen delio â cheisiadau HTTP allanol a chyflawni dadlwythiadau SSL. Mae hyn yn gofyn am integreiddio â chydbwysedd llwyth fel ha-procsi. Her arall yw graddio clwstwr Kubernetes ei hun yn lled-awtomatig wrth redeg mewn amgylchedd cwmwl, er enghraifft lleihau'r clwstwr yn rhannol yn y nos.
Er nad oes gan Kubernetes y nodweddion hyn allan o'r bocs, mae'n darparu API y gallwch ei ddefnyddio i ddatrys problemau tebyg. Datblygwyd offer ar gyfer defnyddio Glas/Gwyrdd awtomataidd a graddio clwstwr Kubernetes fel rhan o brosiect Cloud RTI, a grëwyd yn seiliedig ar ffynhonnell agored.
Mae'r erthygl hon, trawsgrifiad fideo, yn dangos i chi sut i sefydlu Kubernetes ynghyd â chydrannau ffynhonnell agored eraill i greu amgylchedd sy'n barod ar gyfer cynhyrchu sy'n derbyn cod gan ymrwymiad git heb amser segur wrth gynhyrchu.
Felly, unwaith y bydd gennych fynediad i'ch cymwysiadau o'r byd y tu allan, gallwch ddechrau sefydlu awtomeiddio'n llawn, hynny yw, dod ag ef i'r llwyfan lle gallwch chi berfformio ymrwymiad git a sicrhau bod yr ymrwymiad git hwn yn dod i ben yn y cynhyrchiad. Yn naturiol, wrth weithredu'r camau hyn, wrth roi defnydd ar waith, nid ydym am ddod ar draws amser segur. Felly, mae unrhyw awtomeiddio yn Kubernetes yn dechrau gyda'r API.
Nid yw Kubernetes yn offeryn y gellir ei ddefnyddio'n gynhyrchiol allan o'r bocs. Wrth gwrs, gallwch chi wneud hynny, defnyddio kubectl ac yn y blaen, ond yr API o hyd yw'r peth mwyaf diddorol a defnyddiol am y platfform hwn. Trwy ddefnyddio'r API fel set o swyddogaethau, gallwch gyrchu bron unrhyw beth rydych chi am ei wneud yn Kubernetes. Mae kubectl ei hun hefyd yn defnyddio'r API REST.
Dyma REST, felly gallwch chi ddefnyddio unrhyw iaith neu offeryn i weithio gyda'r API hwn, ond bydd eich bywyd yn cael ei wneud yn llawer haws gan lyfrgelloedd personol. Ysgrifennodd fy nhîm 2 lyfrgell o'r fath: un ar gyfer Java/OSGi ac un ar gyfer Go. Ni ddefnyddir yr ail un yn aml, ond beth bynnag mae gennych y pethau defnyddiol hyn ar gael ichi. Maent yn brosiect ffynhonnell agored wedi'i drwyddedu'n rhannol. Mae yna lawer o lyfrgelloedd o'r fath ar gyfer gwahanol ieithoedd, felly gallwch chi ddewis y rhai sydd fwyaf addas i chi.
Felly, cyn i chi ddechrau awtomeiddio eich defnydd, mae angen i chi sicrhau na fydd y broses yn destun unrhyw amser segur. Er enghraifft, mae ein tîm yn cynnal gosodiadau cynhyrchu yn ystod canol y dydd pan fydd pobl yn defnyddio'r cymwysiadau fwyaf, felly mae'n bwysig osgoi oedi yn y broses. Er mwyn osgoi amser segur, defnyddir 2 ddull: defnydd glas/gwyrdd neu ddiweddariad treigl. Yn yr achos olaf, os oes gennych 5 copi o'r rhaglen yn rhedeg, cânt eu diweddaru'n olynol un ar ôl y llall. Mae'r dull hwn yn gweithio'n wych, ond nid yw'n addas os oes gennych chi fersiynau gwahanol o'r cais yn rhedeg ar yr un pryd yn ystod y broses leoli. Yn yr achos hwn, gallwch chi ddiweddaru'r rhyngwyneb defnyddiwr tra bod y backend yn rhedeg yr hen fersiwn, a bydd y rhaglen yn rhoi'r gorau i weithio. Felly, o safbwynt rhaglennu, mae gweithio mewn amodau o'r fath yn eithaf anodd.
Dyma un o'r rhesymau pam mae'n well gennym ddefnyddio defnydd glas/gwyrdd i awtomeiddio'r broses o leoli ein ceisiadau. Gyda'r dull hwn, rhaid i chi sicrhau mai dim ond un fersiwn o'r cais sy'n weithredol ar y tro.
Mae'r mecanwaith lleoli glas/gwyrdd yn edrych fel hyn. Rydym yn derbyn traffig ar gyfer ein ceisiadau trwy ha-proxy, sy'n ei anfon ymlaen at replicas rhedeg o gymhwysiad yr un fersiwn.
Pan wneir defnydd newydd, rydym yn defnyddio Deployer, sy'n cael y cydrannau newydd ac yn defnyddio'r fersiwn newydd. Mae defnyddio fersiwn newydd o raglen yn golygu bod set newydd o atgynyrchiadau yn cael eu “codi”, ac ar ôl hynny mae'r copïau hyn o'r fersiwn newydd yn cael eu lansio mewn pod newydd ar wahân. Fodd bynnag, nid yw ha-procsi yn gwybod dim amdanynt ac nid yw'n cyfeirio unrhyw lwyth gwaith atynt eto.
Felly, yn gyntaf oll, mae angen cynnal gwiriad perfformiad o fersiynau newydd o wirio iechyd i sicrhau bod y copïau yn barod i wasanaethu'r llwyth.
Rhaid i'r holl gydrannau lleoli gefnogi rhyw fath o wiriad iechyd. Gall hyn fod yn wiriad galwad HTTP syml iawn, pan fyddwch chi'n derbyn cod gyda statws 200, neu wiriad manylach, lle rydych chi'n gwirio cysylltiad y copïau â'r gronfa ddata a gwasanaethau eraill, sefydlogrwydd y cysylltiadau amgylchedd deinamig , ac a yw popeth yn dechrau ac yn gweithio'n gywir. Gall y broses hon fod yn eithaf cymhleth.
Ar ôl i'r system wirio bod yr holl atgynyrchiadau wedi'u diweddaru yn gweithio, bydd Deployer yn diweddaru'r ffurfweddiad ac yn pasio'r confd cywir, a fydd yn ad-drefnu ha-proxy.
Dim ond ar ôl hyn y bydd traffig yn cael ei gyfeirio at y pod gyda chopïau o'r fersiwn newydd, a bydd yr hen god yn diflannu.
Nid yw'r mecanwaith hwn yn nodwedd o Kubernetes. Mae'r cysyniad o leoli Glas/gwyrdd wedi bodoli ers cryn amser ac mae bob amser wedi defnyddio cydbwysydd llwyth. Yn gyntaf, rydych chi'n cyfeirio'r holl draffig i hen fersiwn y cais, ac ar ôl y diweddariad, rydych chi'n ei drosglwyddo'n llwyr i'r fersiwn newydd. Defnyddir yr egwyddor hon nid yn unig yn Kubernetes.
Nawr byddaf yn eich cyflwyno i gydran defnyddio newydd - Deployer, sy'n cynnal gwiriadau iechyd, yn ail-gyflunio dirprwyon, ac yn y blaen. Mae hwn yn gysyniad nad yw'n berthnasol i'r byd y tu allan ac sy'n bodoli y tu mewn i Kubernetes. Byddaf yn dangos i chi sut y gallwch greu eich cysyniad Deployer eich hun gan ddefnyddio offer ffynhonnell agored.
Felly, y peth cyntaf y mae Deployer yn ei wneud yw creu rheolydd atgynhyrchu RC gan ddefnyddio'r Kubernetes API. Mae'r API hwn yn creu codennau a gwasanaethau i'w defnyddio ymhellach, hynny yw, mae'n creu clwstwr cwbl newydd ar gyfer ein cymwysiadau. Cyn gynted ag y bydd RC yn argyhoeddedig bod y copïau wedi dechrau, bydd yn cynnal gwiriad Iechyd ar eu swyddogaeth. I wneud hyn, mae Deployer yn defnyddio'r gorchymyn GET /iechyd. Mae'n rhedeg y cydrannau sgan priodol ac yn gwirio'r holl elfennau sy'n cefnogi gweithrediad y clwstwr.
Ar ôl i bob codennau adrodd am eu hiechyd, mae Deployer yn creu elfen ffurfweddu newydd - storfa ddosbarthedig ac ati, a ddefnyddir yn fewnol gan Kubernetes, gan gynnwys storio'r cyfluniad balancer llwyth. Rydym yn ysgrifennu data i etcd, ac offeryn bach o'r enw monitorau confd ac ati ar gyfer data newydd.
Os yw'n canfod unrhyw newidiadau i'r ffurfweddiad cychwynnol, mae'n cynhyrchu ffeil gosodiadau newydd ac yn ei throsglwyddo i ha-proxy. Yn yr achos hwn, mae ha-proxy yn ailgychwyn heb golli unrhyw gysylltiadau ac yn mynd i'r afael â'r llwyth i wasanaethau newydd sy'n galluogi'r fersiwn newydd o'n cymwysiadau i weithio.
Fel y gwelwch, er gwaethaf y doreth o gydrannau, nid oes dim byd cymhleth yma. Mae angen i chi dalu mwy o sylw i'r API ac ati. Rwyf am ddweud wrthych am y trefnydd ffynhonnell agored yr ydym ni ein hunain yn ei ddefnyddio - Amdatu Kubernetes Deployer.
Mae'n offeryn ar gyfer trefnu gosodiadau Kubernetes ac mae ganddo'r nodweddion canlynol:
- Defnydd Glas/Gwyrdd;
- sefydlu cydbwysedd llwyth allanol;
- rheoli disgrifydd lleoli;
- rheoli'r defnydd gwirioneddol;
- gwirio ymarferoldeb gwiriadau Iechyd yn ystod y defnydd;
- rhoi newidynnau amgylcheddol ar waith mewn codennau.
Mae'r Defnyddiwr hwn wedi'i adeiladu ar ben API Kubernetes ac mae'n darparu API REST ar gyfer rheoli dolenni a gosodiadau, yn ogystal ag API Websocket ar gyfer ffrydio logiau yn ystod y broses leoli.
Mae'n rhoi'r data cyfluniad cydbwysedd llwyth i mewn ac ati, felly does dim rhaid i chi ddefnyddio ha-proxy gyda chefnogaeth y tu allan i'r bocs, ond yn hawdd defnyddiwch eich ffeil ffurfweddu cydbwysedd llwyth eich hun. Mae Amdatu Deployer wedi'i ysgrifennu yn Go, fel Kubernetes ei hun, ac mae wedi'i drwyddedu gan Apache.
Cyn i mi ddechrau defnyddio'r fersiwn hon o'r gosodwr, defnyddiais y disgrifydd defnydd canlynol, sy'n nodi'r paramedrau sydd eu hangen arnaf.
Un o baramedrau pwysig y cod hwn yw galluogi'r faner “useHealthCheck”. Mae angen i ni nodi bod yn rhaid cynnal gwiriad glanweithdra yn ystod y broses leoli. Gellir analluogi'r gosodiad hwn pan fydd y gosodiad yn defnyddio cynwysyddion trydydd parti nad oes angen eu gwirio. Mae'r disgrifydd hwn hefyd yn nodi nifer y copïau a'r URL blaen sydd eu hangen ar ha-procsi. Ar y diwedd mae baner manyleb y pod "podspec", sy'n galw Kubernetes am wybodaeth am gyfluniad porthladd, delwedd, ac ati. Mae hwn yn ddisgrifydd JSON eithaf syml.
Offeryn arall sy'n rhan o brosiect ffynhonnell agored Amdatu yw Deploymentctl. Mae ganddo UI ar gyfer ffurfweddu gosodiadau, storio hanes defnyddio, ac mae'n cynnwys bachau gwe ar gyfer galwadau yn ôl gan ddefnyddwyr trydydd parti a datblygwyr. Ni chewch ddefnyddio'r UI gan fod Amdatu Deployer ei hun yn API REST, ond gall y rhyngwyneb hwn wneud defnydd yn llawer haws i chi heb gynnwys unrhyw API. Mae Deploymentctl wedi'i ysgrifennu yn OSGi/Vertx gan ddefnyddio Angular 2.
Byddaf nawr yn dangos yr uchod ar y sgrin gan ddefnyddio recordiad wedi'i recordio ymlaen llaw fel nad oes rhaid i chi aros. Byddwn yn defnyddio rhaglen Go syml. Peidiwch â phoeni os nad ydych wedi rhoi cynnig ar Go o'r blaen, mae'n gais syml iawn felly dylech allu ei ddarganfod.
Yma rydym yn creu gweinydd HTTP sydd ond yn ymateb i / iechyd, felly dim ond y gwiriad iechyd y mae'r cymhwysiad hwn yn ei brofi a dim byd arall. Os bydd y siec yn pasio, defnyddir y strwythur JSON a ddangosir isod. Mae'n cynnwys y fersiwn o'r rhaglen a fydd yn cael ei defnyddio gan y trefnydd, y neges a welwch ar frig y ffeil, a'r math data boolean - p'un a yw ein rhaglen yn gweithio ai peidio.
Fe wnes i dwyllo ychydig gyda'r llinell olaf, oherwydd gosodais werth boolean sefydlog ar frig y ffeil, a fydd yn y dyfodol yn fy helpu i ddefnyddio cymhwysiad "afiach" hyd yn oed. Byddwn yn ymdrin â hyn yn ddiweddarach.
Felly gadewch i ni ddechrau. Yn gyntaf, rydym yn gwirio am bresenoldeb unrhyw godennau rhedeg gan ddefnyddio'r gorchymyn ~ codennau cael kubectl ac, yn seiliedig ar absenoldeb ymateb o'r URL blaen, rydym yn sicrhau nad oes unrhyw ddefnyddiau'n cael eu gwneud ar hyn o bryd.
Nesaf ar y sgrin fe welwch y rhyngwyneb Deploymentctl y soniais amdano, lle mae paramedrau defnyddio wedi'u gosod: gofod enw, enw cymhwysiad, fersiwn defnyddio, nifer y copïau, URL pen blaen, enw cynhwysydd, delwedd, terfynau adnoddau, rhif porthladd ar gyfer gwiriad iechyd, etc. Mae terfynau adnoddau yn bwysig iawn, gan eu bod yn caniatáu ichi ddefnyddio'r caledwedd mwyaf posibl. Yma gallwch hefyd weld y log Defnyddio.
Os ydych chi nawr yn ailadrodd y gorchymyn ~ kubectl get codennau, gallwch weld bod y system yn “rhewi” am 20 eiliad, pan fydd ha-proxy yn cael ei ail-gyflunio. Ar ôl hyn, mae'r pod yn cychwyn, a gellir gweld ein replica yn y log lleoli.
Fe wnes i dorri allan yr aros 20 eiliad o'r fideo, a nawr gallwch chi weld ar y sgrin bod fersiwn gyntaf y cais wedi'i ddefnyddio. Gwnaed hyn i gyd gan ddefnyddio'r UI yn unig.
Nawr gadewch i ni roi cynnig ar yr ail fersiwn. I wneud hyn, rwy'n newid neges y cais o "Helo, Kubernetes!" ar “Helo, Deployer!”, Mae'r system yn creu'r ddelwedd hon ac yn ei gosod yn y gofrestrfa Docker, ac ar ôl hynny rydym yn syml yn clicio ar y botwm “Deploy” eto yn y ffenestr Deploymentctl. Yn yr achos hwn, mae'r log lleoli yn cael ei lansio'n awtomatig yn yr un modd ag y digwyddodd wrth ddefnyddio fersiwn gyntaf y rhaglen.
Mae'r gorchymyn ~ kubectl get pods yn dangos bod 2 fersiwn o'r cymhwysiad yn rhedeg ar hyn o bryd, ond mae'r frontend yn dangos ein bod ni'n dal i redeg fersiwn 1.
Mae'r cydbwysedd llwyth yn aros i'r gwiriad iechyd gael ei gwblhau cyn ailgyfeirio traffig i'r fersiwn newydd. Ar ôl 20 eiliad, rydyn ni'n newid i Curl ac yn gweld bod gennym ni fersiwn 2 o'r cais bellach, a bod yr un cyntaf wedi'i ddileu.
Roedd hwn yn ddefnydd o gais “iach”. Gadewch i ni weld beth sy'n digwydd os byddaf yn newid y paramedr Iach o wir i ffug ar gyfer fersiwn newydd o'r cais, hynny yw, rwy'n ceisio defnyddio cymhwysiad afiach sydd wedi methu'r gwiriad iechyd. Gall hyn ddigwydd os gwnaed rhai gwallau cyfluniad yn y cais yn ystod y cam datblygu, a'i fod yn cael ei anfon i gynhyrchu yn y ffurflen hon.
Fel y gallwch weld, mae'r defnydd yn mynd trwy'r holl gamau uchod ac mae ~ kubectl get pods yn dangos bod y ddau god yn rhedeg. Ond yn wahanol i'r defnydd blaenorol, mae'r log yn dangos y statws terfyn amser. Hynny yw, oherwydd bod y gwiriad iechyd wedi methu, ni ellir defnyddio'r fersiwn newydd o'r cais. O ganlyniad, fe welwch fod y system wedi dychwelyd i ddefnyddio'r hen fersiwn o'r rhaglen, ac mae'r fersiwn newydd wedi'i dadosod yn syml.
Y peth da am hyn yw, hyd yn oed os oes gennych nifer fawr o geisiadau cydamserol yn dod i mewn i'r cais, ni fyddant hyd yn oed yn sylwi ar yr amser segur wrth weithredu'r weithdrefn leoli. Os byddwch chi'n profi'r cais hwn gan ddefnyddio fframwaith Gatling, sy'n anfon cymaint o geisiadau ag sy'n bosibl ato, yna ni fydd unrhyw un o'r ceisiadau hyn yn cael eu gollwng. Mae hyn yn golygu na fydd ein defnyddwyr hyd yn oed yn sylwi ar ddiweddariadau fersiwn mewn amser real. Os bydd yn methu, bydd gwaith yn parhau ar yr hen fersiwn; os yw'n llwyddiannus, bydd defnyddwyr yn newid i'r fersiwn newydd.
Dim ond un peth a all fethu - os bydd y gwiriad iechyd yn llwyddo, ond bod y cais yn methu cyn gynted ag y bydd y llwyth gwaith yn cael ei gymhwyso iddo, hynny yw, dim ond ar ôl cwblhau'r defnydd y bydd y cwymp yn digwydd. Yn yr achos hwn, bydd yn rhaid i chi rolio'n ôl i'r hen fersiwn â llaw. Felly, fe wnaethom edrych ar sut i ddefnyddio Kubernetes gyda'r offer ffynhonnell agored a ddyluniwyd ar ei gyfer. Bydd y broses leoli yn llawer haws os byddwch yn cynnwys yr offer hyn yn eich piblinellau Adeiladu/Defnyddio. Ar yr un pryd, i ddechrau defnyddio, gallwch ddefnyddio naill ai'r rhyngwyneb defnyddiwr neu awtomeiddio'r broses hon yn llawn trwy ddefnyddio, er enghraifft, ymrwymo i feistroli.
Bydd ein Gweinyddwr Adeiladu yn creu delwedd Docker, yn ei gwthio i mewn i Docker Hub neu ba bynnag gofrestrfa rydych chi'n ei defnyddio. Mae Docker Hub yn cefnogi webhook, felly gallwn sbarduno defnydd o bell trwy Deployer yn y ffordd a ddangosir uchod. Fel hyn gallwch chi awtomeiddio'n llawn y defnydd o'ch cais i gynhyrchu posibl.
Gadewch i ni symud ymlaen i'r pwnc nesaf - graddio clwstwr Kubernetes. Sylwch fod y gorchymyn kubectl yn orchymyn graddio. Gyda mwy o help, gallwn yn hawdd gynyddu nifer y copïau sydd yn ein clwstwr presennol. Fodd bynnag, yn ymarferol, rydym fel arfer am gynyddu nifer y nodau yn hytrach na'r codennau.
Ar yr un pryd, yn ystod oriau gwaith efallai y bydd angen i chi gynyddu, ac yn y nos, i leihau cost gwasanaethau Amazon, efallai y bydd angen i chi leihau nifer yr achosion cais rhedeg. Nid yw hyn yn golygu y bydd graddio dim ond nifer y codennau yn ddigon, oherwydd hyd yn oed os yw un o'r nodau'n segur, bydd yn rhaid i chi dalu Amazon amdano o hyd. Hynny yw, ynghyd â graddio'r codennau, bydd angen i chi raddio nifer y peiriannau a ddefnyddir.
Gall hyn fod yn heriol oherwydd p'un a ydym yn defnyddio Amazon neu wasanaeth cwmwl arall, nid yw Kubernetes yn gwybod dim am nifer y peiriannau sy'n cael eu defnyddio. Nid oes ganddo offeryn sy'n eich galluogi i raddfa'r system ar lefel y nod.
Felly bydd yn rhaid i ni ofalu am y nodau a'r codennau. Gallwn ni raddio lansiad nodau newydd yn hawdd gan ddefnyddio peiriannau grŵp API a Scaling AWS i ffurfweddu nifer nodau gweithwyr Kubernetes. Gallwch hefyd ddefnyddio cloud-init neu sgript debyg i gofrestru nodau yng nghlwstwr Kubernetes.
Mae'r peiriant newydd yn cychwyn yn y grŵp Scaling, yn cychwyn ei hun fel nod, yn cofrestru yng nghofrestrfa'r meistr ac yn dechrau gweithio. Ar ôl hyn, gallwch gynyddu nifer y copïau i'w defnyddio ar y nodau canlyniadol. Mae graddio i lawr yn gofyn am fwy o ymdrech, gan fod angen i chi sicrhau nad yw cam o'r fath yn arwain at ddinistrio cymwysiadau sydd eisoes yn rhedeg ar ôl diffodd peiriannau "diangen". Er mwyn atal senario o'r fath, mae angen i chi osod y nodau i'r statws "heb ei drefnu". Mae hyn yn golygu y bydd y trefnydd rhagosodedig yn anwybyddu'r nodau hyn wrth amserlennu codennau DaemonSet. Ni fydd y trefnydd yn dileu unrhyw beth o'r gweinyddwyr hyn, ond ni fydd hefyd yn lansio unrhyw gynwysyddion newydd yno. Y cam nesaf yw dileu'r nôd draen, hynny yw, trosglwyddo codennau rhedeg ohono i beiriant arall, neu nodau eraill sydd â chapasiti digonol ar gyfer hyn. Unwaith y byddwch wedi sicrhau nad oes unrhyw gynwysyddion ar y nodau hyn mwyach, gallwch eu tynnu o Kubernetes. Ar ôl hyn, byddant yn peidio â bodoli ar gyfer Kubernetes. Nesaf, mae angen i chi ddefnyddio'r API AWS i analluogi nodau neu beiriannau diangen.
Gallwch ddefnyddio Amdatu Scalerd, offeryn graddio ffynhonnell agored arall tebyg i API AWS. Mae'n darparu CLI i ychwanegu neu ddileu nodau mewn clwstwr. Ei nodwedd ddiddorol yw'r gallu i ffurfweddu'r amserlennydd gan ddefnyddio'r ffeil json ganlynol.
Mae'r cod a ddangosir yn lleihau capasiti'r clwstwr o hanner yn ystod y nos. Mae'n ffurfweddu nifer y copïau sydd ar gael a chynhwysedd dymunol clwstwr Amazon. Bydd defnyddio'r rhaglennydd hwn yn lleihau nifer y nodau yn y nos yn awtomatig ac yn eu cynyddu yn y bore, gan arbed cost defnyddio nodau o wasanaeth cwmwl fel Amazon. Nid yw'r nodwedd hon wedi'i chynnwys yn Kubernetes, ond bydd defnyddio Scalerd yn caniatáu ichi raddio'r platfform hwn sut bynnag y dymunwch.
Hoffwn nodi bod llawer o bobl yn dweud wrthyf, “Mae hynny'n iawn ac yn dda, ond beth am fy nghronfa ddata, sydd fel arfer yn sefydlog?” Sut allwch chi redeg rhywbeth fel hyn mewn amgylchedd deinamig fel Kubernetes? Yn fy marn i, ni ddylech wneud hyn, ni ddylech geisio rhedeg warws data yn Kubernetes. Mae hyn yn dechnegol bosibl, ac mae tiwtorialau ar y Rhyngrwyd ar y pwnc hwn, ond bydd yn cymhlethu'ch bywyd yn ddifrifol.
Oes, mae cysyniad o siopau parhaus yn Kubernetes, a gallwch geisio rhedeg siopau data fel Mongo neu MySQL, ond mae hon yn dasg eithaf llafurddwys. Mae hyn oherwydd y ffaith nad yw warysau data yn cefnogi rhyngweithio ag amgylchedd deinamig yn llawn. Mae angen cyfluniad sylweddol ar y rhan fwyaf o gronfeydd data, gan gynnwys cyfluniad â llaw o'r clwstwr, nid ydynt yn hoffi awtoraddio a phethau tebyg eraill.
Felly, ni ddylech gymhlethu'ch bywyd trwy geisio rhedeg warws data yn Kubernetes. Trefnwch eu gwaith yn y ffordd draddodiadol gan ddefnyddio gwasanaethau cyfarwydd a rhowch y gallu i Kubernetes eu defnyddio.
I gloi'r pwnc, hoffwn eich cyflwyno i lwyfan Cloud RTI yn seiliedig ar Kubernetes, y mae fy nhîm yn gweithio arno. Mae'n darparu logio canolog, cymhwysiad a monitro clwstwr, a llawer o nodweddion defnyddiol eraill a fydd yn ddefnyddiol. Mae'n defnyddio offer ffynhonnell agored amrywiol fel Grafana i arddangos monitro.
Roedd cwestiwn ynghylch pam defnyddio'r balancer llwyth ha-procsi gyda Kubernetes. Cwestiwn da oherwydd ar hyn o bryd mae 2 lefel o gydbwyso llwyth. Mae gwasanaethau Kubernetes yn dal i fyw ar gyfeiriadau IP rhithwir. Ni allwch eu defnyddio ar gyfer porthladdoedd ar beiriannau cynnal allanol oherwydd os bydd Amazon yn gorlwytho ei westeiwr cwmwl, bydd y cyfeiriad yn newid. Dyma pam rydyn ni'n gosod ha-proxy o flaen y gwasanaethau - i greu strwythur mwy sefydlog i draffig gyfathrebu'n ddi-dor â Kubernetes.
Cwestiwn da arall yw sut allwch chi ofalu am newidiadau sgema cronfa ddata wrth wneud defnydd glas/gwyrdd? Y ffaith yw, waeth beth fo'r defnydd o Kubernetes, mae newid sgema'r gronfa ddata yn dasg anodd. Mae angen i chi sicrhau bod y sgema hen a newydd yn gydnaws, ac ar ôl hynny gallwch chi ddiweddaru'r gronfa ddata ac yna diweddaru'r cymwysiadau eu hunain. Gallwch boeth cyfnewid y gronfa ddata ac yna diweddaru'r ceisiadau. Gwn am bobl sydd wedi cychwyn clwstwr cronfa ddata cwbl newydd gyda sgema newydd, mae hwn yn opsiwn os oes gennych gronfa ddata heb gynllun fel Mongo, ond nid yw'n dasg hawdd beth bynnag. Os nad oes gennych unrhyw gwestiynau pellach, diolch am eich sylw!
Rhai hysbysebion 🙂
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, , analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com