Ciwb-ar-ciwb, meta-glystyrau, crwybrau, dosbarthu adnoddau

Reis. 1. ecosystem Kubernetes ar Alibaba Cloud

Ers 2015, mae Gwasanaeth Cynhwysydd Cwmwl Alibaba ar gyfer Kubernetes (ACK) wedi bod yn un o'r gwasanaethau cwmwl sy'n tyfu gyflymaf yn Alibaba Cloud. Mae'n gwasanaethu nifer o gleientiaid a hefyd yn cefnogi seilwaith mewnol Alibaba a gwasanaethau cwmwl eraill y cwmni.

Yn yr un modd â gwasanaethau cynwysyddion tebyg gan ddarparwyr cwmwl o'r radd flaenaf, ein prif flaenoriaethau yw dibynadwyedd ac argaeledd. Felly, mae platfform graddadwy a hygyrch yn fyd-eang wedi'i greu ar gyfer degau o filoedd o glystyrau Kubernetes.

Yn yr erthygl hon, byddwn yn rhannu ein profiad o reoli nifer fawr o glystyrau Kubernetes ar seilwaith cwmwl, yn ogystal â phensaernïaeth y llwyfan sylfaenol.

Mynediad

Mae Kubernetes wedi dod yn safon de facto ar gyfer amrywiaeth o lwythi gwaith yn y cwmwl. Fel y dangosir yn Ffig. 1 uchod, mae mwy a mwy o gymwysiadau Alibaba Cloud bellach yn rhedeg ar glystyrau Kubernetes: cymwysiadau gwladwriaethol a di-wladwriaeth, yn ogystal â rheolwyr cymwysiadau. Mae rheolaeth Kubernetes bob amser wedi bod yn bwnc trafod diddorol a difrifol i beirianwyr sy'n adeiladu ac yn cynnal a chadw seilwaith. O ran darparwyr cwmwl fel Alibaba Cloud, mae mater graddio yn dod i'r amlwg. Sut i reoli clystyrau Kubernetes ar y raddfa hon? Rydym eisoes wedi ymdrin ag arferion gorau ar gyfer rheoli clystyrau enfawr o 10 nod Kubernetes. Wrth gwrs, mae hon yn broblem raddio ddiddorol. Ond mae graddfa arall: maint y clystyrau eu hunain.

Rydym wedi trafod y pwnc hwn gyda llawer o ddefnyddwyr ACK. Mae'r rhan fwyaf ohonynt yn dewis rhedeg dwsinau, os nad cannoedd, o glystyrau Kubernetes bach neu ganolig. Mae rhesymau da am hyn: cyfyngu ar ddifrod posibl, gwahanu clystyrau ar gyfer gwahanol dimau, creu clystyrau rhithwir ar gyfer profi. Os yw ACK yn anelu at wasanaethu cynulleidfa fyd-eang gyda'r model defnydd hwn, rhaid iddo reoli nifer fawr o glystyrau ar draws mwy nag 20 rhanbarth yn ddibynadwy ac yn effeithlon.

Reis. 2. Problemau rheoli nifer enfawr o glystyrau Kubernetes

Beth yw prif heriau rheoli clystyrau ar y raddfa hon? Fel y dangosir yn y ffigur, mae pedwar mater i ymdrin â hwy:

• Heterogenedd

Dylai ACK gefnogi gwahanol fathau o glystyrau, gan gynnwys clystyrau safonol, di-weinydd, Edge, Windows, a sawl un arall. Mae angen gwahanol opsiynau, cydrannau a modelau cynnal ar wahanol glystyrau. Mae angen cymorth ar rai cwsmeriaid i addasu ar gyfer eu hachosion penodol.

• Meintiau clwstwr amrywiol

Mae clystyrau'n amrywio o ran maint, o un neu ddau o nodau gyda rhai codennau i ddegau o filoedd o nodau gyda miloedd o godennau. Mae gofynion adnoddau hefyd yn amrywio'n fawr. Gall dyraniad adnoddau amhriodol effeithio ar berfformiad neu hyd yn oed achosi methiant.

• Fersiynau gwahanol

