Istio a Kubernetes vo výrobe. Časť 2. Sledovanie

V poslednom článok Pozreli sme sa na základné komponenty Service Mesh Istio, zoznámili sa so systémom a odpovedali na hlavné otázky, ktoré sa zvyčajne vynárajú pri začatí práce s Istio. V tejto časti sa pozrieme na to, ako organizovať zber informácií o sledovaní cez sieť.

Prvá vec, ktorá mnohým vývojárom a správcom systému napadne, keď počujú slová Service Mesh je sledovanie. Ku každému sieťovému uzlu, cez ktorý prechádza všetka prevádzka TCP, pridávame špeciálny proxy server. Zdá sa, že teraz je možné jednoducho odosielať informácie o všetkých sieťových interakciách v sieti. Bohužiaľ, v skutočnosti existuje veľa nuancií, ktoré je potrebné vziať do úvahy. Pozrime sa na ne.

Mylná predstava číslo jedna: môžeme získať online turistické údaje zadarmo.

V skutočnosti relatívne zadarmo môžeme spojiť uzly nášho systému iba šípkami a rýchlosťou prenosu dát medzi službami (v skutočnosti iba počtom bajtov za jednotku času). Vo väčšine prípadov však naše služby komunikujú cez nejaký druh protokolu aplikačnej vrstvy, ako je HTTP, gRPC, Redis atď. A, samozrejme, chceme vidieť informácie o sledovaní špeciálne pre tieto protokoly; chceme vidieť rýchlosť žiadostí, nie rýchlosť prenosu dát. Chceme pochopiť latenciu požiadaviek pomocou nášho protokolu. Nakoniec chceme vidieť úplnú cestu, ktorou žiadosť prechádza od prihlásenia do nášho systému až po prijatie odpovede od používateľa. Tento problém už nie je také ľahké vyriešiť.

Najprv sa pozrime na to, ako vyzerá rozsah odosielania trasovania z architektonického hľadiska v Istiu. Ako si pamätáme z prvého dielu, Istio má samostatný komponent s názvom Mixer na zbieranie telemetrie. V aktuálnej verzii 1.0.* sa však odosielanie uskutočňuje priamo z proxy serverov, konkrétne z envoy proxy. Envoy proxy podporuje odosielanie rozpätí sledovania pomocou protokolu zipkin hneď po vybalení. Je možné pripojiť ďalšie protokoly, ale iba cez plugin. S Istio okamžite získame zostavený a nakonfigurovaný server proxy, ktorý podporuje iba protokol zipkin. Ak chceme použiť napríklad Jaeger protokol a posielať tracing spans cez UDP, tak si budeme musieť zostaviť vlastný istio-proxy image. Existuje podpora pre vlastné pluginy pre istio-proxy, ale stále je v alfa verzii. Ak sa teda chceme zaobísť bez veľkého množstva vlastných nastavení, rozsah technológií používaných na ukladanie a prijímanie rozpätí sledovania sa zmenšuje. Z hlavných systémov v skutočnosti teraz môžete použiť samotný Zipkin alebo Jaeger, ale všetko tam posielať pomocou protokolu kompatibilného so zipkinom (čo je oveľa menej efektívne). Samotný protokol zipkin zahŕňa odosielanie všetkých informácií o sledovaní zberateľom prostredníctvom protokolu HTTP, čo je dosť drahé.

Ako som už povedal, chceme sledovať protokoly na úrovni aplikácie. To znamená, že proxy servery, ktoré stoja vedľa každej služby, musia pochopiť, aký druh interakcie sa teraz deje. Istio predvolene nakonfiguruje všetky porty ako obyčajný TCP, čo znamená, že sa nebudú odosielať žiadne stopy. Aby sa mohli odosielať stopy, musíte túto možnosť najskôr povoliť v konfigurácii hlavnej siete a čo je veľmi dôležité, pomenovať všetky porty entít služby kubernetes podľa protokolu, ktorý sa v službe používa. Teda napríklad takto:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Môžete tiež použiť zložené názvy ako http-magic (Istio uvidí http a rozpozná tento port ako koncový bod http). Formát je: proto-extra.

