Safari ya K8S Multicluster

Habari Habr!

Tunawakilisha timu ya jukwaa la Exness. Hapo awali, wenzetu tayari waliandika makala kuhusu Picha zilizo tayari kwa utengenezaji wa k8s. Leo tunataka kushiriki uzoefu wetu wa kuhamia huduma za Kubernetes.

Kuanza, tunakupa nambari kadhaa kwa ufahamu bora wa kile kitakachojadiliwa:

• Idara yetu ya maendeleo ina watu zaidi ya 100, ikijumuisha zaidi ya timu 10 tofauti zilizo na michakato ya kujitosheleza ya QA, DevOps na Scrum. Rafu ya maendeleo - Python, PHP, C++, Java na Golang. 
• Ukubwa wa mazingira ya majaribio na uzalishaji ni takriban kontena 2000 kila moja. Wanaendesha Rancher v1.6 kwa uvumbuzi wao wenyewe na chini ya VMware. 

Motisha

Kama wanasema, hakuna kitu hudumu milele, na Rancher alitangaza mwisho wa usaidizi wa toleo la 1.6 muda mrefu uliopita. Ndiyo, katika zaidi ya miaka mitatu tumejifunza jinsi ya kuitayarisha na kutatua matatizo yanayotokea, lakini mara nyingi zaidi na zaidi tunakabiliwa na matatizo ambayo hayatawahi kusahihishwa. Rancher 1.6 pia ina mfumo wa ossified wa kutoa haki, ambapo unaweza kufanya karibu kila kitu au bila chochote.

Ingawa uvumbuzi wa umiliki ulitoa udhibiti mkubwa zaidi wa uhifadhi wa data na usalama wake, uliweka gharama za uendeshaji ambazo zilikuwa ngumu kukubalika kutokana na ukuaji wa mara kwa mara wa kampuni, idadi ya miradi na mahitaji yake.

Tulitaka kufuata viwango vya IaC na, ikihitajika, kupata uwezo haraka, katika eneo lolote la kijiografia na bila kufuli ya muuzaji, na pia tuweze kuiacha haraka.

Hatua ya kwanza

Kwanza kabisa, tulitaka kutegemea teknolojia na suluhu za kisasa ambazo zingeruhusu timu kuwa na mzunguko wa maendeleo wa haraka na kupunguza gharama za uendeshaji kwa kuingiliana na mfumo unaotoa nguvu. 
 
Bila shaka, jambo la kwanza lililokuja akilini mwetu lilikuwa Kubernetes, lakini hatukusisimka na tulifanya utafiti mdogo ili kuona ikiwa ni chaguo sahihi. Tulitathmini masuluhisho ya rasilimali huria pekee, na katika vita visivyo vya haki, Kubernetes alishinda bila masharti.  

Ifuatayo ilikuja swali la kuchagua zana ya kuunda vikundi. Tulilinganisha suluhisho maarufu zaidi: kops, kubespray, kubeadm.

Kuanza, kubeadm ilionekana kwetu kuwa njia ngumu sana, badala yake kama aina ya mvumbuzi wa "baiskeli," na kops hakuwa na kubadilika kwa kutosha.

Na mshindi alikuwa:

Tulianza kufanya majaribio ya uboreshaji wetu wenyewe na AWS, tukijaribu kuunda upya kitu kinachofanana na muundo wetu wa awali wa usimamizi wa rasilimali, ambapo kila mtu alishiriki "nguzo" sawa. Na sasa tuna kundi letu la kwanza la mashine 10 ndogo za mtandaoni, ambazo kadhaa ziko katika AWS. Tulianza kujaribu kuhamia timu huko, kila kitu kilionekana kuwa "nzuri", na hadithi inaweza kumalizika, lakini ...

Matatizo ya Kwanza

Ansible ni nini kubespray imejengwa juu yake, sio zana ambayo hukuruhusu kufuata IaC: wakati wa kuagiza/kuondoa nodi, kitu kilienda vibaya kila wakati na aina fulani ya uingiliaji inahitajika, na wakati wa kutumia OS tofauti, kitabu cha kucheza kilikuwa na tabia tofauti. . Kadiri idadi ya timu na nodi kwenye nguzo ilivyoongezeka, tulianza kugundua kuwa kitabu cha kucheza kilikuwa kinachukua muda mrefu na zaidi kukamilika, na kwa sababu hiyo, rekodi yetu ilikuwa saa 3,5, vipi kuhusu yako? 🙂

Na inaonekana kama kubespray ni Ansible tu, na kila kitu ni wazi kwa mtazamo wa kwanza, lakini:

Mwanzoni mwa safari, kazi ilikuwa kuzindua uwezo tu katika AWS na juu ya virtualization, lakini basi, kama mara nyingi hutokea, mahitaji iliyopita.
 


Kwa kuzingatia hili, ikawa wazi kwamba muundo wetu wa zamani wa kuchanganya rasilimali katika mfumo mmoja wa ochestration haukufaa - katika kesi ambapo makundi ni mbali sana na yanasimamiwa na watoa huduma tofauti. 

