Remak. trad.: Atik sa a, ekri pa Galo Navarro, ki moun ki kenbe pozisyon nan Enjenyè Software Prensipal nan konpayi Ewopeyen an Adevinta, se yon "ankèt" kaptivan ak enstriktif nan jaden an nan operasyon enfrastrikti. Tit orijinal li te yon ti kras elaji nan tradiksyon pou yon rezon ke otè a eksplike nan kòmansman an anpil.
Remak nan men otè a: Sanble pòs sa a pi plis atansyon pase espere. Mwen toujou resevwa kòmantè fache ke tit la nan atik la se twonpe ak ke kèk lektè yo tris. Mwen konprann rezon ki fè sa k ap pase a, se poutèt sa, malgre risk pou yo ruine konplote a tout antye, mwen vle imedyatman di ou ki sa atik sa a se sou. Yon bagay kirye mwen te wè pandan ekip yo imigre nan Kubernetes se ke chak fwa yon pwoblèm rive (tankou ogmante latansi apre yon migrasyon), premye bagay ki vin blame se Kubernetes, men Lè sa a, li vire soti ke orchestrator a se pa reyèlman. blame. Atik sa a pale de yon ka konsa. Non li repete eksklamasyon youn nan devlopè nou yo (pita ou pral wè ke Kubernetes pa gen anyen fè ak li). Ou pa pral jwenn okenn revelasyon etone sou Kubernetes isit la, men ou ka atann yon koup nan leson bon sou sistèm konplèks.
Sa gen yon koup de semèn, ekip mwen an t ap emigre yon sèl mikwosèvis nan yon platfòm debaz ki gen ladan CI/CD, yon ègzekutabl ki baze sou Kubernetes, mezi, ak lòt bagay. Mouvman an te yon nati esè: nou te planifye pou pran li kòm yon baz epi transfere apeprè 150 plis sèvis nan mwa kap vini yo. Yo tout responsab pou operasyon kèk nan pi gwo platfòm sou entènèt nan peyi Espay (Infojobs, Fotocasa, elatriye).
Apre nou te deplwaye aplikasyon an nan Kubernetes ak redireksyon kèk trafik sou li, yon sipriz alarmant t ap tann nou. Reta (latansi) demann nan Kubernetes yo te 10 fwa pi wo pase nan EC2. An jeneral, li te nesesè swa jwenn yon solisyon a pwoblèm sa a, oswa abandone migrasyon an nan mikwosèvis la (e, pètèt, tout pwojè a).
Poukisa latansi tèlman pi wo nan Kubernetes pase nan EC2?
Pou jwenn blokaj la, nou kolekte mezi sou tout chemen demann lan. Achitekti nou an senp: yon pòtay API (Zuul) voye demann nan ka mikwosèvis nan EC2 oswa Kubernetes. Nan Kubernetes nou itilize NGINX Ingress Controller, ak backend yo se objè òdinè tankou ak yon aplikasyon JVM sou platfòm Spring.
EC2
+---------------+
| +---------+ |
| | | |
+-------> BACKEND | |
| | | | |
| | +---------+ |
| +---------------+
+------+ |
Public | | |
-------> ZUUL +--+
traffic | | | Kubernetes
+------+ | +-----------------------------+
| | +-------+ +---------+ |
| | | | xx | | |
+-------> NGINX +------> BACKEND | |
| | | xx | | |
| +-------+ +---------+ |
+-----------------------------+Pwoblèm nan te sanble yo gen rapò ak premye latansi nan backend la (mwen make zòn nan pwoblèm sou graf la kòm "xx"). Sou EC2, repons aplikasyon an te pran apeprè 20 ms. Nan Kubernetes, latansi a ogmante a 100-200 ms.
Nou byen vit ranvwaye sispèk ki gen anpil chans ki gen rapò ak chanjman nan ègzekutabl. Vèsyon JVM a rete menm jan an. Pwoblèm kontenèrizasyon tou pa te gen anyen fè ak li: aplikasyon an te deja kouri avèk siksè nan resipyan sou EC2. Chaje? Men, nou te obsève gwo latans menm nan 1 demann pou chak segonn. Poz pou koleksyon fatra ta ka neglije tou.
Youn nan administratè Kubernetes nou yo te mande si aplikasyon an te gen depandans ekstèn paske demann DNS te lakòz pwoblèm ki sanble nan tan lontan an.
Ipotèz 1: rezolisyon non DNS
Pou chak demann, aplikasyon nou an jwenn aksè nan yon egzanp AWS Elasticsearch youn a twa fwa nan yon domèn tankou elastic.spain.adevinta.com. Anndan kontenè nou yo , pou nou ka tcheke si chèche yon domèn aktyèlman pran yon bon bout tan.
Rekèt DNS soti nan veso:
[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 msecDemann menm jan an soti nan youn nan ka EC2 kote aplikasyon an ap kouri:
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 msecLè ou konsidere ke rechèch la te pran apeprè 30ms, li te vin klè ke rezolisyon DNS lè w te jwenn aksè nan Elasticsearch te tout bon kontribye nan ogmantasyon nan latansi.
Sepandan, sa a te etranj pou de rezon:
- Nou deja gen yon tòn aplikasyon Kubernetes ki kominike avèk resous AWS san yo pa soufri gwo latansi. Kèlkeswa rezon an, li gen rapò espesyalman nan ka sa a.
- Nou konnen ke JVM a fè nan memwa DNS kachèt. Nan imaj nou yo, valè TTL ekri nan
$JAVA_HOME/jre/lib/security/java.securityepi mete sou 10 segonn:networkaddress.cache.ttl = 10. Nan lòt mo, JVM a ta dwe kache tout demann DNS pou 10 segonn.
Pou konfime premye ipotèz la, nou deside sispann rele DNS pou yon ti tan epi wè si pwoblèm nan ale. Premyèman, nou te deside reconfigure aplikasyon an pou ke li kominike dirèkteman ak Elasticsearch pa adrès IP, olye ke atravè yon non domèn. Sa a ta mande chanjman kòd ak yon nouvo deplwaman, kidonk nou tou senpleman trase domèn nan adrès IP li yo /etc/hosts:
34.55.5.111 elastic.spain.adevinta.comKoulye a, veso a te resevwa yon IP prèske imedyatman. Sa a te lakòz kèk amelyorasyon, men nou te sèlman yon ti kras pi pre nivo latansi yo te espere yo. Malgre ke rezolisyon DNS te pran yon bon bout tan, rezon reyèl la toujou evite nou.
Dyagnostik atravè rezo a
Nou deside analize trafik soti nan veso a lè l sèvi avèk tcpdumpPou wè sa egzakteman k ap pase sou rezo a:
[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap
Lè sa a, nou te voye plizyè demann epi telechaje kapti yo (kubectl cp my-service:/capture.pcap capture.pcap) pou plis analiz nan .
Pa te gen anyen ki sispèk sou demann DNS yo (eksepte yon ti bagay ke mwen pral pale sou pita). Men, te gen sèten bizarre nan fason sèvis nou an te okipe chak demann. Anba a se yon Ekran nan kapti a ki montre demann lan yo te aksepte anvan repons lan kòmanse:
Nimewo pake yo montre nan premye kolòn nan. Pou klè, mwen te kode koulè diferan koule TCP yo.
Kouran vèt la kòmanse ak pake 328 montre kijan kliyan an (172.17.22.150) te etabli yon koneksyon TCP ak veso a (172.17.36.147). Apre premye lanmen (328-330), pake 331 te pote HTTP GET /v1/.. — yon demann fèk ap rantre nan sèvis nou an. Tout pwosesis la te pran 1 ms.
Kouran an gri (ki soti nan pake 339) montre ke sèvis nou an te voye yon demann HTTP bay egzanp Elasticsearch la (pa gen okenn TCP lanmen paske li ap itilize yon koneksyon ki deja egziste). Sa te pran 18ms.
Jiskaprezan tout bagay anfòm, ak fwa yo apeprè koresponn ak reta yo espere (20-30 ms lè yo mezire nan men kliyan an).
Sepandan, seksyon ble a pran 86ms. Kisa k ap pase ladan l? Avèk pake 333, sèvis nou an voye yon demann HTTP GET bay /latest/meta-data/iam/security-credentials, epi imedyatman apre li, sou menm koneksyon TCP a, yon lòt demann GET a /latest/meta-data/iam/security-credentials/arn:...
Nou te jwenn ke sa a repete ak chak demann nan tout tras la. Rezolisyon DNS se vre yon ti kras pi dousman nan resipyan nou yo (eksplikasyon an pou fenomèn sa a se byen enteresan, men mwen pral sove li pou yon atik separe). Li te tounen soti ke kòz la nan reta yo long sete apèl nan sèvis la Metadata Instance AWS sou chak demann.
Ipotèz 2: apèl pa nesesè pou AWS
Tou de pwen final yo fè pati . Mikwosèvis nou an sèvi ak sèvis sa a pandan w ap kouri Elasticsearch. Tou de apèl yo fè pati pwosesis otorizasyon debaz la. Pwen final la ki jwenn aksè nan premye demann la bay wòl IAM ki asosye ak egzanp lan.
/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_roleDezyèm demann lan mande dezyèm pwen final la pou otorizasyon tanporè pou egzanp sa a:
/ # 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"
}
Kliyan an ka sèvi ak yo pou yon kout peryòd de tan epi li dwe detanzantan jwenn nouvo sètifika (anvan yo Expiration). Modèl la senp: AWS wotasyon kle tanporè souvan pou rezon sekirite, men kliyan yo ka kache yo pou kèk minit pou konpanse penalite pèfòmans ki asosye ak jwenn nouvo sètifika.
AWS Java SDK ta dwe pran responsablite pou òganize pwosesis sa a, men pou kèk rezon sa a pa rive.
Apre rechèch pwoblèm sou GitHub, nou te rankontre yon pwoblèm . Li te ede nou detèmine direksyon nan ki pou "fouye" pi lwen.
AWS SDK mete ajou sètifika yo lè youn nan kondisyon sa yo rive:
- Dat ekspirasyon (
Expiration) Tonbe nanEXPIRATION_THRESHOLD, hardcoded pou 15 minit. - Plis tan pase depi dènye tantativ pou renouvle sètifika pase
REFRESH_THRESHOLD, hardcoded pou 60 minit.
Pou wè dat ekspirasyon aktyèl sètifika nou resevwa yo, nou te kouri kòmandman cURL ki anwo yo soti nan veso a ak egzanp EC2 la. Peryòd validite sètifika a te resevwa nan men veso a te vin pi kout: egzakteman 15 minit.
Koulye a, tout bagay te vin klè: pou premye demann lan, sèvis nou an te resevwa sètifika tanporè. Kòm yo pa te valab pou plis pase 15 minit, AWS SDK ta deside mete ajou yo sou yon demann ki vin apre. Ak sa a te rive ak chak demann.
Poukisa peryòd validite sètifika yo vin pi kout?
AWS Instance Metadata fèt pou travay avèk enstans EC2, pa Kubernetes. Nan lòt men an, nou pa t 'vle chanje koòdone aplikasyon an. Pou sa nou te itilize - yon zouti ki, lè l sèvi avèk ajan sou chak ne Kubernetes, pèmèt itilizatè yo (enjenyè deplwaye aplikasyon nan yon gwoup) bay wòl IAM nan resipyan ki nan gous tankou si yo te ka EC2. KIAM entèsepte apèl nan sèvis Metadata Instance AWS la epi trete yo nan kachèt li yo, li te deja resevwa yo nan men AWS. Soti nan pwen de vi aplikasyon an, pa gen anyen ki chanje.
KIAM bay gous sètifika a kout tèm. Sa fè sans lè nou konsidere ke lavi mwayèn yon gous pi kout pase sa yon egzanp EC2. Peryòd validite default pou sètifika yo .
Kòm yon rezilta, si ou kouvri tou de valè default youn sou lòt, yon pwoblèm rive. Chak sètifika yo bay yon aplikasyon ekspire apre 15 minit. Sepandan, AWS Java SDK fòse yon renouvèlman nenpòt sètifika ki gen mwens pase 15 minit kite anvan dat ekspirasyon li.
Kòm yon rezilta, sètifika tanporè a fòse yo dwe renouvle ak chak demann, ki enplike yon koup nan apèl nan AWS API a ak lakòz yon ogmantasyon siyifikatif nan latansi. Nan AWS Java SDK nou jwenn , ki mansyone yon pwoblèm menm jan an.
Solisyon an te tounen senp. Nou senpleman reconfigure KIAM pou mande sètifika ak yon peryòd validite pi long. Yon fwa sa a te rive, demann yo te kòmanse koule san patisipasyon sèvis AWS Metadata, ak latansi a tonbe nan nivo menm pi ba pase nan EC2.
Jwenn
Dapre eksperyans nou ak migrasyon, youn nan sous pwoblèm ki pi komen yo se pa pinèz nan Kubernetes oswa lòt eleman nan platfòm la. Epitou, li pa adrese okenn defo fondamantal nan mikwosèvis n ap pote yo. Pwoblèm souvan rive tou senpleman paske nou mete diferan eleman ansanm.
Nou melanje ansanm sistèm konplèks ki pa janm kominike youn ak lòt anvan, nou espere ke ansanm yo pral fòme yon sèl, pi gwo sistèm. Ay, plis eleman, plis plas pou erè, se pi wo entropi a.
Nan ka nou an, gwo latansi a pa te rezilta ensèk oswa move desizyon nan Kubernetes, KIAM, AWS Java SDK, oswa mikwosèvis nou an. Se te rezilta konbine de paramèt default endepandan: youn nan KIAM, lòt la nan AWS Java SDK. Pran separeman, tou de paramèt yo gen sans: politik renouvèlman sètifika aktif nan AWS Java SDK, ak peryòd validite kout sètifika nan KAIM. Men, lè ou mete yo ansanm, rezilta yo vin enprevizib. De solisyon endepandan ak lojik pa gen sans lè konbine.
PS soti nan tradiktè
Ou ka aprann plis sou achitekti sèvis piblik KIAM pou entegre AWS IAM ak Kubernetes nan soti nan kreyatè li yo.
Li tou sou blog nou an:
- «";
- «";
- «";
- «'.
Sous: www.habr.com