„Kubernetes suurendas viivitust 10 korda“: kes on selle eest vastutav?

Märkus tõlke kohta.: See artikkel, mille autor on Galo Navarro, Euroopa ettevõtte Adevinta peamine tarkvarainsener, on põnev ja hariv "uurimine" infrastruktuuri haldamise valdkonnas. Selle algne pealkiri on tõlkes mõnevõrra täiendatud põhjusel, mille selgitab autor artikli alguses.

Autori märkus: Tundub, et see postitus meelitas palju rohkem tähelepanu, kui oodatud. Ma saan endiselt pahaseid kommentaare selle kohta, et artikli pealkiri on eksitav ja et mõned lugejad on kurvad. Ma mõistan, mis toimub, seetõttu, hoolimata riski kaotada kogu intrigeerivus, tahan kohe rääkida, millest see artikkel räägib. Kui meeskonnad liiguvad Kubernetesesse, näen huvitavat asja: igal korral, kui tekib probleem (näiteks viivituste suurenemine pärast migratsiooni), süüdistatakse esmalt Kuberneteset, kuid hiljem selgub, et orkestraator pole tegelikult süüdi. See artikkel räägib ühest sellisest juhtumist. Selle pealkiri kordab ühte meie arendaja hüüatust (hiljem saate veenduda, et Kubernetes pole siin sugugi süüdi). Siit leiate mitte üllatavaid äratundeid Kubernetesest, kuid võite oodata paar head õppetundi keeruliste süsteemide kohta.

Paari nädala eest tegeles mu meeskond ühe mikroteenuse migreerimisega peamisele platvormile, mis hõlmab CI/CD, Kubernetesel põhinevat töökeskkonda, mõõdikuid ja muid kasulikke funktsioone. Veebisait oli katsekorral: plaanisime selle aluseks võtta ja migreerida veel umbes 150 teenust järgnevate kuude jooksul. Kõik need teenused vastutavad mõnede suurimate Interneti-platvormide nagu Infojobs, Fotocasa jne toimimise eest.

Pärast rakenduse käivitamist Kuberneteses ja osa liikluse suunamist selle suunas ootab meid murettekitav üllatus. Viivitus (latency) Kuberneteses oli 10 korda kõrgem, kui EC2-s. Üldiselt oli vajalik kas selle probleemi lahendamine või mikroteenusest loobumine (ja võib-olla ka kogu projektist).

Miks on viivitus Kuberneteses nii palju kõrgem kui EC2-s?

Selle kitsaskoha leidmiseks kogusime mõõdikud kogu päringu teekonnalt. Meie arhitektuur on lihtne: API-läbipääs (Zuul) vahendab päringud mikroteenuse eksemplaridele EC2-s või Kuberneteses. Kuberneteses kasutame NGINX Ingress Controllerit, samas kui taustsüsteemid koosnevad tavalistest objektidest, Deployment millel on JVM-rakendus Springi platvormil.

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

Tundus, et probleem oli seotud algse tööfaasi viivitusega backend'is (markeerisin probleemse ala graafikul kui «хх»). EC2-s oli rakenduse vastus umbes 20 ms. Kuberneteses kasvas viivitus 100–200 ms-eni.

Viskasime kiiresti kõrvale kahtlusalused, mis olid seotud teostuskeskkonna vahetamisega. JVM versioon jäi muutumatuks. Konteinerimise probleemid ei olnud samuti mängus: rakendus töötas juba edukalt konteinerites EC2-s. Koormus? Aga me märkasime kõrgeid viivitusi isegi 1 päringu sekundis. Pausid prügikogu kogumise ajal saadi samuti välistada.

Üks meie Kubernetes administraatoreid küsis, kas rakendusel on väliseid sõltuvusi, kuna minevikus on DNS päringud tekitanud sarnaseid probleeme.

Hüpotees 1: DNS-nimede lahendamine

Iga päringu korral pöördub meie rakendus üks kuni kolm korda AWS Elasticsearch instantsi poole domeenis, mis näeb välja nagu elastic.spain.adevinta.com. Konteinerite sees on meil shell, seega saame kontrollida, kas domeeni otsimine tõepoolest võtab kaua aega.

DNS-päringud konteinerist:

[root@be-851c76f696-alf8z \/]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Küsitav aeg: 22 msec
;; Küsitav aeg: 22 msec
;; Küsitav aeg: 29 msec
;; Küsitav aeg: 21 msec
;; Küsitav aeg: 28 msec
;; Küsitav aeg: 43 msec
;; Küsitav aeg: 39 msec

Sarnased päringud ühest EC2 instantsist, kus rakendus töötab:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Küsitav aeg: 77 msec
;; Küsitav aeg: 0 msec
;; Küsitav aeg: 0 msec
;; Küsitav aeg: 0 msec
;; Küsitav aeg: 0 msec

Arvestades, et otsimine kestab umbes 30 ms, sai selgeks, et DNS lahendamine Elasticsearch'i poole pöördumisel panustab tõesti viivituse suurenemisse.

