“Meudaich Kubernetes latency 10 tursan": cò as coireach airson seo?

Thoir an aire. eadar-theangachadh.Tha an t-artaigil seo, a sgrìobh Galo Navarro, Prìomh Innleadair Bathar-bog aig a’ chompanaidh Eòrpach Adevinta, na “rannsachadh” inntinneach is teagasgach air raon obrachaidhean bun-structair. Chaidh an tiotal tùsail atharrachadh beagan san eadar-theangachadh airson adhbhar a mhìnicheas an t-ùghdar aig an toiseach.

Nota bhon ùghdarTha e coltach ris an fhoillseachadh seo air a tharraing Tha an t-artaigil seo air barrachd aire fhaighinn na bha dùil. Tha mi fhathast a’ faighinn beachdan feargach mun tiotal meallta agus cuid de luchd-leughaidh a’ faireachdainn mì-thoilichte. Tha mi a’ tuigsinn nan adhbharan airson seo, agus mar sin ged a tha mi ann an cunnart an sgeulachd gu lèir a mhilleadh, tha mi airson mìneachadh dè a tha an t-artaigil seo mu dheidhinn. Nuair a bhios sgiobaidhean a’ gluasad gu Kubernetes, bidh mi a’ mothachadh rud neònach: a h-uile uair a thig duilgheadas am bàrr (mar eisimpleir, barrachd dàil às deidh imrich), is e Kubernetes a’ chiad rud a chuireas iad a’ choire, ach tha e a’ tionndadh a-mach nach e an t-eagraiche a tha ri choireachadh idir. Tha an t-artaigil seo ag innse sgeulachd aon chùis mar sin. Tha an tiotal aige a’ nochdadh glaodh bho aon de na luchd-leasachaidh againn (chì thu nas fhaide air adhart nach robh dad aig Kubernetes ris). Cha lorg thu foillseachaidhean iongantach sam bith mu Kubernetes, ach faodaidh tu a bhith an dùil ri beagan leasanan math mu shiostaman iom-fhillte.

Beagan sheachdainean air ais, bha an sgioba agam a’ gluasad aon mhicro-sheirbheis gu àrd-ùrlar bunaiteach anns an robh CI/CD, àrainneachd cinneasachaidh stèidhichte air Kubernetes, meatairean, agus feartan feumail eile. B’ e pròiseact pìleat a bha seo: bha sinn an dùil togail air agus timcheall air 150 seirbheis eile a ghluasad anns na mìosan a tha romhainn. Tha na seirbheisean seo uile a’ toirt cumhachd do chuid de na margaidhean air-loidhne as motha san Spàinn (Infojobs, Fotocasa, agus feadhainn eile).

Às dèidh dhuinn an aplacaid a chuir a-mach gu Kubernetes agus beagan trafaic ath-stiùireadh thuige, bha iongnadh eagallach romhainn. Latency (latency) Bha an àireamh de dh’iarrtasan ann an Kubernetes 10 uiread nas àirde na ann an EC2. Mu dheireadh, b’ fheudar fuasgladh a lorg air an duilgheadas seo no an imrich microservice a thrèigsinn (agus, is dòcha, am pròiseact gu lèir).

Carson a tha latency cho àrd ann an Kubernetes na ann an EC2?

Gus am bacadh a lorg, chruinnich sinn meatairean air feadh slighe na h-iarrtas gu lèir. Tha an ailtireachd againn sìmplidh: bidh geata API (Zuul) a’ cur iarrtasan gu eisimpleirean microservice ann an EC2 no Kubernetes. Ann an Kubernetes, bidh sinn a’ cleachdadh Smachdair Ingress NGINX, agus tha na backends nan nithean cunbhalach den t-seòrsa Cleachdadh le tagradh JVM air àrd-ùrlar Spring.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

Bha coltas ann gu robh a’ chùis co-cheangailte ri dàil aig ìre tòiseachaidh giollachd a’ chùl-raoin (chomharraich mi an raon trioblaideach air a’ ghraf mar “xx”). Ann an EC2, thug freagairt an tagraidh timcheall air 20 ms. Ann an Kubernetes, dh’ èirich an dàil gu 100-200 ms.

Chuir sinn às gu sgiobalta do na h-amharasan a dh’ fhaodadh a bhith ann co-cheangailte ris an atharrachadh ruith-ùine. Dh’fhan an dreach JVM mar a bha e. Cha robh cùisean containerachaidh co-cheangailte ri chèile nas motha: bha an aplacaid mu thràth ag obair gu soirbheachail ann an soithichean ann an EC2. Luchdaich? Ach chunnaic sinn latencies àrd eadhon le aon iarrtas gach diog. Bha stadan cruinneachadh sgudail neo-shuntasach cuideachd.

