Thoir an aire. eadar-theangachadh.: Tha an artaigil seo, air a sgrìobhadh le Galo Navarro, aig a bheil dreuchd Prìomh Einnseanair Bathar-bog aig a’ chompanaidh Eòrpach Adevinta, na “sgrùdadh” inntinneach agus oideachail ann an raon gnìomhachd bun-structair. Chaidh an tiotal tùsail aige a leudachadh beagan ann an eadar-theangachadh airson adhbhar a mhìnich an t-ùghdar aig an fhìor thoiseach.
Nota bhon ùghdar: Tha e coltach ris a’ phost seo tòrr a bharrachd aire na bha dùil. Tha mi fhathast a’ faighinn beachdan feargach gu bheil tiotal an artaigil meallta agus gu bheil cuid de luchd-leughaidh fo bhròn. Tha mi a 'tuigsinn na h-adhbharan airson na tha a' tachairt, mar sin, a dh'aindeoin a 'chunnart a bhith a' milleadh an inntinn gu lèir, tha mi airson innse dhut sa bhad cò mu dheidhinn a tha an artaigil seo. Is e an rud annasach a chunnaic mi nuair a bhios sgiobaidhean a’ gluasad gu Kubernetes, nuair a dh’ èiricheas duilgheadas (leithid barrachd latency às deidh imrich), gur e Kubernetes a’ chiad rud a gheibh a’ choire, ach an uairsin thig e a-mach nach eil an orcastra dha-rìribh ri. coire. Tha an artaigil seo ag innse mu aon chùis mar sin. Tha an t-ainm ag ath-aithris clisgeadh aon den luchd-leasachaidh againn (nas fhaide air adhart chì thu nach eil dad aig Kubernetes ris). Chan fhaigh thu foillseachaidhean iongantach mu Kubernetes an seo, ach faodaidh dùil a bhith agad ri leasanan math no dhà mu shiostaman iom-fhillte.
O chionn seachdain no dhà, bha an sgioba agam a ’dèanamh imrich air aon mhicro-sheirbheis gu àrd-ùrlar bunaiteach a bha a’ toirt a-steach CI / CD, ùine ruith stèidhichte air Kubernetes, meatrach, agus rudan math eile. Bha an gluasad seo de nàdar deuchainneach: bha sinn an dùil a ghabhail mar bhunait agus timcheall air 150 seirbheis a bharrachd a ghluasad anns na mìosan a tha romhainn. Tha iad uile an urra ri cuid de na h-àrd-ùrlaran air-loidhne as motha san Spàinn (Infojobs, Fotocasa, msaa).
Às deidh dhuinn an tagradh a chuir gu Kubernetes agus beagan trafaic ath-stiùireadh thuige, bha iongnadh eagallach a’ feitheamh rinn. Moill (latency) bha iarrtasan ann an Kubernetes 10 tursan nas àirde na ann an EC2. San fharsaingeachd, bha e riatanach an dàrna cuid fuasgladh fhaighinn air an duilgheadas seo, no cuir às do imrich na microservice (agus, is dòcha, am pròiseact gu lèir).
Carson a tha latency cho fada nas àirde ann an Kubernetes na ann an EC2?
Gus na botail a lorg, chruinnich sinn metrics air an t-slighe iarrtas gu lèir. Tha an ailtireachd againn sìmplidh: tha geata API (Zuul) a’ toirt seachad iarrtasan gu suidheachaidhean microservice ann an EC2 no Kubernetes. Ann an Kubernetes bidh sinn a’ cleachdadh NGINX Ingress Controller, agus tha na backends nan nithean àbhaisteach mar le tagradh JVM air àrd-ùrlar an Earraich.
EC2
+---------------+
| +---------+ |
| | | |
+-------> BACKEND | |
| | | | |
| | +---------+ |
| +---------------+
+------+ |
Public | | |
-------> ZUUL +--+
traffic | | | Kubernetes
+------+ | +-----------------------------+
| | +-------+ +---------+ |
| | | | xx | | |
+-------> NGINX +------> BACKEND | |
| | | xx | | |
| +-------+ +---------+ |
+-----------------------------+Bha coltas gu robh an duilgheadas co-cheangailte ri latency tùsail san backend (chomharraich mi an raon duilgheadas air a’ ghraf mar “xx”). A thaobh EC2, thug freagairt an tagraidh timcheall air 20ms. Ann an Kubernetes, chaidh an latency suas gu 100-200 ms.
Chuir sinn às gu sgiobalta na daoine a bha fo amharas co-cheangailte ris an atharrachadh ùine ruith. Tha an dreach JVM fhathast mar a tha e. Cha robh gnothach sam bith aig duilgheadasan gleidhidh ris cuideachd: bha an tagradh mu thràth a’ ruith gu soirbheachail ann an soithichean air EC2. A' luchdachadh? Ach chunnaic sinn amannan fada eadhon aig iarrtas 1 san diog. Dh’ fhaodadh stadan airson cruinneachadh sgudail a bhith air an dearmad cuideachd.
Bha aon de ar luchd-rianachd Kubernetes a ’faighneachd an robh eisimeileachd bhon taobh a-muigh aig an tagradh leis gu robh ceistean DNS air cùisean coltach ris adhbhrachadh san àm a dh’ fhalbh.
Beachd-bheachd 1: Fuasgladh ainm DNS
Airson gach iarrtas, bidh an tagradh againn a’ faighinn cothrom air eisimpleir AWS Elasticsearch aon no trì tursan ann an raon mar elastic.spain.adevinta.com. Taobh a-staigh ar soithichean , gus an urrainn dhuinn dearbhadh a bheil rannsachadh airson àrainn a’ toirt ùine mhòr.
Ceistean DNS bho shoitheach:
[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msecIarrtasan coltach ri seo bho aon de na cùisean EC2 far a bheil an tagradh a’ ruith:
bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msecLeis gun tug an lorg timcheall air 30ms, thàinig e am follais gun robh rùn DNS nuair a bha e a’ faighinn cothrom air Elasticsearch gu dearbh a’ cur ris an àrdachadh ann an latency.
Ach, bha seo neònach airson dà adhbhar:
- Tha tunna de thagraidhean Kubernetes againn mu thràth a bhios ag eadar-obrachadh le goireasan AWS gun a bhith a’ fulang le latency àrd. Ge bith dè an adhbhar, tha e a 'buntainn gu sònraichte ris a' chùis seo.
- Tha fios againn gu bheil an JVM a’ dèanamh tasgadan DNS ann an cuimhne. Anns na h-ìomhaighean againn, tha luach TTL sgrìobhte a-steach
$JAVA_HOME/jre/lib/security/java.securityagus cuir sìos gu 10 diogan:networkaddress.cache.ttl = 10. Ann am faclan eile, bu chòir don JVM a h-uile ceist DNS a thasgadh airson 10 diogan.
Gus a ’chiad bheachd-bharail a dhearbhadh, chuir sinn romhainn stad a chuir air fios DNS airson greis gus faicinn an deach an duilgheadas air falbh. An toiseach, chuir sinn romhainn an tagradh ath-dhealbhadh gus am biodh e a’ conaltradh gu dìreach ri Elasticsearch le seòladh IP, seach tro ainm fearainn. Dh'fheumadh seo atharrachaidhean còd agus cleachdadh ùr, agus mar sin cha do rinn sinn ach an àrainn a mhapadh chun t-seòladh IP aige /etc/hosts:
34.55.5.111 elastic.spain.adevinta.comA-nis fhuair an soitheach IP cha mhòr sa bhad. Dh'adhbhraich seo beagan leasachaidh, ach cha robh sinn ach beagan nas fhaisge air na h-ìrean latency ris an robh dùil. Ged a thug fuasgladh DNS ùine mhòr, chuir an fhìor adhbhar às dhuinn fhathast.
Diagnosachd tro lìonra
Cho-dhùin sinn sgrùdadh a dhèanamh air trafaic bhon ghobhar a’ cleachdadh tcpdumpgus faicinn dè dìreach a tha a’ tachairt air an lìonra:
[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap
Chuir sinn an uairsin grunn iarrtasan agus luchdaich sinn sìos an glacadh (kubectl cp my-service:/capture.pcap capture.pcap) airson tuilleadh sgrùdaidh ann an .
Cha robh dad amharasach mu na ceistean DNS (ach a-mhàin aon rud beag air am bi mi a’ bruidhinn nas fhaide air adhart). Ach bha rudan neònach san dòigh anns an do làimhsich an t-seirbheis againn gach iarrtas. Gu h-ìosal tha dealbh-sgrìn den ghlacadh a’ sealltainn an iarrtas a thathar a’ gabhail ris mus tòisich am freagairt:
Tha àireamhan pacaid air an sealltainn sa chiad cholbh. Airson soilleireachd, tha mi air còd dath a chuir air na diofar shruthan TCP.
Tha an sruth uaine a’ tòiseachadh le pacaid 328 a’ sealltainn mar a stèidhich an neach-dèiligidh (172.17.22.150) ceangal TCP ris a’ ghobhar (172.17.36.147). Às deidh a’ chiad chrathadh làimhe (328-330), thug pasgan 331 HTTP GET /v1/.. - iarrtas a’ tighinn a-steach don t-seirbheis againn. Ghabh am pròiseas gu lèir 1 ms.
Tha an sruth glas (bho phacaid 339) a’ sealltainn gun do chuir an t-seirbheis againn iarrtas HTTP chun eisimpleir Elasticsearch (chan eil crathadh làimhe TCP ann leis gu bheil e a’ cleachdadh ceangal a th’ ann mar-thà). Thug seo 18m.
Gu ruige seo tha a h-uile dad gu math, agus tha na h-amannan gu ìre mhòr a rèir an dàil ris a bheil dùil (20-30 ms nuair a thèid a thomhas bhon neach-dèiligidh).
Ach, bheir an earrann ghorm 86ms. Dè tha dol ann? Le pacaid 333, chuir an t-seirbheis againn iarrtas HTTP GET gu /latest/meta-data/iam/security-credentials, agus dìreach às a dhèidh, thairis air an aon cheangal TCP, iarrtas GET eile gu /latest/meta-data/iam/security-credentials/arn:...
Fhuair sinn a-mach gun deach seo a-rithist leis a h-uile iarrtas air feadh an lorg. Tha rùn DNS gu dearbh beagan nas slaodaiche anns na soithichean againn (tha am mìneachadh airson an iongantas seo gu math inntinneach, ach sàbhalaidh mi e airson artaigil air leth). Thionndaidh e a-mach gur e adhbhar an dàil fhada fiosan gu seirbheis AWS Instance Metadata air gach iarrtas.
Beachd-bharail 2: fiosan neo-riatanach gu AWS
Buinidh an dà phuing crìochnachaidh . Bidh am microservice againn a’ cleachdadh na seirbheis seo fhad ‘s a tha iad a’ ruith Elasticsearch. Tha an dà ghairm mar phàirt den phròiseas ceadachaidh bunaiteach. Tha a’ phuing crìochnachaidh a gheibhear air a’ chiad iarrtas a’ cur a-mach dreuchd IAM co-cheangailte ris an t-suidheachadh.
/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_roleTha an dàrna iarrtas a’ faighneachd don dàrna puing-deiridh airson ceadan sealach airson an t-suidheachaidh seo:
/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
"SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token" : "token",
"Expiration" : "2017-05-17T15:09:54Z"
}
Faodaidh an neach-dèiligidh an cleachdadh airson ùine ghoirid agus feumaidh e teisteanasan ùra fhaighinn bho àm gu àm (mus bi iad Expiration). Tha am modail sìmplidh: bidh AWS a’ cuairteachadh iuchraichean sealach gu tric airson adhbharan tèarainteachd, ach faodaidh teachdaichean an tasgadh airson beagan mhionaidean gus dìoladh a dhèanamh airson a’ pheanas coileanaidh co-cheangailte ri bhith a’ faighinn theisteanasan ùra.
Bu chòir don AWS Java SDK an uallach a ghabhail airson a’ phròiseas seo a chuir air dòigh, ach airson adhbhar air choireigin chan eil seo a’ tachairt.
Às deidh dhuinn cùisean a sgrùdadh air GitHub, thàinig sinn tarsainn air duilgheadas . Chuidich i sinn le bhith a’ faighinn a-mach an t-slighe airson “cladhach” a bharrachd.
Bidh an AWS SDK ag ùrachadh theisteanasan nuair a thachras aon de na cumhaichean a leanas:
- Ceann-latha crìochnachaidh (
Expiration) Tuit a steachEXPIRATION_THRESHOLD, le còd cruaidh gu 15 mionaidean. - Tha barrachd ùine air a dhol seachad bhon oidhirp mu dheireadh air teisteanasan ùrachadh
REFRESH_THRESHOLD, le còd cruaidh airson 60 mionaid.
Gus fìor cheann-latha crìochnachaidh nan teisteanasan a gheibh sinn fhaicinn, ruith sinn na h-òrdughan cURL gu h-àrd bhon dà chuid an soitheach agus an eisimpleir EC2. Bha ùine dligheachd an teisteanais a fhuaireadh bhon bhogsa gu math nas giorra: dìreach 15 mionaidean.
A-nis tha a h-uile dad air fàs soilleir: airson a 'chiad iarrtas, fhuair an t-seirbheis againn teisteanasan sealach. Leis nach robh iad dligheach airson barrachd air 15 mionaidean, cho-dhùin an AWS SDK an ùrachadh an ath thuras a chaidh iarraidh orra. Agus thachair seo leis a h-uile iarrtas.
Carson a tha ùine dligheachd theisteanasan air fàs nas giorra?
Tha AWS Instance Metadata air a dhealbhadh gus obrachadh le cùisean EC2, chan e Kubernetes. Air an làimh eile, cha robh sinn airson eadar-aghaidh an tagraidh atharrachadh. Airson seo chleachd sinn - inneal a leigeas le luchd-cleachdaidh (innleadairean a’ cleachdadh thagraidhean gu brabhsair) dreuchdan IAM a shònrachadh do shoithichean ann am pods mar gum biodh iad nan eisimpleirean EC2. Bidh KIAM a’ toirt a-steach fiosan gu seirbheis AWS Instance Metadata agus gan giullachd bhon tasgadan aige, às deidh dhaibh fhaighinn bho AWS roimhe seo. Bho shealladh an tagraidh, chan eil dad ag atharrachadh.
Bidh KIAM a’ toirt seachad teisteanasan geàrr-ùine gu pods. Tha seo a’ dèanamh ciall leis gu bheil beatha cuibheasach pod nas giorra na eisimpleir EC2. Ùine dligheachd bunaiteach airson teisteanasan .
Mar thoradh air an sin, ma chuireas tu thairis an dà luach bunaiteach air mullach a chèile, bidh duilgheadas ag èirigh. Thig gach teisteanas a thèid a thoirt do thagradh gu crìch an dèidh 15 mionaidean. Ach, tha an AWS Java SDK a’ sparradh ùrachadh air teisteanas sam bith aig a bheil nas lugha na 15 mionaidean air fhàgail ron cheann-latha crìochnachaidh aige.
Mar thoradh air an sin, feumar an teisteanas sealach ùrachadh le gach iarrtas, a tha a’ toirt a-steach fios no dhà gu API AWS agus ag adhbhrachadh àrdachadh mòr ann an latency. Ann an AWS Java SDK lorg sinn , a tha a 'toirt iomradh air duilgheadas coltach ris.
Thionndaidh am fuasgladh gu bhith sìmplidh. Dìreach rinn sinn ath-dhealbhadh air KIAM gus teisteanasan iarraidh le ùine dligheachd nas fhaide. Aon uair ‘s gun do thachair seo, thòisich iarrtasan a’ sruthadh às aonais com-pàirt seirbheis Metadata AWS, agus thuit an latency gu ìrean eadhon nas ìsle na ann an EC2.
toraidhean
Stèidhichte air ar n-eòlas le imrich, is e aon de na stòran trioblaid as cumanta nach e biastagan ann an Kubernetes no eileamaidean eile den àrd-ùrlar. Chan eil e cuideachd a’ dèiligeadh ri lochdan bunaiteach sam bith anns na microservices a tha sinn a’ giùlan. Bidh duilgheadasan gu tric ag èirigh dìreach leis gu bheil sinn a’ cur diofar eileamaidean ri chèile.
Bidh sinn a’ measgachadh shiostaman iom-fhillte nach robh riamh air eadar-obrachadh le chèile roimhe, agus sinn an dùil gun cruthaich iad còmhla siostam singilte nas motha. Gu mì-fhortanach, mar as motha de eileamaidean, is ann as motha de rùm airson mearachdan, is ann as àirde an entropy.
Anns a ’chùis againn, cha robh an latency àrd mar thoradh air biastagan no droch cho-dhùnaidhean ann an Kubernetes, KIAM, AWS Java SDK, no ar microservice. Bha e mar thoradh air dà shuidheachadh bunaiteach neo-eisimeileach a chur còmhla: aon ann an KIAM, am fear eile anns an AWS Java SDK. Air an gabhail air leth, tha an dà pharamadair a’ dèanamh ciall: am poileasaidh ath-nuadhachaidh theisteanasan gnìomhach anns an AWS Java SDK, agus an ùine dligheachd goirid de theisteanasan ann an KAIM. Ach nuair a chuireas tu iad ri chèile, bidh na toraidhean a 'fàs neo-fhaicsinneach. Chan fheum dà fhuasgladh neo-eisimeileach agus loidsigeach ciall a dhèanamh nuair a thèid an cur còmhla.
PS bhon eadar-theangair
Faodaidh tu barrachd ionnsachadh mu ailtireachd goireas KIAM airson a bhith ag amalachadh AWS IAM le Kubernetes aig bho a luchd-cruthachaidh.
Leugh air ar blog cuideachd:
- «";
- «";
- «";
- «".
Source: www.habr.com