Kuid see oli kummaline kahel põhjusel:

1. Meil on juba palju Kubernetes'i rakendusi, mis suhtlevad AWS-i ressurssidega, kuid ei kannata suuri viivitusi. Ükskõik, mis põhjus see ka ei oleks, on see seotud just selle juhtumiga.
2. Teame, et JVM rakendab DNS-i mäluvahehoidu. Meie piltides on TTL väärtus määratud $JAVA_HOME/jre/lib/security/java.security ja see on seatud 10 sekundiks: networkaddress.cache.ttl = 10. Teisisõnu peab JVM kõik DNS-i päringud 10 sekundiks vahemällu salvestama.

Esimese hüpoteesi kinnitamiseks otsustasime ajutiselt loobuda DNS-i kõnedest ja vaadata, kas probleem kaob. Esmalt otsustasime rakendust ümber seadistada, et see suhtleks Elasticsearch'iga otse IP-aadressi kaudu, mitte domeeninime kaudu. See nõuaks koodi muutmist ja uut juurutamist, seega lihtsalt sidusime domeeni selle IP-aadressiga /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

Nüüd sai konteiner IP-aadressi peaaegu koheselt. See tõi kaasa mõningase paranemise, kuid olime vaid veidi lähenenud oodatud viivituse tasemele. Kuigi DNS-i lahendamine võttis palju aega, jäi tõeline põhjus endiselt meilt varjatuks.

Võrgu diagnostika

Otsustasime analüüsida liiklust konteinerist, kasutades tcpdump, et jälgida, mis võrgus täpselt toimub:

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

Seejärel saatsime mõned päringud ja allalaadisime nende andmed (kubectl cp my-service:\/capture.pcap capture.pcap) edasiseks analüüsiks Wireshark.

DNS-i päringutes ei olnud kahtlast (välja arvatud üks pisiasi, millest räägin hiljem). Kuid meie teenuse käitlemisel igas päringus oli teatud kõrvalekaldeid. Allpool on ekraanipilt kajastusest, mis näitab päringu vastuvõttu enne vastuse algust:

Pakettide numbrid on esimeses veerus. Selguse huvides olen erinevad TCP voolud värviga esile tõstnud.

Roheline voog, mis algab 328. paketist, näitab, kuidas klient (172.17.22.150) kehtestas TCP-ühenduse konteineriga (172.17.36.147). Pärast esialgset käepigistust (328-330) tõi pakett 331 HTTP GET \/v1\/.. — sisenev päring meie teenusele. Kogu protsess võttis aega 1 ms.

Hall voog (paketist 339) näitab, et meie teenus saatis HTTP-päringu Elasticsearchi eksemplarile (TCP-käepigistus puudub, kuna kasutatakse juba olemasolevat ühendust). Selleks kulus 18 ms.

Praegu on kõik korras ja ajad vastavad enam-vähem oodatud viivitustele (20–30 ms kliendi mõõtmiste puhul).

Kuid sinine sektsioon võtab aega 86 ms. Mis selles toimub? Paketi 333 puhul saatis meie teenus HTTP GET-päringu /latest/meta-data/iam/security-credentials, ning kohe pärast seda, sama TCP-ühenduse kaudu, veel ühe GET-päringu /latest/meta-data/iam/security-credentials/arn:...

Me leidsime, et see kordub iga päringu, mis saadeti jälgimise käigus. DNS-i lahendamine on tõepoolest meie konteinerites veidi aeglasem (selle fenomeni selgitamine on väga huvitav, kuid ma hoian seda eraldi artikli jaoks). Selgus, et pikemate viivituste põhjuseks on kõned AWS Instance Metadata teenusele iga päringu korral.

Hüpotees 2: liigsed kõned AWS-i

Mõlemad endpoint’id kuuluvad AWS Instance Metadata API. Meie mikroteenus kasutab seda teenust töötamisel Elasticsearchiga. Mõlemad kõned kuuluvad baasauditi protsessi. Endpoint, millele esimeses päringus pöördutakse, annab IAM-i rolli, mis on seotud eksemplariga.

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

Teine päring pöördub teise endpoint’i poole, et saada ajutisi volitusi selle eksemplari jaoks:

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

Kliendil on lubatud neid kasutada lühikese aja jooksul ja aeg-ajalt peab ta saama uusi sertifikaate (kuni nende Expiration). Mudel on lihtne: AWS viib läbi sagedase ajutiste võtmete rotatsiooni turvakaalutlustel, kuid kliendid saavad neid mõneks minutiks vahemällu salvestada, et kompenseerida uute sertifikaatide hankimisega seotud jõudluse langust.

AWS Java SDK peaks võtma enda kanda selle protsessi haldamise, kuid mingil põhjusel see ei toimu.

Otsides GitHubist, kohtasime probleemi #1921. See aitas meil määratleda suuna, milles tuleks edasi «kaevata».

