Kubernetes er frábært tæki til að keyra Docker gáma í þyrptu framleiðsluumhverfi. Hins vegar eru vandamál sem Kubernetes getur ekki leyst. Fyrir tíðar framleiðsluuppsetningar þurfum við fullkomlega sjálfvirka bláa/græna uppsetningu til að forðast niður í miðbæ í ferlinu, sem þarf einnig að sinna utanaðkomandi HTTP beiðnum og framkvæma SSL afhleðslu. Þetta krefst samþættingar við álagsjafnara eins og ha-proxy. Önnur áskorun er hálfsjálfvirk stigstærð á Kubernetes klasanum sjálfum þegar keyrt er í skýjaumhverfi, til dæmis að minnka klasann að hluta á nóttunni.
Þó að Kubernetes sé ekki með þessa eiginleika út úr kassanum, þá býður það upp á API sem þú getur notað til að leysa svipuð vandamál. Verkfæri fyrir sjálfvirka bláa/græna uppsetningu og mælikvarða á Kubernetes klasa voru þróuð sem hluti af Cloud RTI verkefninu, sem var búið til byggt á opnum uppspretta.
Þessi grein, myndbandsuppskrift, sýnir þér hvernig á að setja upp Kubernetes ásamt öðrum opnum íhlutum til að búa til framleiðslutilbúið umhverfi sem tekur við kóða frá git commit án niðurtíma í framleiðslu.
Svo þegar þú hefur aðgang að forritunum þínum frá umheiminum geturðu byrjað að setja upp sjálfvirkni að fullu, það er að koma því á það stig að þú getur framkvæmt git commit og tryggt að þessi git commit endi í framleiðslu. Auðvitað, þegar við innleiðum þessi skref, við innleiðingu dreifingar, viljum við ekki lenda í niður í miðbæ. Svo, öll sjálfvirkni í Kubernetes byrjar með API.
Kubernetes er ekki tæki sem hægt er að nota á afkastamikinn hátt út úr kassanum. Auðvitað geturðu gert það, notað kubectl og svo framvegis, en samt sem áður er API það áhugaverðasta og gagnlegasta við þennan vettvang. Með því að nota API sem mengi aðgerða geturðu nálgast næstum allt sem þú vilt gera í Kubernetes. kubectl sjálft notar einnig REST API.
Þetta er REST, svo þú getur notað hvaða tungumál eða tól sem er til að vinna með þetta API, en líf þitt verður miklu auðveldara með sérsniðnum bókasöfnum. Liðið mitt skrifaði 2 slík bókasöfn: eitt fyrir Java/OSGi og eitt fyrir Go. Sá seinni er ekki oft notaður, en í öllum tilvikum hefur þú þessa gagnlegu hluti til umráða. Þau eru opinn uppspretta verkefni með leyfi að hluta. Það eru mörg slík bókasöfn fyrir mismunandi tungumál, svo þú getur valið þau sem henta þér best.
Svo, áður en þú byrjar að gera sjálfvirkan dreifingu þína, þarftu að ganga úr skugga um að ferlið verði ekki háð neinum niður í miðbæ. Til dæmis framkvæmir teymið okkar framleiðsludreifingu á miðjum degi þegar fólk er að nota forritin sem mest, svo það er mikilvægt að forðast tafir á þessu ferli. Til að forðast niður í miðbæ eru 2 aðferðir notaðar: blá/græn uppsetning eða rúllandi uppfærsla. Í síðara tilvikinu, ef þú ert með 5 eftirlíkingar af forritinu í gangi, eru þær uppfærðar í röð hver á eftir annarri. Þessi aðferð virkar frábærlega, en hún hentar ekki ef þú ert með mismunandi útgáfur af forritinu í gangi samtímis meðan á dreifingarferlinu stendur. Í þessu tilviki geturðu uppfært notendaviðmótið á meðan bakendinn keyrir gömlu útgáfuna og þá hættir forritið að virka. Þess vegna, frá sjónarhóli forritunar, er það frekar erfitt að vinna við slíkar aðstæður.
Þetta er ein af ástæðunum fyrir því að við kjósum að nota bláa/græna dreifingu til að gera sjálfvirkan dreifingu forritanna okkar. Með þessari aðferð verður þú að tryggja að aðeins ein útgáfa af forritinu sé virk í einu.
Bláa/græna dreifingarkerfið lítur svona út. Við fáum umferð fyrir forritin okkar í gegnum ha-proxy, sem sendir það áfram til að keyra eftirlíkingar af forritinu af sömu útgáfu.
Þegar ný uppsetning er gerð notum við Deployer, sem fær nýju íhlutina og setur upp nýju útgáfuna. Að koma nýrri útgáfu af forriti í notkun þýðir að nýtt sett af eftirlíkingum er „hækkað“, eftir það eru þessar eftirlíkingar af nýju útgáfunni settar í sérstakan, nýjan hólf. Hins vegar veit ha-proxy ekkert um þá og beinir ekki neinu vinnuálagi til þeirra ennþá.
Þess vegna er fyrst og fremst nauðsynlegt að framkvæma frammistöðuathugun á nýjum útgáfum af heilsufarsskoðun til að tryggja að eftirlíkingarnar séu tilbúnar til að þjóna álaginu.
Allir dreifingaríhlutir verða að styðja einhvers konar heilsufarsskoðun. Þetta getur verið mjög einfalt HTTP-símtalathugun, þegar þú færð kóða með stöðu 200, eða ítarlegri athugun, þar sem þú athugar tengingu eftirmyndanna við gagnagrunninn og aðra þjónustu, stöðugleika kviku umhverfistenginganna , og hvort allt byrjar og virki rétt. Þetta ferli getur verið nokkuð flókið.
Eftir að kerfið hefur staðfest að allar uppfærðar eftirmyndir virki mun Deployer uppfæra stillingarnar og senda rétta confd, sem mun endurstilla ha-proxy.
Aðeins eftir þetta verður umferð beint að belgnum með eftirlíkingum af nýju útgáfunni og gamli belgurinn hverfur.
Þessi vélbúnaður er ekki eiginleiki Kubernetes. Hugmyndin um bláa/græna uppsetningu hefur verið til í nokkuð langan tíma og það hefur alltaf notað álagsjafnara. Í fyrsta lagi beinir þú allri umferð yfir í gömlu útgáfuna af forritinu og eftir uppfærsluna flyturðu hana algjörlega yfir í nýju útgáfuna. Þessi regla er ekki aðeins notuð í Kubernetes.
Nú mun ég kynna þér nýjan dreifingarþátt - Deployer, sem framkvæmir heilsufarsskoðun, endurstillir umboð og svo framvegis. Þetta er hugtak sem á ekki við umheiminn og er til inni í Kubernetes. Ég mun sýna þér hvernig þú getur búið til þitt eigið Deployer hugmynd með því að nota opinn hugbúnað.
Svo, það fyrsta sem Deployer gerir er að búa til RC afritunarstýringu með því að nota Kubernetes API. Þetta API býr til belg og þjónustu til frekari dreifingar, það er að segja, það býr til alveg nýjan þyrping fyrir forritin okkar. Um leið og RC er sannfærður um að eftirlíkingarnar séu byrjaðar mun það framkvæma heilsufarsskoðun á virkni þeirra. Til að gera þetta notar Deployer GET /heilsu skipunina. Það keyrir viðeigandi skannahluta og athugar alla þætti sem styðja rekstur klasans.
Eftir að allir fræbelgir hafa tilkynnt um heilsu sína, býr Deployer til nýjan stillingarþátt - etcd dreifða geymslu, sem er notuð innbyrðis af Kubernetes, þar á meðal að geyma uppsetningu álagsjafnaðar. Við skrifum gögn í etcd og lítið tól sem kallast confd fylgist með etcd fyrir ný gögn.
Ef það finnur einhverjar breytingar á upphaflegri stillingu, býr það til nýja stillingaskrá og flytur hana yfir á ha-proxy. Í þessu tilviki endurræsir ha-proxy án þess að tapa neinum tengingum og fjallar um álag á nýjar þjónustur sem gera nýju útgáfunni af forritunum okkar kleift að virka.
Eins og þú sérð, þrátt fyrir ofgnótt af íhlutum, er ekkert flókið hér. Þú þarft bara að borga meiri eftirtekt til API og etcd. Mig langar að segja þér frá opnum uppspretta dreifingaraðila sem við sjálf notum - Amdatu Kubernetes Deployer.
Það er tæki til að skipuleggja Kubernetes dreifingu og hefur eftirfarandi eiginleika:
- Blá/græn dreifing;
- setja upp ytri álagsjafnara;
- stjórnun dreifingarlýsingar;
- stjórna raunverulegri dreifingu;
- athuga virkni heilbrigðiseftirlits meðan á dreifingu stendur;
- innleiðing umhverfisbreyta í belg.
Þessi dreifingaraðili er byggður ofan á Kubernetes API og býður upp á REST API til að stjórna handföngum og dreifingum, sem og Websocket API fyrir streymiskrár meðan á dreifingarferlinu stendur.
Það setur uppsetningargögn álagsjafnvægis í etcd, þannig að þú þarft ekki að nota ha-proxy með út-af-the-box stuðning, en auðveldlega nota þína eigin álagsjafnvægi stillingarskrá. Amdatu Deployer er skrifað í Go, eins og Kubernetes sjálft, og er með leyfi frá Apache.
Áður en ég byrjaði að nota þessa útgáfu af dreifingarforritinu notaði ég eftirfarandi dreifingarlýsingu, sem tilgreinir færibreyturnar sem ég þarf.
Ein af mikilvægustu breytum þessa kóða er að virkja „useHealthCheck“ fánann. Við þurfum að tilgreina að geðheilsuskoðun verður að fara fram á meðan á dreifingarferlinu stendur. Hægt er að slökkva á þessari stillingu þegar uppsetningin notar ílát frá þriðja aðila sem ekki þarf að staðfesta. Þessi lýsing gefur einnig til kynna fjölda eftirmynda og framenda vefslóðarinnar sem ha-proxy þarf. Í lokin er pod forskrift fáninn "podspec", sem kallar Kubernetes til að fá upplýsingar um tengistillingar, mynd o.fl. Þetta er frekar einfalt JSON lýsing.
Annað tól sem er hluti af opnum Amdatu verkefninu er Deploymentctl. Það hefur notendaviðmót til að stilla uppsetningar, geymir dreifingarferil og inniheldur vefhóka fyrir endurhringingar frá þriðja aðila notendum og forriturum. Þú mátt ekki nota notendaviðmótið þar sem Amdatu Deployer sjálft er REST API, en þetta viðmót getur gert uppsetningu mun auðveldara fyrir þig án þess að taka þátt í API. Deploymentctl er skrifað í OSGi/Vertx með því að nota Angular 2.
Ég mun nú sýna ofangreint á skjánum með því að nota fyrirfram upptöku svo þú þurfir ekki að bíða. Við munum setja upp einfalt Go forrit. Ekki hafa áhyggjur ef þú hefur ekki prófað Go áður, þetta er mjög einfalt forrit svo þú ættir að geta fundið það út.
Hér erum við að búa til HTTP netþjón sem bregst aðeins við /heilsu, þannig að þetta forrit prófar aðeins heilsufarsskoðunina og ekkert annað. Ef athugunin stenst er JSON uppbyggingin sem sýnd er hér að neðan notuð. Það inniheldur útgáfuna af forritinu sem dreifingaraðilinn mun birta, skilaboðin sem þú sérð efst í skránni og boolean gagnagerð - hvort sem forritið okkar virkar eða ekki.
Ég svindlaði aðeins með síðustu línunni, vegna þess að ég setti fast boolean gildi efst í skránni, sem í framtíðinni mun hjálpa mér að dreifa jafnvel „óhollu“ forriti. Við munum takast á við þetta síðar.
Svo skulum við byrja. Í fyrsta lagi athugum við hvort einhver hlaupandi belg séu til staðar með því að nota skipunina ~ kubectl get belg og, byggt á því að ekki sé svar frá framenda slóðinni, tryggjum við að engar dreifingar séu gerðar eins og er.
Næst á skjánum sérðu Deploymentctl viðmótið sem ég nefndi, þar sem dreifingarfæribreytur eru stilltar: nafnrými, nafn forrits, dreifingarútgáfa, fjöldi eftirmynda, framenda vefslóð, heiti gáma, mynd, auðlindamörk, gáttarnúmer fyrir heilsuskoðun, o.s.frv. Auðlindamörk eru mjög mikilvæg, þar sem þau gera þér kleift að nota sem mest magn af vélbúnaði. Hér geturðu líka skoðað dreifingarskrána.
Ef þú endurtekur skipunina ~ kubectl get pods geturðu séð að kerfið „frýs“ í 20 sekúndur, þar sem ha-proxy er endurstillt. Eftir þetta byrjar belgurinn og eftirmynd okkar má sjá í dreifingarskránni.
Ég klippti út 20 sekúndna biðina úr myndbandinu og nú geturðu séð á skjánum að fyrsta útgáfan af forritinu hefur verið sett í notkun. Allt þetta var gert með því að nota aðeins HÍ.
Nú skulum við prófa seinni útgáfuna. Til að gera þetta breyti ég skilaboðum forritsins úr "Halló, Kubernetes!" á "Halló, Deployer!", býr kerfið til þessa mynd og setur hana í Docker registry, eftir það smellum við einfaldlega aftur á "Deploy" hnappinn í Deploymentctl glugganum. Í þessu tilviki er dreifingarskráin sjálfkrafa ræst á sama hátt og það gerðist þegar fyrstu útgáfu forritsins var dreifð.
Skipunin ~ kubectl get pods sýnir að það eru 2 útgáfur af forritinu í gangi eins og er, en framhliðin sýnir að við erum enn að keyra útgáfu 1.
Hleðslujafnari bíður eftir að heilsuathuguninni ljúki áður en umferð er beint yfir í nýju útgáfuna. Eftir 20 sekúndur skiptum við yfir í krulla og sjáum að við höfum nú útgáfu 2 af forritinu og þeirri fyrstu hefur verið eytt.
Þetta var dreifing á „heilbrigðu“ forriti. Við skulum sjá hvað gerist ef ég breyti færibreytunni Healthy úr satt í ósatt fyrir nýja útgáfu af forritinu, það er að segja ég reyni að senda inn óhollt forrit sem hefur ekki staðist heilsufarsskoðun. Þetta getur gerst ef einhverjar stillingarvillur voru gerðar í forritinu á þróunarstigi og það var sent í framleiðslu á þessu formi.
Eins og þú sérð fer dreifingin í gegnum öll skrefin hér að ofan og ~kubectl get belg sýnir að báðir belgirnir eru í gangi. En ólíkt fyrri dreifingunni sýnir annálinn stöðuna á tímamörkum. Það er að segja, vegna þess að heilsufarsskoðun mistókst, er ekki hægt að nota nýju útgáfuna af forritinu. Fyrir vikið sérðu að kerfið hefur farið aftur í að nota gömlu útgáfuna af forritinu og nýja útgáfan hefur einfaldlega verið fjarlægð.
Það góða við þetta er að jafnvel þótt þú sért með gríðarlegan fjölda beiðna samtímis inn í forritið, munu þeir ekki einu sinni taka eftir stöðvunartímanum meðan þú innleiðir dreifingarferlið. Ef þú prófar þetta forrit með Gatling ramma, sem sendir því eins margar beiðnir og mögulegt er, þá verður engum af þessum beiðnum sleppt. Þetta þýðir að notendur okkar munu ekki einu sinni taka eftir útgáfuuppfærslum í rauntíma. Ef það mistekst verður unnið áfram með gömlu útgáfuna; ef það tekst munu notendur skipta yfir í nýju útgáfuna.
Það er aðeins eitt sem getur mistekist - ef heilsuathugunin heppnast, en umsóknin mistekst um leið og vinnuálaginu er beitt á það, það er að hrunið verður ekki fyrr en eftir að uppsetningunni er lokið. Í þessu tilviki verður þú að snúa aftur í gömlu útgáfuna handvirkt. Svo skoðuðum við hvernig á að nota Kubernetes með opnum hugbúnaði sem hannað er fyrir það. Dreifingarferlið verður miklu auðveldara ef þú byggir þessi verkfæri inn í Build/Deploy leiðslur þínar. Á sama tíma, til að hefja dreifingu, geturðu notað annað hvort notendaviðmótið eða fullkomlega sjálfvirkt þetta ferli með því að nota, til dæmis, skuldbinda sig til að skipuleggja.
Byggingaþjónninn okkar mun búa til Docker mynd, ýta henni inn í Docker Hub eða hvaða skrá sem þú notar. Docker Hub styður webhook, svo við getum kveikt á fjardreifingu í gegnum Deployer á þann hátt sem sýnt er hér að ofan. Þannig geturðu fullkomlega sjálfvirkt dreifingu forritsins þíns í hugsanlega framleiðslu.
Við skulum halda áfram að næsta efni - stækka Kubernetes þyrpinguna. Athugaðu að kubectl skipunin er stærðarskipun. Með meiri hjálp getum við auðveldlega aukið fjölda eftirmynda í núverandi klasa okkar. Hins vegar, í reynd, viljum við venjulega fjölga hnútum frekar en belgjum.
Á sama tíma gætir þú þurft að auka á vinnutíma og á nóttunni, til að draga úr kostnaði við Amazon þjónustu, gætirðu þurft að fækka forritatilvikum í gangi. Þetta þýðir ekki að það sé nóg að stækka aðeins fjölda fræbelgja, því jafnvel þó að einn af hnútunum sé aðgerðalaus þarftu samt að borga Amazon fyrir það. Það er, ásamt því að stækka belgina þarftu að skala fjölda véla sem notaðar eru.
Þetta getur verið krefjandi vegna þess að hvort sem við notum Amazon eða aðra skýjaþjónustu veit Kubernetes ekkert um fjölda véla sem eru notaðar. Það vantar tól sem gerir þér kleift að skala kerfið á hnútastigi.
Þannig að við verðum að sjá um bæði hnúta og fræbelg. Við getum auðveldlega skalað kynningu á nýjum hnútum með því að nota AWS API og Scaling hópvélar til að stilla fjölda Kubernetes starfsmannahnúta. Þú getur líka notað cloud-init eða svipað handrit til að skrá hnúta í Kubernetes klasanum.
Nýja vélin byrjar í Scaling hópnum, byrjar sjálfan sig sem hnút, skráir sig í master's registry og byrjar að vinna. Eftir þetta geturðu aukið fjölda eftirmynda til notkunar á hnútunum sem myndast. Að minnka við sig krefst meiri fyrirhafnar, þar sem þú þarft að ganga úr skugga um að slíkt skref leiði ekki til eyðileggingar á forritum sem þegar eru í gangi eftir að slökkt er á „óþarfa“ vélum. Til að koma í veg fyrir slíka atburðarás þarftu að stilla hnútana á „ótímaáætlun“ stöðuna. Þetta þýðir að sjálfgefinn tímaáætlun mun hunsa þessa hnúta þegar DaemonSet belg eru tímasett. Tímaáætlunin mun ekki eyða neinu af þessum netþjónum en mun heldur enga nýja gáma ræsa þar. Næsta skref er að koma frárennslishnútnum frá, það er að flytja hlaupandi belg úr honum yfir í aðra vél eða aðra hnúta sem hafa nægilega afkastagetu til þess. Þegar þú hefur tryggt að það séu ekki lengur neinir ílát á þessum hnútum geturðu fjarlægt þá úr Kubernetes. Eftir þetta munu þeir einfaldlega hætta að vera til fyrir Kubernetes. Næst þarftu að nota AWS API til að slökkva á óþarfa hnútum eða vélum.
Þú getur notað Amdatu Scalerd, annað opinn uppspretta mælikvarða tól svipað AWS API. Það veitir CLI til að bæta við eða fjarlægja hnúta í klasa. Áhugaverður eiginleiki þess er hæfileikinn til að stilla tímaáætlunina með því að nota eftirfarandi json skrá.
Kóðinn sem sýndur er dregur úr afkastagetu klasans um helming yfir nóttina. Það stillir bæði fjölda eftirlíkinga sem eru tiltækar og æskilega getu Amazon þyrpingarinnar. Notkun þessa tímaáætlunar mun sjálfkrafa fækka hnútum á kvöldin og fjölga þeim á morgnana, sem sparar kostnað við að nota hnúta frá skýjaþjónustu eins og Amazon. Þessi eiginleiki er ekki innbyggður í Kubernetes, en með því að nota Scalerd geturðu stækkað þennan vettvang eins og þú vilt.
Ég vil taka það fram að margir segja við mig: „Þetta er allt í góðu, en hvað með gagnagrunninn minn, sem er venjulega kyrrstæður? Hvernig geturðu keyrt eitthvað svona í kraftmiklu umhverfi eins og Kubernetes? Að mínu mati ættirðu ekki að gera þetta, þú ættir ekki að reyna að reka gagnavöruhús í Kubernetes. Þetta er tæknilega mögulegt og það eru til kennsluefni á netinu um þetta efni, en það mun flækja líf þitt verulega.
Já, það er hugmynd um þrálátar verslanir í Kubernetes og þú getur prófað að keyra gagnaverslanir eins og Mongo eða MySQL, en þetta er töluvert vinnufrekt verkefni. Þetta er vegna þess að gagnageymslur styðja ekki að fullu samskipti við kraftmikið umhverfi. Flestir gagnagrunnar krefjast umtalsverðrar stillingar, þar á meðal handvirkrar stillingar á klasanum, líkar ekki við sjálfstýringu og annað svipað.
Þess vegna ættir þú ekki að flækja líf þitt með því að reyna að reka gagnavöruhús í Kubernetes. Skipuleggja vinnu sína á hefðbundinn hátt með því að nota kunnuglega þjónustu og einfaldlega veita Kubernetes möguleika á að nota þær.
Til að ljúka viðfangsefnið langar mig að kynna þér Cloud RTI vettvang byggt á Kubernetes, sem teymið mitt er að vinna að. Það býður upp á miðlæga skráningu, eftirlit með forritum og klasa, og marga aðra gagnlega eiginleika sem munu koma sér vel. Það notar ýmis opinn hugbúnað eins og Grafana til að sýna vöktun.
Það var spurning um hvers vegna þú notar ha-proxy load balancer með Kubernetes. Góð spurning vegna þess að það eru 2 stig af álagsjafnvægi eins og er. Kubernetes þjónusta býr enn á sýndar IP tölum. Þú getur ekki notað þau fyrir höfn á ytri hýsingarvélum vegna þess að ef Amazon ofhleður skýhýsingaraðila sinn, mun heimilisfangið breytast. Þetta er ástæðan fyrir því að við setjum ha-proxy fyrir framan þjónustuna - til að búa til kyrrstæðari uppbyggingu fyrir umferð til að eiga óaðfinnanleg samskipti við Kubernetes.
Önnur góð spurning er hvernig geturðu séð um breytingar á kerfiskerfi gagnagrunns þegar þú gerir bláa/græna uppsetningu? Staðreyndin er sú að óháð notkun Kubernetes er erfitt verkefni að breyta gagnagrunnsskema. Þú þarft að tryggja að gamla og nýja skemað sé samhæft, eftir það geturðu uppfært gagnagrunninn og síðan uppfært forritin sjálf. Þú getur heitt skipt um gagnagrunninn og síðan uppfært forritin. Ég veit um fólk sem hefur ræst upp alveg nýjan gagnagrunnsklasa með nýju skema, þetta er möguleiki ef þú ert með kerfislausan gagnagrunn eins og Mongo, en það er samt ekki auðvelt verkefni. Ef þú hefur engar frekari spurningar, þakka þér fyrir athyglina!
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com