Mae Kubernetes yn esblygu'n gyflym iawn. Mae fersiynau newydd yn cael eu rhyddhau bob ychydig fisoedd. Mae cwsmeriaid bob amser yn barod i roi cynnig ar nodweddion newydd. Felly maen nhw am osod y llwyth prawf ar y fersiynau newydd o Kubernetes a'r llwyth cynhyrchu ar y rhai sefydlog. Er mwyn bodloni'r gofyniad hwn, rhaid i ACK gyflwyno fersiynau newydd o Kubernetes i gwsmeriaid yn barhaus wrth gynnal fersiynau sefydlog.

• Cydymffurfiad Diogelwch

Dosberthir clystyrau ar draws gwahanol ranbarthau. O'r herwydd, rhaid iddynt gydymffurfio â gofynion diogelwch amrywiol a rheoliadau swyddogol. Er enghraifft, rhaid i glwstwr yn Ewrop gydymffurfio â GDPR, tra bod yn rhaid i gwmwl ariannol yn Tsieina gael haenau ychwanegol o amddiffyniad. Mae'r gofynion hyn yn orfodol ac mae'n annerbyniol eu hanwybyddu, gan fod hyn yn creu risgiau enfawr i gleientiaid y llwyfan cwmwl.

Mae'r llwyfan ACK wedi'i gynllunio i ddatrys y rhan fwyaf o'r problemau uchod. Ar hyn o bryd mae'n rheoli mwy na 10 mil o glystyrau Kubernetes ledled y byd yn ddibynadwy ac yn sefydlog. Gadewch i ni edrych ar sut y cyflawnwyd hyn, gan gynnwys trwy nifer o egwyddorion dylunio/pensaernïaeth allweddol.

Dylunio

Ciwb-ar-ciwb a diliau mêl

Yn wahanol i hierarchaeth ganolog, mae pensaernïaeth sy'n seiliedig ar gelloedd yn cael ei defnyddio'n nodweddiadol i raddio llwyfan y tu hwnt i un ganolfan ddata neu i ehangu cwmpas adfer ar ôl trychineb.

Mae pob rhanbarth yn y Cwmwl Alibaba yn cynnwys sawl parth (AZ) ac fel arfer yn cyfateb i ganolfan ddata benodol. Mewn rhanbarth mawr (e.e. Huangzhou), yn aml mae miloedd o glystyrau cleientiaid Kubernetes yn rhedeg ACK.

Mae ACK yn rheoli'r clystyrau Kubernetes hyn gan ddefnyddio Kubernetes ei hun, sy'n golygu bod gennym ni fetacluster Kubernetes yn rhedeg i reoli clystyrau Kubernetes cleient. Gelwir y bensaernïaeth hon hefyd yn “kube-on-kube” (KoK). Mae pensaernïaeth KoK yn symleiddio rheolaeth clystyrau cleientiaid oherwydd bod y defnydd o glystyrau yn syml a phenderfynol. Yn bwysicach fyth, gallwn ailddefnyddio nodweddion brodorol Kubernetes. Er enghraifft, rheoli gweinyddwyr API trwy ddefnyddio, defnyddio'r gweithredwr ac ati i reoli ac ati lluosog. Mae dychweliad o'r fath bob amser yn dod â phleser arbennig.

Mae sawl metacluster Kubernetes yn cael eu defnyddio o fewn un rhanbarth, yn dibynnu ar nifer y cleientiaid. Rydyn ni'n galw'r metaclusterau hyn yn gelloedd. Er mwyn amddiffyn rhag methiant parth cyfan, mae ACK yn cefnogi gosodiadau aml-weithredol mewn un rhanbarth: mae'r metacluster yn dosbarthu prif gydrannau clwstwr cleientiaid Kubernetes ar draws parthau lluosog ac yn eu rhedeg ar yr un pryd, hynny yw, mewn modd aml-weithredol. Er mwyn sicrhau dibynadwyedd ac effeithlonrwydd y meistr, mae ACK yn gwneud y gorau o leoliad cydrannau ac yn sicrhau bod y gweinydd API ac ati yn agos at ei gilydd.

Mae'r model hwn yn caniatáu ichi reoli Kubernetes yn effeithlon, yn hyblyg ac yn ddibynadwy.

