"Ang mga Kubernetes nagdugang sa latency sa 10 ka beses": kinsa ang mabasol niini?

Nota. transl.: Kini nga artikulo, nga gisulat ni Galo Navarro, kinsa naghupot sa posisyon sa Principal Software Engineer sa European nga kompanya nga Adevinta, usa ka makaiikag ug matulon-anon nga "imbistigasyon" sa natad sa mga operasyon sa imprastraktura. Ang orihinal nga titulo niini gamay nga gipalapdan sa paghubad tungod sa usa ka hinungdan nga gipatin-aw sa tagsulat sa sinugdanan.

Pahinumdom gikan sa tagsulat: Morag kini nga post nadani labi pa nga atensyon kaysa gipaabut. Nasuko gihapon ko sa mga komento nga ang ulohan sa artikulo nagpahisalaag ug nga ang pipila ka mga magbabasa nasubo. Nasabtan nako ang mga hinungdan sa kung unsa ang nanghitabo, busa, bisan pa sa peligro nga makaguba sa tibuuk nga intriga, gusto nako nga isulti dayon kanimo kung unsa kini nga artikulo. Usa ka katingad-an nga butang nga akong nakita samtang ang mga team migrate sa Kubernetes mao nga kung adunay problema nga moabut (sama sa pagtaas sa latency pagkahuman sa usa ka paglalin), ang una nga butang nga mabasol mao ang Kubernetes, apan kini nahimo nga ang orkestra dili gyud pagbasol. Kini nga artikulo naghisgot bahin sa usa sa ingon nga kaso. Gisubli sa ngalan niini ang pagtuaw sa usa sa among mga developer (sa ulahi imong makita nga ang Kubernetes walay labot niini). Dili nimo makit-an ang bisan unsang katingad-an nga mga pagpadayag bahin sa Kubernetes dinhi, apan mahimo nimong mapaabut ang usa ka pares nga maayong mga leksyon bahin sa komplikado nga mga sistema.

Pipila ka semana ang milabay, ang akong team mibalhin sa usa ka microservice ngadto sa usa ka kinauyokan nga plataporma nga naglakip sa CI/CD, usa ka Kubernetes-based runtime, metrics, ug uban pang mga maayong butang. Ang lakang kay usa ka pagsulay nga kinaiya: nagplano kami nga himoon kini nga basehan ug ibalhin ang gibana-bana nga 150 pa nga mga serbisyo sa umaabot nga mga bulan. Silang tanan ang responsable sa operasyon sa pipila sa pinakadako nga online platform sa Spain (Infojobs, Fotocasa, etc.).

Human namo ma-deploy ang aplikasyon sa Kubernetes ug ma-redirect ang pipila ka trapiko niini, usa ka makapakurat nga surpresa ang naghulat kanamo. Paglangan (latency) ang mga hangyo sa Kubernetes 10 ka pilo nga mas taas kaysa sa EC2. Sa kinatibuk-an, kinahanglan nga mangita usa ka solusyon sa kini nga problema, o biyaan ang paglalin sa microservice (ug, posible, ang tibuuk nga proyekto).

Ngano nga mas taas ang latency sa Kubernetes kaysa sa EC2?

Aron makit-an ang bottleneck, gikolekta namon ang mga sukatan sa tibuuk nga agianan sa paghangyo. Ang among arkitektura yano ra: ang usa ka API gateway (Zuul) naghangyo sa mga proxy sa mga microservice nga mga higayon sa EC2 o Kubernetes. Sa Kubernetes gigamit namo ang NGINX Ingress Controller, ug ang mga backend kay ordinaryo nga mga butang sama deployment nga adunay JVM nga aplikasyon sa Spring platform.

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

Ang problema daw may kalabutan sa inisyal nga latency sa backend (gimarkahan nako ang problema nga lugar sa graph isip "xx"). Sa EC2, ang tubag sa aplikasyon gikuha mga 20ms. Sa Kubernetes, ang latency misaka ngadto sa 100-200 ms.

Dali namong gibasura ang posibleng mga suspek nga may kalabutan sa pagbag-o sa runtime. Ang JVM nga bersyon nagpabilin nga pareho. Ang mga problema sa containerization wala usab labot niini: ang aplikasyon malampuson nga nagdagan sa mga sudlanan sa EC2. Nagkarga? Apan among naobserbahan ang taas nga latency bisan sa 1 nga hangyo matag segundo. Ang mga paghunong sa pagkolekta sa basura mahimo usab nga mapasagdan.

