“Nampitomboin'ny Kubernetes in-10 ny fahatarana”: iza no tokony homena tsiny amin'izany?

Fanamarihana. transl.: Ity lahatsoratra ity, nosoratan'i Galo Navarro, izay mitana ny toeran'ny Injeniera Lozisialy Principal ao amin'ny orinasa Eoropeana Adevinta, dia “fanadihadiana” mahavariana sy mampianatra eo amin'ny sehatry ny fampandehanana fotodrafitrasa. Ny lohateniny tany am-boalohany dia nitarina kely tamin'ny fandikan-teny noho ny antony hazavain'ny mpanoratra hatrany am-piandohana.

Fanamarihana avy amin'ny mpanoratra: Toa ity lahatsoratra ity nahasarika fifantohana be lavitra noho ny nantenaina. Mbola mahazo fanehoan-kevitra feno hatezerana aho fa mamitaka ny lohatenin'ilay lahatsoratra ary malahelo ny mpamaky sasany. Azoko tsara ny anton'ny zava-mitranga, noho izany, na dia eo aza ny mety hanimba ny tsikombakomba manontolo, dia tiako ny hilaza aminao avy hatrany ny momba ity lahatsoratra ity. Ny zava-mahatalanjona hitako tamin'ny nifindran'ny ekipa ho any Kubernetes dia ny hoe isaky ny misy olana (toy ny fampitomboana ny fahatarana aorian'ny fifindra-monina), ny zavatra voalohany omena tsiny dia i Kubernetes, fa avy eo dia hita fa tsy ny orkestra no tena manao izany. manome tsiny. Miresaka momba ny tranga iray toy izany ity lahatsoratra ity. Ny anarany dia mamerina ny fitarainan'ny iray amin'ireo mpamorona anay (ho hitanao any aoriana fa tsy misy ifandraisany amin'izany i Kubernetes). Tsy hahita fanambarana mahagaga momba an'i Kubernetes eto ianao, saingy afaka manantena lesona tsara roa momba ny rafitra sarotra ianao.

Herinandro vitsivitsy lasa izay, ny ekipako dia nifindra monina microservice iray mankany amin'ny sehatra fototra misy CI/CD, fotoana fandehanana miorina amin'ny Kubernetes, metric ary zava-tsoa hafa. Fitsapana ny hetsika: nikasa ny handray izany ho fototra izahay ary hamindra tolotra 150 eo ho eo amin'ny volana ho avy. Izy rehetra dia tompon'andraikitra amin'ny fampandehanana ny sasany amin'ireo sehatra an-tserasera lehibe indrindra ao Espaina (Infojobs, Fotocasa, sns.).

Taorian'ny nandefasanay ny fampiharana tany amin'ny Kubernetes ary navitrika ny fifamoivoizana sasany ho any aminy, dia nisy tsy ampoizina nanaitra niandry anay. fahatarana (latency) avo 10 heny noho ny tamin'ny EC2 ny fangatahana ao amin'ny Kubernetes. Amin'ny ankapobeny, ilaina ny mitady vahaolana amin'ity olana ity, na miala amin'ny fifindra-monina ny microservice (ary, angamba, ny tetikasa manontolo).

Nahoana no avo kokoa ny fahatarana ao amin'ny Kubernetes noho ny ao amin'ny EC2?

Mba hitadiavana ny fikaonan-doha dia nanangona metrika teny amin'ny lalana fangatahana manontolo izahay. Tsotra ny maritranonay: vavahadin'ny API (Zuul) no mangataka proxies amin'ny ohatra microservice ao amin'ny EC2 na Kubernetes. Ao amin'ny Kubernetes dia mampiasa NGINX Ingress Controller izahay, ary ny backends dia zavatra tsotra toy ny fanapariahana miaraka amin'ny fampiharana JVM amin'ny sehatra Lohataona.

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

Ny olana dia toa mifandray amin'ny latency voalohany ao amin'ny backend (Nomarihako hoe "xx" ny faritra misy olana amin'ny grafika). Ao amin'ny EC2, 20ms eo ho eo ny valin'ny fampiharana. Ao amin'ny Kubernetes, nitombo ho 100-200 ms ny fahatarana.

Nesorinay haingana ireo olona ahiahiana mifandraika amin'ny fiovan'ny fotoam-pivoriana. Ny version JVM dia tsy miova. Tsy misy ifandraisany amin'izany koa ny olana amin'ny fametrahana container: efa nandeha soa aman-tsara tao anaty container amin'ny EC2 ny fampiharana. Loading? Saingy nahatsikaritra fahatarana ambony izahay na dia tamin'ny fangatahana 1 isan-tsegondra aza. Mety ho atao tsinontsinona koa ny fiatoana amin'ny fanangonana fako.

Nanontany tena ny iray amin'ireo mpitantana anay Kubernetes raha toa ka manana fiankinan-doha ivelany ilay fampiharana satria niteraka olana mitovy amin'izany taloha ny fangatahana DNS.

Hypothesis 1: famaha ny anaran'ny DNS

Ho an'ny fangatahana tsirairay dia miditra in-telo na in-telo amin'ny sehatra iray toy ny AWS Elasticsearch ny fampiharana anay elastic.spain.adevinta.com. Ao anatin'ny fitoeranay misy akorandriaka, mba ahafahantsika manamarina raha tena mila fotoana lava ny fitadiavana sehatra iray.

Fanontaniana DNS avy amin'ny container:

[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

Fangatahana mitovitovy amin'ny iray amin'ireo tranga EC2 izay mandeha ny fampiharana:

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

Raha jerena fa 30ms eo ho eo ny fitadiavana, dia nanjary nazava fa ny famahana ny DNS rehefa miditra amin'ny Elasticsearch dia tena nandray anjara tamin'ny fitomboan'ny latency.

Na izany aza, hafahafa izany noho ny antony roa:

1. Efa manana fampiharana Kubernetes taonina izahay izay mifandray amin'ny loharanon-karena AWS nefa tsy mijaly noho ny fahatarana ambony. Na inona na inona antony, dia mifandray manokana amin'ity raharaha ity.
2. Fantatsika fa ny JVM dia manao cache DNS ao anaty fahatsiarovana. Ao amin'ny sarintsika, ny sanda TTL dia voasoratra ao $JAVA_HOME/jre/lib/security/java.security ary asio 10 segondra: networkaddress.cache.ttl = 10. Raha lazaina amin'ny teny hafa, ny JVM dia tokony hameno ny fangatahana DNS rehetra mandritra ny 10 segondra.

Mba hanamafisana ny petra-kevitra voalohany dia nanapa-kevitra izahay ny hampitsahatra ny fiantsoana DNS mandritra ny fotoana kelikely ary hijery raha toa ka lasa ny olana. Voalohany, nanapa-kevitra ny hanova ny fampiharana izahay mba hifandraisany mivantana amin'ny Elasticsearch amin'ny alàlan'ny adiresy IP, fa tsy amin'ny anaran'ny sehatra. Mitaky fanovana kaody sy fametrahana vaovao izany, noho izany dia nanao sarintany fotsiny ny sehatra ho amin'ny adiresy IP-ny /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

Ankehitriny dia nahazo IP saika avy hatrany ilay container. Niteraka fanatsarana kely izany, saingy nanakaiky kely kokoa ny haavon'ny fahatarana nantenaina izahay. Na dia naharitra ela aza ny famahana ny DNS, dia mbola nandositra anay ny tena antony.

Diagnostics amin'ny tambajotra

Nanapa-kevitra ny hamakafaka ny fifamoivoizana avy amin'ny kaontenera mampiasa tcpdumpmba hahitana hoe inona marina no mitranga amin'ny tambajotra:

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

Nandefa fangatahana maromaro izahay avy eo ary naka ny fisamborana azy ireo (kubectl cp my-service:/capture.pcap capture.pcap) ho an'ny fanadihadiana fanampiny ao amin'ny Wireshark.

Tsy nisy zavatra nampiahiahy momba ny fangatahana DNS (afa-tsy ny zavatra kely iray izay horesahiko any aoriana). Nisy zavatra hafahafa anefa teo amin’ny fomba nandraisanay ny fangatahana tsirairay. Ity ambany ity ny pikantsarin'ny fakana sary mampiseho fa ekena ny fangatahana alohan'ny hanombohan'ny valiny:

Ny laharan'ny fonosana dia aseho amin'ny tsanganana voalohany. Mba hanazavana dia nasiako loko ireo stream TCP samihafa.

Ny renirano maitso manomboka amin'ny fonosana 328 dia mampiseho ny fomba nananganan'ny mpanjifa (172.17.22.150) fifandraisana TCP amin'ny fitoeran-javatra (172.17.36.147). Taorian'ny fifanomezan-tanana voalohany (328-330), dia nentina ny fonosana 331 HTTP GET /v1/.. - fangatahana ho avy amin'ny serivisy. Naharitra 1 ms ny dingana manontolo.

Ny renirano miloko (avy amin'ny fonosana 339) dia mampiseho fa ny serivisy dia nandefa fangatahana HTTP tamin'ny ohatra Elasticsearch (tsy misy TCP tànana satria mampiasa fifandraisana efa misy). Naharitra 18ms izany.

Hatreto dia tsara daholo ny zava-drehetra, ary ny fotoana dia mifanandrify amin'ny fahatarana andrasana (20-30 ms rehefa refesina avy amin'ny mpanjifa).

Na izany aza, ny fizarana manga dia maka 86ms. Inona no mitranga ao? Miaraka amin'ny fonosana 333, nandefa fangatahana HTTP GET ny serivisinay /latest/meta-data/iam/security-credentials, ary avy hatrany aorian'izany, amin'ny fifandraisana TCP mitovy, dia misy fangatahana GET hafa amin'ny /latest/meta-data/iam/security-credentials/arn:...

Hitanay fa niverimberina izany tamin'ny fangatahana rehetra nandritra ny dian. Ny famahana ny DNS dia tena miadana kokoa ao amin'ny fitahirizanay (tena mahaliana ny fanazavana momba an'io tranga io, fa hotehiriziko ho an'ny lahatsoratra misaraka). Hita fa ny fiantsoana ny serivisy AWS Instance Metadata no anton'ny fahatarana amin'ny fangatahana tsirairay.

Hypothesis 2: antso tsy ilaina amin'ny AWS

Samy an'ny AWS Instance Metadata API. Mampiasa an'ity serivisy ity ny microservice anay rehefa mihazakazaka Elasticsearch. Ireo antso roa ireo dia ampahany amin'ny dingana fanomezan-dàlana fototra. Ny teboka farany azo idirana amin'ny fangatahana voalohany dia mamoaka ny anjara asan'ny IAM mifandraika amin'ny ohatra.

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

Ny fangatahana faharoa dia mangataka alalana vonjimaika amin'ity tranga ity amin'ny teboka farany faharoa:

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

Ny mpanjifa dia afaka mampiasa azy ireo mandritra ny fotoana fohy ary tsy maintsy mahazo mari-pankasitrahana vaovao tsindraindray (alohan'ny Expiration). Tsotra ny modely: AWS dia manodina ny fanalahidy vonjimaika matetika noho ny antony fiarovana, fa ny mpanjifa dia afaka mitahiry azy ireo mandritra ny minitra vitsivitsy mba hanonerana ny sazy amin'ny asa mifandraika amin'ny fahazoana mari-pankasitrahana vaovao.

Ny AWS Java SDK dia tokony handray ny andraikiny amin'ny fandaminana ity dingana ity, saingy noho ny antony sasany dia tsy mitranga izany.

Rehefa avy nikaroka olana tao amin'ny GitHub izahay dia nahita olana #1921. Nanampy anay izy hamantatra ny lalana tokony hizorana kokoa.

Ny AWS SDK dia manavao ny mari-pankasitrahana rehefa misy ny iray amin'ireto fepetra manaraka ireto:

• Daty farany (Expiration) Latsaka ao EXPIRATION_THRESHOLD, hardcode hatramin'ny 15 minitra.
• Bebe kokoa ny fotoana lasa hatramin'ny andrana farany hanavao ny mari-pankasitrahana noho ny REFRESH_THRESHOLD, natao hardcode mandritra ny 60 minitra.

Mba hijerena ny daty lany daty marina amin'ny mari-pankasitrahana azonay, dia nihazakazaka ireo baiko cURL etsy ambony izahay avy amin'ny container sy ny ohatra EC2. Ny fe-potoana manan-kery amin'ny taratasy fanamarinana azo avy amin'ny kaontenera dia hita fa fohy kokoa: 15 minitra katroka.

Ankehitriny dia nanjary mazava ny zava-drehetra: ho an'ny fangatahana voalohany, ny serivisy dia nahazo mari-pankasitrahana vonjimaika. Satria tsy manan-kery nandritra ny 15 minitra mahery izy ireo, ny AWS SDK dia hanapa-kevitra ny hanavao azy ireo amin'ny fangatahana manaraka. Ary izany dia nitranga tamin'ny fangatahana rehetra.

Nahoana no mihafohy ny fe-potoana manankery ny certificat?

AWS Instance Metadata dia natao hiasa amin'ny tranga EC2 fa tsy Kubernetes. Amin'ny lafiny iray, tsy te hanova ny interface interface izahay. Ho an'ity dia nampiasainay KIAM - fitaovana iray izay mampiasa mpiasa amin'ny node Kubernetes tsirairay, ahafahan'ny mpampiasa (injeniera mametraka rindranasa amin'ny kluster) hanendry ny andraikitry ny IAM amin'ny kaontenera ao anaty pods toy ny hoe EC2 izy ireo. Ny KIAM dia manakana ny antso amin'ny serivisy AWS Instance Metadata ary manodina azy ireo avy amin'ny cache-ny, rehefa nahazo azy ireo taloha avy amin'ny AWS. Raha ny fomba fijery fampiharana dia tsy misy fiovana.

Ny KIAM dia manome mari-pankasitrahana fohy ho an'ny pods. Misy dikany izany raha jerena fa ny androm-piainan'ny pod dia fohy kokoa noho ny ohatra EC2. Vanim-potoana manan-kery ho an'ny fanamarinana mitovy amin'ny 15 minitra ihany.

Vokatr'izany, raha ampifandraisinao ny soatoavina default roa, dia misy olana. Ny taratasy fanamarinana tsirairay omena ny fangatahana iray dia tapitra aorian'ny 15 minitra. Na izany aza, ny AWS Java SDK dia manery ny fanavaozana ny taratasy fanamarinana izay manana latsaky ny 15 minitra alohan'ny daty lany daty.

Vokatr'izany dia voatery havaozina ny taratasy fanamarinana vonjimaika isaky ny fangatahana, izay mitaky antso roa amin'ny AWS API ary miteraka fitomboana lehibe amin'ny fahatarana. Tao amin'ny AWS Java SDK dia hitanay fangatahana endri-javatra, izay miresaka olana mitovy amin'izany.

Tsotra ny vahaolana. Navaozinay fotsiny ny KIAM mba hangataka mari-pankasitrahana manana fe-potoana maharitra kokoa. Raha vao nitranga izany dia nanomboka nikoriana ny fangatahana raha tsy nisy ny fandraisana anjara tamin'ny serivisy AWS Metadata, ary nidina hatrany amin'ny ambaratonga ambany kokoa noho ny tao amin'ny EC2 ny fahatarana.

hitany

Mifototra amin'ny traikefanay momba ny fifindra-monina, ny iray amin'ireo loharanon'ny olana mahazatra indrindra dia tsy ny bibikely ao amin'ny Kubernetes na ireo singa hafa amin'ny sehatra. Tsy mamaly ny lesoka fototra amin'ny microservices alefanay koa izy io. Mipoitra matetika ny olana satria fotsiny hoe mampitambatra singa samihafa isika.

Mampifangaro rafitra saro-takarina izay mbola tsy nifampiraharaha hatrizay izahay, manantena fa hiara-hiangona rafitra tokana sy lehibe kokoa. Indrisy, ny singa bebe kokoa, ny toerana bebe kokoa ho an'ny fahadisoana, ny avo kokoa ny entropy.

Raha ny zava-misy anay dia tsy vokatry ny bibikely na fanapahan-kevitra ratsy tao amin'ny Kubernetes, KIAM, AWS Java SDK, na ny microservice anay ny fahatarana ambony. Izany dia vokatry ny fampifangaroana lamina tsy miankina roa tsy miankina: ny iray ao amin'ny KIAM, ny iray ao amin'ny AWS Java SDK. Raha raisina misaraka, dia misy dikany ireo mason-tsivana roa ireo: ny politika fanavaozana certificat mavitrika ao amin'ny AWS Java SDK, ary ny fe-potoana manankery fohy amin'ny fanamarinana ao amin'ny KAIM. Saingy rehefa atambatra ireo dia lasa tsy ampoizina ny vokany. Vahaolana roa mahaleo tena sy lojika dia tsy voatery hisy dikany rehefa atambatra.

PS avy amin'ny mpandika teny

Azonao atao ny mianatra bebe kokoa momba ny maritrano ny fitaovana KIAM amin'ny fampidirana ny AWS IAM amin'ny Kubernetes ao amin'ny ity lahatsoratra ity avy amin’ny mpamorona azy.

Vakio ihany koa ao amin'ny bilaoginay:

• «Tantara 3 momba ny tsy fahombiazan'ny Kubernetes tamin'ny famokarana: anti-affinity, fanakatonana tsara, webhook";
• «Ahoana no nahatonga ny laharam-pahamehana ao amin'ny Kubernetes tamin'ny fotoana fiatoana tao amin'ny Grafana Labs";
• «6 bibikely rafitra mampiala voly amin'ny fiasan'ny Kubernetes [sy ny vahaolana amin'izy ireo]";
• «Tantara 6 azo ampiharina avy amin'ny fiainantsika andavanandro SRE".

Source: www.habr.com