Zaidi zaidi. Wakati timu zote zinafanya kazi ndani ya nguzo moja, huduma mbalimbali zilizo na NodeSelectors zilizowekwa vibaya zinaweza kuruka kwa mwenyeji wa "kigeni" wa timu nyingine na kutumia rasilimali huko, na ikiwa taint imewekwa, kulikuwa na maombi ya mara kwa mara kwamba huduma moja au nyingine haifanyi kazi, haijasambazwa kwa usahihi kutokana na sababu za kibinadamu. Tatizo jingine lilikuwa ni kukokotoa gharama, hasa kwa kuzingatia matatizo ya kusambaza huduma katika maeneo yote.

Hadithi tofauti ilikuwa utoaji wa haki kwa wafanyikazi: kila timu ilitaka kuwa "kichwa" cha nguzo na kuisimamia kabisa, ambayo inaweza kusababisha kuanguka kabisa, kwani timu kimsingi hazitegemei kila mmoja.

Nini cha kufanya?

Kwa kuzingatia yaliyo hapo juu na matakwa ya timu kuwa huru zaidi, tulifanya hitimisho rahisi: timu moja - nguzo moja. 

Kwa hivyo tulipata ya pili:

Na kisha nguzo ya tatu: 

Kisha tukaanza kufikiria: hebu sema kwamba katika mwaka timu zetu zitakuwa na nguzo zaidi ya moja? Katika maeneo tofauti ya kijiografia, kwa mfano, au chini ya udhibiti wa watoa huduma tofauti? Na baadhi yao watataka kuweza kupeleka haraka nguzo ya muda kwa majaribio kadhaa. 

Kubernetes kamili atakuja! Hii ni aina fulani ya MultiKubernetes, inageuka. 

Wakati huo huo, sote tutahitaji kwa namna fulani kudumisha makundi haya yote, kuwa na uwezo wa kusimamia upatikanaji wao kwa urahisi, na pia kuunda mpya na kufuta zamani bila kuingilia kati kwa mikono.

Muda umepita tangu mwanzo wa safari yetu katika ulimwengu wa Kubernetes, na tuliamua kuchunguza tena masuluhisho yanayopatikana. Ilibadilika kuwa tayari iko kwenye soko - Rancher 2.2.

Katika hatua ya kwanza ya utafiti wetu, Rancher Labs tayari walikuwa wametoa toleo la kwanza la toleo la 2, lakini ingawa inaweza kukuzwa haraka sana kwa kuzindua chombo kisicho na utegemezi wa nje na vigezo kadhaa au kutumia Chati rasmi ya HELM, ilionekana kuwa mbaya. kwetu, na hatukujua ikiwa tunaweza kutegemea uamuzi huu ikiwa utaendelezwa au kuachwa haraka. Mtazamo wa nguzo = mibofyo katika kiolesura chenyewe pia haukufaa, na hatukutaka kushikamana na RKE, kwa kuwa ni zana inayolenga kwa ufinyu. 

Toleo la Rancher 2.2 tayari lilikuwa na mwonekano unaoweza kufanya kazi zaidi na, pamoja na zile za awali, zilikuwa na rundo la vipengele vya kuvutia nje ya boksi, kama vile ushirikiano na watoa huduma wengi wa nje, sehemu moja ya usambazaji wa haki na faili za kubeconfig, kuzindua kubectl. picha na haki zako katika UI, nafasi za majina zilizowekwa kwenye miradi. 

Pia kulikuwa na jumuiya ambayo tayari imeundwa karibu na Rancher 2, na mtoa huduma anayeitwa HashiCorp Terraform aliundwa ili kuisimamia, ambayo ilitusaidia kuweka kila kitu pamoja.

Nini kimetokea

Kama matokeo, tuliishia na nguzo moja ndogo inayoendesha Rancher, inayofikiwa na vikundi vingine vyote, na vile vile vikundi vingi vilivyounganishwa nayo, ufikiaji wa yoyote ambayo inaweza kutolewa kwa urahisi kama kuongeza mtumiaji kwenye saraka ya ldap, bila kujali ilipo na rasilimali za mtoa huduma inazotumia.

Kwa kutumia gitlab-ci na Terraform, mfumo uliundwa unaokuwezesha kuunda kundi la usanidi wowote katika watoa huduma za wingu au miundombinu yetu wenyewe na kuwaunganisha kwa Rancher. Yote hii inafanywa kwa mtindo wa IaC, ambapo kila nguzo inaelezewa na hazina, na hali yake imetolewa. Wakati huo huo, moduli nyingi zimeunganishwa kutoka kwa hazina za nje ili kilichobaki ni kupitisha vigeu au kuelezea usanidi wako maalum kwa matukio, ambayo husaidia kupunguza asilimia ya marudio ya msimbo.

Kwa kweli, safari yetu iko mbali na bado kuna kazi nyingi za kupendeza mbele, kama vile sehemu moja ya kazi iliyo na kumbukumbu na vipimo vya vikundi vyovyote, matundu ya huduma, gitops za kudhibiti mizigo katika nguzo nyingi na mengi zaidi. Tunatarajia kupata uzoefu wetu kuvutia! 

Makala hiyo iliandikwa na A. Antipov, A. Ganush, Wahandisi wa Jukwaa. 

Chanzo: mapenzi.com