Usa sa among mga admin sa Kubernetes naghunahuna kung ang aplikasyon adunay mga eksternal nga dependency tungod kay ang mga pangutana sa DNS nagpahinabog parehas nga mga isyu kaniadto.

Hypothesis 1: resolusyon sa ngalan sa DNS

Alang sa matag hangyo, ang among aplikasyon nag-access sa usa ka pananglitan sa AWS Elasticsearch usa hangtod tulo ka beses sa usa ka domain sama elastic.spain.adevinta.com. Sulod sa among mga sudlanan naay kabhang, aron atong masusi kung ang pagpangita sa usa ka domain sa tinuud nagkinahanglag taas nga panahon.

Mga pangutana sa DNS gikan sa sudlanan:

[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

Susama nga mga hangyo gikan sa usa sa mga higayon sa EC2 diin ang aplikasyon nagdagan:

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

Sa pagkonsiderar nga ang pagpangita gikuha mga 30ms, nahimo nga tin-aw nga ang resolusyon sa DNS sa pag-access sa Elasticsearch sa tinuud nakatampo sa pagtaas sa latency.

Bisan pa, kini katingad-an tungod sa duha ka hinungdan:

1. Naa na kami usa ka tonelada nga aplikasyon sa Kubernetes nga nakig-uban sa mga kapanguhaan sa AWS nga wala mag-antos sa taas nga latency. Bisan unsa pa ang hinungdan, kini adunay kalabotan sa kini nga kaso.
2. Nahibal-an namon nga ang JVM naghimo sa in-memory DNS caching. Sa among mga imahe, ang kantidad sa TTL gisulat sa $JAVA_HOME/jre/lib/security/java.security ug ibutang sa 10 segundos: networkaddress.cache.ttl = 10. Sa laing pagkasulti, ang JVM kinahanglan nga mag-cache sa tanan nga mga pangutana sa DNS sulod sa 10 segundos.

Aron makumpirma ang una nga hypothesis, nakahukom kami nga hunongon ang pagtawag sa DNS sa makadiyot ug tan-awon kung nawala ba ang problema. Una, nakahukom kami nga i-reconfigure ang aplikasyon aron direktang makigkomunikar sa Elasticsearch pinaagi sa IP address, imbes pinaagi sa domain name. Nagkinahanglan kini og mga pagbag-o sa code ug bag-ong deployment, mao nga gimapa lang namo ang domain sa IP address niini /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

Karon ang sudlanan nakadawat usa ka IP hapit dayon. Miresulta kini sa pipila ka pag-uswag, apan mas duol ra kami gamay sa gipaabot nga lebel sa latency. Bisan kung ang resolusyon sa DNS dugay nga panahon, ang tinuud nga hinungdan nakalikay gihapon kanamo.

Diagnostics pinaagi sa network

Nakahukom kami nga analisahon ang trapiko gikan sa gigamit nga sudlanan tcpdumparon makita kung unsa gyud ang nahitabo sa network:

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

Nagpadala kami og daghang mga hangyo ug gi-download ang ilang pagkadakop (kubectl cp my-service:/capture.pcap capture.pcap) alang sa dugang nga pagtuki sa Wireshark.

Walay bisan unsa nga kadudahan bahin sa mga pangutana sa DNS (gawas sa usa ka gamay nga butang nga akong hisgutan sa ulahi). Apan adunay pipila ka mga katingad-an sa paagi sa pagdumala sa among serbisyo sa matag hangyo. Sa ubos usa ka screenshot sa pagkuha nga nagpakita sa hangyo nga gidawat sa wala pa magsugod ang tubag:

Ang mga numero sa package gipakita sa unang kolum. Alang sa katin-awan, gi-koloran nako ang lainlaing mga sapa sa TCP.

Ang berde nga sapa nga nagsugod sa packet 328 nagpakita kung giunsa ang kliyente (172.17.22.150) nagtukod og koneksyon sa TCP sa sudlanan (172.17.36.147). Human sa inisyal nga paglamano (328-330), gidala ang package 331 HTTP GET /v1/.. — usa ka umaabot nga hangyo sa among serbisyo. Ang tibuok proseso mikuha ug 1 ms.

Ang gray nga sapa (gikan sa packet 339) nagpakita nga ang among serbisyo nagpadala og HTTP nga hangyo sa Elasticsearch nga pananglitan (walay TCP handshake tungod kay kini naggamit sa kasamtangan nga koneksyon). Nagkinahanglan kini og 18 ms.

Sa pagkakaron maayo ang tanan, ug ang mga oras halos katumbas sa gipaabot nga mga paglangan (20-30 ms kung gisukod gikan sa kliyente).

Bisan pa, ang asul nga seksyon nagkinahanglan og 86ms. Unsa may nahitabo niini? Uban sa packet 333, ang among serbisyo nagpadala ug HTTP GET nga hangyo sa /latest/meta-data/iam/security-credentials, ug pagkahuman niini, sa parehas nga koneksyon sa TCP, lain nga GET nga hangyo sa /latest/meta-data/iam/security-credentials/arn:...

Among nakita nga kini gisubli sa matag hangyo sa tibuok pagsubay. Ang resolusyon sa DNS sa tinuud usa ka gamay nga hinay sa among mga sudlanan (ang pagpatin-aw alang niini nga panghitabo medyo makapaikag, apan itago ko kini alang sa usa ka lahi nga artikulo). Nahibal-an nga ang hinungdan sa taas nga mga paglangan mao ang mga tawag sa serbisyo sa AWS Instance Metadata sa matag hangyo.

Hypothesis 2: wala kinahanglana nga mga tawag sa AWS

Ang duha ka endpoint iya sa AWS Instance Metadata API. Gigamit sa among microservice kini nga serbisyo samtang nagpadagan sa Elasticsearch. Ang duha ka tawag kabahin sa batakang proseso sa pagtugot. Ang endpoint nga na-access sa unang hangyo nag-isyu sa papel sa IAM nga nalangkit sa instance.

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

Ang ikaduha nga hangyo nangutana sa ikaduha nga endpoint alang sa temporaryo nga mga pagtugot alang niini nga higayon:

/ # 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"
}

