Helo, fy enw i yw Dmitry Krasnov. Am fwy na phum mlynedd rwyf wedi bod yn gweinyddu clystyrau Kubernetes ac adeiladu pensaernïaeth microwasanaeth cymhleth. Ar ddechrau'r flwyddyn hon, fe wnaethom lansio gwasanaeth ar gyfer rheoli clystyrau Kubernetes yn seiliedig ar Containerum. Gan gymryd y cyfle hwn, dywedaf wrthych beth yw Kubernetes a sut mae integreiddio â gwerthwr yn wahanol i ffynhonnell agored.
I ddechrau, beth yw . Mae hon yn system ar gyfer rheoli cynwysyddion ar nifer fawr o westeion. O'r Groeg, gyda llaw, fe'i cyfieithir fel "peilot" neu "helmsman." Wedi'i ddatblygu'n wreiddiol gan Google ac yna wedi'i roi fel cyfraniad technoleg i'r Cloud Native Computing Foundation, sefydliad dielw rhyngwladol sy'n dod â datblygwyr, defnyddwyr terfynol a darparwyr technoleg cynhwysydd blaenllaw'r byd ynghyd.
Rheoli nifer fawr o gynwysyddion
Nawr gadewch i ni ddarganfod pa fath o gynwysyddion yw'r rhain. Mae hwn yn gymhwysiad gyda'i amgylchedd cyfan - yn bennaf y llyfrgelloedd y mae'r rhaglen yn dibynnu arnynt. Mae hyn i gyd yn cael ei becynnu mewn archifau a'i gyflwyno ar ffurf delwedd y gellir ei rhedeg waeth beth fo'r system weithredu, ei phrofi a mwy. Ond mae yna broblem - mae rheoli cynwysyddion ar nifer fawr o westeion yn anodd iawn. Dyna pam y crëwyd Kubernetes.
Mae delwedd cynhwysydd yn cynrychioli cais ynghyd â'i ddibyniaethau. Mae'r cais, ei ddibyniaethau, a delwedd system ffeiliau OS wedi'u lleoli mewn gwahanol rannau o'r ddelwedd, haenau fel y'u gelwir. Gellir ailddefnyddio haenau ar gyfer gwahanol gynwysyddion. Er enghraifft, gallai pob cais mewn cwmni ddefnyddio haen sylfaen Ubuntu. Wrth redeg cynwysyddion, nid oes angen storio copïau lluosog o un haen sylfaen ar y gwesteiwr. Mae hyn yn caniatáu ichi optimeiddio storio a danfon delweddau.
Pan fyddwn am redeg cais o gynhwysydd, mae'r haenau angenrheidiol yn cael eu harosod ar ei gilydd a ffurfir system ffeiliau troshaen. Rhoddir haen recordio ar ei ben, sy'n cael ei dynnu pan fydd y cynhwysydd yn stopio. Mae hyn yn sicrhau, pan fydd y cynhwysydd yn rhedeg, y bydd gan y cais yr un amgylchedd bob amser, na ellir ei newid. Mae hyn yn gwarantu atgynhyrchu'r amgylchedd ar wahanol OSes gwesteiwr. P'un a yw'n Ubuntu neu CentOS, bydd yr amgylchedd bob amser yr un peth. Yn ogystal, mae'r cynhwysydd wedi'i ynysu oddi wrth y gwesteiwr gan ddefnyddio mecanweithiau sydd wedi'u hymgorffori yn y cnewyllyn Linux. Nid yw ceisiadau mewn cynhwysydd yn gweld ffeiliau, prosesau'r gwesteiwr a chynwysyddion cyfagos. Mae'r ynysu hwn o gymwysiadau o'r OS gwesteiwr yn darparu haen ychwanegol o ddiogelwch.
Mae yna lawer o offer ar gael i reoli cynwysyddion ar westeiwr. Y mwyaf poblogaidd ohonynt yw Docker. Mae'n caniatáu ichi ddarparu cylch bywyd llawn cynwysyddion. Fodd bynnag, dim ond ar un gwesteiwr y mae'n gweithio. Os oes angen i chi reoli cynwysyddion ar draws gwesteiwyr lluosog, gall Docker wneud uffern bywyd i beirianwyr. Dyna pam y crëwyd Kubernetes.
Mae'r galw am Kubernetes yn union oherwydd y gallu i reoli grwpiau o gynwysyddion ar westeion lluosog fel rhyw fath o endid sengl. Mae poblogrwydd y system yn rhoi'r cyfle i adeiladu DevOps neu Weithrediadau Datblygu, lle mae Kubernetes yn cael ei ddefnyddio i redeg prosesau'r DevOps hwn.
Ffigur 1. Cynrychioliad sgematig o sut mae Kubernetes yn gweithio
Awtomatiaeth llawn
Yn y bôn, DevOps yw awtomeiddio'r broses ddatblygu. Yn fras, mae datblygwyr yn ysgrifennu cod sy'n cael ei uwchlwytho i'r ystorfa. Yna gellir casglu'r cod hwn yn awtomatig ar unwaith i mewn i gynhwysydd gyda'r holl lyfrgelloedd, ei brofi a'i “roi allan” i'r cam nesaf - Llwyfannu, ac yna ar unwaith i Gynhyrchu.
Ynghyd â Kubernetes, mae DevOps yn caniatáu ichi awtomeiddio'r broses hon fel ei bod yn digwydd heb fawr ddim cyfranogiad gan y datblygwyr eu hunain. Oherwydd hyn, mae'r adeilad yn sylweddol gyflymach, gan nad oes rhaid i'r datblygwr wneud hyn ar ei gyfrifiadur - yn syml, mae'n ysgrifennu darn o god, yn gwthio'r cod i'r ystorfa, ac ar ôl hynny mae'r biblinell yn cael ei lansio, a all gynnwys y broses. o adeiladu, profi, a chyflwyno. Ac mae hyn yn digwydd gyda phob ymrwymiad, felly mae profion yn digwydd yn barhaus.
Ar yr un pryd, mae defnyddio cynhwysydd yn eich galluogi i fod yn siŵr y bydd amgylchedd cyfan y rhaglen hon yn cael ei ryddhau i gynhyrchu yn union yn y ffurf y cafodd ei brofi. Hynny yw, ni fydd unrhyw broblemau fel “roedd rhai fersiynau yn y prawf, eraill yn cael eu cynhyrchu, ond pan wnaethon ni eu gosod, syrthiodd popeth.” Ac ers heddiw mae gennym duedd tuag at bensaernïaeth microwasanaeth, pan fydd cannoedd o rai bach yn lle un cymhwysiad enfawr, er mwyn eu gweinyddu â llaw, bydd angen staff enfawr o weithwyr. Dyna pam rydyn ni'n defnyddio Kubernetes.
Manteision, manteision, manteision
Os byddwn yn siarad am fanteision Kubernetes fel platfform, yna mae ganddo fanteision sylweddol o safbwynt rheoli pensaernïaeth microwasanaeth.
- Rheoli atgynyrchiadau lluosog. Y peth pwysicaf yw rheoli cynwysyddion ar draws gwesteiwyr lluosog. Yn bwysicach fyth, rheoli copïau cais lluosog mewn cynwysyddion fel endid sengl. Diolch i hyn, nid oes rhaid i beirianwyr boeni am bob cynhwysydd unigol. Os bydd un o'r cynwysyddion yn damwain, bydd Kubernetes yn gweld hyn ac yn ei ailgychwyn eto.
- Rhwydwaith clwstwr. Mae gan Kubernetes hefyd rwydwaith clwstwr fel y'i gelwir gyda'i ofod cyfeiriad ei hun. Diolch i hyn, mae gan bob pod ei gyfeiriad ei hun. Deellir subpod fel uned strwythurol leiaf clwstwr lle mae cynwysyddion yn cael eu lansio'n uniongyrchol. Yn ogystal, mae gan Kubernetes ymarferoldeb sy'n cyfuno cydbwysedd llwyth a Darganfod Gwasanaeth. Mae hyn yn caniatáu ichi gael gwared ar reoli cyfeiriad IP â llaw a dirprwyo'r dasg hon i Kubernetes. A bydd gwiriadau iechyd awtomatig yn helpu i ganfod problemau ac ailgyfeirio traffig i godennau gweithio.
- Rheoli cyfluniad. Wrth reoli nifer fawr o gymwysiadau, mae'n dod yn anodd rheoli cyfluniad cymwysiadau. At y diben hwn, mae gan Kubernetes adnoddau ConfigMap arbennig. Maent yn caniatáu ichi storio cyfluniadau'n ganolog a'u hamlygu i godau wrth redeg cymwysiadau. Mae'r mecanwaith hwn yn ein galluogi i warantu cysondeb y ffurfweddiad mewn o leiaf ddeg neu gant o atgynhyrchiadau cais.
- Cyfrolau Parhaus. Mae cynwysyddion yn gynhenid na ellir eu cyfnewid a phan fydd y cynhwysydd yn cael ei stopio, bydd yr holl ddata a ysgrifennir i'r system ffeiliau yn cael ei ddinistrio. Ond mae rhai cymwysiadau yn storio data yn uniongyrchol ar ddisg. I ddatrys y broblem hon, mae gan Kubernetes swyddogaeth rheoli storio disg - Cyfrolau Parhaus. Mae'r mecanwaith hwn yn defnyddio storfa allanol ar gyfer data a gall drosglwyddo storfa barhaus, bloc neu ffeil, i gynwysyddion. Mae'r datrysiad hwn yn caniatáu ichi storio data ar wahân i weithwyr, sy'n eu harbed os bydd yr un gweithwyr hyn yn torri i lawr.
- Llwyth Balancer. Er ein bod yn Kubernetes yn rheoli endidau haniaethol fel Deployment, StatefulSet, ac ati, yn y pen draw mae cynwysyddion yn rhedeg ar beiriannau rhithwir rheolaidd neu weinyddion caledwedd. Nid ydynt yn berffaith a gallant ddisgyn ar unrhyw adeg. Bydd Kubernetes yn gweld hyn ac yn ailgyfeirio traffig mewnol i atgynyrchiadau eraill. Ond beth i'w wneud gyda thraffig sy'n dod o'r tu allan? Os ydych chi'n cyfeirio traffig at un o'r gweithwyr yn unig, os bydd yn damwain, ni fydd y gwasanaeth ar gael. I ddatrys y broblem hon, mae gan Kubernetes wasanaethau fel Load Balancer. Maent wedi'u cynllunio i ffurfweddu cydbwysydd cwmwl allanol yn awtomatig ar gyfer yr holl weithwyr yn y clwstwr. Mae'r cydbwysedd allanol hwn yn cyfeirio traffig allanol i weithwyr ac yn monitro eu statws ei hun. Os na fydd un neu fwy o weithwyr ar gael, caiff traffig ei ailgyfeirio i eraill. Mae hyn yn caniatáu ichi greu gwasanaethau sydd ar gael yn fawr gan ddefnyddio Kubernetes.
Mae Kubernetes yn gweithio orau wrth redeg pensaernïaeth microwasanaeth. Mae'n bosibl gweithredu'r system i bensaernïaeth glasurol, ond mae'n ddibwrpas. Os na all cais redeg ar atgynyrchiadau lluosog, yna pa wahaniaeth y mae'n ei wneud - yn Kubernetes ai peidio?
Kubernetes ffynhonnell agored
Mae ffynhonnell agored Kubernetes yn beth gwych: fe'i gosodais ac mae'n gweithio. Gallwch ei ddefnyddio ar eich gweinyddwyr caledwedd eich hun, ar eich seilwaith eich hun, gosod meistri a gweithwyr y bydd pob rhaglen yn rhedeg arnynt. Ac yn bwysicaf oll, mae hyn i gyd yn rhad ac am ddim. Fodd bynnag, mae yna arlliwiau.
- Y cyntaf yw'r galw am wybodaeth a phrofiad gweinyddwyr a pheirianwyr a fydd yn defnyddio ac yn cefnogi hyn i gyd. Gan fod y cleient yn cael rhyddid llwyr i weithredu yn y clwstwr, mae'n gyfrifol am berfformiad y clwstwr ei hun. Ac mae'n hawdd iawn torri popeth yma.
- Yr ail yw diffyg integreiddiadau. Os ydych chi'n rhedeg Kubernetes heb blatfform rhithwiroli poblogaidd, ni chewch holl fanteision y rhaglen. Megis defnyddio gwasanaethau cydbwyso Cyfaint Parhaus a Llwyth.
Ffigur 2. pensaernïaeth k8s
Kubernetes gan y gwerthwr
Mae integreiddio â darparwr cwmwl yn darparu dau opsiwn:
- Yn gyntaf, gall person glicio ar y botwm “creu clwstwr” a chael clwstwr sydd eisoes wedi'i ffurfweddu ac yn barod i'w ddefnyddio.
- Yn ail, mae'r gwerthwr ei hun yn gosod y clwstwr ac yn sefydlu integreiddio â'r cwmwl.
Sut mae'n digwydd yma. Mae'r peiriannydd sy'n cychwyn y clwstwr yn nodi faint o weithwyr sydd eu hangen arno a pha baramedrau (er enghraifft, 5 gweithiwr, pob un â 10 CPUs, 16 GB o RAM a, dyweder, 100 GB o ddisg). Ar ôl hynny mae'n cael mynediad i'r clwstwr sydd eisoes wedi'i ffurfio. Yn yr achos hwn, mae'r gweithwyr y mae'r llwyth yn cael ei lansio arnynt yn cael eu trosglwyddo'n llwyr i'r cleient, ond mae'r awyren reoli gyfan yn parhau i fod o dan gyfrifoldeb y gwerthwr (os yw'r gwasanaeth yn cael ei ddarparu yn unol â'r model gwasanaeth a reolir).
Fodd bynnag, mae gan y cynllun hwn ei anfanteision. Oherwydd y ffaith bod yr awyren reoli yn aros gyda'r gwerthwr, nid yw'r gwerthwr yn rhoi mynediad llawn i'r cleient, ac mae hyn yn lleihau hyblygrwydd wrth weithio gyda Kubernetes. Weithiau mae'n digwydd bod cleient eisiau ychwanegu rhywfaint o ymarferoldeb penodol i Kubernetes, er enghraifft, dilysu trwy LDAP, ond nid yw cyfluniad yr awyren reoli yn caniatáu hyn.
Ffigur 3. Enghraifft o glwstwr Kubernetes gan ddarparwr cwmwl
Beth i'w ddewis: ffynhonnell agored neu werthwr
Felly, a yw Kubernetes ffynhonnell agored neu werthwr penodol? Os cymerwn Kubernetes ffynhonnell agored, yna mae'r defnyddiwr yn gwneud yr hyn y mae ei eisiau ag ef. Ond mae siawns wych o saethu eich hun yn y droed. Gyda'r gwerthwr mae'n anoddach, oherwydd mae popeth yn cael ei feddwl a'i ffurfweddu ar gyfer y cwmni. Yr anfantais fwyaf o ffynhonnell agored Kubernetes yw'r gofyniad am arbenigwyr. Gydag opsiwn gwerthwr, mae'r cwmni'n cael ei ryddhau o'r cur pen hwn, ond bydd yn rhaid iddo benderfynu a ddylid talu ei arbenigwyr neu'r gwerthwr.
Wel, mae'r manteision yn amlwg, mae'r anfanteision hefyd yn hysbys. Mae un peth yn gyson: mae Kubernetes yn datrys llawer o broblemau trwy awtomeiddio rheolaeth llawer o gynwysyddion. A pha un i'w ddewis, ffynhonnell agored neu werthwr - mae pawb yn gwneud eu penderfyniad eu hunain.
Paratowyd yr erthygl gan Dmitry Krasnov, prif bensaer gwasanaeth Containerum y darparwr #CloudMTS
Ffynhonnell: hab.com