Kumbuka. tafsiri.: Wafanyakazi wa huduma maarufu duniani ya Tinder hivi majuzi walishiriki baadhi ya maelezo ya kiufundi ya kuhamisha miundombinu yao hadi Kubernetes. Mchakato huo ulichukua karibu miaka miwili na kusababisha kuzinduliwa kwa jukwaa kubwa sana kwenye K8s, likijumuisha huduma 200 zilizowekwa kwenye kontena elfu 48. Je, wahandisi wa Tinder walikumbana na matatizo gani ya kuvutia na walipata matokeo gani? Soma tafsiri hii.
Kwa nini?
Takriban miaka miwili iliyopita, Tinder iliamua kuhamisha jukwaa lake hadi Kubernetes. Kubernetes ingeruhusu timu ya Tinder kuweka vyombo na kuhamia kwenye uzalishaji kwa juhudi ndogo kupitia upelekaji usiobadilika. (usambazaji usiobadilika). Katika kesi hii, mkusanyiko wa maombi, uwekaji wao, na miundombinu yenyewe itafafanuliwa kipekee na nambari.
Pia tulikuwa tunatafuta suluhu la tatizo la uthabiti na uthabiti. Wakati uongezaji ulipokuwa muhimu, mara nyingi tulilazimika kusubiri dakika kadhaa kwa matukio mapya ya EC2 kuzunguka. Wazo la kuzindua vyombo na kuanza kuhudumia trafiki kwa sekunde badala ya dakika likawa la kuvutia sana kwetu.
Mchakato uligeuka kuwa mgumu. Wakati wa uhamiaji wetu mapema mwaka wa 2019, nguzo ya Kubernetes ilifikia idadi kubwa na tulianza kukumbana na matatizo mbalimbali kutokana na wingi wa trafiki, ukubwa wa nguzo na DNS. Njiani, tulitatua matatizo mengi ya kuvutia yanayohusiana na kuhama huduma 200 na kudumisha nguzo ya Kubernetes inayojumuisha nodi 1000, ganda 15000 na vyombo 48000 vinavyoendesha.
Jinsi gani?
Tangu Januari 2018, tumepitia hatua mbalimbali za uhamiaji. Tulianza kwa kujumuisha huduma zetu zote na kuzipeleka kwenye mazingira ya majaribio ya Kubernetes. Kuanzia Oktoba, tulianza kuhamishia huduma zote zilizopo Kubernetes. Kufikia Machi mwaka uliofuata, tulikamilisha uhamishaji na sasa mfumo wa Tinder unatumia Kubernetes pekee.
Kujenga picha za Kubernetes
Tuna zaidi ya hazina 30 za msimbo wa chanzo kwa huduma ndogo ndogo zinazoendeshwa kwenye nguzo ya Kubernetes. Nambari katika hazina hizi imeandikwa katika lugha tofauti (kwa mfano, Node.js, Java, Scala, Go) na mazingira mengi ya wakati wa kukimbia kwa lugha moja.
Mfumo wa kujenga umeundwa ili kutoa "muktadha wa kujenga" unaoweza kubinafsishwa kikamilifu kwa kila huduma ndogo. Kawaida huwa na Dockerfile na orodha ya amri za ganda. Maudhui yao yanaweza kubinafsishwa kabisa, na wakati huo huo, miktadha hii yote ya ujenzi imeandikwa kulingana na umbizo sanifu. Kusawazisha muktadha wa ujenzi huruhusu mfumo mmoja wa ujenzi kushughulikia huduma ndogo zote.
Kielelezo 1-1. Mchakato wa ujenzi uliosawazishwa kupitia kontena la Wajenzi
Ili kufikia uwiano wa juu kati ya nyakati za kukimbia (mazingira ya wakati wa kukimbia) mchakato huo wa kujenga hutumiwa wakati wa maendeleo na majaribio. Tulikumbana na changamoto ya kuvutia sana: ilitubidi tutengeneze njia ya kuhakikisha uthabiti wa mazingira ya ujenzi kwenye jukwaa zima. Ili kufikia hili, taratibu zote za kusanyiko hufanyika ndani ya chombo maalum. Wajenzi.
Utekelezaji wa chombo chake ulihitaji mbinu za hali ya juu za Docker. Mjenzi hurithi kitambulisho cha mtumiaji na siri za ndani (kama vile ufunguo wa SSH, vitambulisho vya AWS, n.k.) zinazohitajika kufikia hazina za kibinafsi za Tinder. Huweka saraka za ndani zilizo na vyanzo ili kuhifadhi asili za vizalia vya ujenzi. Mbinu hii huboresha utendakazi kwa sababu huondoa hitaji la kunakili vizalia vya ujenzi kati ya chombo cha Mjenzi na seva pangishi. Vizalia vya programu vilivyohifadhiwa vinaweza kutumika tena bila usanidi wa ziada.
Kwa baadhi ya huduma, ilitubidi kuunda kontena lingine ili kuweka mazingira ya mkusanyo kwa mazingira ya wakati wa kutekelezwa (kwa mfano, maktaba ya Node.js bcrypt huzalisha vizalia vya programu binary mahususi wakati wa usakinishaji). Wakati wa mchakato wa ujumuishaji, mahitaji yanaweza kutofautiana kati ya huduma, na Dockerfile ya mwisho inakusanywa kwa kuruka.
Usanifu na uhamiaji wa nguzo ya Kubernetes
Usimamizi wa ukubwa wa nguzo
Tuliamua kutumia kube-aws kwa uwekaji wa nguzo otomatiki kwenye matukio ya Amazon EC2. Mwanzoni kabisa, kila kitu kilifanya kazi katika bwawa moja la kawaida la nodi. Tuligundua haraka hitaji la kutenganisha mzigo wa kazi kwa ukubwa na aina ya mfano ili kutumia rasilimali kwa ufanisi zaidi. Mantiki ilikuwa kwamba kuzindua maganda kadhaa yaliyopakiwa yenye nyuzi nyingi iligeuka kuwa ya kutabirika zaidi katika suala la utendaji kuliko kuwepo kwao pamoja na idadi kubwa ya maganda ya nyuzi moja.
Mwishowe tulitatua:
- m5.4 kubwa - kwa ufuatiliaji (Prometheus);
- c5.4 kubwa - kwa mzigo wa kazi wa Node.js (mzigo wa kazi wa thread moja);
- c5.2 kubwa - kwa Java na Go (mzigo wa kazi wa multithreaded);
- c5.4 kubwa - kwa jopo la kudhibiti (nodi 3).
Uhamiaji
Mojawapo ya hatua za maandalizi ya kuhama kutoka kwa miundombinu ya zamani hadi Kubernetes ilikuwa kuelekeza upya mawasiliano ya moja kwa moja yaliyopo kati ya huduma kwa visawazisha vipya vya mizigo (Elastic Load Balancers (ELB). Ziliundwa kwenye subnet maalum ya wingu la kibinafsi la kawaida (VPC). Subnet hii iliunganishwa kwa Kubernetes VPC. Hii ilituruhusu kuhama moduli hatua kwa hatua, bila kuzingatia mpangilio maalum wa utegemezi wa huduma.
Viingilio hivi viliundwa kwa kutumia seti zilizopimwa za rekodi za DNS ambazo zilikuwa na CNAME zinazoelekeza kwa kila ELB mpya. Ili kubadilisha, tuliongeza ingizo jipya linaloelekeza kwa huduma mpya ya Kubernetes ELB yenye uzito wa 0. Kisha tukaweka Muda wa Kuishi (TTL) wa ingizo lililowekwa kuwa 0. Baada ya hayo, uzani wa zamani na mpya ulirekebishwa polepole. , na hatimaye 100% ya mzigo ilitumwa kwa seva mpya. Baada ya ubadilishaji kukamilika, thamani ya TTL ilirudi kwa kiwango cha kutosha zaidi.
Moduli za Java tulikuwa nazo zinaweza kukabiliana na TTL DNS ya chini, lakini programu za Node hazingeweza. Mmoja wa wahandisi aliandika upya sehemu ya msimbo wa bwawa la unganisho na kuifunga kwa meneja ambaye alisasisha mabwawa kila baada ya sekunde 60. Mbinu iliyochaguliwa ilifanya kazi vizuri sana na bila uharibifu wowote wa utendaji unaoonekana.
Masomo
Mipaka ya Kitambaa cha Mtandao
Mapema asubuhi ya Januari 8, 2019, jukwaa la Tinder lilianguka bila kutarajiwa. Kwa kukabiliana na ongezeko lisilohusiana la kusubiri kwa jukwaa mapema asubuhi hiyo, idadi ya maganda na nodi kwenye nguzo iliongezeka. Hii ilisababisha kache ya ARP kuisha kwenye nodi zetu zote.
Kuna chaguzi tatu za Linux zinazohusiana na kashe ya ARP:
()
gc_thresh3 - hii ni kikomo ngumu. Kuonekana kwa maingizo ya "meza ya jirani" kwenye logi ilimaanisha kwamba hata baada ya ukusanyaji wa takataka wa synchronous (GC), hapakuwa na nafasi ya kutosha katika cache ya ARP ili kuhifadhi ingizo la jirani. Katika kesi hii, kernel ilitupa pakiti kabisa.
Tunatumia kama kitambaa cha mtandao huko Kubernetes. Pakiti hupitishwa kupitia VXLAN. VXLAN ni handaki ya L2 iliyoinuliwa juu ya mtandao wa L3. Teknolojia hutumia usimbaji wa MAC-in-UDP (Itifaki ya Datagram ya Anwani ya MAC) na inaruhusu upanuzi wa sehemu za mtandao za Tabaka 2. Itifaki ya usafiri kwenye mtandao wa kituo cha data halisi ni IP pamoja na UDP.
Kielelezo 2-1. Mchoro wa flannel ()
Kielelezo 2-2. Kifurushi cha VXLAN ()
Kila nodi ya mfanyakazi wa Kubernetes hutenga nafasi ya anwani pepe na mask /24 kutoka kwa kizuizi kikubwa /9. Kwa kila nodi hii ni ingizo moja kwenye jedwali la uelekezaji, kiingilio kimoja kwenye jedwali la ARP (kwenye kiolesura cha flannel.1), na kiingilio kimoja kwenye meza ya kubadilishia (FDB). Zinaongezwa mara ya kwanza nodi ya mfanyakazi inapoanzishwa au kila wakati nodi mpya inapogunduliwa.
Zaidi ya hayo, mawasiliano ya nodi-pod (au pod-pod) hatimaye hupitia kiolesura eth0 (kama inavyoonyeshwa kwenye mchoro wa Flannel hapo juu). Hii inasababisha ingizo la ziada katika jedwali la ARP kwa kila chanzo sambamba na mwenyeji lengwa.
Katika mazingira yetu, aina hii ya mawasiliano ni ya kawaida sana. Kwa vipengee vya huduma katika Kubernetes, ELB inaundwa na Kubernetes husajili kila nodi na ELB. ELB haijui chochote kuhusu maganda na nodi iliyochaguliwa inaweza isiwe mahali pa mwisho pa pakiti. Jambo ni kwamba wakati nodi inapokea pakiti kutoka kwa ELB, inazingatia kuzingatia sheria iptables kwa huduma maalum na kwa nasibu huchagua ganda kwenye nodi nyingine.
Wakati wa kushindwa, kulikuwa na nodes 605 kwenye nguzo. Kwa sababu zilizotajwa hapo juu, hii ilitosha kushinda umuhimu gc_thresh3, ambayo ndiyo chaguo-msingi. Wakati hii itatokea, sio tu pakiti huanza kudondoshwa, lakini nafasi nzima ya anwani ya Flannel na mask /24 hupotea kutoka kwa meza ya ARP. Mawasiliano ya nodi-pod na hoja za DNS zimekatizwa (DNS inapangishwa katika kundi; soma baadaye katika makala haya kwa maelezo zaidi).
Ili kutatua tatizo hili, unahitaji kuongeza maadili gc_thresh1, gc_thresh2 ΠΈ gc_thresh3 na uanze upya Flannel ili kusajili upya mitandao iliyokosekana.
Kuongeza DNS isiyotarajiwa
Wakati wa mchakato wa uhamiaji, tulitumia DNS kikamilifu kudhibiti trafiki na kuhamisha huduma hatua kwa hatua kutoka kwa miundombinu ya zamani hadi Kubernetes. Tunaweka viwango vya chini vya TTL kwa RecordSets zinazohusiana katika Route53. Wakati muundo msingi wa zamani ulikuwa ukifanya kazi kwenye matukio ya EC2, usanidi wetu wa kisuluhishi ulielekeza kwenye Amazon DNS. Tulichukulia hili kuwa jambo la kawaida na athari za TTL ya chini kwenye huduma zetu na huduma za Amazon (kama vile DynamoDB) hazikutambuliwa kwa sehemu kubwa.
Tulipohamisha huduma hadi Kubernetes, tuligundua kuwa DNS ilikuwa ikichakata maombi elfu 250 kwa sekunde. Kwa hivyo, programu zilianza kupata muda wa kuisha na mbaya kwa hoja za DNS. Hili lilifanyika licha ya jitihada za ajabu za kuboresha na kubadili mtoa huduma wa DNS hadi CoreDNS (ambayo kwa upakiaji wa kilele ilifikia maganda 1000 yanayotumia cores 120).
Wakati tukitafiti sababu na suluhisho zingine zinazowezekana, tuligundua , inayoelezea hali za mbio zinazoathiri mfumo wa kuchuja pakiti netfilter katika Linux. Muda tulioona, pamoja na kihesabu kinachoongezeka kuingiza_imeshindwa katika kiolesura cha Flana ziliendana na matokeo ya makala.
Tatizo hutokea katika hatua ya Tafsiri ya Anwani ya Chanzo na Lengwa ya Mtandao (SNAT na DNAT) na kuingia kwenye jedwali. kubadilisha. Mojawapo ya suluhisho zilizojadiliwa ndani na kupendekezwa na jamii ilikuwa kuhamisha DNS hadi nodi ya wafanyikazi yenyewe. Kwa kesi hii:
- SNAT haihitajiki kwa sababu trafiki hukaa ndani ya nodi. Haina haja ya kupitishwa kupitia interface eth0.
- DNAT haihitajiki kwa kuwa IP ya marudio ni ya ndani kwa nodi, na sio ganda lililochaguliwa kwa nasibu kulingana na sheria. iptables.
Tuliamua kushikamana na njia hii. CoreDNS iliwekwa kama DaemonSet katika Kubernetes na tulitekeleza seva ya eneo la DNS katika kutatua kila ganda kwa kuweka bendera --cluster-dns timu mchemrabaβ. Suluhisho hili lilifanikiwa kwa kuisha kwa muda kwa DNS.
Walakini, bado tuliona upotezaji wa pakiti na kuongezeka kwa kihesabu kuingiza_imeshindwa kwenye kiolesura cha Flannel. Hii iliendelea baada ya usuluhishi kutekelezwa kwa sababu tuliweza kuondoa SNAT na/au DNAT kwa trafiki ya DNS pekee. Masharti ya mbio yalihifadhiwa kwa aina zingine za trafiki. Kwa bahati nzuri, pakiti zetu nyingi ni TCP, na tatizo likitokea hutumwa tena. Bado tunajaribu kutafuta suluhisho linalofaa kwa aina zote za trafiki.
Kutumia Mjumbe kwa Usawazishaji Bora wa Mzigo
Tulipohamisha huduma za nyuma hadi Kubernetes, tulianza kuteseka kutokana na mzigo usio na usawa kati ya maganda. Tuligundua kuwa HTTP Keepalive ilisababisha miunganisho ya ELB kuning'inia kwenye maganda ya kwanza tayari ya kila upelekaji uliotolewa. Kwa hivyo, wingi wa trafiki ulipitia asilimia ndogo ya maganda yaliyopatikana. Suluhisho la kwanza tulilojaribu lilikuwa kuweka MaxSurge hadi 100% kwa usambazaji mpya kwa hali mbaya zaidi. Athari iligeuka kuwa ndogo na isiyo na matumaini kwa suala la upelekaji mkubwa.
Suluhisho lingine tulilotumia lilikuwa kuongeza maombi ya rasilimali kwa huduma muhimu. Katika hali hii, maganda yaliyowekwa karibu yatakuwa na nafasi zaidi ya kuendesha ikilinganishwa na maganda mengine mazito. Haingefanya kazi kwa muda mrefu pia kwa sababu itakuwa upotezaji wa rasilimali. Kwa kuongezea, programu tumizi zetu za Node zilikuwa zenye nyuzi moja na, ipasavyo, zinaweza kutumia msingi mmoja tu. Suluhisho pekee la kweli lilikuwa kutumia kusawazisha mzigo bora.
Kwa muda mrefu tumetaka kuthamini kikamilifu . Hali ya sasa ilituruhusu kuipeleka kwa njia ndogo sana na kupata matokeo ya haraka. Mjumbe ni proksi ya utendakazi wa juu, chanzo-wazi, safu-7 iliyoundwa kwa ajili ya programu kubwa za SOA. Inaweza kutekeleza mbinu za hali ya juu za kusawazisha upakiaji, ikijumuisha majaribio ya kiotomatiki, vivunja saketi, na kikwazo cha kimataifa. (Kumbuka. tafsiri.: Unaweza kusoma zaidi kuhusu hili katika kuhusu Istio, ambayo inategemea Mjumbe.)
Tulikuja na usanidi ufuatao: kuwa na kando ya Mjumbe kwa kila ganda na njia moja, na unganisha nguzo kwenye kontena ndani yako kupitia mlango. Ili kupunguza uwezekano wa kuporomoka na kudumisha radius ndogo ya kugonga, tulitumia kundi la maganda ya wakala wa Mjumbe, moja kwa kila Eneo la Upatikanaji (AZ) kwa kila huduma. Walitegemea injini rahisi ya ugunduzi wa huduma iliyoandikwa na mmoja wa wahandisi wetu ambayo ilirudisha tu orodha ya maganda katika kila AZ kwa huduma fulani.
Wajumbe wa mbele wa Huduma kisha wakatumia utaratibu huu wa ugunduzi wa huduma na nguzo moja ya juu ya mkondo na njia. Tuliweka muda wa kutosha wa kuisha, tukaongeza mipangilio yote ya kikatiza mzunguko, na tukaongeza usanidi mdogo wa kujaribu tena kusaidia kwa hitilafu moja na kuhakikisha utumiaji laini. Tuliweka TCP ELB mbele ya kila moja ya Wajumbe hawa wa mbele wa huduma. Hata kama hifadhi hai kutoka kwa safu yetu kuu ya seva mbadala ilikwama kwenye baadhi ya ganda la Wajumbe, bado ziliweza kushughulikia mzigo vizuri zaidi na zilisanidiwa ili kusawazisha kupitia angalau_request katika sehemu ya nyuma.
Kwa usambazaji, tulitumia ndoano ya preStop kwenye ganda la programu na maganda ya kando. Ndoano ilisababisha hitilafu katika kuangalia hali ya sehemu ya mwisho ya msimamizi iliyo kwenye kontena la kando na kulala kwa muda ili kuruhusu miunganisho inayotumika kukatika.
Mojawapo ya sababu ambazo tumeweza kusonga haraka ni kwa sababu ya vipimo vya kina ambavyo tuliweza kujumuisha kwa urahisi kwenye usakinishaji wa kawaida wa Prometheus. Hili lilituruhusu kuona ni nini hasa kilikuwa kikitendeka tulipokuwa tukirekebisha vigezo vya usanidi na kusambaza tena trafiki.
Matokeo yalikuwa ya haraka na dhahiri. Tulianza na huduma zisizo na usawa, na kwa sasa inafanya kazi mbele ya huduma 12 muhimu zaidi kwenye nguzo. Mwaka huu tunapanga mpito kwenda kwa wavu kamili wa huduma yenye ugunduzi wa huduma ya hali ya juu zaidi, uvunjaji wa mzunguko, utambuzi wa nje, kupunguza kasi na ufuatiliaji.
Kielelezo 3-1. Muunganisho wa CPU wa huduma moja wakati wa mpito hadi Mjumbe
Matokeo ya mwisho
Kupitia uzoefu huu na utafiti wa ziada, tumeunda timu dhabiti ya miundombinu yenye ujuzi dhabiti katika kubuni, kupeleka na kuendesha vikundi vikubwa vya Kubernetes. Wahandisi wote wa Tinder sasa wana ujuzi na uzoefu wa kufunga vyombo na kupeleka programu kwa Kubernetes.
Wakati hitaji la uwezo wa ziada lilipotokea kwenye miundombinu ya zamani, ilitubidi kusubiri dakika kadhaa kwa matukio mapya ya EC2 kuzindua. Sasa vyombo vinaanza kufanya kazi na kuanza kuchakata trafiki ndani ya sekunde badala ya dakika. Kupanga vyombo vingi kwenye mfano mmoja wa EC2 pia hutoa mkusanyiko ulioboreshwa wa mlalo. Kwa hivyo, tunatabiri kupungua kwa kiasi kikubwa kwa gharama za EC2019 katika 2 ikilinganishwa na mwaka jana.
Uhamiaji ulichukua karibu miaka miwili, lakini tulikamilisha Machi 2019. Jukwaa la Tinder kwa sasa linaendeshwa tu kwenye kundi la Kubernetes linalojumuisha huduma 200, nodi 1000, maganda 15, na kontena 000 zinazoendesha. Miundombinu si tena kikoa pekee cha timu za uendeshaji. Wahandisi wetu wote wanashiriki jukumu hili na kudhibiti mchakato wa kujenga na kupeleka programu zao kwa kutumia msimbo pekee.
PS kutoka kwa mtafsiri
Soma pia safu ya nakala kwenye blogi yetu:
- Β«'.
- Β«'.
- Β«'.
- Β«'.
- Β«'.
- Β«'.
- Β«'.
- Β«'.
- Β«'.
- Β«'.
Chanzo: mapenzi.com