Mahimong gamiton kini sa kliyente sa mubo nga panahon ug kinahanglan nga matag karon ug unya makakuha mga bag-ong sertipiko (sa wala pa kini Expiration). Ang modelo yano ra: Ang AWS nagtuyok sa temporaryo nga mga yawe kanunay alang sa mga hinungdan sa seguridad, apan ang mga kliyente mahimo’g i-cache kini sa pipila ka minuto aron mabayran ang silot sa pasundayag nga may kalabotan sa pagkuha og bag-ong mga sertipiko.

Ang AWS Java SDK kinahanglan nga mopuli sa responsibilidad sa pag-organisar niini nga proseso, apan sa pipila ka rason kini dili mahitabo.

Pagkahuman sa pagpangita sa mga isyu sa GitHub, nakit-an namon ang usa ka problema #1921. Gitabangan niya kami sa pagtino sa direksyon kung asa "pagkalot" pa.

Ang AWS SDK nag-update sa mga sertipiko kung ang usa sa mosunod nga mga kondisyon mahitabo:

• Petsa sa pag-expire (Expiration) Nahulog sa EXPIRATION_THRESHOLD, hardcoded sa 15 minutos.
• Daghang oras ang milabay sukad sa katapusang pagsulay sa pag-renew sa mga sertipiko kaysa REFRESH_THRESHOLD, gi-hardcode sulod sa 60 minutos.

Aron makita ang aktuwal nga expiration date sa mga sertipiko nga among nadawat, among gipadagan ang mga sugo sa ibabaw nga cURL gikan sa sudlanan ug sa EC2 nga pananglitan. Ang balido nga panahon sa sertipiko nga nadawat gikan sa sudlanan nahimo nga labi ka mubu: eksakto nga 15 minuto.

Karon ang tanan nahimong klaro: alang sa unang hangyo, ang among serbisyo nakadawat temporaryo nga mga sertipiko. Tungod kay dili sila balido sa sobra sa 15 ka minuto, ang AWS SDK magdesisyon nga i-update kini sa sunod nga hangyo. Ug kini nahitabo sa matag hangyo.

Ngano nga ang balido nga panahon sa mga sertipiko nahimong mas mubo?