Cynllunio adnoddau metacluster

Fel y soniasom eisoes, mae nifer y metaclusterau ym mhob rhanbarth yn dibynnu ar nifer y cleientiaid. Ond ar ba bwynt i ychwanegu metacluster newydd? Mae hon yn broblem cynllunio adnoddau nodweddiadol. Fel rheol, mae'n arferol creu un newydd pan fydd metaclusterau presennol wedi disbyddu eu holl adnoddau.

Gadewch i ni gymryd adnoddau rhwydwaith, er enghraifft. Ym mhensaernïaeth KoK, mae cydrannau Kubernetes o glystyrau cleientiaid yn cael eu defnyddio fel codennau mewn metacluster. Rydym yn defnyddio Terway (Ffig. 3) yn ategyn perfformiad uchel a ddatblygwyd gan Alibaba Cloud ar gyfer rheoli rhwydwaith cynwysyddion. Mae'n darparu set gyfoethog o bolisïau diogelwch ac yn caniatáu ichi gysylltu â chymylau preifat rhithwir (VPCs) cwsmeriaid trwy Ryngwyneb Rhwydweithio Elastig Cwmwl Alibaba (ENI). Er mwyn dosbarthu adnoddau rhwydwaith yn effeithiol ar draws nodau, codennau a gwasanaethau mewn metaclwstwr, rhaid inni fonitro'n ofalus eu defnydd o fewn metaclwstwr cymylau preifat rhithwir. Pan ddaw adnoddau rhwydwaith i ben, crëir cell newydd.

Er mwyn pennu'r nifer gorau posibl o glystyrau cleientiaid ym mhob metaclwstwr, rydym hefyd yn ystyried ein costau, gofynion dwysedd, cwota adnoddau, gofynion dibynadwyedd ac ystadegau. Gwneir y penderfyniad i greu metaclwstwr newydd ar sail yr holl wybodaeth hon. Sylwch y gall clystyrau bach ehangu'n fawr yn y dyfodol, felly mae'r defnydd o adnoddau'n cynyddu hyd yn oed os bydd nifer y clystyrau yn aros heb newid. Fel arfer byddwn yn gadael digon o le am ddim i bob clwstwr dyfu.

Reis. 3. Pensaernïaeth rhwydwaith Terway

Graddio cydrannau dewin ar draws clystyrau cleientiaid

Mae gan gydrannau dewin anghenion adnoddau gwahanol. Maent yn dibynnu ar nifer y nodau a'r codennau yn y clwstwr, nifer y rheolwyr / gweithredwyr ansafonol sy'n rhyngweithio ag APIServer.

Yn ACK, mae pob clwstwr cleient Kubernetes yn wahanol o ran maint a gofynion amser rhedeg. Nid oes cyfluniad cyffredinol ar gyfer gosod cydrannau dewin. Os byddwn yn gosod terfyn adnoddau isel ar gam ar gyfer cleient mawr, yna ni fydd ei glwstwr yn gallu ymdopi â'r llwyth. Os byddwch yn gosod terfyn ceidwadol uchel ar gyfer pob clwstwr, caiff adnoddau eu gwastraffu.

I ddod o hyd i gyfaddawd cynnil rhwng dibynadwyedd a chost, mae ACK yn defnyddio system fath. Sef, rydym yn diffinio tri math o glwstwr: bach, canolig a mawr. Mae gan bob math broffil dyrannu adnoddau ar wahân. Mae'r math yn cael ei bennu yn seiliedig ar y llwyth o gydrannau dewin, nifer y nodau, a ffactorau eraill. Gall y math o glwstwr newid dros amser. Mae ACK yn monitro'r ffactorau hyn yn barhaus a gall deipio i fyny/i lawr yn unol â hynny. Unwaith y bydd y math o glwstwr yn cael ei newid, caiff y dyraniad adnoddau ei ddiweddaru'n awtomatig heb fawr o ymyrraeth gan ddefnyddwyr.

Rydym yn gweithio i wella'r system hon gyda graddio mwy manwl a diweddaru mathau mwy manwl gywir fel bod y newidiadau hyn yn digwydd yn fwy llyfn ac yn gwneud mwy o synnwyr economaidd.