AWS SDK uuendab sertifikaate ühel järgmistest tingimustest:

• Nende kehtivuse lõppemise aeg (Expiration) jõuab EXPIRATION_THRESHOLD, mis on koodis fikseeritud 15 minutiks.
• Viimati, kui prooviti sertifikaate uuendada, on möödunud rohkem aega kui REFRESH_THRESHOLD, mis on ‘hardcode’itud 60 minutiks.

Et näha tegelikku aegumistähtaega, mille saime sertifikaatidest, käivitasime ülaltoodud cURL-käsud konteinerist ja EC2 eksemplarist. Sertifikaadi kehtivusaeg, mis saadi konteinerist, osutus palju lühemaks: täpselt 15 minutiks.

Nüüd on kõik selge: esimese päringu korral sai meie teenus ajutisi sertifikaate. Kuna nende kehtivusaeg ei ületanud 15 minutit, otsustas AWS SDK järgmisel päringul need uuendada. Ja seda juhtus iga päringu puhul.

Miks on sertifikaatide kehtivusaeg lühenenud?

AWS Instance Metadata teenus on mõeldud EC2 instantside jaoks, mitte Kubernetes'e jaoks. Teisest küljest ei soovinud me rakenduste liidest muuta. Selle jaoks kasutasime KIAM — tööriista, mis võimaldab Kubernetes'e iga sõlme agentide kaudu kasutajatel (inseneridel, kes juurutavad rakendusi klastrisse) määrata IAM rolle konteineritele pod'ides, justkui need oleksid EC2 instantsid. KIAM püüab kinni väljakutsed AWS Instance Metadata teenusele ja töötleb neid oma vahemälust, saades esmalt AWS'ilt. Rakenduse seisukohalt ei muutu midagi.

KIAM annab pod'idele lühiajalisi sertifikaate. See on mõistlik, arvestades, et pod'i keskmine eluiga on lühem kui EC2 instantsi oma. Vaikimisi on sertifikaatide kehtivusaeg sama 15 minutit.

Seetõttu, kui mõlemad vaikeseaded üksteisega kokku lükata, tekib probleem. Iga rakendusele antud sertifikaat aegub 15 minuti pärast. Samal ajal sunnib AWS Java SDK sundsekkuma igasuguse sertifikaadi uuendamisse, mille kehtivusaeg on vähem kui 15 minutit.

Kuna tulemuseks on ajutine sertifikaat, uuendatakse seda iga päringu korral, mis toob kaasa paari API AWS kõne ja põhjustab märkimisväärset latentsuse suurenemist. AWS Java SDK-s leidsime feature request, milles mainitakse sarnast probleemi.

Lahendus osutus lihtsaks. Muutasime lihtsalt KIAM-i, et ta otsiks pikema kehtivusajaga sertifikaate. Niipea kui see juhtus, käidi päringud läbi ilma AWS Metadata teenuse sekkumiseta ning latentsus langes isegi madalamale tasemele kui EC2-s.

Järeldused

Meie üleviimise kogemustest lähtudes võib öelda, et üks levinumaid probleemide allikaid ei ole vigu Kuberneteses või muudes platvormi elementides. See ei ole seotud ka mikroteenuste fundamentaalsete puudustega, mida me üle kanname. Probleemid tekivad sageli lihtsalt seetõttu, et ühendame erinevaid elemente.

Me segame keerulisi süsteeme, mis pole kunagi varem omavahel suhelnud, lootes, et koos moodustavad nad ühe suurema süsteemi. Kahjuks, mida rohkem komponente, seda rohkem ruumi eksimustele, seda kõrgem on entropia.

Meie puhul ei tulenenud kõrge latentsus Kubernetes, KIAM, AWS Java SDK või meie mikroteenusest. See oli kahe eraldiseisva vaikimisi määratud parameetri ühendamise tulemus: üks KIAM-is ja teine AWS Java SDK-s. Eraldi on mõlemad parameetrid mõistlikud: nii aktiivne sertifikaatide uuendamise poliitika AWS Java SDK-s kui ka lühike sertifikaatide kehtivusaeg KAI-s. Kuid kui need kokku tuua, muutuvad tulemused ettearvamatuks. Kaks sõltumatut ja loogilist otsust ei pea sugugi koos toimima mõistlikult.

P.S. tõlkijalt

Rohkem informatsiooni KIAM-i arhitektuuri kohta, mis integreerib AWS IAM-i Kubernetesega, leiate selles artiklis kui selle loo autoritelt.

Meie blogist leiate ka:

• «3 Kubernetes'i tõrke lugu tootmises: anti-affinity, sujuv sulgemine,Webhook»;
• «Kuidas Kubernetes'e pod'ide prioriteedid põhjustasid seisakuid Grafana Labs'is»;
• «6 huvitavat süsteemiviga Kubernetes'i kasutamise ajal [ja nende lahendamine]»;
• «6 praktilist lugu meie SRE-päevadest».

Allikas: habr.com