Ang AWS Instance Metadata gidesinyo sa pagtrabaho uban sa EC2 instances, dili sa Kubernetes. Sa laing bahin, dili namo gusto nga usbon ang interface sa aplikasyon. Alang niini among gigamit KIAM - usa ka himan nga, gamit ang mga ahente sa matag Kubernetes node, nagtugot sa mga tiggamit (mga inhenyero nga nag-deploy sa mga aplikasyon ngadto sa usa ka cluster) sa pag-assign sa mga tahas sa IAM ngadto sa mga sudlanan sa mga pod nga daw mga EC2 nga mga higayon. Gibabagan sa KIAM ang mga tawag sa serbisyo sa AWS Instance Metadata ug giproseso kini gikan sa cache niini, nga nadawat kini kaniadto gikan sa AWS. Gikan sa punto sa aplikasyon, wala’y pagbag-o.

Ang KIAM nagsuplay og mga short-term nga sertipiko sa mga pod. Makataronganon kini nga gikonsiderar nga ang kasagaran nga lifespan sa usa ka pod mas mubo kaysa usa ka EC2 nga pananglitan. Default nga panahon sa balido alang sa mga sertipiko katumbas sa parehas nga 15 minuto.

Ingon usa ka sangputanan, kung imong gi-overlay ang duha nga mga default nga kantidad sa usag usa, usa ka problema ang motungha. Ang matag sertipiko nga gihatag sa usa ka aplikasyon matapos pagkahuman sa 15 minuto. Bisan pa, ang AWS Java SDK nagpugos sa pagbag-o sa bisan unsang sertipiko nga wala’y 15 minuto ang nahabilin sa wala pa ang petsa sa pag-expire niini.

Ingon usa ka sangputanan, ang temporaryo nga sertipiko napugos nga mabag-o sa matag hangyo, nga nag-apil sa usa ka pares nga tawag sa AWS API ug hinungdan sa usa ka hinungdanon nga pagtaas sa latency. Sa AWS Java SDK among nakit-an hangyo sa bahin, nga naghisgot ug susamang problema.

Ang solusyon nahimong yano. Gi-reconfigure lang namo ang KIAM aron mangayo og mga sertipiko nga adunay mas taas nga panahon sa balido. Sa diha nga kini nahitabo, ang mga hangyo misugod sa pagdagayday nga walay pag-apil sa AWS Metadata nga serbisyo, ug ang latency mikunhod ngadto sa mas ubos nga lebel kaysa sa EC2.

kaplag

Base sa among kasinatian sa mga paglalin, usa sa kasagarang tinubdan sa mga problema dili mga bug sa Kubernetes o ubang elemento sa plataporma. Wala usab kini nagtubag sa bisan unsang sukaranan nga mga sayup sa mga microservice nga among gi-port. Ang mga problema kasagarang motungha tungod lang kay atong gihiusa ang lainlaing mga elemento.

Gisagol namo ang mga komplikadong sistema nga wala pa sukad makig-interact sa usag usa, nga nagpaabot nga magkauban sila nga magporma og usa, mas dako nga sistema. Alaut, ang daghang mga elemento, ang labi nga lugar alang sa mga sayup, labi ka taas ang entropy.

Sa among kaso, ang taas nga latency dili resulta sa mga bug o dili maayo nga mga desisyon sa Kubernetes, KIAM, AWS Java SDK, o among microservice. Kini ang resulta sa paghiusa sa duha ka independente nga default setting: ang usa sa KIAM, ang lain sa AWS Java SDK. Gilain nga gikuha, ang duha nga mga parameter adunay kahulugan: ang aktibo nga palisiya sa pagbag-o sa sertipiko sa AWS Java SDK, ug ang mubo nga panahon sa pagkabalido sa mga sertipiko sa KAIM. Apan kung imong gihiusa kini, ang mga sangputanan mahimong dili matag-an. Ang duha ka independente ug lohikal nga mga solusyon dili kinahanglan nga adunay kahulugan kung gihiusa.

PS gikan sa tighubad

Makakat-on ka og dugang mahitungod sa arkitektura sa KIAM utility para sa paghiusa sa AWS IAM sa Kubernetes sa kini nga artikulo gikan sa mga magbubuhat niini.

Basaha usab sa among blog:

• «3 ka istorya sa mga kapakyasan sa Kubernetes sa produksiyon: anti-affinity, graceful shutdown, webhook";
• «Giunsa pod ang mga prayoridad sa Kubernetes hinungdan sa downtime sa Grafana Labs";
• «6 makapaikag nga mga bug sa sistema kung gigamit ang Kubernetes [ug ilang mga solusyon]";
• «6 praktikal nga mga istorya gikan sa among SRE matag adlaw nga kinabuhi".

Source: www.habr.com