Kumbuka. tafsiri.: Kupitishwa kwa Kubernetes katika GitLab kunachukuliwa kuwa mojawapo ya sababu kuu mbili zinazochangia ukuaji wa kampuni. Hata hivyo, hadi hivi majuzi, miundombinu ya huduma ya mtandaoni ya GitLab.com ilijengwa kwenye mashine pepe, na takriban mwaka mmoja uliopita uhamiaji wake hadi K8 ulianza, ambao bado haujakamilika. Tunayo furaha kuwasilisha tafsiri ya nakala ya hivi majuzi ya mhandisi wa GitLab SRE kuhusu jinsi hii inafanyika na ni hitimisho gani wahandisi wanaoshiriki katika mradi hufanya.
Kwa takriban mwaka mmoja sasa, kitengo chetu cha miundombinu kimekuwa kikihamisha huduma zote zinazoendeshwa kwenye GitLab.com hadi Kubernetes. Wakati huu, tulikumbana na changamoto zinazohusiana sio tu na kuhamisha huduma hadi Kubernetes, lakini pia kudhibiti uwekaji mseto wakati wa mpito. Mambo muhimu tuliyojifunza yatazungumziwa katika makala hii.
Kuanzia mwanzoni mwa GitLab.com, seva zake zilikimbia kwenye wingu kwenye mashine za kawaida. Mashine hizi za kawaida zinasimamiwa na Chef na kusakinishwa kwa kutumia yetu . ikiwa programu itahitajika kusasishwa, inajumuisha tu kusasisha meli za seva kwa njia iliyoratibiwa, iliyofuatana kwa kutumia bomba la CI. Njia hii - angalau polepole na kidogo - inahakikisha kwamba GitLab.com inatumia mbinu sawa za usakinishaji na usanidi kama watumiaji wa nje ya mtandao (kujisimamia) Usanikishaji wa GitLab kwa kutumia vifurushi vyetu vya Linux kwa hili.
Tunatumia njia hii kwa sababu ni muhimu sana kupata huzuni na furaha zote ambazo wanajumuiya wanapata wakati wa kusakinisha na kusanidi nakala zao za GitLab. Mbinu hii ilifanya kazi vizuri kwa muda, lakini idadi ya miradi kwenye GitLab ilipozidi milioni 10, tuligundua kuwa haikukidhi mahitaji yetu ya kuongeza na kupeleka.
Hatua za kwanza za Kubernetes na GitLab ya asili ya wingu
Mradi huo uliundwa mnamo 2017 kutayarisha GitLab kwa matumizi ya wingu, na kuwezesha watumiaji kusakinisha GitLab kwenye makundi ya Kubernetes. Tulijua basi kwamba kuhamisha GitLab hadi Kubernetes kungeongeza kasi ya jukwaa la SaaS, kurahisisha utumaji, na kuboresha ufanisi wa rasilimali za kompyuta. Wakati huo huo, kazi nyingi za programu yetu zilitegemea sehemu za NFS zilizowekwa, ambazo zilipunguza kasi ya mpito kutoka kwa mashine za kawaida.
Msukumo kuelekea cloud native na Kubernetes uliwaruhusu wahandisi wetu kupanga mabadiliko ya taratibu, ambapo tuliachana na baadhi ya utegemezi wa programu kwenye hifadhi ya mtandao huku tukiendelea kutengeneza vipengele vipya. Tangu tulipoanza kupanga uhamaji katika msimu wa joto wa 2019, mengi ya mapungufu haya yametatuliwa, na mchakato wa kuhamia GitLab.com hadi Kubernetes sasa unaendelea!
Vipengele vya GitLab.com katika Kubernetes
Kwa GitLab.com, tunatumia nguzo moja ya eneo la GKE ambayo inashughulikia trafiki yote ya programu. Ili kupunguza uchangamano wa uhamiaji (tayari ni gumu), tunaangazia huduma ambazo hazitegemei hifadhi ya ndani au NFS. GitLab.com hutumia msingi wa kanuni za Reli za monolithic, na tunaelekeza trafiki kulingana na sifa za mzigo wa kazi hadi ncha tofauti ambazo zimetengwa kwenye vidimbwi vyao vya nodi.
Kwa upande wa mandhari ya mbele, aina hizi zimegawanywa katika maombi ya wavuti, API, Git SSH/HTTPS na Usajili. Kwa upande wa nyuma, tunagawanya kazi kwenye foleni kulingana na sifa tofauti kulingana na , ambayo huturuhusu kuweka Malengo ya Kiwango cha Huduma (SLO) kwa mizigo mbalimbali ya kazi.
Huduma hizi zote za GitLab.com zimesanidiwa kwa kutumia chati ya Helm ya GitLab ambayo haijabadilishwa. Usanidi unafanywa katika chati ndogo, ambazo zinaweza kuwashwa kwa kuchagua tunapohamisha huduma kwenye kundi. Ingawa tuliamua kutojumuisha baadhi ya huduma zetu kuu katika uhamiaji, kama vile Redis, Postgres, GitLab Pages na Gitaly, kutumia Kubernetes huturuhusu kupunguza kwa kiasi kikubwa idadi ya VM ambazo Chef anasimamia kwa sasa.
Mwonekano na Usimamizi wa Usanidi wa Kubernetes
Mipangilio yote inasimamiwa na GitLab yenyewe. Kwa hili, miradi mitatu ya usanidi kulingana na Terraform na Helm hutumiwa. Tunajaribu kutumia GitLab yenyewe wakati wowote inapowezekana ili kuendesha GitLab, lakini kwa kazi za uendeshaji tuna usakinishaji tofauti wa GitLab. Hii inahitajika ili kuhakikisha kuwa hautegemei upatikanaji wa GitLab.com wakati wa kutekeleza uwekaji na masasisho ya GitLab.com.
Ingawa mabomba yetu ya nguzo ya Kubernetes yanaendeshwa kwa usakinishaji tofauti wa GitLab, kuna vioo vya hazina za msimbo ambazo zinapatikana kwa umma katika anwani zifuatazo:
- - Mfumo wa usanidi wa GitLab.com kwa chati ya GitLab Helm;
- - Ina usanidi wa huduma ambazo hazihusiani moja kwa moja na programu ya GitLab. Hizi ni pamoja na usanidi wa ukataji miti na ufuatiliaji wa nguzo, pamoja na zana zilizojumuishwa kama vile PlantUML;
- - Usanidi wa Terraform kwa Kubernetes na miundombinu ya VM ya urithi. Hapa unasanidi rasilimali zote zinazohitajika ili kuendesha kikundi, ikijumuisha nguzo yenyewe, mabwawa ya nodi, akaunti za huduma, na uwekaji nafasi wa anwani ya IP.
Mwonekano wa umma unaonyeshwa mabadiliko yanapofanywa. iliyo na kiunga cha tofauti ya kina ambayo SRE huchanganua kabla ya kufanya mabadiliko kwenye nguzo.
Kwa SRE, kiungo husababisha tofauti ya kina katika usakinishaji wa GitLab, ambao hutumika kwa uzalishaji na ufikiaji ambao umezuiwa. Hii inaruhusu wafanyakazi na jumuiya, bila kufikia mradi wa uendeshaji (ambao uko wazi kwa SRE pekee), kutazama mabadiliko yaliyopendekezwa ya usanidi. Kwa kuchanganya mfano wa umma wa GitLab kwa msimbo na mfano wa faragha wa mabomba ya CI, tunadumisha mtiririko mmoja wa kazi huku tukihakikisha uhuru kutoka kwa GitLab.com kwa masasisho ya usanidi.
Tulichogundua wakati wa uhamiaji
Wakati wa kuhama, uzoefu ulipatikana ambao tunatumika kwa uhamiaji mpya na usambazaji huko Kubernetes.
1. Kuongezeka kwa gharama kutokana na trafiki kati ya maeneo ya upatikanaji
Takwimu za kila siku za egress (baiti kwa siku) za meli za hazina za Git kwenye GitLab.com
Google inagawanya mtandao wake katika maeneo. Wale, kwa upande wake, wamegawanywa katika kanda za ufikiaji (AZ). Upangishaji wa Git unahusishwa na idadi kubwa ya data, kwa hivyo ni muhimu kwetu kudhibiti utokaji wa mtandao. Kwa trafiki ya ndani, egress ni bure tu ikiwa inakaa ndani ya eneo sawa la upatikanaji. Kufikia uandishi huu, tunatoa takriban TB 100 ya data katika siku ya kawaida ya kazi (na hiyo ni kwa hazina za Git). Huduma ambazo ziliishi katika mashine zilezile za mtandaoni katika topolojia yetu ya zamani ya VM sasa zinaendeshwa katika maganda tofauti ya Kubernetes. Hii ina maana kwamba baadhi ya trafiki ambayo hapo awali ilikuwa karibu na VM inaweza kusafiri nje ya maeneo yanayopatikana.
Makundi ya GKE ya Kikanda hukuruhusu kutumia Maeneo mengi ya Upatikanaji kwa ajili ya kupunguzwa kazi. Tunazingatia uwezekano kwa huduma zinazozalisha idadi kubwa ya trafiki. Hii itapunguza gharama za kutoka wakati wa kudumisha upunguzaji wa viwango vya nguzo.
2. Mipaka, maombi ya rasilimali na kuongeza
Idadi ya trafiki ya utayarishaji wa nakala kwenye registry.gitlab.com. Trafiki kilele saa ~ 15:00 UTC.
Hadithi yetu ya uhamiaji ilianza Agosti 2019, tulipohamisha huduma yetu ya kwanza, Usajili wa Vyombo vya GitLab, hadi Kubernetes. Huduma hii muhimu ya dhamira, na ya trafiki ya juu ilikuwa chaguo nzuri kwa uhamiaji wa kwanza kwa sababu ni programu isiyo na uraia na tegemezi chache za nje. Tatizo la kwanza tulilokumbana nalo lilikuwa idadi kubwa ya maganda yaliyofukuzwa kutokana na ukosefu wa kumbukumbu kwenye nodi. Kwa sababu hii, tulilazimika kubadili maombi na mipaka.
Iligunduliwa kuwa katika kesi ya maombi ambapo utumiaji wa kumbukumbu huongezeka kwa wakati, maadili ya chini ya maombi (kuhifadhi kumbukumbu kwa kila ganda) pamoja na kikomo "kigumu" cha utumiaji kilisababisha kueneza. (kueneza) nodi na kiwango cha juu cha kufukuzwa. Ili kukabiliana na tatizo hili, ilikuwa . Hii iliondoa shinikizo kwenye nodi na kuhakikisha kuwa maganda yana mzunguko wa maisha ambao haukuweka shinikizo nyingi kwenye nodi. Sasa tunaanza uhamiaji kwa ombi la ukarimu (na karibu sawa) na kupunguza maadili, tukiyarekebisha inapohitajika.
3. Vipimo na kumbukumbu
Mgawanyiko wa miundombinu unazingatia muda wa kusubiri, viwango vya makosa na kueneza kwa kusakinishwa (SLO) iliyounganishwa na .
Katika mwaka uliopita, moja ya matukio muhimu katika kitengo cha miundombinu yamekuwa maboresho katika ufuatiliaji na kufanya kazi na SLOs. SLO zilituruhusu kuweka malengo ya huduma za kibinafsi ambazo tulifuatilia kwa karibu wakati wa uhamiaji. Lakini hata kwa uangalizi huu ulioboreshwa, si mara zote inawezekana kuona matatizo mara moja kwa kutumia vipimo na arifa. Kwa mfano, kwa kuzingatia viwango vya kusubiri na hitilafu, hatutoi kikamilifu matukio yote ya utumiaji wa huduma inayopitia uhamiaji.
Suala hili liligunduliwa mara tu baada ya kuhamisha baadhi ya mizigo ya kazi kwenye nguzo. Ilikua kali sana tulipolazimika kuangalia vitendaji ambavyo idadi ya maombi ilikuwa ndogo, lakini ambayo ilikuwa na utegemezi maalum wa usanidi. Moja ya masomo muhimu kutoka kwa uhamiaji ilikuwa haja ya kuzingatia sio tu metrics wakati wa ufuatiliaji, lakini pia magogo na "mkia mrefu" (hii ni kuhusu kwenye chati - takriban. tafsiri.) makosa. Sasa kwa kila uhamiaji tunajumuisha orodha ya kina ya hoja za kumbukumbu (maswali ya kumbukumbu) na kupanga taratibu za urejeshaji zilizo wazi ambazo zinaweza kuhamishwa kutoka zamu moja hadi nyingine iwapo matatizo yatatokea.
Kutoa maombi yale yale sambamba na miundombinu ya zamani ya VM na miundombinu mipya ya Kubernetes kulileta changamoto ya kipekee. Tofauti na uhamiaji wa kuinua-na-kuhama (uhamisho wa haraka wa maombi "kama ilivyo" kwa miundombinu mpya; maelezo zaidi yanaweza kusomwa, kwa mfano, - takriban. tafsiri.), kazi sambamba kwenye VM "zamani" na Kubernetes inahitaji zana za ufuatiliaji zilingane na mazingira yote mawili na kuweza kuchanganya vipimo katika mwonekano mmoja. Ni muhimu kwamba tutumie dashibodi sawa na hoja za kumbukumbu ili kufikia uangalizi thabiti katika kipindi cha mpito.
4. Kubadilisha trafiki hadi kikundi kipya
Kwa GitLab.com, sehemu ya seva imejitolea . Canary Park hutumikia miradi yetu ya ndani na pia inaweza . Lakini kimsingi imeundwa kujaribu mabadiliko yaliyofanywa kwa miundombinu na matumizi. Huduma ya kwanza iliyohamishwa ilianza kwa kukubali idadi ndogo ya trafiki ya ndani, na tunaendelea kutumia njia hii ili kuhakikisha kuwa SLO zinatimizwa kabla ya kutuma trafiki yote kwenye kundi.
Katika kesi ya uhamiaji, hii inamaanisha kuwa maombi ya miradi ya ndani hutumwa kwa Kubernetes kwanza, na kisha hatua kwa hatua tunabadilisha trafiki iliyosalia hadi kwenye kundi kwa kubadilisha uzito wa mazingira ya nyuma kupitia HAProxy. Wakati wa uhamiaji kutoka VM hadi Kubernetes, ilionekana wazi kuwa ilikuwa na manufaa sana kuwa na njia rahisi ya kuelekeza trafiki kati ya miundombinu ya zamani na mpya na, ipasavyo, kuweka miundombinu ya zamani tayari kwa urejeshaji katika siku chache za kwanza baada ya uhamiaji.
5. Hifadhi uwezo wa maganda na matumizi yao
Karibu mara moja tatizo lifuatalo liligunduliwa: maganda ya huduma ya Usajili yalianza haraka, lakini uzinduzi wa maganda ya Sidekiq ulichukua hatua. . Muda mrefu wa kuanza kwa maganda ya Sidekiq ukawa suala tulipoanza kuhamisha mzigo wa kazi hadi Kubernetes kwa wafanyikazi ambao walihitaji kushughulikia kazi haraka na kuongeza haraka.
Katika kesi hii, somo lilikuwa kwamba wakati Kubernetes' Horizontal Pod Autoscaler (HPA) inashughulikia ukuaji wa trafiki vizuri, ni muhimu kuzingatia sifa za mzigo wa kazi na kutenga uwezo wa vipuri kwa maganda (hasa wakati mahitaji yanasambazwa kwa usawa). Kwa upande wetu, kulikuwa na kuongezeka kwa ghafla kwa kazi, na kusababisha kuongezeka kwa haraka, ambayo ilisababisha kueneza kwa rasilimali za CPU kabla ya kuwa na wakati wa kuongeza dimbwi la nodi.
Kila mara kuna kishawishi cha kubana kadri tuwezavyo kutoka kwa kundi, hata hivyo, kwa kuwa tumekumbana na matatizo ya utendakazi hapo awali, sasa tunaanza na bajeti ya ukarimu ya ganda na kuipunguza baadaye, tukizingatia kwa karibu SLOs. Uzinduzi wa maganda ya huduma ya Sidekiq umeongezeka sana na sasa unachukua takriban sekunde 40 kwa wastani. ilishinda GitLab.com na watumiaji wetu wa usakinishaji unaojidhibiti wenyewe wanaofanya kazi na chati rasmi ya Helm ya GitLab.
Hitimisho
Baada ya kuhama kila huduma, tulifurahia manufaa ya kutumia Kubernetes katika uzalishaji: utumaji programu kwa haraka na salama, kuongeza ukubwa na ugawaji rasilimali kwa ufanisi zaidi. Zaidi ya hayo, faida za uhamiaji huenda zaidi ya huduma ya GitLab.com. Kila uboreshaji wa chati rasmi ya Helm hunufaisha watumiaji wake.
Natumai ulifurahia hadithi ya matukio yetu ya uhamiaji ya Kubernetes. Tunaendelea kuhamishia huduma zote mpya kwenye kikundi. Maelezo ya ziada yanaweza kupatikana katika machapisho yafuatayo:
- Β«";
- Β«";
- .
PS kutoka kwa mtafsiri
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com