Reis. 4. newid math aml-gam deallus

Esblygiad clystyrau cleientiaid ar raddfa

Roedd yr adrannau blaenorol yn ymdrin â rhai agweddau ar reoli niferoedd mawr o glystyrau Kubernetes. Fodd bynnag, mae problem arall y mae angen ei datrys: esblygiad clystyrau.

Kubernetes yw "Linux" byd y cwmwl. Mae'n cael ei ddiweddaru'n barhaus ac yn dod yn fwy modiwlaidd. Rhaid inni gyflwyno fersiynau newydd yn gyson i'n cwsmeriaid, trwsio gwendidau a diweddaru clystyrau presennol, yn ogystal â rheoli nifer fawr o gydrannau cysylltiedig (CSI, CNI, Device Plugin, Scheduler Plugin a llawer o rai eraill).

Gadewch i ni gymryd rheolaeth cydrannau Kubernetes fel enghraifft. I ddechrau, rydym wedi datblygu system ganolog ar gyfer cofrestru a rheoli'r holl gydrannau cysylltiedig hyn.

Reis. 5. Cydrannau hyblyg a phlygadwy

Cyn symud ymlaen, mae angen i chi sicrhau bod y diweddariad yn llwyddiannus. I wneud hyn, rydym wedi datblygu system ar gyfer gwirio ymarferoldeb cydrannau. Perfformir y gwiriad cyn ac ar ôl y diweddariad.

Reis. 6. Gwiriad rhagarweiniol o gydrannau clwstwr

Er mwyn diweddaru'r cydrannau hyn yn gyflym ac yn ddibynadwy, mae system defnyddio barhaus yn gweithio gyda chefnogaeth ar gyfer datblygiad rhannol (graddfa lwyd), seibiannau a swyddogaethau eraill. Nid yw rheolwyr safonol Kubernetes yn addas iawn ar gyfer yr achos defnydd hwn. Felly, i reoli cydrannau clwstwr, rydym wedi datblygu set o reolwyr arbenigol, gan gynnwys ategyn a modiwl rheoli ategol (rheoli ceir ochr).

Er enghraifft, mae rheolydd BroadcastJob wedi'i gynllunio i ddiweddaru cydrannau ar bob peiriant gweithiwr neu wirio nodau ar bob peiriant. Mae'r swydd Broadcast yn rhedeg pod ar bob nod yn y clwstwr, fel DaemonSet. Fodd bynnag, mae DaemonSet bob amser yn cadw'r pod yn rhedeg am amser hir, tra bod BroadcastJob yn ei gwympo. Mae'r rheolydd Darlledu hefyd yn lansio codennau ar nodau sydd newydd ymuno ac yn cychwyn y nodau gyda'r cydrannau angenrheidiol. Ym mis Mehefin 2019, fe wnaethom agor cod ffynhonnell injan awtomeiddio OpenKruise, yr ydym ni ein hunain yn ei ddefnyddio yn y cwmni.

Reis. 7. Mae OpenKurise yn trefnu cyflawni'r dasg Darlledu ar bob nod

Er mwyn helpu cwsmeriaid i ddewis y ffurfweddiadau clwstwr cywir, rydym hefyd yn darparu set o broffiliau wedi'u diffinio ymlaen llaw, gan gynnwys proffiliau Serverless, Edge, Windows, a Bare Metal. Wrth i'r dirwedd ehangu ac anghenion ein cwsmeriaid dyfu, byddwn yn ychwanegu mwy o broffiliau i symleiddio'r broses sefydlu ddiflas.

Reis. 8. Proffiliau clwstwr uwch a hyblyg ar gyfer gwahanol senarios

Arsylwedd byd-eang ar draws canolfannau data

Fel y dangosir yn y ffigur isod. 9, mae gwasanaeth cwmwl Alibaba Cloud Container wedi'i ddefnyddio mewn ugain rhanbarth ledled y byd. O ystyried y raddfa hon, un o nodau allweddol ACK yw monitro cyflwr rhedeg clystyrau yn hawdd fel y gallwn ymateb yn gyflym i'r sefyllfa os bydd clwstwr cleient yn dod ar draws problem. Mewn geiriau eraill, mae angen ichi ddod o hyd i ateb a fydd yn caniatáu ichi gasglu ystadegau mewn amser real yn effeithlon ac yn ddiogel o glystyrau cleientiaid ym mhob rhanbarth - a chyflwyno'r canlyniadau yn weledol.

