V minulosti sme preskúmali základné komponenty služobnej siete Istio, oboznámili sme sa so systémom a odpovedali na hlavné otázky, ktoré zvyčajne vznikajú na začiatku práce s Istio. V tejto časti sa pozrieme na to, ako usporiadať zber informácií o sledovaní (tracing) v sieti.
Prvá vec, ktorá mnohým vývojárom a systémovým administrátorom napadne, keď počujú slová služobná sieť, je sledovanie (tracing). A naozaj, do každého uzla siete pridáme špeciálny proxy server, ktorým prechádza celý TCP traffic. Zdá sa, že teraz môžeme jednoducho posielať informácie o všetkých sieťových interakciách v sieti. Bohužiaľ, v skutočnosti sa objavuje množstvo nuáns, ktoré treba vziať do úvahy. Poďme sa na ne pozrieť.
Mýtus číslo jeden: môžeme získať dáta o zásahoch v sieti zadarmo
V skutočnosti môžeme relatívne zadarmo získať iba spojene uzly našej sústavy so šípkami a rýchlosť dát, ktorá prechádza medzi službami (v podstate iba počet bajtov za jednotku času). Avšak vo väčšine prípadov naše služby komunikujú prostredníctvom nejakej aplikačnej úrovne protokolu, ako sú HTTP, gRPC, Redis a tak ďalej. A samozrejme, chceme vidieť sledovacie informácie práve podľa týchto protokolov, chceme vidieť rýchlosť požiadaviek, nie rýchlosť dát. Chceme porozumieť latencii požiadaviek podľa nášho protokolu. Nakoniec, chceme vidieť celú cestu, ktorú požiadavka prejde od vstupu do nášho systému po obdržanie odpovede používateľom. Tento úkol sa už nerobí tak jednoducho.
Na začiatku sa pozrime, ako vyzerá odosielanie tracing spanov z pohľadu architektúry v Istio. Ako sme si pamätali z prvej časti, na zber telemetrie má Istio samostatnú zložku, ktorá sa nazýva Mixer. Avšak v aktuálnej verzii 1.0.* sa odosielanie vykonáva priamo z proxy serverov, konkrétne z envoy proxy. Envoy proxy podporuje odosielanie tracing spanov cez protokol zipkin priamo zo zásobníka. Iné protokoly je možné pripojiť, ale iba prostredníctvom pluginu. S Istio okamžite získavame prebuilt a nakonfigurovaný envoy proxy, ktorý podporuje iba zipkin protokol. Ak chceme použiť napríklad Jaeger protokol a odosielať tracing spany cez UDP, budeme musieť zostaviť svoj obraz istio-proxy. Podpora vlastných pluginov pre istio-proxy existuje, avšak je still v alfa verzii. Preto, ak chceme obísť množstvo vlastných nastavení, okruh použitých technológií na ukladanie a prijímanie tracing spanov sa zmenšuje. Z hlavných systémov je v podstate možné použiť buď Zipkin, alebo Jaeger, ale odosielať tam všetko cez zipkin-kompatibilný protokol (čo je významne menej efektívne). Samotný zipkin protokol predpokladá odosielanie všetkých tracing informácií na kolektory cez HTTP protokol, čo je dosť náročné.
Ako som už povedal, chceme sledovať protokoly aplikačnej úrovne. To znamená, že proxy servery, ktoré sú umiestnené vedľa každého servisu, musia chápať, aká interakcia sa momentálne deje. Predvolene Istio konfiguruje pre všetky porty typ plain TCP, čo znamená, že žiadne trašky nebudú odosielané. Aby sa začali odosielať trašky, je potrebné, po prvé, zapnúť túto možnosť v hlavnom mesh configu a, čo je veľmi dôležité, pomenovať všetky porty u service entít Kubernetes v súlade s protokolom, ktorý sa používa v servise. Teda, napríklad, takto:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxJe tiež možné použiť zložené názvy, napríklad http-magic (Istio uvidí http a rozpozná tento port ako http endpoint). Formát je taký: proto-extra.
Aby sme nemuseli patchovať obrovské množstvo konfigurácií na určenie protokolu, môžeme využiť nečistý workaround: patchovať komponent Pilot v momente, keď práve Nakoniec bude potrebné túto logiku zmeniť na štandardnú a prejsť na konvenciu pomenovania všetkých portov.
Aby sme pochopili, či je protokol skutočne správne definovaný, musíme sa prihlásiť do niektorého z sidecar kontajnerov s envoy proxy a urobiť požiadavku na port administrátorského rozhrania envoy s lokalizáciou /config_dump. V získanej konfigurácii je potrebné skontrolovať pole operation pre požadovanú službu. Používa sa v Istio ako identifikátor, kam je požiadavka smerovaná. Na prispôsobenie hodnoty tohto parametra v Istio (potom ho budeme vidieť v našom sledovacom systéme) je potrebné pri spúšťaní sidecar kontajnera zadať prapor serviceCluster. Napríklad to je možné vypočítať takto z premenných získaných z downward API kubernetes:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Dobrým príkladom na pochopenie, ako funguje sledovanie v envoy, je .
Sám endpoint na odosielanie sledovacích spanov je tiež potrebné zadať v praporoch spúšťania envoy proxy, napríklad: --zipkinAddress tracing-collector.tracing:9411
Mýtus číslo dva: môžeme za nízku cenu získať kompletné trasy prechodu požiadaviek systémom bez dodatočných nákladov.
Bohužiaľ, nie je to pravda. Zložitosti implementácie závisí od toho, akým spôsobom už máte realizované interakcie medzi službami. Prečo je to tak?
Vec je taká, že aby istio-proxy mohlo pochopiť zodpovednosť prichádzajúcich požiadaviek do služby a odchádzajúcich z tej istej služby, nestačí len zachytávať všetok prenos. Je potrebné mať nejaký identifikátor spojenia. V HTTP envoy proxy sa používajú špeciálne hlavičky, podľa ktorých envoy rozumie, ktorá konkrétna požiadavka na službu generuje konkrétne požiadavky do iných služieb. Zoznam takýchto hlavičiek:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-sampled,
- x-b3-flags,
- x-ot-span-context.
Ak máte jednotný bod, napríklad základného klienta, do ktorého je možné pridať túto logiku, potom je všetko v poriadku, len sa budete musieť dočkať aktualizácie tejto knižnice u všetkých klientov. Ale ak máte veľmi heterogénny systém a nie je unifikácia vo spôsoboch komunikácie medzi službami v sieti, potom to pravdepodobne bude veľkým problémom. Bez pridania takejto logiky bude všetka sledovacia informácia jednoducho "jednoúrovňová". Inými slovami, dostaneme všetky medzi služobné interakcie, ale nebudú zlúčené do jedinečných reťazcov prechodu po sieti.
Záver
Istio poskytuje pohodlný nástroj na zhromažďovanie tracing informácií v sieti, avšak je potrebné si uvedomiť, že jeho implementácia vyžaduje prispôsobenie vašej sústavy a zohľadnenie osobitostí realizácie Istio. Nakoniec je potrebné vyriešiť dva hlavné body: určenie aplikačného protokolu (ktorý musí podporovať envoy proxy) a nastavenie prenosu informácií o súvislosti požiadaviek zo služby na požiadavky zo služby (pomocou hlavičiek, v prípade HTTP protokolu). Ak sú tieto otázky vyriešené, získavame mocný nástroj, ktorý umožňuje transparentne zhromažďovať informácie zo siete aj v veľmi heterogénnych systémoch, naprogramovaných v rôznych jazykoch a rámcoch.
V nasledujúcom článku o Service Mesh sa pozrieme na jeden z najväčších problémov Istio – vysokú spotrebu RAM každým sidecar proxy kontajnerom a budeme diskutovať o tom, ako sa s ním dá bojovať.
Zdroj: habr.com