Dh’fhaighnich aon de na rianairean Kubernetes againn an robh eisimeileachdan taobh a-muigh sam bith aig an aplacaid, leis gun robh ceistean DNS air cùisean coltach ris adhbhrachadh roimhe.

Beachd-bharail 1: Fuasgladh ainmean DNS

Airson gach iarrtas, bidh an aplacaid againn a’ dèanamh aon gu trì gairmean gu eisimpleir AWS Elasticsearch ann an àrainn mar elastic.spain.adevinta.comTaobh a-staigh nan soithichean a th’ againn tha slige ann, gus an urrainn dhuinn sgrùdadh a dhèanamh a bheil an rannsachadh fearainn a’ toirt ùine mhòr dha-rìribh.

Ceistean DNS bhon chontair:

[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 msec

Iarrtasan coltach ri seo bho aon de na h-eisimpleirean EC2 a tha a’ ruith an tagraidh:

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 msec

Leis gu bheil rannsachaidhean a’ toirt timcheall air 30ms, dh’fhàs e soilleir gu robh rùn DNS nuair a bha e a’ faighinn cothrom air Elasticsearch gu dearbh a’ cur ris an dàil a bha a’ sìor fhàs.

Ach, bha seo neònach airson dà adhbhar:

1. Tha tòrr aplacaidean Kubernetes againn mu thràth a bhios ag eadar-obrachadh le goireasan AWS gun dàil mhòr a bhith orra. Ge bith dè an adhbhar, tha e sònraichte don chùis seo.
2. Tha fios againn gu bheil an JVM a’ cur an gnìomh tasgadan DNS sa chuimhne. Anns na h-ìomhaighean againn, tha luach an TTL air a chòdachadh gu cruaidh ann an $JAVA_HOME/jre/lib/security/java.security agus suidhich gu 10 diogan: networkaddress.cache.ttl = 10Ann am faclan eile, bu chòir don JVM a h-uile ceist DNS a stòradh airson 10 diogan.

Gus a’ chiad bharail a dhearbhadh, chuir sinn romhainn rannsachaidhean DNS a dhì-cheadachadh airson ùine agus faicinn an rèiticheadh ​​an duilgheadas. An toiseach, smaoinich sinn air an aplacaid ath-rèiteachadh gus conaltradh le Elasticsearch gu dìreach tro sheòladh IP seach ainm an àrainn aige. Bhiodh seo air atharrachadh còd agus cleachdadh ùr a dhìth, agus mar sin dìreach mhapadh sinn an àrainn chun t-seòladh IP aige ann an /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

Fhuair an soitheach a sheòladh IP cha mhòr sa bhad. Mar thoradh air an seo, bha beagan leasachaidh ann, ach cha robh sinn ach beagan nas fhaisge air an ìre dàil a bha dùil. Ged a bha fuasgladh DNS a’ toirt ùine mhòr, cha robh an fhìor adhbhar fhathast ri lorg againn.

Diagnosachd lìonra

Cho-dhùin sinn an trafaic bhon chontair a sgrùdadh le bhith a’ cleachdadh tcpdumpgus sùil a chumail air dè dìreach a tha a’ tachairt air an lìonra:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

An uairsin chuir sinn cuid de dh’iarrtasan agus luchdaich sinn sìos an glacadh aca (kubectl cp my-service:/capture.pcap capture.pcap) airson tuilleadh mion-sgrùdaidh ann an Wireshark.

Cha robh dad amharasach mu na ceistean DNS (ach a-mhàin aon mhion-fhiosrachadh beag a bhruidhneas mi nas fhaide air adhart). Ach, bha beagan rudan neònach ann an mar a phròiseas an t-seirbheis againn gach iarrtas. Seo dealbh-sgrìn bho ghlacadh a’ sealltainn an iarrtas ga ghabhail mus do thòisich am freagairt:

Tha àireamhan nam pacaidean air an sealltainn sa chiad cholbh. Airson soilleireachd, tha mi air na diofar shruthan TCP a chomharrachadh ann an dath.

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’ chontair (172.17.36.147). Às dèidh a’ chiad chrathadh-làimhe (328-330), thug pacaid 331 HTTP GET /v1/.. — iarrtas a’ tighinn a-steach don t-seirbheis againn. Thug am pròiseas gu lèir 1 ms.

Tha an sruth liath (a’ tòiseachadh le pacaid 339) a’ sealltainn gun do chuir an t-seirbheis againn iarrtas HTTP chun an eisimpleir Elasticsearch (chan eil crathadh-làimhe TCP ann oir tha e a’ cleachdadh ceangal a tha ann mu thràth). Thug seo 18 ms.

Gu ruige seo tha a h-uile càil ceart gu leòr, agus tha na h-amannan faisg air a rèir nan 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 86 ms. Dè tha a’ dol air adhart an sin? 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 gu robh seo a rèir gach iarrtas tron ​​lorg. Gu dearbh, bha rùn DNS 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 gairmean chun t-seirbheis AWS Instance Metadata airson gach iarrtas a bha ag adhbhrachadh nan dàil mhòr.

Beachd-bharail 2: Cus ghairmean gu AWS

Buinidh an dà cheann-uidhe API Meata-dhàta Eisimpleir AWSBidh am microservice againn a’ cleachdadh na seirbheis seo nuair a bhios iad ag obair le Elasticsearch. Tha an dà ghairm nam pàirt den phròiseas ùghdarrachaidh bunaiteach. Bidh an ceann-uidhe a chaidh a chleachdadh rè an iarrtas tùsail a’ toirt seachad an dreuchd IAM co-cheangailte ris an eisimpleir.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

Bidh an dàrna iarrtas a’ cur fios chun dàrna ceann-uidhe airson ceadan sealach airson an eisimpleir 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 iad teisteanasan ùra fhaighinn bho àm gu àm (gus an tig an ceann-latha gu crìch). ExpirationTha am modail sìmplidh: bidh AWS gu tric a’ cuairteachadh iuchraichean sealach airson adhbharan tèarainteachd, ach faodaidh luchd-ceannach an stòradh san tasgadan airson beagan mhionaidean gus an cunnart coileanaidh a tha an lùib teisteanasan ùra fhaighinn a chothromachadh.

Bu chòir don AWS Java SDK uallach a ghabhail airson a’ phròiseas seo a chur air dòigh, ach airson adhbhar air choireigin chan eil seo a’ tachairt.

Às dèidh dhuinn sgrùdadh a dhèanamh air cùisean air GitHub, thachair sinn ri duilgheadas #1921Chuidich i sinn le bhith a’ dearbhadh an taobh anns am bu chòir dhuinn cladhach nas fhaide.

Bidh SDK AWS ag ùrachadh teisteanasan nuair a thachras aon de na cumhaichean a leanas:

• An ceann-latha crìochnachaidh aca (Expiration) a’ dol a-steach EXPIRATION_THRESHOLD, air a chòdachadh gu cruaidh gu 15 mionaidean.
• Tha barrachd ùine air a dhol seachad bhon oidhirp mu dheireadh air teisteanasan ùrachadh na tha REFRESH_THRESHOLD, air a chòdachadh gu cruaidh airson 60 mionaid.

Gus na cinn-latha crìochnachaidh a bh’ aig na teisteanasan a bha sinn a’ faighinn fhaicinn, ruith sinn na h-òrdughan cURL gu h-àrd bhon dà chuid an soitheach agus an eisimpleir EC2. Bha ceann-latha crìochnachaidh mòran nas giorra aig an teisteanas a fhuaireadh bhon t-soitheach: dìreach 15 mionaidean.

A-nis bha a h-uile càil soilleir: airson a’ chiad iarrtas, bha an t-seirbheis againn a’ faighinn teisteanasan sealach. Leis gun robh an ceann-latha crìochnachaidh aca cuibhrichte gu 15 mionaidean, bhiodh an AWS SDK gan ùrachadh air iarrtasan às dèidh sin. Agus thachair seo le gach iarrtas.

Carson a tha ùine dligheachd theisteanasan air fàs nas giorra?

Tha seirbheis Meata-dhàta Eisimpleirean AWS air a dhealbhadh gus obrachadh le eisimplearan EC2, chan e Kubernetes. Air an làimh eile, cha robh sinn airson eadar-aghaidh an tagraidh atharrachadh. Gus seo a choileanadh, chleachd sinn KIAM — inneal a leigeas le luchd-cleachdaidh (innleadairean a bhios a’ cur a-mach aplacaidean chun a’ chruinneachaidh) dreuchdan IAM a shònrachadh do shoithichean ann am pods mar gum biodh iad nan eisimpleirean EC2, le bhith a’ cleachdadh riochdairean air gach nód Kubernetes. Bidh KIAM a’ glacadh ghairmean chun t-seirbheis AWS Instance Metadata agus gan giullachd bhon tasgadan aige, às deidh dhaibh a bhith air an toirt bho AWS roimhe. Bho shealladh an aplacaid, chan eil dad ag atharrachadh.

Bidh KIAM a’ toirt seachad teisteanasan geàrr-ùine do phodan. Tha seo ciallach leis gu bheil fad-beatha cuibheasach pod nas giorra na fad-beatha eisimpleir EC2. Gu gnàthach, thig crìoch air teisteanasan. co-ionann ris an aon 15 mionaidean.

Mu dheireadh, bidh an dà roghainn bunaiteach seo a chur còmhla a’ cruthachadh duilgheadas. Bidh a h-uile teisteanas a thèid a thoirt do thagradh a’ tighinn gu crìch an dèidh 15 mionaidean. Bidh SDK Java AWS a’ sparradh ùrachadh air teisteanas sam bith aig a bheil nas lugha na 15 mionaidean air fhàgail gus an tig an crìoch air.

Mar thoradh air an sin, feumaidh an teisteanas sealach ùrachadh le gach iarrtas, agus tha sin a’ ciallachadh grunn ghairmean chun API AWS agus a’ meudachadh an dàil gu mòr. Lorg sinn seo ann an AWS Java SDK. iarrtas feart, a tha a’ toirt iomradh air duilgheadas coltach ris.

Thionndaidh am fuasgladh a-mach gu bhith sìmplidh. Rinn sinn ath-rèiteachadh air KIAM gus iarraidh air teisteanasan le amannan dligheachd nas fhaide. Cho luath ‘s a thachair seo, thòisich iarrtasan a’ dol air adhart às aonais seirbheis AWS Metadata, agus thuit an dàil gu ìrean eadhon nas ìsle na ann an EC2.

toraidhean

A rèir ar n-eòlais le imrichean, chan e biastagan ann an Kubernetes no eileamaidean àrd-ùrlair eile aon de na stòran dhuilgheadasan as cumanta. Agus chan eil e co-cheangailte ri lochdan bunaiteach sam bith anns na microservices a tha sinn a’ gluasad. Bidh duilgheadasan gu tric ag èirigh dìreach air sgàth 's gu bheil sinn a' cur diofar eileamaidean ri chèile.

Bidh sinn a’ measgachadh shiostaman iom-fhillte nach do rinn eadar-obrachadh le chèile a-riamh roimhe, an dùil gum bi iad a’ cruthachadh aon shiostam nas motha. Gu mì-fhortanach, mar as motha de eileamaidean, ’s ann as motha an comas airson mearachd agus ’s ann as àirde an entropy.

Nar cùis-ne, cha robh an dàil àrd mar thoradh air biastagan no droch cho-dhùnaidhean ann an Kubernetes, KIAM, an AWS Java SDK, no ar microservice. B’ e toradh dà shuidheachadh bunaiteach neo-eisimeileach a bh’ ann: aon ann an KIAM agus aon ann an AWS Java SDK. Leotha fhèin, tha ciall anns an dà shuidheachadh: am poileasaidh ùrachaidh teisteanas gnìomhach ann an AWS Java SDK agus an ùine ghoirid crìochnachaidh teisteanas ann an KAIM. Ach nuair a thèid an cur còmhla, bidh na toraidhean do-sheachanta. Chan eil dà fhuasgladh neo-eisimeileach agus loidsigeach gu riatanach a’ dèanamh ciall nuair a thèid an cur còmhla.

PS bhon eadar-theangair

Faodaidh tu barrachd ionnsachadh mu ailtireachd goireas KIAM airson AWS IAM a thoirt còmhla ri Kubernetes ann an an artaigil seo bho na luchd-cruthachaidh aige.

Agus anns a’ bhlog againn, faodaidh tu cuideachd leughadh:

• «3 Sgeulachdan mu Fhàilligeadh Riochdachaidh Kubernetes: Anti-affinity, Graceful Shutdown, agus Webhook";
• «Mar a dh’ adhbhraich prìomhachasan pod ann an Kubernetes ùine downt aig Grafana Labs";
• «6 bugaichean siostam aoigheachd ann an obrachadh Kubernetes [agus am fuasgladh]";
• «6 sgeulachdan practaigeach bho ar beatha làitheil SRE".

Source: www.habr.com