Reis. 9. Defnydd byd-eang o wasanaeth Cynhwysydd Cwmwl Alibaba mewn ugain rhanbarth

Fel llawer o systemau monitro Kubernetes, rydym yn defnyddio Prometheus fel ein prif offeryn. Ar gyfer pob metacluster, mae asiantau Prometheus yn casglu'r metrigau canlynol:

• metrigau OS megis adnoddau gwesteiwr (CPU, cof, disg, ac ati) a lled band rhwydwaith.
• Metrigau ar gyfer y metacluster a system rheoli clwstwr cleientiaid, megis kube-apiserver, kube-controller-rheolwr a kube-scheduler.
• Metrigau o kubernetes-state-metrics a chadvisor.
• metrigau ac ati fel amser ysgrifennu disg, maint cronfa ddata, trwygyrch cysylltiadau rhwng nodau, ac ati.

Cesglir ystadegau byd-eang gan ddefnyddio model agregu aml-haen nodweddiadol. Mae data monitro o bob metaclwstwr yn cael ei agregu gyntaf ym mhob rhanbarth ac yna'n cael ei anfon at weinydd canolog sy'n dangos y darlun cyffredinol. Mae popeth yn gweithio trwy fecanwaith y ffederasiwn. Mae gweinydd Prometheus ym mhob canolfan ddata yn casglu metrigau o'r ganolfan ddata honno, a'r gweinydd Prometheus canolog sy'n gyfrifol am agregu data monitro. AlertManager cysylltu â Prometheus canolog ac, os oes angen, yn anfon rhybuddion trwy DingTalk , e-bost , SMS , ac ati Delweddu - gan ddefnyddio Grafana .

Yn Ffigur 10, gellir rhannu'r system fonitro yn dair lefel:

• Lefel ffin

Yr haen sydd bellaf o'r canol. Mae Gweinydd Prometheus Edge yn rhedeg ym mhob metaclwstwr, gan gasglu metrigau o glystyrau meta a chleientiaid o fewn yr un parth rhwydwaith.

• Lefel rhaeadru

Swyddogaeth haen rhaeadru Prometheus yw casglu data monitro o ranbarthau lluosog. Mae'r gweinyddwyr hyn yn gweithredu ar lefel unedau daearyddol mwy fel Tsieina, Asia, Ewrop ac America. Wrth i glystyrau dyfu, gellir rhannu'r rhanbarth, ac yna bydd gweinydd Prometheus lefel rhaeadru yn ymddangos ym mhob rhanbarth mawr newydd. Gyda'r strategaeth hon, gallwch raddio'n llyfn yn ôl yr angen.

• Lefel ganolog

Mae'r gweinydd Prometheus canolog yn cysylltu â'r holl weinyddion rhaeadru ac yn perfformio'r cydgasglu data terfynol. Ar gyfer dibynadwyedd, codwyd dau achos Prometheus canolog mewn gwahanol barthau, wedi'u cysylltu â'r un gweinyddwyr rhaeadru.

Reis. 10. Pensaernïaeth fonitro aml-lefel fyd-eang yn seiliedig ar fecanwaith ffederasiwn Prometheus

Crynodeb

Mae datrysiadau cwmwl seiliedig ar Kubernetes yn parhau i drawsnewid ein diwydiant. Mae gwasanaeth cynhwysydd Alibaba Cloud yn darparu gwesteiwr diogel, dibynadwy a pherfformiad uchel - mae'n un o'r gwesteiwr cwmwl Kubernetes gorau. Mae tîm Alibaba Cloud yn credu'n gryf yn egwyddorion Ffynhonnell Agored a'r gymuned ffynhonnell agored. Byddwn yn bendant yn parhau i rannu ein gwybodaeth ym maes gweithredu a rheoli technolegau cwmwl.

Ffynhonnell: hab.com