Aby ste neopravovali veľké množstvo konfigurácií na určenie protokolu, môžete použiť špinavé riešenie: opravte komponent Pilot v momente, keď je vykonáva logiku definície protokolu. Nakoniec bude samozrejme potrebné zmeniť túto logiku na štandardnú a prejsť na konvenciu pomenovania pre všetky porty.

Aby ste pochopili, či je protokol skutočne definovaný správne, musíte prejsť do ľubovoľného kontajnera postranného vozíka s proxy servera a odoslať požiadavku na port správcu rozhrania vyslanca s umiestnením /config_dump. Vo výslednej konfigurácii sa musíte pozrieť na operačné pole požadovanej služby. Používa sa v Istio ako identifikátor miesta, kde sa žiadosť podáva. Aby bolo možné prispôsobiť hodnotu tohto parametra v Istio (následne ho uvidíme v našom sledovacom systéme), je potrebné špecifikovať príznak serviceCluster vo fáze spúšťania kontajnera postranného vozíka. Napríklad sa dá vypočítať takto z premenných získaných z klesajúceho kubernetes API:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Dobrým príkladom na pochopenie toho, ako funguje sledovanie v vyslancovi, je tu.

Samotný koncový bod na odosielanie rozsahov sledovania musí byť špecifikovaný aj v príznakoch spustenia proxy servera, napríklad: --zipkinAddress tracing-collector.tracing:9411

Mylná predstava číslo dva: môžeme lacno získať kompletné stopy žiadostí prostredníctvom systému hneď po vybalení

Žiaľ, nie je. Zložitosť implementácie závisí od toho, ako ste už implementovali interakciu služieb. prečo je to tak?

Faktom je, že na to, aby istio-proxy dokázalo pochopiť korešpondenciu prichádzajúcich požiadaviek na službu s tými, ktorí opúšťajú rovnakú službu, nestačí jednoducho zachytiť všetku komunikáciu. Musíte mať nejaký komunikačný identifikátor. HTTP envoy proxy používa špeciálne hlavičky, pomocou ktorých envoy rozumie, ktorá konkrétna požiadavka na službu generuje špecifické požiadavky na iné služby. Zoznam takýchto hlavičiek:

• x-request-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-vzorky,
• x-b3-flags,
• x-ot-span-context.

Ak máte jeden bod, napríklad základného klienta, v ktorom môžete pridať takúto logiku, potom je všetko v poriadku, len treba počkať na aktualizáciu tejto knižnice pre všetkých klientov. Ale ak máte veľmi heterogénny systém a neexistuje žiadna jednota pri prechode zo služby na službu cez sieť, potom to bude s najväčšou pravdepodobnosťou veľký problém. Bez pridania takejto logiky budú všetky informácie o sledovaní iba „jednoúrovňové“. To znamená, že dostaneme všetky interakcie medzi službami, ale nebudú zlepené do jednotlivých reťazcov prechodu cez sieť.

Záver

Istio poskytuje pohodlný nástroj na zhromažďovanie informácií o sledovaní cez sieť, ale musíte pochopiť, že na implementáciu budete musieť prispôsobiť váš systém a vziať do úvahy vlastnosti implementácie Istio. V dôsledku toho je potrebné vyriešiť dva hlavné body: definovať protokol na úrovni aplikácie (ktorý musí byť podporovaný proxy servera) a nastaviť preposielanie informácií o pripojení požiadaviek k službe z požiadaviek zo služby (pomocou hlavičiek , v prípade protokolu HTTP). Keď sú tieto problémy vyriešené, máme výkonný nástroj, ktorý nám umožňuje transparentne zbierať informácie zo siete, a to aj vo veľmi heterogénnych systémoch napísaných v mnohých rôznych jazykoch a rámcoch.

V ďalšom článku o Service Mesh sa pozrieme na jeden z najväčších problémov Istio – veľkú spotrebu RAM každým kontajnerom proxy postranného vozíka a prediskutujeme, ako sa s tým môžete vysporiadať.

Zdroj: hab.com